Многотенантность и служба хранилища Azure

  • Статья

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

Функции служба хранилища Azure, поддерживающие мультитенантность

служба хранилища Azure включает множество функций, поддерживающих мультитенантность.

Подписанные URL-адреса

При работе с служба хранилища Azure из клиентского приложения важно учитывать, следует ли отправлять клиентские запросы через другой компонент, который вы управляете, например сеть доставки содержимого или API, или если клиент должен подключаться непосредственно к учетной записи хранения. Могут быть веские причины для отправки запросов через другой компонент, включая кэширование данных в пограничной части сети. Однако в некоторых ситуациях для конечных точек клиента удобно подключаться непосредственно к служба хранилища Azure для скачивания или отправки данных. Это подключение помогает повысить производительность решения, особенно при работе с большими blob-объектами или большим количеством файлов. Это также снижает нагрузку на внутренние приложения и серверы, а также уменьшает количество сетевых прыжков. Подписанный URL-адрес (SAS) позволяет безопасно предоставлять клиентским приложениям доступ к объектам в служба хранилища Azure.

Сигнатуры общего доступа можно использовать для ограничения область операций, которые может выполнять клиент, и объектов, с которыми они могут выполнять операции. Например, если у вас есть общая учетная запись хранения для всех клиентов, и вы храните все данные клиента A в контейнере tenantaBLOB-объектов, можно создать SAS, который разрешает пользователям клиента A доступ к данному контейнеру. Дополнительные сведения см. в моделях изоляции, чтобы изучить подходы, которые можно использовать для изоляции данных клиентов в учетной записи хранения.

Шаблон ключа valet полезен в качестве способа выдачи ограниченных и область подписанных подписанных URL-адресов на уровне приложения. Например, предположим, что у вас есть мультитенантное приложение, позволяющее пользователям отправлять видео. Уровень API или приложения может пройти проверку подлинности клиента с помощью собственной системы проверки подлинности. Затем вы можете предоставить SAS клиенту, который позволяет им отправлять видеофайл в указанный большой двоичный объект в контейнер и путь к большому двоичному объекту. Затем клиент отправляет файл непосредственно в учетную запись хранения, избегая дополнительной пропускной способности и нагрузки на API. Если они пытаются считывать данные из контейнера BLOB-объектов или пытаются записать данные в другую часть контейнера в другой контейнер в учетной записи хранения, служба хранилища Azure блокирует запрос. Срок действия подписи истекает после настраиваемого периода времени.

Хранимые политики доступа расширяют функциональные возможности SAS, что позволяет определить одну политику, которую можно использовать при выдаче нескольких подписанных URL-адресов.

Доступ на основе удостоверений

служба хранилища Azure также предоставляет управление доступом на основе удостоверений с помощью идентификатора Microsoft Entra. Эта возможность также позволяет использовать управление доступом на основе атрибутов, что обеспечивает более точный доступ к путям BLOB-объектов или большим двоичным объектам, помеченным определенным идентификатором клиента.

Управление жизненным циклом

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

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

Неизменяемое хранилище

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

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

Копирование на стороне сервера

В мультитенантной системе иногда требуется переместить данные из одной учетной записи хранения в другую. Например, при перемещении клиента между метками развертывания или перебалансированием сегментированного набора учетных записей хранения необходимо скопировать или переместить данные конкретного клиента. При работе с большими объемами данных рекомендуется использовать ИНТЕРФЕЙСы API копирования на стороне сервера, чтобы уменьшить время, необходимое для переноса данных.

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

Если вам нужно использовать API копирования на стороне сервера непосредственно из кода, рассмотрите возможность использования API put Block From URL, Put Page From URL API, Append Block From URL API и Copy Blob From URL API при работе с небольшими BLOB-объектами.

Репликация объектов

Функция реплика tion объекта автоматически реплика tes данные между исходной и целевой учетной записью хранения. Объект реплика является асинхронным. В мультитенантном решении эта функция может оказаться полезной, если необходимо непрерывно реплика te данные между метками развертывания или реализацией шаблона геодокумента.

Шифрование

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

Наблюдение

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

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

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

служба хранилища Azure инвентаризации предоставляет другой подход к измерению общего размера контейнера BLOB-объектов.

Модели изоляции

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

служба хранилища учетные записи для каждого клиента

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

Примечание.

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

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

Модели изоляции хранилища BLOB-объектов

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

Фактор Контейнеры общих BLOB-объектов Контейнеры BLOB-объектов для каждого клиента служба хранилища учетные записи для каждого клиента
Изоляция данных Низкий средний. Используйте пути для идентификации данных каждого клиента или иерархических пространств имен Средняя. Использование URL-адресов SAS для область контейнера для поддержки изоляции безопасности Высокая
Изоляция производительности Низкая Низкая. Большинство квот и ограничений применяются ко всей учетной записи хранения Высокая
Сложность развертывания Низкая Средняя Высокая
Операционная сложность Низкая Средняя Высокая
Пример сценария Хранение небольшого количества больших двоичных объектов для каждого клиента Проблема с URL-адресами SAS область клиента Отдельные метки развертывания для каждого клиента

Контейнеры общих BLOB-объектов

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

Tenant ID Пример пути большого двоичного объекта
tenant-a https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4
tenant-b https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4

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

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

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

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

Контейнеры BLOB-объектов для каждого клиента

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

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

Модели изоляции хранилища файлов

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

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

Общие файловые ресурсы

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

Tenant ID Пример пути к файлу
tenant-a https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4
tenant-b https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4

Если вы используете приложение, которое может взаимодействовать с помощью протокола "Блок сообщений сервера" (S МБ), а также при использовании служб домен Active Directory либо в локальной среде, либо в Azure, общие папки поддерживают авторизацию на уровне общей папки и файлов.

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

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

Общие папки для каждого клиента

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

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

Модели изоляции хранилища таблиц

В следующей таблице перечислены различия между основными моделями изоляции аренды для таблиц служба хранилища Azure:

Фактор Общие таблицы с ключами секции для каждого клиента Таблицы для каждого клиента служба хранилища учетные записи для каждого клиента
Изоляция данных Низкая. Приложение применяет изоляцию Низкий средний Высокая
Изоляция производительности Низкая Низкая. Большинство квот и ограничений применяются ко всей учетной записи хранения Высокая
Сложность развертывания Низкая Средняя Высокая
Операционная сложность Низкая Средняя Высокая
Пример сценария Крупное мультитенантное решение с общим уровнем приложений Проблема с URL-адресами SAS область клиента Отдельные метки развертывания для каждого клиента

Общие таблицы с ключами секции для каждого клиента

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

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

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

Таблицы для каждого клиента

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

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

Модели изоляции хранилища очередей

В следующей таблице перечислены различия между основными моделями изоляции аренды для очередей служба хранилища Azure:

Фактор Общие очереди Очереди на клиент служба хранилища учетные записи для каждого клиента
Изоляция данных Низкая Низкий средний Высокая
Изоляция производительности Низкая Низкая. Большинство квот и ограничений применяются ко всей учетной записи хранения Высокая
Сложность развертывания Низкая Средняя Высокая
Операционная сложность Низкая Средняя Высокая
Пример сценария Крупное мультитенантное решение с общим уровнем приложений Проблема с URL-адресами SAS область клиента Отдельные метки развертывания для каждого клиента

Общие очереди

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

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

Очереди на клиент

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

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

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

Соавторы

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

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

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

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

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

Просмотрите подходы к хранилищу и данным для мультитенантности.