Pull to refresh

Comments 92

Я не спешу переходить на PVE 4 и LXC из-за одной, по моему, более глобальной проблемы — Live Migration (CRIU — не допилен). В 3й версии Live Migration с OpenVZ — просто счастье.
Да я уже почти месяц занимаюсь сексом с lxc и понимаю что openvz счастье, ниже говорят уже можно немного юзать виртуозо семь бету.
мучаемся с proxmox 4 с осени, кроме неработающих нормально бекапов и живой миграции всё в целом устраивает. :)
сторэйдж-бекенд — lvm+iscsi.

а так согласен, контейнерам мало времени уделяют. к pct вместо vzctl привык буквально за месяц.
из явных косяков:
если в контейнере больше одного блочного устройства, то бекапится только первое.
апи контейнеров не полностью работает, только через pct.
А что с производительностью дисков у вас на лвме?
Хотя по идее тонких дисков для лвма нет так что должно быть нормально.
проксмокс всегда был не тороплив к сожалению.
"платный вариант virtuozo сильно ушел по кодовой базе в бок и в какой-то момент оказалось, что openvz работает только на старом ядре версии 2.6.32, а работы по слиянию openvz и virtuozo7 идут, сказать честно, не быстро."

Похоже что пост писали около года назад, когда мы объявили о слиянии OpenVZ и коммерческой Virtuozzo.
А сейчас, когда уже доступна Virtuozzo 7 Beta с работающей миграцией и в течение следующих нескольких месяцев планируется выпустить RTM, это слышать по меньшей мере странно.

"платный вариант virtuozo сильно ушел по кодовой базе в бок"

в openvz три основных компонента: ядро (vzkernel), ploop и vzctl. Из этих трех компонентов разъехался только vzctl. Новая бесплатная и открытая версия Virtuozzo включает vzctl из коммерческой версии Vz. Если какие-то фичи из vzctl для OpenVZ для вас критичны, то их можно спортировать.

Просто возьмите последнюю версию Virtuozzo 7 и покритикуйте, но не пишите что OpenVZ на старом ядре и прочие неактуальные вещи :)
А у него есть веб интерфейс? Я бы сказать честно с радостью смигрировал бы на него.
Ага, печально. Потому что никто в здравом уме Technical preview не будет ставить в production. Мы об этом честно писали во всех анонсах.
К тому же вы зачем-то ссылаетесь на описание ограничений для 1-го Technical preview, который был в июле 2015 года. Хотя неделю назад вышла Beta. Она также не годится для production, но в ней можно пробовать и ВМки и контейнеры. Следующей версей Vz7 уже будет RTM. Вот список ограничений для последней Beta — https://docs.openvz.org/virtuozzo_7_readme.webhelp/_known_issues_and_restrictions.html
Баги постоянно исправляются и новые валидные билды выкладываются каждый день.
ну так я же не для хоумпаг его ставить то хочу, че его пробовать если оно с такими проблемами.
Ждем релиза.
Вы смотрите на промежуточный релиз полугодовалой давности и делаете выводы. Как-то это неправильно, не находите?
Ну я глянул там баги в трекере не особо стало лучше. Того же симфс нету ещё
Вы удивляете меня с каждым новым своим утверждением.
Вот анонс SimFS в RHEL7 ядре.
Ну там же написано что оно еще не доделано.
Вы не переживайте так за виртуозо, надеюсь его все таки допилят.
Посмотрел, сыромятно все, панельки нативной нет, только либвиртовские, где все довольно убого, ждем релиза и нормальной панели.
что такое "нативная" панелька?
Ну у openvz есть нативная панелька например от разработчика из паралелса.
В целом устроило бы любое вменяемое решение на около уровне проксмокса, но там же по большей части полное уг, я их все смотрел год назад, когда думал куда мигрировать.
Какая производительность плупа дискового? Насколько велик оверхед?
слишком общий вопрос, смотря какой паттерн нагрузки.
В общем случае производительность близка к обычной ФС,
а лучше сделать тестовый контейнер и погонять под своими нагрузками.

Если хочется побольше про ploop узнать, что можно с этих источников начать:

  1. Container in a file
  2. Ploop vs SimFS
  3. openvz.org/Ploop
Не очень понял, что тут имеется в виду:

