levitra bitcoin

+7(495) 725-8986  г. Москва

Журналы

  • Серия
  • Серия
  • Серия
  • Серия
  • Журнал
  • Журнал
  • Журнал
  • Журнал

М.В. Каманде,  (Аспирант, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В. И. Ульянова (Ленина))

А. Чубахиро,  (Аспирант, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В. И. Ульянова (Ленина))

Серия «Естественные и Технические науки» # 06 2018
Контейнеры
    Рассматриваются вопросы сетевого взаимодействия в рамках контейнеров. Проанализирован случай виртуализации на уровне операционной системы с использованием Linux Containers. Рассмотрены способы организации сетевого взаимодействия для контейнеров в операционной системе Linux. Вопросы сетевого взаимодействия рассматриваются применительно для случая виртуального вычислительного кластера. Рассмотрена работа двух виртуальных интерфейсов для ОС Linux: «veth» и «macvlan».

Ключевые слова: Контейнеры, сетевое взаимодействие, виртуальные сети, вычислительные кластеры, Linux Containers.

 

Общие сведения

Виртуализация на уровне ОС — перспективное направление, востребованное в последние годы. Такой подход к виртуализации вызывает все больший интерес как в академической среде, так в сфере бизнеса. Контейнеры в ОС Linux — одно из лучших решений. Доказательством этому могут служить программные комплексы, созданные на их основе (например, Docker [1], Singulartity [2]). Виртуализация на уровне ОС предлагает достаточную степень изоляции ресурсов при крайне низких накладных расходах. Такое соотношение не может предложить ни один другой тип виртуализации. Контейнеры в ОС Linux предлагают гибкость конфигурирования и производительность для решения различных задач. Контейнеры могут использоваться как для запуска сервисов, так и для организации расчетов. И в том, и в другом случае производительность сети — важный фактор, который может сказаться на общей производительности расчетов, ведь как для предоставления сервиса, так и для расчетов, очень часто используют вычислительные кластеры, в рамках которых производительность сети выходит на первый план, зачастую являясь главным ограничивающим фактором. Таким образом, рассмотрение вопросов, связанных с виртуальными вычислительными сетями для контейнеров, является важной и актуальной задачей. Рассмотрению вопросов производительности и безопасности контейнеров и виртуальных машин посвящен ряд статей, например, [3] и [4].

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

  1. Отдельное пространство имен для процессов - PID («Process Identifier») namespace. Использование данного пространства имен позволяет изолировать иерархию процессов в рамках отдельных контейнеров. Так, процессы одного контейнера будут недоступны для процессов другого контейнера (пользователь, работающий в рамках одного контейнера, даже не сможет увидеть процессы другого контейнера).
  2. Отдельное пространство имен для межпроцессного взаимодействия — IPC («Inter-Process Communication») namespace. Позволяет изолировать ресурсы IPС.
  3. Отдельное пространство имен для пользователей и групп — User namespace. Позволяет изолировать ресурсы, связанные с обеспечением безопасности работы пользователей и групп.
  4. Отдельное пространство имен для иерархии каталогов — Mount namespace. Позволяет разным контейнерам работать с различными иерархиями каталогов.
  5. пространство имен для UTS («UNIX Time-sharing System») — UTS namespace. Позволяет изолировать ресурсы, связанные с именем узла.
  6. Отдельное пространство имен для сетевого взаимодействия (сетевое пространство имен) — Net namespace. Позволяет изолировать ресурсы, связанные с обеспечением работы сети.

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

Отдельное сетевое пространство имен в рамках Linux позволяет обеспечить изоляцию следующих ресурсов: настройки отдельных стеков сетевых протоколов (например, ограничения на использование памяти для очередей, связанных с сокетами), ресурсы, связанные со стеками протоколов (например, таблицы маршрутизации, адреса и номера портов), сетевые интерфейсы. Стоит отметить, что сетевые интерфейсы могут быть как физическими, так и виртуальными — и в том, и в другом случае в рамках Linux сетевой интерфейс будет представлен экземпляром структуры «net_device». И каждое такое представление связано с определенным сетевым пространством имен (созданным или пространством имен по умолчанию). При этом сетевое устройство может принадлежать лишь одному пространству имен. Так, сетевые пространства имен определяют к каким сетевым устройствам будет иметь доступ контейнер.

Способы организации сетевого взаимодействия для контейнеров

