Данный документ содержит текущие варианты развертывания приложений в CloudHub 2.0 в соответствии с высокими требованиями к доступности и послеаварийному восстановлению. Он использует регион США в качестве примера и может быть применен к другим регионам.

CloudHub 2.0 - это полностью управляемая облачная платформа интеграции, которая устраняет инфраструктуру за счет автоматизации развертывания, масштабирования и управления MuleSoft API и интеграциями в облаке. Это современная платформа облачного развертывания MuleSoft, работающая на инфраструктуре Amazon AWS.

В большинстве случаев достаточно стандартных параметров «Высокая доступность» (HA) и «Аварийное восстановление» (DR), предоставленных CloudHub 2.0. CloudHub 2.0 предоставляет ОВД и ДР на региональном уровне (дополнительную информацию см. в разделе «Сценарии сбоя CloudHub 2.0»). Раздел «Ключевые рекомендации CloudHub 2.0» предоставляет дополнительные сведения о поддерживаемых CloudHub-2.0 АБ и DR.

Условия, требующие создания вне стандартной доступности CloudHub 2.0, включают:

• Приложение должно обеспечить отсутствие потери данных в сценарии катастрофы (например, выход из строя региона Amazon).
• Приложение зависит от объекта «Магазин» и должно обеспечить непрерывность, если область развертывания падает.

• Базовые системы настроены на эквивалентную доступность. CloudHub 2.0 иногда может обеспечить надежность посредством очередей или аналогичных механизмов, но независимо от того, является ли интеграция асинхронной или в реальном времени, базовые системы должны поддерживать сопоставимый уровень АБ и ДР.
• Если сбой на уровне региона AWS влияет на базовые системы, их восстановление выполняется параллельно с восстановлением CloudHub 2.0.
• Настройка личного пространства завершена в нескольких регионах.

Параметры дизайна в этом руководстве сосредоточены на решениях для доступности приложения в CloudHub 2.0, когда вся зона или регион доступности AWS становится недоступной.

В настоящем руководстве эти сценарии восстановления не рассматриваются, хотя в нем и отмечаются соответствующие последствия:

• Восстановление базовых систем, приложений, баз данных, компонентов сети и центров обработки и хранения данных, управляемых и инициализированных вне Anypoint CloudHub, как в локальной среде, так и в облаке.
• Восстановление VPN-ссылок между CloudHub 2.0 и личным центром обработки и хранения данных клиента (например, туннели IPsec и шлюзы VPN). Некоторые параметры DR в этом руководстве могут частично учитывать эти сценарии.
• Изменения в IP-адресах выхода MuleSoft во время аварийного восстановления, когда добавление в список разрешенных IP-адресов используется для интеграций. Некоторые параметры DR в этом руководстве могут частично учитывать эти сценарии.
• Внешние системы службы сообщений, используемые в клиентских решениях, будь то предоставленные MuleSoft (например, Anypoint MQ) или другими поставщиками (например, AWS MSK или Heroku Kafka).

При оценке CloudHub 2.0 на наличие требований послеаварийного восстановления ознакомьтесь с данными ключевыми рекомендациями.

Зависимость CloudHub 2.0 от региональной доступности AWS

• CloudHub 2.0 работает в AWS; его доступность связана с регионами AWS.
• Развертывания и доступность приложения систематизированы по регионам. Эти регионы соответствуют регионам AWS.

При сбое целого региона AWS приложения в этом регионе недоступны и не реплицируются автоматически в других областях.

Высокая доступность приложения (HA) и управление репликами

• CloudHub 2.0 автоматически развертывает приложения в одном регионе при сбое аппаратного обеспечения, но приложение с одной репликой может столкнуться с простоем.
• Приложения с несколькими репликами развертываются в отдельных зонах доступности по умолчанию, предоставляя АБ в зонах.
• Если зона доступности для приложения с одной репликой не удается, приложение автоматически открывается в другой зоне доступности в этом же регионе.

Специальное влияние Восточного региона США

• В случае сбоя Восточного региона США:
  • Пользовательский интерфейс управления CloudHub 2.0 и службы REST развертывания недоступны, и новые приложения не могут быть развернуты.
  • Приложения в других регионах остаются незатронутыми в большинстве сценариев сбоев. Эти приложения продолжают работать в обычном режиме, однако возможности мониторинга и управления посредством самолета управления будут недоступны во время сбоя.
  • Модули Core CloudHub 2.0 (например, параметры приложения) сохраняются на Востоке США, поэтому параметры не могут быть изменены во время сбоя.

Мониторинг и предупреждение

• Настройте оповещение о сбоях зоны доступности или региона посредством status.mulesoft.com.
• Используйте отдельный механизм проверки состояния и оповещения за пределами CloudHub 2.0, чтобы рабочие группы получали уведомления в случае сбоя реплик или прекращения ответа приложений.

