Я не знаю, видел ли кто-нибудь День открытых дверей Tencent Technology Open, проведенный несколько дней назад. Темой TechoDay является всестороннее и многостороннее обсуждение «трудностей и решений миграции информационных систем».

Честно говоря, после просмотра прямой трансляции в тот день не было никакой лжи, это была вся практическая информация. Также есть подробное «Руководство по инструменту Tencent Cloud». Заинтересованные друзья могут нажать на картинку, чтобы получить его.

Итак, на этот раз позвольте мне начать с архитектуры 3AZ и поделиться с вами своим опытом.

1. Введение

Ниже мы представим основные концепции и принципы реализации архитектуры 3AZ, обсудим преимущества и ключевые факторы архитектуры 3AZ и, наконец, поделимся кейсами на основе архитектуры 3AZ.

1.1 Что такое архитектура развертывания 3AZ

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

1.2 Цели и преимущества проектирования

Архитектура развертывания 3AZ — это архитектурный шаблон для распределенных приложений, предназначенный для частного развертывания на предприятии. Ее цели и преимущества включают в себя:

● Высокая доступность: развертывайте копии приложений в нескольких зонах доступности, чтобы повысить доступность приложений и сократить время простоев, вызванное сбоем одной зоны доступности.

● Надежность данных. Данные обычно реплицируются и резервируются в нескольких зонах доступности, чтобы обеспечить надежность и безопасность данных. В случае сбоя система может автоматически перенаправить запросы в другую зону доступности, чтобы избежать потери данных.

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

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

2. Ключ к архитектуре 3AZ

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

● Распределенная архитектура. Каждая зона доступности представляет собой независимый центр обработки данных, а разные копии приложения развертываются в разных зонах доступности. АЗ имеет независимую систему электроснабжения, сеть и т.д.

● Проектирование сети. Необходимо убедиться, что сетевые соединения между несколькими зонами доступности стабильны и надежны, чтобы при необходимости можно было быстро переключиться на альтернативную зону доступности. Обычно выделенная сеть или виртуальная частная сеть (VPC) используется для реализации сетевых подключений между несколькими зонами доступности, а между различными зонами доступности необходимо установить резервные сетевые подключения.

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

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

3. Лучшие практики

Реализация таких мер, как архитектура высокой доступности, автоматизация и мониторинг, может помочь архитектуре 3AZ достичь большей надежности и эффективности.

3.1 Архитектура высокой доступности

Архитектура высокой доступности. Для достижения высокой доступности архитектура 3AZ должна обладать следующими характеристиками:

● Уровень доступа к сети: 3AZ единообразно подключен к магистральной сети и реализует взаимосвязь и совместимость через магистральную сеть.

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

● Уровень вычислений и ресурсов хранения. Благодаря единому большому VPC в зоне доступности облачные серверы в 3AZ могут быть разделены на один и тот же VPC для достижения доступности сети уровня 3 без необходимости проходить через централизованный кластер шлюзов. Компании могут развертывать мультиактивные экземпляры 3AZ в большом VPC.

● Уровень шлюза SDN: благодаря большим кластерам между зонами доступности и возможностям доступа поблизости он реализует доступ к трафику поблизости и возможность взять на себя управление процессом между зонами доступности в случае сбоя кластера.

● Уровень ресурсов PaaS. Благодаря возможности большого кластера между зонами доступности пользователи могут создавать несколько копий экземпляров службы PaaS, распределенных по зонам доступности. Уровень приложений не должен заботиться о синхронизации данных между зонами доступности между копиями экземпляров PaaS и использует унифицированный уровень. VIP для доступа. Возможности аварийного восстановления в пределах зоны доступности предоставляются службами PaaS.

● Платформа управления облаком и базовый уровень. Контейнеры и постоянные компоненты службы поддержки общей платформы управления облаком развертываются и планируются в зонах доступности, чтобы обеспечить высокую доступность платформы управления облаком в разных зонах доступности и избежать недоступности платформы после сбоя в одной зоне доступности.

Вот простая диаграмма, показывающая, как приложение развертывается в архитектуре 3AZ:

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

3.2 Автоматизация и контроль аварийных сигналов

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

