Наш мир устроен так, что ничто не вечно под Луной. Другими словами, абсолютно все может прийти в негодность. Ну или, применительно к IT отрасли, может дать сбой. IT индустрия буквально пропитана идеей резервирования всего и вся ради обеспечения непрерывности работы и доступности сервисов. Начинаем с дублирования компонентов в рамках отдельной «железки», далее выполняем дублирование самих серверов, строим кластеры, резервируем каналы связи, осуществляем территориальное распределение и так далее. Все это напоминает спираль, где каждый новый виток означает очередное дублирование уже имеющейся IT инфраструктуры на более высоком уровне. Вопрос лишь в том, когда происходит остановка. Ведь давно уже не секрет, что очередная девятка после запятой в числовом значении доступности сервиса означает увеличение стоимости решения на порядок (то есть в 10 раз!).
Безусловно, всем хочется максимально продвинутую систему. Но часто приходится идти на компромиссы, сознательно отказываясь от тех или иных функций в угоду стоимости. Причем, зачастую это означает ухудшение в плане автоматизации, а не надежности. И, главное, решает основную задачу по резервированию IT инфраструктуры.
В рамках данной статьи хотелось бы затронуть вопрос построения отказоустойчивого решения на базе двух территориально разнесенных СХД, которые работают в составе кластера под управлением VMware vSphere. Основной идеей, разумеется, является минимизация затрат на осуществление проекта. И потому решение будет основываться на базе СХД производства QSAN Technology. Бюджетность решения заключается в том, что помимо самих СХД и VMware vSphere ничего не понадобится, то есть никаких затрат на дополнительное ПО и/или лицензии не требуется.
Ряд конфигурационных вопросов будет опущен, дабы не перегружать статью. Тем более, что эти моменты подробным образом освещены в одной из предыдущих наших статей.
В качестве основы для решения будет использоваться функционал асинхронной репликации, который имеется у СХД и All Flash QSAN серий XCubeSAN и XCubeFAS. Данный функционал является базовым и, как уже упоминалось выше, не требует отдельного лицензирования.
Подразумевается, что все хосты с гипервизорами имеют физическую и логическую связь с обеими СХД через iSCSI/Fibre Channel. Весь ввод/вывод с хостов идет только на основную СХД. СХД, в свою очередь, общаются друг с другом посредством iSCSI для репликации по расписанию с основной на резервную.
Так как в такой схеме от хостов до резервной СХД можно дотянуть высокоскоростной интерфейс, то и между СХД разумно использовать максимально возможную скорость подключения. Напомним, что в базе СХД имеют медные порты 10GbE, которые удобно использовать для этой цели. В общем случае порты iSCSI могут использоваться совместно как для целей ввода/вывода, так и для репликации. Если стоит задача тотальной экономии, то можно воспользоваться этой особенностью. Но для лучшего результата, конечно же, лучше использовать выделенные порты.
В таком случае алгоритм работы будет следующий:
Создаются снапшоты виртуальных машин средствами VMware
Происходит репликация тома средствами СХД
Созданные ранее снапшоты виртуальных машин удаляются как уже не нужные
Если происходит отказ резервной СХД, то для продолжения работы кластера предпринимать ничего не требуется. Если же отказывает основная СХД, то администратору необходимо переключить работу хостов на резервное хранилище. Отметим, что некоторый ручной труд как раз и является компенсацией за, по сути, нулевую стоимость решения.
При начальной настройке у всех виртуальных машин, расположенных на реплицируемом томе, создаются по одному снапшоту. Затем на основной СХД настраивается связь с резервной:
Создается том, размером не меньше исходного, с типом Backup
Резервный том публикуется для доступа через iSCSI
На исходном томе назначается место для хранения снапшотов. Оно фактически резервируется на свободном пространстве того же пула. Следует внимательно отнестись к данному шагу, так как при нехватке места снапшот не создастся, и репликация остановится.
На исходной СХД задаются параметры связи с резервной (IP, credentials, используемые физические порты и прочее)
Создается расписание, по которому будет происходить репликация
В теории СХД QSAN позволяют осуществлять репликацию с минимальными интервалами в 15 мин. Но создавая расписание, нужно учитывать объем передаваемой информации, накопленной между двумя моментами репликации, а также производительность дисковой подсистемы на основной и резервной СХД. Пропускная способность канала связи здесь также играет роль. Но, как уже отмечалось ранее, в данном случае она скорее всего будет максимально возможной.
Так как репликация запускается впервые, происходит полное копирование тома, что может занять значительное время. По окончании данного процесса необходимо создать расписание по созданию снапшотов виртуальных машин средствами VMware. Следует учитывать, что эти снапшоты должны создаваться до того, как начнется репликация тома. Так как VMware при работе со снапшотами использует технологию Redirect-on-Write, они создаются фактически мгновенно. Однако, небольшой временнОй лаг не помешает.
Так как VMware не имеет встроенного механизма ротации снапшотов, следует самостоятельно ограничить их максимальное количество у каждой ВМ до двух штук. Для этого на соответствующем Datastor создаем папку Crontabs, в которую загружаем скрипт (назовем его SnapshotAutoDelete.sh)
LOG_PATH="/var/log/Schedule_Snapshot.log"
[ -f "$LOG_PATH" ] && rm $LOG_PATH;
QTY=2 # Reserved quantity
for i in `vim-cmd vmsvc/getallvms 2>/dev/null | awk '{print $1}' | grep -e "[0-9]"`
# Grab all Vmid on esxi
do
SNAPSHOT_COUNT=`vim-cmd vmsvc/snapshot.get $i | egrep -- '--\|-CHILD|^\|-ROOT'
| wc -l`
GuestName=$(vim-cmd vmsvc/get.summary $i | grep name | awk '{ print $3 }' | cut
-d \" -f 2)
if [ $SNAPSHOT_COUNT -gt $QTY ]; then # If the number of snapshots is greater
than the number of reservations
DELETE_COUNT=$(($SNAPSHOT_COUNT-$QTY))
OLD_SNAPSHOT_ID=`vim-cmd vmsvc/snapshot.get $i | grep Id | head -
$DELETE_COUNT | awk -F: '{print $2}'`
for n in $OLD_SNAPSHOT_ID
do
vim-cmd vmsvc/snapshot.remove $i $n; ret=$?
sleep 30s
if [ $ret -eq 0 ];then
echo "$(date "+%F %T") : $GuestName snapshot $n Delete
Success.." >> $LOG_PATH # Output to log path after deletion
else
echo "$(date "+%F %T") : $GuestName snapshot $n Delete
FAILED.." >> $LOG_PATH
fi
done
else
echo "$(date "+%F %T") : $GuestName snapshot not found." >> $LOG_PATH
fi
done Далее необходимо изменить права на полный доступ (777) к данному файлу через консоль гипервизора ESXi (можно также воспользоваться сессией через ssh, предварительно разрешив такой вид доступа в настройках firewall).
И наконец, необходимо создать задачу на периодическое выполнение скрипта. Определяем UUID нужного Datastor:
# esxcli storage filesystem list
Добавляем задачу в локальный файл конфигурации /etc/rc.local.d/local.sh
# vi /etc/rc.local.d/local.sh
...
/bin/echo "30 23 * * * sh /vmfs/volumes/5d445d0a-fae8654e-a676-00lb2ld4d680/Crontabs/SnapshotAutoDelete.sh" >>/var/spool/cron/crontabs/root
/bin/kill $(cat /var/run/crond.pid)
/usr/lib/vmware/busybox/bin/busybox crondЗдесь 30 23 – это локальное время хоста ESXi 23:30 (для примера), когда следует начать удаление лишних снапшотов. Время выполнения скрипта выбирается с таким расчетом, чтобы лишние снапшоты успели удалиться до начала следующей итерации. Если в этот момент внутри ВМ происходит большое число операций записи, следует учесть, что снапшоты будут удаляться отнюдь не спешно.
Теперь остается добавить к хостам возможность связи с резервной СХД на случай аварии. Если используется Fibre Channel, то достаточно просто прописать соответствующий зоннинг на коммутаторах. В случае же iSCSI на хостах следует добавить в инициаторы IP адреса резервной СХД.
Допустим, основная СХД не важно по какой причине отказала. У хостов пропала связь с Datastor. В этом случае администратор на резервной СХД меняет тип тома с Backup на RAID и публикует его для хостов. Хосты после команды Rescan all обнаруживают Datastor, который следует примаппить с опцией Use an Existing signature. После чего следует произвести импорт всех ВМ, расположенных на томе. Важно, что перед стартом машин необходимо произвести откат на один снапшот назад. Это обязательно необходимо сделать, чтобы исключить любую неконсистентность внутри ВМ из-за того, что на момент репликации часть ее кэша располагалась в ОЗУ гипервизора. Откат на предыдущий снапшот гарантированно исключит такую возможную проблему, в результате чего ВМ сможет запуститься без ошибок.
Построение решения класса Disaster recovery уже давно не является проблемой. Однако, зачастую требуется покупка дорогостоящего программного обеспечения. С помощью встроенных средств VMware vSphere, технологий СХД QSAN и небольших трудозатрат со стороны администратора можно решить данную проблему без дополнительных капиталовложений.
Компания Skilline является официальным дистрибутором и авторизованным сервисным центром QSAN на территории РФ. Будем рады ответить на все интересующие вопросы и поделиться накопленным опытом.