Сохранение данных (магазин объектов V2)

• Магазин объектов V2 связан с регионом первого развертывания приложения.
• При перемещении приложения в другой регион, Object Store V2 остается в исходном регионе во избежание потери данных.
• Если регион развертывания Object Store V2 не удается, магазин объектов недоступен.

Контроллеры доступа и личные пространства

• Контроллеры выполнения CloudHub 2.0 широко доступны на уровне региона.
• В общем пространстве, если одна область не работает, контроллер выполнения в другой области остается доступным, но может обслуживать только приложения, развернутые в этой области.
• В личном пространстве, если область не удается, контроллеры входа в других регионах недоступны, если они не настроены заранее.
• Настройка личного пространства является региональной; если область не удается, личное пространство недоступно, если не настроен другой регион.

Общие сведения о снижающемся сценарии служб платформы – магазин объектов

Высокая доступность (HA) - это показатель способности системы оставаться доступной в случае сбоя компонента системы. Как правило, АБ внедряется посредством встроенных в систему возможностей сбоустойчивости и/или балансировки нагрузки нескольких уровней. Как правило, это конфигурация Active-Active, которая приводит к ограниченному влиянию на бизнес-службы или не влияет вообще.

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

Если региональная высокая доступность или региональное аварийное восстановление желательно уменьшить влияние на бизнес в случае региональной ошибки AWS, учитывайте следующие моменты при создании решения в MuleSoft CloudHub 2.0:

• Реплики CloudHub 2.0 и связанные возможности (личные пространства, контроллеры входа и назначения Anypoint MQ) зависят от региона.
• При сбое целого региона AWS все реплики и связанные службы в этом регионе становятся недоступными.
• После восстановления региона конфигурации восстанавливаются; необходимо перезапустить приложения.
• Если Восточный регион США не удается, службы платформы Anypoint Platform (например, управление доступом и менеджер среды выполнения) также недоступны.
• MuleSoft предоставляет SLA 99,95% доступности для служб платформы, включительно с репликами CloudHub 2.0 в активно активной конфигурации в регионе; см. последние сведения об облачном предложении MuleSoft SLA.
• CloudHub 2.0 не поддерживает многорегиональный АБ или DR в готовом виде; доступность предоставляется только в одном регионе.

Рекомендации по созданию применяются независимо от выбранной настройки.

Настройка многорегиональных личных пространств

Все параметры, описанные в следующих разделах, требуют развертывания приложений в отдельных регионах. Это возможно, только если настройка личного пространства завершена заранее, до катастрофы. Поскольку настройка личного пространства является региональной, стратегия DR требует как минимум двух личных пространств (по одному на регион) и механизма переключения трафика на соответствующую конечную точку VPN.

Доступная настройка личного пространства в регионе

CloudHub 2.0 не предоставляет автоматический отказ при сбое личного пространства в регионе. Решение — это активно-пассивная настройка в нескольких средах, которая требует:

• Настройка нескольких шлюзов VPN в личном пространстве.
• Создание отдельных сред в регионе CloudHub 2.0, каждая с собственным личным пространством.
• Назначение одной из этих сред пассивной (где приложения не развертываются изначально, но создаются в случае сбоя основного личного пространства).

Если настройка высокой доступности без шлюза VPN является одним из сложных требований, развертывание в двух регионах является лучшим вариантом. Ошибка шлюза VPN в этом сценарии может быть устранена путем переноса пострадавшего региона в альтернативный регион, где личное пространство уже настроено.

Потеря нулевого сообщения

Чтобы достичь нулевой потери сообщений при сбое всей области, приложение должно предотвратить потерю данных и устранить следующие моменты:

• Используйте внешние сообщения для достижения надежности сообщений.
• Убедитесь, что магазин объектов не используется для транзакционных данных в процессе работы, которые являются транзакционными по своей природе. Если область развертывания, в которой было впервые развернуто приложение MuleSoft, отключится, магазин объектов будет недоступен.
• Объедините весь доступ к объектному магазину в отдельный поток или раздел, который продолжает функционировать (для обработки исключений и поведения) при сбое операций чтения или записи объектного магазина.

Примечание. В большинстве случаев, требования DR не должны обеспечивать потерю нулевого сообщения в случае сбоя и необходимость обеспечить потерю данных меньше объема данных данного периода (например, 1 час).

Сохранение интеграции без гражданства

