【编者按】
下面这篇文章摘选自《VMware软件定义存储》第6章。文末有赠书规则。
---Begin---
Web-Scale这一词的概念，最早是由Gartner在2013年提出，指的是一种架构方法，基于这种方法超大规模云提供商（如Google，Amazon，Facebook，Netflix和其他厂商等）可以为大型企业IT组织和服务提供商提供所需的服务保障能力，建立和运维一个极大规模的基础设施平台。同时，Web-Scale的目的也不仅仅是构建极大规模的基础架构，还可通过一套固定的流程和架构标准化来提高基础架构运营的敏捷性。
Web-Scale不是一项单一的技术，它是一种适用于任意规模数据中心的架构和管理的方法论，借助于标准化和可重复的构建块（building-block）的设计方法，构建满足不同业务需求的基础架构。
以下是大型企业IT组织或云服务提供商在考虑构建基于Web-Scale的基础架构时的关键要求：
¨ 能够在x86服务器上提供超融合架构（HCI）平台，具有完全集成的计算和存储组件。
¨ 能够以分布式方式提供数据和应用服务，包括集群范围内分发资源的能力。
¨ 系统基础架构的高可用和自我修复，包括能够提供故障隔离和分布式系统恢复能力。
¨ 通过软件定义的数据中心概念提供API驱动的自动化，以及通过底层基础架构监控进行综合分析。
¨ 为工作负载提供关键服务需求时，具备跨平台同时托管多种应用类型的能力。
如第4章“使用 VirtualSAN 实现策略驱动的存储设计”所强调的，Virtual SAN集群具有强大的可扩展性，vSphere 6中最多可以配置64个节点，可以轻松支持成千上万的虚拟机工作负载。在设计Web-Scale的Virtual SAN平台时，您有两种基本的设计策略：
纵向扩展：每个Virtual SAN主机都有更多的存储资源可用，但总体Virtual SAN节点数较少。
横向扩展：通过增加Virtual SAN节点数量来扩展，但最终占据更大的总体空间。
在Web-Scale的架构设计中，架构师通常要同时考虑纵向扩展和横向扩展。设计上不仅仅考虑每个Virtual SAN集群是否拥有更少的较大资源主机或更小的节点，还要更多的结合用户的业务情况设计构建块，结合纵向和横向扩展架构搭建一个标准和可控的基础架构。
6.1 纵向扩展架构
Virtual SAN环境中的纵向扩展策略是指增加每个主机上可用的存储资源的数量。这可以通过增加每个磁盘组中的容量磁盘数量或增加每个Virtual SAN主机上的磁盘组数量来实现。Virtual SAN是完全支持将容量磁盘添加到现有磁盘组的，如图6.1所示。企业或服务提供商在设计Web-Scale架构时会为磁盘组配置定义好的构建块标准，例如按1:4比例配置混合磁盘组，一块闪存盘为四块容量机械磁盘提供写入缓存和读取缓存。
Virtual SAN支持由一块耐久性高的闪存设备和最多七块容量磁盘组成磁盘组，这七块容量磁盘可以是机械硬盘，也可以是闪存盘，取决于设计上要使用的磁盘组类型。此外，Virtual SAN集群中的每个主机最多可以支持五个磁盘组，每个磁盘组都为分布式Virtual SAN数据存储的总容量提供存储资源。
如第4章所述，使用多个较小的磁盘组而不是单个大型磁盘组，可以减少故障域，当容量磁盘故障时重建的组件也会相应变少，从而重建的时间会更快。使用多个较小的磁盘组，如图6.2所示，性能也得到了提升，在混合模型中性能提升更加明显。在磁盘组架构中使用更多的闪存设备，使得闪存和容量存储之间的比例变小，更多的数据将会驻留在闪存设备高速的读取缓存中，Virtual SAN将获得更好的性能。
综上所述，Virtual SAN的配置很重要。为了在分布式Virtual SAN数据存储上获得一致性的性能，建议在集群中的所有节点上采用统一的磁盘组配置。并且从Virtual SAN集群Web-Scale架构角度来说，更加不建议对Virtual SAN不同的节点采用不同的配置。
Web-Scale架构设计中的纵向扩展部分还要考虑每个Virtual SAN主机的存储I / O控制器的数量。在不同存储控制器上创建磁盘组时，会降低故障域，同时控制器队列分布在所有的存储控制器上，会带来更加出色的存储性能。
另一个设计上的考虑点还包括使用SAS扩展器代替额外的存储控制器。这种存储技术可以超出普通存储控制器8、12、16或24块驱动盘的限制，最大限度的利用SAS存储扩展器的存储能力。
SAS扩展器将额外的驱动盘放在单个存储控制器后面，比添加存储控制器更加节省成本。然而，SAS扩展器的性能和可靠性应被视为设计上的风险。通常不推荐将SAS扩展器包含在任何VirtualSAN平台中。
【编者Peter Ye按开始】
VMware建议避免调整SAS Expander（扩展卡）：
1、SAS Expander不需要驱动，通常对系统来说是透明的，所以用户比较难注意到Expander的存在；
2、Build Your Own不支持Expander；
3、vSAN SAS Expander 注意事项的细节
1）除了DELL R730XD，每超过8块盘，再需要额外的存储控制器
http://cormachogan.com/2015/07/27/sas-expander-support-on-virtual-san/
通过vSAN认证的，支持SAS Expander的，也就是说一个控制器可以支持超过8块盘的，为数不多。目前DELL有R730XD（24块盘）、HPE有DL380 Gen10 with SAS Expander （24块盘）
2）多数情况下，每个控制器仅支持最多8块盘 ，有的支持16块盘
举例：LSI MegaRAID SAS 9260-16i支持16个内部端口，也即最多16块盘；9261-8i只支持8个内部端口，也即支持最多8块盘。
参考：vSAN 硬件快速参考指南
https://www.vmware.com/resources/compatibility/vsan_profile.html?locale=zh_CN
SAS 扩展器仅在就绪节点中支持。请查看就绪节点列表以获得支持。如果 SAS 扩展器不支持就绪节点，则每个控制器仅支持 8 个或16个驱动器（具体取决于控制器型号）。如果需要 8 个或16个以上的驱动器，请额外添加一个控制器。
【编者Peter Ye按结束】
图6.1 磁盘组纵向扩展策略（增加容量磁盘）
图6.2 磁盘组纵向扩展策略（增加磁盘组）
6.2 横向扩展架构
横向扩展策略是指将新主机添加到Virtual SAN集群中，同时增加存储资源和计算资源。这里需要说明的是，Virtual SAN计算资源的横向扩展是可以独立于存储单独实现的，但增加Virtual SAN节点无法只扩展存储资源，除非使用基于DAS的JBOD硬件。
Virtual SAN支持在正常操作期间热添加节点和磁盘组，无需停机。然而，与数据中心的大多数物理硬件打补丁需要进入维护窗口一样，Virtual SAN这些操作通常建议应在软件维护窗口期执行。
图6.3说明了Virtual SAN如何扩展以满足最苛刻的企业或服务提供商的环境需求。Web-Scale架构下的单个Virtual SAN集群最大64个节点可以轻松支持数以万计的虚拟工作负载。
图6.3基于Virtual SAN的vSphere集群纵向扩展和横向扩展到8个主机
6.3 基于vSphere主机集群的Web-Scale设计
Virtual SAN集群是共享存储资源的边界。因此，在规划多个大型集群的设计时，请考虑以下关键注意事项：
¨ 容量规划：尽管用较少数量的大型集群（大型集群指的是单个集群节点数多）来规划未来扩展可能更为简单，但在总体主机数量固定的前提下，从单个集群容纳的主机数量上限角度去考虑构建块设计，能更好的实现集群横向扩展。例如，16个24节点的集群和6个64节点的集群相比，总体主机数量相同，但前者24节点集群显然更适合按照构建块方式来进行集群横向扩展。
¨ 硬件成本：由于Virtual SAN集群需要一定数量的备用存储资源防止出现故障，在考虑Web-Scale时，数量巨大的较小资源的Virtual SAN集群会导致硬件成本更高。
¨ 安全：在多租户或多业务环境中，将租户或业务组放到专门的Virtual SAN集群是分割负载的一个好方法，并通过基于角色的访问控制（Role-based Access Control，RBAC）控制访问。
¨ 性能：在多租户或多业务环境中，将租户工作负载或特定业务应用放到专门的Virtual SAN集群，确保设计的资源始终为这些用户和应用使用。
6.4 构建块集群和 Web-Scale 横向扩展架构
Virtual SAN集群设计的一个简单并可扩展的方法是构建块方法，这个方法也被多个云服务提供商和大型企业私有云客户使用。构建块的每个集群都是一个标准的资源容器，提供简单、可扩展的计算和存储资源。按照这种方法，不仅可以实现跨数据中心扩展，还可以保证扩展的一致性，消除配置偏差，减少运维工作量。这种方法同时也是最简单和最有效的方式，以灵活的解决方案，满足大型企业IT组织和云服务提供商的Web-Scale和平台扩展需求。这种构建块方法通过对Virtual SAN主机、集群和服务器机柜的配置制定构建标准，使得管理和支持基础架构的工作变得更加便利。
在大规模部署时，标准化的构建块对基础架构的可管理性和可支持性至关重要，它通过对Virtual SAN主机和集群的物理和逻辑配置标准化，消除了大规模部署时的差异性。在Virtual SAN的vSphere集群中主要通过vSphere主机配置文件（Host Profile）实现标准化，主机配置文件可以跨主机和Virtual SAN的集群保持构建块配置的一致性。
6.5 Web-Scale架构的物理资源设计
对于设计一个可扩展且规模达到数百甚至数千台主机，提供PB级存储，并支持大型复杂网络的虚拟基础架构，如何提高扩展性是一个关键问题。在扩展大型物理Virtual SAN平台同时又要保证平台可控，符合合规性以及保障安全，从规划扩展性的第一天开始，就要采用预定义的构建块方法进行设计。
此外，每个主机的安装和配置过程都应该标准化，让每个组件的安装步骤保持一致。物理组件配置的标准化对于Web-Scale基础架构的可管理性、一致性和可支持性等方面至关重要。整个过程的标准化消除了差异性，减少了补丁管理涉及的工作量，提供了一个更加灵活的构建块解决方案。
尽管Virtual SAN平台配置和扩展的一些方面可能取决于硬件供应商，但这些也应该是Web-Scale的Virtual SAN平台设计需要考虑的一部分。图6.4所示的示例描述了一个常见的构建块场景。
在这个例子中，每个Web-Scale的单元由96个机架式Virtual SAN主机组成，配置为四个24节点集群，主机平均安放在六个服务器机柜中。每个Web-Scale的单元还包含两个48端口10GbE交换机和两个1GbE IPMI管理交换机，用于带外连接。每个单元设计为Virtual SAN提供多个故障域，以及计算和网络资源。
本示例中的Web-Scale单元的数量可以根据设计要求，以及软硬件限制，相应地进行横向扩展。
如图6.5所示，每个包含96台主机的Web-Scale单元可以横向扩展，并在多个数据中心可用性区域和物理数据中心之间形成一个真正的Web-Scale平台。
本示例中，每个Web-Scale单元中的vSphere组件由单个vCenter Server实例进行管理。表6.1提供了此构建块Web-Scale架构的每个组件的计算、存储和网络资源清单。
图6.4 Web-Scale单元逻辑架构设计
表6.1 构建块Web-Scale架构扩展性示例
资源 |
主机 |
集群 |
Web-Scale单元 |
内存 |
512 GB DDR3 |
10.5 TB (24 节点，3节点为HA保留资源) |
42 TB |
CPU |
2 * Intel E5 8-Core 3.1 GHz = 49.6 GHz |
1,041.6 GHz (24 节点，3节点为HA保留资源) |
4,166.4 GHz |
|
高性能存储集群 (一级) 1 * 400 GB MLC SSD (~15% 可用容量) 5 * 1.2 TB 10k SAS |
~20k IOPS 读 ~15k IOPS 混合 6 TB 裸存储 |
~480k IOPS 读 ~360k IOPS 混合 144 TB 裸存储 |
~1920k IOPS 读 ~1440k IOPS 混合 576 TB 裸存储 |
|
标准存储集群(二级) 1 * 400 GB MLC SSD (~10%可用容量) 7 * 2 TB 7.2k NL-SAS |
~15k IOPS 读 ~10k IOPS 混合 14 TB 裸存储 |
~360k IOPS 读 ~240k IOPS 混合 336 TB 裸存储 |
~1440k IOPS 读 ~960k IOPS 混合 1.3 PB 裸存储 |
|
容量存储集群 (三级) 2 * 400 GB MLC SSD (~4% 可用容量) 10 * 4 TB 7.2k NL-SAS |
~10k IOPS 读 ~5k IOPS 混合 40 TB 裸存储 |
~240k IOPS 读 ~120k IOPS 混合 960 TB 裸存储 |
~960k IOPS 读 ~480k IOPS 混合 3.7 PB 裸存储 |
网络带宽 |
20Gb/s |
480Gb/s |
1,920Gb/s (80 Gb/s MLAG to Spine) |
注意: 在此示例中，IOPS基于70％读取和80％混合（随机）I / O负载
图6.5 Web-Scale单元数据中心横向扩展策略
这个例子只是Web-Scale平台架构中的一种。这种级别的可扩展的Virtual SAN物理基础架构平台设计非常复杂，它在Web-Scale构建块设计方面的关键考量点如下：
¨ 平台增长预期
¨ 硬件可用性和交货周期
¨ 物理硬件扩展性限制（如管理工具）
¨ 建设费用支出和硬件折旧考虑
¨ 数据中心电源，空间，区域及冷却限制
6.6 Web-Scale 叶脊架构
传统的三层（核心、汇聚和访问）网络拓扑架构，虽然对网络数据进出数据中心进行过优化，但并不适用于Web-Scale的Virtual SAN平台跨机架内部数据传输。
另一方面，在第4章中介绍的叶-脊（Leaf-Spine）架构使用一个多重拓扑，通过使用等价多路径（ECMP）来主动管理两个端点之间的多个路径。此外，Spine设备使用高端口计数平台并基于层叠式Clos（或胖树）的设计实现部署，无需再使用其他交换机组件。叶-脊（Leaf-Spine）拓扑的关键特性与Web-Scale的Virtual SAN平台相关，包括：
¨ 可变长度的Spine使用ECMP，在Leaf和Spine交换机之间有多个可用路径时，可以做出多种设计选择。
¨ 这种架构也指引着未来的高性能和自动化软件定义网络平台（如VMware NSX）。
图6.6展示了使用多路径拓扑的叶-脊（Leaf-Spine）架构，与上一节中描述的Web-Scale架构相一致。
在Virtual SAN的扩展设计中还需要考虑的有：
¨ 每个Virtual SAN集群都应使用专有的VLAN进行隔离复制和工作负载。这将VirtualSAN集群流量与任何外部干扰隔离开来，更方便地进行故障排查。
¨ 在Virtual SAN 6中，为了使Virtual SAN集群能够支持64个节点，必须在集群所有主机上设置三个选项：
1. 集群中每个主机设置高级选项，增加节点支持：
esxcli system settings advanced set -o/VSAN/goto11 -i 1
图6.6 Web-Scale 叶-脊架构
2. 增加TCP / IP堆大小：
esxcli system settings advanced set –o/Net/TcpipHeapMax –i 1024
3. 将客户端限制设置为65，最多允许64台主机：
esxcli system settings advanced set -o/CMMDS/clientLimit 65
必须重新启动所有主机才能使这些更改生效。此外，还应该查看VMware知识库上相关文章的最新配置建议。
此外，Web-Scale扩展设计包括以下最大值：
¨ 在Virtual SAN 5.5中集群最多32个节点，6.2中集群最多64个节点。
¨ 每个混合磁盘组中都只能使用一个缓存闪存设备。
¨ 每个磁盘组可以使用1到7个容量机械磁盘或容量闪存设备。
¨ 每个主机最多有5个磁盘组。
¨ Virtual SAN 5.5 VMDK大小最多为2TB， 6.2中最大62 TB。
¨ Virtual SAN 5.5中每个主机最多可容纳100个虚拟机，6.2每个主机的虚拟机数为200。
除了这些设计最大值外，表6.2还强调了在规划大型VirtualSAN部署时需遵守的最大值。
表6.2 Virtual SAN 6.0、6.1、或6.2最大值
属性 |
最大值 |
每个集群的 Virtual SAN 数据存储 |
1 |
每个主机的最大虚拟机数 |
200 |
每个主机的最大组件数 |
9,000 |
每个集群的最大虚拟机数 |
6,400 |
每个集群受 HA 保护的最大虚拟机数 |
2,048 |
---End---
赠书规则：
欢迎大家转发本篇文章，您的留言获赞数较多的，2~3个人有机会获得《VMware软件定义存储：原理剖析和设计指南》、1个人有机会获得《中国IT运维能力建设指南》，也就是说至少有3个人有机会各自获得一本赠书。再提醒一遍，要获得赠书机会，您需要先留言！ 然后邀请别人给你的留言点赞，留言获赞数较多的，且言之有物的，才有机会获得赠书！
上次 "VMware软件定义存储的设计 | 留言点赞获赠书&获奖名单公布" 活动的三位获奖者将依次收到赠书。
恭喜王小胖要减肥、安可新、Z S 、三位朋友，获得了赠书，如下图所示。
《VMware软件定义存储：原理剖析和设计指南》纸质书在各大网店都有销售，包括当当、淘宝、亚马逊、机械工业出版社读者服务网(golden-book.com)等。不过，个人推荐去京东的自营店，8.8折，也即104.50元。或者互动出版网China-Pub (http://www.china-pub.com/)，7折，也即83.30元。京东的其他网店也有本书出售，折扣可能更深，不过从我自己下单的经验看，发现其他网店要比京东自营店慢好几天。而且其他网店不能保证是正版书籍。
点击左下角“阅读原文”，即可跳转到京东自营店。