В centos 6 пхп не коннектиться к сокету mysql, надо везде прописывать вместо localhost айпи 127.0.0.1

Не работает коннект к unix сокету (например /var/run/mysql.sock) или по IP? Если был localhost и помогла замена на 127.0.0.1, то это коннект по IP и подозреваю, что дело в пустом файле hosts.
Когда ты пишешь в коннекте localhost php коннектится по сокету, а не по айпи.
А когда 127.0.0.1 то коннект идет по айпи и его можно видеть в том же tcpdump
Ну так а mysql слушает этот сокет? Команда mysql может подключится по сокету? Может права на сокет странные?
ну конечно слушает
ну конечно подключается к сокету мускуль клиент
ну отличные права и любой может читать и писать в него

ну такие то детские проблемы я бы поди на десятке то контейнеров смог бы и сам решить.
lxc у меня совсем не много, но postgres и mysql там есть и работают. У вас хост случайно не убунта? Беглый обзор гугла выявил такую проблему для включённого apparmor, при хранении фалов гостя на ФС хоста.
у вас mysql на centos 6 и можете подключиться с php-mysql?
Это баг именно этой связки.
Какие версии php и mysql взять для теста? Хост будет debian testing
стандартные из centos 6
Итак потестил. Debian testing.
создал контейнер. sudo lxc-create -n ct6 -t centos — R 6
Сразу обнаружилось, что для старта upstart необходима sys_nice. Добавил.
Поставил стандартные mysql-server и php-fpm php-cli php-mysql

Создал скрипт из примера в интернете.

t.php
<?php

echo 'hello';
$link = mysql_connect('localhost', 'lxcct6', 'lxcct6') or die('Не удалось соединиться: '. mysql_error());
mysql_select_db('mysql') or die('Не удалось выбрать базу данных');

$result = mysql_query('show tables;') or die('Запрос не удался: '. mysql_error());

while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
foreach ($line as $col_value) {
echo "$col_value";
}
echo "\n";
}

?>


Создал пользователя в мускле. и потестил.
sudo -u apache php /tmp/t.php
php /tmp/t.php

В обоих случаях все работает прекрасно.

вывод скрипта
hellocolumns_priv
db
event
func
general_log
help_category
help_keyword
help_relation
help_topic
host
ndb_binlog_index
plugin
proc
procs_priv
servers
slow_log
tables_priv
time_zone
time_zone_leap_second
time_zone_name
time_zone_transition
time_zone_transition_type
user


Следовательно проблема с проксмос. Они что-то делают не так с конфигом. Например активируют apparmor. Ведь хост убунта?

Версии
Debian stretch/sid
lxc 1:1.1.5-1
kernel 4.3.0-1-amd64

CentOS release 6.7 (Final)
php-common-5.3.3-46.el6_7.1.x86_64
php-pdo-5.3.3-46.el6_7.1.x86_64
php-mysql-5.3.3-46.el6_7.1.x86_64
php-cli-5.3.3-46.el6_7.1.x86_64
mysql-libs-5.1.73-5.el6_6.x86_64
mysql-5.1.73-5.el6_6.x86_64
php-fpm-5.3.3-46.el6_7.1.x86_64
mysql-server-5.1.73-5.el6_6.x86_64

Ну в тестинге может уже и пофиксили
прокмокс то юзает стейбл
А не покажите конфиг, сгенеренный проксмоксом для этого контенера?
arch: amd64
cpulimit: 8
cpuunits: 8024
hostname:
memory: 16000
net0: bridge=vmbr0,gw=148.251.213.222,hwaddr=62:35:63:30:64:30,ip=/24,ip6=auto,name=eth0,type=veth
onboot: 1
ostype: centos
rootfs: local:224/vm-224-disk-1.subvol,size=0T
swap: 512
На днях бодался с этой проблемой. Да, дело в правах доступа на файл с сокетом.
Пока не нашел ничего лучше чем в стартовом скрипте воткнуть chmod 777 $socketfile
Что то правами у меня эта проблема не решилась
в centos 6 нет никакого системд
а на всех остальных мускул нормально работает
не запустился только старый дебиан, в целом я уже понял что lxc мертвая технология и уже дураку понятно надо мигрировать.
в целом я уже понял что lxc мертвая технология

