«Из-за незабитого гвоздя потеряли подкову,
Из-за потерянной подковы потеряли лошадь,
Из-за потерянной лошади гонец не доставил послание,
Из-за недоставленного послания проиграли войну…»
Японская притча
Мониторинг инфраструктуры — важнейшая задача для любого системного администратора. Для сбора информации, поступающей от различных устройств, чаще всего применяются такие универсальные системы мониторинга, как Zabbix. Данные можно визуализировать с помощью встроенных инструментов, но они достаточно сложны для настройки. Поэтому часто используется такой сторонний инструмент, как Grafana. Zabbix-оповещения же настраиваются через уведомления на электронную почту или с помощью интеграции в корпоративный мессенджер, например Slack.
В любой, даже хорошо налаженной, системе есть критичные узлы, отказ которых может привести к самым плачевным последствиям. Мониторинг этих узлов позволяет прогнозировать отказы или принимать правильные решения, если что-то пошло не так. Парадокс в том, что система мониторинга сама по себе является критичным узлом.
Разумеется, резервирование такого узла — первое, о чем стоит подумать, благо Zabbix поддерживает прокси для сбора данных от имени централизованного сервера мониторинга. Но на этом работа по обеспечению отказоустойчивости не заканчивается. При определенных условиях слабым звеном может стать канал связи, даже если он зарезервирован.
Большинство компаний уже давно отказались от концепции «серверная в офисе» и размещают свое оборудование в стойках дата-центров. Это снимает множество проблем с обеспечением комфортного микроклимата для оборудования, потерей связности или электропитания. Но не все так идеально, как хотелось бы. Сегодня мы расскажем о трех кейсах, когда система мониторинга не сможет оповестить системного администратора.
Рассматриваемая IT-инфраструктура представляет собой серверную стойку с оборудованием, размещенную в дата-центре Tier III, то есть все системы зарезервированы на уровне провайдера.
Возможные проблемы
Потеря связности
Рис. 1 — неисправность пограничного маршрутизатора
Чаще всего для обеспечения периметра между глобальной и локальной сетью устанавливается пограничный маршрутизатор. Его задача проста — обеспечить нужным устройствам выход в интернет, а если основной канал связи провайдера недоступен, то выполнить переключение на резерв.
Что произойдет, если сервер мониторинга находится внутри периметра, а пограничный маршрутизатор выйдет из строя? Правильно — сообщения мониторинга до системного администратора не дойдут. Глобально сбой станет виден как потеря связности со стойкой, но для выяснения истинной причины потребуется привлечение технической поддержки провайдера, инженеры которого смогут посмотреть на физическое состояние оборудования. Пока не станет ясно, что произошло, нельзя будет принять соответствующие меры.
DDoS-атака
Рис. 2 — доставка уведомлений в обход основного канала связи
Точно так же, как и в случае выхода из строя пограничного маршрутизатора, DDoS-атака, направленная на то, чтобы забить канал связи, приводит к полной или частичной недоступности сервиса. В условиях «массированной бомбардировки» пакетами уведомления от системы мониторинга могут либо дойти с задержкой, либо вообще не дойти. Все это время сервис де-факто работать не будет, а системному администратору потребуется взять контроль над ситуацией.
Решением может быть как временная отправка всех пакетов в black-holе, так и включение защиты от атак. И чем быстрее это будет сделано, тем меньше будет простой сервиса. Корректная настройка мониторинга плюс доставленные вовремя уведомления позволят минимизировать ущерб от атаки и предпринять правильные действия.
Недоступность почтового сервера
Рис. 3 — доставка уведомлений при недоступности основного почтового сервера
В подавляющем большинстве случаев уведомления от систем мониторинга настраиваются с помощью электронной почты. Это удобно, поскольку оповещения сразу поступают ответственным лицам, а по истории почтового ящика можно восстановить события с точностью до секунды. При каких условиях Zabbix не сможет доставить уведомления? Это может произойти, если почтовый сервер по каким-либо причинам перестанет работать.
Несмотря на популярность различных сторонних почтовых сервисов, многие системные администраторы предпочитают внутри организации использовать собственноручно настроенные почтовые серверы, на которые чаще всего и привязывают доставку уведомлений.
Чего не хватает?
Во всех трех описанных сценариях проблемы возникают из-за отсутствия так называемого узла-свидетеля, не зависящего от каналов связи провайдеров дата-центра. Один из интересных вариантов организации такого узла — решение UniPing server solution v3/SMS.
Рис. 4 — внешний вид устройства
Устройство с форм-фактором 1U предназначено для установки в стандартную 19″ стойку. Его основная задача — мониторинг состояния различных датчиков:
Такое оборудование идеально подходит для мониторинга состояния серверной стойки, а GSM-модем позволяет доставлять СМС-оповещения без привязки к интернет-каналу. Но этим его возможности не ограничиваются. Помимо штатных функций устройства, одной из недокументированных возможностей является отправка email-уведомлений с использованием резервного GPRS-канала, который обеспечивается встроенным GSM-модемом.
Настройка и особенности
Прежде всего определимся с логикой взаимодействия. При наступлении определенного события триггер в Zabbix должен вызывать пользовательский скрипт оповещения. Этот скрипт обращается к странице /at.html веб-интерфейса устройства, последовательно выполняя команды на установку соединения, отсылку сообщения с содержанием уведомления и разрыва соединения.
Устройство NetPing взаимодействует с GSM-модемом при помощи AT-команд, что позволяет легко создать bash-скрипт, передающий команды с помощью curl.
Рассмотрим форму /at.html
<form name=»frm»>
<input name=»cmd»/>
<input type=»button» value=»Send» onclick=»send()»/>
</form>
Тут все просто — для отправки команды нам нужно передать:
curl —user <логин>:<пароль> -d «cmd=<AT-команда>» http://<адрес устройства>/at.html
Ответ от выполненной команды запрашивается CGI-скриптом:
curl —user <логин>:<пароль> http://<адрес устройства>/atget.cgi
Осталось лишь понять, какими AT-командами следует оперировать. Разделим их на две группы: соединение с интернетом и отправка сообщения.
Соединение с интернетом
Перед установкой соединения зададим несколько переменных:
-
AT+SAPBR=3,1,«CONTYPE»,«GPRS» — устанавливаем тип соединения.
-
AT+SAPBR=3,1,«APN»,«Адрес APN мобильного оператора» — задаем имя точки доступа.
-
AT+SAPBR=3,1,«USER»,«Имя пользователя» — задаем имя пользователя.
-
AT+SAPBR=3,1,«PWD»,«Пароль» — задаем пароль.
Теперь можно установить соединение командой:
AT+SAPBR=1,1
Отправка еmail
Как и при настройке соединения, вначале определим переменные:
-
AT+EMAILCID=1 — задаем CID параметра для email-сессии.
-
AT+EMAILTO=30 — задаем значение тайм-аута для SMTP-сервера.
-
AT+SMTPSRV=»Адрес почтового сервера», Порт подключения — указываем адрес нашего почтового сервера и порт для подключения.
-
AT+SMTPAUTH=1,»Имя пользователя»,»Пароль» — данные для авторизации на почтовом сервере.
-
AT+SMTPFROM=»E-mail адрес»,»Название устройства» — указываем email-адрес и название устройства в качестве имени отправителя.
-
AT+SMTPRCPT=0,0,»E-mail адрес»,»Имя получателя» — указываем email-адрес и имя получателя.
-
AT+SMTPSUB=»Тема письма» — задаем тему письма.
-
AT+SMTPBODY=»Текст» — текст уведомления.
Отправляем письмо:
AT+SMTPSEND
Завершаем соединение:
AT+SAPBR=0,1
Уведомления отправлены системному администратору, даже если основной и резервный канал связи в дата-центре оказались недоступны.
Что в итоге
Мы не просто так рассматривали три возможные проблемы, при которых сообщения от системы мониторинга не смогут дойти до системного администратора. UniPing server solution v3/SMS легко решит эти проблемы за счет независимости от каналов связи провайдера инфраструктуры и сможет сразу оповестить о наличии сбоя посредством электронной почты.
Подобное устройство в серверной стойке предоставляет больший контроль над ситуацией и дает следующие преимущества:
- определение источника проблемы (виноват ли провайдер в сбое или же проблема носит локальный характер);
- более точное планирование RTO (промежутка времени, в течение которого система будет оставаться недоступной);
- понимание, в каком состоянии находится оборудование, без привлечения технической поддержки провайдера инфраструктуры.
Чем раньше системный администратор получит всю вышеперечисленную информацию, тем быстрее проблема будет решена, а бизнес получит объективные прогнозы сроков восстановления сервиса.