Кто-то скоро упадёт
Потому что СХД хранит святая святых — данные. Если данные стали недоступны, очень скоро запахнет жареным. Или если вдруг место закончилось — тоже неприятный сюрприз. Поэтому мониторинг должен быть обязательно, и он должен покрывать СХД.
Есть два основных подхода к мониторингу хранилок. Либо использовать универсальную систему мониторинга наподобие Nagios, Icinga, которая будет собирать инфу по протоколу SNMP, либо купить узкоспециализированный софт от производителей самих СХД. Само собой, второй вариант обеспечивает более глубокий анализ состояния железа, показывает специфические вещи наподобие состояния кэша, iops, hit rate, загрузку контроллеров и т. д. Именно такой вариант и выбирали чаще всего наши заказчики, у которых в строю стоят крупные и дорогостоящие массивы.
Но к слову сказать, не всё так гладко с коммерческим ПО для мониторинга. В подробностях я расскажу дальше. Это будет, так сказать, опыт из первых рук. В своё время я почти 2 года допиливал одну такую систему за много тысяч зелёных бумажек от именитого вендора. И расковырял её так, что даже поддержка вендора со мной стала советоваться. Но одни проблемы софта сменялись другими, равно как одни индусы из поддержки сменялись новыми индусами — и тогда-то мне и пришла мысль, а не поступить ли вообще радикально… В общем, с этого всё и началось.
Что не так с вендорским ПО?
Как я уже сказал, мониторинг от производителя отлично мониторит СХД того же производителя. В этом его главное достоинство. Недостатки растут отсюда же: массивы других производителей поддерживаются ограниченно или никак. Получается, что если у вас в хозяйстве несколько разных массивов, то нужно несколько разных инструментов мониторинга. Да ещё и не забыть, какой от чего и когда в него надо в следующий раз посмотреть. В идеале — вообще по админу на каждый массив.
Не секрет, что инструменты от вендоров-производителей стоят денег, и довольно больших. И продление поддержки потом тоже обходится в копеечку. А некоторые вендоры освоили новый фокус: объявляют об окончании жизненного цикла своего ПО и предлагают просто приобрести другой продукт, без миграции лицензий. Именно такая подстава буквально пару месяцев назад и случилась с одним нашим заказчиком. Вариантов нет: хочешь дальше мониторить железо — делай новую покупку.
Если копнуть вендорский софт глубже, то всплывают и другие неприятные особенности. Например, в ряде продуктов можно видеть текущую картинку состояния, но нельзя посмотреть историю за предыдущий период. Либо история ограниченная: лог перезаписывается раз в 3 дня. Говорить тут о накоплении статистики просто не приходится. А зачастую история событий требуется и для прогнозов, например закупки ЗиП, и для отчётности, и для расследований инцидентов. Например, тормоза в какой-то бизнес-системе могут спихнуть на СХД и, если нет фактических данных, прикрыться нечем.
Ну и, наконец, нельзя не пожаловаться на скорость обновлений и изменений в вендорском ПО. С этой бедой за мою долгую практику я сталкивался ох как часто! Выходят новые модели массивов, выходят новые прошивки, появляются новые настройки. Всё это легко ломает работающий мониторинг: то какая-то инфа перестаёт собираться, то массивы вообще отваливаются. Был случай, когда в новом микрокоде производитель отключил поддержку старых версий SSL, а ПО мониторинга пока ещё не поддерживало протокол TLS. И никто сначала не мог найти причину. Уже после моего собственного расследования я отправил эти вводные производителю, и они уже тогда обновили древние библиотеки. Однако вся эта волокита длилась бесконечно долго.
А однажды мы провалили пилот у заказчика. Предлагалось использовать вендорский софт, и всё в плане функционала и интерфейса заказчику нравилось. Но на беду их основные продуктивные системы не поддерживались. Они даже были готовы подождать месяц-два, но вендор сказал, что в ближайших планах включения этих систем в поддержку нет (а ведь это было всего лишь обновление линейки Hitachi AMS на HUS).
В общем, довольно много неудобств и почему-то за большие деньги.
Давненько я не брал в руки шашки...
Раздосадованный таким положением вещей, я не раз задумывался о том, чтобы реализовать свой собственный мониторинг для СХД. Если ты хорошо знаешь массив и владеешь его CLI, то можно довольно быстро получить нужную инфу о состоянии или докопаться до истоков проблем. Конечно, перед этим надо перелопатить немало доков, покурить форумы и базы знаний вендоров, по крупицам собрать разную информацию. Но когда знаешь, какую команду с каким ключом набрать и что значит каждый столбец вывода, ты уже гуру. Оставалось это знание встроить в удобный интерфейс, который дальше будет всё делать за тебя.
Признаюсь, что поначалу я задумывал и интерфейс тоже с нуля писать, но потом мне попался Zabbix — зрелый инструмент с большим комьюнити, который к тому же легко расширяется. В нём было всё, что мне нужно: интерфейс, ролевая модель, нотификации, система триггеров, прокси-клиенты-агенты. Оставалось только в этот комбайн правильно подавать информацию об СХД и пороговых значениях разных параметров. Дело закипело. У нас собралась команда спецов по массивам. Знать все массивы одному человеку, понятное дело, невозможно, поэтому мы разделились по моделям и производителям.
Ещё одной трудностью в разработке собственного мониторинга является возможность доступа к самим железякам и чтобы их ещё было не страшно нагружать, ломать и проводить всякие эксперименты. Благо, ресурсы нашей лаборатории всё это позволяли.
Первое, что нужно мониторить, — это исправность всех аппаратных компонентов. Что-то можно брать по SNMP, но в большинстве случаев это опрос по специальному протоколу (SMI-S, REST API, SOAP API и другие). Надо сказать, что сами массивы позволяют настроить на них нотификации о поломках. И этим все заказчики худо-бедно пользуются. Но что будет, если сломалась сама нотификация на массиве? Такое было, и не раз, когда массив молчал неделями и всем казалось, что всё в порядке, — молчит же. А потом вдруг выяснялось, что на нём полетело критическое количество дисков, но было уже поздно.
Второй важный момент для мониторинга — производительность. Потому что при просадке перфоманса на СХД при задержке на запись в несколько секунд Oracle может просто взять и упасть. Без затей. Именно производительность в больших инфраструктурах со множеством СХД контролируется хуже всего. А в Zabbix есть крайне удобный предиктивный анализ: можно на основе прогноза задать значение метрики, каким оно станет в будущем. К примеру, мы сделали триггер, который сработает, если будет прогноз, что места при текущей утилизации осталось всего на 3 месяца. Или, например, что время отклика по прогнозу через 2 недели станет больше на 50 миллисекунд. Мониторинг даёт нам время узнать о грядущих проблемах заранее и что-то уже предпринять.
В какой-то момент мы поняли, что знать о состоянии СХД, конечно, хорошо, но гораздо лучше понимать, что ещё происходит в сети и на стороне серверов. В итоге через несколько месяцев работы появилась возможность в одном интерфейсе видеть и серверы, и сеть, и сами системы хранения. Появились не только плагины и коннекторы для СХД, но и полезная обвязка в виде карт топологии сети. Пока, естественно, плагин учитывает наш опыт и наши потребности, но если вы расскажете, что нужно видеть в нём, мы докрутим.
Топология End-to-End для кластера VMware: от виртуальной машины до тома на СХД
Производительность
На графике производительности массива мы видим, что система перегружена очень сильно. Высокая утилизация дисковых групп показывает, что диски перегружены. На портах СХД много операций ввода-вывода, что говорит о том, что ИТ-системы нагружают массив со своей стороны. Ну и характерный график по времени отклика, а также утилизация процессоров выше рекомендуемых значений. Вердикт — на массив положили слишком много задач, нужно часть из них мигрировать.
Карта сети хранения данных: поиск узких мест
Итог
Что же у нас получилось? Мы оснастили популярную и весьма распространённую систему мониторинга Zabbix новыми возможностями, среди которых:
- Сбор информации о состоянии всех аппаратных и логических компонент с дисковых массивов и коммутаторов сети хранения данных.
- Статистика производительности для абсолютно всех систем, для которых мы сделали плагины (у вендоров в этом плане есть пробелы).
- Топологические карты как общей сети хранения, так и end-to-end от виртуальных машин до томов на СХД (пока только для VMware).
- Сбор всей инвентарной информации.
- Запас дискового пространства.
Сам Zabbix позволяет создавать очень классные уведомления, выставлять пороговые значения, отправлять информативные письма о проблеме. Например, если упал порт на коммутаторе (или трафик на порту стал очень большим), в письме придёт не только имя коммутатора с номером порта, но и информация о подключенном устройстве.
Какие системы мы сейчас поддерживаем? Много разных:
- Все массивы Hitachi (AMS, HUS, VSP, VSP G).
- Массивы Dell-EMC CLARiiON, VNX, Unity, ISILON, Compellent.
- Массивы HPE 3PAR, P9500, XP7.
- Массивы IBM Storwize, DS5000.
- Массивы NetApp FAS (7-mode, c-mode).
- Дисковые библиотеки HPE StoreOnce, EMC DataDomain.
- Коммутаторы Brocade Silkworm, Cisco MDS.
Также у нас есть расширения для некоторых ОС (Windows, ESX), с помощью которых мы собираем данные о FC HBA, чтобы в дальнейшем рисовать топологические карты. Активно ведётся разработка плагинов под OpenStack и системы виртуализации.
При разработке плагинов учитывается экспертиза наших инженеров, за плечами которых множество кейсов по решению проблем на массивах — как аппаратных, так и с производительностью. Новые плагины разрабатываются по запросу в короткие сроки за счёт большого количества собственных готовых библиотек.
Некоторые наши заказчики настраивают систему так: на нашу почту автоматически приходят уведомления с указанием номера контракта, контактных лиц и всех параметров неисправного компонента. Это сокращает время реакции и заказа необходимой запчасти, так как у дежурного инженера нет необходимости звонить и уточнять массу информации — даже ночью. Заявка уходит сразу в работу.
А как вы решаете задачи мониторинга вашей инфраструктуры, в частности СХД? Расскажите об этом в комментариях или в письме на почту VRyzhevsky@croc.ru
Автор: VRyzevsky