● Используйте инструменты автоматизации для развертывания приложений и инфраструктуры и управления ими, такие как Helm, Ansible, DevOps, PaaS, SaaS и другие платформы.

● Автоматический мониторинг и оповещение с использованием инструментов для реализации механизмов автоматического оповещения и автоматического восстановления, таких как Prometheus, Grafana, Alertmanager и т. д.

Мониторинг и оповещение: отслеживайте состояние работы приложения в режиме реального времени, отслеживая различные индикаторы, а также своевременно обнаруживайте и решайте проблемы. В основном отслеживайте следующие аспекты:

● Инфраструктура: включая серверы, балансировщики нагрузки, базы данных и т. д.

● Приложение: включает в себя различные индикаторы и параметры производительности приложения, такие как время отклика, пропускная способность и т. д.

3.3 Соответствие требованиям безопасности

Архитектура 3AZ — это облачная архитектура, в которой соблюдение требований безопасности является очень важным фактором.

● Контроль доступа. Архитектура 3AZ использует аутентификацию и авторизацию для управления доступом пользователей и служб к ресурсам. Для защиты ресурсов можно использовать различные методы аутентификации.

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

● Защита сети: предоставляет возможности изоляции сетевого трафика для удовлетворения различных требований соответствия, таких как виртуальные частные сети, контроль доступа к сети, группы безопасности и т. д.

4. Корпус архитектуры 3AZ

В приведенном выше разделе мы подробно остановились на основных требованиях к архитектуре 3AZ. Но потребности клиентов поставщиков облачных вычислений разнообразны. В последнем выпуске «Руководства по инструментам Tencent Cloud» мы видели, что Tencent Cloud использовала структуру 3AZ для локализации внутренней банковской системы. Требования заказчика к данному проекту следующие:

● Развертывание пулов облачных ресурсов нескольких архитектур в одном облаке по требованию, включая ресурсы Haiguang, Kunpeng, Feiteng и X86.

● Требования к RPO и RTO чрезвычайно высоки, требуя надежных возможностей аварийного восстановления и архитектуры, которая может поддерживать расширение для мультиактивного развертывания в одном и том же городе в будущем.

> RPO Целевая точка восстановления данных относится к объему потери данных, который может выдержать бизнес-система. РТО То есть целевое время восстановления в основном относится к максимальному времени, в течение которого предприятие может выйти из строя.

● Глубокая интеграция и связь конфигураций между продуктами Laas и Paas позволяют избежать разделения управления и обслуживания между несколькими продуктами традиционного частного облака.

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

В ответ на вышеуказанные требования полнофункциональная облачная платформа TCE от Tencent Cloud предоставляет полную матрицу облачных продуктов IaaS/PaaS/SaaS для удовлетворения потребностей предприятий в приватизированном развертывании, соблюдении требований безопасности и независимой управляемости. И он поддерживает различные архитектуры чипов для удовлетворения потребностей локализации.

> TCE Список поддерживаемых типов серверов и архитектур чипов: https://cloud.tencent.com/solution/tce.

Собственное облако Tencent PaaS платформа,аббревиатура Tencent TCS, с точки зрения приложения, в Kubernetes Cloud Native, построенный на основе облачных базовых технологий, представленных PaaS Платформа сочетает в себе автоматизированную оркестрацию, эластичное расширение, выпуск в оттенках серого, управление микросервисами, высокую доступность и DevOps для облачных приложений. и другие преимущества.

Для мультиактивного развертывания в одном городе, возможностей аварийного восстановления, RTO и других требований Tencent Cloud предлагает 3 архитектуры развертывания:

Арбитражная зона физически независима от MAZ (основная доступная зона) и SAZ (резервная доступная зона), а MAZ и SAZ могут взаимодействовать друг с другом в сети. Развертываются только необходимые (выбранные) распределенные сервисы, без каких-либо конкретных бизнес-сервисов. развернут. Добавление роли «Другая зона доступности» в общую архитектуру TCS для совместной работы позволяет предыдущим MAZ и SAZ играть равные роли с точки зрения самой облачной платформы, сокращая количество шагов ручного вмешательства.

