有人很快就会跌倒因为SHD存储着圣物-数据。 如果数据不再可用，它将很快闻到油炸的味道。 或者，如果突然结束了，这也是令人不快的惊喜。 因此，监视应该是强制性的，并且应覆盖存储系统。
有两种主要的
监视存储方法 。 要么使用像Nagios，Icinga这样的通用监视系统，它就会通过SNMP收集信息，或者从存储系统制造商那里购买高度专业的软件。 当然，第二个选项可对铁的状态进行更深入的分析，显示诸如高速缓存状态，iops，命中率，控制器负载等特定信息。这是我们的客户最常选择的选项，他们在使用大型且昂贵的阵列。 。
但是顺便说一下，使用商业监视软件并不是一切都那么顺利。 我将更详细地说明。 可以说，这将是第一手的经验。 在过去的两年中，我一次完成了一个这样的系统，用于处理来自著名供应商的成千上万张绿色纸。 然后他拿起它，以便甚至在供应商的支持下也开始向我咨询。 但是有些软件问题却被其他软件问题所取代，就像一些印第安人在支持下被新的印第安人所取代一样，那时我才有了这个想法，即使根本不采取根本行动……总的来说，这一切都始于此。
供应商软件有什么问题？
正如我所说，来自制造商的监视可以完美监视同一制造商的存储系统。 这是它的主要优势。 缺点从这里开始增长：有限地支持或根本不支持其他制造商的阵列。 事实证明，如果服务器场上有几个不同的阵列，则需要几个不同的监视工具。 是的，不要忘记下次需要看什么，什么时候看。 理想情况下，通常由管理员管理每个阵列。
供应商制造商的工具要花钱，而且相当大，这已不是什么秘密。 扩展支持也要花费一分钱。 一些供应商已经掌握了新的关注点：他们宣布软件生命周期即将结束，只提供购买另一种产品的权利，而无需迁移许可证。 这种设置是几个月前与我们的一位客户发生的。 没有选择：如果您要继续监视硬件-请重新购买。
如果您深入研究供应商软件，则会弹出其他不愉快的功能。 例如，在许多产品中，您可以看到当前状态图片，但是看不到前一时期的历史记录。 或故事是有限的：日志每3天重写一次。 完全没有必要谈论统计的累积。 通常，事件的历史是进行预测（例如，购买备件，进行报告和调查事件）所必需的。 例如，某些业务系统中的制动器可以推到存储系统上，并且，如果没有实际数据，则没有任何隐藏的内容。
最后，人们不得不抱怨供应商软件的更新和更改的速度。 哦，我长期练习遇到这种麻烦的频率是多少！ 新型号的阵列问世，新固件推出，新设置出现。 所有这些很容易破坏工作监控：要么停止收集某种INFA，要么阵列通常脱落。 在新的微代码中，制造商关闭了对旧版本SSL的支持，并且监视软件尚不支持TLS协议。 首先，没有人能找到原因。 经过我自己的调查，我将这些输入发送给了制造商，他们已经更新了古代图书馆。 但是，所有这些繁文tape节无限期地持续下去。
一旦我们在客户身上使飞行员失败了。 提议使用供应商软件，并且客户在功能和界面方面都喜欢所有东西。 但是不幸的是，他们的主要生产系统没有得到支持。 他们甚至准备等待一两个月，但是供应商表示没有计划在不久的将来将这些系统包括在内（这只是HUS上Hitachi AMS系列的更新）。
总的来说，给您带来很多不便，并且出于某种原因要花很多钱。
很久以前我没有接跳棋...
对于这种情况感到沮丧，我经常想到如何实现自己的存储监视。 如果您非常了解该阵列并拥有其CLI，则可以快速获取所需的有关状态的信息或深入了解问题的根源。 当然，在此之前，有必要铲除许多码头，烟雾论坛和供应商的知识库，这些零碎的不同信息。 但是，当您知道使用哪个键键入哪个命令以及每个输出列的含义时，您已经是专家。 仍然需要将这些知识构建到一个方便的界面中，该界面将继续为您做所有事情。
我承认，起初我也打算从头开始编写接口，但是后来我遇到了Zabbix，它是一个具有大型社区的成熟工具，也很容易扩展。 它具有我所需的一切：界面，角色模型，通知，触发系统，代理客户端代理。 仅此组合器即可正确提供有关存储系统和各种参数阈值的信息。 案件开始沸腾了。 我们拥有一系列的专家团队。 当然，不可能一个人知道所有阵列，因此我们按型号和制造商进行划分。
开发自己的监控器的另一个困难是能够自己访问铁片，因此仍然不怕加载，破坏和进行各种实验。 幸运的是，我们实验室的资源使这一切成为可能。
监视的第一件事是所有硬件组件的运行状况。 可以通过SNMP采取某些措施，但是在大多数情况下，这是使用特殊协议（SMI-S，REST API，SOAP API等）的调查。 我必须说，阵列本身允许您配置有关其故障的通知。 所有客户至少都使用此功能。 但是，如果数组上的通知本身中断，会发生什么呢？ 这发生了一次，而且不止一次，当阵列保持沉默数周，并且每个人似乎一切都井井有条时，它却保持沉默。 然后突然变得很清楚，有大量磁盘飞过，但为时已晚。
监视的第二个重点是性能。 因为当在存储系统上以几秒钟的记录延迟来提高性能时，Oracle可以简单地上下移动。 不知道 在具有许多存储系统的大型基础架构中，对性能的控制最差。 Zabbix提供了极为方便的预测分析：基于预测，您可以设置指标的值，该指标将在将来使用。 例如，我们做出了一个触发器，如果预测到目前仅剩3个月的时间，该触发器将起作用。 或者，例如，根据预测，在2周内的响应时间将增加50毫秒。 监视使我们有时间提前了解即将出现的问题并已经做一些事情。
在某个时候，我们意识到了解存储状态当然是一件好事，但是了解网络和服务器端的其他情况要好得多。 结果，经过几个月的工作，就可以在一个界面中同时看到服务器，网络和存储系统。 不仅出现了用于存储的插件和连接器，而且还以网络拓扑图的形式出现了有用的绑定。 到目前为止，当然，该插件考虑了我们的经验和我们的需求，但是如果您告诉我们您需要从中看到什么，我们将予以扭转。
VMware群集的端到端拓扑：从虚拟机到存储卷
性能表现在阵列性能图上，我们看到系统非常重载。 磁盘组利用率高表明磁盘过载。 存储端口上有很多I / O操作，这意味着IT系统需要为它们加载阵列。 好了，响应时间的特性图以及高于建议值的处理器利用率。 判断-阵列上放置了太多任务；其中一些任务需要迁移。
存储网络图：查找瓶颈总结
我们得到了什么？ 我们为流行且非常常见的Zabbix监视系统配备了新功能，其中包括：
- 从存储网络的磁盘阵列和交换机收集有关所有硬件和逻辑组件状态的信息。
- 绝大部分我们为其制作插件的系统的性能统计信息（供应商在这方面存在差距）。
- 共享存储网络以及从虚拟机到存储系统上卷的端到端的拓扑图（到目前为止仅适用于VMware）。
- 收集所有库存信息。
- 磁盘空间量。
Zabbix本身允许您创建非常酷的通知，设置阈值，发送有关问题的信息性信件。 例如，如果交换机上的端口掉线（或端口上的流量变得很大），则该消息将不仅包含带有端口号的交换机名称，而且还将包含有关所连接设备的信息。
我们目前支持哪些系统？ 许多不同之处：
- 所有Hitachi阵列（AMS，HUS，VSP，VSP G）。
- 阵列Dell-EMC CLARiiON，VNX，Unity，ISILON，Compellent。
- HP 3PAR，P9500，XP7阵列
- IBM Storwize，DS5000的阵列。
- 阵列NetApp FAS（7模式，c模式）。
- HPE StoreOnce，EMC DataDomain磁盘库。
- 博科家蚕交换机，思科MDS。
我们还对某些操作系统（Windows，ESX）进行了扩展，使用它们我们可以在FC HBA上收集数据，以便将来绘制拓扑图。 积极开发适用于OpenStack和虚拟化系统的插件。
在开发插件时，要考虑我们工程师的专业知识，在此之后，有很多情况下需要解决阵列上的问题-硬件和性能。 由于拥有大量现成的库，因此可以在短时间内根据要求开发新插件。
我们的一些客户对系统的配置如下：带有合同编号，联系人和故障组件的所有参数的通知会自动发送到我们的邮件中。 这减少了反应时间并订购了必要的备件，因为值班工程师甚至在晚上都不需要致电和澄清很多信息。 该应用程序立即开始工作。
您如何解决监视基础结构（尤其是存储）的问题？ 在评论中或在给我们的邮件VRyzhevsky@croc.ru的信中告诉我们