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 для каждого из трех клиентов, как показано на следующей схеме. Каждая подписка содержит группу ресурсов с полным набором ресурсов для этого клиента.
Схема с тремя подписками для конкретного клиента. Каждая подписка содержит группу ресурсов с полным набором ресурсов для этого клиента.
Каждая подписка содержит группу ресурсов с полным набором ресурсов для этого клиента.
Они используют группу управления для упрощения управления подписками. Включив рабочую среду в имя группы управления, они могут четко различать любой рабочий клиент от непроизводственных или тестовых клиентов. Клиенты, не являющиеся рабочими, будут применяться разные правила и политики управления доступом Azure.
Все их подписки связаны с одним клиентом Microsoft Entra. Использование одного клиента Microsoft Entra означает, что удостоверения группы Contoso, включая пользователей и субъектов-служб, могут использоваться во всем их активе Azure.
Отдельные подписки в отдельных клиентах Microsoft Entra
Кроме того, можно вручную создавать отдельные клиенты Microsoft Entra для каждого клиента или развертывать ресурсы в подписках в клиентах Microsoft Entra. Однако работа с несколькими клиентами Microsoft Entra затрудняет проверку подлинности, управление назначениями ролей, применение глобальных политик и выполнение многих других операций управления.
Предупреждение
Рекомендуется создавать несколько клиентов Microsoft Entra для большинства мультитенантных решений. Работа в клиентах Microsoft Entra обеспечивает дополнительную сложность и сокращает возможности масштабирования ресурсов и управления ими. Как правило, этот подход используется только поставщиками управляемых служб (MSPs), которые управляют средами Azure от имени своих клиентов.
Прежде чем предпринять усилия по развертыванию нескольких клиентов Microsoft Entra, рассмотрите возможность достижения требований с помощью групп управления или подписок в одном клиенте.
В ситуациях, когда необходимо управлять ресурсами Azure в подписках, связанных с несколькими клиентами Microsoft Entra, рассмотрите возможность использования Azure Lighthouse для управления ресурсами в клиентах Microsoft Entra.
Например, Contoso может создавать отдельные клиенты Microsoft Entra и отдельные подписки Azure для каждого из своих клиентов, как показано на следующей схеме.
Схема, показывающая клиент Microsoft Entra для каждого клиента Contoso, который содержит подписку и необходимые ресурсы. Azure Lighthouse подключен к каждому клиенту Microsoft Entra.
Клиент Microsoft Entra настроен для каждого клиента Contoso, который содержит подписку и необходимые ресурсы. Azure Lighthouse подключен к каждому клиенту Microsoft Entra.
Упаковка корзины
Независимо от модели изоляции ресурсов важно учитывать, когда и как решение будет масштабироваться в нескольких ресурсах. Возможно, потребуется масштабировать ресурсы по мере увеличения нагрузки на систему или по мере увеличения числа клиентов. Рассмотрите возможность упаковки ячеек , чтобы развернуть оптимальное количество ресурсов для ваших требований.
Совет
Во многих решениях проще масштабировать весь набор ресурсов, а не масштабировать ресурсы по отдельности. Рассмотрите возможность выполнения шаблона меток развертывания.
Ограничения ресурсов
Ресурсы Azure имеют ограничения и квоты , которые необходимо учитывать в планировании решения. Например, ресурсы могут поддерживать максимальное количество одновременных запросов или параметров конфигурации для конкретного клиента.
Способ настройки и использования каждого ресурса также влияет на масштабируемость этого ресурса. Например, предположим, что при определенном количестве вычислительных ресурсов приложение может успешно реагировать на определенное количество транзакций в секунду. Помимо этого, может потребоваться горизонтальное масштабирование. Тестирование производительности помогает определить точку, в которой ресурсы больше не соответствуют вашим требованиям.
Примечание.
Принцип масштабирования до нескольких ресурсов применяется даже при работе со службами, поддерживающими несколько экземпляров.
Например, служба приложение Azure поддерживает масштабирование числа экземпляров плана, но существуют ограничения на масштабирование одного плана. В высокомасштабируемом мультитенантном приложении вы можете превысить эти ограничения и развернуть дополнительные Служба приложений планы для соответствия росту.
При совместном использовании некоторых ресурсов между клиентами сначала следует определить количество клиентов, поддерживаемых ресурсом, когда оно настроено в соответствии с вашими требованиями. Затем разверните столько ресурсов, сколько потребуется для обслуживания общего числа клиентов.
Например, предположим, что вы развертываете Шлюз приложений Azure в составе мультитенантного решения SaaS. Вы просматриваете проект приложения, тестируете производительность шлюза приложений под нагрузкой и просматриваете ее конфигурацию. Затем вы определите, что один ресурс шлюза приложений можно совместно использовать среди 100 клиентов. Согласно плану роста вашей организации, вы планируете подключить 150 клиентов в первый год, поэтому вам нужно спланировать развертывание нескольких шлюзов приложений для обслуживания ожидаемой нагрузки.
Схема с двумя шлюзами приложений. Первый шлюз предназначен для клиентов от 1 до 100, а второй — для клиентов 101–200.
На предыдущей схеме есть два шлюза приложений. Первый шлюз предназначен для клиентов от 1 до 100, а второй — для клиентов 101–200.
Ограничения группы ресурсов и подписки
Независимо от того, работаете ли вы с общими или выделенными ресурсами, важно учитывать ограничения. Azure ограничивает количество ресурсов, которые можно развернуть в группе ресурсов и в подписке Azure. При подходе к этим ограничениям необходимо спланировать масштабирование между несколькими группами ресурсов или подписками.
Например, предположим, что вы развертываете выделенный шлюз приложений для каждого клиента в общую группу ресурсов. Для некоторых ресурсов поддержка Azure развертывает до 800 ресурсов одного типа в одну группу ресурсов. Поэтому при достижении этого ограничения необходимо развернуть новые шлюзы приложений в другую группу ресурсов. На следующей схеме существует две группы ресурсов. Каждая группа ресурсов содержит 800 шлюзов приложений.
Схема с двумя группами ресурсов. Каждая группа ресурсов содержит 800 шлюзов приложений.
Клиенты пакета bin в группах ресурсов и подписках
Вы также можете применить концепцию упаковки ячеек между ресурсами, группами ресурсов и подписками. Например, если у вас небольшое количество клиентов, вы можете развернуть один ресурс и предоставить общий доступ ко всем клиентам. На следующей схеме показана упаковка ячеек в один ресурс.
Схема, показывающая упаковку ячеек в один ресурс.
По мере роста можно приблизиться к ограничению емкости для одного ресурса и увеличить масштаб до нескольких ресурсов (R). На следующей схеме показана упаковка корзин в нескольких ресурсах.
Схема, показывющая упаковку ячеек в нескольких ресурсах.
С течением времени можно достичь предельного количества ресурсов в одной группе ресурсов, а затем развернуть несколько ресурсов (R) в нескольких группах ресурсов (G). На следующей схеме показана упаковка ячеек между несколькими ресурсами в нескольких группах ресурсов.
Схема, показывющая упаковку ячеек между несколькими ресурсами в нескольких группах ресурсов.
И по мере увеличения размера можно развертывать в нескольких подписках (S), каждая из которых содержит несколько групп ресурсов (G) с несколькими ресурсами (R). На следующей схеме показана упаковка ячеек между несколькими ресурсами в нескольких группах ресурсов и подписках.
Схема, показывющая упаковку ячеек между несколькими ресурсами в нескольких группах ресурсов и подписках.
Планируя стратегию горизонтального масштабирования, вы можете масштабироваться до чрезвычайно большого количества клиентов и поддерживать высокий уровень нагрузки.
Теги
Теги ресурсов позволяют добавлять пользовательские метаданные в ресурсы Azure, которые могут быть полезны для управления и отслеживания затрат. Дополнительные сведения см. в разделе "Выделение затрат с помощью тегов ресурсов".
Стеки развертывания
Стеки развертывания позволяют группировать ресурсы на основе общего времени существования, даже если они охватывают несколько групп ресурсов или подписок. Стеки развертывания полезны при развертывании ресурсов для конкретного клиента, особенно если у вас есть подход к развертыванию, требующий развертывания различных типов ресурсов в разных местах из-за проблем масштабирования или соответствия требованиям. Стеки развертываний также позволяют легко удалять все ресурсы, связанные с одним клиентом в одной операции, если этот клиент отключен. Дополнительные сведения см. в стеках развертывания.
Неподходящие антишаблоны
- Не планируется масштабирование. Убедитесь, что у вас есть четкое представление об ограничениях развернутых ресурсов, и какие ограничения могут стать важными, так как нагрузка или число клиентов увеличивается. Планирование развертывания дополнительных ресурсов при масштабировании и тестирование плана.
- Не планируется упаковывать пакет. Даже если вам не нужно немедленно увеличивать масштаб ресурсов Azure в нескольких ресурсах, группах ресурсов и подписках. Избегайте предположений в коде приложения, таких как один ресурс, когда вам может потребоваться масштабировать несколько ресурсов в будущем.
- Масштабирование множества отдельных ресурсов. При наличии сложной топологии ресурсов может стать сложно масштабировать каждый компонент по отдельности. Часто проще масштабировать решение как единицу, следуя шаблону меток развертывания.
- Развертывание изолированных ресурсов для каждого клиента, если это не требуется. Во многих решениях эффективнее и эффективнее развертывать общие ресурсы для нескольких клиентов.
- Не удается отслеживать ресурсы для конкретного клиента. При развертывании ресурсов для конкретного клиента убедитесь, что вы понимаете, какие ресурсы выделяются для клиентов. Эта информация важна для целей соответствия требованиям, для отслеживания затрат и для отмены подготовки ресурсов, если клиент отключен. Рассмотрите возможность использования тегов ресурсов для отслеживания сведений о клиентах ресурсов и рассмотрите возможность использования стеков развертывания для группирования ресурсов для конкретного клиента в логическую единицу независимо от группы ресурсов или подписки, в которую они входит.
- Использование отдельных клиентов Microsoft Entra. Как правило, не рекомендуется подготавливать несколько клиентов Microsoft Entra. Управление ресурсами в клиентах Microsoft Entra является сложным. Проще масштабировать подписки, связанные с одним клиентом Microsoft Entra.
- Переопределения при необходимости масштабирования. В некоторых решениях вы знаете с уверенностью, что вы никогда не будете расти за пределы определенного уровня масштаба. В этих сценариях нет необходимости создавать сложную логику масштабирования. Тем не менее, если ваша организация планирует расти, вам потребуется подготовиться к масштабированию — потенциально в короткие сроки.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Джон Даунс | Главный инженер программного обеспечения
Другие участники:
- Джейсон Бек | Старший инженер по работе с клиентами, FastTrack для Azure
- Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure
- Лора Николас | Старший инженер по работе с клиентами, FastTrack для Azure
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
- Джошуа Уадделл | Старший инженер по работе с клиентами, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Ознакомьтесь с подходами к управлению затратами и распределению .