Как и с чем едят SureBackup

SureBackup — один из инструментов Veeam Backup. Работает он благодаря двум функциям: vPower (запуск ВМ из архива) и VirtualLab (изолированная виртуальная среда).
В автоматическом режиме, по расписанию, с рассылкой результатов проверки на почту, SureBackup позволяет запустить группу ВМ и проверить их работоспособность на уровне ОС, сети и приложений.

Вот на третьем способе проверки (приложений) я и хочу остановиться подробней.
Для проверки стандартных приложений есть возможность выбора: AD, Global Catalog, SQL, Web, Mail, DNS. Проверка идет просто: опрашивается сетевой порт, и если на соответствующий порт приложение отвечает, значит считаем, что приложение работает.

Но на этом варианты проверки не заканчиваются. О том, как проверить другие приложения, в том числе, зависящие от физических серверов дальше и идет речь.

1. Простая проверка других приложений

Как быть с приложениями не из означенного выше списка "стандартных" приложений?
Можно задействовать утилиту из состава Veeam Backup — VmConnectionTester. Она располагается в папке установки Veeam Backup.
Принцип прост — прописать утилиту в строке, указать параметры проверки как "%vm_ip% <номер_порта_приложения>".

На скриншоте настройка проверки для Oracle DB.

Список стандартных приложений для проверки можно расширить, создав свой xml. В документации сказано, как это сделать. Тогда не надо будет прописывать один и тот же скрипт каждый раз для однотипных ВМ, а достаточно просто отметить соответствующую галку в списке.

2. Сложная проверка

Для тех сервисов, которые невозможно проверить на уровне открытых сетевых портов, или если такой проверки недостаточно. Можно написать свою проверку. Например, tnsping-запрос для БД Oracle с проверкой результата; скрипт опроса web-севера с анализом ответа. В-принципе, здесь все ограничено умением написать нужную проверку, потребностями и желанием администратора.

В этой статье отличный пример скрипта написанного на PowerShell, проверяющего состояние Windows-сервиса.

Если у кого есть идеи или готовые скрипты — присылайте мне на eskinv@gmail.com, я их размещу для всеобщего пользования.

Для проверок "сложными" скриптами также можно сделать свои xml, как я говорил выше.

3. Проверка ВМ, связанных с внешним физическим сервером

Все вышеописанные проверки работают для полностью виртуализированных сервисов. Как быть с проверкой ВМ, которые зависят от физических серверов?
Понятно, что если сервер по каким-то причинам остался физическим, то это так и нужно. Потому простой совет — виртуализировать такой сервер — чаще всего не подходит (хотя не редко бывает, что физическим ему оставаться уже и не обязательно).

Опишу концепцию проверки.
Виртуальная лаборатория (VirtualLab) — изолированная среда, потому в нее можно подключить через консоль vClient любую виртуальную машину.

Раз визуализировать сервер не представляется возможным, я предлагаю для проверок воспользоваться "заглушкой" вместо реального сервера. В большинстве случаев физическим остается сервер баз данных, от которого и зависят сервера приложений внутри виртуальных машин. Чаще всего подключение к СУБД прописано на самих серверах приложений по имени или адресу. Для того, чтобы приложение работало необходимо подключение к базе данных. При этом наличие данных, "идентичных натуральному" боевому серверу (в тех же объемах) для работы сервиса (а значит и для проверки) не нужны — база должна содержать только определенную схему, набор таблиц.

Основное требование для работы большинства серверов приложений (application server) — наличие подключения к серверу СУБД со следующими характеристиками:
● определенный IP-адрес или имя;
● база с определенной схемой.

Вот и создав такой сервер-заглушку в виде ВМ с теми же параметрами подключения (адрес и имя) и пустой базой, а затем включив его в соответствующую сеть виртуальной лаборатории, можно решить проблему проверки сервисов приложений.

Замечу. Для серверов БД, нам помогают сами производители СУБД: например, если физический сервер у нас Oracle на AIX, мы можем сделать "заглушку" в виде Oracle Express на Windows/Linux — со стороны приложения подмена ОС и редакции скорее всего не будет видна. Т.е. нет необходимости делать "заглушку" 100% одинаковой с боевой системой.


По такому же принципу можно осуществить проверку и других приложений: главное создать правильную "заглушку".
Это не панацея, но применимо в большинстве случаев. А если вы нашли исключение — делитесь. Во-первых, интересны такие варианты. Во-вторых, может, найдем совместно решение.