Пропускная способность сети самой арбитражной зоны, соединяющей MAZ и SAZ, обычно относительно низкая, а задержка относительно велика. Поэтому применяется политика, предотвращающая подключение служб к узлам арбитражной зоны. Арбитражная зона используется только для внутренних выборов. в кластере.

Ниже приведены протестированные ситуации высокой доступности и RTO для нескольких типов промежуточного программного обеспечения в различных архитектурах развертывания:

Для ЕС:

● Архитектура развертывания арбитражной зоны 2AZ: кластеры ES развертываются в двух зонах доступности (так же, как и в 2AZ). При сбое узла в одной зоне доступности главный узел необходимо переизбрать вручную. Этот процесс занимает определенное время, поэтому время восстановления зоны 2AZ+арбитраж относительно велико.

● В архитектуре среды 3AZ: кластеры ES развертываются в трех разных зонах доступности, по несколько узлов в каждой зоне доступности. Кластеры ES развертываются в разных зонах доступности, и данные также реплицируются в разных зонах доступности. Таким образом, даже если узел в одной зоне доступности выйдет из строя, данные по-прежнему будут доступны на узлах в других зонах доступности. Кластер ES имеет функцию автоматического восстановления. При сбое узла этот автоматический процесс восстановления может значительно сократить время восстановления системы.

Его эффект аварийного восстановления в арбитражной зоне 2AZ+ слабее, чем в 3AZ.

Для Redis в качестве примера возьмем режим Sentinel:

● Архитектура развертывания 2AZ + зона арбитража: 3 узла Sentinel распределены в 3 зонах доступности (1+1+1), а 2 узла данных Redis развернуты в 2 зонах доступности (1+1, в зоне арбитража узлы данных не развернуты). ). В режиме архитектуры Redis master-slave + Sentinel Sentinel отвечает за переключение высокой доступности кластера. При сбое любой из доступных зон большинство Sentinel могут выбрать новый главный Redis и автоматически восстановить службы, чтобы обеспечить высокую доступность кластера.

● Архитектура развертывания 3AZ: 3 узла Sentinel и 3 узла данных Redis распределены в 3 зонах доступности (Sentinel 1+1+1, узел данных Redis 1+1+1). В режиме архитектуры Redis master-slave + Sentinel Sentinel является архитектурой. отвечает за переключение кластера с высокой доступностью. При выходе из строя любой из доступных зон он может обеспечить выживание большинства Sentinel, а затем выбрать новый Redis. master автоматически восстанавливает службы, чтобы обеспечить высокую доступность кластера.

Его эффект аварийного восстановления в зоне 2AZ+арбитража примерно такой же, как и у 3AZ.

Что касается системы в целом, то она имеет множество сервисных компонентов, таких как ES и Redis. Общая способность аварийного восстановления арбитражной зоны 2AZ+ находится между 2AZ и 3AZ.

5. Резюме

Сама арбитражная зона 2AZ, 2AZ+ выходит из строя, а время восстановления системы велико. Таким образом, архитектура среды арбитражной зоны 2AZ имеет пониженную доступность и отказоустойчивость по сравнению с архитектурой среды 3AZ.

При фактическом развертывании необходимо взвесить различные факторы и выбрать наиболее подходящую архитектуру среды и план развертывания, исходя из реальных потребностей и условий бизнеса. Например, для отраслей с чрезвычайно высокими требованиями к доступности, таких как финансовая отрасль и медицинская отрасль, больше подходит развертывание архитектуры на базе 3AZ.

В архитектуре развертывания 3AZ все возможности общедоступного облака Tencent Cloud можно использовать или развертывать в частном порядке для соответствия требованиям безопасности данных. Он также совместим с облачными технологиями, такими как Kubernetes и Docker, что делает разработку и развертывание приложений в архитектуре развертывания 3AZ проще и эффективнее.

В последнем выпуске «Руководства по инструментам Tencent Cloud» Tencent Cloud представляет технические трудности миграции и решения в нескольких ключевых областях, таких как базовые операционные системы, базы данных и большие данные, посредством конкретных технических случаев.

Друзья, которые заинтересованы в локализованных решениях, могут нажать на изображение ниже, чтобы загрузить его.

👇 Получите новейшее «Руководство по облачным инструментам Tencent» 👇

Конечно, вы также можете прочитать оригинальный текст.