Контейнеры визуализации и NFV
Содержание:
1. Контейнеры против гипервизоров - все дело в плотности;
2. История контейнеров визуализации ;
3. Контейнеры визуализации на предприятии: почему ажиотаж именно сейчас??;
4. Контейнеры визуализации и NFV (Вы читаете данный раздел);
5. Ближайшее будущее: контейнеры визуализации решают все?.
В качестве примера нестандартного подхода к решению задач виртуализации с помощью контейнеров рассмотрим виртуализацию сетевых функций (Network Function Virtualization), весьма востребованную технологию на рынке телекоммуникаций. Традиционно при NFV с использованием гипервизора сетевая функция выполняется в гостевом ядре и пропускает через себя весь сетевой трафик, для чего применяются средства виртуального драйвера. Последний, в свою очередь, извлекает этот трафик непосредственно из физического канала передачи информации (что соответствует первому уровню сетевой модели OSI). Благодаря такому подходу гостевая система может обрабатывать сетевой трафик с эффективностью физического устройства, находясь при этом в виртуальной среде под программным контролем.
Упомянутую сетевую функцию можно реализовать в гостевой системе через один или несколько стандартных сетевых интерфейсов. А вместо внедрения драйвера можно попробовать подсоединить контейнер к такой проксирующей функции с помощью средств сетевого интерфейса. Применяемая в контейнерах технология под названием «сетевое пространство имен» (network namespace) позволяет превратить сетевой интерфейс из совместно используемого в выделяемый одному контейнеру. Поэтому, если есть возможность внедрить специальный драйвер в общее ядро операционной системы, сетевой интерфейс, с которым связан этот драйвер, можно по-прежнему (как при использовании гипервизора) передать в отдельный контейнер посредством пространства имен.
С помощью такого специального драйвера контейнер получает способность обрабатывать сетевой трафик в виртуальной среде, при этом достигаются большая плотность виртуальных объектов и высокая эффективность, ведь контейнерная инфраструктура занимает меньший объем (по сравнению с виртуальными машинами). Эту концепцию можно развить: поскольку приложение в контейнере может пользоваться сервисами физической операционной системы, каждое из запущенных в ней приложений можно вынести в отдельный контейнер с собственной прокси-функцией и отдельное приложение будет запускаться в своем собственном сетевом окружении. В этом подходе, называемом контейнеризацией приложения, в контейнере размещается только приложение, без операционной системы. В результате плотность размещения приложений будет почти в 10 раз больше, чем при традиционной виртуализации.
1. Контейнеры против гипервизоров - все дело в плотности;
2. История контейнеров визуализации ;
3. Контейнеры визуализации на предприятии: почему ажиотаж именно сейчас??;
4.
5. Ближайшее будущее: контейнеры визуализации решают все?.
В качестве примера нестандартного подхода к решению задач виртуализации с помощью контейнеров рассмотрим виртуализацию сетевых функций (Network Function Virtualization), весьма востребованную технологию на рынке телекоммуникаций. Традиционно при NFV с использованием гипервизора сетевая функция выполняется в гостевом ядре и пропускает через себя весь сетевой трафик, для чего применяются средства виртуального драйвера. Последний, в свою очередь, извлекает этот трафик непосредственно из физического канала передачи информации (что соответствует первому уровню сетевой модели OSI). Благодаря такому подходу гостевая система может обрабатывать сетевой трафик с эффективностью физического устройства, находясь при этом в виртуальной среде под программным контролем.
Упомянутую сетевую функцию можно реализовать в гостевой системе через один или несколько стандартных сетевых интерфейсов. А вместо внедрения драйвера можно попробовать подсоединить контейнер к такой проксирующей функции с помощью средств сетевого интерфейса. Применяемая в контейнерах технология под названием «сетевое пространство имен» (network namespace) позволяет превратить сетевой интерфейс из совместно используемого в выделяемый одному контейнеру. Поэтому, если есть возможность внедрить специальный драйвер в общее ядро операционной системы, сетевой интерфейс, с которым связан этот драйвер, можно по-прежнему (как при использовании гипервизора) передать в отдельный контейнер посредством пространства имен.
С помощью такого специального драйвера контейнер получает способность обрабатывать сетевой трафик в виртуальной среде, при этом достигаются большая плотность виртуальных объектов и высокая эффективность, ведь контейнерная инфраструктура занимает меньший объем (по сравнению с виртуальными машинами). Эту концепцию можно развить: поскольку приложение в контейнере может пользоваться сервисами физической операционной системы, каждое из запущенных в ней приложений можно вынести в отдельный контейнер с собственной прокси-функцией и отдельное приложение будет запускаться в своем собственном сетевом окружении. В этом подходе, называемом контейнеризацией приложения, в контейнере размещается только приложение, без операционной системы. В результате плотность размещения приложений будет почти в 10 раз больше, чем при традиционной виртуализации.
