We all have been there, you deploy a new Nutanix HCI Cluster with the help of Nutanix Foundation and then the real configuration steps start. Unfortunately not every setting can be defined via the API so we will connect to the Controller VM to run some basic commands to secure our cluster.
My notes from the field on the actions required:
- Name the cluster
- Define DNS, NTP & Proxy Servers
- Join the Nutanix cluster to Prism Central
- Set resiliency factor of the Nutanix cluster
- Set the Data services IP of the Nutanix cluster
- Enable Pulse
- Create customer default storage containers
- Enable Data-At-Rest Encryption (DARE)
- Create workload vLANs
Name the cluster
To ensure the clustername is correct, I always start with naming the cluster (again)
ncli cluster set-name name=<NewClusterName>Define DNS, NTP & Proxy servers
DNS is important for name resolution in the network where the HCI cluster resides, whereas NTP is crucial for a proper functioning for your cluster.
DNS
ncli cluster get-name-serversncli cluster add-to-name-servers servers=<DNS-Server-IP1>,<DNS-Server-IP2>ncli cluster add-to-dns-search-suffixes search-suffix=<AD Domain>NTP
ncli cluster get-ntp-servers
ncli cluster add-to-ntp-servers servers=<NTP-Server-IP1>,<NTP-Server-IP2>,<NTP-Server-IP3>,<NTP-Server-IP4>,<NTP-Server-IP5>And the last thing for NTP is to set the correct timezone
ncli cluster set-timezone timezone=Europe/AmsterdamProxy
Not every environment is behind a proxy but if you need to access the internet via a proxy you need to ensure the proxy is set on your cluster. To avoid issues with registration to Prism Central, add the Prism Central to the proxy whitelist
ncli http-proxy add name=Proxy port=<proxy-port> address=<proxy-IP>ncli cluster add-to-proxy-whitelist ip-subnet-masks= <Prism-Central-IP/32>Join the Nutanix cluster to Prism Central
Check if the cluster is not registered to a Prism Central
ncli multicluster get-cluster-stateRegister to Prism Central
ncli multicluster register-to-prism-central prism-central-ip=<PC IP> username=admin password=<PASSWORD>After the cluster is registered to Prism Central I make sure that the licenses are in place so all features can be enabled without any errors.
Set resiliency factor of the Nutanix cluster
The resiliency factor in Nutanix refers to the system’s ability to maintain data integrity and availability through replication, typically defined by replication factors of 2 or 3. Nutanix uses a concept called Replication Factor (RF), which determines how many copies of data are stored across the cluster. The most common settings are:
- RF2: Two copies of data are maintained, ensuring that data is available even if one node fails.
- RF3: Three copies of data are maintained, providing an additional layer of redundancy and fault tolerance.
Check the redundancy state of the cluster
ncli cluster get-redundancy-stateSet the cluster redundancy state to the desired factor
ncli cluster set-redundancy-state desired redundancy-factor=3Set the Data services IP of the Nutanix cluster
The Data Services IP in Nutanix is a cluster-wide IP address used to provide access to storage services, such as iSCSI and Nutanix Files. It acts as a discovery portal and an initial connection point for clients, simplifying external configurations.
ncli cluster edit-params external-data-services-ip-address=<Data-Services-IP>
Enable Pulse
Nutanix Pulse is a built-in tool designed to send diagnostic and usage data from Nutanix clusters to Nutanix Support. It helps administrators and support teams monitor cluster health, detect potential issues early, and provide context-aware guidance for troubleshooting without impacting system performance. Pulse collects basic system-level information, such as cluster status, configuration, and performance metrics, but does not collect personally identifiable information (PII).
ncli pulse-config edit enable=true enable-default-nutanix-email=true support-verbosity-level=BASIC_COREDUMP email-contacts=<email-contact1>, <email-contactn>ncli alerts edit-alert-config enable=true enable-default-nutanix-email=true email-contacts=<email-contact1>, <email-contactn>
Create customer default storage containers
Nowadays you can do a lot with the storage policies (set RF, enable/disable encryption, data reduction settings) but I still create 2 distinct containers for the client. One container is for “standard” workloads (incl OS-disks of DB workloads) and the 2nd one is for hosting database.
First I get the default container and delete that one:
dctr=ncli ctr list | grep-i VStore | grep-i default | awk '{print $4}'ncli container remove name=$dctrOn the SelfService Container all data reduction measures are enabled:
ncli container update name=SelfServiceContainer enable-compression=true compression-delay=0 on-disk-dedup=post-process erasure-code=onWhen that’s done I create the 2 containers (with different settings)
spname=ncli sp list | grep-i name | awk '{print $3}'ncli container create name=DefaultContainer sp-name=$spname enable-compression=true compression-delay=0 on-disk-dedup=post-process erasure-code=on rf=3ncli container create name=DatabaseContainer sp-name=$spname enable-compression=true compression-delay=0 rf=3
Enable Data-At-Rest Encryption (DARE)
Within most of my clients Software based encryption using the AES-256 standard is enabled where the main difference is where the keys are stored, either on an external KMS server or a native (local) KMS server.
External KMS Server
ncli key-management-server add name=<KMS-Server> ip-address= port=5696ncli cluster enable-encryption key-management-server=<KMS-Server>Native KMS Server
ncli cluster enable-encryptionCreate workload vLANs
Last step of my initial cluster deployment is to define the workload vLANs. Within the current client we deploy Basic vLANs that are internally (incl. IPAM) & externally managed.
External
acli net.create <VLAN-NAME> vlan=<VLAN-ID>Internal
acli net.create <VLAN-NAME> vlan=<VLAN-ID> ip_config=<IP-RANGE/SUBNET-MASK> dhcp_address=<DHCP-IP>acli net.add_dhcp_pool <VLAN-NAME> start=<DHCP-POOL-STARTIP> end=<DHCP-POOL-ENDIP>I normally have a text file containing these commands that will be updated before I start a deployment and then after this first actions I just logon to the CVM and copy/paste the commands and my cluster is deployed and secured and ready to be used.