Однако выделение физического интерфейса для контейнера в отдельном сетевом пространстве имен кажется нецелесообразным, ведь в таком случае доступ к нему будет иметь лишь один контейнер. Поэтому для контейнеров, как правило, используются виртуальные сетевые интерфейсы. Отдельные сетевые интерфейсы для каждого контейнера позволяют работать контейнерам с отдельными сетевыми адресами (возможно, в разных подсетях). Использование разных сетевых пространств имен для разных контейнеров позволяет задавать настройки для сетевого стека каждого контейнера независимо. В рамках Linux доступен ряд виртуальных сетевых интерфейсов, однако для работы контейнеров, как правило, используют или интерфейсы «veth» («Virtual Ethernet») вместе с интерфейсом «bridge», или интерфейсы «macvlan». Именно рассмотрению этих двух вариантов и будет уделено основное внимание в рамках данной статьи. Отсюда и далее под «контейнером» подразумевается контейнер, работающий в отдельном сетевом пространстве имен, если явно не указано иное.

Интерфейс «veth»

Данный интерфейс подразумевает пару интерфейсов одинакового типа. При отправке кадра через один из двух интерфейсов, кадр появляется на втором интерфейсе — ОС получает кадр примерно также, как если бы он был получен на втором интерфейсе, например, из внешней сети. Интерфейсы равноценны, для их работы используются одни и те же функции. Если интерфейсы принадлежат к разным сетевым пространствам имен, то с помощью пары таких интерфейсов можно организовать передачу кадров между отдельными сетевыми пространствами имен. Такой подход используется как раз в рамках контейнеров Linux с разными сетевыми пространствами имен. Благодаря интерфейсу «veth» можно организовать передачу данных между отдельными контейнерами или между контейнером и хостовой ОС (имеется ввиду сетевое пространство имен по умолчанию, в котором работают процессы, не принадлежащие контейнерам).

Однако отдельная пара интерфейсов «veth» сама по себе, как правило, не используется. Контейнерам, как правило, требуется доступ во внешнюю сеть. Для этого необходимо организовать передачу данных между контейнером и физическим сетевым интерфейсом. Для этой цели, как правило, используется виртуальный мост Linux — интерфейс «bridge». Он выполняет ту же роль, что и обыкновенный физический мост, а именно объединение отдельных сегментов сети. Он точно также работает на втором уровне модели OSI («Open System Interconnection»). Он постепенно собирает информацию об известных узлах с тем, чтобы отправлять кадры лишь по нужному порту. Он поддерживает STP («Spanning Tree Protocol»). Как правило, мост работает в сетевом пространстве имен по умолчанию, в котором, как правило, работают и физические сетевые интерфейсы. Поэтому к мосту можно подключить, как физический интерфейс, так и интерфейс «veth» из пары, работающий в сетевом пространстве имен по умолчанию (речь идет об ассоциации экземпляра структуры «net_device», представляющего физический сетевой интерфейс в системе, с виртуальным сетевым мостом). Если второй интерфейс будет работать в сетевом пространстве имен контейнера, то благодаря такому подключению можно будет наладить передачу данных из контейнера во внешнюю сеть и наоборот. Схематично работа интерфейсов «veth» и «bridge» изображена на рис. 1.

Читать полный текст статьи …


СПИСОК ЛИТЕРАТУРЫ:
1. Официальный сайт проекта Docker [Электронный ресурс] // https://www.docker.com/
2. Официальный сайт проекта Singularity [Электронный ресурс] // http://singularity.lbl.gov/
3. Felter W. et al. An Updated Performance Comparison of Virtual Machines and Linux Containers [Текст] / W. Felter, A. Ferreira, R. Rajamony, J. Rubio // Performance Analysis of Systems and Software (ISPASS), 2015 IEEE International Symposium On. – IEEE, 2015. – p. 171-172.
4. Xavier M. G. et al. Performance Evaluation of Container-Based Virtualization for High Performance Computing Environments [Текст] / M. G. Xavier, M. V. Neves, F. D. Rossi, T. C. Ferreto, T. Lange, C. A. F. De Rose // Parallel, Distributed and Network-Based Processing (PDP), 2013 21st Euromicro International Conference on. – IEEE, 2013. – p. 233-240.
5. Параметры стека TCP/IP в ОС Linux [Электронный ресурс] // https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
6. Hess B. et al. GROMACS 4: Algorithms for Highly Efficient, Load-Balanced, and Scalable Molecular Simulation [Текст] / B. Hess, C. Kutzner, D. van der Spoel, E. Lindahl // Journal of chemical theory and computation 4.3, 2008. – p. 435-447.
7. Официальный сайт проекта OpenFOAM [Электронный ресурс] // https://www.openfoam.com/


©  М.В. Каманде, А. Чубахиро, Журнал "Современная наука: актуальные проблемы теории и практики".
 

 

 

 
SCROLL TO TOP
viagra bitcoin buy

Rambler's Top100 �������@Mail.ru