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

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

Ключевые рекомендации и требования

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

• Ожидаемый масштаб: вы планируете поддерживать небольшое количество клиентов (например, пять или меньше), или вы будете увеличиваться до большого количества клиентов?
• Автоматическое или поддерживаемое подключение. Когда клиент готов к подключению, они смогут выполнить процесс самостоятельно, выполнив автоматическую процедуру? Или же, инициируют ли новые клиенты запрос, и вы вручную включаете их после получения запроса? Существуют ли инструкции по утверждению вручную, необходимые вашей команде, например, чтобы предотвратить злоупотребление вашей службой?
• Время подготовки: когда клиент готов к подключению, насколько быстро необходимо выполнить процесс подключения? Если у вас нет четкого ответа, рассмотрите, следует ли измерять это в секундах, минутах, часах или днях.
• Azure Marketplace. Планируется ли использовать Azure Marketplace для запуска развертывания? Если вы это делаете, существуют требования, которые необходимо выполнить для добавления новых клиентов.

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

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

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

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

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

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

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

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

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

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

При развертывании в мультитенантной среде следует использовать конвейеры развертывания и использовать инфраструктуру в качестве кода (IaC), такие как Bicep, шаблоны JSON ARM, Terraform или пакеты SDK Azure.

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

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

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

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

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

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

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

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

Ниже приведено дальнейшее обсуждение этих подходов.

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

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

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

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

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

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

Круги развертывания

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

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

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

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

Неподходящие антишаблоны

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

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

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

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

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

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

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

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

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

1. Обновите список клиентов. Обычно это происходит вручную, настраивая сам конвейер или изменяя файл параметров, включенный в конфигурацию конвейера.
2. Активируйте конвейер для запуска.
3. Конвейер повторно развертывает полный набор ресурсов Azure, включая все новые ресурсы для конкретного клиента.

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

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

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

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

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

1. Запрос на подключение клиента, например путем инициирования запроса API на плоскость управления вашей системы.
2. Компонент рабочего процесса получает запрос на создание и оркеструет остальные шаги.
3. Рабочий процесс инициирует развертывание ресурсов для конкретного клиента в Azure. Это можно сделать с помощью императивной модели программирования, например с помощью пакетов SDK Azure или путем принудительного запуска развертывания шаблона Bicep или Terraform.
4. После завершения развертывания рабочий процесс сохраняет сведения о новом клиенте в центральном каталоге клиентов. Данные, хранящиеся для каждого клиента, могут содержать идентификатор клиента и идентификаторы ресурсов для всех созданных рабочим процессом ресурсов.

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

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

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

Пример

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

Компания Contoso использует Bicep для развертывания своих ресурсов Azure.

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

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

Если Компания Contoso следует этой модели, необходимо обновить файл параметров в рамках подключения нового клиента. Затем им нужно повторно запустить конвейер. Кроме того, они должны вручную отслеживать, находятся ли они рядом с любыми ограничениями, например, если они растут на неожиданно высоком уровне и подходят к максимальному количеству баз данных, поддерживаемых на одном логическом сервере 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 с помощью библиотеки управления.

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

Текущие обновления схемы базы данных инициируются их уровнем приложения.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Джон Даунс | Главный инженер программного обеспечения

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

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

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

Следующие шаги

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