Почему корпоративные заказчики используют виртуальные машины, а не контейнеры

Виртуальные машины или контейнеры

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

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

Виды виртуализации

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

Более того: и контейнеры, и виртуальные машины избавляют от привязки к конкретному физическому оборудованию, что позволяет более эффективно использовать вычислительные ресурсы с точки зрения потребления энергии и экономической эффективности.

Основное различие между контейнерами и виртуальными машинами – в их архитектурном подходе.

Виртуальные машины

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

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

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

VM

Контейнеры

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

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

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

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

контейнеры

Виртуальные ЦОД

Виртуальный ЦОД – это услуга. Облачные ЦОД предоставляют решение, которое позволит использовать легко настраиваемый комплекс ИТ-инфраструктуры (серверы, хранилища данных, программное обеспечение) с доступом к ним через интернет или по выделенным каналам связи. Заказчик может сам изменять объем предоставленных ресурсов и осуществлять их настройку.

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

Типовые задачи корпоративных заказчиков при аренде виртуальной инфраструктуры

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

Компании, имеющие критические информационные системы, при переносе своей инфраструктуры в виртуальную среду, решают следующие задачи:

  • вынос всей или части серверной инфраструктуры в облако;
  • размещение в облаке всей критичной информационной системы или отдельных сервисов;
  • развертывание в облаке сервисов для взаимодействия с клиентами и партнерами;
  • создание резервной площадки.

Приоритетные требования таких клиентов:

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

Чтобы удовлетворить потребности клиентов, поставщики облачных услуг должны обеспечить:

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

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

Станут ли контейнеры чудодейственным средством

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

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

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

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

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

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

На сегодняшний день самой распространенной платформой контейнеризации является Docker. По данным статистики, собранной  сервисом мониторинга Datalog, чаще всего в Docker запускают следующие сервисы: nginx, Redis, Elasticsearch, Registry, PostgreSQL, MySQL, etcd, Fluentd, MongoDB, RabbitMQ.

При всех достоинствах у этой технологии есть и недостатки.

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

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

Третья проблема – это проблема обеспечения качества. Управлять большим количеством контейнеров,  выполняющих разные задачи, сложнее, чем одной виртуальной машиной.

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

Наконец, если корпоративный заказчик имеет дело с информацией ограниченного доступа, то есть деятельность организации регулируется законами РФ, обработка такой информации возможна только в специализированной IaaS, такой как «Облако ФЗ-152».

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

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

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


1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...