nepal
  • k001

OpenVZ пакеты для Debian

(Ниже перевод моего недавнего поста в openvz. Как и любой перевод, он несколько корявый -- простите великодушно!)

Хорошие новости!
Проф. Фарнсворт

Много кто использует OpenVZ на Дебиане. Более того, Дебиан был один из первых дистрибутивов, в который было включено ядро и утилиты OpenVZ. К сожалению, сейчас это не так -- из Дебиана 7 "Wheezy" убрали ядро OpenVZ. Обходным вариантом решения этой проблемы было преобразование RPM-пакета с ядром в формат .deb при помощи утилиты alien -- но это процесс ручной и не очень естественный.

К счастью, сейчас у нас есть работающая билд-система для Дебиановских пакетов, и репозиторий для wheezy с последними самыми лучшими ядрами (и утилиты там тоже есть). На самом деле даже два репозитория: один для стабильных, другой для тестовых ядер и утилит. Ядра билдятся в .deb и выпускаются одновременно с rpm-пакетами. На сегодня утилиты (vzctl/vzquota/ploop) лежат только в репозитории "wheezy-test" -- как только мы получим достаточно много писем о том, что они работают хорошо, мы перенесём их в стабильный репозиторий "wheezy".

Чтобы включить эти репозитории:

cat << EOF > /etc/apt/sources.list.d/openvz.list
deb http://download.openvz.org/debian wheezy main
deb http://download.openvz.org/debian wheezy-test main
EOF
apt-get update

Для установки ядра:

apt-get install linux-image-openvz-amd64

Ссылки по теме:

Диски OpenVZ контейнеров ploop на NFS шаре

Всем привет!

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

Но в случае использования ploop все становится весьма радужно, так как вместо тысяч файлов контейнеров мы храним лишь один единственный, причем, не пользуемся даже частью POSIX фич ФС.

Также стоит вопрос - NFS3 vs NFS4, есть ли в контексте данной задачи у NFS4 явные преимущества?

Вопрос - у кого есть реальный опыт эксплуатации такого в продакшене и кто будет рад им поделться?

Включение pfcache в openvz

pfcache в OpenVZ - по changelog вроде уже работает в OpenVZ ядрах. Я попробовал его включить MOUNT_OPTS="discard,pfcache_csum,pfcache=/vz-ssd/pfcache"

Далее в логах я нашел

May 7 11:52:49 kernel: [1162584.490801] EXT4-fs (ploop50161p1): mounted filesystem with ordered data mode. Opts:
May 7 11:52:49 kernel: [1162584.491138] PFCache: relink 182:802577 to "/vz-ssd/pfcache" +0 -0 =0 peers
May 7 11:52:49 kernel: [1162584.491259] EXT4-fs (ploop50161p1): loaded balloon from 12 (0 blocks)
May 7 11:52:49 kernel: [1162584.492775] CT: 104: started


Так и должно быть? Права на /vz-ssd/pfcache -> 0700? Папка остается пустой, по du -sh -> 4.0K

Kir пишет

Важно вот что -- если контейнер доступается до файла, у которого есть такая прописанная в xattrs чексумма, И файл с такой чексуммой есть в "общаке" -- то внутри ядра файл подменяется на файл из общака. Как следствие -- шаринг памяти (и экономия i/o, и лучшее использование кеша).


В официальной wiki я почти ничего не нашел на счет pfcache. Кто-нибудь пробовал включать? На сколько ускоряется i/o? На сколько лучше использование кеша?
Работает ли это вместе с Page cache isolation? Есть паблик бенчмарки?

И мой частный случай. Я использую 2xSATA(RAID-1 софт) - под бекапы, 2xSSD(RAID-1 софт) -> на каком из массивов лучше размещать pfcache?

Перезагрузка/ выключение контейнера во время ploop snapshot

Всем привет! Делаю бекап контейнеров с помощью ploop snapshot -> вот таким скриптом.
Мне стало интересно, что может произойти -> если я перезагружу контейнер во время бекапа.
Результат можно увидеть на видео.



Контейнер не блокируется и далее можно потерять данные.

Далее я решил попробовать сделать тоже самое во время vzctl compact. В этом случае контейнер не перезагрузился, но остался в статусе -> mounted.
Даже когда vzctl compact закончился, контейнер продолжал оставаться в статусе -> mounted.
То есть если пользователь VPS во время vzctl compact -> перезагрузит свою VPS, то единственное, что ему останется или ребут через панель или писать в тех поддержку.
nepal
  • k001

vzstats

Предвидя вал негативных комментов, всё же рискну попросить о помощи.

Мы тут сделали небольшую систему для сбора статистики использования OpenVZ. На сервер, где крутится OpenVZ, ставится клиент, который собирает и передаёт данные на сервер. Сервер обобщает данные и рисует всякие интересные таблички и картинки. Код клиента прозрачен и доступен для понимания, а статистика анонимна, насколько это возможно. Ваши файлы, айпи-адреса, пароли, явки и номера кредитных карт нам не нужны. Вот прямо совсем не нужны.

