Nutanix Clusters provides a single platform that can span private and public clouds but operates as a single cloud using Prism Central enabling true hybrid cloud architecture.
Using the same platform on both clouds, Nutanix Clusters on AWS (NCA) reduces the operational complexity of extending, bursting, or migrating your applications and data between clouds. Because Nutanix Clusters runs Nutanix AOS and AHV with the same CLI, UI, and APIs, existing IT processes or third-party integrations that work on-premises continue to work regardless of where they are running. Nutanix Clusters resources are deployed in your cloud provider account, thereby enabling you to use your existing cloud provider relationship, credits, commits, and discounts.
Figure. Overview of the Nutanix Enterprise Cloud Software
Click to enlarge
Nutanix Clusters place the complete Nutanix hyperconverged infrastructure (HCI) stack directly on a bare-metal instance in Amazon Elastic Compute Cloud (EC2). This bare-metal instance runs a Controller VM (CVM) and Nutanix AHV as the hypervisor like any on-premises Nutanix deployment, using the AWS Elastic Network Interface (ENI) to connect to the network. AHV user VMs do not require any additional configuration to access AWS services or other EC2 instances.
AHV runs an embedded distributed network controller that integrates user VM networking with AWS networking. Instead of creating an overlay network, Nutanix Clusters integrates IP address management with AWS Virtual Private Cloud (VPC). AWS allocates all user VM IP addresses from the AWS subnets in the existing VPCs. Native integration with AWS networking allows you to seamlessly use AWS services on AHV user VMs without a complex network deployment or performance loss.
AOS can withstand hardware failures and software glitches and ensures that application availability and performance are managed as per the configured resilience. Combining features such as native rack awareness with AWS partition placement groups allows Nutanix to operate freely in a dynamic cloud environment.
Nutanix Clusters provides on-prem workloads, a home in the cloud, offering native access to available AWS services without requiring you to reconfigure your software.
To use Nutanix Clusters, you must have a My Nutanix account and subscribe to Nutanix Clusters. See Nutanix Clusters Registration for information about how to subscribe to Nutanix Clusters.
You use the Nutanix Clusters console to deploy a cluster in a VPC in AWS, and not Foundation. After you launch a Nutanix cluster in AWS by using Nutanix Clusters, you can operate the cluster in the same manner as you operate your on-prem Nutanix cluster with no change in nCLI, the Prism Element and Prism Central web console, and APIs. You use the Nutanix Clusters console to create, hibernate, resume, update, and delete your Nutanix cluster.
Note: Nutanix cluster is deployed in AWS in approximately 40 to 45 minutes. If there are any issues with provisioning the Nutanix cluster, see the Notification Center on the Nutanix Clusters Dashboard.
See Software Documentation in the Nutanix portal to perform regular Nutanix tasks after you create a Nutanix cluster in AWS.
Key Points About Nutanix Clusters on AWS
Following are the key points about Nutanix Clusters on AWS:
-
Runs on the EC2 bare metal instances. Nutanix supports the following EC2 bare metal instances:
-
z1d.metal
-
m5d.metal
-
i3.metal
-
i3en.metal
-
-
Supports three or more EC2 bare metal instances. See the Limitations section for more information about the number of nodes supported by Nutanix Clusters.
-
Supports only the AHV hypervisor on Nutanix clusters running in AWS.
-
Supports both existing on-prem Prism Central instance or Prism Central instance deployed on Nutanix Clusters on AWS to manage the Nutanix clusters in AWS.
AWS Infrastructure for Nutanix Clusters
The Nutanix Clusters console places the complete Nutanix hyperconverged infrastructure (HCI) stack directly on a bare-metal instance in Amazon Elastic Compute Cloud (EC2). This bare-metal instance runs a Controller VM (CVM) and Nutanix AHV as the hypervisor like any on-premises Nutanix deployment, using the AWS Elastic Network Interface (ENI) to connect to the network. AHV user VMs do not require any additional configuration to access AWS services or other EC2 instances.
Nutanix Clusters stack in AWS includes the following:
-
VPC in AWS.
-
Private management subnet.
-
One or more private subnets for user VMs (UVMs).
Figure. AWS Infrastructure for Nutanix Clusters
Click to enlarge
When you deploy a Nutanix cluster in AWS by using the Nutanix Clusters console, you can either choose to deploy the cluster in a new VPC and private subnet, or choose to deploy the cluster in an existing VPC and private subnet. If you opt to deploy the cluster in a new VPC, during the cluster creation process, the Nutanix Clusters console provisions a new VPC and private subnet for management traffic in AWS. You must manually create one or more separate subnets in AWS for user VMs.
-
Nutanix Clusters Architecture
The bare metal instance runs the AHV hypervisor and the hypervisor, like any on-premises deployment, runs a Controller Virtual Machine (CVM) with direct access to NVMe instance storage hardware. -
Nutanix Clusters Security Approach
Nutanix takes a holistic approach to security and mandates the following to deploy a secure Nutanix Clusters infrastructure:
Nutanix Clusters Architecture
The bare metal instance runs the AHV hypervisor and the hypervisor, like any on-premises deployment, runs a Controller Virtual Machine (CVM) with direct access to NVMe instance storage hardware.
Acropolis Distributed Storage Fabric (ADSF) uses the following three core principles for distributed systems to achieve linear performance at scale:
-
Must have no single points of failure (SPOF).
-
Must not have any bottlenecks at any scale (must be linearly scalable).
-
Must apply concurrency (MapReduce).
Together, a group of Nutanix nodes forms a distributed system (Nutanix cluster) responsible for providing the Prism and Acropolis capabilities. Each cluster node has two EBS volumes attached. Both are gp2 volumes. The size of each volume is 100GiB. All services and components are distributed across all CVMs in a cluster to provide for high-availability and linear performance at scale.
Figure. Nutanix Clusters AWS Architecture
Click to enlarge
This enables our MapReduce Framework (Curator) to use the full power of the cluster to perform activities concurrently. For example, activities such as data protection, compression, erasure coding, deduplication, and more.
Figure. Cluster Deployment in a VPC
Click to enlarge
-
Preventing Network Partition Errors
The DSF uses the Paxos algorithm to avoid split-brain scenarios. Paxos is a proven protocol for reaching consensus or quorum among several participants in a distributed system. -
Resolving Bad Disk Resources
The DSF incorporates a Curator process that performs background housekeeping tasks to keep the entire cluster running smoothly. -
Maintaining Availability: Node and Rack Failure
The cluster orchestrator running in the cloud service is responsible for maintaining your intended capacity under rack and node failures. -
Maintaining Availability: AZ Failure
AWS Availability Zones are distinct locations within an AWS Region that are engineered to be isolated from failures in other Availability Zones. They provide inexpensive, low-latency network connectivity to other Availability Zones in the same AWS Region. -
Hybrid Deployment
To protect your Nutanix Cluster if there is an Availability Zone failure, use your existing on-prem Nutanix cluster as a disaster recovery target. -
Multiple–Availability Zone Deployment
If you do not have an on-prem cluster available for data protection or you want to use the low-latency links between Availability Zones, you can create a second Nutanix Clusters in a different Availability Zone.
Preventing Network Partition Errors
The DSF uses the Paxos algorithm to avoid split-brain scenarios. Paxos is a proven protocol for reaching consensus or quorum among several participants in a distributed system.
Before any file system metadata is written to Cassandra, Paxos ensures that all nodes in the system agree on the value. If the nodes do not reach a quorum, the operation fails in order to prevent any potential corruption or data inconsistency. This design protects against events such as network partitioning, where communication between nodes may fail or packets may become corrupt, leading to a scenario where nodes disagree on values. The DSF also uses time stamps to ensure that updates are applied in the proper order.
Resolving Bad Disk Resources
The DSF incorporates a Curator process that performs background housekeeping tasks to keep the entire cluster running smoothly.
The multiple responsibilities of Curator include ensuring file system metadata consistency and combing the extent store for corrupt and under replicated data.
Also, Curator scans extents in successive passes, computes each extent’s checksum, and compares it with the metadata checksum to validate consistency. If the checksums do not match, the corrupted extent is replaced with a valid extent from another node. This proactive data analysis protects against data loss and identifies bad sectors you can use to detect disks that are about to fail.
Maintaining Availability: Node and Rack Failure
The cluster orchestrator running in the cloud service is responsible for maintaining your intended capacity under rack and node failures.
Instances in the cluster are deployed using a partition placement group with seven partitions. A placement group is created for each instance type and the instances are maintained well balanced within the placement group. The placement group + partition number is translated into a rack ID of the node. This enables ADSF to place meta data and data replicas in different fault domains.
Figure. Nutanix Clusters on AWS –- Partition Placement (Multi)
Click to enlarge
Setting up a cluster with redundancy factor 2 (RF2) protects data against a single rack failure and setting it up with RF3 protects against a two-rack failure. Also, to protect against multiple correlated failures within a data center and an entire AZ failure, Nutanix recommends you set up sync replication to a second cluster in a different AZ in the same Region or an async replication to an AZ in a different Region. AWS data transfer charges may apply.
AWS deploys each node of the Nutanix cluster on a separate AWS rack (also called AWS partition) for fault tolerance.
If a cluster loses rack awareness, an alert is displayed in the Alerts dashboard of the Prism Element web console and the Data Resiliency Status dashboard displays a Critical status.
A cluster might lose rack awareness if you:
-
Update the cluster capacity.
For example, if you add or remove a node. -
Manually condemn a node or the condemn node action is automatically triggered by the Nutanix Clusters console.
-
Change the Replication Factor (RF), that is from RF2 to RF3.
-
Create a cluster with either 8 or 9 nodes and configure RF3 on the cluster.
-
Deploy a cluster in an extremely busy AWS region.
This is a rare scenario in which the cluster might get created without rack awareness due to limited availability of resources in that region.
Contact Nutanix Support for assistance if you receive an alert in the Prism Element web console that indicates your cluster has lost rack awareness.
Maintaining Availability: AZ Failure
AWS Availability Zones are distinct locations within an AWS Region that are engineered to be isolated from failures in other Availability Zones. They provide inexpensive, low-latency network connectivity to other Availability Zones in the same AWS Region.
Similarly, the storage is also designed to be ephemeral in nature. Although rare, failures can occur that affect the availability of instances that are in the same AZ. If you host all your instances in a single AZ that is affected by such a failure, none of your instances are available.
Deployment of a production cluster in an AZ without protection either by using disaster recovery to on-prem or Xi Leap results in data loss if there is AZ failures. The destination for data protection could be Xi Leap, another on-prem cluster, or another Nutanix Cluster in a different Availability Zone.
Nutanix has native inbuilt replication capabilities to recover from complete cluster failure. Nutanix supports both near-synchronous (NearSync) and asynchronous replication on an on-premn AHV cluster. You can set your Recovery Point Objective (RPO) to be as less as 1 minute with NearSync and 1 hour with asynchronous replication.
Deploying a single cluster in AWS is beneficial for more ephemeral workloads where you want to take advantage of performance improvements and use the same automation pipelines you use on-prem. You can use back up products compatible with AHV to target S3 as the back up destination, and, depending on the failure mode you want to recover from, you can also replicate that S3 bucket to a different Region. HYCU and Veeam are compatible with AHV.
Hybrid Deployment
To protect your Nutanix Cluster if there is an Availability Zone failure, use your existing on-prem Nutanix cluster as a disaster recovery target.
Figure. Hybrid Deployment
Click to enlarge
Multiple–Availability Zone Deployment
If you do not have an on-prem cluster available for data protection or you want to use the low-latency links between Availability Zones, you can create a second Nutanix Clusters in a different Availability Zone.
Figure. Multiple–Availability Zone Deployment
Click to enlarge
For more information on Nutanix Clusters, please visit Nutanix Clusters Guide
For release notes information, please follow Nutanix Clusters on AWS Release Notes