Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to VMware virtual SAN 6 overview
Similar to VMware virtual SAN 6 overview (20)
More from solarisyougood
More from solarisyougood (20)
Recently uploaded
Recently uploaded (20)
VMware virtual SAN 6 overview
- 1. VMware Virtual SAN 6.0 What’s New Technical Walkthrough Raiko Mesterheide Systems Engineer
- 3. The Software-Defined Data Center Transform storage by aligning it with app demands 3 Expand virtual compute to all applications Virtualize the network for speed and efficiency Management tools give way to automation
- 4. VMware Software-Defined Storage 4 vSphere Storage Policy-Based Mgmt Virtual SAN Storage Policy-Based Mgmt SAN / NAS vSphere Virtual Volumes Virtual Datastore VMware Software-Defined Storage Virtual Datastore Bringing the Efficient Operational Model of Virtualization to Storage and Availability
- 5. Storage Policy-Based Management: 5 vSphere Storage Policy-Based Mgmt Virtual SAN Capacity Performance Availability 2 Failures to tolerate Reserve thick 10 GB Flash Read Cache 10 % • Intelligent storage placement at scale • Dynamic adjustments in real time • Automated policy enforcement App-centric Control Plane That Across Storage Tiers
- 6. Virtual SAN Virtual SAN Puts The App In Charge 6 VM-centric Service Levels for Simpler and Automated Storage Management Through App-centric Approach 1. Define storage policy 2. Apply policy at VM creation ✖ Hardware-centric, vendor- specific management ✖ Slow provisioning, rigid storage constructs (LUNs, Volumes) ✖ Data services aligned to storage container, not directly with VM needs ✖ Frequent data migrations Fast, VM-centric provisioning No need to manage LUNs, Vols. Resources and data service are automatically provisioned and maintained Easy to change without data migration Today Virtual SAN Storage Policy Capacity Availability Performance Virtual SAN DatastoreLUN LUN
- 7. VMware Virtual SAN : Hybrid 7 vSphere + Virtual SAN … • Software-defined storage built into vSphere • Runs on any standard x86 server • Pools flash-based devices into a shared datastore • Managed through per-VM storage policies • Delivers High performance through flash acceleration • 2x more IOPS with VSAN Hybrid • Up to 40K IOPS/host • Highly resilient - zero data loss in the event of hardware failures • Deeply integrated with the VMware stack Virtual SAN Hard disksSSD Hard disks SSD Hard disks SSD Virtual SAN Datastore Radically Simple Hypervisor-Converged Storage Software
- 8. VMware Virtual SAN : All-Flash 8 vSphere + Virtual SAN … • Flash-based devices used for caching as well as persistence • Cost-effective all-flash 2-tier model: o Cache is 100% write: using write-intensive, higher grade flash-based devices o Persistent storage: can leverage lower cost read- intensive flash-based devices • Very high IOPS: up to 90K(1) IOPS/Host • Consistent performance with sub- millisecond latencies Virtual SAN All-Flash Virtual SAN All-Flash Datastore NEW in 6.0 SSDs SSDs SSDs (1) All performance numbers are subject to final benchmarking results. Please refer to guidance published at GA Extremely High Performance with Predictability
- 9. Enterprise-Class Scale and Performance 9 Enhancements in 6.0 Hosts / Cluster 32 64 64 IOPS / Host 20K 40K 90K VMs / Host 100 200 200 VMs / Cluster 3200 6400 6400 Virtual SAN 5.5 Virtual SAN 6.0 Hybrid Virtual SAN 6.0 All-Flash Note: All performance numbers are subject to final benchmarking results. Please refer to guidance published at GA
- 10. Virtual SAN 6.0 Now Ready For Business-Critical Apps 10 VDI DR Test/Dev Virtual Infrastructure Best storage for VMs Optimized for Virtual Infrastructure Enterprise-class Ready for business critical apps Business Critical Apps
- 12. Hardware Requirements 12 Any Server on the VMware Compatibility Guide All flash-based devices, and storage controllers MUST be listed on the VMware Compatibility Guide for VSAN 1Gb/10Gb NIC SAS/SATA Controllers (RAID Controllers must work in “pass-through” or RAID0” mode) SAS/SATA//PCIe SSD SAS/NL-SAS/SATA HDD At least 1 of each (Except All-Flash) 4GB to 8GB USB, SD Cards
- 13. Flash Based Devices In Virtual SAN hybrid ALL read and write operations always go directly to the Flash tier. Flash based devices serve two purposes in Virtual SAN hybrid architecture 1. Non-volatile Write Buffer (30%) – Writes are acknowledged when they enter prepare stage on the flash-based devices. – Reduces latency for writes 2. Read Cache (70%) – Cache hits reduces read latency – Cache miss – retrieve data from the magnetic devices Choice of hardware is the #1 performance differentiator between Virtual SAN configurations. 13
- 14. Flash Based Devices In Virtual SAN all-flash read and write operations always go directly to the Flash devices. Flash based devices serve two purposes in Virtual SAN All Flash: 1. Cache Tier (write buffer) – High endurance flash devices. – Listed on VCG 2. Capacity Tier – Low endurance flash devices – Listed on VCG Choice of hardware is the #1 performance differentiator between Virtual SAN configurations. 14
- 15. Network • 1Gb / 10Gb supported for hybrid architecture – 10Gb shared with NetIOC for QoS will support most environments – If 1GB then recommend dedicated links for Virtual SAN • 10Gb only supported for all-flash architecture – 10Gb shared with NIOC for QoS will support most environment • Jumbo Frames will provide nominal performance increase – Enable for greenfield deployments – Enable in large deployments to reduce CPU overhead • Virtual SAN supports both VSS & VDS – NetIOC requires VDS • Network bandwidth performance has more impact on host evacuation, rebuild times than on workload performance 15
- 16. VMware Virtual SAN High Density Direct Attached Storage 2015 & 2016 – Manage disks in enclosures – helps enable blade environment – Flash acceleration provided on the server or in the subsystem – Data services delivered via the VSAN Data Services and platform capabilities – Direct attached and disks (flash devices, and magnetic devices) are Supports combination of direct attached disks and high density attached disks (SSDs and HDDs) per disk group. – Supported HDDASs will be tightly controlled by the HCL (exact list TBD). • Applies to HDDASs and controllers • Also supported on Virtual SAN 5.5 HDDAS Blade Servers HDDSSD vSphere + Virtual SAN
- 17. VMware Virtual SAN – VCG and Ready Nodes 17 1 2 1 2 www.vmware.com/go/virtualsan-hcl Virtual SAN Hardware Quick Reference Guide • 5 Ready Node profile guidelines • Sizing assumptions • Design considerations Virtual SAN Ready Nodes • List components and quantity that make up each Ready Node • Info on how to quote/order the Ready Node 3 3 Always use certified components! • Drivers and firmware • Supportability • Increase customer satisfaction • Reduce rework and time-to- market
- 18. VMware Virtual SAN: One Destination SDDC & SDS, Three Paths 18 Component Based …using the VMware Virtual SAN Compatibility Guide (VCG) (1) Choose individual components … SSD or PCIe SAS/NL-SAS/ SATA HDDs Any Server on vSphere Hardware Compatibility List HBA/RAID Controller Virtual SAN Ready Node 40+ OEM validated server configurations ready for Virtual SAN deployment (2) Note: 1) Components must be chosen from Virtual SAN HCL, using any other components is unsupported – see Virtual SAN VMware Compatibility Guide Page 2) VMware continues to update/add list of the available Ready Nodes, please refer to Virtual SAN VMware Compatibility Guide Page for latest list 3) Product availability varies by countries. Please contact your local VMware partners for details, pricing and availability – click here Maximum Flexibility Maximum Ease of Use VMware EVO:RAIL A Hyper-Converged Infrastructure Appliance (HCIA) for the SDDC Each EVO:RAIL HCIA is pre-built on a qualified and optimized 2U/4 Node server platform. Sold via a single SKU by VMware Qualified EVO:RAIL Partners (QEPs) (3) Software + Hardware Hyper-Converged Infrastructure
- 19. There are 5 VSAN Ready Node Profiles – Server Workload Virtual SAN All Flash - Server Server Low Profile Server Medium Profile Server High Profile • Up to 30VMs • Up to 4K IOPs • 5TB raw capacity • Up to 60VMs • Up to 24K IOPs • 8TB raw capacity • Up to 120VMs • Up to 40K IOPs • 14.4TB raw capacity Virtual SAN Hybrid - Server Server Medium Profile Server High Profile • Up to 60VMs • Up to 60K IOPs • 8TB raw capacity • Capacity 8x1TB SSD • Caching 2x200GB SSD • Up to 120VMs • Up to 80K IOPs • 12TB raw capacity • Capacity 12x1TB SSD • Caching 2x400GB SSD For complete details on the sizing assumptions and design considerations of the Ready Node profiles, please refer to the “Virtual SAN Hardware Quick Reference Guide” on the Virtual SAN VMware Compatibility Guide Page
- 20. There are 4 VSAN Ready Node Profiles – VDI Workload Virtual SAN All Flash - VDI VDI Linked Clones Profile VDI Full Clones Profile • Up to 100 desktops • Up to 10K IOPs • 1.2TB raw capacity • Up to 100 desktops • Up to 10K IOPs • 10.8TB raw capacity For complete details on the sizing assumptions and design considerations of the Ready Node profiles, please refer to the “Virtual SAN Hardware Quick Reference Guide” on the Virtual SAN VMware Compatibility Guide Page Virtual SAN Hybrid - VDI VDI Linked Clones Profile VDI Full Clones Profile • Up to 200 desktops • 1.6TB raw capacity • Capacity 4x400GB SSD • Caching 1x400GB SSD • Up to 200 desktops • 9.6TB raw capacity • Capacity 12x800GB SSD • Caching 2x400GB SSD VMWARE FIELD & PARTNER USE ONLY - CONFIDENTIAL
- 21. 2x VMs per host 62TB Virtual Disks Snapshots and Clone • Greater capacity allocations per VMDK • VMDK >2TB are supported • Larger supported capacity of snapshots and clones per VMs • 32 per Virtual Machine • Larger Consolidation Ratios • Due to increase of supported components per hosts • 9000 Components per Host Virtual SAN Performance and Scale Improvements Host Scalability • Cluster support raised to match vSphere • Up to 64 nodes per cluster in vSphere • VSAN can scale up to 64 nodes. 21
- 22. Disk Format VSAN 5.5 to 6.0 Disk Serviceability Functions • In-Place modular rolling upgrade • Seamless In-place Upgrade • Seamless Upgrade Rollback Supported • Upgrade performed from RVC CLI • PowerCLI integration for automation and management • Ability to manage flash- based and magnetic devices. • Storage consumption models for policy definition • Default Storage Policies • Resync Status dashboard in UI • VM capacity consumption per VMDK • Disk/Disk group evacuation • New On-Disk Format • New delta-disk type vsanSparse • Performance Based snapshots and clones Virtual SAN 6.0 New Features VSAN Platform • New Caching Architecture for all-flash VSAN • Virtual SAN Health Services • Proactive Rebalance • Fault domains support • High Density Storage Systems with Direct Attached Storage • File Services via 3rd party • Limited support hardware encryption and checksum 22 VMFS-L VSAN FS
- 23. Virtual SAN 6.0 Enables Both Hybrid or All-Flash Architectures 23 Hybrid All-Flash 30K IOPS/Host 90K IOPS/Host predictable sub-millisecond latency New! Caching SSD, PCIe, Ultra DIMM etc. Read cache / Write buffer SSD, PCIe, Ultra DIMM etc. Write-only buffer Magnetic Disks Flash Devices Data Persistence
- 24. Virtual SAN Flash Caching Architectures disk group disk group capacity capacity read cache read cache 10% of projected used capacity High Endurance devices - 2 to 3 TBW per day Cache Tier Capacity Tier Size for remainder of capacity Magnetic devices Price on best $/GB disk group disk group capacity capacity write buffer write bufferCache Tier Capacity Tier Size for remainder of capacity Lower required endurance - 0.2 TBW per day sufficient Price on best $/GB 10% of projected used capacity High Endurance devices - 2 to 3 TBW per day Hybrid All-Flash
- 25. All-Flash Cache Tier Sizing Cache tier should have 10% of the anticipated consumed storage capacity Cache is entirely write-buffer in all-flash architecture Cache devices should be high write endurance models: Choose 2+ TBW/day or 3650+/5 year Total cache capacity percentage should be based on use case requirements. – For general recommendation visit the VMware Compatibility Guide. – For write-intensive workloads a higher amount should be configured. – Increase cache size if expecting heavy use of snapshots Measurement Requirements Values Projected VM space usage 20GB Projected number of VMs 1000 Total projected space consumption per VM 20GB x 1000 = 20,000 GB = 20 TB Target flash cache capacity percentage 10% Total flash cache capacity required 20TB x .10 = 2 TB
- 26. VMware Virtual SAN 6.0 Usability Improvements
- 27. • vCenter can manage multiple vsanDatastores with different sets of requirements. • Each vsanDatastore can have a different default profile assigned. Default Storage Policies vSphere + Virtual SAN Hard disksHard disks SSD SSD Hard disksSSD … vSphere + Virtual SAN Hard disksHard disks SSD SSD Hard disksSSD … vCenter Server VSAN default policy BCA default policy
- 28. Virtual Machine Usability Improvements • Virtual SAN 6.0 adds functionality to visualize Virtual SAN datastore resource utilization when a VM Storage Policy is created or edited. • Virtual SAN’s free disk space is raw capacity. – With replication, actual usable space is lesser. • New UI shows real usage on – Flash Devices – Magnetic Disks – Displayed in the vSphere Web Client and RVC:
- 29. Virtual Machine >2TB VMDKs • In VSAN 5.5, the max size of a VMDK was limited to 2TB. – Max size of a VSAN component is 255GB. – Max number of stripes per object was 12. • In VSAN 6.0 the limit has been increased to allow VMDK up to 62TB. – Objects are still striped at 255GB. • 62TB limit is the same as VMFS and NFS so VMDK can be
- 30. Resynchronization Status • Virtual SAN might need to move data around in the background: change policy, host failure, long term/permanent component loss, user triggered reconfig, maintenance mode, etc. • UI Resync Dashboard shows the VMs and objects that are resyncing and remaining bytes to sync.
- 31. Proactive Rebalance • Proactive rebalance is a new feature introduced in 6.0 to address two typical use cases: – Adding a new node to an existing vsan cluster or bringing a node out of decommission state. – Leverage the new nodes even if the fullness of existing disks are below 80%. – Rebalance would be more effective if it can be started earlier than disk almost full. • Performed through RVC – vsan.proactive_rebalance --start ~/computers/cluster
- 32. VMware Virtual SAN Failure Scenarios
- 33. Fault Domains Rack A Fault Domain A Fault Domain B Fault Domain C Virtual SAN Cluster Rack CRack B vmdk witness raid-1 vmdk raid-1 vmdk witnessvmdk
- 34. In Virtual SAN 5.5 assumed different hosts have independent failure behavior. For FTT=n, VSAN creates (n+1) replicas on (n+1) unique hosts Failure protection example in Virtual SAN 5.5 Four racks with two hosts each FTT=2 to protect against one rack failure requires 3 replicas Fault Domains vsanDatastore R1 R2 R3 VSAN network VSAN network VSAN network VSAN network esx-1 esx-2 esx-3 esx-4 esx-5 esx-6 esx-7 esx-8 Virtual SAN Cluster Rack A Rack B Rack C Rack D
- 35. An example of Virtual SAN 6.0 utilizing new fault domain feature with four racks with two hosts each Four defined fault domains FD1 = esx-1, esx-2 FD2 = esx-3, esx-4 FTT=2 to protect against one rack failure requires only 2 replicas Fault Domains FD3 = esx-5, esx-6 FD4 = esx-7, esx-8 Rack A Rack B Rack C Rack D W vsanDatastore R1 R2 VSAN network VSAN network VSAN network VSAN network esx-1 esx-2 esx-3 esx-4 esx-5 esx-6 esx-7 esx-8 Virtual SAN Cluster W
- 36. vSphere admins can configure fault domains and their definitions from: • vSphere Web Client • ESXCLI Fault Domain Configuration
- 37. Number of failures to tolerate (FTT) are applied based on fault domains and no longer on hosts. – Example: FTT=n, (2n + 1) fault domains are required – Provisioning failures can occur due to misconfigured hosts or unsatisfiable number of fault domains. Fault domains are configurable though host profiles – Host profile configurations are persistent across reboots – Once reconfiguration begins objects will be out of compliance for a period of time – Once the objects are synchronize they will be back in compliance Failure Domain
- 38. New RVC commands provide visibility and management capabilities to the failure domains configuration: • vsan.fault_domains /Datacenter/Computer/VSAN • vsan.fault_domains --help Fault Domains
- 39. Virtual SAN Objects, Components, Witness • New Quorum computation: – Each fault domain must have equal number of votes during quorum computation. – In VSAN 5.5, each component has only one vote and VSAN may add additional witnesses to equalize votes. – In VSAN 6.0, each component initially has only one vote and VSAN may increase number of votes for certain components to equalize votes. 56
- 40. VMware Virtual SAN 6.0 Interoperability
- 41. File Services with NexentaConnect • NexentaConnect complements VMware Virtual SAN simplified operating and storage consumption models by: – Adding file services (SMB, NFS) on top of Virtual SAN – Provide similar ease of management capabilities – Leveraging Storage Policy Based Management (SPBM) and underlying storage technologies • NexentaConnect is used for storing files while VSAN is for virtual machine storage • Offers vSphere Administrators flexibility and benefits such as – Abstracted pool of files services – High performance NFS and SMB network shares – Live monitoring capabilities – Disaster Recovery planning capabilities • This is a 3rd party solution and not developed by VMware vSphere + Virtual SAN Hard disksHard disks SSD SSD Hard disks SSD … Virtual SAN Shared Datastore
- 42. vRealize Automation • vRealize Automation Advanced complements VMware Virtual SAN simplified operating and storage consumption models by: – Delivering a dynamic storage service level allocation on top of Virtual SAN. – Leveraging Storage Policy Based Management (SPBM) and underlying Virtual SAN storage technologies.
- 43. vRealize Operations • Day to Day Operations Management – Enable Alerting & Notification for troubleshooting VSAN related failures and performance issues – Provide a single pane of glass for simplified and automated operations management for VSAN by means of exploratory dashboards, heat maps etc • Analytics and Future Capacity Planning – Analyze Health, Risk and Efficiency of Virtual SAN cluster around performance, capacity and availability – Enable use of advanced analytics, reporting and planning capabilities for physical infrastructure supporting Virtual SAN
- 44. PowerCLI • PowerCLI 6.0 delivers a set of Virtual SAN related cmdlets (no longer a fling) for managing Virtual SAN. – Some of the existing cmdlets were altered to work with Virtual SAN. • Here is some of the new cmdlets: – Export-SpbmStoragePolicy – Get-SpbmCapability – Get-SpbmCompatibleStorage – Get-SpbmEntityConfiguration – Get-SpbmStoragePolicy – Get-VSANDisk – Get-VsanDiskGroup – Import-SpbmStoragePolicy – New-SpbmRule – New-SpbmRuleSet – New-SpbmStoragePolicy – New-VsanDisk – New-VsanDiskGroup – Remove-SpbmStoragePolicy – Remove-VsanDisk – Remove-VsanDiskGroup – Set-SpbmEntityConfiguration – Set-SpbmStoragePolicy
- 45. Disaster Recovery For The Software-Defined Data Center • VM-centric, storage-independent replication simplifies protection • Flexible storage topologies (External to Virtual SAN or vCloud Air) vSphere Replication Production Site Recovery Site vSphere Site Recovery Manager vSphere Replication VDPA backup replication VDPA Backup datastore Virtual SAN Virtual SAN External Storage Backup datastore vSphere vSphere Replication • Storage-efficient dedupe reduces storage investments • WAN-efficient backup data replication enables basic DR vSphere Data Protection Advanced • Server side economics lower storage costs • Hyper-convergence on x86 platform reduces DR footprint Virtual SAN • Centralized recovery plans enables DR scale for thousands of VMs • DR workflow automation reduces OpEx on DR management Site Recovery Manager • DR as a Service to vCloud Air shifts DR investments from CapEx to OpEx • Fully delivered and supported by VMware vCloud Air Disaster Recovery Site Recovery Manager
- 46. VMware Virtual SAN Monitoring & Troubleshooting
- 47. Ruby vSphere Console (RVC) • New RVC commands for management and configurations purposes have been added • Here is the list of the new commands: – vsan.v2_ondisk_upgrade – vsan.proactive_rebalance – vsan.purge_inaccessible_vswp_objects – vsan.enable_capacity_flash – vsan.host_claim_disks_differently – vsan.host_wipe_non_vsan_disk – vsan.host_evacuate_data – vsan.host_exit_evacuation – vsan.scrubber_info – basic.screenlog
- 48. Virtual SAN Health Virtual SAN Health Services: is designed deliver troubleshooting and health reports to vSphere Administrators about Virtual SAN 6.0 subsystems and their dependencies such as: – Cluster Health – Network Health – Data Health – Limits Health – Physical Disk Health
- 49. 66 THANK YOU
Editor's Notes
- SDDC is not just a VMware vision -- an approach embraced by IT teams around the world SDDC involves decoupling software from hardware to improve agility, flexibility and efficiency Abstracting, Pooling and Automating resources to make them more easily consumed Four key pillars of SDDC… Expanding compute to all applications… Virtualize the network to increase speed and efficiency… Replacing manual approaches to IT management with automation… Storage has long been a critical piece of every datacenter Not only does it allow you to store data, but we are transitioning into a data-driven era Capacity and speed are important The industry is changing, new competition, new technologies
- Customer ask us the question sometimes… “Why is VMware entering the storage market?” The answer is simple, with the hypervisor, we have an opportunity to change how we address the storage challenges The hypervisor is uniquely positioned in the IT stack, and has the unique ability to make optimal decisions around matching the demands of virtualized applications with the supply of underlying physical infrastructure. The hypervisor allows to transform storage, bringing the same operational efficiency that server virtualization brought to compute We can accomplish this by: Virtualizing storage resources into logical, VM-centric pools of capacity that are flexible consumed And by automating the delivery of storage service levels to applications through a standardized approach that is common across all tiers of storage
- Customer ask us the question sometimes… “Why is VMware entering the storage market?” The answer is simple, with the hypervisor, we have an opportunity to change how we address the storage challenges The hypervisor is uniquely positioned in the IT stack, and has the unique ability to make optimal decisions around matching the demands of virtualized applications with the supply of underlying physical infrastructure. The hypervisor allows to transform storage, bringing the same operational efficiency that server virtualization brought to compute We can accomplish this by: Virtualizing storage resources into logical, VM-centric pools of capacity that are flexible consumed And by automating the delivery of storage service levels to applications through a standardized approach that is common across all tiers of storage
- As we have mentioned, the policy-driven framework makes it easy to provision and manage storage It enables each VM or application to specify the amount of storage it needs Then, the software ensures that policies are met by matching against underlying storage resources Virtual SAN monitors on an ongoing basis through SLAs Let’s look at it in more detail: Today Difficult to forecast right Difficult to change policies once allocated Difficult to change apps to new policies Virtual SAN No overprovisioning (better safe than sorry!) Automates provisioning and management Eliminates the complexity T: Let’s examine in more detail how storage policy-based management works.
- Virtual SAN is a persistent storage technology embedded in the vSphere hypervisor The product: Abstracts and pools server-side disks and flash => shared datastore CLICK Decouples software from hardware // Converts physical to virtual Embedded in ESXi kernel to create high performance storage tier running on x86 servers Leverages flash architecture to create read cache / write buffer to accelerate performance Policy-based management framework automates routine tasks Creates a resilient, scalable storage tier that is easy to use Gives users the flexibility to configure the storage they need T: Virtual SAN is a true Software-Defined Storage product that runs on standard x86 servers, and has really created quite a response from the market…
- Virtual SAN All-Flash architecture - Virtual SAN 6.0 allows the ability to create an all-flash architecture in which SSDs are used for caching as well as data persistence. In this architecture, the flash cache is used completely for write caching. This all-flash architecture allows tiering of SSDs: a write-intensive, high endurance caching tier for the writes and a read-intensive, cost-effective SSD tier for data persistence, thereby reducing the cost of the all-flash architecture. Virtual SAN All-Flash provides consistent, predictable performance with up to 90K IOPS/Host and sub-millisecond response times, making it ideal for tier-1 workloads as well.
- Virtual SAN 6.0 doubles the scalability of Virtual SAN 5.5 by scaling up to 64 nodes per cluster for both hybrid and all-flash configurations. Furthermore, Virtual SAN 6.0 improves VM densities by more than 50% with the ability to manage up to 150 VMs/host on a hybrid configuration and 200 VMs/host in an all-flash configuration. In addition to providing enterprise-level scale improvements, VSAN 6.0 provides extremely high and consistent performance. In hybrid architecture, VSAN can provide up to 40K IOPS/host, reflecting a 2x improvement over the first release of VSAN. All-Flash architecture is specially designed to provide high performance with predictably low latencies. It can provide up to 90K IOPS/host.
- With the major enhancements of this release, Virtual SAN provides both enterprise-class scale and performance as well as new capabilities that broaden the applicability of the now proven Virtual SAN technology to business critical environments. VSAN is built from the ground up for the vSphere virtual infrastructure. With its simplicity, performance, scalability and cost-savings, VSAN is suited to be the storage for all your VMs. VSAN is now enterprise-ready and customers can use it for a broad range of use cases, including business-critical and tier-1 production applications.
- SSD capacity should be at least ~10% of used HDD storage capacity* Choice of SSD hardware is the #1 performance differentiator between VSAN configurations! BLOG: Virtual SAN Hardware Guidance Part 1 – Solid State Drives BLOG: Virtual SAN Hardware Guidance Part 2 – Controllers
- SSD capacity should be at least ~10% of used HDD storage capacity* Choice of SSD hardware is the #1 performance differentiator between VSAN configurations!
- There are three options to help you deploy VSAN depending on whether you’re looking for maximum flexibility or time to market with prescriptive configurations Build Your Own using certified VSAN components provides you the highest flexibility There are hundreds of certified components for Virtual SAN, such as the SSD, HDD, and controllers. List is available on VMware Virtual SAN Compatibility Guide (www.vmware.com/go/virtualsan-hcl) Just pick any of the server platform certified on vSphere Hardware Compatibility List (HCL) 2) You can get to market faster and create productized solution using the Virtual SAN Ready Node VSAN Ready Node is a validated server configuration that vmware and the server OEM jointly recommend for Virtual SAN deployment Each Ready Node has specific components and quantity for different use case/workload The Ready Node can be ordered as-is or further customized for different customer need VSAN Ready Nodes provide flexibility with prescriptive configurations 3) VMware is proud to also introduce EVO:RAIL EVO:RAIL combines VMware compute, networking, and storage resources into a hyper-converged infrastructure appliance to create a simple, easy to deploy, all-in-one solution offered by our partners EVO:RAIL provides maximum ease of use and out of box experience in 15min.
- The Virtual SAN Ready Nodes are categorized into nine different profiles for different objectives, design & sizing considerations. 5 are for VSAN Hybrid & 4 are for VSAN All Flash There are 3 server workload profiles and 2 VDI workload profiles for Hybrid & 4 server workloads for All Flash Server profiles - Low, Medium, and High profiles: You can see that the # of VMs supported, IOPs, memory, disk size are increasing as you go up the profile VDI profiles – Linked Clones and Full Clones profiles: Capacity and SSD size are higher for Full Clones All Flash Server profiles - Medium, and High profiles: You can see that the # of VMs supported, IOPs, memory, disk size are increasing as you go up the profile All Flash VDI profiles – Linked Clones and Full Clones profiles: Capacity and SSD size are higher for Full Clones All Flash Caching vs. Capacity SSDs class specific specifications are available on the VSAN HCL. For more details on the design and sizing assumptions used for each of the profiles, please see "Virtual SAN Hardware Quick Reference Guide“ on www.vmware.com/go/virtualsan-hcl
- The Virtual SAN Ready Nodes are categorized into nine different profiles for different objectives, design & sizing considerations. 5 are for VSAN Hybrid & 4 are for VSAN All Flash There are 3 server workload profiles and 2 VDI workload profiles for Hybrid & 4 server workloads for All Flash Server profiles - Low, Medium, and High profiles: You can see that the # of VMs supported, IOPs, memory, disk size are increasing as you go up the profile VDI profiles – Linked Clones and Full Clones profiles: Capacity and SSD size are higher for Full Clones All Flash Server profiles - Medium, and High profiles: You can see that the # of VMs supported, IOPs, memory, disk size are increasing as you go up the profile All Flash VDI profiles – Linked Clones and Full Clones profiles: Capacity and SSD size are higher for Full Clones All Flash Caching vs. Capacity SSDs class specific specifications are available on the VSAN HCL. For more details on the design and sizing assumptions used for each of the profiles, please see "Virtual SAN Hardware Quick Reference Guide“ on www.vmware.com/go/virtualsan-hcl
- VMware is recommending Virtual SAN for the following use cases Although the technology is general purpose, VMware is recommending these use cases for initial deployment The technology is proven and scalable and could handle any enterprise workload However, the above are recommended as VMware is being conservative and Virtual SAN is the company’s first major storage product As time passes, you will see Virtual SAN being actively used for Tier I workloads that are mission critical VDI Handle peak performance requirements (boot, login, read/write storms) Granularly scale from POC to production without huge upfront investments Support high VDI density Tier 2 / Tier 3 / Staging / Test/Dev Definition: RPOs of 15 minutes or more Production ready 2 snapshots per day SLAs for replication Rapid storage provisioning and complete automation Ideal price/performance Enables Cloud Architect to easily provision storage DR Target Integrated with vSphere Replication and VMware SRM Reduces cost of storage Minimizes data center footprint T: For these use cases, VMware is making it easy for potential customers to get started through its simple packaging and promotional offers.
- VMware is recommending Virtual SAN for the following use cases Although the technology is general purpose, VMware is recommending these use cases for initial deployment The technology is proven and scalable and could handle any enterprise workload However, the above are recommended as VMware is being conservative and Virtual SAN is the company’s first major storage product As time passes, you will see Virtual SAN being actively used for Tier I workloads that are mission critical VDI Handle peak performance requirements (boot, login, read/write storms) Granularly scale from POC to production without huge upfront investments Support high VDI density Tier 2 / Tier 3 / Staging / Test/Dev Definition: RPOs of 15 minutes or more Production ready 2 snapshots per day SLAs for replication Rapid storage provisioning and complete automation Ideal price/performance Enables Cloud Architect to easily provision storage DR Target Integrated with vSphere Replication and VMware SRM Reduces cost of storage Minimizes data center footprint T: For these use cases, VMware is making it easy for potential customers to get started through its simple packaging and promotional offers.
- Cache Tier Sizing The general recommendation for sizing Virtual SAN's flash capacity is to have 10% of the anticipated consumed storage capacity before the Number of Failures To Tolerate is considered. For the cache tier devices, high endurance models are recommended, where generally the higher the terabyte write limits guaranteed by the vendor the better. The cache tier provides write buffering to protect the capacity tier, and therefore is heavily used for writes, requiring a resilient set of drives. Devices are measured in TBW. This is analogous to other industry measurements such as Drive Writes Per Day (DWPD). Given a 5 year average lifespan, TBW can be derived from DWPD (DWPDxSizex365x5). This 5 year rating usually ranges from 0.2TBW through 3 TBW daily or 365 TBW through 5475 for a 5 year window. VMware recommends devices for the cache tier that offer at least 2 or more daily terabyte writes for a 5 year rating of 3650 or higher. For clusters with write-oriented workload characteristics even higher TBW may be required. Note that a small device that supports a high daily write per day rating may be equal in the long term to a large device with a lower drive write per day rating. E.g. a 100GB device with 10 DWPD is interchangeable from an endurance perspective with a 1TB device with 1 DWPD. This is why a 5 year TBW rating is a better calculation for sizing than strictly using DWPD or Program/Erase cycles. Device size can be calculated by dividing the total cache required for the cluster by the number of disk groups. There may be up to 5 disk groups per host. E.g.: -2 TB cache required -10 hosts = 200 GB cache required per host -1x200 GB cache device = 2x100 GB cache device = 4x500 MB cache device. -For every cache device and disk group you will need at least 1 capacity device. Generally, given the same TBW rating, fewer but higher capacity devices will yield better longevity as each individual write buffer location will have greater capacity to hold component writes without needing to destage writes to disk. On the other hand more cache devices and disk groups will offer easier scaling and device replacement. Business requirements should drive the architecture decision between fewer but larger cache devices vs more but smaller cache devices. Capacity Tier Sizing This layer serves predominantly as a read layer, therefore the predominant factor for sizing is the cost per GB. It is sized to the total required (not estimated used) space. Cache devices can be lower endurance higher capacity models: Choose .2 TBW/day or 365+/5 year Number of devices is dictated by the total capacity of the Virtual SAN divided by the number of disk groups.
- Cache Tier Sizing The general recommendation for sizing Virtual SAN's flash capacity is to have 10% of the anticipated consumed storage capacity before the Number of Failures To Tolerate is considered. For the cache tier devices, high endurance models are recommended, where generally the higher the terabyte write limits guaranteed by the vendor the better. The cache tier provides write buffering to protect the capacity tier, and therefore is heavily used for writes, requiring a resilient set of drives. Devices are measured in TBW. This is analogous to other industry measurements such as Drive Writes Per Day (DWPD). Given a 5 year average lifespan, TBW can be derived from DWPD (DWPDxSizex365x5). This 5 year rating usually ranges from 0.2TBW through 3 TBW daily or 365 TBW through 5475 for a 5 year window. VMware recommends devices for the cache tier that offer at least 2 or more daily terabyte writes for a 5 year rating of 3650 or higher. For clusters with write-oriented workload characteristics even higher TBW may be required. Note that a small device that supports a high daily write per day rating may be equal in the long term to a large device with a lower drive write per day rating. E.g. a 100GB device with 10 DWPD is interchangeable from an endurance perspective with a 1TB device with 1 DWPD. This is why a 5 year TBW rating is a better calculation for sizing than strictly using DWPD or Program/Erase cycles. Device size can be calculated by dividing the total cache required for the cluster by the number of disk groups. There may be up to 5 disk groups per host. E.g.: -2 TB cache required -10 hosts = 200 GB cache required per host -1x200 GB cache device = 2x100 GB cache device = 4x500 MB cache device. -For every cache device and disk group you will need at least 1 capacity device. Generally, given the same TBW rating, fewer but higher capacity devices will yield better longevity as each individual write buffer location will have greater capacity to hold component writes without needing to destage writes to disk. On the other hand more cache devices and disk groups will offer easier scaling and device replacement. Business requirements should drive the architecture decision between fewer but larger cache devices vs more but smaller cache devices. Capacity Tier Sizing This layer serves predominantly as a read layer, therefore the predominant factor for sizing is the cost per GB. It is sized to the total required (not estimated used) space. Cache devices can be lower endurance higher capacity models: Choose .2 TBW/day or 365+/5 year Number of devices is dictated by the total capacity of the Virtual SAN divided by the number of disk groups.
- There is is not a customer intractable feature. The vSphere Web Client or CLI doesn’t show the disk group format type.
- There is is not a customer intractable feature. The vSphere Web Client or CLI doesn’t show the disk group format type.
- There is is not a customer intractable feature. The vSphere Web Client or CLI doesn’t show the disk group format type.
- All disks in a vsanSparse disk-chain need to be vsanSparse (except base disk). Cannot create linked clones of a VM with vsanSparse snapshots on a non-vsan datastore. If a VM has existing redo log based snapshots, it will continue to get redo log based snapshots until the user consolidates and deletes all current snapshots.
- Disk Format Conversion (DFC) conversion phase is where VMFS-L disk format will be replaced by VirstoFS on all participating magnetic devices. What happens during the disk reformat phase? All the nodes should have been completed its software upgrade (ESXi6.0) (VSAN1.0 --> VSAN2.0 cluster) Operates on one node and one diskgroup at a time. Node --> DiskGroup --> Data Evacuation --> reformat MDs with VirstoFs --> DiskGroup comes Online While DFC is in progress, object switching takes place (v1 -> v2). The above flow repeats for renaming Diskgroups in the node and then the process jumps to the next node. No vsan node with ESXi55x software is allowed to join the vSAN2.0 cluster after starting DFC.
- Disk Format Conversion (DFC) conversion phase is where VMFS-L disk format will be replaced by VirstoFS on all participating magnetic devices. What happens during the disk reformat phase? All the nodes should have been completed its software upgrade (ESXi6.0) (VSAN1.0 --> VSAN2.0 cluster) Operates on one node and one diskgroup at a time. Node --> DiskGroup --> Data Evacuation --> reformat MDs with VirstoFs --> DiskGroup comes Online While DFC is in progress, object switching takes place (v1 -> v2). The above flow repeats for renaming Diskgroups in the node and then the process jumps to the next node. No vsan node with ESXi55x software is allowed to join the vSAN2.0 cluster after starting DFC.
- Once all the pre-checks are done CMMDS will not allow 5.5x hosts to join the cluster
- Once all the pre-checks are done CMMDS will not allow 5.5x hosts to join the cluster
- Once all the pre-checks are done CMMDS will not allow 5.5x hosts to join the cluster
- Software-Defined Storage Flexible resource management Common control across heterogeneous resources Granular VM-centric SLA management
- Light LED on failures When a disk hits a permanent error, it can be challenging to find where that disk sits in the chassis to find and replace it. When SSD or MD encounters a permanent error, VSAN automatically turns the disk LED on. Turn disk LED on/off User might need to locate a disk so VSAN supports manually turning a SSD or MD LED on/off. Marking a disk as SSD Some SSDs might not be recognized as SSDs by ESX. Disks can be tagged/untagged as SSDs Marking a disk as local Some SSDs/MDs might not be recognized by ESX as local disks. Disks can be tagged/untagged as local disks.
- Software-Defined Storage Flexible resource management Common control across heterogeneous resources Granular VM-centric SLA management
- VSAN Default Profile is automatically created in SPBM when VSAN is enabled on a cluster. FTT=1, stripes=1, cache reservation=0 object space reservation=0
- The VSAN 1.0 factory defaults (configured via esxcli) are unused (except if one by-passes VC).
- Objects are still striped at 255GB. 62TB object = ~500 components (HFT=1). In a realistic customer scenario, we expect no more than 5X over commitment, i.e. at least 12.5TB of data is written to a 62TB disk. Used as guideline to size the system (not enforced). ~6 VMDKs with 160TB of raw storage. ~14 VMDKs with 360TB of raw storage. 62TB limit is the same as VMFS and NFS so VMDK can be cloned/SVM’d across VSAN and other datastores.
- Misconfigurations detected: Network Stats- MTU, Multicast, configuration over L3, Physical Disks – Are all disks used be VSAN, Are any disk not use use due to VMFS-L Snapshots Objects – current status, current limits, health,
- Misconfigurations detected: Network Stats- MTU, Multicast, configuration over L3, Physical Disks – Are all disks used be VSAN, Are any disk not use use due to VMFS-L Snapshots Objects – current status, current limits, health,
- Misconfigurations detected: Network Stats- MTU, Multicast, configuration over L3, Physical Disks – Are all disks used be VSAN, Are any disk not use use due to VMFS-L Snapshots Objects – current status, current limits, health,