2.3. 规划节点硬件配置¶
Acronis Cyber Infrastructure 在商用硬件上工作,这样您可以从常规服务器、磁盘和网卡创建簇。为了达到最优性能,仍必须满足许多要求,并应遵循大量建议。
注解
如果不确定选择哪个硬件,请咨询销售代表。还可以使用在线硬件计算器。如果要避免进行测试、安装和配置硬件和/或软件的麻烦,请考虑使用 Acronis Appliance。开箱即用,您将获得企业级容错五节点基础架构解决方案,该方案提供在 3U 形式因素下运行的出色存储性能。
2.3.1. 硬件限制¶
下表列出了 Acronis Cyber Infrastructure 服务器的当前硬件限制:
硬件 |
理论 |
已认证 |
---|---|---|
RAM |
64 TB |
1 TB |
CPU |
5120 个逻辑 CPU |
384 个逻辑 CPU |
在多核心(多线程)处理器中,逻辑 CPU 是核心(线程)。
2.3.2. 硬件要求¶
下表根据磁盘角色列出了最低和推荐的磁盘要求(请参阅 存储架构概述):
磁盘角色 |
数量 |
最小值 |
推荐 |
---|---|---|---|
系统 |
每个节点一个磁盘 |
100 GB SATA/SAS HDD |
250 GB SATA/SAS SSD |
元数据 |
每个节点一个磁盘 一个簇建议使用五个磁盘 |
100 GB 企业级 SSD,具有断电保护功能,最低 1 DWPD 耐久性 |
|
缓存 |
可选 每 4-12 个 HDD 一个 SSD 磁盘 |
100+ GB 企业级 SSD,具有断电保护功能,每个服务 HDD 具有 75 MB/s 连续写入性能; 最低 1 DWPD 耐力,建议 10 DWPD |
|
存储器 |
可选 每个簇至少一个 |
建议至少 100 GB,最多 16 TB SATA/SAS HDD 或 SATA/SAS/NVMe SSD(企业级,具有断电保护功能,最低 1 DWPD 耐久性) |
下表根据您将使用的服务列出了一个节点建议的 RAM 和 CPU 核心数量:
服务 |
RAM |
CPU 核心* |
|
---|---|---|---|
系统 |
6 GB |
2 个核心 |
|
存储服务:每个具有存储角色或缓存角色的磁盘(任意大小)** |
1 GB |
0.2 个核心 |
|
计算 |
8 GB |
3 个核心 |
|
负载均衡器 |
服务 |
1 GB |
1 个核心 |
每个负载均衡器 |
1 GB |
1 个核心 |
|
Kubernetes |
2 GB |
2 个核心 |
|
S3 |
4.5 GB |
3 个核心 |
|
Backup Gateway*** |
1 GB |
2 个核心 |
|
NFS |
服务 |
4 GB |
2 个核心 |
每个共享 |
0.5 GB |
0.5 个核心 |
|
iSCSI |
服务 |
1 GB |
1 个核心 |
每个卷 |
0.1 GB |
0.5 个核心 |
* 64 位 x86 AMD-V 或 Intel VT 处理器,已启用硬件虚拟化扩展。对于 Intel 处理器,请在 BIOS 中使用“扩展页表”启用“不受限制的来宾”和 VT-x。建议在每个节点上有相同的 CPU 型号,以避免 VM 实时迁移问题。此处的 CPU 核心是多核处理器中的物理核心(不考虑超线程)。
** 对于大于 1 PB 物理空间的簇,请为每个元数据服务另外添加 0.5 GB RAM。
*** 使用公共云和 NFS 时,Backup Gateway 消耗的 RAM 和 CPU 与本地存储一样多。
对于网络,建议至少使用 2 x 10 GbE 接口;25 GbE、40 GbE 和 100 GbE 更好。建议绑定。但是,您可以从1 GbE 链接开始,不过它们可能会限制基于现代负载的簇吞吐量。
让我们考虑一些示例,并计算特定案例的要求。
如果您有 1 个节点(1 个系统磁盘和 4 个存储磁盘)并想将其用于 Backup Gateway,则该节点应满足以下要求:系统要求(6 GB,2 个核心)+ 4 个磁盘(4 GB,0.8 个核心)用于存储服务 + Backup Gateway(1 GB,2 个核心)。总而言之,该节点有 11 GB 的 RAM 和 5 个核心。
如果您有 3 个节点(1 个系统磁盘和 4 个存储磁盘)并想将它们用于计算服务,则每个群集节点应满足以下要求:系统要求(6 GB,2 个核心)+ 计算(8 GB,3 个核心)。总而言之,该节点有 14 GB 的 RAM 和 5 个核心。例如,如果要启用一个 Kubernetes VM 和一个负载均衡器,则将以下要求添加到管理节点:负载均衡器(2 GB,2 个核心)+ Kubernetes(2 GB,2 个核心)。总而言之,该管理节点有 18 GB 的 RAM 和 9 个核心。
如果您有 5 个节点(2 个系统磁盘和 10 个存储磁盘)并想将它们用于 Backup Gateway,则每个群集节点应满足以下要求:系统要求(6 GB,2 个核心)+ 10 个磁盘(10 GB,2 个核心)用于存储服务 + Backup Gateway(1 GB,2 个核心)。总而言之,每个有 17 GB 的 RAM 和 6 个核心。
通常,您为簇提供的资源越多,它的运行效果就越好。所有额外的 RAM 用于缓存磁盘读取内容。额外的 CPU 核心可提高性能并降低延迟。
2.3.3. 硬件建议¶
通常,Acronis Cyber Infrastructure 在与为 Red Hat Enterprise Linux 7 建议的相同硬件上工作,包括 AMD EPYC 处理器:服务器,组件。
以下建议进一步解释了由硬件需求表中的特定硬件添加的优势。使用它们以最优方式配置簇。
2.3.3.1. 存储簇构成建议¶
设计高效的存储簇意味着在适合您用途的性能和成本之间找到折中。在规划时,记住具有许多节点和每个节点少量磁盘的簇会提供更高的性能,而具有最少数量的节点 (3) 和每个节点大量磁盘的簇更便宜。请参见下表获取更多详细信息。
设计注意事项 |
最少的节点 (3),每个节点许多磁盘 |
许多节点,每个节点少量磁盘,每个节点少量磁盘(全闪存配置) |
---|---|---|
最优化 |
成本更低。 |
性能更高。 |
要保留的空闲磁盘空间 |
为簇重建保留更多的空间,因为较少的运行正常的节点将必须存储来自故障节点的数据。 |
为簇重建保留更少的空间,因为较多的运行正常的节点将必须存储来自故障节点的数据。 |
冗余 |
更少的擦除编码选择。 |
更多的擦除编码选择。 |
簇均衡和重建性能 |
更差的均衡和更慢的重建。 |
更好的均衡和更快的重建。 |
网络容量 |
在重建期间需要更多的网络带宽来维持簇性能。 |
在重建期间需要更少的网络带宽来维持簇性能。 |
有利的数据类型 |
冷数据(例如,备份)。 |
热数据(例如,虚拟环境)。 |
服务器配置样本 |
Supermicro SSG-6047R-E1R36L(Intel Xeon E5-2620 v1/v2 CPU、32GB RAM、36 x 12TB HDD、500GB 系统磁盘)。 |
Supermicro SYS-2028TP-HC0R-SIOM(4 个 Intel E5-2620 v4 CPU、4 个 16GB RAM、24 个 1.9TB Samsung PM1643 SSD)。 |
注意以下内容:
这些注意事项仅在故障域是主机时适用。
在复制模式下的重建速度与簇中节点的数量无关。
Acronis Cyber Infrastructure 支持每节点数百个磁盘。如果计划使用每节点超过 36 个磁盘,请联系销售工程师,他们将帮助您设计更高效的簇。
2.3.3.2. 一般硬件建议¶
对于生产环境,至少需要五个节点。这可确保在两个节点出现故障时,簇仍能正常工作而不会丢失数据。
Acronis Cyber Infrastructure 的最强大功能之一是可扩展性。簇越大,Acronis Cyber Infrastructure 运行得就越好。建议从至少十个节点创建生产簇,以便在生产场景中改进弹性、性能和容错。
即使可以在不同的硬件上创建簇,但在每个节点上使用具有相似硬件的节点将产生更好的簇性能、容量和整体均衡。
任何簇基础架构在部署到生产之前,必须经过广泛测试。类似 SSD 驱动器的常见故障点和网络适配器绑定必须始终完全经过验证。
不建议在具有其自己的冗余机制的 SAN/NAS 硬件上为生产运行 Acronis Cyber Infrastructure。这样做可能对性能和数据可用性产生不利影响。
要达到最佳性能,请保留至少 20% 的可用簇容量。
在灾难恢复期间,Acronis Cyber Infrastructure 可能需要额外的磁盘空间用于复制。确保保留至少与任意单个存储节点具有的空间数量相同的空间。
建议在每个节点上有相同的 CPU 型号,以避免 VM 实时迁移问题。有关更多详细信息,请参阅 Administrator’s Command Line Guide。
如果计划在云中使用 Backup Gateway 存储备份,则确保本地存储簇有大量逻辑空间用于分层存储(在将备份发送到云之前,本地保留备份)。例如,如果执行每日备份,请为至少 1.5 天的备份提供足够的空间。有关更多详细信息,请参阅 Administrator’s Guide。
如果受硬件支持,建议使用 UEFI 而不是 BIOS。尤其当使用 NVMe 驱动器时。
2.3.3.3. 存储硬件建议¶
可以在相同的簇中使用不同大小的磁盘。但要记住,对于相同的 IOPS,较小的磁盘会比较大的磁盘提供更高的每 TB 数据性能。建议在相同层中将具有每 TB 的相同 IOPS 的磁盘编组在一起。
使用建议的 SSD 型号可能有助于避免数据丢失。并不是所有 SSD 驱动器都能够承受企业工作负载,并可能在操作的前几个月中中断,导致 TCO 猛增。
SSD 内存单元可承受有限数量的重写。SSD 驱动器应作为消费品来看待,您需要在特定时间后更换。消费级 SSD 驱动器可承受非常少的重写(实际上,数量非常低,以至于这些数量并没有显示在技术规范中)。旨在用于存储簇的 SSD 驱动器必须提供至少 1 DWPD 的耐久性(建议 10 DWPD)。耐久性越高,需要更换 SSD 的次数就越少,从而提高 TCO。
许多消费级 SSD 驱动器可以忽略磁盘刷新,并误报给操作系统数据已写入,但实际上并未写入。此类驱动器的示例包括 OCZ Vertex 3、Intel 520、Intel X25-E 和 Intel X-25-M G2。已经知道这些驱动器在数据提交方面不安全,它们不应当用于数据库,而且在出现电源故障时,它们可能轻易损坏文件系统。出于这些原因,请使用遵守刷新规则的企业级 SSD 驱动器(有关详细信息,请参阅 http://www.postgresql.org/docs/current/static/wal-reliability.html)。正常运作的企业级 SSD 驱动器在其技术规范中通常具有断电保护属性。此技术的一些市场名称有增强的电源丢失数据保护 (Intel)、缓存电源保护 (Samsung)、电源故障支持 (Kingston)、完全电源故障保护 (OCZ)。
强烈建议检查磁盘的数据刷新功能,如 检查磁盘数据刷新功能 中所述。
消费级 SSD 驱动器通常具有不稳定的性能,而且不适于承受可持续的企业工作负载。出于此原因,在选择 SSD 时,请注意可持续的负载测试。我们推荐以下企业级 SSD 驱动器,它们在性能、耐久性和投资方面是最佳的:Intel S3710、Intel P3700、Huawei ES3000 V2、Samsung SM1635 和 Sandisk Lightning。
SSD 磁盘的性能可能取决于其大小。较低容量的驱动器(100 至 400 GB)比较高容量的驱动器(1.9 至 3.8 TB)可能慢很多。在购买硬件之前,先咨询驱动器性能和耐久性规范。
将 NVMe 或 SAS SSD 用于写缓存可提高随机 I/O 性能,并强烈建议用于所有具有高度随机访问的所有工作负载(例如,iSCSI 卷)。反之,SATA 磁盘最适用于仅 SSD 的配置但不适用于写缓存。
强烈建议不要使用叠瓦式磁记录 (SMR) HDD,即使对于备份场景。此类磁盘具有不可预测的延迟,可能导致意外的临时服务中断和突然的性能降级。
在 SSD 上运行元数据服务可提高簇性能。还为了最大程度地降低 CAPEX,相同的 SSD 可用于写缓存。
如果容量是主要目标,而且您需要存储不常访问的数据,请选择SATA 磁盘而不是 SAS 磁盘。如果性能是主要目标,则选择 NVMe 或 SAS 磁盘而不是 SATA 磁盘。
每个节点的磁盘越多,CAPEX 越低。例如,从每个节点有两个磁盘的十个节点创建的簇将比每个节点有一个磁盘的二十个节点创建的簇便宜。
将具有一个 SSD 的 SATA HDD 用于缓存比仅使用无此类 SSD 的SAS HDD 更经济高效。
使用 RAID 或 HBA 控制器分别为系统磁盘创建硬件或软件 RAID1 卷,以确保其高性能和可用性。
使用 HBA 控制器,因为它们比 RAID 控制器更便宜而且更易于管理。
为 SSD 驱动器禁用所有 RAID 控制器缓存。现代 SSD 有良好的性能,但可被 RAID 控制器的写和读缓存降低。建议禁用 SSD 驱动器的缓存,并保留仅为 HDD 驱动器启用它。
如果使用 RAID 控制器,则不要从用于存储的 HDD 创建 RAID 卷。每个存储 HDD 需要由 Acronis Cyber Infrastructure 识别为单独的设备。
如果使用具有缓存的 RAID 控制器,则配备备份电池单元 (BBU) 以防在电源中断时缓存丢失。
磁盘块大小(例如 512b 或 4K)并不重要,并且对性能没有影响。
2.3.3.4. 网络硬件推荐¶
为内部和公共流量使用单独的网络(尽管是可选的,但最好是单独的网络适配器)。这样做将阻止公共流量影响簇 I/O 性能,还会阻止可能来自外部的服务拒绝攻击。
网络延迟会大大降低簇性能。使用具有低延迟链路的高质量网络设备。不要使用消费级网络交换机。
不要使用桌面网络适配器,比如 Intel EXPI9301CTBLK 或 Realtek 8129,因为它们不是针对高负载而设计的,而且可能不支持全双工链路。还使用非阻止的以太网交换机。
要避免入侵,Acronis Cyber Infrastructure 应位于不可从外部访问的专用内部网络上。
节点上有两个 HDD ,每个使用一个 1 Gbit/s 链路(上入)。对于节点上的一个或两个 HDD,仍建议将两个绑定网络接口用于高网络可用性。此建议的原因是,1 Gbit/s 以太网网络可以提供 110-120 MB/s 的吞吐量,这接近于单个磁盘的序列 I/O 性能。因为服务器上的多个磁盘比单个 1 Gbit/s 以太网链路提供更高的吞吐量,因此网络可能成为一个瓶颈。
要获得最高的序列 I/O 性能,请每个硬盘使用一个 1Gbit/s 链路,或每个节点一个 10Gbit/s 链路。即使 I/O 操作在实际场景中经常是随机的,但序列 I/O 在备份场景中很重要。
要获得最高的整体性能,请每个节点使用一个 10 Gbit/s 链路(或者两个绑定用于高网络可用性)。
不建议配置 1 Gbit/s 网络适配器来使用非默认的 MTU(例如 9000 字节的巨型帧)。此类设置需要其他交换机配置,并经常导致人为错误。另一方面,需要配置 10+ Gbit/s 网络适配器以使用巨型帧,从而达到最高性能。
当前支持的光纤通道主机总线适配器 (HBA) 是 QLogic QLE2562-CK 和 QLogic ISP2532。
建议使用 Mellanox ConnectX-4 和 ConnectX-5 InfiniBand 适配器。Mellanox ConnectX-2 和 ConnectX-3 卡不受支持。
不建议使用 BNX2X 驱动程序的适配器,例如 Broadcom Limited BCM57840 NetXtreme II 10/20-Gigabit Ethernet/HPE FlexFabric 10Gb 2-port 536FLB Adapter。它们会将 MTU 限制为 3616,这会影响簇性能。
2.3.4. 硬件和软件限制¶
硬件限制:
每个管理节点必须至少有两个磁盘(一个系统+元数据,一个存储)。
每个计算或存储节点必须至少有三个磁盘(一个系统,一个元数据,一个存储)。
要测试产品的所有功能,需要三个服务器。
系统磁盘必须至少有 100 GB 的空间。
管理面板需要全高清监视器以便正确显示。
受支持的最高物理分区大小为 254 TiB。
软件限制:
一个节点可以仅是一个簇的一部分。
仅可以在存储簇上创建一个 S3 簇。
在管理面板中仅可使用预定义的冗余模式。
始终为所有数据启用精简配置,否则无法配置。
管理面板已经过测试,以便在以下 Web 浏览器中以 1280x720 及更高的分辨率工作:最新的 Firefox、Chrome、Safari。
有关网络限制,请参阅 网络限制。
2.3.5. 最低存储配置¶
在表中描述的最低配置将使您评估存储簇的功能。它不是针对生产的。
节点号 |
第 1 个磁盘角色 |
第 2 个磁盘角色 |
第 3 个及以上磁盘角色 |
访问点 |
---|---|---|---|---|
1 |
系统 |
元数据 |
存储器 |
iSCSI、S3 专用、S3 公共、NFS、Backup Gateway |
2 |
系统 |
元数据 |
存储器 |
iSCSI、S3 专用、S3 公共、NFS、Backup Gateway |
3 |
系统 |
元数据 |
存储器 |
iSCSI、S3 专用、S3 公共、NFS、Backup Gateway |
共 3 个节点 |
|
共 3 个 MDS |
共超过 3 个 CS |
访问点服务共在三个节点上运行。 |
注解
可以为 SSD 磁盘同时指派系统、元数据和缓存角色,从而为存储角色释放更多磁盘。
即使为最低的配置建议使用三个节点,也可以开始评估仅有一个节点的 Acronis Cyber Infrastructure,并在以后添加更多节点。存储簇必须至少有一个运行的元数据服务和一个区块服务。单节点安装将让您评估类似 iSCSI、Backup Gateway 等服务。但此类配置将有两个主要限制:
只有一个 MDS 将是单一故障点。如果失败,整个簇将停止工作。
只有一个 CS 将能够仅存储一个区块副本。如果失败,数据将丢失。
重要
如果在单个节点上部署 Acronis Cyber Infrastructure,则必须使其存储持久且冗余,以避免数据丢失。如果节点是物理的,则必须有多个磁盘,这样可以在磁盘之间复制数据。如果节点是虚拟机,则确保从中运行 VM 的解决方案使此 VM 高度可用。
注解
Backup Gateway 以分层存储模式使用本地对象存储。这表示要复制、迁移或上传到公共云的数据将首先本地存储,仅在此之后发送到目标。本地对象存储持续且冗余很重要,以便本地数据不会丢失。有多种方法可确保本地存储的持续和冗余。可以在多个节点上部署 Backup Gateway 并选择一种好的冗余模式。如果网关部署在 Acronis Cyber Infrastructure 中的单个节点上,可通过在多个本地磁盘之间复制它来使存储冗余。如果整个 Acronis Cyber Infrastructure 安装都部署在单个虚拟机上,其唯一目的是创建网关,则确保从中运行 VM 的解决方案使此 VM 高度可用。
2.3.6. 建议的存储配置¶
建议至少有五个元数据服务,以确保在两个节点同时发生故障时,簇可正常运行而无数据丢失。以下配置将帮助您为生产环境创建簇:
节点号 |
第 1 个磁盘角色 |
第 2 个磁盘角色 |
第 3 个及以上磁盘角色 |
访问点 |
---|---|---|---|---|
节点 1 至 5 |
系统 |
SSD;元数据,缓存 |
存储器 |
iSCSI、S3 专用、S3 公共、Backup Gateway |
节点 6+ |
系统 |
SSD;缓存 |
存储器 |
iSCSI、S3 专用、Backup Gateway |
共超过 5 个节点 |
|
共 5 个 MDS |
共超过 5 个 CS |
所有节点运行所需的访问点。 |
可以只从具有建议硬件的五个节点创建可用于生产的簇。但是,如果打算通过直连存储 (DAS) 或改进的恢复时间实现显著的性能优势,则建议至少使用十个节点进入生产。
下面是可以用在生产中的一些更具体的配置示例。每种配置可以通过添加区块服务器和节点进行扩展。
2.3.6.1. 仅 HDD¶
此基本配置需要专用磁盘用于每个元数据服务器。
节点 1-5(基本) |
节点 6+(扩展) |
||||
---|---|---|---|---|---|
磁盘号 |
磁盘类型 |
磁盘角色 |
磁盘号 |
磁盘类型 |
磁盘角色 |
1 |
硬盘 |
系统 |
1 |
硬盘 |
系统 |
2 |
硬盘 |
MDS |
2 |
硬盘 |
CS |
3 |
硬盘 |
CS |
3 |
硬盘 |
CS |
… |
… |
… |
… |
… |
… |
N |
硬盘 |
CS |
N |
硬盘 |
CS |
2.3.6.2. HDD + 系统 SSD(无缓存)¶
此配置适用于创建以容量为导向的簇。
节点 1-5(基本) |
节点 6+(扩展) |
||||
---|---|---|---|---|---|
磁盘号 |
磁盘类型 |
磁盘角色 |
磁盘号 |
磁盘类型 |
磁盘角色 |
1 |
SSD |
系统,MDS |
1 |
SSD |
系统 |
2 |
硬盘 |
CS |
2 |
硬盘 |
CS |
3 |
硬盘 |
CS |
3 |
硬盘 |
CS |
… |
… |
… |
… |
… |
… |
N |
硬盘 |
CS |
N |
硬盘 |
CS |
2.3.6.3. HDD + SSD¶
此配置适用于创建以性能为导向的簇。
节点 1-5(基本) |
节点 6+(扩展) |
||||
---|---|---|---|---|---|
磁盘号 |
磁盘类型 |
磁盘角色 |
磁盘号 |
磁盘类型 |
磁盘角色 |
1 |
硬盘 |
系统 |
1 |
硬盘 |
系统 |
2 |
SSD |
MDS,缓存 |
2 |
SSD |
缓存 |
3 |
硬盘 |
CS |
3 |
硬盘 |
CS |
… |
… |
… |
… |
… |
… |
N |
硬盘 |
CS |
N |
硬盘 |
CS |
2.3.6.4. 仅 SSD¶
此配置不需要 SSD 用于缓存。
当选择硬件用于此配置时,记住以下事项:
每个 Acronis Cyber Infrastructure 客户端都能够从簇获取最高约 40K 的可持续 IOPS(读 + 写)。
如果使用擦除编码冗余方案,每个擦除编码文件(例如,单个 VM HDD 磁盘)将获取最高 2K 的可持续 IOPS。即,在 VM 内工作的用户在其处理中每个虚拟 HDD 将有最高 2K 的可持续 IOPS。节点上的多个 VM 可以利用更多 IOPS,最高可达客户端的限制。
在此配置中,网络延迟定义超过一半的整体性能,因此要确保网络延迟是最小的。一种建议是在簇中的任意两个节点之间有一个 10Gbps 交换机。
节点 1-5(基本) |
节点 6+(扩展) |
||||
---|---|---|---|---|---|
磁盘号 |
磁盘类型 |
磁盘角色 |
磁盘号 |
磁盘类型 |
磁盘角色 |
1 |
SSD |
系统,MDS |
1 |
SSD |
系统 |
2 |
SSD |
CS |
2 |
SSD |
CS |
3 |
SSD |
CS |
3 |
SSD |
CS |
… |
… |
… |
… |
… |
… |
N |
SSD |
CS |
N |
SSD |
CS |
2.3.6.5. HDD + SSD(无缓存),2 层¶
在此配置示例中,第 1 层用于无缓存的 HDD,而第 2 层用于 SSD。第 1 层可存储冷数据(例如备份),第 2 层可存储热数据(例如,高性能虚拟机)。
节点 1-5(基本) |
节点 6+(扩展) |
||||||
---|---|---|---|---|---|---|---|
磁盘号 |
磁盘类型 |
磁盘角色 |
级 |
磁盘号 |
磁盘类型 |
磁盘角色 |
级 |
1 |
SSD |
系统,MDS |
1 |
SSD |
系统 |
||
2 |
SSD |
CS |
2 |
2 |
SSD |
CS |
2 |
3 |
硬盘 |
CS |
1 |
3 |
硬盘 |
CS |
1 |
… |
… |
… |
… |
… |
… |
… |
… |
N |
HDD/SSD |
CS |
1/2 |
N |
HDD/SSD |
CS |
1/2 |
2.3.6.6. HDD + SSD,3 层¶
在此配置示例中,第 1 层用于无缓存的 HDD,第 2 层用于有缓存的 HDD,第 3 层用于 SSD。第 1 层可存储冷数据(例如备份),第 2 层可存储常规虚拟机,第 3 层可存储高性能虚拟机。
节点 1-5(基本) |
节点 6+(扩展) |
||||||
---|---|---|---|---|---|---|---|
磁盘号 |
磁盘类型 |
磁盘角色 |
级 |
磁盘号 |
磁盘类型 |
磁盘角色 |
级 |
1 |
HDD/SSD |
系统 |
1 |
HDD/SSD |
系统 |
||
2 |
SSD |
MDS,T2 缓存 |
2 |
SSD |
T2 缓存 |
||
3 |
硬盘 |
CS |
1 |
3 |
硬盘 |
CS |
1 |
4 |
硬盘 |
CS |
2 |
4 |
硬盘 |
CS |
2 |
5 |
SSD |
CS |
3 |
5 |
SSD |
CS |
3 |
… |
… |
… |
… |
… |
… |
… |
… |
N |
HDD/SSD |
CS |
1/2/3 |
N |
HDD/SSD |
CS |
1/2/3 |
2.3.7. 原始磁盘空间注意事项¶
当规划基础架构时,记住以下事项以避免混淆:
HDD 和 SSD 的容量是使用十进制而不是二进制前缀测量和指定的,因此磁盘规范中的“TB”通常表示“太字节”。但操作系统使用二进制前缀显示驱动器容量,即“TB”表示“百万兆”,这是一个大得多的数字。因此,显示的磁盘容量可能小于供应商所售的容量。例如,在规范中有 6TB 的磁盘可能在 Acronis Cyber Infrastructure 中显示为有 5.45 TB 的实际磁盘空间。
保留 5% 的磁盘空间用于紧急需要。
因此,如果将 6TB 磁盘添加到簇,则可用的物理空间应增加约 5.2 TB。
2.3.8. 检查磁盘数据刷新功能¶
强烈建议确保计划包含在簇中的所有存储设备都可以在电源意外中断时,将数据从缓存中刷新到磁盘。这样,您将找到可能在电源故障时丢失数据的设备。
Acronis Cyber Infrastructure 附带 vstorage-hwflush-check
工具,该工具检查在紧急情况下存储设备如何将数据刷新到磁盘。该工具作为客户端/服务器实用程序实施:
客户端持续将数据块写入到存储设备。写入数据块时,客户端将增加一个特殊的计数器,并将其发送到保留它的服务器上。
服务器跟踪从客户端传入的计数器,并始终知道下一个计数器数字。如果服务器收到的计数器小于它所拥有的计数器(例如,由于电源发生故障以及存储设备未将缓存的数据刷新到磁盘),服务器将报告错误。
要检查存储设备在发生电源故障时是否能够将数据成功刷新到磁盘,请遵循以下步骤:
在一个节点上,运行服务器:
# vstorage-hwflush-check -l
在托管想要测试的存储设备的不同节点上,运行客户端,例如:
# vstorage-hwflush-check -s vstorage1.example.com -d /vstorage/stor1-ssd/test -t 50
其中:
vstorage1.example.com
是服务器的主机名。/vstorage/stor1-ssd/test
是用于数据刷新测试的目录。在执行期间,客户端在此目录中创建文件并将数据块写入该文件。50
是客户端将数据写入磁盘的线程数。每个线程有其自己的文件和计数器。可以增加线程数(最大为 200)以在更严苛的条件下测试系统。在运行客户端时,还可以指定其他选项。有关可用选项的更多信息,请参阅vstorage-hwflush-check
手册页。
至少等待 10-15 秒,从客户端节点切断电源(按下电源按钮或拔出电源线),然后重新打开电源。
重新启动客户端:
# vstorage-hwflush-check -s vstorage1.example.com -d /vstorlage/stor1-ssd/test -t 50
启动后,客户端将读取所有以前写入的数据、确定磁盘上数据的版本,并从最后一个有效的计数器重新启动测试。然后,它将此有效计数器发送到服务器,服务器将其与最新的计数器进行比较。您看到的输出可能类似于:
id<N>:<counter_on_disk> -> <counter_on_server>
它表示以下其中一项:
如果磁盘上的计数器低于服务器上的计数器,则存储设备无法将数据刷新到磁盘。避免在生产中使用此存储设备,尤其对于 CS 或日志,因为您会有丢失数据的风险。
如果磁盘上的计数器高于服务器上的计数器,则存储设备已将数据刷新到磁盘,但客户端无法将其报告给服务器。对于设置的载入线程数,网络可能太慢或者存储设备可能太快,因此考虑增加线程数。此存储设备可以用在生产中。
如果两个计数器相等,则存储设备已将数据刷新到磁盘,并且客户端已将其报告给服务器。此存储设备可以用在生产中。
慎重起见,请重复该过程几次。在检查了第一个存储设备后,继续检查计划用在簇中的所有剩余设备。需要测试计划用在簇中的所有设备:用于 CS 日志的 SSD 磁盘,用于 MDS 日志和区块服务器的磁盘。