Важным аспектом при построении IT-инфраструктуры любой сложности является ее устойчивость к различным инцидентам. К сожалению, полностью исключить ошибки, вызванные аппаратной или программной неисправностью, а также человеческими действиями (случайными или преднамеренными), увы, невозможно. Поэтому всегда необходимо иметь четко отработанный план по восстановлению. Раз мы ведем речь в контексте использования СХД, то наиболее уязвимыми здесь являются как раз хранимые на ней данные.

Один из основных способов - восстановление из резервной копии. Но, помимо этого, существуют и другие способы сохранения инфраструктуры в рабочем состоянии, а именно – репликация.

Для начала стоит прояснить, от чего мы защищаемся и каким образом будем действовать в случае инцидента.

Резервное копирование – это холодная копия данных на определенный момент времени. Неоспоримым плюсом является неизменность этой копии и возможность откатиться на нее в случае аварии. Очевидным минусом же является прежде всего долгое время восстановления. И чем медленнее носитель данных, на котором хранится резервная копия, тем дольше мы будем ждать, когда наши сервисы будут снова доступны. Также не стоит забывать о порой значительном значении RPO (Recovery point objective, максимальный период, за который могут быть потеряны данные). Данный показатель можно сократить за счет увеличения частоты создания резервных копий. Но он все равно не будет нулевым.

В качестве альтернативы существуют различные варианты репликации.

Асинхронная репликация. В этом случае ввод/вывод производится на основную СХД, где периодически создаются снапшоты согласно заданному расписанию. Затем очередной снапшот копируется на резервную СХД. В случае сбоя на основной СХД администратор всего лишь переключает ввод/вывод с хостов на резервную СХД для возобновления работы. По сравнению с восстановлением из резервной копии, показатель RTO (Recovery time objective, время восстановления после аварии) будет значительно ниже, хоть и RPO будет соизмеримым.

Синхронная репликация. Здесь ввод/вывод также производится на основную СХД, а затем только что записанные данные дублируются на резервную СХД. То есть, по сути, мы получаем двойную запись в итоге. В случае сбоя на основной СХД администратор также всего лишь переключает ввод/вывод с хостов на резервную СХД для возобновления работы. В этом случае RPO уже будет нулевым (в реальности все же почти нулевым, так как данные из кэша основной СХД могут не успеть скопироваться на резервную), а показатель RTO будет предельно низким.

Важное замечание. Несмотря на некоторое преимущество репликации над резервным копированием касательно показателей RTO/RPO, она не отменяет создание резервных копий при наличии действующей репликации. Ведь резервная копия – это прежде всего холодная копия данных, которая уже не подвержена изменению и может храниться на отчуждаемых носителях для большей сохранности. В отличие от этого синхронная репликация – это зеркальная копия действующей системы. И если, например, данные удалены на основной СХД, они также будут отсутствовать на резервной. Поэтому важно использовать и репликацию, и резервное копирование.

Безусловным лидером в нелегком деле построения максимально отказоустойчивой системы в применении к СХД, конечно, является синхронная репликация. Ниже мы приведем пример настройки синхронной репликации между двумя СХД Qsan XCubeSAN/XCubeFAS при подключении к хостам под управлением VMware.

На основной СХД необходимо создать том и добавить его в соответствующую хост группу. Затем, на стороне хоста обнаружить новое дисковое устройство и создать на нем Datastore (в примере используется интерфейс iSCSI).

После этого можно приступать к настройке синхронной репликации на основной СХД. Это можно сделать в автоматическом режиме, указав всего лишь IP и credentials резервной СХД, либо вручную для получения большего контроля над процессом. Важным моментом при настройке репликации вручную является то, что целевой том на резервной СХД должен иметь тип Backup, тогда как обычные тома имеют тип RAID. Переключение типа осуществляется в свойствах тома.

После того, как произойдет первичная синхронизация содержимого между двумя СХД, дальнейшая репликация продолжается в режиме реального времени.

Для имитации отказа основной СХД достаточно остановить ввод/вывод с хостов и задание по репликации.

После этого необходимо на резервной СХД обратно переключить тип тома с Backup на RAID и добавить его в хост группу к хостам. При монтировании тома на стороне хоста важно оставить существующую сигнатуру Datastore. А затем можно импортировать имеющиеся там виртуальные машины.

В рамках данной статьи мы постарались осветить ряд важных моментов касательно построения отказоустойчивой IT-инфраструктуры с использованием механизма репликации средствами СХД. Разумеется, в реальной жизни прочтение короткой статьи может оказаться недостаточным для учета всех возможных нюансов. Поэтому мы настоятельно рекомендуем самостоятельно знакомиться с документацией производителей как СХД, так и прикладного ПО. Также не стоит забывать о помощи со стороны поставщиков подобного решения. Мы, как специалисты, обладающие подобными знаниями и навыками, имеющие колоссальный опыт, а также являющиеся старейшим дистрибьютером Qsan на территории РФ, всегда готовы помочь своим заказчикам на всех этапах построения и внедрения IT-инфраструктуры.