Виртуализация SR-IOV и контейнеры Linux*

CERNopenlab

 

Центр компетенции «Платформы»


Содержание

  1. Введение 
  2. Оборудование и программное обеспечение
  3. Настройка SR-IOV в ОС
  4. Тесты
  5. Выводы
  6. Библиография

Приложение A. Управление использованием ресурсов внутри контейнеров

Приложение Б. Дополнительные ресурсы

Краткий обзор

Виртуализация — это технология, предоставляющая абстрактный уровень между программным обеспечением и оборудованием. Эта технология может имитировать аппаратную платформу, чтобы предоставить операционной системе абстракции различных ресурсов. Виртуализация также позволяет удобно управлять аппаратными ресурсами и запускать службы в облаке. Один из основных недостатков традиционной виртуализации на основе гипервизоров заключается в значительных издержках по отношению к использованию памяти и ЦП1. Контейнеры Linux* (LXC) — это облегченная альтернатива традиционному подходу. Контейнеры обеспечивают разделение пространств имен и файловых систем, но все процессы выполняются в одном и том же ядре. В сочетании с виртуализацией SR-IOV (виртуализация ввода-вывода с единым рутовым элементом) можно получить решение, в котором контейнеры будут отображаться в сети как отдельные вычислительные узлы с разными MAC-адресами2, используя при этом одно подключение и один физический сетевой адаптер.

Эта статья создана в результате совместных исследований CERN openlab и Intel. Целью исследования было изучение возможностей использования контейнеров Linux вместе с SR-IOV в дополнение к существующей инфраструктуре виртуализации в центре обработки данных CERN. Это решение можно применять на узлах хранилища, характерными особенностями которых является высокая интенсивность операций ввода-вывода, но крайне низкая нагрузка на ЦП. Таким образом, CERN получит преимущества за счет LXC/SR-IOV, запуская задания с высокой нагрузкой на ЦП и задания хранения данных в контейнерах на узлах хранилища с полным разделением этих приложений и с полным контролем потребления ресурсов.

Мы описываем успешную настройку контейнеров Linux с 10-гигабитными адаптерами Ethernet Intel® с поддержкой SR-IOV, приводим результаты синтетических тестов сети и хранилища.

Авторы: Павел Шостек (CERN openlab) и Марко Ригини (Intel)

1 Центральный процессор.

2 Управление доступом к среде передачи данных.

 

Аннотация

В этом документе рассматривается возможность настройки SR-IOV с LXC в среде CERN с использованием последней версии операционной системы, используемой в CERN (CentOS* 7). Мы описываем все действия, необходимые для настройки. Также мы представляем результаты тестов сети и хранилища, запущенных в этой конфигурации. Результаты свидетельствуют о том, что такое сочетание технологий вполне работоспособно. Тем не менее обнаружено некоторое снижение производительности при интенсивных операциях ввода-вывода. В дальнейшем предполагается проведение тестов производительности и надежности для этого набора технологий.

1. Введение

Что такое контейнеры Linux?

Контейнеры Linux* (LXC) — это функция ядра Linux, позволяющая разделять процессы, выполняемые в одном ядре, внутри собственных пространств имен и файловых систем. Как показано в различных исследованиях (Ксавьер и др., 2013 г.; Кьялман и др., 2015 г.), издержки производительности в этом случае ниже, чем при использовании гипервизора, но при этом несколько снижается гибкость и управляемость. LXC можно использовать вместе с Cgroups, чтобы получить возможность управления аппаратными ресурсами внутри контейнеров. В результате достигается еще лучшее разделение приложений, работающих в разных контейнерах.

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

Что такое SR-IOV?

SR-IOV (виртуализация ввода-вывода3 с единым рутовым элементом) — это технология виртуализации ввода-вывода, разработанная группой PCI Special Interest Group (PCI-SIG). Эта технология предоставляет стандартный механизм, при помощи которого устройства сообщают о своей способности совместно использоваться несколькими виртуальными машинами. Также поддерживается разделение функции PCI на несколько виртуальных интерфейсов, чтобы можно было обеспечить общий доступ к ресурсам устройства PCI Express* (PCIe*) в виртуальной среде.

