Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
(no subject)
Speaker Rabbit
abbra
Отличная заметка Дреппера по поводу борьбы на рынке виртуальных сред. В сочетании с опубликованной 23 февраля статьей VMWare о кознях Microsoft в этой области хорошо демонстрирует общую перегретость ожиданий рынка и очередную "войну миров".

А мне вот интересно, как живут друг с другом KVM и OpenVZ? k001? В частности, меня интересуют в OpenVZ две вещи: производительность прокси-драйверов (сеть, файловая система) и перспективы поддержки POSIX ACLs, POSIX ATTRs в simfs. Без поддержки этих базовых вещей размещение всяких сетевых штук вроде Samba/NFSv4 в контейнерах OpenVZ бессмысленно.

  • 1
производительность сети в OVZ, имхо, страдает на уровне генокода (увы), нормально виртуализовать tcp/ip не удалось ни в OVZ, ни в VServer (только в смысле производительности, в смысле же архитектуры в OVZ с этим получше на порядок)

про ACL/ATTRS:

[root@vpeet64 ~]# mount
simfs on / type simfs (rw)
sysfs on /sys type sysfs (rw)
proc on /proc type proc (rw,noexec,nosuid,gid=19)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
[root@vpeet64 ~]# lsattr
------------- ./tmp
----i-------- ./bala
[root@vpeet64 ~]# echo dala >bala
-bash: bala: Permission denied


и вот:

[root@vpeet64 ~]# setfacl -m user:nobody:--x bala
[root@vpeet64 ~]# getfacl bala
# file: bala
# owner: root
# group: root
user::rw-
user:nobody:--x
group::r--
mask::r-x
other::r--


если б ещё TBS навесили на simfs, цены бы не было.

Первый пример показывает обычные атрибуты, меня же волнуют extended attributes, setfattr/getfattr. В моем случае оба этих варианта не сработали -- ни attrs, ни acls.

mount /opt/vz -o remount,acl

update: mount /opt/vz -o remount,acl,user_xattr

производительность сети в OVZ, имхо, страдает


Вы не могли бы подробно аргументировать этот тезис?

эээ... начал писать рассказ о том, как, не найдя правды в сетевой части VServer (нужны были виртуальные loopback'и), в Обнинске с удовольствием послушал про OVZ и ради интереса почитал код в тех же местах, но ниже оказался Ваш же пост, который именно про это и написан. Возможно, падение в два раза (ну, реально не в два, чуть меньше) -- не так много. Но я только недавно почуствовал разницу, увеличив скорость на линке на треть, и не готов делить это пополам :) (ну, я преувеличиваю, просто процессор будет загружен, скорее всего, вдвое)

Я не ругаю OVZ ни в коем случае, просто реализовать виртуализацию в ядре на том уровне, на котором это делают OVZ и VServer, имхо, без серьёзных проблем сложно -- порукой тому объём Вашего же кода. И всё должно кончаться либо полной "шизофренией" у ядра, либо постоянными проверками на принадлежность объекта I/O к контексту безопасности. В первом случае уйдёт много памяти, да и проще гонять kvm или xen, во втором -- падает производительность. А если, как в VServer, по мере возможности копировать пакет -- ну, тут вообще беда.

То есть, дело не в качестве кода, дело в использованной технологии, вот я про что.

Вы тестирования venet или veth? Можете кратенько набросать методику тестирования?

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

тескейс, который я юзал -- многочисленный netcat одного файла (взятого из /dev/urandom) через direct link машины в машину на полуметровом патчкорде (чтоп исключить настроение свитча, проблемы с эхом на длинном проводе и т.п.). С одной стороны линух, с другой -- линух либо гест (один) ovz (venet) либо гест (один) xen. Тайминги могу на досуге снять, не проблема. Veth не гонял.

ещё одно допущение: я гонял (гоняю) xen, как и ovz, на amd64x2, где xen работает в режиме нормальной виртуализации. Как будет себя вести xen в паравиртуализации -- хез, можно попробовать.

Что-то это нифига не согласуется с тем, что у меня есть в голове. Это был fast ethernet, gigabit ethernet, или что-то ещё?

Ещё: это был tcp или udp?

ещё хорошо бы коммандлайны привести, размер файла, в какую сторону его тянули, и что конкретно мерялось?

PS на самом деле я, возможно, догадываюсь, что там произошло. /proc/user_beancounters не смотрели в процессе теста?

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

Пойду сегодня мерять, расширив буферы.

На гигабите оверхед может достигать 15%. Мы достаточно много времени потратили на исследование этой ситуации, профайлинг и прочее.

я попробовал так.

1. Сгенерил файлик 10 мегабайт:
dd if=/dev/urandom of=test10M bs=1M count=10)

