Шаблон геоузла

Шаблон Geode включает развертывание коллекции внутренних служб в набор geographical nodes, каждый из которых может обслуживать любой запрос для любого клиента в любом регионе. Этот шаблон позволяет обслуживать запросы в активном стиле, повышая задержку и увеличивая доступность путем распространения обработки запросов по всему миру.

Контекст и проблема

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

Классический подход может представлять ряд проблем:

• Проблемы с задержкой сети для пользователей, поступающих с другой стороны земного шара для подключения к конечной точке размещения
• Управление трафиком для всплесков спроса, которые могут перегружать службы в одном регионе
• Сложность развертывания копий инфраструктуры приложений в нескольких регионах для службы 24x7.

Современная облачная инфраструктура изменилась, чтобы обеспечить географическую балансировку нагрузки интерфейсных служб, обеспечивая географическую репликацию внутренних служб. Для доступности и производительности получение данных ближе к пользователю. Если данные распределены по всей базе пользователей с большим объемом, геораспределенные хранилища данных также должны быть совместно распределены с вычислительными ресурсами, обрабатывающими данные. Шаблон геоопределений приводит вычислительные ресурсы к данным.

Решение

Разверните службу в ряде вспомогательных развертываний, распределенных по всему миру, каждая из которых называется геодой. Шаблон геодеяния использует ключевые функции Azure для маршрутизации трафика через кратчайший путь к близлежащему геоде, что повышает задержку и производительность. Каждая геодея находится за глобальной подсистемой балансировки нагрузки и использует геореплицированную службу чтения и записи, например Azure Cosmos DB , для размещения плоскости данных, обеспечивая согласованность данных между геоопределенными данными. Службы репликации данных гарантируют, что хранилища данных идентичны между геодами, поэтому все запросы можно обслуживать со всех геодан.

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

Геодосы имеют следующие характеристики:

• Состоит из коллекции разрозненных типов ресурсов, часто определенных в шаблоне.
• Не имеют зависимостей за пределами географического пространства и автономны. Ни один геоде не зависит от другого для работы, и если один умирает, другие продолжают работать.
• Слабо связаны через граничную сеть и серверную планку репликации. Например, вы можете использовать Диспетчер трафика Azure или Azure Front Door для фронтинга геодоков, в то время как Azure Cosmos DB может выступать в качестве обратной планки репликации. Георазведки не совпадают с кластерами, так как они совместно используют серверную планку репликации, поэтому платформа заботится о проблемах кворума.

Шаблон геоопределений возникает в архитектурах больших данных, использующих оборудование для обработки данных, совместно размещенных на одном компьютере, и MapReduce для консолидации результатов на компьютерах. Другое использование — это почти пограничные вычисления, которые приближают вычисления к интеллектуальному краю сети для уменьшения времени отклика.

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

Кроме того, можно расширить локальные методы доступности, такие как зоны доступности или парные регионы, с шаблоном геодокумента для глобальной доступности. Это повышает сложность, но полезно, если архитектура поддерживается подсистемой хранилища, например хранилищем BLOB-объектов, которое может реплицироваться только в парном регионе. Вы можете развертывать геозоны в пределах зоны, зонального или регионального следа с учетом нормативных или задержек в расположении.

Проблемы и рекомендации

Используйте следующие методы и технологии для реализации этого шаблона:

• Современные методики и средства DevOps для создания и быстрого развертывания идентичных георазведок в большом количестве регионов или экземпляров.
• Автоматическое масштабирование для горизонтального масштабирования экземпляров вычислительных ресурсов и пропускной способности базы данных в геоде. Каждая геодея по отдельности масштабируется в пределах общих ограничений backplane.
• Интерфейсная служба, например Azure Front Door, которая выполняет динамическое ускорение содержимого, разделение TCP и маршрутизацию Anycast.
• Реплицируемое хранилище данных, например Azure Cosmos DB, для управления согласованностью данных.
• Бессерверные технологии, где это возможно, чтобы сократить затраты на развертывание постоянного доступа, особенно если загрузка часто перебалансируется по всему миру. Эта стратегия позволяет развертывать множество геодокументов с минимальными дополнительными инвестициями. Бессерверные и технологии выставления счетов на основе потребления сокращают затраты и затраты из повторяющихся геораспределенных развертываний.
• Управление API не требуется для реализации шаблона проектирования, но его можно добавить в каждую геодокумент, которая входит в приложение-функцию Azure региона, чтобы обеспечить более надежный уровень API, что позволяет реализовать дополнительные функциональные возможности, такие как ограничение скорости, например.

