Запуск критически важных приложений в облаке возможен при правильных стратегии и архитектуре. Речь о настройке виртуальных машин (ВМ), отказоустойчивого кластера и репликации данных, пишет на портале Network Computing старший технический евангелист SIOS Technology Дэйв Бермингем.
Многие организации, управляющие собственной инфраструктурой, пытаются создать среду высокой доступности (High Availability, HA), в которой приложения будут доступны не менее 99,99% времени, используя несколько серверов или ВМ, сконфигурированных как отказоустойчивый кластер. Так чтобы, например, если узел кластера, на котором запущено критически важное приложение, выходит из строя, вторичный узел мог мгновенно взять на себя управление и продолжить работу с того места, где остановился поврежденный узел.
Такие отказоустойчивые кластеры обычно опираются на сеть хранения (SAN) для совместного хранения данных. Однако сама по себе общая сеть SAN представляет единую точку отказа, которая может поставить под угрозу высокую доступность. Если она выйдет из строя, SQL-база данных, поддерживающая критически важные системы, окажется недоступной, и уже не имеет значения, сколько узлов могут быть готовы к взаимодействию с ней.
Для организаций, рассматривающих облако в качестве среды HA-приложений, существует еще более насущная проблема: хотя некоторые поставщики облачных решений предлагают варианты совместного хранения данных, не все они гарантируют 99,99%-ную доступность. Значит ли это, что вам нужно отказаться от облака как варианта среды для HA-приложений? Нет, это означает, что просто нужно переосмыслить конфигурацию отказоустойчивого кластера.
Понимание высокой доступности в облаке
Первое, что нужно знать об облаке, — это то, что там очень легко создавать и настраивать новые ВМ. На самом деле, крупные облачные провайдеры позволяют легко создавать HA-кластеры, состоящие из нескольких ВМ, работающих в разных дата-центрах, также известных как зоны доступности. Настраивая ВМ в нескольких зонах, вы устраняете риск того, что катастрофа в масштабах зоны может вывести из строя всю вашу критически важную инфраструктуру.
Но если внимательно прочитать соглашения об уровне обслуживания (SLA) основных облачных провайдеров, можно заметить важную оговорку: они гарантируют, что после настройки своего HA-кластера с ВМ в нескольких зонах вы сможете получать доступ хотя бы к одному из этих узлов не менее 99,99% времени. Это не гарантирует, что ваше приложение будет работать, а только то, что вы сможете получить доступ к одной из ВМ. Это критическое различие, которое напоминает о проблеме с SAN: не имеет значения, доступ к скольким ВМ у вас имеется, если ваши приложения не могут получить доступ к данным.
Делитесь данными, а не хранилищем
Это возвращает нас к вопросу переосмысления конфигурации отказоустойчивого кластера в облаке. Если вы рассчитываете, что любая ВМ в нем сможет взять на себя производственные рабочие нагрузки в случае сбоя — а именно для этого вы и развернули HA-решение — вам необходимо сконфигурировать каждую ВМ с собственным хранилищем. Более того, нужен механизм, который будет активно реплицировать данные из хранилища на активном узле кластера на вторичные узлы. Таким образом, если активная ВМ по какой-либо причине выйдет из строя, кластер сможет переключиться на вторичную ВМ, на которой есть все данные, необходимые для восстановления работоспособности приложения в течение нескольких секунд.
Существует целый ряд решений для репликации данных, которые могут предоставить службы, необходимые организации для обеспечения истинной высокой доступности приложений в облачном развертывании. Для начала обратите внимание на синхронные службы репликации на уровне блоков. Синхронность гарантирует, что все транзакции, записанные в хранилище на первичной системе, будут также записаны в хранилища на вторичных системах до того, как транзакция будет считаться завершенной. Репликация на уровне блоков также важна, поскольку она гарантирует, что любые данные, записанные в первичное хранилище, будут реплицированы во вторичное хранилище.
Если ваша основная облачная инфраструктура поддерживает более одного приложения, или если вы используете ее хранилище в качестве репозитория для нескольких приложений, все данные — а не только данные, связанные с SQL-базой данных — будут реплицированы на вторичную инфраструктуру, где они будут доступны для любых приложений или пользователей, если вторичная инфраструктура будет неожиданно задействована.