2. На удалённой машине запустил:
nc -v -l -p 12345 -q 0 >/dev/null

3. На локальной машине запустил:
time (for i in `seq 1 30`; do nc RE.MO.TE.IP 12345 < test10M; done)

Сделал то же самое, только вместо удалённой машины использовал VE.

Сделал то же самое, только вместо netcat использовал scp -c blowfish. И с машиной, и с ВЕ.

Во всех случаях результаты колеблются от 32 до 33 секунд, и от того, машина это или ВЕ, ничего не зависит (то бишь там разница в 0.1 секунды или вроде того).

Вопрос: что я делаю не так?

в п. 2 вкралась опечатка. на самом деле команда выглядит так:
while true; do nc -v -l -p 12345 -q 0 > /dev/null; done

ибо там стоит какая-то простая версия нетката, которая не умеет игнорировать eof.

единственное, что у меня не так — это то, что машины не стоят рядом — между ними там как минимум один маршрутизатор. с двумя через кроссовер смогу попробовать только днём.

как живут друг с другом KVM и OpenVZ

мы не пробовали

производительность прокси-драйверов (сеть, файловая система)

Ты имеешь в виду OpenVZ драйвера или KVM-драйвера?

Если OpenVZ, то дефолтная сетка (т.н. venet)у нас устроена как ещё один TCP/IP стек — то бишь, хост-система работает как маршрутизатор, а в VE есть отдельный девайс venet. Плюсы — можно в VE заводить iptables and routing rules, всё это весьма секьюрно. Минусы — некоторое (весьма незначительное, цифры не помню) падение производительности (потому что пакет по двум стекам путешествует), отсутствие MACa (невозможность приёма бродкастов и т.п.).

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

В каждой ВЕ можно использовать любой вариант, или оба сразу. Разница меж ними тут наглядно расписана: http://wiki.openvz.org/Differences_between_venet_and_veth

По поводу файловой системы — simfs совсем тупой (поэтому и называется SIMple), он, в общем-то, нужен только для того, чтобы был суперблок — а суперблок нужен для дисковой квоты. На производительности simfs никак не сказывается, то бишь всё так же, как на подлежащей ФС.

Плюс к тому, можно bind mount-ом что-нибудь монтировать внутрь VE, или дать ей доступ к физической партиции. Всякие там AIO мы тоже поддерживаем (и даже умеем мигрировать, что нетривиально).

По поводу acl/attrs — в планах есть, но сроки точно сейчас затрудняюсь назвать.

всяких сетевых штук вроде Samba/NFSv4

NFS сервер или клиент? Ядерный nfs-cервер в ВЕ нельзя запустить (его надо виртуализовывать), юзерспейс можно, монтировать нфс-ные шары (экспорты?:) из ВЕ можно. http://wiki.openvz.org/NFS

Самбу, наверное, монтировать изнутри ВЕ нельзя — требует виртуализации.

> По поводу acl/attrs — в планах есть, но сроки точно сейчас затрудняюсь назвать.

Видимо, я чего-то не заметил, или текущей реализации не хватает? Вроде всё работает, нет?

Может, я что напутал. Завтра посмотрю точно.

Да, оно действительно работает, причём никаких подпрыгиваний не потребовалось. Просто мы раньше собирали ядро без поддержки оных.

Речь идет именно о запуске серверов внутри контейнеров (а зачем тогда контейнеры, если этого делать нельзя? :-)

Вообще, отсутствие нормальной сети и поддержки функционала обычных файловых систем (ext3/reiserfs/jfs/xfs) -- главное, что меня напрягает в текущих sub-виртуализациях. Потому что без этого сложно делать сервисы, которые как раз и хотелось бы виртуализовывать в рамках одной среды, разбросав куски по разным "машинам". Контроллер домена, клиенты, другие компоненты. Я смотрю на субвиртуализацию сейчас как на относительно легкий механизм собирания тестовых стендов для сложных сетевых приложений.

Почему бы не появиться разновидности venet с MAC-ом? В конечном итоге, в рамках одной физической машины это можно было бы сделать и широковещательные пакеты ходили бы между машинками, технически можно было бы и на всю виртуальную среду-домен распространить посредством какого-нибудь VPN (в VMWare оно же ходит), так чтобы широковещательные запросы работали в этой "сети" между всеми машинами, на которых подняты контейнеры, входящие в единую среду (там, где можно сделать заморозку/разморозку контейнера).