В качестве общего принципа проектирования всегда важно обеспечить, чтобы интеграции были государственными по своему характеру. Это значит, что между разными вызовами или выполнениями клиента (в случае запланированных услуг) не предоставляется общий доступ к транзакционным сведениям. Если некоторые данные должны храниться в промежуточном программном обеспечении из-за системного ограничения, они должны храниться во внешнем хранилище, например, в базе данных или очереди службы сообщений, а не в инфраструктуре MuleSoft или памяти. Важно отметить, что по мере масштабирования, особенно в облаке, состояние и ресурсы, используемые каждой репликой, должны быть независимыми от других реплик. Эта модель обеспечивает лучшую производительность, масштабируемость и надежность.

Сеть и управление трафиком

• Домены тщеславия обязательны для региональной доступности; они действуют как глобальный DNS для всех контроллеров входа в регионах.
• Глобальный балансировщик нагрузки перенаправляет трафик между основным и личным пространствами региона DR. Клиенты предоставляют этот компонент; используйте маршрут AWS 53 или глобальный CDN с политиками маршрутизации для маршрутизации трафика между регионами.
• Настройте контроллеры Ingress как в основной области, так и в области DR с настраиваемым доменом тщеславия.
• Планируйте и обслуживайте правила брандмауэра и туннелирование VPN, чтобы локальные приложения были доступны как из основного, так и из личного пространства региона DR.
• Обслуживание сертификатов TLS должно охватывать личные пространства как в первичных, так и в областных округах для беспрепятственного восстановления.

Развертывание и конфигурация приложения

• Имена приложений должны быть уникальными в разных регионах. Например, ожидаемые продажи CI/CD могут дополнить имя региона (или код региона) именами приложений перед развертыванием, чтобы сохранить уникальность в основных регионах и регионах DR.
• Настройте ожидаемые продажи CI/CD для развертывания приложений в основной и DR областях, чтобы все приложения были доступны в обеих областях.

Инфраструктура и пропускная способность
Производительность лучше, если все аспекты инфраструктуры имеют одинаковую основную и региональную нагрузку DR. Производительность снижается, если эти аспекты инфраструктуры не идентичны.

Сохранение и хранение данных

• Сохранение стойкости должно периодически синхронизироваться между двумя регионами. Клиенты несут ответственность за репликацию хранилища; MuleSoft ее не предоставляет. Один общий магазин между VPC в основной и DR областях возможен, но общее хранилище должно быть высокодоступным, иначе оно станет единой точкой сбоя для двух регионов.
• Объектный магазин V2 является региональным и доступен только в регионе первого развертывания приложения Mule. Если приложение перемещается в другой регион, Object Store V2 остается в исходном регионе во избежание потери данных. Используйте другое постоянное хранилище для многорегиональных стратегий DR.

Процедуры испытания и эксплуатации

Примите официальную стратегию тестирования DR и выполните периодические учения DR. Для активных DR используйте стратегию развертывания канарейки для проверки обеих областей.

Соглашения о производительности и уровне обслуживания (SLA)

Некоторое снижение производительности может произойти, поскольку регион ДР может находиться дальше от конечных пользователей или базовых систем, чем основной регион. Определите и передайте DR SLA заинтересованным лицам.

Поведение режима восстановления (контекстное примечание)

В активном режиме отказ от основной области к личному пространству области ДР выполняется быстро: глобальный балансировщик нагрузки обнаруживает, что основная нездоровая, и перенаправляет трафик в область здоровых (DR). В активно-пассивном режиме необходимо развернуть приложение в личном пространстве региона ДР при возникновении аварии.

Существует 3 варианта достижения более высокой доступности уровня DR:

Активно-активная конфигурация

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

Теплая конфигурация ожидания
Активно-пассивная настройка будет основана на активном сотруднике в одном регионе и пассивном сотруднике в другом регионе. При необходимости будет начата работа в пассивном регионе.

Некоторые элементы пассивного региона должны оставаться активными на случай сбоя или быть настроены заранее, включая личные пространства, VPN и вложения транзитных шлюзов.

Конфигурация холодной ожидания

Как указано выше, реплики и контроллеры Ingress инициализируются во втором регионе посредством полностью автоматизированного процесса DevOps при отказе. Некоторые элементы пассивного региона должны оставаться активными для отказа, включая личные пространства, VPN и вложения транзитного шлюза.

Базовыми компонентами архитектуры сети CloudHub 2.0 являются:

• Балансировщик загрузки HTTP
• Записи DNS реплики Mule
• Личные пространства
• Региональные услуги

Дополнительные сведения см. в разделе Архитектура сети CloudHub 2.0.

Vanity Domains

При создании личного пространства оно получает имя цели DNS в формате: <space-id>.<region>.cloudhub.io . После развертывания приложения под именем test-api в этом личном пространстве его конечная точка будет соответствовать следующему формату:

