Поделиться через


Архитектурные подходы к развертыванию и настройке мультитенантных решений

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

Основные рекомендации и требования

Четко определите свои требования перед планированием стратегии развертывания. Обратите внимание на следующие факторы:

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

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

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

  • Azure Marketplace: Убедитесь, что вы планируете использовать Azure Marketplace для запуска развертывания. Если вы это делаете, выполните необходимые требования для добавления новых клиентов.

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

Шаги подключения и подготовки

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

  1. Примите коммерческие соглашения.
  2. Выполните действия по утверждению вручную, например, чтобы предотвратить мошенничество или неправильное использование службы.
  3. Подготовка ресурсов в Azure.
  4. Создание или настройка доменных имен.
  5. Выполнение задач конфигурации после развертывания, таких как создание первой учетной записи пользователя для клиента и безопасное передача учетных данных клиенту.
  6. Примените изменения конфигурации вручную, например изменения записи системы доменных имен (DNS).

Четко документируйте рабочий процесс, необходимый для подключения нового клиента.

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

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

Автоматизация

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

  • Шкала: По мере увеличения численности клиентов процессы развертывания вручную становятся все более сложными и трудоемкими. Автоматизированный подход к развертыванию проще масштабировать по мере увеличения числа клиентов.

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

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

При развертывании в мультитенантной среде следуйте приведенным ниже рекомендациям.

  • Используйте конвейеры развертывания для развертывания общих ресурсов.

  • Используйте инфраструктуру как технологии кода (IaC), такие как Bicep, шаблоны AZURE Resource Manager (шаблоны ARM) или Terraform.

  • При необходимости используйте код для вызова пакетов SDK Azure.

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

Максимальная емкость ресурсов

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

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

Ответственность по управлению ресурсами

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

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

  • Обработайте клиентов как конфигурацию развернутых ресурсов и используйте конвейеры развертывания для развертывания и настройки этих ресурсов.

  • Обработка клиентов как данных и подготовка уровня управления и настройка инфраструктуры для клиентов.

В следующих разделах описаны эти подходы.

Тестирование

Тщательно протестируйте решение во время и после каждого развертывания. Вы можете использовать автоматическое тестирование для проверки функционального и нефункционального поведения решения. Убедитесь, что вы протестируете модель изоляции клиента. Рассмотрите возможность использования таких средств, как Azure Chaos Studio , чтобы намеренно вводить ошибки, которые имитируют реальные сбои и проверяют, что функции решения выполняются даже в том случае, если компонент становится недоступным или неисправным.

Подходы и шаблоны, которые следует учитывать

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

Шаблон меток развертывания (Deployment Stamps)

Используйте шаблон меток развертывания для развертывания выделенной инфраструктуры для клиента или группы клиентов. Одна метка может содержать несколько клиентов или может быть выделена для одного клиента. Можно развернуть одну метку или координировать развертывание между несколькими метками. При развертывании выделенных меток для каждого клиента рассмотрите возможность программного развертывания целых меток.

Этапы развертывания

Используйте кольца развертывания для развертывания обновлений в разных группах инфраструктуры в разное время. Этот подход часто дополняет шаблон меток развертывания. Назначьте группы меток отдельным кольцам на основе параметров клиента, типов рабочей нагрузки и других соображений. Дополнительные сведения см. в разделе "Круги развертывания".

Флаги функций

Используйте флаги функций для постепенного предоставления новых функций или версий решения разным клиентам или пользователям без повторного развертывания кода. Рекомендуется использовать конфигурацию приложений Azure для управления флагами функций. Дополнительные сведения см. в разделе "Флаги компонентов".

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

Антипаттерны, которых следует избегать

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

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

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

Список клиентов в виде конфигурации или данных

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

  • Используйте конвейер автоматического развертывания для развертывания каждого ресурса. При добавлении новых клиентов перенастройка конвейера для подготовки ресурсов для каждого клиента.

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

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

Список клиентов в качестве конфигурации

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

