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

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

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

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

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

Многие сложные системы включают контрольную плоскость. Например, уровень управления Azure, Azure Resource Manager, представляет собой набор API, средств и внутренних компонентов, которые развертывают и настраивают ресурсы Azure. А плоскость управления Kubernetes управляет множеством задач, таких как размещение модулей pod Kubernetes на рабочих узлах. Практически все решения SaaS имеют уровень управления для обработки задач между клиентами.

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

Обязанности плоскости управления

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

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

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

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

• Конфигурация клиента: Он хранит конфигурацию каждого клиента и управляет ими.

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

• Телеметрия: Он отслеживает использование функций каждого клиента и производительность системы.

• Отслеживание потребления: Он измеряет и агрегирует потребление ресурсов каждого клиента. Метрики потребления могут информировать системы выставления счетов или поддерживать управление ресурсами.

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

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

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

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

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

• Перебалансировка арендатора: Она перебалансирует существующие арендаторы по меткам развертывания по мере изменения их использования.

• Отслеживание действий клиентов: Он интегрируется с внешними решениями по управлению клиентами, такими как Dynamics 365, для отслеживания действий клиентов.

Область действия плоскости управления

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

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

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

Проектирование плоскости управления

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

Соображения

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

Плоскость управления функционирует как собственная система, поэтому при проектировании следует учитывать все пять основных компонентов платформыWell-Architected Framework . В следующих разделах рассматриваются конкретные области, на которые следует сосредоточиться.

Надежность

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

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

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

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

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

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

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

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

Определите цели уровня обслуживания для плоскости управления, включая целевые показатели доступности, целевое время восстановления (RTO) и целевую точку восстановления (RPO). Цели, которые вы определяете для контролирующей плоскости, могут отличаться от целей, которые вы предлагаете клиентам.

Безопасность

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

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

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

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

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

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

Операционное превосходство

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

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

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

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

Компоненты

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

Изоляция уровня управления от рабочих нагрузок клиента

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

Изоляция плоскости управления обеспечивает следующие преимущества:

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

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

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

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

Оркестрация последовательностей длительных операций

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

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

1. Разверните новую базу данных. Эта операция развертывания Azure может занять несколько минут.

2. Обновите каталог метаданных клиента. Это действие может включать выполнение команды в базе данных SQL Azure.

3. Отправьте приветственное письмо новому клиенту. Это действие вызывает API, отличный от Майкрософт, для отправки сообщения электронной почты.

4. Обновите систему выставления счетов, чтобы подготовиться к выставлению счетов новому клиенту. Это действие вызывает API, отличный от Майкрософт, который иногда завершается сбоем.

5. Обновите систему управления отношениями клиентов (CRM), чтобы отслеживать новый клиент. Это действие вызывает API, отличный от Майкрософт.

Если какой-либо шаг в последовательности завершается ошибкой, рассмотрите способ реагирования:

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

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

• Отмените рабочий процесс и активируйте процесс восстановления вручную.

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

Управление общими компонентами

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

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

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

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

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

Использование нескольких плоскостей управления

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

Глобальные плоскости управления

Глобальная контрольная плоскость обычно обрабатывает общее управление и отслеживание арендаторов. Глобальная плоскость управления может иметь следующие обязанности:

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

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

Плоскости управления меткой

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

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

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

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

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

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

Плоскости управления клиентом

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

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

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

• Управление обновлениями: Он выполняет обновления, если клиенты могут управлять собственными обновлениями своих приложений.

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

Соавторы

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

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

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

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

• Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure
• Лэндон Пирс | Инженер клиента, FastTrack для Azure
• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

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

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

• Хорошо спроектированная платформа

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

• Общие сведения об архитектуре
• Архитектурные подходы для плоскостей управления в мультитенантных решениях