Дэйв Бермингем, старший технический евангелист компании SIOS Technology, рассказывает на портале ITPro Today о том, как обеспечить истинную доступность приложений и устойчивость данных в эпоху облачных вычислений.
Облако обещает повсеместный доступ и отказоустойчивость. Можно работать из любого места, получая доступ к критически важным приложениям и данным. Поставщики облачных услуг даже предоставляют соглашения об уровне обслуживания (SLA) для своих кластеров высокой доступности (HA), гарантируя, что хотя бы одна из виртуальных машин (ВМ), на которых работают критически важные приложения, будет доступна не менее 99,99% времени — стандартное определение высокой доступности в отрасли (при этом инфраструктура, поддерживающая ваши критически важные приложения, может быть недоступна не более четырех с половиной минут в месяц).
Но присмотритесь внимательнее. Облачные SLA гарантируют доступ к инфраструктуре, но для вашей организации и ее клиентов действительно важен именно доступ к приложениям и данным. В SLA, гарантирующих уровень отказоустойчивости HA, ничего не говорится о ваших приложениях. Они не гарантируют, что ваши приложения смогут получить доступ к своим критически важным базам данных и взаимодействовать с ними. Другими словами, вы можете столкнуться с ситуацией, когда ВМ работает и соответствует требованиям облачного SLA, но ваше критически важное приложение находится в автономном режиме.
Но не стоит отчаиваться. Вы можете настроить свою облачную инфраструктуру на HA и доступность данных. Для этого не нужно полагаться только на SLA инфраструктуры, которые предоставляют облачные провайдеры.
Настройка доступности приложений
В основе любого обсуждения HA — как в облаке, так и в локальной инфраструктуре — лежит понятие избыточности. Если основная ВМ, на которой запущено приложение, перестает отвечать на запросы — по любой причине, — необходимо, чтобы для выполнения ее рабочих нагрузок была доступна другая ВМ. Одним из способов поддержки этого является кластер обхода отказа, состоящий из двух или более ВМ, одна из которых всегда готова к работе на случай, если основная ВМ перестанет работать. Для настоящей HA эти ВМ следует развернуть в отдельных облачных дата-центрах или зонах доступности (AZ). Таким образом, если масштабное событие, такое как ураган или отключение электричества (или человеческая ошибка, которая, как известно, способна посеять хаос в публичном облаке), отключит весь дата-центр, в котором работает активная ВМ, вторичная ВМ в географически отличном дата-центре вряд ли пострадает и сможет немедленно взять на себя управление. ПО, управляющее отказоустойчивым кластером, заставит задания на первичной ВМ «переключиться» на вторичную ВМ.
Но одного обхода отказа недостаточно. Вторичная ВМ должна иметь доступ к данным, с которыми взаимодействовали приложения на первичном сервере. Например, если вы используете SQL Server, вторичная ВМ должна иметь возможность взаимодействовать с теми же данными, с которыми взаимодействовала первичная ВМ, иначе вторичная ВМ не сможет продолжить работу там, где остановилась первичная.
Хотя облачные провайдеры предлагают варианты общего хранилища, каждое такое решение имеет свои проблемы и ограничения, и во многих случаях оно не по карману. Вместо решения с общим хранилищем вашей инфраструктуре HA может подойти решение, которое синхронно реплицирует все транзакции, происходящие в базе данных на первичной ВМ, на копию базы данных, запущенную на вторичной ВМ. Таким образом, если вторичная ВМ внезапно будет задействована, все данные, которые обрабатывались на первичной ВМ, будут доступны вторичной ВМ, которая сможет немедленно приступить к работе.
Обеспечение доступности данных
Хотя облачные SLA гарантируют высокую доступность хотя бы одной из этих двух ВМ, поставщики облачных услуг не предоставляют механизм репликации данных между ВМ, поэтому ваша организация может не иметь доступа к своим критическим приложениям и данным, когда хотя бы одна ВМ все еще остается доступной. Чтобы получить услуги по репликации данных, которые вам нужны, у вас есть два варианта: либо использовать службы репликации, которые могут быть встроены в ваши приложения, например группы доступности (AG) в SQL Server, либо использовать сторонний инструмент кластеризации без SAN, который будет реплицировать все, что находится в хранилище на первичной ВМ, в хранилище на вторичной ВМ.
По сути, оба подхода обеспечивают синхронную репликацию данных, необходимую для обеспечения постоянного доступа к приложениям и данным со вторичных ВМ. Разница между подходами заключается в деталях. Такое решение, как функция AG в SQL Server, будет реплицировать только данные, связанные с SQL Server. Оно не будет реплицировать другие данные, которые могут находиться в хранилище на первичной ВМ. В то же время подход кластеризации без SAN будет реплицировать все данные из хранилища на первичной ВМ в хранилище на вторичной ВМ.
Если вы рассматриваете инструмент репликации, основанный на базе данных, определите, накладывает ли он ограничения на количество баз данных, которые вы можете реплицировать, или на количество целей, на которые вы можете реплицировать. Например, при использовании функции Basic AG стандартной редакции SQL Server одна группа доступности может реплицировать одну базу данных с именем пользователя на одну вторичную ВМ. Если вы хотите реплицировать несколько баз данных одновременно, вам придется либо настроить несколько AG «один в один», которые могут не работать одновременно в сценарии обхода отказа, либо перейти на функцию Always On AG в SQL Server Enterprise Edition, что может быть очень дорогостоящим апгрейдом, если вы переходите только на функцию репликации. То же самое, если вы хотите реплицировать базу данных SQL Server на несколько вторичных ВМ. Для этого вам потребуется запустить SQL Server Enterprise Edition, даже если вашим приложениям требуется только функциональность SQL Server Standard Edition. В отличие от этого, подход кластеризации без SAN просто реплицирует данные — независимо от количества баз данных или целей репликации.
Таким образом, SLA, предлагаемые поставщиками облачных сервисов, обеспечивают необходимую, но недостаточную защиту для ваших потребностей в HA. Вам необходимо сосредоточиться на репликации данных, чтобы гарантировать, что ваша облачная инфраструктура обеспечивает отказоустойчивость и доступность, на которые рассчитывает ваша организация.
