What’s .NEXT 2016 – Acropolis File Services (AFS)

At .NEXT 2015 Nutanix announced the Scale out File Server Tech Preview which was supported for AHV environments only. With the imminent release of AOS 4.7 the Scale out File Server has been renamed to Acropolis File Services (AFS) and will now be GA for AHV and ESXi.

AFS provides what I personally refer to as an “invisible” file server experience because it can be setup with just a few clicks in PRISM without the need to deploy operating systems.

AFS provides a highly available and distributed single namespace across 3 or more front end VMs which are automatically deployed and maintained by ADSF. The below shows a mixed cluster of 10 nodes made up of 8 x NX3060 and 2 x NX6035C nodes with the AFS UVMs spread across the cluster.

AFSoverview

Data is then stored on the underlying Acropolis Distributed Storage Fabric (ADSF) in a Container which can be configured with your desired level of resiliency e.g.: RF2 or RF3 as well as data reduction features such as Compression, Deduplication and Erasure coding.

AFS inherits all of the resiliency that ADSF natively provides and supports operational tasks such as one-click rolling upgrades of AOS and hypervisor without impacting the availability of the file services.

Functionality

Backups

Nutanix will provide AFS with native support for local recovery points on the primary storage (cluster) and allow both Async-DR (60 mins) and Sync-DR (0 RPO) to allow data to be backed up to remote cluster.

For customers who employ 3rd party backup tools, AFS can also be simply backed up as an SMB share which is a common capability amongst backup vendors such as Commvault and Netbackup.

The below shows a high level of what a 3rd party backup solution looks like with AFS.

AFSbackup2

Quotas

AFS also allows administrators to set quotas to help with capacity management especially in environments with multi-tenant or departmental deployments to avoid users monopolising capacity in the environment.

Patching/Upgrades

Acropolis File Server can be upgraded and patched separately to AOS and the underlying hypervisor. This ensures that the version of AFS is not dependant on the AOS or hypervisor versions which also makes QA easier and minimizes the chance of bugs since the AFS layer is abstracted from the AOS and hypervisor.

This is similar to how the AOS version is not dependant on a hypervisor version, ensuring maximum flexibility and stability for customers. This means as new features/improvements are added, AFS can be upgraded via PRISM without worrying about interoperability and dependancies.

Patches and upgrades are one-click, rolling, non-disruptive upgrades the same as AOS.

Scaling

As the file serving workload increases, Acropolis File Server can be scaled out by simply adding instances to balance the workload across. If the Nutanix cluster has more nodes than AFS instances, this can be done quickly and easily through prism.

If the cluster has for example 4 nodes and 4 AFS instances are already deployed, then to scale the performance of the AFS environment the UVMs vCPU/vRAM can be scaled up OR additional nodes can be added to the cluster and AFS instances scaled out.

When one or more additional AFS instances (UVM) are added, the workload is automatically balanced across all UVMs in the environment. ADSF will also automatically balance the new and existing file server data across the ADSF cluster to ensure even capacity utilization across nodes as well as consistent performance and linear scaling.

So in short, AFS provides both scale up and scale out options.

Interoperability with Storage Only nodes

Acropolis File Server is fully supported on environments using storage only nodes. As the storage nodes provide a Nutanix CVM and underlying storage to ADSF, the available capacity and performance is made available to AFS just like it is to any other VM. The only requirement is 3 or more Compute+Storage nodes in a cluster to support the minimum 3 AFS UVMs.

AFS deployment examples

Acropolis File Services can be deployed on existing Nutanix clusters which allows file data to be co-located on the same storage pool with existing data from virtual machines as well as with physical or virtual servers utilising Acropolis Block Services (ABS).

AFS_ExistingCluster

Acropolis File Services can be deployed on dedicated clusters such as storage heavy and storage only nodes for environments which do not have virtual machines, or for very large environments while be centrally managed along with other Nutanix clusters via PRISM Central.

AFS_DedicatedCluster

Multi-tenancy

AFS also allows multiple seperate instances to be deployed in the same Nutanix cluster to service different security zones, tenants or use cases. The following shows an example of a 4 node Nutanix cluster with two instances of AFS. The first has 4 AFS instances (UVMs) and the second has just 3 instances. Each instance can have different data reduction (Compression, Dedupe,EC-X) settings and be scaled independently.
AFSMultipleFileServers

