Есть 2 обычных сервера EQ4 в разных ДЦ Hetzner, подключенные к сети 100-Мбитными линками, прямой связи между серверами нет. На серверах стоит CentOS и крутятся виртальные машины в основном с серверным ПО. Дополнительно для этих серверов заказаны 2 FailoverIP — ip-адрес, который можно переносить между серверами (посылкой POST-запроса к роботу Hetznera), переключение длится до 15 секунд.
Задача: добавить для 2-х виртуалок (это для начала) отказоустойчивость, т.е. при падении сервера или процесса виртуальной машины, они должны продолжить свою работу на оставшемся сервере. На виртуалках работает корпоративное ПО и хранятся корпоративные данные и поскольку они работают в небезопасном месте, то жесткие диски этих виртуалок зашифрованы, т.е. при запуске виртуальная машина стопорится на вводе пароля для HDD.
Почему VirtualBox? В основном из-за скорости, плюс давно используется на десктопе, поэтому хорошо знакома. Где-то тут читал посты про то, что она не enterprise, но для моих масштабов управляемость нормальная. Если просто поставить в виртуалку систему и забыть (т.е. не проделывать с ней, например, описанных тут действий), то работает без глюков месяцами, а скорость работы очень высокая.
Можно было сделать внутри каждой виртуальной машины heartbeat+drbd, но хотелось сделать более универсальную систему, чтобы не возиться с кучей различных сервисов внутри виртуалок, поэтому нужна была отказоустойчивость для виртуалок.
Поскольку есть опыт создания систем на heartbeat+drbd, да и в рунете есть статья про VirtualBox на drbd, между серверами было создано дисковое устройство на основе drbd с файловой системой ocfs2. Но практика показала, что при связи серверов через внешние каналы, хоть и внутри инфраструктуры Hetzner, drbd работает очень нестабильно, в результате от его использования пришлось отказаться.
Основной принцип созданной системы прост: получение снапшота работающей виртуалки, передача его на второй сервер и восстановление его там. При обнаружении сбоя FailoverIP, связанный с виртуальной машиной, переносится на второй сервер и там запускается вирталка. Снапшоты нужны для того чтоб можно было в автоматическом режиме запустить виртуалку на втором сервере, минуя стадию ввода пароля (в подобных решениях обычно просто синхронизируется диски виртуальных машин и при сбое выполняется полный запуск машины). При этом сервера работают независимо друг от друга, объем передаваемых даныых достаточно небольшой (канала в 100 Мбит хватает для их оперативной передачи). Основной недостаток системы: данные восстанавливаются с задержкой в 2-3 минуты, т.е при сбое будет потеряно 2-3 минуты последних рабочих данных.
Все это реализовано с помощью обычных скриптов для bash с использованием ssh, scp и VboxManage:
1.Каждая виртуалка должна работать под отдельным пользователем. Продиктовано это не только безопасностью, но и механизмом кеширования конфигурации виртуалки сервисным процессом VirtualBoxa — VboxSVC (для каждого пользователя в системе для всех его виртуалок выполняется один такой процесс, который отвечает в общем за управление виртуалками, как показала практика — если он умирает, то умирают и все работающие виртуалки этого пользователя). При передаче снапшота необходимо обновлять конфигурацию виртуальной машины, а нормально сделать это можно только когда VboxSVC не запущен.
2.Все виртуалки работают с host-only сетью (vboxnet). Дать доступ разным пользователям к одному сетевому интерфейсу, например vboxnet0, у меня не получилось, поэтому для каждой виртуалки создается свой vboxnet, все равно потом выход в мир делается через iptables.
3.Самая длительная операция в подготовке к синхронизации виртуалки — это синхронизация основных дисков машины. На рабочей машине делается снапшот, при этом VirtualBox создает разностный диск и в дальнейшем записывает изменения только в него, а основной диск (размеров в десятки Гбайт) монтируется в режиме read-only и его можно спокойно копировать на второй сервер.
4.Наконец, запускается бесконечный цикл в котором после проверки того, что виртуалка работает, делается ее снапшот, он копируется на второй сервер, локально удаляется предыдущий снапшот, на второй сервер копируется предыдущая конфигурация виртуалки (файлик с расширением vbox-prev — получается что в нем описаны виртуалка и 2 ее снапшота), на втором сервере регистрируется виртуальная машина с этой конфигурацией, в ней удалется предыдущий снапшот и виртуалка дерегистрируется.
5.За доступностью виртуалок и серверов следит monit. Сервер проверяется просто пингами, а виртуалка — по TCP порту основного сервиса (например apache или tomcat). При обнаружении сбоя на резервном сервере регистрируется виртуалка, выполняется откат к последнему снапшоту (чтобы получить нужное состояние памяти), виртуалка запускается и на этот сервер переносится FailoverIP. Потом, когда второй сервер поднимается, запускается синхронизация основных дисков виртуалок и процесс передачи снапшотов, но уже в обратном направлении. Для удобства наблюдения за процессом monitы серверов прикручены к m/monit.
При создании системы проявилась очень неприятная ошибка VirtualBox (она уже где-то с полгода есть в их баглисте, хочется верить что скоро исправят) — если используются виртуалки с SMP, то они наглухо зависают при получении 5-10 снапшота с момента ее запуска, а виртуалка с одним СPU работает нормально.
Система работает стабильно, постоянное получение/удаление снапшотов на скорости виртуалки никак не сказывается, разве что на резервном сервере на дисковый IO немного влияет постоянная запись снапшотов по сети.
Задача: добавить для 2-х виртуалок (это для начала) отказоустойчивость, т.е. при падении сервера или процесса виртуальной машины, они должны продолжить свою работу на оставшемся сервере. На виртуалках работает корпоративное ПО и хранятся корпоративные данные и поскольку они работают в небезопасном месте, то жесткие диски этих виртуалок зашифрованы, т.е. при запуске виртуальная машина стопорится на вводе пароля для HDD.
Почему VirtualBox? В основном из-за скорости, плюс давно используется на десктопе, поэтому хорошо знакома. Где-то тут читал посты про то, что она не enterprise, но для моих масштабов управляемость нормальная. Если просто поставить в виртуалку систему и забыть (т.е. не проделывать с ней, например, описанных тут действий), то работает без глюков месяцами, а скорость работы очень высокая.
Можно было сделать внутри каждой виртуальной машины heartbeat+drbd, но хотелось сделать более универсальную систему, чтобы не возиться с кучей различных сервисов внутри виртуалок, поэтому нужна была отказоустойчивость для виртуалок.
Поскольку есть опыт создания систем на heartbeat+drbd, да и в рунете есть статья про VirtualBox на drbd, между серверами было создано дисковое устройство на основе drbd с файловой системой ocfs2. Но практика показала, что при связи серверов через внешние каналы, хоть и внутри инфраструктуры Hetzner, drbd работает очень нестабильно, в результате от его использования пришлось отказаться.
Основной принцип созданной системы прост: получение снапшота работающей виртуалки, передача его на второй сервер и восстановление его там. При обнаружении сбоя FailoverIP, связанный с виртуальной машиной, переносится на второй сервер и там запускается вирталка. Снапшоты нужны для того чтоб можно было в автоматическом режиме запустить виртуалку на втором сервере, минуя стадию ввода пароля (в подобных решениях обычно просто синхронизируется диски виртуальных машин и при сбое выполняется полный запуск машины). При этом сервера работают независимо друг от друга, объем передаваемых даныых достаточно небольшой (канала в 100 Мбит хватает для их оперативной передачи). Основной недостаток системы: данные восстанавливаются с задержкой в 2-3 минуты, т.е при сбое будет потеряно 2-3 минуты последних рабочих данных.
Все это реализовано с помощью обычных скриптов для bash с использованием ssh, scp и VboxManage:
1.Каждая виртуалка должна работать под отдельным пользователем. Продиктовано это не только безопасностью, но и механизмом кеширования конфигурации виртуалки сервисным процессом VirtualBoxa — VboxSVC (для каждого пользователя в системе для всех его виртуалок выполняется один такой процесс, который отвечает в общем за управление виртуалками, как показала практика — если он умирает, то умирают и все работающие виртуалки этого пользователя). При передаче снапшота необходимо обновлять конфигурацию виртуальной машины, а нормально сделать это можно только когда VboxSVC не запущен.
2.Все виртуалки работают с host-only сетью (vboxnet). Дать доступ разным пользователям к одному сетевому интерфейсу, например vboxnet0, у меня не получилось, поэтому для каждой виртуалки создается свой vboxnet, все равно потом выход в мир делается через iptables.
3.Самая длительная операция в подготовке к синхронизации виртуалки — это синхронизация основных дисков машины. На рабочей машине делается снапшот, при этом VirtualBox создает разностный диск и в дальнейшем записывает изменения только в него, а основной диск (размеров в десятки Гбайт) монтируется в режиме read-only и его можно спокойно копировать на второй сервер.
4.Наконец, запускается бесконечный цикл в котором после проверки того, что виртуалка работает, делается ее снапшот, он копируется на второй сервер, локально удаляется предыдущий снапшот, на второй сервер копируется предыдущая конфигурация виртуалки (файлик с расширением vbox-prev — получается что в нем описаны виртуалка и 2 ее снапшота), на втором сервере регистрируется виртуальная машина с этой конфигурацией, в ней удалется предыдущий снапшот и виртуалка дерегистрируется.
5.За доступностью виртуалок и серверов следит monit. Сервер проверяется просто пингами, а виртуалка — по TCP порту основного сервиса (например apache или tomcat). При обнаружении сбоя на резервном сервере регистрируется виртуалка, выполняется откат к последнему снапшоту (чтобы получить нужное состояние памяти), виртуалка запускается и на этот сервер переносится FailoverIP. Потом, когда второй сервер поднимается, запускается синхронизация основных дисков виртуалок и процесс передачи снапшотов, но уже в обратном направлении. Для удобства наблюдения за процессом monitы серверов прикручены к m/monit.
При создании системы проявилась очень неприятная ошибка VirtualBox (она уже где-то с полгода есть в их баглисте, хочется верить что скоро исправят) — если используются виртуалки с SMP, то они наглухо зависают при получении 5-10 снапшота с момента ее запуска, а виртуалка с одним СPU работает нормально.
Система работает стабильно, постоянное получение/удаление снапшотов на скорости виртуалки никак не сказывается, разве что на резервном сервере на дисковый IO немного влияет постоянная запись снапшотов по сети.