Звучит так, будто это отдельная подсистема ядра, и она не работает.

Следуя этой логике можно сделать вывод, что докер не работает. Так как он является альтернативной утилитой для создания неймспейсов, как и lxc.
Ну я же уже не первый раз пробовал lxc ну всегда у него детские проблемы альфа версии.
Отгреб аналогичных проблем при миграции, еще и не все устройства корректно прокидываются с хота в гостевую систему, адски деградировала сеть, у меня есть контейнер с разбором трафика на L7, так производительность упала боле чем в 10 раз, промучился с неделю, откатился назад на 3 ветку прокса, буду сидеть там до последнего. На сколько я понимаю, предлагаемый тут Virtuozzo не умеет KVM, у меня хоть и не много таких машин, но есть с десяток в кластере и городить отдельный гипервизор как-то не хочется. Меня более чем устраивает OpenVZ в плане допиленности и стабильности, надеюсь что OpenVZ все таки догонит virtuozo7 и прокс вернут обратно OpenVZ, к сожалению lxc даже близко не готов к продакшину.
Сказать честно я ожидал, что все будет не гладко, но что все настолько чудовищно просто сложно представить пока не попробуешь.
"На сколько я понимаю, предлагаемый тут Virtuozzo не умеет KVM"

Серьезно?

[root@s164 ~]# rpm -qa | grep -e "qemu"
qemu-kvm-tools-vz-2.3.0-31.2.4.vz7.12.x86_64
ipxe-roms-qemu-20130517-7.gitc4bce43.vz7.2.noarch
qemu-kvm-common-vz-2.3.0-31.2.4.vz7.12.x86_64
qemu-kvm-vz-2.3.0-31.2.4.vz7.12.x86_64
libvirt-daemon-driver-qemu-1.3.1-1.vz7.3.x86_64
qemu-img-vz-2.3.0-31.2.4.vz7.12.x86_64
[root@s164 ~]# cat /etc/issue
Virtuozzo Linux release 7.2
Kernel \r on an \m

Одна из особенностей версии 7 это переезд на открытый гипервизор KVM и QEMU.
Спасибо, не знал что умеет, буду к лету усиленно копать в сторону Virtuozzo значит.
С виртуалками там все нормально, кстати.
Штатный prlctl практически со всем справляется.
Спасибо, последнее что читал в новостях, что виртуалки вроди как в планах, но не знал что допилили. Как только закончится поддержка proxmox 3, самый вероятный кандидат для миграции значит будет Virtuozzo, к лету будет ясно в какую сторону двигаться. Отдельно благодарю за ссылку на вменяемый туториал, я так понимаю вы в теме, подскажите как дела обстоят с кластеризацией? Есть ли живая миграция, поддержка фенсинга и прочие фишки "из коробки" или это уже решается на свое усмотрение средствами самой операционки гипервизора? Есть ли единая система управления кластером? Может по ценам за продукт знаете, а то на сайте нет указаний, только звоните.
Насчет цен не знаю, не уверен что сами Odin уже точно по ценам что-то утвердили. В этом вопросе наверняка estet подскажет.
Что касается кластеризации, в документации я ничего об этом не нашел, немного написано только о storage кластерах.
Живую миграцию недавно тестировал, до сих пор не работает.
По описанию выглядит вполне достойной альтернативой, подождем релиза. storage — можно кластеризировать средствами самого СХД, либо собрать CEPH, а вот поддержка со стороны гипервизора перевода виртуалки/контейнера на другой сервер при проблемах на основном — фишка очень нужная, как и фенсинг, без которого сервер может зависнуть наглухо так, что плющить будет весь кластер, пока его по питанию не дернуть.
Живую миграцию недавно тестировал, до сих пор не работает.

должно работать. Зафайлите пожалуйста баг в https://bugs.openvz.org/
Потестил. Все работает, с багами не столкнулся.
По фичам можете здесь посмотреть — https://openvz.org/Comparison и заодно посмотреть feature parity с другими решениями для виртуализации.
HA, распределенное хранилище данных (vzstorage) будут доступны только в платной версии, после установки дополнительных пакетов и активации лицензии. По ценам ничего подсказать не могу. Живая миграция и для контейнеров и для вирутальных машин уже доступна в opensource версии.
TRD про функциональность живой миграции:
https://lists.openvz.org/pipermail/users/2016-February/006792.html
https://lists.openvz.org/pipermail/users/2016-February/006793.html

