Сегодня при загрузке программно-конфигурируемого ЦОДа можно применять как виртуальные машины (ВМ), так и программные контейнеры. Отличие контейнеров состоит в том, что они работают на одном уровне с физическими серверами, используют их ресурсы и благодаря привлечению ресурсов реального оборудования и драйверов, а не виртуализованного, как у ВМ, обеспечивают более высокую производительность, плотность размещения, скорость создания и запуска в работу прикладных экземпляров.
Тем не менее применение как контейнеров, так и ВМ, дает преимущества при учете конкретных требований. Недавно они были систематизированы блоге компании VMware на сайте Talkin’Cloud.
Преимущества контейнерного подхода
При загрузке дата-центра всегда возникает задача обеспечить координированный доступ приложений ко всем элементам базовой вычислительной инфраструктуры. Это касается ресурсов физических серверов, сетевой инфраструктуры, систем хранения, а также базовой операционной системы, используемых прикладных подсистем, библиотек, файлов конфигурации.
Традиционный подход, связанный с исполнением приложений в ВМ, предусматривал виртуализацию аппаратных ресурсов, которые затем поддерживались аппаратно системой по мере поступления запросов. Сложности построения таких систем и обеспечения должной их производительности привели к появлению технологии контейнеров, которые стали популярны в последнее время.
Наиболее часто контейнеры применяются сегодня для обеспечения функционирования баз данных и приложений для больших данных. Их также активно применяют на стадии разработки прикладных систем. Согласно недавнему отчету Cloud Foundry Foundation, применение контейнеров уже названо ключевым признаком поступательного движения компаний в сторону цифровой трансформации их бизнеса.
Выбор контейнерного подхода действительно несет ряд значимых улучшений. Это простота контроля за версионностью продуктов; возможность поддержки определенной программной среды на всех этапах создания прикладных систем (от разработки до выпуска в эксплуатацию); высокая скорость развертывания и свертывания систем, исчисляемая несколькими миллисекундами. Однако самым важным достоинством контейнеров чаще всего называют возможность обеспечения высокой изоляции рабочего объекта от всего, что происходит внутри ЦОДа.
Когда следует отдать предпочтение контейнерам
Прежде всего это относится к задачам, когда большое внимание уделяется высокой доступности для прикладной системы занимаемого ею места в ЦОДе, используемых ею системных ресурсов и надстройки. Модель контейнера априори предполагает, что в этом случае накладные затраты будут ниже, чем в случае выбора модели ВМ. Объясняется это просто: каждая ВМ использует собственную виртуализированную копию ОС и аппаратных ресурсов, тогда как контейнеры привлекают только те ресурсы, которые необходимы им для определенного приложения. В результате на одном сервере можно легко одновременно обслужить до тысячи контейнеров, тогда как количество запускаемых ВМ будет на порядок меньше.
Другой пример предпочтительного выбора модели контейнеров связан с задачами, где большое значение уделяется обеспечению высокой производительности приложений, скорости реакции на внешние события. Например, это характерно для систем, требующих привлечения больших объемов данных и соблюдения необходимых требований по скорости обработки запросов. На загрузку ВМ может уйти до нескольких минут. Контейнер приводится в рабочее состояние за считанные миллисекунды.
Третий пример — многократный запуск одной программной системы. Контейнер сумеет начать свою работу значительно быстрей, а его работа будет протекать более эффективно, чем при выборе ВМ.
Когда следует отдать предпочтение ВМ
Выбор в пользу ВМ предпочтителен в задачах, связанных с одновременным использованием нескольких прикладных систем на нескольких серверах или поддержкой разных ОС для различных приложений. В этом случае преимущества контейнерной виртуализации оказываются размытыми: эта модель оптимизирована под выполнение отдельных заданий, а не группы задач с разными требованиями под каждую из них.
Другой пример связан с задачами, где по главу угла ставится соблюдение требований по безопасности. В этом контейнеры явно отстают, по крайней мере на текущий момент — их функционирование пока не остается не столь прозрачным, как у ВМ. В случае компрометации контейнерных систем опасность может оставаться незамеченной в течение длительного времени. Причина состоит в том, что контейнеры использую общие системные ресурсы и прикладные библиотеки, тогда как ВМ виртуализирует системные ресурсы, обеспечивая определенную изоляцию среды от аппаратной части ЦОДа.
Тем не менее проблемы с обеспечением безопасности контейнеров не столь критичны. Уже сейчас существуют способы, позволяющие повысить их защищенность. Например, разработчики могут заложить в конфигурацию системы возможность подключения только к определенным закрытым сегментам интрасети. Они могут также указать, какие файлы применять в режиме read-only. Есть и другие способы блокировки от проникновения вредоносного или компрометирующего кода.