А что нам нужно и зачем? Нам нужно всё и сразу. Хочется понять, например, каково распределение между RHEL5 и RHEL6-based ядрами. Как часто люди обновляют vzctl. Насколько широко используется ploop и vswap. Под какое количество CPU, памяти, контейнеров нам оптимизировать софт. И так далее.

Вам, быть может, тоже что-нибудь из этого интересно. Поэтому результаты открыты, они есть на сайте http://stats.openvz.org/. Возможно, я сделаю доступным дамп базы данных, если его можно будет совсем уж обезличить (сейчас там хранится uuid -- случайно сгенерированный привязанный к ноде идентификатор).

Несколько более подробно про сам проект на http://openvz.org/vzstats.

Попросить хочу о двух вещах:

1. Помогите нам это потестить. Поставьте клиент себе на ноды (yum install vzstats). Изучить его исходники можно на http://git.openvz.org/?p=vzstats;a=summary

2. Напишите, что можно исправить или улучшить. Если вы не хотите ставить клиента, напишите (хотя бы тут в комментах), почему именно, и что можно сделать для того, чтобы изменить ваше решение.

Ну и спрашивайте, если что хотите узнать. Пока это всё в режиме бета- (а может и альфа-) тестирования.
  • poige

Чем больше я имею дело с OpenVZ, тем больше недоумения вызывает userspace этого проекта

Весь, буквально весь!
  1. Хуки при старте/стопе VE. Почему-то есть хуки, которые будут вызваны в контексте VE, а не HN. Непродуманность подхода очевидна сразу же — из HN легко и просто запустить что угодно внутри VE, из VE в HN — по определению нельзя. Кто и чем думал, чем руководствовался ­— непонятно, но ясно одно — только не здравым смыслом. Не я один это понимаю, да.
  2. Настройка VETH с какими-то proxy_arp, /32-роутами через broadcast-интерфейс. Зачем?! Правильно это делается просто «развешиванием» одной IP-сети (начиная с /30) на стороне HN, и VE. Внутри VE получается логичный и простой default gateway IP-address. Это (детка) — Ethernet, всё остальное тут уже слегка кривовато. Тем более, что есть pointopoint ус-во VENET.
  3. Численные идентификаторы VE 100500, вместо возможности использовать alias'ы — ns.foobar.com, внутри которых хранились бы UUID'ы — уникальные идентификаторы каждой VE. Миграция упрощается на раз-два, риск коллизий номеров практически 0. Очевидные удобства обращения с символическими именами, вместо численных параметров известны со времён изобретения ассемблера, или, хотя бы, DNS.
  4. Про внезапное перетирание конфигов внутри VE (простым перезапуском VE с конфигом в котором руками добавлен параметр IP_ADDRESS) я уже писал. Что характерно, в переписаном /etc/network/interfaces вам скажут, типа, "don't edit, автоматишен генерашен файло", но предупреждения postfactum это скорее издевательство, чем предупреждения. Бэкап никто сделать не догадался. Предложенный патч для бэкапа перетираемого конфига, если в нём нет предупреждения (читай ванильный юзерский конфиг), нужно пропихивать через список рассылки разработчиков — иначе нет пути (потому что все очень гордые, а некоторые ещё и умные).
  5. Забавное (мягко говоря) использование 127.0.0.2. Типа, чтобы Debian 3 поддержать, ага. А ничего, что сетка 127/8 — это loopback, и если уж иметь резоны использовать IP, который логически внутри неё, то хотя бы помнить, что 127. — это класс A, и маска, по-умолчанию, будет /8, и нужно использовть что-то более узкое, типа /32, ну или /30. А ещё лучше использовать какой-нибудь link-level autoconfig scope, а не loopback. А ещё лучше вообще без этих костылей сделать поддержку. Закат солнцаУдаление маршрутов через интерфейс, при переводе его в down — из той же оперы.
  • poige

Приходилось ли вам делать vzmigrate в пределах одной HN?

Необходимость может быть очень простой — например перетащить VE с одного раздела на другой, без прерывания сервисов.

Судя по man'у, штатной возможности для локальной миграции не предусмотрено вовсе, но наверное можно поискать обходные пути.
  • poige

А вы не считаете, что сетевая «автоматизация» в CT не должна быть включеной по-умолчанию?

— Сейчас единственный(?) вариант — это вытирать из конфига OSTEMPLATE, в противном случае, ваш /etc/network/interfaces (для Debian/Ubuntu) будет заботливо испоганен простым запуском виртуалки, в конфиге которой прописан IP-адрес. Без предупреждений, собственно. Нафига? Я понимаю, что уши OpenVZ торчат из Virtuozzo, и такая автоматизация там была частью ТЗ (возможно), но зачем она OpenVZ по-умолчанию?

UPD.: Кстати, 2-й вопрос это чей сумрачный гений выдал такое(!):
# Auto generated venet0 interface
auto venet0
iface venet0 inet manual
        up ifconfig venet0 up
        up ifconfig venet0 127.0.0.2
        up route add default dev venet0
        down route del default dev venet0
        down ifconfig venet0 down
— ? Тут же каждая строчка прекрасна!