Ну и если просто хотите доступные фичи попробовать, то имеет смысл глянуть гайд "Virtuozzo Beta Homework" — https://docs.openvz.org/
Наймите уже тесторов что ли. Меня например )
Велкам

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

Естественно у нас есть свой отдел QA, который днями и ночами в хвост и гриву тестирует Virtuozzo. Вот чуть-чуть про наше тестирование ядра:

А дайте панельку погонять бесплатно вашу ?
она не готова пока
А когда ожидается релиз?
я не могу говорить точных дат, но в ближайшее время. Как я уже писал, мы выпустили TP1, TP2, недавно Beta и скорее всего следующий анонс уже будет про RTM.
Дошли руки осилить туториал по вашей ссылке, в его todo наткнулся на ссылку на свою же статью на хабре по пробросу устройств в OpenVZ, страшная вещь рекурсия.
>Два контейнера у меня намертво зависли и их не получилось убить никакими способами

Я на это же напоролся и прекратил эксперименты с LXC. Какой смысл экономить ресурсы, чтобы перегружать весь сервер?
Это полный ахтунг, я был в шоке, в первый раз подумал что это случайность, но когда это стало каждый день (
"Два контейнера у меня намертво зависли и их не получилось убить никакими способами"
Имею более 3000 контейнеров с приложениями на openvz centos6.

Так вот залипших таким образом контейнеров скапливается за неделю до сотни минимум. Их невозможно прибить, vzctl залипает и не убивается даже через kill -9. Через gdb выяснил, что зависает на ioctl VZCTL_ENV_CREATE.

Дальше не колупал, так как нашёлся костыль — vzctl CTID --cpulimit 0. После этого, внезапно, все процессы оживают.
у меня тоже куча контейнеров на опенвз и не встречал такой проблемы. Тут есть ещё такая проблема что такой контейнер в lxc ложит всю ноду в итоге.
До нахождения костыля регулярно перезагружалась вся хост нода. Но, возможно проблема общая, так как LXC и OVZ частично используют одни возможности ядра.
"Два контейнера у меня намертво зависли и их не получилось убить никакими способами"

Про проблемы лучше писать в рассылку, на форум OpenVZ или в багтрекер.
Ну причем тут проблемы lxc в багтрекере опенвз
Да я что-то уже запутался с чем там проблемы. В тексте упоминается vzctl и VZCTL_ENV_CREATE, поэтому и подумал что проблемы с OpenVZ.
Только что глянул что вы менеджер проекта опенвз.
А можно на русском заводить баг?
не рекомендуется
Все комменты не читал, но с миграциями с PVE3 на PVE4 провозился месяца 2 в общем.
Глобальной проблемой оказались (внимание) обновления проксмокса. Т.е. с каждой новой версией появлялись новые проблемы. После одного обновления вырубилась сеть. После другого — перестала высвобождаться память. Так, создание бэкапов (рсинком) файлов убивал насмерть всю ноду. Сначала грешил на ZFS, но после долгих переборов собрал версии всех компонентов, которые точно работают. Кстати, конкретно проблема с памятью при использовании zfs была прям в оригинальном скачанном с офсайта релизе 4.1.
В одной из миграций вообще получилось так, что в контейнере с редмайном не запускался mysql — не было прав на mysql.pid

До этого в 3 версии все работало пару лет вооообще без проблем. Переезд на 4 нужен был из за нового ядра в первую очередь. В целом, в итоге все вроде стабильно стало работать. Но плевался долго.
В общем статья критикует LXC но все проблемы тут исключительно в Proxmox.

  • Миграция ovz -> lxc утилитами Proxmox
  • IO проблемы скорее всего связаны с монтированием qcow2 образов через nbd.
    Зависшие контейнеры, наверное единственная проблема. Но я не встречал такого на LXC ранее. А вот на OVZ — прям сейчас.

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

Миграция это меньшее из зол, в целом я нашел пути как побороть все проблемы с запуском контейнеров после миграции.
ИО проблемы связаны с loopfs которую юзает lxc ну и как вариат в thin provision тоже работает чертовски медленно.

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

НУ а 3 процента зависших контейнеров меня бы уже давно заставили бы смигрировать на какой нибудь квм.
Тут проблема именно в реализации LXC в Proxmox. Отдельно LXC плотно не ковырял, однозначно говорить что проблема в нем не буду, но по факту миграции, когда перенес на тест всего около сотни контейнеров из Proxmox3 в Proxmox4 — начался сущий ад, все виснет, тупит, зависает, отваливается и не работает, один глюк чинишь — вылазит 2 новых, производительность деградировала просто в разы, либо разработчики прокса взяли в команду рукожопов, которые и занимались прикручиванием LXC, либо не все так гладко в королевстве LXC. Я не говорю что OpenVZ безупречен, там своих проблем хватает (контейнеры пару раз висли, из примерно 2.5К контейнеров за крайний месяц зависал один и тот-же дважды), но то, что началось после попытки миграции — кромешний ад. Если LXC по вашему хорош — подскажите продукт на его основе, где он работает без сбоев не на локалхосте (напильник в виде, не нравится — перепиши сам, не предлагать) думаю многие скажут спасибо.

По ссылкам на форум в конце поста вообще смешно читать. Просто жалобы без попыток разобраться.

Жалобы идут обычно после попыток разобраться, когда известные методы решения проблем кончились, если вас веселит откровенно хреновая работа технологии, возможно с вашим ч.ю. что-то не так.
Proxmox не виноват. У меня LXC зависли в Debian Jessie с оригинальным дебиановским ядром.
UFO just landed and posted this here
Надеюсь, simfs допилят в Virtuozzo…

лучше не надеяться и попробовать самому, чтобы о багах узнать до релиза, а не после него
UFO just landed and posted this here
Одно из распространённых заблуждений в использовании opensource — люди думают, что надо немного подождать, пока другие выловят все баги, отрепортят их, сами исправят или добьются того, чтобы кто-то исправил, а они потом уже начнут использовать хорошо протестированную версию. Так вот это не так. Ваши сценарии использования могут отличаться от сценариев других пользователей. И если у кого-то все работает хорошо, то это не значит, что и у вас будет тоже все хорошо :) Именно поэтому стоит попробовать тестовую версию до финального релиза — чтобы убедиться, что на ваших сценариях ПО работает.