В зависимости от физического устройства и поддержки на стороне ядра в системе можно сделать доступным разное количество виртуальных функций (ВФ). Для этой статьи мы использовали платы Intel X520, предоставляющие до 64 виртуальных функций на каждый порт. Каждую из них можно делегировать контейнеру. Этот контейнер будет владеть делегированной ему функцией в течение своего срока существования. В результате устройство будет видно в сети как независимый узел с совершенно изолированным трафиком.

Крупным планом

Центр обработки данных CERN находится в сердцевине вычислительной сети большого адронного коллайдера (БАК). Именно здесь собираются, хранятся и обрабатываются данные экспериментов БАК. В центре обработки данных используется почти 110 тысяч процессорных ядер и 11 тысяч серверов. Они работают круглосуточно, чтобы обеспечить бесперебойное обслуживание. Все узлы, размещенные в центре обработки данных CERN, можно разделить на несколько категорий в зависимости от их назначения. В этой статье мы рассматриваем узлы переднего плана. Их цель — сбор данных, поступающих из экспериментов, и подача этих данных по требованию в вычислительные узлы. Для таких узлов характерна низкая нагрузка на ЦП и интенсивное использование ресурсов постоянного хранения данных. Цель анализа, описанного в этой статье Openlab, заключается в рассмотрении возможности использовать контейнеры Linux для предоставления дополнительных вычислительных ресурсов из серверов хранения данных без ущерба для надежности хранения. Схема конфигурации показана на рис. 1.

Example Of a Storage Node Configuration

Рисунок 1. Пример конфигурации узла хранилища

EOS — это дисковая система хранения данных, используемая в CERN для больших объемов физических данных. Для таких систем характерна высокая интенсивность операций ввода-вывода и умеренная потребность в вычислительных ресурсах. Boinc — это распределенное приложение для обработки данных, оно интенсивно использует ЦП, а его нагрузка на подсистему ввода-вывода пренебрежимо мала. В целевой конфигурации EOS и Boinc должна работать на одном и том же узле хранилища. Такой подход даст возможность эффективнее загружать центральные процессоры, которые сейчас используются недостаточно, обеспечив при этом разделение приложений и предоставление им необходимых аппаратных ресурсов.  Для этого SR-IOV позволяет создавать множество виртуальных сетевых интерфейсов, которые можно независимо один от другого использовать в контейнерах. При этом Cgroups обеспечивает разделение ресурсов.

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

3 Ввод-вывод (операции).

2. Оборудование и программное обеспечение

Протестированный узел оборудован массивом JBOD из 24 жестких дисков Hitachi HUA72302 A800 и 10-гигабитным адаптером Ethernet Intel® 82599ES с поддержкой SR-IOV. Кроме того, на системной плате установлен один порт Ethernet 1 Гбит/с для передачи данных и еще один — для управления.

На компьютере загружается предварительная версия CentOS* 7 с ядром 3.10.0-123.13.2.el7.x86_64 и надстройками CERN. Везде устанавливается стандартный набор пакетов, если явным образом не оговорено иное.

Настройка BIOS

Для правильной работы SR-IOV требуется настроить BIOS следующим образом: VT — включено, SR-IOV — включено, VT-D — отключено.

3. Настройка SR-IOV в ОС

В этом разделе мы подробно описываем действия, необходимые для настройки SR-IOV в тестовой системе. В дальнейшей части этой статьи главная система (хост) будет называться p01001534852033, а контейнеры — centos1 и centos2.

Сначала нужно убедиться в том, что адаптеры Ethernet видны в системе. Поскольку это устройства PCIe, мы используем команду lspci.

[root@p01001534852033 tmp]# lspci | grep 10-Gig 04:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 04:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Драйверы ядра, используемые для платы, общедоступны на веб-сайте Intel. После загрузки драйверов мы распаковываем их, собираем и устанавливаем модули ядра ixgbe и ixgbevf kernel.

tar xvzf ixgbe-*.tar.gz
cd ixgbe-*/src
make install
cd ../..
tar xvzf ixgbevf-*.tar.gz
cd ixgbevf-*/src
make install

