Упорядочение ресурсов Azure в мультитенантных решениях

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

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

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

Требования к изоляции клиента

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

Шкала

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

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

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

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

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

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

Изоляция арендаторов

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

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

Изоляция в общем ресурсе

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

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

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

В качестве примера общего подхода к ресурсам предположим, что Contoso создает мультитенантное программное обеспечение как службу (SaaS), включающее веб-приложение, базу данных и учетную запись хранения. Они могут решить развернуть общие ресурсы для обслуживания всех своих клиентов. На следующей схеме все клиенты совместно используют один набор ресурсов.

Отдельные ресурсы в группе ресурсов

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

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

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

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

Предположим, компания Contoso имеет трех клиентов или тенантов: Adventure Works, Fabrikam и Tailwind. Они могут предоставить общий доступ к веб-приложению и учетной записи хранения между тремя клиентами, а затем развернуть отдельные базы данных для каждого клиента. На следующей схеме показана группа ресурсов, содержащая общие ресурсы и группу ресурсов, содержащую базу данных каждого клиента.

Отдельные группы ресурсов в подписке

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

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

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

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

Отдельные подписки

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

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

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

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

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

Каждая подписка содержит группу ресурсов, содержащую полный набор ресурсов для этого клиента.

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

Все подписки Contoso связаны с одним клиентом Microsoft Entra. Используя один клиентский элемент Microsoft Entra, Contoso может использовать идентификации своей команды, включая пользователей и субъектов-служб, в пределах всей своей среды Azure.

Отдельные подписки в отдельных клиентах Microsoft Entra

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

В ситуациях, когда необходимо управлять ресурсами Azure в подписках, связанных с несколькими клиентами Microsoft Entra, рассмотрите возможность использования Azure Lighthouse для управления ресурсами в клиентах Microsoft Entra.

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

Клиент Microsoft Entra настроен для каждого клиента Contoso. Каждый клиент содержит подписку и ресурсы, необходимые каждому клиенту. Azure Lighthouse подключен к каждому клиенту Microsoft Entra.

Упаковка корзины

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

Ограничения ресурсов

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

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

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

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

На схеме показаны два шлюза приложений. Первый шлюз предназначен для клиентов от 1 до 100, а второй — для клиентов 101–200.

Ограничения группы ресурсов и подписки

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

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

Клиенты пакета bin в группах ресурсов и подписках

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

По мере роста можно приблизиться к ограничению емкости для одного ресурса и масштабироваться до нескольких ресурсов (R). На следующей схеме показана упаковка корзин в нескольких ресурсах.

Если достигнут предел количества ресурсов в одной группе ресурсов, можно развернуть несколько ресурсов (R) в нескольких группах ресурсов (G). На следующей схеме показана упаковка ячеек между несколькими ресурсами в нескольких группах ресурсов.

По мере увеличения размера ресурсы можно развертывать в нескольких подписках (S), каждый из которых содержит несколько групп ресурсов (G), имеющих несколько ресурсов (R). На следующей схеме показана упаковка ячеек между несколькими ресурсами в нескольких группах ресурсов и подписках.

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

Метки

Теги ресурсов позволяют добавлять пользовательские метаданные в ресурсы Azure. Эти метаданные можно использовать для управления ресурсами и отслеживания затрат. Дополнительные сведения см. в разделе "Выделение затрат с помощью тегов ресурсов".

Стеки развертывания

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

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

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

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

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

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

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

• Использование отдельных клиентов Microsoft Entra. Как правило, не рекомендуется подготавливать несколько клиентов Microsoft Entra. Управление ресурсами в клиентах Microsoft Entra является сложным. Проще масштабировать подписки, связанные с одним клиентом Microsoft Entra.

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

Соавторы

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

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

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

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

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

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

Связанный ресурс

• Подходы к управлению затратами и распределению