Archives for December 2016


Why losing a disk on Nutanix is no big deal (*No Humans Required)

When Acropolis DFS detects an accumulation of errors for a particular disk (e.g., I/O errors or bad sectors) it is the Hades service running the Controller VM. The purpose of Hades is to simplify the break-fix procedures for disks and to automate several tasks that previously required manual user actions. Hades aids in fixing failing devices before the device become unrecoverable.

Nutanix has a unified component called Stargate that manages the responsibility of receiving and processing data. All read and write requests are sent to the Stargate process running on that node. Once Stargate sees delays in responses to I/O requests to a disk, it marks a disk offline. Hades then automatically removes the disk from the data path and runs smartctl checks against it. If the checks pass, Hades then automatically marks the disk online and returns it to service. If Hades’ smartctl checks fail, or if Stargate marks a disk offline three times within one hour (regardless of the smartctl check results), Hades automatically removes the disk from the cluster, and following occurs:

• The disk is marked for removal within the cluster Zeus configuration.
• This disk is unmounted.
• The Red LED of the disk is turned on to provide a visual indication of the failure.
• The cluster automatically begins to create new replicas of any data that is stored on the disk.

The failed disk is marked as a tombstoned Disk to prevent it from being used again without manual intervention.

When disk is marked offline, an alert is triggered, and is immediately removed from the storage pool by the system. Curator then identifies all extents stored on the failed disk, and Acropolis DSF is then prompted to re-replicate copies of the associated replicas to restore the desired replication factor. By the time the Nutanix administrators become aware of the disk failure via Prism, SNMP trap, or email notification, Acropolis DSF will be well on its way to healing the cluster.

Acropolis DSF data rebuild architecture provides faster rebuild times and no performance impact to workloads supported by the Nutanix cluster when compared to traditional RAID data protection schemes. RAID groups or sets typically comprise a small number of drives. When a RAID set performs a rebuild operation, typically one disk is selected to be the rebuild target. The other disks that comprise the RAID set must divert enough resources to quickly rebuild the data on the failed disk. This can lead to performance penalties for workloads served by the degraded RAID set. Acropolis DSF can distribute remote copies found on any individual disk among the remaining disks in the Nutanix cluster. Therefore Acropolis DSF replication operations can happen as background processes with no impact to cluster operations or performance. Acropolis DSF can access all disks in the cluster at any given time as a single, unified pool of storage resources. This architecture provides a very advantageous consequence. As the cluster size grows, the length of time needed to recover from a disk failure decreases as every node in the cluster participates in the replication. Since the data needed to rebuild a disk is distributed throughout the cluster, more disks are involved in the rebuild process. This increases the speed at which the affected extents are re-replicated.

It’s important to note that Nutanix also keeps the performance consistent during the rebuild operations. For hybrid systems Nutanix rebuilds cold data to cold data so large hard drives do not flood the cache of the SSD’s. For all flash systems Nutanix has quality of service implemented for backend I/O to prevent user I/O from being impacted.

In addition to a many-to-many rebuild approach to data availability, the Acropolis DFS data rebuild architecture ensures that all healthy disks are available for use all of the time. Unlike most traditional storage arrays, there’s no need for “hot-spare” or standby drives in a Nutanix cluster. Since data can be rebuilt to any of the remaining healthy disks, reserving physical resources for failures is unnecessary. Once healed, you can lose the next drive/node.


THE WORD FROM GOSTEV – 3rd Party Backups aren’t going away.

First off the Veeam newsletter is great and you should sign up. There was one comment that I found interesting was regarding the need for backups. I’ve always said that while Nutanix has a great integrated backup story sometimes it doesn’t meet all of the requirements needed by a business. Getting it out of the storage vendor’s hands is a wise decision. While Nutanix and every other vendor does rigourous QA the fact remains is that were still human and problems can occur.

Something like this has to happen once in a while so that everyone is reminded that storage snapshots are not backups – not even if you replicate them to a secondary array, like these folks did > HPE storage crash killed Australian Tax Office. You may still remember the same issue with EMC array crash disabling multiple Swedish agencies for 5 days not so long ago. These things just happen, this is why it is extremely important to make real backups by taking the production data out of the storage vendor’s “world” – whether we’re talking about classic storage architectures, or up and coming hyper-converged vendors (one of which have not been shy marketing < 5 min "backup" windows lately).

Food for thought, in the end it will be what meets the needs of your business. AKA Can you live with the pain.


AOS 5.0 – Adapt Not React – Performance

In AOS 5.0 is Adaptive replica selection is intelligent data placement for the extent store. Rather than use a random selection placement decisions are based on this capacity and queue length, these metrics are used to create a weighted random selection. The current algorithm was great for spreading all of the work load around for fast rebuilds but could cause issues with heterogeneous clusters. With mixed clusters with different tiers size, CPU strength, and running various workloads could have some nodes could be taxed more than others. It also didn’t take in to account the need for rebuilding data if the affected nodes had heavy running workloads.

This new algorithm can prevent weaker nodes from getting overburden and their hot tier from filling up and reduce the risk of having busy disks. It can also allow for lower utilized nodes to send their replicas to each other and allow busier nodes to have less replica traffic being delivered to them. If we take the example of our storage only nodes we can ensure that replicas will go to the storage only nodes while we’re not sending replicas to other computer-based nodes. This new algorithm also reduces the need to run auto balancing from a capacity perspective. By reducing the need to react we also reserve CPU cycles for workloads and save on wear and tear of the drives.
In a rudimentary static placement systems this ability to have adaptive replicas would also solve the problem of moving data that then blows up your cache.

The two less used nodes send their replication traffic to each other. The high-performing node is not impacted by incoming replica traffic.

The two less used nodes send their replication traffic to each other. The high-performing node is not impacted by incoming replica traffic.

Since we have a high performing NoSQL database collecting disk usage and performance stats for each disc we can use those stats to create a fitness value. If we can collect stats for a disc we assume the worst case and place a low number for the probability. If we can’t grab stats there is likely chance that something bad is happening to that disc. The disks once assigned a fitness value can be selected by a weighted random lottery to prevent some nodes taking all of the traffic.

As the product continues to mature were trying to avoid problems from even happening. Whether VDI, Splunk, SAP, SharePoint, SQL your workloads can get very consistent high performance on top of data locality.

The doctor says prevention is always the best medicine.


Get Ready for AOS 5.0 – Nutanix

This authentication behavior is changed in AOS 5.0. If you are using Active Directory, you must also assign roles to entities or users, especially before upgrading from a previous AOS version. If you’re not using AD, pass Go and collect $200!

For customers upgrading their clusters to AOS 5.0:

* Customers upgrading their clusters to AOS 5.0 will see a pre-upgrade check warning if user authentication is enabled for the Active Directory (AD) service and role permissions are not assigned to any user. The upgrade process will fail in this case.

Warning - no role mappings

Warning – no role mappings

* The AOS 5.0 Prism service (part of the Prism web console) will not authenticate AD users if role permissions are not configured for those users. This situation effectively locks out existing AD users that previously were allowed to access the Prism 4.x web console and other components such as the Nutanix command line (nCLI).
Add a Role mapping for your AG Groups or Users

Add a Role mapping for your AG Groups or Users

To upgrade successfully in this case and to maintain existing access, assign roles (role permissions) to entities that are allowed access to Prism before attempting to upgrade your cluster.


Integrated Single Node Backup with Nutanix

Integrated backup for remote branch offices and small to medium sized business. Single Node backup is using the NX-1155 which is quotable today . Single Node Backup is apart of AOS 5.0