CloudHub 2.0 также поддерживает настраиваемые домены или домены тщеславия, настраивая их в личном пространстве посредством контекстов TLS и записей DNS. Чтобы создать контекст TLS в менеджере выполнения для личного пространства, загрузите открытый сертификат и личный ключ, потом добавьте настраиваемую конечную точку в параметры приложения для использования этого домена. Создайте запись DNS (например, CNAME), указывающую домен тщеславия на имя хоста личного пространства по умолчанию.

Например, приложение под именем test-api, развернутое в us-west-2 со стандартным DNS 42y52r.usa-w2.cloudhub.io, имеет конечную точку API:

https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io

Данный URL-адрес не использует тщеславный или настраиваемый домен. Чтобы использовать acme.com для отображения URL-адресов API в виде https://test-api.acme.com, выполните указанные ниже действия.

1. Создайте контекст TLS в менеджере выполнения с помощью открытых и личных ключей.
2. Добавьте домен тщеславия в параметры приложения для использования этого домена.
3. Создайте запись DNS в маршруте AWS 53 и настройте простую политику маршрутизации (например, CNAME), чтобы домен тщеславия определил стандартное имя хоста личного пространства.

Для настраиваемых доменов можно использовать маршрут AWS 53 или любые другие глобальные службы CDN с политиками маршрутизации. На схеме ниже маршрут AWS 53 используется с «простой» политикой маршрутизации. Когда потребитель из общедоступной (внешней) сети запрашивает acme.com, AWS Route 53 перенаправляет запрос в личный контроллер входа в пространство MuleSoft.

Используйте этот параметр, когда приложения требуют отказа: разверните один экземпляр в основной области (например, us-west-2) и другой в дополнительной (например, us-east-1).

При возможности используйте существующую среду во дополнительной области; создание новой среды требует дополнительных усилий.

Пример приложений, развернутых в одном регионе (Запад США 2), с отказом в другом регионе (Восток США 1)

В этой конфигурации AWS Route 53 перенаправляет трафик контроллерам входа для личных пространств в США West 2 и US East 1. Политика отказоустойчивой маршрутизации настроена посредством проверки состояния.

Для снижения задержки и высокой доступности используйте стратегию развертывания, описанную на схеме. С помощью этой стратегии приложения можно развернуть в двух регионах (us-west-2 и us-east-1 в данном примере).

Используйте политику маршрутизации с задержкой в маршруте AWS 53 для маршрутизации запросов в регион, который предлагает самую низкую задержку, сохраняя высокую доступность. Политика маршрутизации с задержкой в маршруте AWS 53 для маршрутизации запроса с низкой задержкой, все еще имеющего высокую доступность.

Приложения развернуты в обоих регионах (Западный 2 США и Восточный 1 США) для снижения задержки и высокой доступности

MuleSoft CloudHub 2.0 предоставляет надежную основу для устойчивости внутри региона, в первую очередь используя автоматическое резервирование реплик и интеллектуальную балансировку нагрузки. В одном облачном регионе развертывание приложений с несколькими репликами обеспечивает, что в случае сбоя одного экземпляра другие могут немедленно взять на себя рабочую нагрузку. Интегрированный балансировщик нагрузки эффективно распределяет входящий трафик между этими здоровыми репликами, минимизируя простой и обеспечивая постоянную доступность обслуживания в нормальных условиях работы.

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

• Крупномасштабные инциденты инфраструктуры
• Основные сбои в электроснабжении
• Распространенные прерывания сети

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

Архитектура сети CloudHub 2.0

Настройка межрегионального сбоя для стандартных очередей

Регионы развертывания объектного магазина V2

Регион развертывания магазина объектов

Гуляль Кумар является архитектором программного обеспечения в Salesforce, специализируется на архитектуре данных и интеграции. Имея более 20 лет опыта в интеграции и API, программах модернизации, безопасности и инициативах AIML, он предоставляет богатый опыт. Гуляль привержен продвижению инициатив по трансформации бизнеса, повышению безопасности и устойчивости, содействию совершенству архитектуры и руководству инициативами AIML в различных областях.

Аджай Нагараджу — корпоративный архитектор и старший директор MuleSoft с более чем 28-летним опытом в области архитектуры предприятия, интеграции системы и масштабной цифровой трансформации. Он руководил архитектурой и доставкой сложных многомиллионных программ в организациях Fortune 100 и Fortune 500, обладая глубоким опытом в подключении под управлением API, SOA, облачных технологиях и схемах интеграции предприятия. Аджай тесно сотрудничает с руководством по модернизации бизнес-процессов, платформ данных и экосистем интеграции и увлечен созданием масштабируемых архитектур, инструктированием рабочих групп и продвижением измеримых бизнес-результатов посредством технологий.