Разница между Single Tenant и Multi Tenant в AWS

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

Что такое Одиночная Арендаторство?

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

Примеры использования одиночной арендаторства

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

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

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

Пример одноарендного размещения в AWS

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

Преимущества одноарендного размещения

Преимущества подхода с одним арендатором:

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

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

Что такое многопользовательскость?

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

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

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

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

Примеры использования многопользовательской архитектуры

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

  • Многопользовательский подход часто используется организациями, предоставляющими решения программного обеспечения как услугу (SaaS), где несколько клиентов используют одно и то же приложение и базовую инфраструктуру.
  • Многопользовательский подход также используется в облачных вычислительных средах, где несколько клиентов могут использовать один и тот же пул вычислительных ресурсов.
  • Многопользовательский подход используется, когда организация хочет максимизировать использование ресурсов и снизить затраты, разделяя ресурсы между несколькими клиентами.
  • Этот подход особенно полезен в ситуациях, где использование ресурсов каждым клиентом относительно мало или переменно, например, в решениях SaaS, где у клиентов могут быть различные паттерны использования и требования к ресурсам.
  • A multi-tenant architecture is used when organizations can achieve economies of scale and reduce operational costs associated with managing and maintaining separate infrastructure for each customer.

Примеры многопользовательского подхода

Многопользовательский подход иногда используется в крупных предприятиях, где разные отделы выступают в качестве арендаторов. Однако наиболее интересным случаем использования многопользовательского подхода является случай поставщиков управляемых услуг (MSP) в облачных средах, таких как AWS. Есть несколько причин, по которым клиенты могут хотеть удовлетворить свои потребности в области ИТ через облачного поставщика услуг MSP таким образом.

В некоторых случаях у меньших компаний нет штатного специалиста по ИТ. Они могли бы столкнуться с трудностями при технической настройке, конфигурации и обслуживании ИТ-инфраструктуры, которая им нужна. Некоторые клиенты просто хотят избежать технических (а также финансовых) проблем, связанных с развертыванием физических серверов и настройкой программного обеспечения в собственной среде.

Кроме того, в облаке арендаторы платят только за то, что используют. Например, по завершении крупного проекта для компании ресурсы виртуальных машин (ВМ), которые использовались для этого проекта, освобождаются, и эти ВМ становятся ненужными. Если клиент использует управляемые услуги, он может просто удалить эти ВМ (или экземпляры Amazon EC2) и избежать оплаты неиспользуемых ресурсов. При использовании физического сервера (даже с запущенными виртуальными машинами) это не является вариантом, и некоторые ресурсы сервера останутся без дела, что приведет к потере денег. Это одна из наиболее распространенных причин, по которой клиент может решить начать использовать облачные услуги, предоставляемые MSP.

Самые популярные из этих услуг известны как инфраструктура как сервис (IaaS), платформа как сервис (PaaS) и программное обеспечение как сервис (SaaS). В этом блоге рассматриваются следующие элементы SaaS: резервное копирование как сервис (BaaS), репликация как сервис (RaaS) и восстановление после катастрофы как сервис (DRaaS).

MSP заинтересованы в оптимизации использования аппаратных ресурсов, финансовых ресурсов и человеческих ресурсов. Поэтому многопользовательский подход идеален для них. MSP могут настроить один экземпляр программного обеспечения с поддержкой многопользовательской поддержки на сервере в облаке AWS и использовать его для предоставления услуг нескольким клиентам с отдельными учетными записями. Нет необходимости устанавливать отдельные экземпляры программного обеспечения для каждого пользователя.

Преимущества многопользовательской архитектуры для MSP