Summary:

  • AFS supports multiple hypervisors and is deployed in mins from PRISM
  • Can be scaled both up and out to support more users, capacity and/or performance
  • Interoperable with all OEMs and node types including storage only
  • Supports non-disruptive one-click rolling upgrades
  • Supports multiple AFS instances on the one cluster for multi-tenancy and security zone support
  • Has native local recovery point support as well as remote backup (Sync and Async) support
  • All data is protected by the underlying ADSF
  • Supports all ADSF data reduction technologies including Compression, Dedupe and Erasure Coding.
  • Eliminates the requirement for a silo for File sharing
  • Capacity available to AFS is automatically expanded as nodes are added to the cluster.

Related .NEXT 2016 Posts

What’s .NEXT 2016 – Acropolis X-Fit

Now that Acropolis Hypervisor (AHV) has been GA for approx 18 months (with many customers using it in production well before official GA), Nutanix has had a lot of positive feedback about its ease of deployment, management, scaling and performance. However there has been a common theme that customers have wanted the ability to create rules to seperate VMs and to keep VMs together much like vSphere’s DRS functionality.

Since the GA of AHV, it has supported some basic DRS functionality including initial placement of VMs and the ability to restore a VMs data locality by migrating the VM to the node containing the most data locally.

These features work very well, so the affinity and anti-affinity rules were the main pain point. While AHV is not designed to or aimed to be feature parity with ESXi or Hyper-V, DRS style rules is one area where similar functionality makes sense whereas in many other areas, AHV is and will remain very different to legacy hypervisors.

No surprise the AHV scheduler now provides VM/host affinity and anti-affinity rule capabilities which (similar to vSphere DRS) allows for “Should” and “Must” rules to control how the cluster enforces the rules.

DRSAffinityAntiAffinity

Rule types which can be created:

  • VM-VM affinity: Keep VMs on a same host.
  • VM-VM anti-affinity: Keep VMs on separate hosts.
  • VM-Host affinity: Keep a given VM on a group of hosts.
  • VM-Host anti-affinity: Keep a given VM out of a group of hosts.
  • Affinity and Anti-affinity rules are cross-cluster policies.
  • Users can specify MUST as well as SHOULD enforcement of DRS rules

In addition to matching the capabilities of vSphere DRS, the Acropolis X-Fit functionality is also tightly integrated with both the compute and storage layers and works to proactively identify and resolve storage and compute contention by automatically moving virtual machines while ensuring data locality is optimised.

AHVScheduling1

There are many other exciting load balancing capabilities to come so stay tuned as the AHV scheduler has plenty more tricks up its sleeve.

Related .NEXT 2016 Posts

What’s .NEXT 2016 – All Flash Everywhere!

I am pleased to say Nutanix and our OEMs are now offering even more flexibility with our “Configure To Order” option (a.k.a CTO) by allowing any node type, yes ANY node type to be configured with all flash.

Why is this so cool, well Nutanix and our OEMs (Dell XC & Lenovo HX) have a wide range of models which customers can choose from and for customers who require large usable capacity of high performance storage, this is a simple way to get a pre-certified solution with all the flexibility of build your own without the risks.

AllFlashEverywhere

With this increased level of flexibility, the argument for BYO/HCL is all but moot in my opinion.

So let’s think about what this means.

The NX-8150, a 1 node per 2RU product (which I was heavily involved in the design of) will now support 24 x SSDs!

Even with the currently supported SSDs (1.92TB each), this would mean >46TB of RAW SSD capacity along with dual Broadwell CPUs and up to 768GB RAM.

Note: Higher capacity SSDs are coming soon to provide even more capacity!

Now with 24 x SSDs that is some serious power!

What’s also exciting is this doesn’t just mean higher flash capacity, it also means higher performance. This is because Nutanix persistent write buffer (OpLog) is striped across all SSDs in a node, this means the write performance can benefit from all SSDs in the node, in the case of that’s NX8150 that’s 24 drives!

Combine this with the fact Nutanix now supports any node as storage only, and this gives customers near unlimited flexibility without the risk/complexity of BYO/HCL options.

After all, the hardware is commodity, all the value is in the software so who cares what HW it runs on as long as its reliable.

Summary:

  • Configure to Order (CTO) now allows any node type to be configured with All Flash
  • All Flash nodes can also be Storage Only nodes
  • Write Performance takes advantage of all SSDs in a node
  • Nutanix Configure to Order (CTO) option makes the argument for BYO/HCL options all but moot.

Related .NEXT 2016 Posts