что такое тенант в ит
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.
Мультитенантность: как вырастить из одного приложения линейку независимых продуктов
Мультитенантность (мультиарендность) – особенность архитектуры ПО, которая позволяет приложению обслуживать несколько независимых арендаторов. Пользователи не мешают друг другу, их данные хранятся независимо и безопасно, а разработчики могут быстро запускать версии продукта с разными техническими возможностями.
В первую очередь мультитенантность нужна SaaS-продуктам, но не только. Этот подход применяется везде, где компания параллельно поддерживает несколько версий одного продукта.
— Одно подразделение в компании продаёт услуги частным клиентам, другое работает с юридическими лицами. В обоих случаях сотрудники используют одну и ту же систему продаж, но набор функций им нужен разный.
— Организация покупает стороннюю компанию, и её нужно подключить к приложению, с которым работают все сотрудники предприятия. При этом данные двух структур должны обрабатываться независимо, должны существовать независимые пространства имён.
— Компания создаёт разные версии одного продукта, которые рассчитаны на разные группы пользователей. Ядро решения остаётся одним, а возможности меняются в зависимости от того, что нужно клиентам.
Без мультитенантности разработчикам приходится встраивать в код переключатели и ограничители функций, настраивать политики доступа, следить за тем, чтобы данные не пересекались, вручную управлять доступом к ресурсам. При запуске каждой новой фичи нужно тщательно продумать, кто должен с ней работать и как на архитектурном уровне ограничить доступ для тех, кому она не нужна.
В мультиарендном приложении функции можно включать и выключать для разных групп пользователей, на уровне поставок настраивать уровни доступа и правила обращения с данными. Даже если у продукта пять версий, управлять ими может одна команда разработчиков.
Данные из каждого бизнес-модуля поступают в выделенную среду. Процессы внутри продукта организованы таким образом, чтобы разные арендаторы не мешали друг другу:
· Микросервисная архитектура позволяет выделять ресурсы для разных процессов и распределять их между пользователями.
· Службы метаданных и контекста получателя обрабатывают данные каждого отдельного бизнес-заказчика, позволяя каждому создавать собственные сущности для определения пользователей, систем-источников данных, и необходимых действий.
· Ключи-идентификаторы используются для распределения потоков данных между разными пользователями и внутри своей собственной ИТ-экосистемы.
Всё это позволяет мультиарендному продукту разграничивать данные и процессы как на уровне отдельных заказчиков, так и на уровне конечных пользователей.
1. Единый пул ресурсов, единое хранилище данных, одна инсталляция, разделение на уровне софта.
Такое приложение само понимает, куда пустить каких пользователей и какие функции им требуются. Этот сценарий обеспечивает оптимальное использование ресурсов, простое администрирование и развитие ПО.
Это мультиарендность на уровне ядра. Именно по такому пути стоит следовать, если вы создаёте мультитенантное приложение с нуля.
2. Единое хранилище данных, одна инсталляция ПО, пул ресурсов у каждого тенанта свой.
В этом случае разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу.
В этом случае ресурсы используются менее экономично, зато у каждого арендатора есть гарантированные мощности – ведь он использует собственный пул. Архитектурно такой подход проще, чем первый вариант, и если у вашей компании есть собственный ЦОД, он действительно может оказаться оптимальным.
3. У каждого арендатора есть собственная инсталляция ПО, собственный пул ресурсов, собственное хранилище.
Наименее экономичный вариант, требует больше всего ресурсов поддержки. По сути своей, каждый арендатор получает собственную копию приложения. Так что и разработчикам нужно развивать каждую версию отдельно, и поддержка у них строится независимо. Если компании нужно контролировать всю ситуацию целиком, нужно строить некое интеграционное решение.
Такой сценарий подходит для приложений, которые разрабатывались без расчёта на мультиарендное использование. Это не мультитенантность в полном смысле этого слова – скорее, способ добиться части её возможностей, когда переделывать продукт оказывается слишком дорого или нецелесообразно по другим причинам.
Мультитенантность закладывается на уровне архитектуры, так что в идеальной ситуации нужно продумывать такие возможности нужно с самых первых шагов работы над приложением.
Разработка мультитенантных продуктов строится по принципу Feature-driven Development (Trunk Based Development). Разработчики создают новые функции, которые можно включать и выключать для разных групп пользователей.
Именно с перехода на Trunk Based Development мы рекомендуем начинать путь к мультитенантности. Это позволит разработчикам взглянуть на продукт как на набор функций, из которых можно составлять параллельные версии.
Multi-tenant Архитектура Данных
Привет Хабр! 
Давным-давно, были компьютеры размером в несколько этажей, и несколько операторов работали с одни мощным ЭВМ. Затем это чудо техники смогли уменьшить до настольного размера и поставить его в каждый дом. Теперь опять, новшеством считаются «облачные вычисления», хм… всё ведь сводится к нескольким терминалам и одной мощной ЭВМ датацентру. Что ж, подождём, пока датацентр гугла уменьшат до размера ноутбука…
Введение
После 2000-го года в жизнь разработчиков и архитекторов, заказчиков и многих других, имеющих отношение к ИТ, вошёл термин-акроним SaaS (software as a service). Суть SaaS сводится к тому, что Исполнитель разрабатывает ПО, размещает его на серверах, поддерживает его работоспособность, безопасность, доступность для заказчиков (обычно во множественном числе) и естественно сам платит за сервера и иные расходы.
Клиент платит за использование сервисов и не думает о покупке серверов и их обслуживании. Такой подход дешевле для Клиента и окупается для Исполнителя (т.к. решает проблемы с лицензированием и пиратством, и самое главное один сервис может предоставляться нескольким клиентам). Однако Клиент должен доверять Исполнителю, т.к. все его данные располагаются далеко-далеко.
Естественно, что такое решение заставило искать компромиссы в области размещения и разделения данных.
Так как рассказывать что-либо без примера достаточно проблематично, рассмотрим абстрактную задачу.
Задача
Для Клиента удобство такой системы очевидно – сотрудники компании заходят в систему и видят все необходимые данные для более выгодной и удобной работы. Исполнитель же может не беспокоиться за несанкционированное использование разработанной системы, а самое главное, эту систему можно одновременно использовать для нескольких Клиентов, так как задача одна и та же, то и структура базы данных так же будет идентична. И вот тут дерево решений разветвляется, но об этом позже.
Итого: есть несколько заказчиков, которые пишут и читают в базу данных и ничего не знают друг о друге. Необходимо обеспечить их изоляцию друг от друга и эффективное использование аппаратуры и ПО.
Решение: MULTI-TENANT
Первое решение, которое приходит в голову, чтобы разделить данные разных заказчиков будем хранить их в разных базах данных (изолированный подход). Как альтернатива, можно хранить все данные в одной базе данных, введя дополнительное поле TenantID, по которому их различать (общий подход). Не смотря на всю двоичность логики, решений оказалось не два, а больше. Данный факт весьма убедительно представлен на картинке, позаимствованной из msdn’а:
Разные Базы Данных
Данное решение – первое, что приходит в голову, является простейшей реализацией разделения данных.
При таком подходе код разделяется между клиентами (используется общие файлы UI и бизнес логики), а данные логически (а возможно и физически) разделяются между собой.
Преимущества:
Недостатки:
В итоге, несмотря на высокую цену, это наиболее правильное решение для клиентов, главной целью которых является безопасность, и которые готовы заплатить (например, банки).
Общая база данных, разные схемы
Итак, мы решили хранить всё в одной базе данных, как это сделать без введения дополнительного поля TenantID? Хранить информацию от разных клиентов в разных таблицах. Для реализации этого способа нам помогут схемы(schema). По сути, схемы это “пространства имён”, которые содержат определённые ресурсы (таблицы например), и на которые можно давать определённые разрешения.
Преимущества:
Недостатки:
Общая база данных, общая схема
Самый третий вариант – хранить всё в одной базе данных и в общих таблицах. Для реализации такого варианта необходимым условием будет введение дополнительного поля TenantID (либо CustomerID как кому нравится) для разделения информации между заказчиками.
Преимущества:
Недостатки:
Суровая реальность
Так как первый вариант (разные базы данных) могут себе позволить не все, то наиболее целесообразным будет использовать вариант с общей базой данных. Но на этом пути нас ждёт несколько неожиданных внезапностей. 
Итак, выберем самый дешёвый вариант как рабочий. Представим, что базы у нас не падают, а жёсткие диски вечны. И вот наша система целый год работает успешно и все довольны, накопились гигабайты данных, и внезапно всё начинает работать медленнее и медленнее. СУБД это не чёрный ящик, её тоже надо настраивать. Проблема банальна – данные пишутся в одну таблицу, в один файл, а значит, и на винчестер попадают друг за другом. А теперь представим, как происходит выборка данных для одного клиента: головка винчестера (да простят меня поклонники SSD винчестеров) медленно читает в буфер всё подряд, а записи с нужным TenantID могут появиться ещё не скоро. А теперь представьте, что нам надо перенести в архив данные одного клиента (удалив их в нашей базе).
Индексы скажете вы? – Дорого скажу я. Кроме того, даже при наличии индексов, данные всё равно будут лежать в разных частях диска.
Есть весьма элегантное решение, доступное в enterprise версиях СУБД называемое Partitioning (Секционирование), суть его можно посмотреть на рисунке:
С partitoning, данные одного клиента располагаются последовательно, в отдельном от остальных месте. Для простоты можно считать, что данные каждого клиента лежат на отдельном логическом диске. Данная возможность поддерживается на уровне СУБД, так что писать драйверов и изобретать велосипедов не нужно.