Затем мы настраиваем систему для автоматической загрузки модулей ядра при загрузке компьютера.

echo "ixgbevf\nixgbe" >> /etc/modules-load.d/modules.conf

Кроме того, для драйвера ixgbe требуется подключить страницы виртуальной памяти крупного размера (крупные страницы памяти).

mkdir -p /mnt/huge chmod 777 /mnt/huge echo "huge /mnt/huge" hugetlbfs defaults 0 0 echo "vm.nr_hugepagesz=2M" >> /etc/sysctl.conf

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

intel_iommu=off default_hugepagesz=2M hugepagesz=2M ixgbe.max_vfs=8,8.

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

Для этого мы добавляем соответствующую запись в grub.cfg. Поскольку в CentOS7 используется grub2, это следует сделать опосредованно, добавив запись в /etc/grub.d/40_custom. Приведенная ниже запись является клоном другой записи с добавленными дополнительными параметрами. Дополнительные сведения см. в /boot/grub2/grub.cfg.

cat << EOF > /etc/grub.d/40_custom
menuentry 'CentOS Linux (3.10.0-123.9.3.el7.x86_64) 7 Intel setup' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-123.el7.x86_64-advanced-3d81a16b-9af7-4ba0-ae53-ef16fb54f864' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  0b7ebc67-f22d-4760-abd9-7503761e827f
        else
          search --no-floppy --fs-uuid --set=root 0b7ebc67-f22d-4760-abd9-7503761e827f
        fi
        linux16 /vmlinuz-3.10.0-123.8.1.el7.x86_64 root=/dev/mapper/cc_p01001534852033-root ro rd.lvm.lv=cc_p01001534852033/swap crashkernel=auto  vconsole.font=latarcyrheb-sun16 rd.lvm.lv=cc_p01001534852033/root vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 intel_iommu=off default_hugepagesz=2M hugepagesz=2M ixgbe.max_vfs=8,8
        initrd16 /initramfs-3.10.0-123.8.3.el7.x86_64.img
}
EOF

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

grub2-mkconfig --output=/boot/grub2/grub.cfg

Наконец, мы перезагружаем систему, чтобы проверить правильность конфигурации, связанной с SR-IOV, и что она воспроизводится при каждой загрузке.

После перезагрузки системы с новыми параметрами мы проверяем, видны ли виртуальные функции в системе. Если их список не выводится командой lspci, это может означать, что драйверы не загружены либо неправильно загружены (в этом случае используйте lsmod и dmesg).

[root@p01001534852033 tmp]# lspci | grep -i virt
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
04:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
04:11.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)

Еще раз проверяем, что подключены крупные страницы памяти.

[root@p01001534852033 tmp]# mount | grep huge
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
huge on /mnt/huge type hugetlbfs (rw,relatime)

Кроме того, команда ifconfig должна выводить список всех виртуальных интерфейсов.

[root@p01001534852033 ~]# ifconfig | grep enp4s | cut -c 1-53
enp4s16: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> 
enp4s17: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> 
enp4s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
enp4s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 150
enp4s16f2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
enp4s16f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
enp4s16f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
enp4s17f2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
enp4s17f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
enp4s17f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>

Если это не так, попробуйте перезагрузить ixgbe и ixgbevf. Если же для подключения к системе используется SSH, то подключение будет нарушено. Во избежание этого запустите

nohup 'rmmod ixgbe && rmmod ixgbevf && insmod ixgbe && insmod ixgbevf'.

Обратите внимание, что ixgbevf необходимо загружать после ixgbe. В противном случае система не будет сообщать о наличии виртуальных функций.

При работе над решением мы обнаружили ошибку в шаблоне CentOS7 LXC. Из-за этой ошибки загрузка контейнера происходит крайне медленно4. Для устранения ошибки можно применить исправление к файлу шаблона5.

Располагая описанной выше конфигурацией, мы создаем с нуля новый контейнер CentOS.

lxc-create -t centos -n centos1

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

