大家好！ 通过这篇文章，AERODISK 开设了 Habré 博客。 万岁，同志们！
Habré 之前的文章讨论了有关存储系统的架构和基本配置的问题。 在本文中，我们将考虑一个以前未涉及但经常被问到的问题 - 关于 AERODISK ENGINE 存储系统的容错能力。 我们的团队将尽一切努力确保 AERODISK 存储系统停止工作，即停止工作。 打破它。
碰巧，关于我们公司的历史、我们的产品以及成功实施示例的文章已经挂在 Habré 上，为此 非常感谢我们的合作伙伴 - TS Solution 和 Softline 公司。
因此，我不会在这里训练复制粘贴管理技能，而只是提供这些文章原文的链接：
我也想分享一个好消息。 当然，我将从问题开始。 作为一个年轻的供应商，我们经常面临这样一个事实：许多工程师和管理员根本不知道如何正确操作我们的存储系统。
显然，从管理员的角度来看，管理大多数存储系统看起来大致相同，但每个制造商都有自己的特点。 我们这里也不例外。
因此，为了简化IT专家的培训任务，我们决定今年致力于免费教育。 为此，我们在俄罗斯的许多大城市开设了 AERODISK 能力中心网络，任何感兴趣的技术专家都可以完全免费参加课程，并获得管理 AERODISK ENGINE 存储系统的证书。
在每个能力中心，我们将安装一个完整的 AERODISK 存储系统演示台和一台物理服务器，我们的老师将在上面进行面对面的培训。 我们将在能力中心出现后公布其工作时间表，但我们已经在下诺夫哥罗德开设了一个中心，下一个是克拉斯诺达尔市。 您可以使用下面的链接报名参加培训。 以下是目前已知的有关城市和日期的信息：
- 下诺夫哥罗德 （已经开放 – 您可以在这里注册 );
16年2019月16日前，任何工作时间均可来中心参观，2019年XNUMX月XNUMX日将组织大型培训课程。 - 克拉斯诺达尔 （即将开放 - 您可以在这里注册 );
9年25月2019日至25月2019日，您可以在任何工作时间来中心参观，XNUMX年XNUMX月XNUMX日将组织大型培训课程。 - 叶卡捷琳堡 （即将开放，请关注我们网站或 Habré 上的信息）；
2019 年 XNUMX 月至 XNUMX 月。 - 新西伯利亚 （遵循我们网站或 Habré 上的信息）；
2019年XNUMX月 - 克拉斯诺亚尔斯克 （遵循我们网站或 Habré 上的信息）；
2019 年 XNUMX 月。
当然，如果莫斯科离您不远，那么您可以随时访问我们在莫斯科的办公室并接受类似的培训。
全部。 我们已经完成了营销，让我们转向技术吧！
在 Habré 上，我们将定期发布有关我们的产品、负载测试、比较、使用功能和有趣的实现的技术文章。
AERODISK ENGINE N2存储系统碰撞测试、强度测试
警告！ 读完这篇文章后，您可以说：好吧，当然，供应商会自我检查，以便一切都“顺利”、温室条件等。 我会回答：没有那样的！ 与我们的外国竞争对手不同，我们位于这里，离您很近，您可以随时来找我们（在莫斯科或任何中央委员会）并以任何方式测试我们的存储系统。 因此，将结果调整为理想的世界图景对我们来说没有多大意义，因为我们很容易检查。 对于那些懒得去、没有时间的人，我们可以组织远程测试。 我们为此有一个专门的实验室。 联系我们。
ACHTUNG-2！ 该测试不是负载测试，因为这里我们只关心容错能力。 几周后，我们将准备一个更强大的支架并对存储系统进行负载测试，并在此发布结果（顺便说一下，接受测试请求）。
那么，让我们去打破它吧。
测试台
我们的展位由以下硬件组成：
- 1 个 Aerodisk Engine N2 存储系统（2 个控制器、64GB 缓存、8 个 FC 端口 8Gb/s、4 个以太网端口 10Gb/s SFP+、4 个以太网端口 1Gb/s）； 存储系统中安装了以下磁盘：
- 4 个 SAS SSD 磁盘 900 GB；
- 12 个 SAS 10k 磁盘 1,2 TB；
- 1 x 物理服务器，配备 Windows Server 2016（2xXeon E5 2667 v3、96GB RAM、2xFC 端口 8Gb/s、2x以太网端口 10Gb/s SFP+）；
- 2 个 SAN 8G 交换机；
- 2 个 LAN 10G 交换机；
我们通过 FC 和 10G 以太网通过交换机将服务器连接到存储系统。 展位图如下。
我们需要的组件（例如 MPIO 和 iSCSI 启动器）已安装在 Windows Server 上。
在 FC 交换机上配置区域，在 LAN 交换机上配置相应的 VLAN，并在存储端口、交换机和主机上安装 MTU 9000（如何执行这一切在我们的文档中有描述，因此我们不再描述这个过程在这里）。
测试方法
碰撞测试计划如下：
- 检查FC口和以太网口故障。
- 电源故障检查。
- 控制器故障检查。
- 检查组/池中的磁盘故障。
所有测试都将在合成负载条件下执行，我们将由 IOMETER 程序生成该负载条件。 同时，我们将执行相同的测试，但条件是将大文件复制到存储系统。
IOmeter配置如下：
- 读/写 – 70/30
- 块 – 128k（我们决定以大块的形式清洗存储系统）
- 线程数 – 128（与生产负载非常相似）
- 全随机
- 工作人员数量 – 4（2 个用于 FC，2 个用于 iSCSI）
该测试有以下目标：
- 确保合成加载和复制过程在各种故障情况下不会中断或导致错误。
- 确保切换端口、控制器等的过程足够自动化，并且在发生故障时不需要管理员操作（也就是说，在故障转移期间，当然我们不是在谈论故障恢复）。
- 确保日志中的信息正确显示。
准备主机和存储系统
我们使用 FC 和以太网端口（分别为 FC 和 iSCSI）在存储系统上配置块访问。 TS Solution 的人员在上一篇文章中详细描述了如何执行此操作（）。 当然，没有人取消手册和课程。
我们使用我们拥有的所有驱动器建立了一个混合组。 将 2 个 SSD 磁盘添加到缓存中，添加 2 个 SSD 磁盘作为附加存储层（在线层）。 我们将 12 个 SAS10k 驱动器分组为 RAID-60P（三重奇偶校验），以便同时检查组中三个驱动器的故障。 留下一张磁盘用于自动替换。
我们连接了两个 LUN（一个通过 FC，一个通过 iSCSI）。
两个 LUN 的所有者都是 Engine-0 控制器
让我们开始测试吧
我们使用上面的配置启用 IOMETER。
我们记录的吞吐量为 1.8 GB/s，延迟为 3 毫秒。 没有错误（错误总数）。
同时，从主机的本地驱动器“C”，我们使用其他接口并行开始将两个 100GB 大文件复制到 FC 和 iSCSI 存储 LUN（Windows 中的驱动器 E 和 G）。
上面是复制到LUN FC的过程，下面是复制到iSCSI的过程。
测试 #1：禁用 I/O 端口
我们从后面接近存储系统））），稍微移动一下手，我们就可以从 Engine-10 控制器上拔出所有 FC 和以太网 0G 电缆。 这就好像一位拿着拖把的清洁女工走过来，决定在鼻涕所在和电缆所在的地方清洗地板（即控制器仍然工作，但 I/O 端口已损坏）。
让我们看看 IOMETER 和复制文件。 吞吐量下降至 0,5 GB/s，但很快恢复到之前的水平（大约 4-5 秒）。 没有错误。
复制文件并没有停止，速度有所下降，但这并不重要（从 840 MB/s 下降到 720 MB/s）。 抄袭还没有停止。
我们查看存储系统日志，看到一条有关端口不可用和组自动重定位的消息。
信息面板还告诉我们 FC 端口的一切都不太好。
存储系统在 I/O 端口故障中幸存下来 成功地。
测试 2. 禁用存储控制器
几乎立即（将电缆插回存储系统后），我们决定通过将控制器从机箱中拉出来完成存储系统。
我们再次从后面接近存储系统（我们喜欢它））），这一次我们拉出 Engine-1 控制器，此时它是 RDG（该组移动到的）的所有者。
IOmeter中的情况如下。 I/O 停止了大约 5 秒。 错误不会累积。
5 秒后，I/O 以大致相同的吞吐量恢复，但延迟为 35 毫秒（延迟在大约几分钟后得到纠正）。 从截图中可以看出，Total error count值为0，即没有出现写入或读取错误。
让我们看看复制我们的文件。 正如您所看到的，它没有被中断，性能略有下降，但总体而言一切都恢复到相同的 ~ 800 MB/s。
我们进入存储系统，在信息面板中看到一个咒语，表示Engine-1控制器不可用（当然，我们杀死了它）。
我们还在日志中看到类似的条目。
存储控制器也幸免于难 成功地。
测试 3：断开电源。
为了以防万一，我们再次开始复制文件，但没有停止 IOMETER。
我们拉动电源装置。
另一个警报已添加到信息面板中的存储系统中。
此外，在传感器菜单中，我们看到与拔出电源相关的传感器已变成红色。
存储系统继续工作。 电源单元的故障不会对存储系统的运行产生任何影响；从主机的角度来看，复制速度和IOMETER指标保持不变。
断电测试通过 成功地。
在最终测试之前，我们决定让存储系统恢复一点活力，放回控制器和电源单元，并将电缆整理好，存储系统很高兴地在其运行状况面板中通过绿色图标通知我们这一点。
测试 4. 一组中的三个磁盘发生故障
在这次测试之前，我们进行了额外的准备步骤。 事实上，ENGINE存储系统提供了一个非常有用的东西——不同的重建策略。 TS Solution 之前写过这个功能，但让我们回顾一下它的本质。 存储管理员可以指定重建过程中资源分配的优先级。 无论是在 I/O 性能方向，即重建时间更长，但没有性能下降。 或者朝着重建速度的方向发展，但生产率会降低。 或者是一个平衡的选择。 由于磁盘组重建期间的存储性能始终是令管理员头疼的问题，因此我们将测试偏向 I/O 性能并以重建速度为代价的策略。
现在让我们检查磁盘是否出现故障。 我们还允许记录到 LUN（文件和 IOMETER）。 由于我们有一个具有三重奇偶校验（RAID-60P）的组，这意味着系统必须能够承受三个磁盘的故障，并且故障后，自动替换必须起作用，一个磁盘必须取代其中一个故障的磁盘在 RDG 中，重建必须从它开始。
开始。 首先，通过存储界面，突出显示我们要拔出的磁盘（以免错过并拔出自动更改磁盘）。
我们检查硬件上的指示。 一切正常，我们看到三个突出显示的磁盘。
我们取出这三个磁盘。
我们来看看主机上有什么。 然后……没有什么特别的事情发生。
删除磁盘并开始重建时，复制指标（它们比开始时更高，因为缓存已预热）和 IOMETER 变化不大（5-10% 以内）。
让我们看看存储系统上有什么。
从集团的现状来看，我们看到重组的进程已经开始，并且接近完成。
在RDG骨架中可以看到2块磁盘处于红色状态，其中3块已经被更换。 自动替换磁盘不再存在；它替换了第三个故障磁盘。 重建花费了几分钟，3块磁盘故障时写文件没有中断，I/O性能没有太大变化。
磁盘故障测试肯定通过了 成功地。
结论
此时，我们决定停止针对存储系统的暴力行为。 我们总结一下：
- FC 端口故障检查 - 成功
- 以太网端口故障检查 - 成功
- 控制器故障检查 - 成功
- 电源故障测试 - 成功
- 检查组池中的磁盘故障 - 成功
没有任何故障停止记录或导致合成负载错误；当然，性能受到影响（我们知道如何克服它，我们很快就会做到），但考虑到这些都是几秒钟，这是完全可以接受的。 结论：AERODISK存储系统所有组件的容错能力都在正常水平，没有出现任何故障点。
显然，在一篇文章中我们无法测试所有故障场景，但我们试图涵盖最常见的故障场景。 因此，请发送您的意见、对未来出版物的建议，当然还有充分的批评。 我们很乐意讨论（或者更好的是，参加培训，我复制时间表以防万一）！ 直到新的测试！
- 下诺夫哥罗德 （已经开放 – 您可以在这里注册 );
16年2019月16日前，任何工作时间均可来中心参观，2019年XNUMX月XNUMX日将组织大型培训课程。 - 克拉斯诺达尔 （即将开放 - 您可以在这里注册 );
9年25月2019日至25月2019日，您可以在任何工作时间来中心参观，XNUMX年XNUMX月XNUMX日将组织大型培训课程。 - 叶卡捷琳堡 （即将开放，请关注我们网站或 Habré 上的信息）；
2019 年 XNUMX 月至 XNUMX 月。 - 新西伯利亚 （遵循我们网站或 Habré 上的信息）；
2019年XNUMX月 - 克拉斯诺亚尔斯克 （遵循我们网站或 Habré 上的信息）；
2019 年 XNUMX 月。
来源： habr.com