В зависимости от конфигурации ИТ-службы в компании требования к непрерывности предоставляемых ИТ-услуг могут существенно различаться. Для компании, в которой ИТ является основой бизнеса или производства, например в телерадиокомпании, в сфере услуг ЦОД или банковской, обеспечение требуемого уровня доступности и качества ИТ-сервисов – краеугольный камень успеха.
Кроме обеспечения доступности приходится решать задачи гарантированной сохранности информации, ее целостности, а также множество проблем, связанных с восстановлением работоспособности ИТ-сервисов и обрабатываемой информации.
От компании к компании, в зависимости от специфики бизнеса, с одной стороны, и от степени зрелости ИТ в компании – с другой, подходы к решению вышеуказанных задач и применяемые при этом технологии и методы могут иметь существенные различия.
Катастрофоустойчивая конфигурация как ИТ-инструмент
Обычно, если речь заходит о катастрофоустойчивой конфигурации ЦОДа, ИТ-сервиса, зданий и сооружений, сразу представляется нечто циклопическое, дорогое и недоступное – в большинстве случаев из-за того, что не каждый бизнес может четко сформулировать необходимые и достаточные требования к надежности ИТ и зачастую играет «по полной», доводя решение задачи до абсолюта, а порой и абсурда – применяет двух- и более кратное резервирование систем, строит собственный ЦОД и т. п. Тогда как перед принятием решения о необходимости обеспечения катастрофоустойчивости ИТ-менеджерам следовало бы уточнить ряд вопросов:
- насколько необходимо применение ресурсоемких технологий высокой доступности в конкретной бизнес-среде;
- может быть, недоступность того или иного ИТ-сервиса не стоит потраченных на обеспечение его катастрофоустойчивости средств;
- какова стоимость минуты простоя ИТ-сервиса.
Со стороны бизнеса тоже неплохо бы получить ответ на другие вопросы:
- что является катастрофой для бизнеса;
- имеет ли к этому отношение служба ИТ;
- готов ли бизнес обеспечить ресурсами, кадрами и сервисом катастрофоустойчивое решение.
По итогам анализа подобных вопросов и должно быть принято осознанное и подкрепленное доброй волей руководителей решение. Если бизнес готов взять на себя эту «ношу», можно двигаться дальше и рассматривать подходы к решению задач обеспечения высокой доступности ИТ.
Многослойный пирог
При анализе рабочих конфигураций ИТ-сервисов высокой доступности можно заметить, что зачастую они сформированы по принципу «слоеного пирога». Его основу могут составлять инфраструктурные методы обеспечения высокой готовности, на которых, в свою очередь, базируются методы обеспечения высокой готовности прикладного уровня, являющиеся частью свойств той или иной прикладной системы, сервера приложений, баз данных и т. д.
Рассмотрим некоторые подходы, начав с ряда конфигураций инфраструктур, обеспечивающих высокую доступность наложенных на них ИТ-сервисов.
Конфигурация инфраструктур. Сравнительный анализ
Создание резервного ЦОД меньшего масштаба под задачи резервирования ряда ИТ-услуг
Данный подход следует применять в случаях, когда перед ИТ стоит задача обеспечить катастрофоустойчивость не всего спектра ИТ-услуг, а лишь отдельных из них. Из плюсов метода можно назвать меньшую стоимость относительно варианта с полным резервированием инфраструктуры. Из минусов – возможные проблемы масштабирования решения, когда ЦОД меньшей мощности не будет способен обеспечить резервирование растущих потребностей ИТ. Либо пиковые нагрузки на резервируемые ИТ-сервисы не могут быть обслужены ограниченными ресурсами меньшего ЦОД. Вариант вполне применим как первый шаг в сторону обеспечения ИТ-сервисов высокой готовности, если компания пока не готова «играть» в облачные сервисы, а предпочитает все реализовывать на физическом уровне. Стоимость решения можно снизить, если использовать варианты конфигурации этих ЦОД как active-passive, переводя нагрузку на резервный ЦОД только в случае аварийной ситуации с основным и принося в жертву время на переброску (failover) сервисов на резервный ЦОД.
Полное резервирование всей физической ИТ-инфраструктуры
Подход отличается самой высокой стоимостью, когда оба ЦОД должны развиваться симметрично. Кроме того, для устранения деградации качества сервиса в случае катастрофы с одним из ЦОД второй должен иметь двойной запас производительности, канальной емкости при active-active конфигурации обоих ЦОД. Другими словами, стоимость такой симметричной конфигурации в режиме работы ЦОД active-active в четыре и более раз выше, чем стоимость обычной незадублированной инфраструктуры. Опять же возможна конфигурация active-passive, когда в нормальном режиме второй ЦОД, имея идентичную конфигурацию с основным, простаивает, принимая нагрузку лишь в случае проблем с первым.
Создание гибридного облака на уровне инфраструктуры
Вариант, когда комбинируется физическая и облачная инфраструктуры, с моей точки зрения, самый перспективный. Он позволяет создавать самые различные конфигурации высокой доступности под все «прихоти» ИТ-службы или бизнеса, от 100%-ного резервирования ИТ-сервисов в облаке до резервирования некоторых из них, используя при этом все плюсы эластичности облачного ЦОД, сняв таким образом ограничения на масштабирование второго вычислительного плеча (точнее говоря, переложив эти задачи на компанию – поставщика облачных услуг в случае аренды облака).
Применение гибридного облака требует дополнительных работ по интеграции физической и облачной инфраструктур. Этот вопрос имеет ординарные решения на уровне организации сетевых L3-стыков, поднятия VPN-туннелей достаточной пропускной способности или объединения сетевых сегментов физической и облачной сети Ethernet и SAN.
Облако как failover-сайт
Конфигурация позволяет обеспечить высокую доступность сервисов путем миграции ИТ-сервиса в облако при возникновении проблем с основным сайтом или ИТ-сервисом, находящимся на штатном оборудовании компании. Данная схема вполне бюджетная, поскольку ресурс облака используется только в случае failover и оплата за такой «горячий резерв», как правило, минимальна.
Из минусов необходимо отметить то, что процесс failback не всегда прост (впрочем, как и в случае с физическим failover-ЦОД), если необходима обратная синхронизация, скажем, конфигураций операционных систем из облака на физический сайт компании. Это требует тщательной разработки плана аварийного восстановления после сбоя и «тренировочных полетов» до запуска схемы в производство.
Облако как часть активной ИТ-инфраструктуры
Конфигурация очень удобна, когда необходимо виртуализовать часть ИТ-инфраструктуры. Например, если нужно, с одной стороны, обеспечить катастрофоустойчивость высоконагруженного front-end (скажем, корпоративного сайта банка или торговой интернет-площадки), а с другой стороны, получить достаточный уровень эластичности ресурса. В случае собственного облака целесообразно использовать его и в других корпоративных ИТ-сервисах, чтобы достичь максимальной эффективности и обеспечить утилизацию вычислительных мощностей облачной инфраструктуры.
Из минусов этой конфигурации можно назвать то, что в случае аренды облака бизнес начинает зависеть от стороннего поставщика услуг ИТ-инфраструктуры. Однако если работать на перспективу и рассматривать покупку ИТ-услуг облачной инфраструктуры как неотъемлемую часть современной жизни – ведь бизнес зависит не только от ИТ-сервисов, но и от поставщиков услуг мобильной и городской телефонной связи, электропитания, водоснабжения и водоотведения и т. п., то вынос части инфраструктуры ИТ-сервисов на арендованные мощности выглядит вполне обыденной операцией.
Облако как эластичный катастрофоустойчивый ресурс
Конфигурация подразумевает вынос ИТ-сервисов в облако, которое способно обеспечить катастрофоустойчивость. Данный вариант можно рекомендовать тем компаниям, которые оценили все «за» и «против» ведения бизнеса в облаках. Плюсы очевидны – оплата (в случае аренды) за фактически оказанный объем услуг, гарантированная самими принципами построения облачных сред катастрофоустойчивость. Эластичность, управляемость, прозрачность потребления ИТ-ресурсов – все это имеется в облаке «из коробки».
Конечно же, прежде чем рассматривать арендованное облако как «панацею», следует внимательно ознакомиться с SLA.
Основной минус – арендованное или частное облако вряд ли будет адаптировано под частные технические требования конкретного пользователя. Настроенных на каждую компанию, кастомизированных решений ожидать не следует ввиду ориентированности облачного сервиса на массового потребителя и максимальной стандартизации всех интерфейсов и возможностей. Другими словами, не все ИТ-сервисы можно успешно мигрировать в облако.
Конфигурации наложенных ИТ-сервисов
Как уже было отмечено, катастрофоустойчивость ИТ-сервисов может быть обеспечена средствами инфраструктуры, средствами наложенных ИТ-сервисов или их комбинацией. Рассмотрим способы обеспечения катастрофоустойчивости ИТ-сервисов с применением технологий прикладного уровня. Все они требуют определенного резерва производительности на каждом сайте в зависимости от бизнес-требований по обеспечению уровня производительности ИТ-сервиса.
Глобальная балансировка
Обычно применяется при необходимости обеспечить высокую доступность того или иного сервиса, базирующегося на географически распределенной архитектуре приложения, наложенной на географически распределенную ИТ-инфраструктуру. При этом могут быть обеспечены как оптимизация маршрутов от потребителя сервиса до сервера приложений, так и высокая доступность за счет динамического перераспределения обращений к сервису между доступными серверами приложений с использованием программных или аппаратных балансировщиков четвертого–седьмого уровней.
Локализация клиентов по каждому из сайтов с перераспределением нагрузки в случае аварии
Этот подход является частным случаем глобальной балансировки и может быть использован при наличии двух и более сайтов, высоконадежной связности между сайтами и синхронизации данных между сайтами. При нормальном режиме работы обращения пользователей распределяются между сайтами в соответствии с политиками балансировки и оптимизации нагрузки или маршрутов, но в случае проблем с одним из сайтов вся нагрузка перераспределяется между остальными работоспособными сайтами.
Асимметричное функциональное резервирование
В подобном подходе часть сайтов в нормальном режиме может работать на один характер обработки информации, скажем, на ее прием и хранение. Другие сайты могут быть оптимизированы на ее отдачу по запросу. Все сайты должны обеспечивать синхронизацию информации между собой, чтобы в рамках каждого сайта хранилась информация в целостном виде. В аварийной ситуации функциональные роли могут быть перераспределены между оставшимися работоспособными сайтами или сосредоточены в рамках одного сайта при двухсайтовой конфигурации. Способ требует тщательного проектирования всех процессов (синхронизации сайтов, миграции функций между сайтами, восстановления после сбоя, обеспечения целостности хранимой информации и т. п.) и избыточной производительности каждого из сайтов.
Встроенные в приложения средства обеспечения HA
Этот метод обеспечения высокой доступности использовался еще тогда, когда не существовало технологий виртуализации, технологий высокоскоростной связи между ЦОД и идеологии облаков. Однако средства кластеризации (и сериализации), встроенные в архитектуру прикладных систем, сделают ИТ-сервис по-настоящему катастрофоустойчивым только в том случае, если будут применены катастрофоустойчивые конфигурации ИТ-инфраструктур (резервирование физической ИТ-инфраструктуры, интеграция с облачными решениями или вынос кластеров в облака), ибо кластеризация в рамках одного сайта не способна обеспечить катастрофоустойчивость решения.
Надо заметить, что зачастую возможности обеспечения катастрофоустойчивости с использованием облачных технологий приводят к отходу от классических, более дорогих решений на основе кластеризации, что можно рассматривать как естественный эволюционный процесс в направлении стандартизации подходов к обеспечению высокой доступности ИТ-сервисов.