Список преимуществ для MSP, использующих многопользовательскую архитектуру, включает:

  • Более простое обслуживание и обновления. С подходом многопользовательского доступа, у поставщиков услуг управляемых служб MSP появляется меньше программных экземпляров для обновления и поддержки. После обновления программного продукта он становится доступным для всех арендаторов (клиентов). Если бы они управляли SaaS с продуктом для одного арендатора, техническим специалистам пришлось бы обновлять или улучшать экземпляр каждого клиента индивидуально.
  • Эффективное использование ресурсов. Поддержка программного обеспечения с многопользовательским доступом означает, что требуется меньше технических специалистов и меньше аппаратных ресурсов для серверов. Это происходит потому, что нужно поддерживать меньше экземпляров программного обеспечения, и все арендаторы используют одни и те же ресурсы и инфраструктуру.
  • Эффективность в затратах и экономия времени. Благодаря только что описанным функциям, программное обеспечение, поддерживающее многопользовательский доступ, может сэкономить вам время и деньги. В долгосрочной перспективе использование архитектуры многопользовательского доступа снижает инвестиции, что является одним из ключевых преимуществ данного подхода. Это происходит потому, что ресурсы приложения распределяются между арендаторами, использующими одни и те же приложения, что уменьшает затраты, связанные с обслуживанием и поддержкой. Когда поставщик услуг MSP использует продукт для многих арендаторов, что позволяет ему экономить средства, он может передавать эти сбережения, предлагая более доступные цены для клиентов. Таким образом, поставщик услуг MSP может привлекать больше клиентов для покупки предоставляемых услуг.
  • Высокая масштабируемость. Добавление новых пользователей становится намного проще и удобнее, без необходимости добавления новых серверов, виртуальных машин или экземпляров приложений. Несколько арендаторов поддерживаются одним и тем же экземпляром, запущенным на сервере. Масштабируемость многопользовательского программного обеспечения означает, что поставщик может увеличивать свои предложения по мере улучшения бизнеса.
  • Улучшение обслуживания клиентов. С многопользовательской архитектурой MSP может отслеживать использование системы. С помощью звукового анализа они могут использовать собранную информацию для оценки и улучшения предоставляемых услуг. MSP может обновить или переорганизовать свою инфраструктуру, а также изменить свои подписки на программное обеспечение в соответствии с их анализом.

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

Многопользовательское решение устраняет необходимость в собственной дорогостоящей инфраструктуре у клиентов, что потребовало бы инвестиций в обслуживание и поддержку. Серверы могут работать как виртуальные машины в облаке, например, с использованием Amazon AWS. Клиенты могут выполнять резервное копирование в облаке Amazon без покупки дорогостоящего физического оборудования или ленточных библиотек. Они могут сосредоточиться на своем основном бизнесе, не беспокоясь о своей ИТ-инфраструктуре.

Клиентам не нужно обновлять или модернизировать программное обеспечение, используемое в качестве предоставляемой услуги. Фактически, пользователи многопользовательского решения по резервному копированию и репликации NAKIVO вообще не должны устанавливать программное обеспечение; это делает MSP. Программное обеспечение регулярно обновляется MSP, в то время как клиенты могут настраивать свои среды в соответствии со своими потребностями.

Использование многопользовательских услуг безопасно. Арендаторы не могут получить доступ к виртуальным средам друг друга.

Однопользовательское vs многопользовательское

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

Критерии Одиночный арендатор Многоквартирный
Настройка Высокая

Каждый экземпляр приложения выделен для одного клиента.

Ограниченная

Все клиенты используют один экземпляр приложения.

Безопасность Высокая

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

Ниже

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

Стоимость Выше

Каждый клиент требует собственной выделенной инфраструктуры и ресурсов.

Эффективные затраты

Ресурсы используются несколькими клиентами, что позволяет более эффективно использовать ресурсы.

Масштабируемость Ограничена

Каждый клиент требует собственных ресурсов.

Высокая

Ресурсы могут использоваться несколькими клиентами, что позволяет более эффективно использовать ресурсы.

Обслуживание Сложное

Выделенные ресурсы и экспертиза для управления и поддержки каждого экземпляра приложения.

Простое

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

Сложность Высокая Низкая
Время развертывания Долгое

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

Короче

Все клиенты используют один экземпляр приложения.

Управление ресурсами Высокий

Каждый экземпляр приложения имеет выделенные ресурсы.

Ниже

Ресурсы используются несколькими клиентами, что может привести к проблемам производительности или конфликту ресурсов.

Использование ресурсов Низкое

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

Высокое

Используются общие ресурсы, и возможно эффективное перераспределение свободных ресурсов, если экземпляр арендатора не используется.

Изоляция ресурсов Полная изоляция Общие ресурсы
Сотрудничество Ограниченное

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

Гибкое

Все клиенты используют один экземпляр приложения и инфраструктуры.

Соответствие регулированиям Проще

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

Более сложно

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

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

BaaS, RaaS и DRaaS.

Давайте рассмотрим, как многопользовательский режим может использоваться в терминах резервного копирования как сервиса (BaaS), репликации как сервиса (RaaS) и восстановления после катастрофы как сервиса (DRaaS).

С растущей популярностью облачных технологий и виртуализации защита данных для виртуализированных сред стала критически важной. Резервное копирование бизнес-критических данных является обязательным для компаний, независимо от того, хранят ли они данные локально или в общедоступных или частных облаках. Согласно правилу резервного копирования 3-2-1, bewстальные практики рекомендуют иметь 3 копии данных, 2 из которых хранятся на разных устройствах, по крайней мере 1 хранится за пределами места их использования.