[root@p01001534852033 tmp]# cat /var/lib/lxc/centos1/config
lxc.autodev = 1
lxc.network.type = phys # was veth
lxc.network.flags = up
lxc.network.link = enp4s16f1  # was virbr0
lxc.rootfs = /var/lib/lxc/centos1/rootfs
lxc.include = /usr/share/lxc/config/centos.common.conf
lxc.arch = x86_64
lxc.utsname = centos1.cern.ch
lxc.autodev = 1

При каждой загрузке модуля ядра ixgbevf виртуальным функциям назначаются новые MAC-адреса. Чтобы предотвратить нежелательные последствия (например, ошибочную маршрутизацию пакетов в сети CERN), мы используем приведенный ниже сценарий Python для сброса адресов. Мы понимаем, что такое решение нельзя назвать оптимальным решением проблемы, но в качестве временного обходного пути оно вполне допустимо.

#!/usr/bin/env python
import subprocess
intf_mac_list0 = [("enp4s16","d6:d6:d6:54:f9:f8"),
("enp4s16f2", "ee:2b:1d:e6:f7:aa"),
("enp4s16f4", "1e:99:1e:f0:bb:64"),
("enp4s16f6", "6e:82:0c:ff:f8:47"),
("enp4s17",   "da:61:59:96:ab:1d"),
("enp4s17f2", "fe:66:3f:87:74:12"),
("enp4s17f4", "72:7b:1a:0c:bf:fc"),
("enp4s17f6", "46:02:c9:b1:3a:a7")]
 
intf_mac_list1 = [("enp4s16f1", "7a:e7:81:9c:43:38"),
("enp4s16f3",  "ca:fa:89:58:95:92"),
("enp4s16f5",  "ba:7d:2e:d3:1b:96"),
("enp4s16f7",  "3e:72:0d:07:2b:e9"),
("enp4s17f1",  "52:7b:24:90:11:01"),
("enp4s17f3",  "fe:14:4f:45:6d:49"),
("enp4s17f5",  "86:1e:f4:cc:fa:bb"),
("enp4s17f7",  "0a:93:df:2e:62:2b")]
 
for idx, tup in enumerate(intf_mac_list0):
    intf, mac = tup
    cmd = "ip link set %s vf %d mac %s" % ("enp4s0f0", idx, mac)
    print(cmd)
    subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
 
for idx, tup in enumerate(intf_mac_list1):
    intf, mac = tup
    cmd = "ip link set %s vf %d mac %s" % ("enp4s0f1", idx, mac)
    print(cmd)
    subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE,
stdout=subprocess.PIPE)

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

[root@p01001534852033 ~]# lxc-start –d -n centos1
[root@p01001534852033 ~]# lxc-attach -n centos1
[root@centos1 ~]#

https://lists.linuxcontainers.org/pipermail/lxc-users/2014-July/007443.html
https://github.com/tukiyo/lxc/commit/dbf45a526bf5a2f0503737b0b68d244e9389a2a7

4. Тесты

Тесты пропускной способности сети

Мы провели очень простые тесты, чтобы доказать, что нагрузка на сеть внутри и снаружи контейнера находится на одинаковом уровне. Для этой цели мы настроили два компьютера с 10-гигабитными адаптерами Ethernet и подключили их к одному и тому же коммутатору Ethernet 10 Гбит/с. Мы использовали тест iperf3, определяющий скорость передачи данных между клиентом и сервером. Наш клиент — это компьютер, на котором размещены контейнеры, а сервер — другой компьютер (cd1001534-0004132575), подключенный напрямую к этому же коммутатору. Сначала мы запустили тест внутри и снаружи контейнера и измерили пропускную способность. Затем мы повторили тесты в обратном режиме, т. е. при движении трафика с сервера на клиент. Результаты показывают, что подключение является симметричным (скорость в обе стороны одинакова) и что использование LXC не влияет на сетевой трафик в такой конфигурации.

[root@centos2 ~]# iperf3 -c cd1001534-0004132575 -O 3 -t 20
Connecting to host cd1001534-0004132575, port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-20.00  sec  21.9 GBytes  9.41 Gbits/sec    0             sender
[  4]   0.00-20.00  sec  22.0 GBytes  9.43 Gbits/sec                  receiver
 
