что такое тенант в ит
tenant
арендатор
Лицо, которое заключает договор аренды и которому предоставляется имущество в аренду.
[ОАО РАО «ЕЭС России» СТО 17330282.27.010.001-2008]
арендатор
Физическое или юридическое лицо, имеющее договорные отношения с оператором связи на получение в исключительное пользование (аренду) средств электросвязи на срок, определенный договором.
[Руководящий документ «Основные положения развития Взаимоувязанной сети связи Российской Федерации на перспективу до 2005 года»]
арендатор
Лицо, которое заключает договор аренды и которому предоставляется имущество в аренду. Арендатор с рангом ААА – наиболее надежный, имеющий хорошую кредитную историю.
[http://slovar-lopatnikov.ru/]
Тематики
арендатор (в информационных технологиях)
Организация (или физическое лицо), разместившая свое оборудование в ЦОДе на правах аренды.
[http://www.dtln.ru/slovar-terminov]
Тематики
Смотреть что такое «tenant» в других словарях:
tenant — tenant, ante [ tənɑ̃, ɑ̃t ] adj. et n. • XIIIe « tenace »; 1160 « stable, ferme »; de tenir I ♦ Adj. 1 ♦ Qui « se tient », ne s interrompt pas. Séance tenante. 2 ♦ (mil. XXe) Chemise à col tenant, qui ti … Encyclopédie Universelle
tenant — ten·ant / te nənt/ n [Anglo French, from Old French, from present participle of tenir to hold, from Latin tenēre]: one who holds or possesses property by any kind of right: one who holds a tenancy in property; specif: one who possesses property… … Law dictionary
tenant — tenant, ante (te nan, nan t ) adj. 1° Qui tient ; usité dans très peu de locutions. Séance tenante, dans le cours de la séance. Je vous remercie, mais rancune tenante, c est à dire sans renoncer à ma rancune. Anciennement, les plaids… … Dictionnaire de la Langue Française d’Émile Littré
Tenant — Ten ant, n. [F. tenant, p. pr. of tenir to hold. See
tenant — Tenant, Tantost signifie un homme chiche, Tenax. Tantost le limite par flanc, soit d un champ, soit d une maison, dont l opposite est Abboutissant, qui est le limite par front. Selon cette signification on dit, Bailler la declaration d un… … Thresor de la langue françoyse
tenant — TENÁNT, Ă adj. (Herald (heraldic).; despre figuri antropomorfe sau zoomorfe) Care susţine scutul cu stema propriu zisă. [< fr. tenant]. Trimis de LauraGellner, 13.09.2007. Sursa: DN TENÁNT s. m. 1. (herald.) figură antropomorfă sau zoomorfă… … Dicționar Român
Tenant — Ten ant, v. t. [imp. & p. p.
Tenant — Porté en Limousin, en Périgord et dans le Lyonnais, correspond à l ancien français tenant (occitan tenent ), sans doute avec le sens de tenancier (autre sens possible : avare). Variante : Tenand (01) … Noms de famille
tenant — early 14c., person who holds lands by title or by lease, from Anglo Fr. tenaunt (late 13c.), O.Fr. tenant (12c.), noun use of prp. of tenir to hold, from L. tenere hold, keep (see TENET (Cf. tenet)) … Etymology dictionary
Мультитенантность на примере 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 и тому подобное. Скорее всего кто-то это уже делал до меня, и лучше взять готовую библиотеку.
Заключение
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.
Мультитенантная архитектура для SaaS приложений
Что такое мультитенантность (multitenancy)?
Самыми простыми словами мультитенантность — это возможность изолированно обслуживать пользователей из разных организацией (т.е. независимых подписчиков SaaS) в рамках одного сервиса (одной инсталляции или развертывания). Основным здесь является соблюдение изолированности подписчиков друг от друга. Действительно, клиенты не обрадуются, если данные, которые они хранят в вашем SaaS приложении, будут доступны при поиске для других клиентов. Это явное нарушение изолированности.
Мультитенантность бывает разной, например, ее можно представить следующей схемой: 
Сейчас очень часто мультитенатность фигурирует совместно с терминов облачные вычисления, но фактически мультитенантность в некотором своем проявлении была актуальной и раньше, например, для хостинг-площадок. Например, SQL Server и IIS позволяют администрировать базы и сайты независимо: когда вы заходите в IIS Management Console удаленного сервера то, вы видите только свои сайты, аналогично для SQL Server – в Management Console вы видите и управляете только своей базой. Это так же можно назвать вариацией мультитенантности – все клиенты хостинга живут на одном веб-сервере или сервере базы данных, но работают только со своими узлами\элементами\данными. Мультитенантность так же является неотъемлемой частью многих ERP и CRM систем (Multi-tenant versus Single-tenant ERP – a comparison).
Для своего SaaS приложения позаботиться о мультитенантности уже предстоит вам, хотя в этом вам могут помочь имеющиеся фичи или готовы компоненты, например, которые предоставляют PaaS-платформы. Вообще говоря, проще сразу проектировать приложение с фокусом на мультитенантность, чем потом приложение «перепроектировать» для ее поддержки.
В чем преимущества мультитенантного подхода?
Кроме мультитенантной архитектуры бывает выделенная архитектура (single-tenant), когда для каждого пользователя предоставляется собственная инфраструктура (это характерно для не SaaS приложений): логические или физические сервера. Для облачных сервисов подобный подход может быть не оправданным, т.к. для каждого подписчика выделяются фиксированные ресурсы, независимо от того, сколько их требуется (а это увеличивает конечную стоимость SaaS подписки для пользователя, в итоге может оказаться, что стоимость решения будет выше, чем у конкурентов). Подобная выделенная архитектура для облачных сервисов может быть оправдана только для premium подписок и т.д.
Мультитенантная архитектура является кардинальным способом снижения стоимости вычислительных ресурсов и хранилища для SaaS решений: за счет минимально необходимого количества используемых ресурсов (разделяемой инфраструктуры) и их максимальной загрузки. Наиболее ощутимой выгода становится при сочетании мультитенантности и «неограниченного масштабирования» (когда нет необходимости затрачивать дополнительные средства на провиженинг дополнительных ресурсов или добавления новых серверов). Неограниченное масштабирование можно попробовать реализовать своими силами или использовать облачные PaaS платформы.
Источник: Cloud Computing: Sharpen Your SAAS Smarts Before Committing to the Cloud
И все-таки что выбрать выделенную модель или мультитенантную?
Мультитенантность тоже бывает разной, например, на уровне данных, на уровне ресурсов и т.п. И все это можно комбинировать, использовать все вместе или вообще не использовать.
Источник: Multi-Tenant Data Strategies for Windows Azure – Part 1
Поэтому нет правильного или неправильного ответа на вопрос выбора того или иного подхода, но есть ряд факторов, которые могут повлиять на ваш выбор. Расскажу далее об этих факторах на примере платформы Widows Azure, хотя большинство из них применимы и для других облачных платформ.
Архитектура
1. В мультитенантном приложении вы всегда можете эмулировать выделенный режим (один подписчик), тогда как возможности расширить выделенное приложение до нескольких независимых подписок обычно отсутствует.
2. Отказоустойчивость. Мультитенатное приложение более уязвимо к сбою экземпляра, чем выделенное приложение. Сбой выделенного развертывания влияет только на клиента, который использует данное приложение, тогда как сбой мультитенатного приложения затронет всех клиентов.
Уменьшить негативные последствия при сбое можно с помощью нескольких экземпляров мультитенатного приложения или его части. Например, Windows Azure может уменьшить этот риск, позволяя выполнить развертывание нескольких идентичных копий приложения за счет использования нескольких экземпляров ролей (такое подход как раз в полной мере реализует мультитенатную модель с несколькими экземплярами). Windows Azure автоматически распределяет нагрузку по обработке запросов между данными экземплярами ролей, следовательно, приложение должно быть разработано таким образом, чтобы оно корректно функционировало при использовании нескольких экземпляров. Например, если приложение использует состояние сеанса, необходимо убедиться, что каждый экземпляр веб-роли может получить доступ к состоянию. Так же Windows Azure выполняет постоянный мониторинг всех экземпляров ролей и автоматически перезапускает экземпляры при возникновении сбоя.
Для некоторых приложений может быть не целесообразным совместное использование всеми клиентами одного мультитенантного развертывания. Например, может понадобиться сгруппировать клиентов на основе функциональности приложения, которую они используют, а затем оптимизировать каждый экземпляр для каждой из созданных групп. В этом случае вам может потребоваться две или более копии мультитенатного приложения, развернутого даже в различных подписка Windows Azure.
3. Соглашение об уровне обслуживания (SLA). Вы можете предлагать различные соглашения об уровне обслуживания (SLA) для различных уровней подписки на сервис. Если подписчики с разными соглашениями об уровне обслуживания совместно используют одно мультитенантное развертывание, следует обеспечить самый высокий SLA.
4. Правовая и нормативная среда. Для некоторых приложений необходимо учитывать конкретные нормативные или юридические вопросы. Для этого могут потребоваться различия в функциональных возможностях, отображение в пользовательском интерфейсе юридических соглашений, обеспечение отдельных баз данных или областей хранилища для каждого конкретного подписчика, расположение сервиса и хранилища в конкретном географическом регионе. При таких условиях может потребоваться реализовать отдельные мультитенантные развертывания для различных групп пользователей, либо строго выделенный режим для каждой подписки на сервис.
5. Проверка подлинности и авторизации. Для приложения в облаке может использовать своя собственная система проверки подлинности и авторизации, в этом случае подписчикам приложения потребуется создавать учетные данные для всех пользователей приложения. С другой стороны клиенты могут предпочесть использовать существующую у них систему проверки подлинности и избежать необходимости создавать новые учетные данные для приложения. Второй вариант для мультитенантного приложения означает необходимость поддержки нескольких поставщиков проверки подлинности, а так же может потребовать сопоставление схемы авторизации приложения в облаке со схемой локальной инфраструктуры авторизации. В Windows Azure для настройки проверки подлинности и авторизации используется Access Control Services, с помощью которой можно реализовать аутентификацию формами, через Active Directory, через LiveId, Google, Facebook и др. OpenID провайдерами. Если речь идет об интеграции с Active Directory и настройке федерации между AD подписчика и сервисом, то, скорее всего, это так же может потребовать выделенного развертывания.
Управление жизненным циклом приложения
1. Ведение базы кода. Для компаний-разработчиков ведение отдельных баз кода для различных клиентов сопряжено с увеличением расходов на поддержку и обслуживание, а так же с проблемами при отслеживании того, какие клиенты какую версию используют. Это может привести к появлению ошибок, которые приведут к дополнительным затратам. Мультитенатная система с одним логическим развертывание гарантирует одну базу кода для всего приложения. Вы можете по-прежнему поддерживать одну базу кода с выделенной моделью с несколькими развертываниями, но может появиться желание (с долгосрочными последствиями) разветвить код для различных клиентов. В некоторых сценариях, где существует потребность в тонкой настройке приложений, несколько баз кода могут быть приемлемым вариантом, но, прежде чем выбрать этот путь, необходимо изучить возможность применения пользовательских конфигураций или пользовательских бизнес-правил на уровне стандартной настройки системы (например, через интерфейс). Если должно быть несколько баз кода, то приложение должно быть структурировано таким образом, чтобы пользовательский код ограничивался только минимально необходимым числом пользовательских компонентов.
2. Обновления приложения. Мультитенантное приложение позволяет одновременно распространить обновления на всех клиентов. Этот подход означает, что обновляется только один логический экземпляр, что позволяет уменьшить усилия по обслуживанию. Кроме того, у вас есть уверенность, что все клиенты используют последнюю версию приложения, что упрощает поддержку.
Например, домены обновления (Update Domain) Windows Azure упрощают этот процесс, позволяя распространять обновления на несколько экземпляров роли без остановки приложения. Если у клиента есть операционные процедуры или программное обеспечение, привязанные к конкретной версии приложения, то любые обновления должны быть скоординированы с клиентом.
Для сокращения рисков, связанных с обновлением приложения, вы можете реализовать процедуру последовательного обновления: на первой фазе происходит обновления приложения для небольшой группы пользователей, на второй фазе, если с новой версией не возникло никаких сложностей, обновления распространяются на оставшихся пользователей.
3. Мониторинг приложения. Мониторинг одного развертывания приложения проще, чем мониторинг нескольких развертываний. В выделенной модели с несколькими развертываниями для любого нового экземпляра роли необходимо устанавливать настройки среды мониторинга, в результате чего увеличивается сложность всего процесса. Если будет решено использовать последовательное обновление, мониторинг будет также более сложным, поскольку необходимо одновременно отслеживать две версии приложения и использовать данные мониторинга для оценки стабильности версии приложения.
4. Использование сторонних компонентов. Если будет решено использование мультитенантную архитектуру, необходимо оценить насколько хорошо в таком режиме будут работать сторонние компоненты. Что убедиться, что сторонний компонент может работать в мультитенантной архитектуре, возможно, потребуется выполнить некоторые дополнительные действия.
5. Провиженинг тестового доступа и новых клиентов. Провиженинг области для нового клиента или инициализация бесплатного пробного использования службы в значительной степени упрощается, если данный процесс предполагает только изменение конфигурации. Для выделенной модели требуется развернуть новый экземпляр приложения для каждого клиента, включая тех, которые используют бесплатную пробную версию. Хотя этот процесс вы можете автоматизировать, это будет значительно сложнее, чем изменение или создание данных конфигурации в мультитенантном приложении.
Windows Azure позволяет сделать процесс провиженинга автоматическим (провиженинг сервисов, сертификатов, хранилища и т.п.), для этого необходимо использовать REST Service Management API. Программная реализация всех необходимых действий очень актуальна, т.к. позволяет пользователям зайти на портал, нажать кнопку «попробовать» и получить через несколько минут временную подписку (trial), созданную специально для них. Так же это актуально при размещении приложения в Marketplace’ах, когда пользователи могут сначала попробовать приложение, а потом его приобрести и продолжить использование – и никаких звонков или писем службу поддержки.
Настройка приложения
2. Настройка приложения клиентом. Разрешение клиентам загружать собственный код увеличивает риск сбоя приложения, потому что снижается уровень контроля выполняемого приложением кода. Поэтому многие SaaS поставщики накладывают ограничение на использование пользовательского кода в мультитенантных приложениях (т.к. сбой повлияет на всех пользователей). В большинстве случаев это просто запрещено, иногда код разрешен, но его функциональные возможности сильно урезаны. Разрешение клиентам загружать код или скрипты также увеличивает риски, связанные с безопасностью приложения.
Архитектура слоя данных
Windows Azure Tables и BLOB’s позволяют реализовать различные уровни изоляции данных на уровне: отдельных аккаунта, таблиц, партиций и контейнеров. SQL Azure реализует изоляцию за счет отдельных: база данных, федерации базы данных или серверов. Например, мы можем создать мобильное приложение, которое сохраняет данные в BLOB хранилище. В этом случае мы можем создать для каждого пользователя отдельный BLOB контейнер и назначить соответствующие права на этот контейнер (т.е. не публичный доступ).
3. Масштабируемость архитектуры данных. Горизонтальное партиционирование позволяет масштабировать хранилище данных. Для достижения масштабируемости SQL Azure можно перенести данные отдельных клиентов в новый экземпляр SQL Azure.
Ключевым фактором, определяющим масштабируемость табличного хранилища Windows Azure, является выбор ключа партиции. Чтобы избежать просмотра (сканирования) нескольких партиций, все запросы должны включать ключ партиции.
Подробнее о выборе архитектуры данных и компромиссах, связанных с этим, в статьях Multi-Tenant Data Strategies for Windows Azure – Part 1 и Multi-Tenant Data Strategies for Windows Azure – Part 2. В частности, поднимается интересные вопросы SLA, резервирования и восстановления реляционных данных при использовании одной разделяемой базы данных.
Финансовые вопросы
1. Выставление счетов клиентам. Одним из подходов к тарификации является использование плана оплаты по фактическому использованию. При таком подходе необходимо отслеживать ресурсы, затраченные на каждого клиента, рассчитывать стоимость этих ресурсов и добавлять маржу для получения прибыли.
Для выделенного приложения можно создать отдельную учетную запись Windows Azure и определить итоговую сумму для каждого клиента. Однако для выделенного развертывания, выполняющегося в отдельной учетной записи Windows Azure, некоторые затраты будут зафиксированы, т.е. их нельзя будет избежать. Например, оплата за использование вычислительных ресурсов 24×7 и базы SQL Azure может сделать начальную стоимость вашего сервиса слишком высокой для небольших компаний. С мультитенантной архитектурой фиксированные затраты можно разделить между клиентами, но затраты на одного пользователя рассчитать не так просто, и для определения объемов ресурсов, потребляемых каждым клиентов, потребуется в приложение добавить дополнительный код. Более того, клиенты захотят каким-то образом отслеживать свои затраты, поэтому вычисление затрат необходимо сделать максимально прозрачным, а так же реализовать механизм доступа клиентов к этим данным.
Модуль Cloud Ninja Metering Block для Windows Azure: позволяет снимать метрики использования ресурсов для каждого тенанта, имеет встроенный портал отображения отчетов для клиентов.
Трудно заранее точно определить нагрузку и ресурсы, которые потребуются для конкретного подписчика, т.к. заранее сложно спрогнозировать кривую использования ресурсов конкретным подписчиком. Если применить модель тарификации, которая предлагает SaaS приложение за фиксированную месячную плату, то прибыльность будет варьироваться между подписчиками (и даже может быть в некоторых случаях отрицательной). Сделав SaaS приложение мультитенантным, можно сгладить различия в шаблонах использования разных подписчиков, что дает возможность легче прогнозировать расходы и доходы и уменьшить риск убытков. Чем больше клиентов, тем легче на основе статистических данных определить шаблоны использования службы.
С точки зрения клиента начисление фиксированной платы за услугу означает, что клиент заранее точно знает, какие будут расходы в следующем платежном периоде. Это также означает, что система тарификации становится намного проще. Некоторые расходы, такие как расходы, связанные с хранилищем и транзакциями, будут переменными и будут завесить от количества имеющихся клиентов и от того, как они используют службу. Другие расходы, такие как расходы на вычисленные ресурсы будут четко зафиксированы.
В итоге, для того чтобы получить итоговую прибыль, необходимо продать достаточное число подписок, которые покроют фиксированные и переменные затраты.
Если ваша клиентская база включает как крупные, так и небольшие компании, то стандартная абонентская плата может быть слишком высокой для привлечения некрупных клиентов. В этом случае потребуется видоизменение второго подхода и предложение ряда пакетов для разных уровней использования. Например, предложить ограниченный пакет услуг с более низкими ежемесячными ценами, чем стандартный пакет.
От выделенной или мультитенантной архитектуры приложения стоимость на одного клиента не зависит. Независимо от модели для конкретного клиента требуется одинаковый объем хранилища и использование одинакового количества вычислительных циклов. Для управления этими затратами необходимо обеспечить максимально эффективное использование этих ресурсов приложением.