西部数据 推出Ultrastar DC SN630 今年 200 月,作为数据中心驱动器 Ultrastar 系列(前身为 HGST)更新和品牌重塑的一部分。 在该产品组合中,Western Digital 拥有多种企业级 NVMe SSD 产品,其中 SN630 成为性能领导者,而新的 SN620 取代了主流单端口 NVMe 空间中的 SN630,后者是 SATA 和 SAS SSD 越来越受欢迎的替代品。 SNXNUMX 是 Western Digital 的主力 NVMe SSD,针对以读取为中心的工作负载或高耐久性混合使用工作负载进行了调整。 两种情况下的驱动器结构都是相同的,进入驱动器的过度配置水平的功能差异,进而产生所需的耐久性等级。
西部数据 推出Ultrastar DC SN630 今年 200 月,作为数据中心驱动器 Ultrastar 系列(前身为 HGST)更新和品牌重塑的一部分。 在该产品组合中,Western Digital 拥有多种企业级 NVMe SSD 产品,其中 SN630 成为性能领导者,而新的 SN620 取代了主流单端口 NVMe 空间中的 SN630,后者是 SATA 和 SAS SSD 越来越受欢迎的替代品。 SNXNUMX 是 Western Digital 的主力 NVMe SSD,针对以读取为中心的工作负载或高耐久性混合使用工作负载进行了调整。 两种情况下的驱动器结构都是相同的,进入驱动器的过度配置水平的功能差异,进而产生所需的耐久性等级。
从 SSD 设计的角度来看,Ultrastar SN630 使用西部数据的内部控制器和固件构建以及西部数据自己的 64 层 BiCS3 3D NAND。 从工程角度来看,像这样的垂直集成解决方案正在成为一流企业级 SSD 的标准。 虽然使用来自不同来源的 NAND、控制器和固件当然是可能的,但我们倾向于看到性能更好、更可靠的供应商提供的解决方案,他们可以自己完成所有工作。 该驱动器本身使用 7 毫米 2.5 英寸 U.2 外形尺寸,与西部数据提供的其他 SSD 一样,SN630 提供专有的磨损均衡算法和断电保护。
如前所述,SN630 采用混合用途和读取密集型 SKU。 前者提供 6.40TB、3.20TB、1.60TB 和 800GB 容量,而后者提供 7.68TB、3.84TB、1.92TB 和 960GB 容量。 所有驱动器都提供即时安全擦除 (ISE),它使用幕后加密密钥来处理驱动器的重新部署和报废。 Western Digital 还提供带有 RSA 身份验证的安全固件下载,以确保 SN630 仅运行正版固件。 最后,这些驱动器享有 5 年有限保修。
在这篇评论中,我们检查了 SN630 在 VMware vSAN 环境中的性能。 评测配置使用 Supermicro SuperServer BigTwin 2029BT-HNR 4 节点机箱、24 个 Ultrastar DC SN630 NVMe SSD 和 VMware vSAN 6.7 Update 1,以更广泛的系统视角深入研究 SN630 的性能。
Western Digital Ultrastar DC SN630 规格
型号 | 可见光/反射率 | |||
容量 | 960GB / 800GB | 1,920GB / 1,600GB | 3,840GB / 3,200GB | 7,680GB / 6,400GB |
外形尺寸 | U.2 2.5 英寸驱动器 | |||
接口 | PCIe Gen 3.1 x4(符合 NVMe 1.3) | |||
闪存技术 | 西部数据 BiCS3 3D TLC NAND | |||
性能 | ||||
顺序读取,(最大 MiB/s) | 2,690/2,690 | 2,660/2,670 | 2,510/2,500 | 2,520/2,540 |
顺序写入,(最大 MiB/s) | 930/960 | 1,230/1,240 | 1,180/1,200 | 1,240/1,240 |
随机读取(最大 IOPS) | 278,760/281,790 | 358,220/356,870 | 332,420/332,510 | 360,280/306,520 |
随机写入(最大 IOPS) | 43,580/86,740 | 53,850/86,870 | 55,000/88,140 | 54,220/88,210 |
随机混合 R70/W30(最大 IOPS) | 107,350/188,480 | 170,390/253,390 | 163,350/238,500 | 170,250/273,960 |
随机读取延迟 (μs) | 179/179 | 190/188 | 243/239 | 243/239 |
可靠性 | ||||
DWPD | 0.8/2 | |||
UBER | 1 分 10 ^ 17 | |||
EOL 数据保留 | 5° C 至 40° C,最长 90 天 | |||
平均无故障时间 | 2万小时 | |||
AFR | 0.44% | |||
电力 | ||||
要求(DC +/- 10%) | 12V | |||
工作功率状态(W,典型值) | 10.75和8.75 | |||
空闲(W,平均) | 5.80 | 5.80 | 5.90 | 6.10 |
环境 | ||||
工作温度 | 0°C至78°C | |||
平均温度 | -40° C 至 70° C 1 年 | |||
物理 | ||||
宽度(mm) | 69.85 +/- 0.25 | |||
长度(毫米,最大) | 100.45 | |||
重量(克,最大) | 95 | |||
z-高度 (mm) | 7.00 +0.2/-0.5(包括标签) | |||
保修政策 | 5年限 |
Western Digital Ultrastar DC SN630 VMware vSAN 设计和构建
Western Digital Ultrastar DC SN630 是一款针对数据中心的 2.5 英寸 NVMe 驱动器。 该驱动器的容量范围从 800GB 到 7.68TB。 SN630 采用黑色金属封装,顶部有一张贴纸,上面贴有名称、品牌、容量、型号和认证等信息。
Supermicro SuperServer BigTwin 机箱的正面配备 24 个 2.5 英寸 NVMe 驱动器托架,每个节点分配 6 个。 每个节点都提供自己的定位 LED 按钮以及独立的电源按钮。
BigTwin 的背面显示了四个计算节点托盘。 每个都标配一个用于带外管理的 IPMI 端口、VGA、两个 USB 3 端口以及一个用户可配置的 NIC。 在我们的配置中,我们使用了一个四端口 NIC,具有两个 10GBase-T 端口和两个 SPF28 25G 端口。 我们的测试配置利用 vSAN 集群的 25G 连接。 作为机箱设计的一部分,所有节点共享一个通用的双 PSU 电源平台。
Western Digital Ultrastar DC SN630 VMware vSAN 查看配置
为了在 vSAN 环境中测试 24 块 SN630 SSD,我们使用了 Supermicro SuperServer BigTwin 2029BT-HNR 四节点系统。 每个节点的配置如下:
- 2 个 Intel Gold 6150 CPU(2.7GHz,18 核)
- 12 x 32GB 2666MHz DDR4 ECC 内存
- 2 个 800GB Western Digital Ultrastar DC SN630 NVMe SSD,用于 vSAN 缓存
- 4 个 1.92TB Western Digital Ultrastar DC SN630 NVMe SSD 用于 vSAN 容量
- 1 x 500GB Western Digital Blue SATA SSD 用于引导驱动器
- 双端口 25Gb Mellanox ConnectX-4 网卡
- VMware ESXi 6.7u1 (10302608)
我们利用相当适度的服务器构建来围绕 Western Digital Ultrastar DC SN630 进行 VMware vSAN 测试。 服务器使用中高端 Intel Gold 6150 CPU,时钟速度为 2.7GHz,内核数为 18。每台服务器为我们提供 97.2GHz 的计算能力,或集群级别的 388.8GHz。 我们还为每个节点使用了 384GB 的 RAM,为我们的合成和应用程序工作负载提供了充足的内存。
在我们的测试配置中,我们使用每个节点两个磁盘组的布局,每个磁盘组有一个 800GB SN630 NVMe SSD 用于缓存,两个 1.92TB SN630 NVMe SSD 用于容量。 可用容量取决于虚拟机在集群中的配置方式以及您使用的镜像级别。 原始存储在我们的集群中测量为 27.95TB,但使用带有 vSAN 开销的默认双向镜像 VM 策略,我们剩下 13.79TB 的可用容量。 尽管对于某些工作负载类型,数据缩减会显着扩展它。
虽然我们的应用程序工作负载将专注于关闭数据缩减的集群性能,但我们将包括综合基准测试,展示启用和不启用数据缩减的集群性能。 虽然数据缩减会产生与之相关的性能开销,但它会在某些部署中显着增加 vSAN 集群的可用容量。
Western Digital Ultrastar DC SN630 VMware vSAN 性能评估
SQL Server 性能
StorageReview 的 Microsoft SQL Server OLTP 测试协议采用事务处理性能委员会的基准 C (TPC-C) 的最新草案,这是一种模拟复杂应用程序环境中活动的在线事务处理基准。 TPC-C 基准比综合性能基准更接近于衡量数据库环境中存储基础设施的性能优势和瓶颈。
每个 SQL Server VM 都配置有两个虚拟磁盘:100GB 卷用于启动,500GB 卷用于数据库和日志文件。 从系统资源的角度来看,我们为每个虚拟机配置了 16 个 vCPU、64GB DRAM 并利用了 LSI Logic SAS SCSI 控制器。 虽然我们之前测试的 Sysbench 工作负载在存储 I/O 和容量方面使平台饱和,但 SQL 测试寻找延迟性能。
此测试使用在 Windows Server 2014 R2012 来宾虚拟机上运行的 SQL Server 2,并由戴尔的数据库基准工厂进行压力测试。 虽然我们对该基准的传统用法是在本地或共享存储上测试 3,000 规模的大型数据库,但在本次迭代中,我们专注于在我们的服务器上均匀分布四个 1,500 规模的数据库。
SQL Server 测试配置(每个虚拟机)
- Windows服务器2012 R2的
- 存储空间:分配 600GB,使用 500GB
- SQL Server的2014的
- 数据库大小:1,500 规模
- 虚拟客户端负载:15,000
- 内存缓冲区:48GB
- 测试时长:3 小时
- 2.5 小时预处理
- 30分钟采样期
对于我们的事务性 SQL Server 基准测试,Supermicro BigTwin 中的 Western Digital Ultrastar DC SN630 VMware vSAN 能够达到 12,610.3 TPS 的总分,单个 VM 的运行速度从 3,152.01 TPS 到 3,153.2 TPS。
对于 SQL Server,我们看到总分 14.75 毫秒,单个虚拟机的总分从 14 毫秒到 15 毫秒不等。
Sysbench MySQL 性能
我们的第一个本地存储应用程序基准测试包括通过 SysBench 测量的 Percona MySQL OLTP 数据库。 该测试测量平均 TPS(每秒事务数)、平均延迟和平均 99% 延迟。
每个 Sysbench VM 配置了三个虚拟磁盘:一个用于启动 (~92GB),一个用于预构建数据库 (~447GB),第三个用于测试中的数据库 (270GB)。 从系统资源的角度来看,我们为每个虚拟机配置了 16 个 vCPU、60GB DRAM 并利用了 LSI Logic SAS SCSI 控制器。
Sysbench 测试配置(每个虚拟机)
- CentOS 6.3 64 位
- Percona XtraDB 5.5.30-rel30.1
- 数据库表:100
- 数据库大小:10,000,000
- 数据库线程:32
- 内存缓冲区:24GB
- 测试时长:3 小时
- 2 小时预处理 32 个线程
- 1 小时 32 个线程
我们使用 Sysbench OLTP 测试了 8 个虚拟机,得到了 11,739.7 TPS 的总分,单个虚拟机的得分从 1,326 TPS 到 1,552.3 TPS 不等。
使用 Sysbench 延迟时,服务器的平均延迟为 21.86 毫秒。
在我们最坏的情况下(第 99 个百分位数)延迟,Western Digital 驱动器给了我们 38.71 毫秒。
VDBench 工作负载分析
在对存储阵列进行基准测试时,应用程序测试是最好的,综合测试排在第二位。 虽然不能完美代表实际工作负载,但综合测试确实有助于为具有可重复性因素的存储设备建立基线,从而可以轻松地在竞争解决方案之间进行同类比较。 这些工作负载提供了一系列不同的测试配置文件,包括“四个角”测试、常见的数据库传输大小测试,以及来自不同 VDI 环境的跟踪捕获。 所有这些测试都利用通用的 vdBench 工作负载生成器,以及一个脚本引擎来自动化和捕获大型计算测试集群的结果。 这使我们能够在各种存储设备上重复相同的工作负载,包括闪存阵列和单个存储设备。
简介:
- 4K 随机读取:100% 读取,128 个线程,0-120% 重复率
- 4K 随机写入:100% 写入,64 线程,0-120% iorate
- 64K 顺序读取:100% 读取,16 个线程,0-120% 迭代
- 64K 顺序写入:100% 写入,8 个线程,0-120% 迭代
- 综合数据库:SQL 和 Oracle
- VDI 完整克隆和链接克隆跟踪
在我们所有的 VDBench 测试中,我们测试了 DR 打开和关闭的 Western Digital 驱动器。 对于随机 4K 读取,两种配置都在 1 毫秒以下开始,DR 版本突然出现并达到 387,937 IOPS 的峰值,延迟为 7.5 毫秒。 在关闭 DR 的情况下,驱动器保持在 1 毫秒以下,直到略高于 350K IOPS 并达到 442,089 IOPS 的峰值,延迟为 4.8 毫秒。
对于 4K 再次写入,两种配置的启动时间都不到 1 毫秒。 DR 版本在大约 90K IOPS 之前具有亚毫秒级延迟,并以 182,791 毫秒的延迟达到 7.4 IOPS 的峰值。 在 DR 关闭的情况下,我们看到驱动器保持在 1 毫秒以下,直到大约 110K IOPS,峰值达到 196,027 IOPS,延迟大约 7 毫秒,然后下降一些。
接下来是我们的顺序工作负载。 在 64K 读取中,DR 版本开始超过 1 毫秒,峰值为 132,918 IOPS 或 8.3GB/s,延迟为 3.7 毫秒。 在关闭 DR 的情况下,驱动器保持在 1ms 以下,直到大约 130K IOPS 或大约 8GB/s,并在 159,681ms 延迟时达到 9.98 IOPS 或 2.87GB 的峰值。
在 64K 写入中,两种配置都以亚毫秒延迟开始,但很快超过 1 毫秒。 在启用 DR 的情况下,我们看到峰值仅为 22.7K IOPS 或大约 1.4GB/s,延迟为 1.32ms,然后性能下降并出现较大的延迟峰值。 关闭 DR 后,驱动器在 63,347 毫秒时达到 4 IOPS 或大约 3.3GB/s 的峰值,然后下降一些。
我们的下一组测试是我们的 SQL 工作负载:SQL、SQL 90-10 和 SQL 80-20。 对于 SQL,两种配置开始时均低于 1 毫秒,DR 版本高于 1 毫秒,然后低于 349,851 毫秒,在 2.6 毫秒延迟时达到 255 IOPS 的峰值。 在关闭 DR 的情况下,驱动器在大约 358,787K IOPS 之前具有亚毫秒级延迟,然后以 2.24 IOPS 达到峰值,延迟为 XNUMX 毫秒,然后略有下降。
在 SQL 90-10 中,我们再次看到启用 DR 的版本在 1 毫秒延迟时达到 283,524 IOPS 的峰值之前几次出现在 3.42 毫秒线以上和以下。 非 DR 版本保持在 1 毫秒以下,直到大约 275K IOPS 并达到 334,737 IOPS 的峰值,延迟为 2.45 毫秒。
SQL 80-20 看到这两种配置都以亚毫秒延迟开始,DR 版本在大约 1K IOPS 时超过 155ms,在 256,926ms 延迟时达到 3.5 IOPS 的峰值。 非 DR 版本在 210 毫秒内达到约 1K IOPS,并以 281,562 IOPS 的峰值达到 2.83 毫秒的延迟。
接下来是我们的 Oracle 工作负载:Oracle、Oracle 90-10 和 Oracle 80-20。 对于 Oracle,启用 DR 的版本在 1 毫秒上下波动,并在 264 毫秒时达到约 3.7K IOPS 的峰值,然后略有下降。 非 DR 版本在大约 250K IOPS 之前具有亚毫秒级延迟,并在 314,954 毫秒时达到 3.17 IOPS 的峰值。
SQL 90-10 看到启用 DR 的版本保持在 1 毫秒以下,直到大约 225K IOPS,峰值为 252,034 IOPS,延迟为 2.44 毫秒。 非 DR 在大约 300K IOPS 之前具有亚毫秒级延迟性能,峰值为 338,146 IOPS,延迟为 1.72ms。
使用 SQL 80-20 时,DR 版本在 1 毫秒左右出现一些波动,并以 225,327 IOPS 的峰值达到 2.64 毫秒的延迟。 非 DR 版本在大约 211K IOPS 之前具有亚毫秒延迟,并在 278,051 IOPS 和 2ms 延迟时达到峰值。
接下来,我们切换到我们的 VDI 克隆测试,完整和链接。 对于 VDI 完整克隆 (FC) 启动,两种配置的启动时间均低于 1 毫秒,DR 版本以约 85K IOPS 的速度超过亚毫秒延迟,并以 250,209 IOPS 和 4.04 毫秒的延迟达到峰值。 非 DR 版本保持在 1 毫秒以下,直到大约 200K IOPS 并达到 283,786 IOPS 的峰值和 3.31 毫秒的延迟,然后略有下降。
使用 VDI FC 初始登录时,DR 版本在 129 毫秒时达到约 4.2K IOPS 的峰值,然后显着降低性能并显着增加延迟。 非 DR 版本开始时低于 1 毫秒,一直保持到大约 75K IOPS,峰值为 139,401 IOPS,延迟为 6.3 毫秒,略有下降。
VDI FC Monday Login 的 DR 版本开始时不到 1 毫秒,但很快就超过了它并达到 108,611 IOPS 的峰值,延迟为 2.22 毫秒。 非 DR 版本保持在 1 毫秒以下,直到略低于 90K IOPS,并达到 152,516 IOPS 的峰值,延迟为 3.25 毫秒。
对于 VDI LC 启动,两种配置都在 1 毫秒以下启动,DR 立即弹出,并在 214,327 毫秒延迟时达到 2.34 IOPS 的峰值。 非 DR 版本保持在 1 毫秒以下,直到大约 205K IOPS,并达到 255,235 IOPS 的峰值和 1.85 毫秒的延迟。
VDI LC 初始登录看到 DR 版本的峰值约为 95K IOPS,延迟为 2.2 毫秒,然后显着下降。 非 DR 版本保持在 1 毫秒以下,直到大约 65K IOPS,并在 112,182 毫秒的延迟时达到 2.23 IOPS 的峰值。
最后,VDI LC Monday Login 绘制了与上面类似的图片,DR 版本峰值约为 108K IOPS,延迟约为 3.7 毫秒,然后下降了很多。 非 DR 版本在大约 65K IOPS 之前具有亚毫秒延迟,并在 126,656 毫秒的延迟时达到 3.91 IOPS 的峰值。
结语
Western Digital Ultrastar DC SN630 是新的数据中心 NVMe SSD,有两种类型:以读取为中心和混合使用。 这些驱动器的容量范围为混合用途的 800GB-6.4TB 和以读取为中心的 960GB-7.68TB。 该驱动器利用了 Western Digital 的控制器、固件和 64 层 BiCS 3D NAND。 所有驱动器均提供 ISE,非常适合重新部署或报废。 另一个安全功能是使用带有 RSA 身份验证的安全固件下载,以确保 SN630 仅运行正版固件。 由于 SN630 通过了 vSAN 认证,我们在 VMware vSAN 环境中对其进行了测试,以了解其性能。
为了提高性能,我们通过应用程序工作负载分析和 VDBench 工作负载分析运行了 Western Digital DC SN630 NVMe SSD。 对于应用程序工作负载分析,驱动器提供了一些不错的数字。 在 SQL Server 中,SN630 的总事务得分为 12,610.3 TPS,总平均延迟为 14.8 毫秒。 使用 Sysbench,SN630 达到 11,739.7 TPS,平均延迟为 21.86 毫秒,在我们最坏的情况下,驱动器给我们的总分是 38.71 毫秒。
在我们的 VDBench 工作负载中,我们测试了 DR 打开和关闭的驱动器。 显然,关闭 DR 会带来更好的性能,但是,一些客户需要运行 DR,最好了解驱动器在 DR 开启时的性能。 DR 关闭的亮点包括 442K 读取中的 4K IOPS、196K 写入中的 4K IOPS、9.98K 读取中的 64GB/s 和 4K 写入中的 64GB/s。 在我们的 SQL 工作负载中,我们看到 359K IOPS、SQL 335-90 中的 10K IOPS 和 SQL 282-80 中的 20K IOPS。 对于 Oracle,我们看到峰值性能高达 315K IOPS、Oracle 338-90 中的 10K IOPS 和 Oracle 278-80 中的 20K IOPS。 在我们的 VDI 克隆测试中,SN630 在启动时为我们提供了 284K IOPS,在初始登录中为我们提供了 139K IOPS,在完整克隆的星期一登录中为我们提供了 153K IOPS。 在链接克隆中,SN630 启动时达到 255K IOPS,初始登录时达到 112K IOPS,周一登录时达到 127K IOPS。
对于启用 DR 的 VDBench 工作负载,SN630 的亮点是 388K 读取 4K IOPS、183K 写入 4K IOPS、8.3K 读取 64GB/s 和 1.4K 写入 64GB/s。 在我们的 SQL 工作负载中,我们看到 350K IOPS,SQL 283-90 中的 10K IOPS,以及 SQL 257-80 中的 20K IOPS。 对于 Oracle,我们看到峰值性能高达 264K IOPS,Oracle 252-90 为 10K IOPS,Oracle 225-80 为 20K IOPS。 在我们的 VDI 克隆测试中,SN630 在启动时为我们提供了 220K IOPS,在初始登录中为我们提供了 129K IOPS,在完整克隆的星期一登录中为我们提供了 109K IOPS。 在链接克隆中,SN630 启动时达到 214K IOPS,初始登录时达到 95K IOPS,周一登录时达到 108K IOPS。
在 VMware vSAN 中使用时,Western Digital DC SN630 SSD 即使在启用 DR 的情况下也能提供令人印象深刻的性能。 在这种情况下,我们利用了适度的服务器构建,但仍然看到了令人印象深刻的结果。 对于那些使用 vSAN 的用户来说,SN630 是一个不错的选择。
*本评论所依据的性能测试由 Western Digital 委托进行