During the extraction of the Smart PHY release package an example directory is created under the staging directory. The example directory contains the following sample configuration files:

• deploy-sample-config.yaml—A configuration file with a deployer, but no cluster.

• aio-smartphy-config.yaml—A configuration file with a deployer and a single-node Smart PHY cluster.

• multinode-smartphy-config.yaml—A configuration file a deployer and multinode Smart PHY cluster.

• aio-smartphy-standby-config.yaml—A configuration file with a deployer and a single-node Smart PHY cluster that is configured for standby (without CIN configuration).

• multinode-smartphy-standby-config.yaml—A configuration file with a deployer and a multinode Smart PHY cluster configured standby (without CIN configuration).

Place the configuration file in the staging directory. This configuration file is in the standard YAML language format, with the following three sections:

• Environments

• Deployers

• Clusters (Smart PHY multi-node/single-node)

Each section can contain multiple items. Replace <...> with actual values.

The environments section defines a vSphere deployment domain. This environment is referenced in the deployers and clusters sections, which you define shortly.

environments:
    <env-name>:                           # Environment name                      
        server: <value>                   # vCenter Server IPv4 Address or name
        username: <value>                 # vCenter username, user will be prompted for the password  
        datacenter: <valuer>              # vCenter Datacenter Name       
        cluster: <value>                  # vCenter Cluster Name       
        nics: [ <list> ]                  # List of vCenter nics (port groups)
        nameservers: [ <value> ]          # List of DNS Server IPv4 Addresses
        search-domains: [ <value> ]       # List of Search domains
        ntp: [ <list> ]                   # List od NTP Server IPv4 Addresses or name
        https-proxy: <value>              # Optional HTTPS Proxy (Ex: http://proxyhost.domain.tld:port)
        no-proxy: <value>                 # Optional HTTPS Proxy bypass

Guidelines for Defining an Environment

• The environment name can have only lowercase letters, digits, and hyphens (-).

• The nics list must contain only one network, although the nics configuration allows multiple networks. This network is used as the management network by the deployer or cluster that refers to this environment.

• Create multiple environments if your vCenter has more than one network that serves as a management network. Create one environments for each network. In addition, refer to the corresponding environments in the deployer or cluster based on the management network it uses.

• Make sure the nics, nameservers, and search-domains values are structured as YAML lists.

The deployers section defines the configuration of a Deployer VM.

deployers:
   <deployer-vm-name>:                 # Deployer VM name
       environment: <value>            # Environment name defined in the 'Environments' section.
       address: <value>                # Deployer VM IPv4 Address in CIDR format
       gateway: <value>                # Deployer VM's Gateway IP Address
       ingress-hostname: <value>       # Optional FQDN (Ex. "deployer1.example.com")
       username: <value>               # Deployer VM username, you will be prompted for the password  
       private-key-file: <value>       # Optional SSH private-key-file (.pem) with path relative to the staging 
                                       #   directory. Key will be auto-generated, if one if not provided.                     
       host: <value>                   # IPv4 Address of the ESXi Host
       datastore: <value>              # Datastore for the Deployer VM
       datastore-folder: <value>       # Optional Datastore folder path. When omitted deployer and
                                       #   cluster VMs are created under root of the Datastore.
                                       #
       # 'docker-subnet-override' and its values are optional. It should only be 
       #  used when you need to customize the deployer VM's Docker IP Addressing.
       #  When omitted, the Docker bridge defaults to 172.17.0.0/16.
                                       #
       docker-subnet-override:         #
       - pool-name: <value>            # Docker bridge address pool name
         base: <value>                 # Docker bridge subnet in CIDR format
         size: <value>                 # Docker bridge subnet size: 8-24

Guidelines for Defining a Deployer

• The deployer-vm-name can have only lowercase letters, digits, and hyphens (-).

• The private-key-file, when present, must refer to the SSH private key file (.pem). This file must be in the staging directory and must not be accessible (read/write/execute) to other users.

• If the private-key-file line is omitted, the deploy tool generates an SSH private key for the deployer and places it in the .sec subdirectory under the staging directory. The filename is <deployer-vm-name>_auto.pem.

• The values associated with docker-subnet-override are optional. Those values should only be included in the configuration when you need to customize the deployer VM's Docker IP addressing. When omitted, the Docker bridge on the Deployer VM defaults to 172.17.0.0/16.

• To avoid resource contention, do not host the deployer VM on the same ESXi hosts running any of the cluster VMs.

