【专家问答（翻译稿）】EMC ScaleIO 2.0介绍

小编插一句，EMC ScaleIO是免费的Server SAN软件，感兴趣的用户可以在这里获得：

http://www.emc.com/products-solutions/trial-software-download/scaleio.htm

用户 Groer 提问：

据我所知（如有错误请指出...），ScaleIO在故障集(Fault Sets)之间会保留两份数据块的拷贝，这似乎是无法更改的。那么

Q1: 有没有文档说明这一算法是如何将数据分发到超过两个故障集或者SDS的？

Q2: 两份数据拷贝不是很冗余，能否分享一些客户是如何克服这一限制的经验的？

Q3: 是否有计划提升这一限制到支持至少三个故障集上的三个拷贝？

Jason Sturgeon 回答：

你说的是对的，我们使用的是2x Mesh Mirroring (双份数据镜像)机制。为什么这样做的原因如下：

Q1: 故障集是对一组可能一起发生故障的节点的描述。举个例子：一台VxRack设备中的数个节点位于一个故障集中，我们的算法会确保数据镜像不会再写进这一故障集中（比如写到另一台VxRack）。这样的话，如果故障集中的多个节点都出现故障，那数据仍然是可用的。故障集最小数量是3.，不过它的数量会影响可用空间，特别当你只有少数节点的时候。

Q2: 当设备或节点出现故障时，数据重建是以大规模并行方式完成的。每一个节点上存储池中的数据都将向外分发数据。因为参与的节点数量非常多，并且数据都是镜像(mirrored)存放的，所以重建过程只需几分钟。风险窗口非常小，关键是重建速度如此之快（只要系统是按照最佳实践来部署的），数据丢失或不可用(DU/DL)的可能性相比传统的RAID 6或三镜像（3-mirror，需要更长的重建时间）就非常低。我们有一个内部的工具，提供在指定配置下的（基于所有组件和节点间的网络连通性）可用性分析。我们发现在2x数据镜像下可以获得非常高的可用性，我们有大量的服务提供商正在他们的关键业务上使用这一机制。

Q3: 现在我们使用的是2x Mesh Mirror机制，我们也在寻找未来可能的其他数据陈列方式。然而，从可用性的角度还没有到必须推动这一讨论的程度。

大家可能不清楚EMC VxRack，VxRack是基于ScaleIO的超融合设备。就像EMC还有一款融合设备VxRail是基于VMware VSAN的。

关于VxRack有篇很好的第三方评测文章，可以一读：EMC VxRack Node powered by ScaleIO Review | StorageReview.com - Storage Reviews

EMC VxRack Node powered by ScaleIO (Performance Compute All Flash PF100) Specifications

• Chassis - # of Node: 2U-4 node
• Processors Per Node: Dual Intel E5-2680 V3, 12c, 2.5GHz
• Chipset: Intel 610
• DDR4 Memory Per Node: 512GB (16x 32GB)
• Embedded NIC Per Node: Dual 1-Gbps Ethernet ports + 1 10/100 management port
• RAID Controller Per Node: 1x LSI 3008
• SSDs Per Node: 4.8TB (6x 2.5-inch 800GB eMLC)
• SATADOM Per Node: 32GBSLC
• 10GbE Port Per Node: 4x 10Gbps ports SFP+
• Power Supply: Dual 1600W platinum PSU AC

用户 Aiyappa 提问：

当故障集出现故障且没有多余的空间用于重建，群集会怎么样？

比如一个4机柜的群集，以单个机柜为故障集的话，很难说服客户将一整个机柜的空间用作冗余空间。

Jason 回答：

系统不会让你使用必要的空间，因此类似情景不会出现。我同意，4机柜群集的话，保留空间确实会比较高。如果群集内设备数量多到大概10个机柜时，也许用机柜为单元做故障集才有意义。

故障集是对一组可能一起发生故障的节点的描述。大多数的数据中心不会出现整个机柜内的设备一起出现故障的情形，所以以机柜为单元不是最好的选择。有些设备在一个机箱内就集成了多个节点，比如2U的机箱里有4个节点（小编：楼上的VxRack就是这样的设计）。如果担心一个机箱出现故障导致4个节点全部不可用，那以机箱为故障集就讲得通了。