Вы можете выполнять резервное копирование виртуальных машин, работающих в облаке, на физическое устройство, находящееся в офисе вашей компании. Если у вашей компании нет собственной инфраструктуры, вы можете выполнять резервное копирование из вашей облачной среды на удаленный сайт или хранить резервные копии в другом облаке, например, в другом географическом регионе облака Amazon. Аналогично виртуальные машины, работающие на физических серверах на месте, могут быть резервно скопированы в облако (обычно с помощью MSP). Резервное копирование как услуга (BaaS) является подходящим решением для компаний, нуждающихся в резервном копировании виртуальных машин как из облака, так и в облако.

MSP стремятся удовлетворить потребности клиентов, которые требуют высокой надежности и высокой доступности; обычно они предоставляют не только BaaS. Репликация как услуга (RaaS) и аварийное восстановление как услуга (DRaaS) обычно предлагаются наряду с BaaS. Это расширенное решение пользуется большим спросом для резервного копирования, репликации и восстановления локальных виртуальных машин, а также виртуальных машин в облаке, как на местных, так и на облачных площадках. Чтобы предоставить лучший сервис своим клиентам, MSP регулярно обновляют свою инфраструктуру и разворачивают надежное многопользовательское программное обеспечение с удобными интерфейсами.

Для стимуляции роста cloud-бизнеса, MSPs нужны легко масштабируемая решения, которая может уменьшить затраты, связанные с установкой и администрированием. такие решения должны быть безопасными, обеспечивать высокую производительность и оптимизированное использование ресурсов. идеально, резервное копирование, репликация и восстановление после катастроф могут быть управляемы с помощью одного интерфейса. предпочтительно, когда работая с виртуальными средами, выбранное программное обеспечение должно быть бесagенным.

Выбор решения для защиты данных многопользовательских проектов: NAKIVO Backup & Replication

NAKIVO Backup & Replication – универсальное решение для защиты данных, разработанное с опытом как MSPs, так и их клиентов. решение может использоваться в режиме многопользовательских проектов, для обеспечения BaaS, RaaS, DRaaS и поддержки виртуальных (VMware vSphere, Microsoft Hyper-V, Nutanix AHV VMs, а также экземпляры Amazon EC2).

Решение NAKIVO может быть установлено в одиночных и многопользовательских проектах. Преимущества использования решения NAKIVO в режиме многопользовательских проектов для MSPs включают:

  • Готово для Amazon AWS. NAKIVO Backup & Replication может быть быстро и легко установлен в облаке Amazon AWS (как предоconfigured AMI).
  • Другие гибкие варианты установки, включая Windows, Linux, NAS, как VA.
  • Консоль MSP. MSP могут управлять всеми своими клиентами из централизованного веб-интерфейса. Они могут добавлять клиентские инфраструктуры, чтобы предоставлять полные услуги по защите данных. MSP также могут добавлять клиентов с собственными развертываниями в NAKIVO Backup & Replication (в режиме для одного арендатора), чтобы предоставлять услуги администрирования и поддержки.
  • Портал самообслуживания для клиентов. Для клиентов MSP, у которых нет собственного экземпляра NAKIVO Backup & Replication, администратор MSP может использовать ролевые контроли доступа в решении, чтобы передать часть задач по резервному копированию и восстановлению клиентам. Каждый клиент (арендатор) может управлять своими собственными задачами по резервному копированию, репликации и восстановлению, получая доступ к своим изолированным панелям управления. Задания и инвентарь одного арендатора не видны другим арендаторам.
  • Индивидуальный брендинг. MSP может настраивать брендинг интерфейса NAKIVO Backup & Replication для обеспечения комфортного опыта для своих клиентов. Поставщики услуг могут стандартизировать внешний вид продукта, чтобы он соответствовал другим используемым ими продуктам и был брендированным, обеспечивая согласованный корпоративный стиль всех предоставляемых ими услуг.
  • Лицензирование. NAKIVO Backup & Replication для MSP лицензируется на основе рабочей нагрузки ежемесячно или ежегодно. MSP могут оплачивать необходимые им рабочие нагрузки каждый месяц или заключить годовую лицензию для больших сбережений.В режиме для нескольких арендаторов NAKIVO Backup & Replication является мощным решением для MSP, желающих предоставлять услуги BaaS, RaaS и DRaaS. Продукт можно использовать даже без локальной инфраструктуры, в облаках, таких как Amazon AWS, что является отличным способом удовлетворить потребности как MSP, так и конечных пользователей.

В режиме Multi-Tenant, NAKIVO Backup & Replication является мощным решением для MSP, желающих предлагать BaaS, RaaS и DRaaS. Продукт можно использовать даже без какой-либо инфраструктуры на месте, в облаках, таких как Amazon AWS, что является отличным способом удовлетворить потребности MSP и конечных пользователей.

Source:
https://www.nakivo.com/blog/single-tenant-vs-multi-tenant/