存储主要服务于业务,如果已经定位到存储故障问题,最快途径肯定是通过厂商解决问题。
但随着客户对存储监控的需求越来越高,可以从业务端做全链路跟踪,围绕业务从应用-操作系统-存储做个按业务拓扑的监控,存储端的监控更多的是通过SNMP去做,不同厂家监控的粒度也不太一样,如果厂家能提供API对接,可以做更细粒度的监控。
可视化也是监控快速故障定位的一种方式,例如Zabbix以其强大的功能和高可扩展性广受企业客户欢迎。通过监控模板, 存储提供灵活的REST API、Prometheus和Elastic Seach等多种标准接口,可与市场上绝大多数第三方应用无缝集成对接。 利用预定义的“发现规则”可动态识别各种存储资源,如服务器、硬盘、存储池、块存储卷、对象存储桶和文件夹等,在存储中进行的各种资源创建、修改和删除操作,可以自动同步到Zabbix平台中。
收起我不太了解您说的深度是什么意思,那就从我的经验出发说说我的想法:
1)我猜测您现有的监控还是依赖设备自身的控制台和报警能力,这已经很具有深度了。毕竟存储厂商的内部检测机制是能否发现无论是硬件还是软件层面的异常的。设备厂商在监控层面唯独做不好或做不到的有两种:系统级故障和亚健康故障。
2)系统级故障:顾名思义不是单点的问题,而是涉及设备、网络和软件的系统级故障。以性能故障居多,常出现在结构复杂、IO延迟要求高的应用场景,例如SAN网络、存储双活系统、两地三中心灾备系统等。要解决这类问题,靠单个厂商的监控能力是不行的,毕竟面临的是多厂商异构的存储环境。要想解决,就需要有专业系统在更高的维度上建立全局管理视图,首先自动识别复杂网络架构,建立端到端拓扑模型,其次对关键位置的关键指标做7x24x365级别的数据采集,针对特定的场景,例如多路径负载、级联链路峰值、端口抖动光衰、盘阵前端拥塞、RAID或池热点、慢速盘等设定阈值,做门限的实时监控。发现故障时,结合端到端拓扑和历史性能数据,就能实现准确的故障定位。
3)亚健康故障:之所谓亚健康就是将坏不坏的状态,没有触发告警机制或仅仅是低级别告警,靠巡检是无法直接发现的,但是对IO的响应造成了影响,常出现在网络侧,例如端口光衰抖动等。发现此类问题同样需要在端到端拓扑模型和历史性能数据的支持,就是需要对亚健康的场景做预警,提前发现,准确定位,及时响应。
如果核心系统存储故障,我们的优先是处理故障 还是按照核心系统的RPO、RTO 进行切换呢?
根据监管要求,肯定是 先切换 保障核心业务连续性。
存储的监控 首要是为了第一时间发现问题,其次才是定位故障。
收起