Ну и хочу напомнить, что стоимость исправления дефекта прямо пропорциональна времени разработки проекта, поэтому после релиза далеко не каждый баг будет исправлен.
Эх, нагуглил этот пост только сегодня в понедельник после выходных проведенных с Proxmox 4. Да, скорость работы дисковой подсистемы на запись сильно огорчила. Сделал уже restore с --rootfs local:0. Производительность чуть выросла, но все равно пока грустно.

Один контейнер (из ДВУХ!) уже успел намертво повиснуть разок.

Кстати, пользуясь случаем хотел уточнить, а как правильно ребутить сервер с Proxmox? В случае с подвисшим контейнером пробовал reboot и shutdown -r now на ноде — реакции никакой.
хардресет кнопкой
Это не самый корректный способ перезагрузки сервера =)
Я тестовый с 4 веткой через IPMI передергивал (за 2 суток 4 раза подвис наглухо сволочь), вообще у меня в продакшинах фенсинг настроен, хотя третья ветка и не подвисает особо.

Как-то так:


sync;
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
Вы конечно же отобразили свое негодование в багтрекере проксмокса?
Да там как бы всем все известно, проблемы то дикие, и в багтрекере есть и на форуме куча постов и это все прекрасно видят разработчики.
Ага, я прочитал все посты. Как я понял, основной от них ответ по поводу IO в LXC — The suggested way is to use ZFS. Или отключите барьер на ext4, но это не безопасно.
барьер то отключен не помогает.
есть у меня подозрение что с зфс тоже будет все не гладко.
У меня стоит один тестовый сервер с 4 проксмоксом и ZFS. Пока нареканий нет, но что-то действительно тяжелое я там не запускал.
у меня тоже нет нареканий на виртуалках где хоумпаги, но база даже размеров в 30 гигов в мускул заливается два дня местами, а что уж говорить про большие базы.
Only those users with full accounts are able to leave comments. Log in, please.