отсутствие нормальной сети

Что такое нормальная сеть? Ethernet? пожалуйста — берите сетевой адаптер, прокидывайте его в ВЕ (vzctl set VEID --netif_add ethX).

поддержки функционала обычных файловых систем (ext3/reiserfs/jfs/xfs)

Все ФС, которые не требуют kernel thread — работают в VE. Которые требуют (а это, например, ext3 (kjournald) — их надо виртуализовывать, либо монтировать ФС из хост-системы.

Почему бы не появиться разновидности venet с MAC-ом?

venet — это хост-система в качестве роутера. там не нужны маки, потому что за роутером маки не видны. Кому нужны маки — есть veth и бриджинг.

Подожди, ты же говоришь, что у тебя в случае venet поднимается еще один стек. Так почему нельзя сделать вариант, при котором у тебя в основную систему виртуальная не будет выглядеть еще одним интерфейсом? Вот как, например, делает IBM Everyplace Connection Manager (WECM): он подымает tun/tap и за весь трафик на него (входящий и исходящий) отвечает демон в user-space, который общается со своим сервером через системные интерфейсы, но инкапсулирует трафик, входящий локально в его этот tun/tap-овский интерфейс, а из него выплевывает то, что ему от сервера пришло (VPN). В случае контейнера, в принципе, ровно такая же картина.

Да, я понимаю, что tun/tap медленные, но такой метод позволяет получить полноценный интерфейс, с которым приложение может делать все, что нужно, включая и броадкасты. Например, сделать десяток контейнеров, в каждом такой интерфейс, со своим мак-адресом, все на самом деле "слышны" друг другу и основной системе, которая их видит через один системный интерфейс. Такая виртуальная локальная сеть.

Я же ж писал выше, что у нас есть venet, а есть veth.

Простой вопрос -- чем не подходит veth?

так более одного контейнера с veth может быть одновременно на одной машине (одной сетевой карте)? Из твоего описания я это не уловил. Вообще, вот эти характеристики бы где-нибудь отдельно в wiki, если честно. Вроде примитивные вопросы, но в вашем wiki я это не откопал, по поводу simfs пришлось просто взять и посмотреть его патч, чтобы понять, что это наслоение поверх существующей файловой системы, да еще и не очень хорошо дружащее с ядерными потоками, как ты объяснил.

так более одного контейнера с veth может быть одновременно на одной машине (одной сетевой карте)? Из твоего описания я это не уловил.


ну конечно, может. veth — это как две ethernet-карты, соединёнными кроссоверным кабелем — одна карта торчит в VE, другая карта — в хост-системе. В вики, вроде бы, так и написано. Понятно, что этих «пар» может быть сколько угодно.

Наверное, надо картинку нарисовать, чтобы было понятно….

да еще и не очень хорошо дружащее с ядерными потоками, как ты объяснил.


simfs к кернель тредам никакого отношения не имеет. Просто, проблема в том, что если ты смонтировал ext3 внутри ВЕ, то ядро запускает kjournald. Таким образом, владелец ВЕ запускает кернель тред, который что-то там делает. Это несекьюрно по определению. На практике — оно работает, но надо смотреть, разбираться, к каким последствиям это может привести.

Все, понял. Но вики "для незнакомых" править надо, однозначно.

поддержки функционала обычных файловых систем (ext3/reiserfs/jfs/xfs)


Во-первых, simfs работает поверх "обычной" файловой системы, то бишь это не simfs, а simfs over ext2, simfs over ext3, simfs over reiser. То бишь, "поддержка функционала обычных файловых систем" по сути есть. Перфоманс такой же.

Во-вторых, что касается возможности напрямую монтировать разделы внутри ВЕ. Таковая возможность есть, надо только дать VE доступ к физической партиции -- хочу отметить, что при этом VE привязывается к реальному железу, то есть мы теряем то преимущество, что ВЕ железонезависима. Я бы хотел услышать сценарий, когда это надо делать.

В-третьих, что касается файловых систем в ВЕ. Этот пункт привязан ко второму. Сейчас можно использовать ext2, ext3 (не очень секьюрно) и автомаунтер. Остальные fs надо смотреть -- возможно, достаточно всего лишь добавить флажок FS_VIRTUALIZED в file_system_type.fs_flags.

Как-то так получилось, что я второй раз спамлю вам в комменты :( Прошу прощения…

:-) Нормально

  • 1
?

Log in

No account? Create an account