用户 wangzz 提问：

关于ScaleIO的性能我有些问题：

1. 有哪些因素会影响性能？（硬盘类型、网络、服务器规格、SDS数量等等？）

2. 每个SDS中设备数量会影响性能吗？（比如3盘的3个SDS对6盘的3个SDS）

3. 加入SDS中的设备可以是硬盘或未挂载的分区，使用裸硬盘和未挂载分区在性能上有区别吗？

Dan 回答：

1. 你列举的这些都会影响，硬盘（数量和类型）、网络（每节点端口数量和其他网络限制如交换机等）、SDS数量（节点数量）、RAID控制器类型、缓存方案等。

2. 答案取决于硬盘类型。如果是机械硬盘，通常限制是硬盘自身，硬盘越多性能越好。硬盘是如何分布在SDS中的通常不影响性能，但作为最佳实践，每个节点最好分配相同的硬盘。如果是固态硬盘(SSD/Flash)，限制就可能是SDS而不是闪存盘，你需要平均分配闪存盘到SDS中。

3. 你可以“技巧性”地将一部分硬盘的空间当作一个"drive"分配给ScaleIO，但我会避免这样做。你得不到任何性能提升，反而会将问题变得复杂，特别当你需要更换“硬盘”的时候。只要保持系统的简单，啥事都会变好。

用户 usakwilliamson 提问：

1. 我对什么时候可以像其他超融合系统一样实现消重和压缩功能比较感兴趣。

2. 什么时候可以让ScaleIO加入VMware HCL硬件兼容列表？我好像没看到。

3. ScaleIO有推荐的硬件列表吗？比如各种闪存卡、硬盘等。

4. ScaleIO考虑存储分层吗？比如在主机上有SSD层和10K转速硬盘层就很好。

Dan 回答：

1. 已经有计划加入压缩，消重我不太确定。我们发现对于大多数的通用应用，将大量融合系统配置中的资源用于消重所带来的收益不够明显。

2. 抱歉这个得有VMware来决定，我会让其他人来跟踪这个问题。

3. ScaleIO对硬件是不挑剔的。就像你买Oracle，他们不会告诉你要买哪些硬件。我们会指定哪些操作系统我们是支持的，任何销售硬件的厂商对会想法设法让他们的设备兼容这些操作系统。如果你执意要看的话，可以看一下VxRack Flex或VxRack Node硬件组合（ScaleIO 硬件+软件解决方案）然后选用一样的硬件组件。

4. 我们有分层。VxRack中我们使用CacheCade技术，允许你配置SSD为后端硬盘的读/写缓存。你也可以使用RFCache（随ScaleIO 2.0免费发布），将SSD或任何闪存设备配置为只读缓存。

关于第二个问题，SN 补充道：

VMware提供对ScaleIO全面的认证和支持。VMware Support团队也已确认这点。我们正在同VMware的同事一起确定将ScaleIO列在HCL上的哪个位置更合适。预计2016年第二季度VMware HCL上就能看到ScaleIO了。

用户 Groer 提问：

能分享一些数据完整性功能对性能影响的数据吗？比如检验(checkrum)、零填充(zero padding)、后台扫描(background scanner)这些操作？即使只能提供数量级上的影响评估也行，比如接近1%或10%？

DanAharoni 回答：

很愿意分享这样的数据。

数据校验(checksum)对性能的影响取决于不同的操作系统：

• Linux：没有实际的影响（使用特殊的Intel CPU指令，几乎可视作是硬件方案）。
• Windows：大约30%的影响（纯软件方案）。需要注意的是，如果你没有达到最大IOPS的限制，那不会有这么高的影响。
• ESX：SDS端没有影响（硬件方案）；SDC端大约30%（纯软件方案）。同上，如果没有达到最大IOPS的限制，不会有这么高的影响。

零填充(zero padding)：实际环境几乎没有影响。类似Thin，这个功能仅影响新写入的数据。除非是完全新的数据卷或者测试，影响是非常小的。

后台扫描：没有影响。扫描是以很低的速率工作，对整个系统来说就是一点点“噪音”。