Схема, показывающая процесс подключения клиента при сохранении списка клиентов в качестве конфигурации конвейера.

Процесс подключения для нового клиента обычно включает следующие действия:

  1. Обновите список клиентов вручную, настроив конвейер или изменив файл параметров, включенный в конфигурацию конвейера.

  2. Активируйте конвейер для запуска.

  3. Конвейер повторно развертывает полный набор ресурсов Azure, включая все новые ресурсы для конкретного клиента.

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

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

Список клиентов в виде данных

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

Схема, показывающая процесс подключения клиента, когда список клиентов хранится в виде данных.

Процесс подключения обычно включает следующие асинхронные шаги:

  1. Запрос на подключение клиента, например инициирование запроса API к плоскости управления системы.

  2. Компонент рабочего процесса получает запрос на создание и оркеструет остальные шаги.

  3. Рабочий процесс инициирует развертывание ресурсов для конкретного клиента в Azure. Вы можете использовать императивную модель программирования, например пакеты SDK Azure, или принудительно активировать развертывание Bicep-файла или шаблона Terraform.

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

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

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

Дополнительные сведения см. в разделе "Рекомендации по многотенантным плоскостям управления".

Замечание

Для выполнения операций развертывания и конфигурации Azure часто требуется время. Убедитесь, что вы используете соответствующий процесс для запуска и мониторинга этих длительных операций. Например, можно рассмотреть возможность выполнения асинхронного Request-Reply шаблона. Используйте технологии, предназначенные для поддержки длительных операций, таких как Azure Logic Apps и устойчивые функции.

Пример

Компания Contoso запускает мультитенантное решение для своих клиентов. В течение следующих 18 месяцев у них есть шесть клиентов, и они ожидают роста до 300 клиентов. Contoso следует мультитенантному приложению с выделенными базами данных для каждого подхода клиента . Они развертывают единый набор ресурсов Службы приложений Azure и логический сервер SQL Azure, которым совместно используются все клиенты. Они также развертывают выделенную базу данных SQL Azure для каждого клиента, как показано на следующей схеме. Компания Contoso использует Bicep для развертывания своих ресурсов Azure.

Схема архитектуры, на которой показаны общие ресурсы и выделенные ресурсы для каждого клиента.

Вариант 1. Использование конвейеров развертывания для всего

Компания Contoso может развернуть все ресурсы с помощью конвейера развертывания. Их конвейер развертывает Bicep-файл, содержащий все ресурсы Azure, включая базы данных SQL Azure для каждого клиента. Файл параметров определяет список клиентов. Файл Bicep использует цикл ресурсов для развертывания базы данных для каждого из перечисленных клиентов, как показано на следующей схеме.

Схема, на которой показан конвейер развертывания общих ресурсов и ресурсов для конкретного клиента.

Если Компания Contoso выполняет эту модель, они должны выполнить следующие действия.

  1. Обновите файл параметров как часть подключения нового клиента.

  2. Повторное выполнение конвейера.

  3. Вручную отслеживайте ограничения ресурсов, например, если они растут на неожиданно высоком уровне и подходят к максимальному количеству баз данных, поддерживаемых на одном логическом сервере SQL Azure.

Вариант 2. Использование сочетания конвейеров развертывания и создания императивных ресурсов

Кроме того, компания Contoso может разделить ответственность за развертывания Azure.

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

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

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

API асинхронно запускает рабочий процесс, который подключен к новым клиентам. Рабочий процесс инициирует развертывание новой базы данных SQL Azure, которая может использовать один из следующих подходов:

  • Используйте пакет SDK Azure для запуска развертывания второго Bicep-файла, который определяет базу данных SQL Azure.

  • Используйте пакет SDK Azure для императивного создания базы данных SQL Azure с помощью библиотеки управления.

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

Схема, показывющая рабочий процесс для развертывания базы данных для нового клиента.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

  • Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

Другие участники:

  • Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure
  • Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.