Мультитенантное решение имеет несколько плоскостей, и каждая из них несет свои обязанности. Плоскость данных позволяет конечным пользователям и клиентам взаимодействовать с системой. Плоскость управления — это компонент, который управляет задачами более высокого уровня для всех клиентов, таких как управление доступом, подготовка и обслуживание системы для поддержки задач администраторов платформы.
В этой статье содержатся сведения об обязанностях плоскостей управления и проектировании плоскости управления, которая соответствует вашим потребностям.
Например, рассмотрим систему бухгалтерского учета для управления финансовыми записями. Несколько клиентов хранят свои финансовые записи в системе. Когда конечные пользователи получают доступ к системе для просмотра и ввода финансовых записей, они используют плоскость данных. Плоскость данных, скорее всего, является основным компонентом приложения для вашего решения. Возможно, ваши клиенты считают его способом использования системы для его целевой цели. В отличие от этого, плоскость управления — это компонент, который объединяет новые клиенты, создает базы данных для каждого клиента и выполняет другие операции управления и обслуживания. Если у системы нет плоскости управления, администраторам потребуется выполнить множество ручных процессов. Или задачи плоскости данных и плоскости управления будут смешаны вместе, переусложняя решение.
Многие сложные системы включают плоскости управления. Например, плоскость управления Azure, Azure Resource Manager, представляет собой набор API, средств и внутренних компонентов, которые отвечают за развертывание и настройку ресурсов Azure. Плоскость управления Kubernetes управляет множеством задач, таких как размещение модулей pod Kubernetes на рабочих узлах. Практически все решения SaaS имеют уровень управления для обработки задач между клиентами.
При разработке мультитенантных решений необходимо учитывать плоскости управления. В следующих разделах приведены сведения, необходимые для области и проектирования плоскости управления.
Обязанности плоскости управления
Нет единого шаблона для плоскости управления или ее обязанностей. Требования и архитектура решения определяют, что нужно сделать в плоскости управления. В некоторых мультитенантных решениях плоскость управления имеет широкий спектр обязанностей и является сложной системой в собственном праве. В других мультитенантных решениях плоскость управления несет только основные обязанности.
Как правило, плоскость управления может иметь многие из следующих основных обязанностей:
- Управление ресурсами. Подготовка системных ресурсов и управление ими, которые система должна обслуживать рабочую нагрузку, включая ресурсы, относящиеся к клиенту. Уровень управления может вызывать и оркестрировать конвейер развертывания, отвечающий за развертывания, или выполнять операции развертывания.
- Конфигурация ресурсов: перенастройка общих ресурсов , чтобы знать о новых клиентах. Например, уровень управления может настроить сетевую маршрутизацию, чтобы убедиться, что входящий трафик сопоставляется с правильными ресурсами клиента или может потребоваться масштабировать емкость ресурса.
- Конфигурация клиента: хранение и управление конфигурацией каждого клиента.
- Управление жизненным циклом клиента: обработка событий жизненного цикла клиента, включая подключение, перемещение и отключение клиентов.
- Данные телеметрии. Отслеживайте использование функций каждого клиента и производительность системы.
- Отслеживание потребления: измеряйте потребление каждого клиента ресурсов вашей системы. Метрики потребления могут информировать системы выставления счетов или использовать их для управления ресурсами.
Если вы используете полностью мультитенантную модель аренды и не развертываете ресурсы для конкретного клиента, базовый уровень управления может просто отслеживать клиентов и связанные с ними метаданные. Например, всякий раз, когда новый клиент регистрируется в службе, плоскость управления может обновить соответствующие записи в базе данных, чтобы остальная часть системы могла обслуживать запросы нового клиента.
В отличие от этого, предположим, что решение использует модель развертывания, требующую инфраструктуры для конкретного клиента, например автоматизированную модель с одним клиентом. В этом сценарии уровень управления может иметь больше обязанностей, например развертывание или перенастройка инфраструктуры Azure при подключении нового клиента. В этом виде решения плоскость управления, вероятно, необходимо взаимодействовать с плоскостями управления для служб и технологий, которые вы используете, например Azure Resource Manager или плоскости управления Kubernetes.
Более сложные плоскости управления также могут взять на себя больше обязанностей:
- Выполнение автоматизированных операций обслуживания: распространенные операции обслуживания включают удаление или архивацию старых данных, создание индексов баз данных и управление ими, а также смена секретов и криптографических сертификатов.
- Размещение клиентов: выделите арендаторы для существующих развертываний или меток, которые могут основываться на различных критериях, включая целевые показатели использования меток, требования к клиенту и стратегии упаковки ячеек.
- Перебалансирование клиента: перебалансируйте существующие клиенты по меткам развертывания по мере изменения их использования.
- Отслеживание действий клиентов: интеграция с внешними решениями по управлению клиентами, такими как Microsoft Dynamics 365, для отслеживания активности клиентов.
Область действия плоскости управления
Необходимо тщательно учесть, сколько усилий необходимо потратить на создание плоскости управления для вашего решения. Сами по себе контрольные плоскости не обеспечивают непосредственное значение клиента, поэтому не может быть легко оправдать затраты на инженерные усилия по проектированию и созданию высококачественной плоскости контроля. Тем не менее, по мере роста и масштабирования системы все чаще требуется автоматизированное управление и операции, чтобы поддерживать рост.
В некоторых ситуациях может не потребоваться плоскость полного управления. Эта ситуация может применяться, если в вашей системе будет меньше 5–10 клиентов. Вместо этого ваша команда может взять на себя обязанности уровня управления и использовать ручное управление операциями и процессами для подключения клиентов и управления ими. Однако для отслеживания клиентов и их конфигураций по-прежнему должен быть процесс и центральное место.
Совет
Если вы решили не создать плоскость полного управления, рекомендуется по-прежнему систематично думать о процедурах управления:
- Тщательно задокументируйте процессы.
- Где это возможно, создайте и повторно используйте скрипты для операций управления.
Если вам нужно автоматизировать процессы в будущем, документация и сценарии могут сформировать основу плоскости управления.
По мере роста за пределами нескольких клиентов, скорее всего, вы сможете отслеживать каждого клиента и применять мониторинг по всему флоту ресурсов и клиентов. Вы также можете заметить, что ваша команда тратит все больше времени и усилий на управление клиентами. Или вы можете заметить ошибки или операционные проблемы из-за несоответствий в способах выполнения командой задач управления. Если эти ситуации возникают, стоит рассмотреть вопрос о создании более комплексной плоскости контроля, чтобы взять на себя эти обязанности.
Примечание.
Если вы предоставляете самостоятельное управление клиентами, вам потребуется плоскость управления в начале вашего путешествия. Вы можете создать базовый уровень управления и автоматизировать только некоторые из наиболее часто используемых функций. С течением времени вы можете постепенно добавлять дополнительные возможности.
Проектирование плоскости управления
После определения требований и области плоскости управления необходимо разработать и разработать его. Плоскость управления является важным компонентом. Необходимо тщательно спланировать его, как и вы планируете другие элементы системы.
Хорошо спроектированные плоскости управления
Так как уровень управления является собственной системой, важно рассмотреть все пять основных компонентов Azure Well-Architected Framework при разработке. В следующих разделах рассматриваются некоторые конкретные области, на которые следует сосредоточиться.
Надежность
Самолеты управления часто являются критически важными компонентами. Важно, чтобы вы планировали уровень устойчивости и надежности, необходимый вашему плоскости управления.
Рассмотрим, что произойдет, если уровень управления недоступен. В крайних случаях сбой плоскости управления может привести к недоступности всего решения. Даже если уровень управления не является одной точкой сбоя, сбой может иметь некоторые из следующих последствий:
- Ваша система не может подключить новых клиентов, что может повлиять на рост продаж и бизнеса.
- Ваша система не может управлять существующими клиентами, что приводит к дополнительным звонкам в службу поддержки.
- Вы не можете измерять потребление клиентов или выставлять счета за их использование, что приводит к потере дохода.
- Вы не можете реагировать на инцидент безопасности, отключив или перенастроив клиент.
- Долг на обслуживание накапливается, что приводит к долгосрочному ущербу системы. Например, если решение требует ночной очистки старых данных, диски могут заполнить или производительность может снизиться.
Определите цели уровня обслуживания для плоскости управления, включая целевые показатели доступности, целевое время восстановления (RTO) и целевую точку восстановления (RPO). Цели, заданные для плоскости управления, могут отличаться от тех, которые вы предлагаете клиентам.
Следуйте инструкциям по azure Well-Architected Framework по созданию надежных решений во всей системе, включая плоскость управления.
Безопасность
Плоскости управления часто являются высоко привилегированными системами. Проблемы безопасности в плоскости управления могут иметь катастрофические последствия. В зависимости от его дизайна и функциональности уровень управления может быть уязвим для многих различных типов атак, включая следующие:
- Уровень управления может иметь доступ к ключам и секретам для всех клиентов. Злоумышленник, имеющий доступ к плоскости управления, может получить доступ к данным или ресурсам любого клиента.
- Плоскость управления часто может развертывать новые ресурсы в Azure. Злоумышленники могут воспользоваться уровнем управления для развертывания собственных ресурсов в подписках, что может привести к значительным расходам.
- Если злоумышленник успешно переносит плоскость управления в автономный режим, может быть немедленный и долгосрочный ущерб вашей системе и вашему бизнесу. См. сведения о надежности , например о последствиях недоступности плоскости управления.
При проектировании и реализации плоскости управления необходимо следовать рекомендациям по обеспечению безопасности и создавать комплексную модель угроз для документирования и устранения потенциальных угроз и проблем безопасности в решении. Дополнительные сведения см. в руководстве по Azure Well-Architected Framework по созданию безопасных решений.
Эффективность работы
Так как плоскость управления является критически важным компонентом, необходимо тщательно рассмотреть способ развертывания и его работы в рабочей среде.
Как и в других частях решения, следует развертывать нерабочие экземпляры плоскости управления, чтобы тщательно протестировать ее функциональные возможности. Если плоскость управления выполняет операции развертывания, рассмотрите, как нерабочие плоскости управления взаимодействуют с вашей средой Azure и в какой подписке Azure развертываются нерабочие ресурсы. Кроме того, спланируйте, как быстро очистить тестовые ресурсы, чтобы они не накапливали расходы случайно.
Вы также должны планировать управление доступом вашей команды к плоскости управления. Следуйте рекомендациям по предоставлению только разрешений, необходимых участникам команды для выполнения своих обязанностей. Помимо того, чтобы избежать инцидентов безопасности, этот подход помогает снизить влияние случайной неправильной настройки.
Компоненты
Для плоскости управления нет единого шаблона, а компоненты, которые вы разрабатываете и создаете, зависят от ваших требований. Как правило, плоскость управления состоит из API и фоновых рабочих компонентов. В некоторых решениях плоскость управления может также включать пользовательский интерфейс, который может использовать ваша команда или даже ваши клиенты.
Изоляция уровня управления от рабочих нагрузок клиента
Рекомендуется разделить ресурсы плоскости управления от тех, кто использовался для обслуживания плоскостей данных клиентов. Например, следует рассмотреть возможность использования отдельных серверов баз данных, серверов приложений и других компонентов. Часто рекомендуется хранить ресурсы плоскости управления в отдельной группе ресурсов Azure от тех, которые содержат ресурсы для конкретного клиента.
Изолируя уровень управления от рабочих нагрузок клиентов, вы получаете несколько преимуществ:
- Масштабирование можно настроить отдельно. Например, уровень управления может иметь согласованные требования к ресурсам, а ресурсы клиентов могут масштабироваться эластично в зависимости от их потребностей.
- Между вашим контролем и плоскостями данных существует переборка , которая помогает предотвратить шумные проблемы соседей от распространения между плоскостями вашего решения.
- Плоскости управления обычно являются высоко привилегированными системами, имеющими высокий уровень доступа. Разделив плоскость управления от плоскостей данных, вы снижаете вероятность того, что уязвимость безопасности может позволить злоумышленникам повысить свои разрешения во всей системе.
- Можно развернуть отдельные конфигурации сети и брандмауэра. Плоскости данных и плоскости управления обычно требуют различных типов сетевого доступа.
Оркестрация последовательностей длительных операций
Операции, выполняемые плоскостем управления, часто являются длительными и связаны с координацией между несколькими системами. Операции также могут иметь сложные режимы сбоя. При разработке плоскости управления важно использовать подходящую технологию для координации длительных операций или рабочих процессов.
Например, предположим, что при подключении нового клиента плоскость управления выполняет следующие действия в последовательности:
- Разверните новую базу данных. Это действие является операцией развертывания Azure. Выполнение может занять несколько минут.
- Обновите каталог метаданных клиента. Это действие может включать выполнение команды в базе данных SQL Azure.
- Отправьте приветственное письмо новому клиенту. Это действие вызывает сторонний API для отправки сообщения электронной почты.
- Обновите систему выставления счетов, чтобы подготовиться к выставлению счетов новому клиенту. Это действие вызывает сторонний API. Вы заметили, что он периодически завершается ошибкой.
- Обновите систему управления отношениями клиентов (CRM), чтобы отслеживать новый клиент. Это действие вызывает сторонний API.
Если какой-либо шаг в последовательности завершается ошибкой, необходимо рассмотреть такие действия, как:
- Повторите неудачную операцию. Например, если команда SQL Azure на шаге 2 завершается сбоем с временной ошибкой, ее можно повторить.
- Перейдите к следующему шагу. Например, вы можете решить, что это допустимо, если обновление системы выставления счетов завершается сбоем, так как ваша команда продаж может вручную добавить клиента позже.
- Отмените рабочий процесс и активируйте процесс восстановления вручную.
Кроме того, необходимо учитывать, что такое взаимодействие с пользователем для каждого сценария сбоя.
Управление общими компонентами
Плоскость управления должна учитывать все компоненты, которые не предназначены для конкретных клиентов, но вместо этого являются общими. Некоторые компоненты могут быть общими для всех клиентов в метках. Другие компоненты могут быть общими для всех меток в регионе или даже совместно использовать их во всех регионах и метках. При подключении, перенастройке или отключении клиента необходимо знать, что делать с этими общими компонентами.
При добавлении или удалении клиента может потребоваться перенастроить некоторые общие компоненты. Например, предположим, что у вас есть глобальный общий профиль Azure Front Door. При добавлении клиента с именем личного домена может потребоваться обновить конфигурацию профиля, чтобы маршрутизировать запросы для этого доменного имени в правильное приложение. Аналогичным образом, при отключении клиента может потребоваться удалить имя личного домена из профиля Azure Front Door, чтобы избежать атак на переход поддомена.
Общие компоненты могут иметь сложные правила масштабирования, которые необходимо соблюдать в плоскости управления. Например, предположим, что вы следуете подходу к упаковке корзин для развертывания баз данных клиентов. При подключении нового клиента вы добавите новую базу данных SQL Azure для этого клиента, а затем назначьте ее эластичному пулу SQL Azure. Возможно, вам потребуется увеличить ресурсы, выделенные пулу для каждой десятой базы данных, которую вы добавили. При добавлении или удалении клиента уровень управления должен повторно оценить конфигурацию пула и решить, следует ли изменить ресурсы пула. При достижении максимального количества баз данных, которые можно назначить одному эластичному пулу, необходимо создать новый пул и начать использовать этот пул для новых баз данных клиента. Ваш уровень управления должен отвечать за управление каждым из этих общих компонентов, масштабирование и перенастройку их при каждом изменении.
Когда плоскость управления управляет общими компонентами, важно учитывать условия гонки, которые могут возникать при параллельном выполнении нескольких операций. Например, если вы подключены к новому клиенту одновременно с подключением другого клиента, необходимо убедиться, что конечное состояние является согласованным и соответствует вашим требованиям масштабирования.
Использование нескольких плоскостей управления
В сложной среде может потребоваться использовать несколько плоскостей управления, каждая из которых имеет различные области ответственности. Многие мультитенантные решения соответствуют шаблону меток развертывания и арендаторам сегментов по нескольким меткам. При использовании этого шаблона можно создать отдельные плоскости управления для глобальных и меток обязанностей.
Совет
Координация между несколькими плоскостями управления сложна, поэтому старайтесь свести к минимуму количество создаваемых плоскостей управления. Большинству решений требуется только одна плоскость управления.
Глобальные плоскости управления
Глобальная плоскость управления обычно отвечает за общее управление и отслеживание клиентов. Глобальная плоскость управления может иметь следующие обязанности:
- Размещение клиента. Глобальная плоскость управления определяет, какую метку должен использовать клиент. Это может сделать это определение на основе таких факторов, как регион клиента, использование емкости каждой метки и требования к уровню обслуживания клиента.
- Подключение клиента и управление жизненным циклом. Эти обязанности включают отслеживание всех клиентов во всех развертываниях.
Плоскости управления меткой
Плоскость управления метками развертывается в каждой метках развертывания и отвечает за арендаторы и ресурсы, выделенные для этой метки. Плоскость управления меткой может иметь следующие обязанности:
- Создание ресурсов для конкретного клиента и управление ими в метки, таких как базы данных и контейнеры хранилища.
- Управление общими ресурсами, включая мониторинг потребления общих ресурсов и развертывание новых экземпляров при подходе к максимальной емкости.
- Выполнение операций обслуживания в метки, таких как управление индексами базы данных и операции очистки.
Плоскость управления каждой метки координируется с глобальной плоскостей управления. Например, предположим, что новый клиент регистрируется. Глобальная плоскость управления изначально отвечает за выбор метки для ресурсов клиента. Затем глобальный уровень управления предложит плоскости управления метки создать необходимые ресурсы для клиента.
На следующей схеме показан пример того, как два плоскости управления могут сосуществовать в одной системе:
Плоскости управления клиентом
Клиенты могут использовать плоскость управления уровня клиента для управления собственными логическими или физическими ресурсами. Плоскость управления клиентом может иметь следующие обязанности:
- Управление конфигурацией для конкретного клиента, например доступ пользователем.
- Операции обслуживания, инициированные клиентом, например резервное копирование данных или скачивание предыдущей резервной копии.
- Управление обновлениями, если позволить клиентам управлять собственными обновлениями в своих приложениях.
На следующей схеме показана сложная система, которая имеет глобальную плоскость управления, плоскости управления меткой и плоскость управления для каждого клиента:
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Джон Даунс | Главный инженер программного обеспечения
Другие участники:
- Мик Альбертс | Технический писатель
- Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure
- Лэндон Пирс | Инженер клиента, FastTrack для Azure
- Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.