[root@p010001534074188 ~]# iperf3 -c cd1001534-0004132575 -O 3 -t 20
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-20.00  sec  21.9 GBytes  9.41 Gbits/sec  0             sender
[  4]   0.00-20.00  sec  21.9 GBytes  9.40 Gbits/sec                receiver

Дисковыетесты

При проведении тестов мы хотели выяснить, существуют ли какие-либо ограничения в наборе программного обеспечения при доступе к дискам. Мы запустили два дисковых теста: iozone и ssdbench. Первый тест предназначен для измерения пропускной способности дисков, мы запускали его на внешних дисках HGST HUA72302, находящихся в массиве JBOD и подключенных через адаптер шины SAS. Второй тест предназначен для измерения пропускной способности и количества операций ввода-вывода в секунду (IOPS) твердотельных накопителей (SSD). Этот тест мы запустили для твердотельного накопителя Intel DC P3700 емкостью 400 ГБ, подключенного в разъем PCIe.

Вращающиеся диски

Для этого теста мы подключили тестовую систему к внешнему массиву JBOD с дисками HGST HUA72302 емкостью 2 ТБ с помощью адаптера шины SAS LSI 9207-8e. Тесты iozone имитируют доступ, осуществляющийся системой управления хранилищем данных CASTOR (CERN Advanced STORage manager). На всех подключенных устройствах мы создали файловую систему XFS, которая была подключена со следующими параметрами.

logbufs=8,logbsize=256k,noatime,swalloc,inode64.

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

for i in `seq 1 4`; do /opt/iozone/bin/iozone -R -I -l 1 -u 1 -r 1m -s 4g -F /srv/castor/{drive}/iozone.dat | tee -a iozone-1m-4g-first-disk-loop-"$i".txt; done

Во втором тесте выполнялось чтение одновременно с 9 дисков и запись на них. Мы использовали следующую команду.

for i in `seq 1 4`; do /opt/iozone/bin/iozone -R -I -l 9 -u 9 -r 1m -s 4g –F /srv/castor/{1,2,3,4,5,6,7,8,9}/iozone.dat | tee -a iozone-1m-4g-24fs-loop-"$i".txt; done

Разница между результатами, полученными в ОС и внутри контейнера, не превышала 1 %. Значения, полученные в ОС хоста, показаны на рис. 2.

Spinning Drive I/O Performance

Рисунок 2. Производительность ввода-вывода вращающихся дисков

Твердотельные накопители

Для тестирования системы с накопителями, отличающимися высокой пропускной способностью и низкими задержками, мы установили в систему твердотельный накопитель Intel DC P3700 емкостью 400 ГБ, подключив его к разъему PCIe 3-го поколения. Для доступа к накопителю мы использовали команду fio, которая предоставляет удобный интерфейс для различных операций с накопителями. С помощью этого теста мы стремились проверить, существуют ли у программных компонентов ограничения по операциям ввода-вывода внутри контейнеров, способные повлиять на количество операций ввода-вывода в секунду, пропускную способность и задержки.

В ходе экспериментов мы проводили следующие тесты.

  • Скорость последовательной однопоточной записи блоков по 512 байт с различной глубиной очереди
  • Скорость последовательной записи блоков различного размера в один поток
  • Устоявшаяся скорость произвольного чтения блоков по 4 КБ с различным количеством потоков
  • Устоявшаяся скорость многопоточного произвольного чтения блоков различного размера
  • Устоявшаяся скорость произвольного смешанного доступа блоков по 4 КБ с различным количеством потоков
  • Устоявшаяся скорость произвольной записи блоков по 4 КБ с различным количеством потоков
  • Устоявшаяся скорость произвольной записи с различным количеством потоков

В большинстве случаев результаты внутри и снаружи контейнеров различались не более чем на 1 %. Но при выполнении тестов с более крупными блоками (32 и 64 КБ) показатели IOPS (количество операций ввода-вывода в секунду), пропускной способности и задержек были существенно хуже внутри контейнеров. Результаты см. в таблицах 1 и 2.

