Компьютерные сети давно перешли в разряд критических составляющих обеспечения бизнес-процессов. Выход из строя такой системы фактически означает остановку деятельности всей организации. Мониторинг и диагностика производительности сети является одной из основных задач обеспечения работоспособности предприятия. Это непрерывный процесс наблюдения за цифровой сетью с целью своевременного обнаружения в ней неисправностей и ошибок с быстрой и адекватной реакцией на них. Всвязи с этим встаёт вопрос о высокой доступности самого сервиса мониторинга и его бесперебойной работе.
В программе реализовано несколько механизмов, которые обеспечивают отказоустройчивость системы мониторинга. Использование этих механизмов позволяет держать сетевую инфраструктуру под надёжным контролем.
Сторож службы мониторинга
Сторож сервера мониторинга реализован в виде службы с именем 10-Strike Network Monitor Watchdog. Она устанавливается на каждом хосте, где развёртывается основной дистрибутив программы или дистрибутив сервера мониторинга). Служба следит за параметрами службы сервера мониторинга 10-Strike Network Monitor Pro Service и СУБД Firebird Server. В случае остановки или аварийного завершения этих служб сторож автоматически запускает их вновь. Если пять попыток запуска этих служб не завершается успехом, сторож отправляет уведомление по e-mail на заданный адрес. Следует учитывать то, что если даже вы штатно остановите службу сервера мониторинга для обслуживания базы, то активный сторож опять запустит её через несколько секунд. Поэтому в таких ситуациях необходимо останавливать сначала службу сторожа, а затем и сервера мониторинга.
Сторож следит не только за состоянием службы (запущена / не запущена), но и активностью самого процесса мониторинга и его параметрами. В случае, если процесс мониторинга перестаёт подавать признаки активности (запись метки в БД), то сторож также перезапускает службу. То же самое он делает, если перестаёт выполняться какое-то количество проверок, что может сигнализировать о накоплении внутренних ошибок при мониторинге.
Использование сторожа предотвращает остановку мониторинга из-за программных ошибок сервера мониторинга.
Резервный сервер базы данных
В распределённой системе мониторинга центральная база данных находится на одном физическом сервере, а сервера мониторинга установлены на других. Службы мониторинга подключаются по TCP к базе данных и обмениваются с ней информацией, получая настройки и записывая статистику и результаты выполнения проверок. Бывают ситуации, когда сервер с базой данных выходит из строя или связь с ним рвётся. Это грозит потерей оперативной информации, которую сервер мониторинга поставляет в центральную базу.
Для решения этой проблемы предлагается использовать резервный сервер с установленной базой данных, на который происходит репликация всей файловой системы (или части файлов). В настройках службы мониторинга предусмотрен параметр, в котором содержится адрес резервного сервера БД. На него сервер мониторинга и консоль переключаются автоматически, если становится недоступным основной сервер баз данных. Адрес резервного сервера задаётся в настройках подключения программы к базе данных. Необходимо самостоятельно настраивать репликацию базы данных (зеркалирование файловой системы, как вариант) для поддержания актуального состояния резервной копии.
Защита от потери информации при разрыве соединения с центральной базой данных
Существует альтернативное решение проблемы потери соединения удалённого сервера мониторинга с центральной базой данных. Если не будет задан и настроен резервный сервер БД, служба мониторинга переключится на локальную базу, которая настраивается и устанавливается автоматически из дистрибутива (c:\ProgramData\10-Strike\Network Monitor Pro\LocalDB\NETMONITOR.FDB). Сервер мониторинга будет писать статистику опроса хостов в локальную базу, пока не восстановится связь с основной базой. После восстановления соединения все накопленные за это время в локальной базе данные автоматически переносятся в основную базу. Весь процесс полностью автоматический и не требует каких-либо действий со стороны пользователя. Никаких дополнительных настроек ПО для работы этого функционала тоже не требуется.
Протокол работы службы в таких ситуациях записывается в журнал программы (c:\ProgramData\10-Strike\Network Monitor Pro\Logs\NetMonitorPro.log). При длительных разрывах соединения с БД можно проверить, данные были успешно перенесены в центральную БД.
Резервирование сервера мониторинга
Резервирование предусмотрено не только для сервера центральной БД, но и самого сервера мониторинга. Рассматривается ситуация, когда выходит из строя хост, на котором установлена служба мониторинга, выполняющая проверки. В этом случае мониторинг полностью останавливается. Во избежание подобных инцидентов предлагается устанавливать сервер мониторинга на второй физический хост и задавать ему такой же ID. Таким образом, мы получаем две активных службы мониторинга, подключенных к одной базе и имеющих в конфигурационном файле c:\ProgramData\10-Strike\Network Monitor Pro\NetMonitorPro.ini одинаковый ID. Служба, стартующая первой, автоматически назначается активной и начинает выполнять все проверки. Стартующая второй служба становится резервной. Она так же зачитывает из базы тот же список проверок, но не выполняет их. Резервная служба постоянно отслеживает активность первой службы по некоторым признакам в БД. В случае, если первая служба перестаёт быть активной, резервная служба мониторинга автоматически начинает выполнять проверки без простоя.
Первая служба после восстановления работоспособности сервера становится резервной и начинает мониторить активность второй службы. И так далее.
Такое решение можно использовать для создания отказоустойчивого кластера серверов.
Программа работает в среде Windows XP/Vista/7/8.1/10/11, Server 2003/2008/2012/2016/2019/2022. Вы можете скачать и попробовать 30-дневную пробную версию бесплатно.