Тенант что это в ит
Тенанты¶
Кластер MRS предоставляет различные ресурсы и услуги для совместного использования несколькими отделами или приложениями. Для гибкого расходования ресурсов можно применять тенанты. Тенанты (tenants) — это логическая сущность, имеющая возможность использовать ресурсы и сервисы.
В настоящее время функцию использования тенантов поддерживают только аналитические кластеры (analysis clusters).
Вычислительные ресурсы связаны с ресурсами очереди задач тенантов. Данные по задачам можно посмотреть и изменить в разрезе тенантов.
Управлению тенантами присущи следующие особенности:
Роли, вычислительные ресурсы и ресурсы хранения создаются автоматически при создании тенантов. Все права на новые вычислительные ресурсы и ресурсы хранения автоматически назначаются ролям тенантов.
По умолчанию у основного тенанта (non-leaf tenant) есть права на просмотр ресурсов тенанта, создание субтенанта и управление ресурсами субтенанта.
После изменения вычислительных ресурсов или ресурсов хранения соответствующие права ролей обновляются автоматически.
Максимально можно создать 512 тенантов.
Создать тенант¶
Аналогичным способом можно создать тенант в консоли MRS.
Заполните следующие поля и нажмите кнопку ОК :
Name — укажите имя тенанта.
Tenant Type — выберите тип тенанта: Non-leaf — к данному тенанту можно создать субтенанты; Leaf — к данному тенанту ничего создать нельзя.
Dynamic Resource — при выборе Yarn — автоматически создается задание очереди в Yarn; если поле оставить пустым — задание в очереди создано не будет.
Default Resource Pool Capacity — процент ресурсов, который может использовать тенант в пуле ресурсов «default».
Default Resource Pool Max. Capacity — максимально возможный процент ресурсов, который может использовать тенант в пуле ресурсов «default».
Storage Resource — при выборе HDFS система автоматически создаст папку с именем тенанта в директории HDFS /tenant (путь автоматически пропишется в поле Storage Path ); если поле оставить пустым — новая директория создана не будет.
Storage Space Quota — укажите объем выделенного хранилища HDFS для данного тенанта.
Рекомендовано указывать величину хранилища в два раза больше расчетной, т.к. для обеспечения надежности работы сервисов при попадании в хранилище автоматически создаются копии файлов.
Service — при необходимости свяжите данного тенанта с сервисом HBase на условиях исключительного или общего владения (в поле Association Mode выберите Exclusive или Share).
Description — добавьте описание.
Создать субтенант¶
Аналогичным способом можно создать субтенант в консоли MRS.
Заполните следующие поля и нажмите кнопку ОК :
Name — укажите имя субтенанта.
Tenant Type — выберите тип субтенанта: Non-leaf — к данному субтенанту можно создать еще субтенантов; Leaf — к данному субтенанту создать других субтенантов нельзя.
Dynamic Resource — при выборе Yarn — автоматически создается задание очереди в Yarn; если поле оставить пустым — задание в очереди создано не будет.
Default Resource Pool Capacity — процент ресурсов, который может использовать субтенант в пуле ресурсов тенанта.
Default Resource Pool Max. Capacity — максимально возможный процент ресурсов, который может использовать субтенант в пуле ресурсов тенанта.
Storage Resource — при выборе HDFS система автоматически создаст папку с именем субтенанта в директории HDFS /tenant (путь автоматически пропишется в поле Storage Path ); если поле оставить пустым — новая директория создана не будет.
Storage Space Quota — укажите объем выделенного хранилища HDFS для данного субтенанта (в пределах ресурсов тенанта).
Service — при необходимости свяжите данного субтенанта с сервисом HBase на условиях исключительного или общего владения (в поле Association Mode выберите Exclusive или Share).
Description — добавьте описание.
Удалить тенант или субтенант¶
What is a Tenant?
I’ve received a lot of questions regarding confusion about what a Tenant is. This has been in the context of Power BI. Specifically with the new Public Preview and how a Tenant plays into that. So, I wanted to get something out there to try and explain what a Tenant is.
For our purposes, a Tenant is a term used for an Office 365 Organization. A Tenant is like an Apartment. If you think about an Apartment and an Apartment Complex, the complex is the foundation, the plumbing, the stair cases or Elevators. And there can be many apartments within the complex.
That is what a Tenant is. It is for your organization, and is a sandboxes environment for your and your assets. It is within the overall O365 Data Center which would be the apartment complex. The Tenant is the container for items of your Organization such as users, domains, subscriptions etc…
When you create a tenant for your organization, we will then register two different DNS entries by default. Let’s assume the tenant name we are picking is guyinacube. The two DNS entries that will be created are the following.
My tenant name is guyinacube. The default domain for the Tenant will be guyinacube.onmicrosoft.com. Any users I add at this point will have a login/email address of user@guyinacube.onmicrosoft.com if I do nothing else.
There is no cost to having a Tenant itself. The cost comes in with whatever subscriptions you have for your Tenant and the number of licenses you are paying for. This may be O365 Subscription, SharePoint Online, Exchange, Power BI, etc…
What does this mean for Power BI?
For Power BI, when you sign up for it, we check your email address. If that domain is registered as a Tenant, we will try to add that user to the existing Tenant. If the Tenant does not exist, we will create, what I call, a shadow tenant that isn’t managed by anyone, and add your user to that tenant. Other users with the same email address will be added to that as well. Check out the following documentation which explains this.
igorsmolin
Знакомимся с Office/Microsoft 365. Часть 1. Создаем тенант.
Что и зачем это?
Цикл статей представляет из себя перевод официальной документации, посвященной изучению и тестированию облачной площадки Microsoft, а также различные дополнения от автора. Сама документация в оригинале доступна здесь.
Структура статьи
Ниже приведена общая архитектура статей для демонстрации базовых функций от Microsoft. Модель состоит из четырех больших блоков:
Структура наших статей построена на документации Microsoft, однако будет отличаться. Ее можно поделить на несколько ключевых разделов:
В этой части мы сфокусируемся на первых трех пунктах.
В чем разница между Office 365 и Microsoft 365?
В определении этих двух понятий может возникать путаница. Особенно, учитывая тот факт, что Office 365 входит в состав Microsoft 365. Однако на деле все гораздо проще, чем кажется на первый взгляд.
Office 365 — набор классического и облачного ПО для повышения продуктивности пользователей распространяющийся по подписке. В состав Office 365 входит немалое количество ПО, которое, наверное, часто забывают сами ребята из Microsoft. 🙂
Вот неполный список поставляемого ПО:
Microsoft 365 — расширенный набор сервисов, включающий в себя Office 365. Помимо уже названного ПО, в состав Microsoft 365 входит: Windows 10 Enterprise, Enterprise Mobility + Security. Как и в случае с Office 365, распространяется по подписке.
Создаем новый тенант
Под понятием tenant подразумевается учетная запись организации в рамках которой предоставляются облачные услуги.
Процедура создания и настройки займет три этапа, которые тоже могут разбиваться на дополнительные этапы. Начнем.
Получаем триальную подписку E5
Предварительно нам понадобится создать учетную запись Microsoft. Переходим по ссылке — https://outlook.com/ и регистрируем новую учетную запись.
Далее переходим по ссылке — https://aka.ms/e5trial и регистрируем учетную запись для получения триальной подписки E5. Процедура состоит из четырех этапов.
1 — Указываем почтовый контакт, который мы регистрировали ранее.
Указываем недавно созданную электронную почту
2 — Заполним информацию о себе.
Также на этом этапе нам потребуется привязать номер телефона и пройти проверку.
3 — Создаем доменное имя для работы в Office 365.
Также нам необходимо создать учетную запись администратора.
4 — Краткое резюме о выполненной работе.
Office 365 предложит нам перейти к дальнейшей настройке. Вернемся к ней чуть позже. А пока — нажмем Перейти к программе установки, укажем пункт Продолжить использование домена для электронной почты и входа и выберем пункт Выйти и продолжить позже.
Конфигурируем Office 365
На этом этапе мы займемся добавлением пользователей и назначением им лицензии Office 365 E5.
Переходим по ссылке — https://portal.office365.com. Вводим ранее созданную учетную запись администратора и попадаем в центр администрирования Office 365.
Переходим в раздел Пользователи > Активные пользователи. Перед нами единственная учетная запись в нашем тенанте.
Кликнем Добавить пользователя. Введем необходимую информацию.
Назначим пользователю триальные лицензии.
После этого, мы увидим в списке вновь созданного облачного пользователя.
Добавляем домен в Office 365
Переходим во вкладку Параметры > Домены. Здесь мы увидим подключенные домены в нашем тенанте.
Выберем кнопку Добавить домен и укажем свое доменное имя.
Мастер настройки сообщит нам о необходимости проверки прав на этот домен. От нас потребуется добавить TXT запись.
После проверки существования записи со стороны Microsoft, нам будет предложено создать дополнительные, необходимые для корректной работы сервисов Microsoft, DNS записи. Пока что нам достаточно просто привязать домен, поэтому мы проигнорируем предложение и завершим процедуру.
Нашей конфигурацией Office 365 уже можно пользоваться. Как минимум мы можем использовать классические и облачные версии приложений Office 365. Однако, скорее всего, пользователей у вас больше, чем один. Также, вероятно, что у вас есть свой приземленный домен Active Directory, где хранится информация о пользователях.
Далее мы узнаем, как можно автоматически синхронизировать пользователей из локального AD в облако, но перед этим нам понадобится смоделировать необходимую инфраструктуру.
Разворачиваем дополнительную инфраструктуру
Для решения задачи синхронизации учетных записей, которая возникла в прошлом разделе, а также для изучения части функций Office 365 нам потребуется дополнительная приземленная инфраструктура. В этой статье мы развернем тестовое окружение в виде нескольких виртуальных машин.
Для этого предлагаю воспользоваться готовыми сценариями автоматизации развертывания Active Directory под названием AD_1.0 или AD_1.1 — https://github.com/mdcowse/vagrant-sandboxie. Именно такой вариант был использован при подготовке к статье. Если нужны подробности или просто интересно понять как оно работает — рекомендую почитать эту статью.
После развертывания этого сценария в нашем распоряжении будут две виртуальных машины: контроллер домена и клиентский компьютер.
Конечно, никто не мешает развернуть необходимую инфраструктуру самостоятельно любым другим способом.
Устанавливаем Azure AD Connect
Возвращаемся к задаче синхронизации учетных записей между локальным AD и Office 365 и познакомимся с инструментом Azure AD Connect.
Azure AD Connect — дополнительное ПО, позволяющее решать задачи которые возникают при интеграции приземленного экземпляра Active Direcroty и облачного Azure Active Directory. В этой статье мы обсудим установку инструмента и одну из его функций — Password Hash Synchronization.
Учитывая, что в нашем тестовом окружении не такой большой выбор, куда можно установить программу, развернем его на контроллере домена.
Перейдем по ссылке — https://aka.ms/aadconnect и скачаем ПО. Немного пройдемся по мастеру установки для более подробного описания и понимания что происходит под капотом в процессе инсталляции, поэтому нажимаем кнопку Customize.
На первом этапе мы выбираем метод аутентификации пользователей. Указываем первый вариант — Password Hash Synchronization. Использование этой опции позволит нам решить задачу синхронизации учетных записей пользователей в облако.
На следующем этапе нам потребуется ввести учетные данные администратора тенанта Office 365 для подключения к Azure AD.
Переходим к настройкам синхронизации. Укажем локальный домен и выбираем Add Directory.
Создаем новый аккаунт для задачи синхронизации в Azure AD. Указываем для этого учетные данные администратора.
В случае успеха установщик сообщит нам об этом и мы сможем перейти к следующему этапу.
Переходим к настройке входа в Azure AD. Установщик предлагает нам выбрать домен, который будет синхронизирован из локальной AD и использован для входа нашими пользователями при входе в облачные сервисы Office 365.
Обратите внимание, что название домена party.hard мы не сможем выбрать, т.к в интернете нет информации о нем по причине отсутствия зоны hard. В таком случае мы можем создать в AD UPN-суффикс igorsmolin.ru для нашего домена party.hard и использовать его для входа в Office 365. Процедуру проверки домена мы уже проходили ранее, поэтому статус — Verified.
Также мы можем выбрать ключевой атрибут пользователя, на основе которого, будет генерироваться учетная запись в облаке.
Далее идут настройки фильтрации Organizational Unit локальной Active Directory. Чтобы не синхронизировать все подряд, мы можем явно указать OU для синхронизации объектов.
Остальные настройки пока можно пропустить.
Мы готовы к установке Azure AD Connect. После установки ПО будет выполнена начальная синхронизация учетных записей.
Как итог — мы увидим подобное сообщение.
Предлагаю проверить результаты синхронизации. Перед ее выполнением в локальном Active Direcotry существовала учетная запись — user1. В качестве имени домена в учетной записи указан UPN-суффикс igorsmolin.ru.
Зайдем в портал администрирования Office 365 во вкладку Пользователи > Активные пользователи.
Теперь попробуем зайти в Office 365 используя синхронизированные учетные данные.
Вход был выполнен успешно. Похоже, что нам удалось установить Azure AD Connect и синхронизировать учетные данные между локальными и облачными экземплярами Active Directory.
Это была первая часть цикла статей по облачным сервисам Microsoft. Сегодня нам удалось разобраться в базовых понятиях, развернуть свой тенант, а также необходимую инфраструктуру и выполнить синхронизацию учетных данных. Все это послужит базой для изучения функций в следующих частях, где мы сфокусируемся на изучении функций Office и Microsoft 365.
Мультитенантность на примере DjangoORM и PostgreSQL
Mar 1, 2019 11:55 · 1859 words · 9 minute read python django tutorial
Что такое SaaS и тенант?
Модели реализации
Итак, у нас есть некоторый продукт, который разрабатывался для одного заказчика. В общем случае он состоит из сервера приложений и базы данных. Потом ваше начальство заметило, что его же почти без переделок можно продать ещё нескольким клиентам. В случае, если у вас уже реализована какая-либо оркестрация, то скорее всего проще будет развернуть рядом ещё один кластер k8s или Docker Swarm. Это вполне рабочее решение, которое успешно масштабируется. Да, будут накладные расходы на поддержание окружений в едином состоянии и одной версии, но иногда это вполне допустимо.
Первые проблемы
Реализация шардирования
Но потом приходит жирный клиент, садится в первую базу данных, и она умирает вместе с зелёным с жёлтым клиентами. Они будут не очень этому рады. Тут скорее всего надо будет правильно подобрать ключ шардирования, чтобы добавить нового большого клиента на отдельный сервер, не затронув работу остальных. Мне кажется, что в общем случае это можно будет сделать только вручную, но это не наш путь. Регистрация нового клиента должна быть автоматическая и занимать пару минут. Так что двигаемся дальше.
Схема мультитенантности
У этой схемы есть ряд плюсов:
Уровни изоляции данных клиентов
Собственная реализация
Для того, чтобы понимать как уже готовые библиотеки работают под капотом, я люблю делать свои велосипеды и сразу же их выбрасывать. Давайте попробуем реализовать минимально необходимый для приложения функционал.
В Django есть несколько способов сделать это. Во-первых, использовать using() при построении каждого запроса через ORM.
Но, собственно, откуда этот самый id клиента брать? Ну раз у вас SaaS, то скорее всего клиенты висят на разных поддоменах, и вот по названию поддомена смотреть какой это клиент. Или при логине пользователя добавлять ключ в его сессию. Вот так:
Окей, но в случае первого запроса нового клиента приложение упадёт, т.к. не найдёт подходящую БД. Напоминаю, что их список жёстко прописан в settings.py и неизменен в процессе выполнения приложения. Так давайте сделаем его динамическим, а именно классом, который прикидывается словарём:
Я не буду подробно останавливаться на создании БД, лишь пройдусь по пунктам:
Подключиться к серверу Postgres через psycopg2, не используя ORM:
Создать через курсор новую базу. Причём я советую иметь некую пустую шаблонную базу для того, чтобы сократить время миграции:
Инициализировать её в роутере:
Запустить миграции, которых ещё нет в шаблонной базе:
Всё, можно катить в прод! Шутка, ещё рано. Что если код выполняется вне контекста, то есть у нас нет запроса, нет домена и непонятно из какой бд читать? Например, задача celery или менеджмент команда.
Тут придётся использовать менеджер контекстов и явно в коде говорить для какого клиента должен быть выполнен следующий код:
Не очень красиво, но что поделать. Внизу же пример использования в декораторе foreach_client, который проходит по всем клиентам и выполняет какую-то функцию. Например, миграции. Очень полезная вещь, скорее всего и у вас появится что-то похожее. Кстати, здесь пример упрощён, а вообще можно распараллелить этот процесс:
Это что касается работы с базой, но надо ж ещё корректно обновить ключи кеширования, обработку URL и тому подобное. Скорее всего кто-то это уже делал до меня, и лучше взять готовую библиотеку.
Заключение
Мультитенантность: как вырастить из одного приложения линейку независимых продуктов
Мультитенантность (мультиарендность) – особенность архитектуры ПО, которая позволяет приложению обслуживать несколько независимых арендаторов. Пользователи не мешают друг другу, их данные хранятся независимо и безопасно, а разработчики могут быстро запускать версии продукта с разными техническими возможностями.
В первую очередь мультитенантность нужна SaaS-продуктам, но не только. Этот подход применяется везде, где компания параллельно поддерживает несколько версий одного продукта.
— Одно подразделение в компании продаёт услуги частным клиентам, другое работает с юридическими лицами. В обоих случаях сотрудники используют одну и ту же систему продаж, но набор функций им нужен разный.
— Организация покупает стороннюю компанию, и её нужно подключить к приложению, с которым работают все сотрудники предприятия. При этом данные двух структур должны обрабатываться независимо, должны существовать независимые пространства имён.
— Компания создаёт разные версии одного продукта, которые рассчитаны на разные группы пользователей. Ядро решения остаётся одним, а возможности меняются в зависимости от того, что нужно клиентам.
Без мультитенантности разработчикам приходится встраивать в код переключатели и ограничители функций, настраивать политики доступа, следить за тем, чтобы данные не пересекались, вручную управлять доступом к ресурсам. При запуске каждой новой фичи нужно тщательно продумать, кто должен с ней работать и как на архитектурном уровне ограничить доступ для тех, кому она не нужна.
В мультиарендном приложении функции можно включать и выключать для разных групп пользователей, на уровне поставок настраивать уровни доступа и правила обращения с данными. Даже если у продукта пять версий, управлять ими может одна команда разработчиков.
Данные из каждого бизнес-модуля поступают в выделенную среду. Процессы внутри продукта организованы таким образом, чтобы разные арендаторы не мешали друг другу:
· Микросервисная архитектура позволяет выделять ресурсы для разных процессов и распределять их между пользователями.
· Службы метаданных и контекста получателя обрабатывают данные каждого отдельного бизнес-заказчика, позволяя каждому создавать собственные сущности для определения пользователей, систем-источников данных, и необходимых действий.
· Ключи-идентификаторы используются для распределения потоков данных между разными пользователями и внутри своей собственной ИТ-экосистемы.
Всё это позволяет мультиарендному продукту разграничивать данные и процессы как на уровне отдельных заказчиков, так и на уровне конечных пользователей.
1. Единый пул ресурсов, единое хранилище данных, одна инсталляция, разделение на уровне софта.
Такое приложение само понимает, куда пустить каких пользователей и какие функции им требуются. Этот сценарий обеспечивает оптимальное использование ресурсов, простое администрирование и развитие ПО.
Это мультиарендность на уровне ядра. Именно по такому пути стоит следовать, если вы создаёте мультитенантное приложение с нуля.
2. Единое хранилище данных, одна инсталляция ПО, пул ресурсов у каждого тенанта свой.
В этом случае разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу.
В этом случае ресурсы используются менее экономично, зато у каждого арендатора есть гарантированные мощности – ведь он использует собственный пул. Архитектурно такой подход проще, чем первый вариант, и если у вашей компании есть собственный ЦОД, он действительно может оказаться оптимальным.
3. У каждого арендатора есть собственная инсталляция ПО, собственный пул ресурсов, собственное хранилище.
Наименее экономичный вариант, требует больше всего ресурсов поддержки. По сути своей, каждый арендатор получает собственную копию приложения. Так что и разработчикам нужно развивать каждую версию отдельно, и поддержка у них строится независимо. Если компании нужно контролировать всю ситуацию целиком, нужно строить некое интеграционное решение.
Такой сценарий подходит для приложений, которые разрабатывались без расчёта на мультиарендное использование. Это не мультитенантность в полном смысле этого слова – скорее, способ добиться части её возможностей, когда переделывать продукт оказывается слишком дорого или нецелесообразно по другим причинам.
Мультитенантность закладывается на уровне архитектуры, так что в идеальной ситуации нужно продумывать такие возможности нужно с самых первых шагов работы над приложением.
Разработка мультитенантных продуктов строится по принципу Feature-driven Development (Trunk Based Development). Разработчики создают новые функции, которые можно включать и выключать для разных групп пользователей.
Именно с перехода на Trunk Based Development мы рекомендуем начинать путь к мультитенантности. Это позволит разработчикам взглянуть на продукт как на набор функций, из которых можно составлять параллельные версии.