Таблица 1. Тесты устоявшейся скорости произвольного многопоточного чтения по размеру блоков, 512 потоков, глубина очереди ввода-вывода = 1

Таблица 2. Тесты последовательной однопоточной записи по размеру блоков, глубина очереди ввода-вывода = 1

Как видно по данным в приведенных выше таблицах, при использовании блоков более крупного размера производительность существенно снижалась. Например, для блоков размером 32 КБ в тесте установившейся скорости многопоточного чтения показатель IOPS оказался на 47,90 % ниже, пропуская способность — на 47,94 % ниже, а задержки — на 91,94 % выше. В тесте последовательной записи в один поток мы также получили на 19,66 % меньше операций ввода-вывода в секунду, пропускную способность на 19,64 % ниже и задержки на 24,02 % выше. Эти расхождения необходимо учитывать при проектировании вычислительной экосистемы, опирающейся на протестированные нами технологии (SR-IOV, LXC, NVMe).

5. Выводы

В ходе изучения нам удалось создать успешно работающую систему с контейнерами Linux и SR-IOV. Мы провели тесты сети и дисков с целью продемонстрировать, что такие системы вполне работоспособны, однако при доступе к твердотельным накопителям возможны отклонения по производительности. Мы считаем этот набор технологий потенциально полезным для инфраструктуры CERN, как описано в параграфе 1.4, и пригодным для дальнейшего изучения в CERN.

6. Библиография

CERN Advanced STORage manager (CASTOR) http://castor.web.cern.ch/.

Кьялман Дж. (KjallmanJ), Кому М. (KomuM), «Гипервизоры и облегченная виртуализация: сравнение производительности [конференция]» // Международная конференция IEEE по облачным системам. — Темпе, шт. Аризона, США: IEEE, 2015 г. — стр. 386–393.

Ксавьер Мигель (XavierMiguel) [и др.], «Оценка производительности контейнерной виртуализации в средах высокопроизводительных вычислений [конференция]» // Параллельные, распределенные и сетевые вычисления. — Белфаст, Северная Ирландия: IEEE, 2013 г. — стр. 233–240.

Приложение A. Управление использованием ресурсов внутри контейнеров

Ограничение использования сети

Для ограничения трафика сетевых интерфейсов можно использовать Linux Traffic Controller (tc). Ниже показан пример ограничения трафика до 1 кбит/с для сетевого адаптера eth0.

tc qdisc add dev eth0 handle 1: root htb default 11
tc class add dev eth0 parent 1: classid 1:1 htb rate 1kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 1kbps

Чтобы снять ограничение с сетевого адаптера eth0, выполните следующую команду.

tc qdisc del dev eth0 root

Ограничение использования других ресурсов

В контейнерах Linux можно ограничивать использование ресурсов каждым контейнером. Ограничения можно установить либо статически путем редактирования файла конфигурации, находящегося по адресу /var/lib/lxc/<имя_контейнера>/config, либо динамически с помощью команды lxc-cgroups. На странице руководства по команде lxc-cgroups доступно подробное описание всех возможных параметров этой команды.

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

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

[root@p01001534852033 centos2]# cat config
--
 
lxc.autodev = 1
lxc.hook.autodev = ./sd.sh
lxc.cgroup.devices.allow = b 8:* rwm
lxc.cgroup.devices.allow = b 259:* rwm
 
[root@p01001534852033 centos2]# cat sd.sh
#!/bin/bash
cd ${LXC_ROOTFS_MOUNT}/dev
mknod sdc b 8 32
mknod sdd b 8 48
mknod sde b 8 64
mknod sdf b 8 80
mknod sdl b 8 176
mknod sdk b 8 160
mknod sdj b 8 144
mknod sdi b 8 128
mknod sdh b 8 112
mknod nvme0 c 10 58
mknod nvme0n1 b 259 0

Приложение Б. Дополнительные ресурсы

Общая документация по контейнерам Linux

Проблема с шаблоном CentOS 7 LXC

Cgroups


6 Пропускная способность.

Дополнительные сведения об оптимизации компиляторов см. в нашем уведомлении об оптимизации.

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