При принятии решения о реализации этого шаблона необходимо учитывать следующие моменты.

• Выберите, следует ли обрабатывать данные локально в каждом регионе или распространять агрегаты в одном геоде и реплицировать результат по всему миру. Обработчик канала изменений Azure Cosmos DB предлагает этот детализированный элемент управления с использованием концепции контейнера аренды и арендыprelectionprefix в соответствующей привязке Функции Azure. Каждый подход имеет уникальные преимущества и недостатки.
• Геодимы могут работать в тандеме, используя канал изменений Azure Cosmos DB и платформу коммуникации в режиме реального времени, например SignalR. Геосети могут взаимодействовать с удаленными пользователями через другие геосети в шаблоне сетки, не зная или заботясь о расположении удаленного пользователя.
• Этот шаблон конструктора неявно отделяет все, что приводит к высоко распределенной и развязанной архитектуре. Рассмотрим, как отслеживать различные компоненты одного запроса, так как они могут выполняться асинхронно на разных экземплярах. Правильная стратегия мониторинга имеет решающее значение. Azure Front Door и Azure Cosmos DB можно легко интегрировать с Log Analytics и Функции Azure следует развертывать вместе с Application Insights, чтобы обеспечить надежную систему мониторинга на каждом компоненте в архитектуре.
• Распределенные развертывания имеют большее количество секретов и точек входящего трафика, требующих мер безопасности свойств. Key Vault предоставляет безопасный уровень для управления секретами, и каждый слой в архитектуре API должен быть правильно защищен, чтобы единственная точка входящего трафика для API была интерфейсной службой, такой как Azure Front Door. Azure Cosmos DB должен ограничить трафик приложения-функции Azure и приложения-функции в Azure Front Door с помощью идентификатора Microsoft Entra или практик, таких как ограничение IP.
• Производительность резко влияет на количество развернутых геод и конкретных планов Служба приложений, применяемых к технологии API в каждой геоде. Развертывание дополнительных географических параметров или перемещение к уровням "Премиум" приходится с повышенными затратами на дополнительную память и вычислительные ресурсы, но не делать это на основе каждой транзакции. Рассмотрите возможность нагрузочного тестирования архитектуры API после развертывания и контрастирования числа геод, увеличивая ценовую категорию, чтобы наиболее эффективная модель использовалась для ваших потребностей.
• Определите требования к доступности данных. Azure Cosmos DB имеет необязательные флаги для включения многорегиональных записей, зон доступности и т. д. Это повышает доступность экземпляра Azure Cosmos DB и создает более устойчивый уровень данных, но при этом требует дополнительных затрат.
• Azure предлагает различные подсистемы балансировки нагрузки, предоставляющие различные функциональные возможности для распределения трафика. Используйте дерево принятия решений, чтобы выбрать подходящий вариант для внешнего интерфейса API.

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

Этот шаблон может быть не подходит для

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

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон геодокумации можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.

Примеры

• Windows Active Directory реализует ранний вариант этого шаблона. Репликация с несколькими основными объектами означает, что все обновления и запросы могут обслуживаться из всех обслуживаемых узлов, но гибкие роли FSMO означают, что все геоданы не равны.
• Акселератор шаблонов геодинок на GitHub демонстрирует этот шаблон проектирования на практике и предназначен для того, чтобы разработчики реализовали его с помощью реальных API.