ЦОД. Часть 4

Организации в силу специфики своей деятельности часто решают использовать два ЦОД. В этом случае возможны два основных сценария применения второго ЦОД:

• в качестве площадки для хранения резервной копии данных основного ЦОД;
• полноценный с функциональной точки зрения ЦОД, аналогичный основному ЦОД.

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

Второй сценарий выбирают организации, для которых непрерывное ведение операций является критически важным условием осуществления своей деятельности. Очевидно, что в этом случае в обоих ЦОД должны «работать», по крайней мере, по одному экземпляру критических для данной организации приложений. Что понимается под термином «работать»?

Опять-таки, возможны два варианта. В рамках первого из них экземпляр приложения во втором ЦОД не выполняет никакого объема работы по обработке запросов – он лишь запущен и готов к обслуживанию нагрузки, или для него подготовлены условия для более или менее быстрого запуска. Однако важно, чтобы набор данных во втором ЦОД был синхронизирован с набором данных в основном ЦОД, что в случае аварийной ситуации в основном ЦОД позволяет продолжить работу с момента остановки – с точки последней успешно выполненной транзакции. Для создания синхронизированных наборов данных могут быть выбраны различные, хорошо известные, способы, хотя мне в большей степени импонирует образование «зеркальных» томов с помощью технологии виртуализации дисковых систем хранения на базе сети хранения (Network-based Storage Virtualization). Почему мне нравится именно эта технология? Да потому, что в случае отказа основного тома данных она позволяет «на лету» переправить на «зеркальный» том обращение экземпляра приложения на чтение-запись, при этом экземпляр приложений даже «не заметит», что работает не с основным, а с «зеркальным» томом. Как бы то ни было, для того чтобы экземпляр приложения во втором ЦОД смог принимать и отвечать на запросы администратору в общем случае требуется выполнить примерно следующую последовательность действий: запустить экземпляр приложения, если он до этого не был запущен вручную или автоматически; сделать привязку этого экземпляра к новому, «зеркальному», тому данных; обеспечить условия для перенаправления запросов на обслуживание (Service Request Routing) на готовый к работе экземпляр приложения. На осуществление этих действий администратору может потребоваться несколько минут, а скорее всего, несколько десятков минут. Но все равно это значительно лучше, чем те несколько часов, которые требовались для восстановления работоспособности в предыдущем сценарии.

Однако для некоторых организаций и такой период восстановления работоспособности может оказаться неприемлемым. Поэтому ими применяется иной подход, предусматривающий, что находящиеся в разных ЦОД экземпляры приложения обрабатывают запросы одновременно. Для этого, во-первых, необходимо обеспечить либо целостность данных в случае, если несколько экземпляров приложения работают с одним и тем же томом данных, предоставляемым дисковым массивом одного из ЦОД, либо идентичность – синхронизацию – данных в случае, если каждый экземпляр приложения обращается к своему тому данных, организованному в дисковой подсистеме этого же ЦОД. Первый случай, кстати, при некоторых допущениях может оказаться вполне рабочим. Второй случай, конечно же, имеет более высокую степень сохранения работоспособности. И, во-вторых, необходимо реализовать динамическую балансировку между экземплярами приложений в разных ЦОД запросов на обслуживание. При этом с целью обеспечения целостности данных необходимо обеспечить направление запросов на обслуживание, составляющих одну транзакцию, к одному и тому же экземпляру приложения. Выбор подходящего метода решения этой задачи зависит от нескольких факторов, например, от способа адресации приложения, от применяемых протоколов при организации сессий. Как бы то ни было, как правило, сразу несколько различных методов реализуются в устройствах, относящихся к классу балансировщиков – GSLB (Global Server Load Balancing) и SLB (Server Load Balancing). Выбор одного из них диктуется конкретными условиями данной информационной инфраструктуры и осуществляется на стадии ввода в действие технического решения. Соблюдение этих двух условий – синхронизация томов данных и балансировка запросов – является обязательным для того, чтобы оба ЦОД могли функционировать в режиме «активный — активный», что, по существу, означает способность организации обеспечить непрерывность ведения операций даже в случае возникновения нештатных ситуаций.

Однако функционирование приложений в ЦОД может происходить и в виртуальных средах. А вот в этом-то случае возникает несколько особенностей, которые следует учитывать и о которых и поговорим в следующей части.