• When you configure a custom ingress-hostname, ensure that the following entries are in the DNS:

  
   <host.domain.tld>
   charts.<host.domain.tld>
   files-offline.smi-cluster-deployer.<host.domain.tld>
   deployer-ui.smi-cluster-deployer.<host.domain.tld>
   cli.smi-cluster-deployer.<host.domain.tld>
   restconf.smi-cluster-deployer.<host.domain.tld>
   docker.<host.domain.tld>
  

The clusters section defines the type and configuration of the cluster. At least one environment and one deployer must be defined in the cluster configuration file in order for a cluster to be deployed.

Clusters can be deployed on a single ESXi host or across three ESXi hosts. The single host deployment is known as a single-node deployment, or an All-in-one (AIO), while the three-node deployment is known as a multi-node deployment.

The clusters configuration below shows the mandatory and optional key-value pairs required for a multi-node deployment.

clusters:
   <cluster-name>:                                         # Cluster name
       type: <value>                                       # Cluster type must be 'opshub'
       size: <value>                                       # Optional cluster size: 'small' or 'normal'. Defaults to small when not specified.
       environment: <value>                                # Environment name defined in the 'Environments' section.
       gateway: <value>                                    # Cluster Gateway IPv4 Address
       ingress-hostname: <value>                           # Optional FQDN (Ex. “smartphy.example.com”)
       username: <value>                                   # Cluster username, User will be prompted for the cluster password  
       private-key-file: <value>                           # SSH private-key-file (.pem) including path relative to the staging directory
                                                           #  Key will be auto-generated, if not provided. 
                                                           #
       primary-vip: <value>                                # Management Virtual IPv4 Address in CIDR format 
       vrouter-id:  <value>                                # Management Keepalived Virtual Router ID, value must be between 0-255
                                                           #    
       enable-http-redirect: value                         # Optional. Defaults to false when not specified. Set to “true” to redirect HTTP requests to HTTPS.
       # The next three key-value pairs are optional. They should only be used
       # when you need to customize the cluster's internal IP Addressing:
                                                            #
       pod-subnet: <value>                                  # K8s Pod subnet in CIDR format. If omitted, defaults to: 192.168.0.0/16
       service-subnet: <value>                              # K8s Service subnet in CIDR format. If omitted, defaults to 10.96.0.0/12
       docker-bridge-subnet: [ <addr-list> ]                # List of Docker bridge subnets in CIDR format. If omitted, defaults to 172.17.0.0/16
                                                            #
       nodes:                                               # 
       -  host: <value>                                     # ESXi Host 1: IPv4 Address  
          addresses: [ <addr-list> ]                        # ESXi Host 1: List of Mgmt IPv4 addr assigned to control-plane, etcd, infra, and Ops VMs respectively
          datastore: <value>                                # ESXi Host 1: IPv4 Address for vCenter Datastore 
       -  host: <value>                                     # ESXi Host 2: IPv4 Address  
          addresses: [ <addr-list> ]                        # ESXi Host 2: List of Mgmt IPv4 addr assigned to control-plane, etcd, infra, and Ops VMs respectively
          datastore: <value>                                # ESXi Host 2: IPv4 Address for vCenter Datastore
       -  host: <value>                                     # ESXi Host 3: IPv4 Address 
          addresses: [ <addr-list> ]                        # ESXi Host 3: List of Mgmt IPv4 addr assigned to control-plane, etcd, infra, and Ops VMs respectively
          datastore: <value>                                # ESXi Host 3: IPv4 Address for vCenter Datastore
                                                            #
       apps:                                                #   
       - smartphy:                                          # All of the parameters below are Smart PHY specific
         nodes:                                             #
           - host: <value>                                  # ESXi Host 1: IPv4 Address (Same address as used earlier in the nodes section.)
             nics: [ <list> ]                               # ESXi Host 1: vCenter list of Network for CIN
             ops:                                           # -- The following parameters apply to Ops VM 1. --
               interfaces:                                  # Ops VM 1: CIN Interface configuration:
                 - addresses: [ <addr-list> ]               #   Ops VM 1: List of CIN IPv4 or v6 Addresses in CIDR format
                   vip: [ <vip-list> ]                      #   Ops VM 1: List of CIN Virtual IPv4 or v6 Addresses in CIDR format
                   vrouter-id: <value>                      #   Ops VM 1: CIN Keepalived Virtual Router ID, value must be between 0-255
                   routes:                                  #   Ops VM 1: Optional Route configuration:
                     - { dest: [ <list> ], nhop: <value> }  #      Ops VM 1: Optional list of Destination Subnets; Next-Hop IP Address
                     - { dest: [ <list> ], nhop: <value> }  #      Ops VM 1: Optional list of Destination Subnets; Next-Hop IP Address
          - host: <value>                                   # ESXi Host 2: IPv4 Address (Same address as used earlier in the nodes section.)
             nics: [ <list> ]                               # ESXi Host 2: vCenter list of Network for CIN
             ops:                                           # -- The following parameters apply to Ops VM 2. --
               interfaces:                                  # Ops VM 2: CIN Interface configuration:
                 - addresses: [ <addr-list> ]               #   Ops VM 2: List of CIN IPv4 or v6 Addresses in CIDR format
                   vip: [ <vip-list> ]                      #   Ops VM 2: List of CIN Virtual IPv4 or v6 Addresses in CIDR format
                   vrouter-id: <value>                      #   Ops VM 2: CIN Keepalived Virtual Router ID, value must be between 0-255
                   routes:                                  #   Ops VM 2: Optional Route configuration:
                     - { dest: [ <list> ], nhop: <value> }  #     Ops VM 2: Optional list of Destination Subnets; Next-Hop IP Address
                     - { dest: [ <list> ], nhop: <value> }  #     Ops VM 2: Optional list of Destination Subnets; Next-Hop IP Address
       - host: <value>                                      # ESXi Host 3: IPv4 Address (Same address as used earlier in the nodes section.)
             nics: [ <list> ]                               # ESXi Host 3: vCenter list of Network for CIN
             ops:                                           # -- The following parameters apply to Ops VM 3. --
               interfaces:                                  # Ops VM 3: CIN Interface configuration:
                 - addresses: [ <addr-list> ]               #   Ops VM 3: List of CIN IPv4 or v6 Addresses in CIDR format
                   vip: [ <vip-list> ]                      #   Ops VM 3: List of CIN Virtual IPv4 or v6 Addresses in CIDR format
                   vrouter-id: <value>                      #   Ops VM 3: CIN Keepalived Virtual Router ID, value must be between 0-255
                   routes:                                  #   Ops VM 3: Optional Route configuration:
                     - { dest: [ <list> ], nhop: <value> }  #     Ops VM 3: Optional list of Destination Subnets; Next-Hop IP Address
                     - { dest: [ <list> ], nhop: <value> }  #     Ops VM 3: Optional list of Destination Subnets; Next-Hop IP Address

