VMware VSAN 与 WS16 S2D竞争分析报告.pptx

VMware VSAN 与 WS16 S2D竞争分析报告;Goals P0: Technical performance comparison – cached workload performance ($/IOPs) on hybrid configurations P1: OOB setup experience, troubleshooting/monitoring Out-of-scope: Operations/Day 100 experience, failover, cache saturation, all-flash configurations Stakeholders/ Audience: Engineering (requestor), Marketing (consumer) Methodology Platform: 2x 8 node clusters w/ ‘identical’ hardware, one running WS16 S2D the other VMware vSAN 6.2 Configuration: followed published and/or internal best practices S2D: MRT virtual disks, ReFS file system, VM workloads homed to node owning underlying virtual disk VSAN: 3-way mirror, 1 parity stripe, 4 disk groups per host (1 per SSD cache device) Workload: IOPS stress with Diskspd (via VMFleet) – Cache-only test ;Highlights No additional software required to enable/manage S2D Being a novice with S2D at the start of this project, but having familiarity with the failover clustering GUI/PS cmdlets, the learning curve to create/manage/operate S2D was very short RDMA provided a notable boost in overall solution performance (with fall back to TCP/IP allowing for additional troubleshooting/maintenance options) Storage QoS policies with a non-zero minimum IOPS value (regardless of what the maximum value was) provided consistent performance normalization of the VM workloads Challenges OOB experience to get from base failover cluster to S2D-enabled cluster was easy (single PowerShell cmdlet), getting to a point where the cluster can begin to service workloads takes an additional few PS cmdlets (virtual disk creation, etc.) Vastly different management experience depending on choice of base OS (Full/Core vs. Nano which lacked failover cluster/CSV PS modules, offered fewer Event Log providers, difficulty installing firmware/drivers, etc.) Ongoing/ proactive health monitoring in S2D disjointed (e.g. many places to look); at load, SMAPI becomes unresponsive (e.g. Get-Physical disk takes several minutes to complete)