Nutanix - Expert Session - Metro Availability

Editor's Notes

• #4: The secret to this radical change is in the patented Nutanix Distributed File System. What you see here is a diagram representing a typical Nutanix cluster made up of nodes which are nothing but standard x86 servers w direct attached SSDs and HDDs. Unlike traditional infrastructure with a finite number of storage controllers, each additional node added to the Nutanix cluster incorporates a storage controller VM ensuring no bottlenecks in the architecture as you scale out. In doing so, you completely avoid forklift upgrades, irregularities in performance as new users are added, and reduce footprint significantly. Lastly, each Nutanix node has a built-in hypervisor of choice, whether it be vSphere, Hyper-V or KVM. This ensures the deployment is well provisioned for future enhancements such as integration with public clouds.
• #5: Convergence - 16 Data - 9 Metadata, MapReduce – 8 Cloud, VM Mobility – 6 Control Plane – 3 VDI - 2 Analytics, Security, Support – 3 (US Patent 8601473)
• #8: Purpose: Nutanix delivers the power of web-scale infrastructure to enterprise customers as a turnkey solutions Key Points: What Nutanix does is bring the simplicity, agility and rapid scale that web-scale technologies deliver but as a turnkey enterprise solution Customers can run their diverse application workloads without having to build custom applications Customers don’t have to learn how to use Cassandra, map-reduce, etc. The Nutanix solution does all that under the hood Talk about “controlled disruption” – Nutanix is building the bridge for enterprise IT to embrace web-scale IT without completely overhauling the way they do things
• #9: The notes section should have a detailed description of how the feature works. De-duplication of data on disk: An administrator can enable disk de-dupe on a container level and/or a vdisk level to reclaim capacity across the cluster. This feature will be available to new as well as existing customers after they upgrade their clusters to NOS 4.0. The feature is disabled by default and has to be explicitly enabled. Once enabled, NDFS deduplicates data in chunks of 4KB blocks (although block size for dedupe is configurable - it works optimally at 4KB). When enabled, upon a write IO request, NDFS calculates and stores SHA01 fingerprint in metadata - data is not deduped at this point. The system performs dedupe when a subsequent read occurs for that data. Curator process scans the data resident on the disks and compares SHA01 fingerprint of the 4KB blocks (which was calculated at the write time and stored along with the metadata). If the fingerprint of a new block matches another existing block, then it updates the metadata to point to the existing block and releases the newly created block. This feature de-dupes data at block level. The block size used by de-dupe is 4KB by default (its configurable). Block Awareness /RF is done at a level below dedupe. So the system has only 2 copies (or 3 copies in case of RF3) of a unique block across the cluster, which are spread over the cluster. Dedupe comes in two flavors - inline and post-process (async). With inline dedupe, there is a performance penalty since it competes with CVM resources (CPU memory) that are being used for servicing user IO at the same time. Whereas, with async/post-processing the performance penalty is minimal. How much CPU/Memory resources of the CVM controller are consumed when de-duplicating disk data? Will we have disk de-dupe inline or post process in Danube? Inline is target. Post process will definitely be there. Inline needs to be turned on for ingest. SE/User should turn it OFF after ingest else performance impact. Which workloads are helped by compression and De-dupe? Can we turn on both compression and De-dupe at the same time? Do we prevent our users to do so at the same time? We do not prevent users to do that from the UI. However, when both are enabled on a container, compression wins today in the backend and de-dupe is disabled. How does de-dupe interoperate with snapshots, backups and quick clones etc.? De-dupe works with snapshots, backups and quick clones. It is not recommended to use de-dupe with shadow clones. Compression and de-dupe? Will prism let them do it? Confirm. They use different block sizes. We don’t recommend mixing both. But the UI lets the user do it. Which workloads should be targeted towards de-dupe and compression? Josh Rodgers: Check best practice. Can a user get any indication of how much space savings he can expect if he enables disk de-dupe on a given Nutanix container before turning de-dupe ON? Dedupe may yield significant savings for workloads (VDI), but may not yield similar returns for all workloads (e.g. server virtualization). Therefore, one should keep this in mind when enabling dedupe for a container/vdisk.
• #11: The notes section should have a detailed description of how the feature works. De-duplication of data on disk: An administrator can enable disk de-dupe on a container level and/or a vdisk level to reclaim capacity across the cluster. This feature will be available to new as well as existing customers after they upgrade their clusters to NOS 4.0. The feature is disabled by default and has to be explicitly enabled. Once enabled, NDFS deduplicates data in chunks of 4KB blocks (although block size for dedupe is configurable - it works optimally at 4KB). When enabled, upon a write IO request, NDFS calculates and stores SHA01 fingerprint in metadata - data is not deduped at this point. The system performs dedupe when a subsequent read occurs for that data. Curator process scans the data resident on the disks and compares SHA01 fingerprint of the 4KB blocks (which was calculated at the write time and stored along with the metadata). If the fingerprint of a new block matches another existing block, then it updates the metadata to point to the existing block and releases the newly created block. This feature de-dupes data at block level. The block size used by de-dupe is 4KB by default (its configurable). Block Awareness /RF is done at a level below dedupe. So the system has only 2 copies (or 3 copies in case of RF3) of a unique block across the cluster, which are spread over the cluster. Dedupe comes in two flavors - inline and post-process (async). With inline dedupe, there is a performance penalty since it competes with CVM resources (CPU memory) that are being used for servicing user IO at the same time. Whereas, with async/post-processing the performance penalty is minimal. How much CPU/Memory resources of the CVM controller are consumed when de-duplicating disk data? Will we have disk de-dupe inline or post process in Danube? Inline is target. Post process will definitely be there. Inline needs to be turned on for ingest. SE/User should turn it OFF after ingest else performance impact. Which workloads are helped by compression and De-dupe? Can we turn on both compression and De-dupe at the same time? Do we prevent our users to do so at the same time? We do not prevent users to do that from the UI. However, when both are enabled on a container, compression wins today in the backend and de-dupe is disabled. How does de-dupe interoperate with snapshots, backups and quick clones etc.? De-dupe works with snapshots, backups and quick clones. It is not recommended to use de-dupe with shadow clones. Compression and de-dupe? Will prism let them do it? Confirm. They use different block sizes. We don’t recommend mixing both. But the UI lets the user do it. Which workloads should be targeted towards de-dupe and compression? Josh Rodgers: Check best practice. Can a user get any indication of how much space savings he can expect if he enables disk de-dupe on a given Nutanix container before turning de-dupe ON? Dedupe may yield significant savings for workloads (VDI), but may not yield similar returns for all workloads (e.g. server virtualization). Therefore, one should keep this in mind when enabling dedupe for a container/vdisk.
• #13: Requirement is enough bandwidth to handle the data change rate, and a round trip time of <=5ms. A redundant network link is obviously highly recommended. Keep in mind that the cluster used to replicate data does not have to have the exact same hardware.