Guidelines for Defining a Cluster

• The cluster-name can have only lowercase letters, digits, and hyphens (-).

• When you specify a FQDN in the ingress-hostname, ensure that the corresponding entries are configured in your DNS servers:

  
  <host.domain.tld>
  opscenter.<host.domain.tld>
  

• If you do not specify an FQDN in the ingress-hostname, the cluster's primary-vip (also known as the Management Virtual IP address) is used to generate an FQDN leveraging nip.io as the domain and top-level domain (TLD). For example, if the primary-vip is 10.0.0.2, the generated FQDN is 10.0.0.2.nip.io. Your DNS servers must allow the resolution of the nip.io domain. If resolution of nip.io is blocked, you cannot access the cluster.

• The private-key-file, when present, must refer to the SSH private key file (.pem). This file must be in the staging directory and must not be accessible (read/write/execute) to other users.

• If the private-key-file line is omitted, the deploy tool generates an SSH private key for the cluster and places it in the .sec subdirectory under the staging directory. The filename is <cluster-name>_auto.pem.

• If multiple clusters share the same management subnet, the management vrouter-id (VRRP ID) of each cluster must be unique.

Configure Converged Interconnect Network (CIN) for the Cisco Smart PHY cluster. One or more CIN networks can be present. Configure CIN under each node.

Guidelines for Defining Smart PHY's CIN Interfaces

• The CIN Virtual IP addresses (vip) filed is mandatory. You can configure up to one IPv4 and one IPv6 addresses per CIN network.

• The CIN Virtual IP addresses (vip) and the VRRP ID (vrouter-id) fields are used only in multi-node cluster deployments. They are configured on the first node.

• If multiple Smart PHY clusters share a CIN subnet, the VRRP ID (vrouter-id) should be unique for each cluster.

• For multi-node clusters, all Ops VMs must have the same number of CIN interfaces. If the nics or route fields are missing for the second or third Ops VM nodes, the corresponding value from the first Ops VM node is used.

• You can setup a Smart PHY cluster as a backup cluster. To do so, do not include any CIN configuration. The configuration should not have ops and interfaces under nodes.

Note	Cisco Smart PHY clusters can connect to multiple CIN networks using multiple network interfaces configured during deployment.