Ажиотаж вокруг контейнерной визуализации
Содержание:
1.Контейнеры против гипервизоров - все дело в плотности (Вы читаете данный раздел);
2. История контейнеров визуализации ;
3. Контейнеры визуализации на предприятии: почему ажиотаж именно сейчас??;
4. Контейнеры визуализации и NFV;
5. Ближайшее будущее: контейнеры визуализации решают все?.
Контейнеры против гипервизоров - все дело в плотности
Гипервизор работает по достаточно простому принципу (смотрите рисунок 1): происходит эмуляция операционного обеспечения, поверх которого запущены гостевые ОС, и за все это отвечает операционная система. Это означает, что взаимосвязь между гостевой и хостовой операционными системами следует «железной» парадигме: все, что «умеет» делать оборудование, должно быть доступно гостевой ОС со стороны хостовой. Напротив, контейнеры (см. рисунок 2) — это виртуализация на уровне операционной системы, а не оборудования, то есть каждая гостевая ОС использует то же самое ядро (а в некоторых случаях — и другие части ОС), что и хостовая. Это дает контейнерам большое преимущество: они меньше и компактнее гипервизорных гостевых сред, поскольку у них с хостом гораздо больше общего.
Рисунок 1. Схема гипервизорной виртуализации
Другой большой плюс — значительно большая эффективность контейнерной виртуализации в отношении совместного использования ресурсов, так как для нее контейнеры — это всего лишь управляемые ресурсы. К примеру, когда Контейнер 1 и Контейнер 2 работают с одним и тем же файлом, ядро хоста открывает этот файл и размещает страницы из него в страничный кэш ядра, которые затем передаются Контейнеру i и Контейнеру 2: если оба «хотят» прочитать одни и те же данные, они получают одну и ту же страницу. Если же гипервизорным виртуальным машинам VMi и VM2 надо выполнить такую же операцию, то сначала сам хост открывает запрашиваемый файл (создавая страницы в своем страничном кэше), а затем еще и каждое из ядер VMi и VM2 выполняет аналогичное действие. Таким образом, в процессе чтения машинами VMi и VM2 одного и того же файла в памяти существует целых три одинаковых страницы (по одной в страничном кэше хоста и в ядрах VMi и VM2), потому что они не «умеют» одновременно использовать одну и ту же страницу, как это делают контейнеры.
Рисунок 2. Схема контейнерной виртуализации
Дело даже не столько в «чтении» файлов, сколько в возможности использовать одну копию исполняемых файлов и разделяемых библиотек (shared libs) в разных контейнерах. В обычной системе, если два или более процесса обращаются к одной и той же разделяемой библиотеке (например, libc), ее код присутствует в памяти только в одном экземпляре. Это относится и к исполняемым файлам, и к сегментам немодифицируемых данных, что позволяет существенно снизить требования к размеру оперативной памяти. Так как контейнеры используют единое ядро, вышеописанный механизм при некоторых условиях распространяется и на них, что приводит, в частности, к повышению плотности их размещения, которая и без этого механизма изначально выше, чем у виртуальных машин, поскольку отсутствуют множественные копии ядра.
В результате у контейнеров плотность (количество виртуальных сред, которые можно запустить на сервере) может быть до трех раз выше, чем у виртуальных машин, а на одном сервере вполне может размещаться несколько сотен контейнеров. Столь высокая плотность — одна из главных причин популярности контейнеров на рынке хостинга виртуальных выделенных серверов (VPS). Если на одном и том же сервере можно создать в три раза больше VPS, то в расчете на один VPS затраты снижаются на 66%, что для такого низкомаржинального бизнеса, как хостинг, иногда равно разнице между убыточностью и прибыльностью.
Конечно, не все идеально в мире контейнеров. Например, из-за совместного использования ядра на одном сервере нельзя запускать разные гостевые ОС (например, на системе с Linux-контейнерами невозможно запустить FreeBSD или Windows, но разные дистрибутивы Linux - сколько угодно). Поэтому Windows и Linux на одном и том же сервере (что для гипервизоров не проблема) не работают. Однако по крайней мере в случае Linux этот недостаток можно смягчить за счет использования интерфейсов ABI и библиотек: благодаря этому появляется возможность запускать на одном сервере контейнеры с различными дистрибутивами Linux, но одновременно сокращается общая для этих контейнеров часть ресурсов. В максимальной же степени преимущества контейнеров проявляются в однородной среде.
1.
2. История контейнеров визуализации ;
3. Контейнеры визуализации на предприятии: почему ажиотаж именно сейчас??;
4. Контейнеры визуализации и NFV;
5. Ближайшее будущее: контейнеры визуализации решают все?.
Контейнеры против гипервизоров - все дело в плотности
Гипервизор работает по достаточно простому принципу (смотрите рисунок 1): происходит эмуляция операционного обеспечения, поверх которого запущены гостевые ОС, и за все это отвечает операционная система. Это означает, что взаимосвязь между гостевой и хостовой операционными системами следует «железной» парадигме: все, что «умеет» делать оборудование, должно быть доступно гостевой ОС со стороны хостовой. Напротив, контейнеры (см. рисунок 2) — это виртуализация на уровне операционной системы, а не оборудования, то есть каждая гостевая ОС использует то же самое ядро (а в некоторых случаях — и другие части ОС), что и хостовая. Это дает контейнерам большое преимущество: они меньше и компактнее гипервизорных гостевых сред, поскольку у них с хостом гораздо больше общего.
Рисунок 1. Схема гипервизорной виртуализации
Другой большой плюс — значительно большая эффективность контейнерной виртуализации в отношении совместного использования ресурсов, так как для нее контейнеры — это всего лишь управляемые ресурсы. К примеру, когда Контейнер 1 и Контейнер 2 работают с одним и тем же файлом, ядро хоста открывает этот файл и размещает страницы из него в страничный кэш ядра, которые затем передаются Контейнеру i и Контейнеру 2: если оба «хотят» прочитать одни и те же данные, они получают одну и ту же страницу. Если же гипервизорным виртуальным машинам VMi и VM2 надо выполнить такую же операцию, то сначала сам хост открывает запрашиваемый файл (создавая страницы в своем страничном кэше), а затем еще и каждое из ядер VMi и VM2 выполняет аналогичное действие. Таким образом, в процессе чтения машинами VMi и VM2 одного и того же файла в памяти существует целых три одинаковых страницы (по одной в страничном кэше хоста и в ядрах VMi и VM2), потому что они не «умеют» одновременно использовать одну и ту же страницу, как это делают контейнеры.
Рисунок 2. Схема контейнерной виртуализации
Дело даже не столько в «чтении» файлов, сколько в возможности использовать одну копию исполняемых файлов и разделяемых библиотек (shared libs) в разных контейнерах. В обычной системе, если два или более процесса обращаются к одной и той же разделяемой библиотеке (например, libc), ее код присутствует в памяти только в одном экземпляре. Это относится и к исполняемым файлам, и к сегментам немодифицируемых данных, что позволяет существенно снизить требования к размеру оперативной памяти. Так как контейнеры используют единое ядро, вышеописанный механизм при некоторых условиях распространяется и на них, что приводит, в частности, к повышению плотности их размещения, которая и без этого механизма изначально выше, чем у виртуальных машин, поскольку отсутствуют множественные копии ядра.
В результате у контейнеров плотность (количество виртуальных сред, которые можно запустить на сервере) может быть до трех раз выше, чем у виртуальных машин, а на одном сервере вполне может размещаться несколько сотен контейнеров. Столь высокая плотность — одна из главных причин популярности контейнеров на рынке хостинга виртуальных выделенных серверов (VPS). Если на одном и том же сервере можно создать в три раза больше VPS, то в расчете на один VPS затраты снижаются на 66%, что для такого низкомаржинального бизнеса, как хостинг, иногда равно разнице между убыточностью и прибыльностью.
Конечно, не все идеально в мире контейнеров. Например, из-за совместного использования ядра на одном сервере нельзя запускать разные гостевые ОС (например, на системе с Linux-контейнерами невозможно запустить FreeBSD или Windows, но разные дистрибутивы Linux - сколько угодно). Поэтому Windows и Linux на одном и том же сервере (что для гипервизоров не проблема) не работают. Однако по крайней мере в случае Linux этот недостаток можно смягчить за счет использования интерфейсов ABI и библиотек: благодаря этому появляется возможность запускать на одном сервере контейнеры с различными дистрибутивами Linux, но одновременно сокращается общая для этих контейнеров часть ресурсов. В максимальной же степени преимущества контейнеров проявляются в однородной среде.
