Comments 90
То есть сервера на зене висли, а на openvz проблемы магически прошли? Что-то как-то странно написано. Вообще, миграция с Xen на контейнеры как средство повышения стабильности вызывает острый скепсис, особенно в свете того, что и в PCS, и в OpenVZ злой гость может попортить нервы администратору bind'ами файловой системы немеряно.
Упомянутый Вами баг-фича с mount bind решен уже месяц с лишним назад: wiki.openvz.org/Download/kernel/rhel6-testing/042stab079.4 да и на практике мы ни разу не видели его эксплуатации.
ок, молодцы, закрыли. Мне для того, чтобы его самому найти понадобилось пол-часа на VDS'ке под openvz.
Повторю вопрос: вы про стабильность openvz по сравнению с xen'ом серьёзно? Не хотите соревнование устроить? Правила простые: по сети на невинные узлы не гадить (то есть specially crafted traffic пожалуйста — он же на соседей — нет), ограничться 30-50 мегабитами максимум.
Каждый предоставляет соседу контейнер/виртуалку и даёт возможность попытаться попортить жизнь администратору хоста/соседям. Разумеется, хосты в этом случае лабораторные.
Как вы думаете, у кого больше шансов попортить жизнь соседям — у root'а в openvz или у root'а в xen'е?
Количество постоянно добавляемых beacon в openvz позволяет легко апроксимировать число «неучтённых» тонких мест в изоляции. Как в этих условиях можно говорить про большую стабильность — не понимаю.
Повторю вопрос: вы про стабильность openvz по сравнению с xen'ом серьёзно? Не хотите соревнование устроить? Правила простые: по сети на невинные узлы не гадить (то есть specially crafted traffic пожалуйста — он же на соседей — нет), ограничться 30-50 мегабитами максимум.
Каждый предоставляет соседу контейнер/виртуалку и даёт возможность попытаться попортить жизнь администратору хоста/соседям. Разумеется, хосты в этом случае лабораторные.
Как вы думаете, у кого больше шансов попортить жизнь соседям — у root'а в openvz или у root'а в xen'е?
Количество постоянно добавляемых beacon в openvz позволяет легко апроксимировать число «неучтённых» тонких мест в изоляции. Как в этих условиях можно говорить про большую стабильность — не понимаю.
Про стабильность мы абсолютно серьезно Случаев, когда клиент виртуального сервера выводил из строя сервер целиком — единицы за последний год (да и-то это бал лишь небольшая деградация производительности, а не отказ). Не буду отрицать — это случается, но это настолько экзотические стечения обстоятельств, которые довольно сложно воспроизвести в лабораторных условиях, что я не вижу совершенно никаких поводов для беспокойства.
А по поводу недочетов в системе изоляции — найдите еще и мы с радостью их починим с инженерами Parallels :)
По поводу тестов — это Вам скорее к Parallels, а не к нам, у них чудесная Test Team, которая как раз отрабатывает ситуации «а давайте замучаем этот контейнер» :)
А по поводу недочетов в системе изоляции — найдите еще и мы с радостью их починим с инженерами Parallels :)
По поводу тестов — это Вам скорее к Parallels, а не к нам, у них чудесная Test Team, которая как раз отрабатывает ситуации «а давайте замучаем этот контейнер» :)
Обратите внимание что речь идет про Xen на Debian Etch. А это должно было быть 2007-2008 год. Тогда у Xen'а действительно были проблемы со стабильностью. И тогда в какой-то момент код Xen'а даже выкинули из ядра… Обратно Xen в ванильное ядро приняли совсем недавно, перед самой сменой нумерации версий Linux на 3.х, если мне не изменяет память.
Тогда проблемы были с этим…
В статье много других вещей смущает. Про изоляцию ввода/вывода например. Индивидуальная файловая система для каждого контейнера — хорошая идея. Но проблему с производительностью подсистемы ввода вывода она решить не может…
Как-то у автора запросто получается сравнивать принципиально разные технологии: контейнеры с гипервизорами.
Кстати, вопрос: Какой гипервизор используется PCS? Уж не Xen ли случаем?
Тогда проблемы были с этим…
В статье много других вещей смущает. Про изоляцию ввода/вывода например. Индивидуальная файловая система для каждого контейнера — хорошая идея. Но проблему с производительностью подсистемы ввода вывода она решить не может…
Как-то у автора запросто получается сравнивать принципиально разные технологии: контейнеры с гипервизорами.
Кстати, вопрос: Какой гипервизор используется PCS? Уж не Xen ли случаем?
Так она и не должна решать проблемы с производительностью ввода вывода непосредственно, она решает лишь проблемы, когда много-много мелких изменений коммитятся в журнал от одного контейнера и мешают жить остальным. Разумеется, если дисковая сама по себе медленная — это никто и никак решить не может, только его величество апгрейд :)
Насколько я знаю, гипервизор используется собственной разработки Parallels, но тут могу нагло врать, так как мы работаем исключительно с контейнерами.
Насколько я знаю, гипервизор используется собственной разработки Parallels, но тут могу нагло врать, так как мы работаем исключительно с контейнерами.
Насколько я знаю (я не спец) там контейнеры, коммерческая версия openvz с приватной панелькой.
Последний раз когда меня в него пустили, я сделал -300Гб (на 300Гб меньше, чем 0) свободного места. Мне сказали «там криво настроено» и на этом всё слегка заглохло, а дальше было лениво смотреть.
Последний раз когда меня в него пустили, я сделал -300Гб (на 300Гб меньше, чем 0) свободного места. Мне сказали «там криво настроено» и на этом всё слегка заглохло, а дальше было лениво смотреть.
Боюсь, такое было возможно только в vzfs, да, она бесилась временами и сходила с ума (за что скоро станет deprecated). Но в ploop как ни финти — за квоту не вылезти.
Уточню сам себя. PCS — это не только контейнеры (openvz), но и полноценный гипервизор с характеристиками на уровне KVM. И да — из одного интерфейса можно создавать и контейнер и виртуальные машины. Например, легко дружится FreeBSD/Solaris в VM и Linux в контейнере.
Хаха, смешно, когда «характеристики на уровне KVM» достигаются использованием [чуть пиленого?] QEMU/KVM.
А можно поподробнее и попредметнее? :)
Поподробнее и попредметнее будет в вашем сообщении вместо фразы «но и полноценный гипервизор с характеристиками на уровне KVM» написать «но и полноценный гипервизор, основанный на QEMU/KVM».
А то получается, что это вроде как гипервизор собственной разработки, который круче, чем горы, яйца и KVM, а на деле это тот же самый QEMU/KVM. Ну, примерно как BolgenOS и Ubuntu.
А то получается, что это вроде как гипервизор собственной разработки, который круче, чем горы, яйца и KVM, а на деле это тот же самый QEMU/KVM. Ну, примерно как BolgenOS и Ubuntu.
Прочтите уже описание продукта www.parallels.com/products/server/baremetal/sp/whatsnew/ и не несите околесицу про «копипасту qemu/kvm». Это самостоятельный продукт, не имеющий никакого отношения к KVM и Qemu в целом и уже долгое время работающий в продакшене.
А вот что говорят нам факты:
[root@server ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 45
Stepping: 7
CPU MHz: 2299.000
BogoMIPS: 4598.00
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 15360K
NUMA node0 CPU(s): 0
Я не очень понимаю зачем вы тут дискутируете и портите себе репутацию непрофессиональными комментариями, поскольку этот вопрос (какой тип виртуализации используется) напрямую не затрагивает ваши интересы. Но факт, что используется KVM-виртуализация, что и требовалось доказать.
Не вижу в этом ничего плохого, KVM — отличный инструмент, лицензия GPL позволяет делать с ним что угодно, но как то более на мой взгляд правильно что ли было бы упоминать в доках о том, что используется этот тип виртуализации. Ну так, чисто из уважения к комьюнити, и чтобы казусов не было, когда партнер с пеной у рта доказывает что KVM ни причем, а KVM-то — вот он ;)
Ничего личного — мы просто стремимся к торжеству истины :) Ведь как мы можем рекомендовать или использовать для пользователей продукт, который не знаем и за который не стоим горой?
Ваши доводы может быть и верны, в какой-то мере. Пока эта мера в том, что lscpu — бажен :)
Если верить lscpu (к слову, это весьма странная тулза) то да, это, безусловно KVM:
sudo lscpu
Architecture: x86_64
CPU op-mode(s): 64-bit
CPU(s): 1
Thread(s) per core: 1
Core(s) per socket: 1
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 26
Stepping: 5
CPU MHz: 3074.000
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
Если же посмотреть на cpuinfo, он не имеет ни малейшего повода для похожести на KVM:
cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 26
model name: Intel® Core(TM) i7 CPU 950 @ 3.07GHz
stepping: 5
cpu MHz: 3074.000
cache size: 8192 KB
fpu: yes
fpu_exception: yes
cpuid level: 11
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc up arch_perfmon rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt hypervisor lahf_lm ida arat
bogomips: 6148.00
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:
Для сравнения KVM выглядит так:
cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 13
model name: QEMU Virtual CPU version (cpu64-rhel6)
stepping: 3
cpu MHz: 3392.292
cache size: 4096 KB
fpu: yes
fpu_exception: yes
cpuid level: 4
wp: yes
flags: fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good pni cx16 hypervisor lahf_lm
bogomips: 6784.58
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:
А если верить родной утилите от производителя KVM (RedHat), virt-what то это — bare metal (случай, когда скрипт не выводит ничего), то есть вообще физическое железо, как же он не признал KVM-то?
Надеюсь, сейчас сомнений в том, что это не KVM? =)
Как последний киллер довод приведу то, что этот же самый гипервизор работает на Mac OS () и виртулизирует все, что пожелает душа. KVM такого не умеет.
Ваши доводы может быть и верны, в какой-то мере. Пока эта мера в том, что lscpu — бажен :)
Если верить lscpu (к слову, это весьма странная тулза) то да, это, безусловно KVM:
sudo lscpu
Architecture: x86_64
CPU op-mode(s): 64-bit
CPU(s): 1
Thread(s) per core: 1
Core(s) per socket: 1
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 26
Stepping: 5
CPU MHz: 3074.000
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
Если же посмотреть на cpuinfo, он не имеет ни малейшего повода для похожести на KVM:
cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 26
model name: Intel® Core(TM) i7 CPU 950 @ 3.07GHz
stepping: 5
cpu MHz: 3074.000
cache size: 8192 KB
fpu: yes
fpu_exception: yes
cpuid level: 11
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc up arch_perfmon rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt hypervisor lahf_lm ida arat
bogomips: 6148.00
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:
Для сравнения KVM выглядит так:
cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 13
model name: QEMU Virtual CPU version (cpu64-rhel6)
stepping: 3
cpu MHz: 3392.292
cache size: 4096 KB
fpu: yes
fpu_exception: yes
cpuid level: 4
wp: yes
flags: fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good pni cx16 hypervisor lahf_lm
bogomips: 6784.58
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:
А если верить родной утилите от производителя KVM (RedHat), virt-what то это — bare metal (случай, когда скрипт не выводит ничего), то есть вообще физическое железо, как же он не признал KVM-то?
Надеюсь, сейчас сомнений в том, что это не KVM? =)
Как последний киллер довод приведу то, что этот же самый гипервизор работает на Mac OS () и виртулизирует все, что пожелает душа. KVM такого не умеет.
Я слышал, что у Parallels есть наработки для виртуализации ОС и для windows.
Есть, даже промышленные и серверные, правда, пока самый крутой продукт в бете: www.parallels.com/products/parallels-containers-windows/
Первое достигается -model host или -model <одна из предефайненных моделей> в qemu.
Аргумент про этч принимается. 2.6.26 — это было легендарное ядро.
Это было не вчера, а несколько лет назад. И тогда у Xen'а действительно были проблемы с надёжностью.
Спасибо, интересный опыт.
А OpenVZ контейнеры на разных ФС в LVM сделать нельзя, это не решит проблему с очередью ФС?
А OpenVZ контейнеры на разных ФС в LVM сделать нельзя, это не решит проблему с очередью ФС?
В принципе, можно, конечно же. Но это довольно сложно поддерживать, так как придется делать следующее: lvcreate (создаем раздел), mkfs.ext4 (создаем на нем ФС), mount (монтируем). После этого через опцию ve_root у утилиты vzctl можно создать контейнер где душа пожелает.
В принципе, на первый взгляд это не так сложно, но на практике — надо будет потом менять размер ФС (как в сторону увеличения, так и в сторону уменьшения), выполнять проверки диска и многое другое. Технология ploop делает в своей сути тоже самое (чисто для себя ploop где-то рядом с LVM, но чуточку иной), но красиво и без привлечения сторонних утилит.
В принципе, на первый взгляд это не так сложно, но на практике — надо будет потом менять размер ФС (как в сторону увеличения, так и в сторону уменьшения), выполнять проверки диска и многое другое. Технология ploop делает в своей сути тоже самое (чисто для себя ploop где-то рядом с LVM, но чуточку иной), но красиво и без привлечения сторонних утилит.
Или берем xcp и даже не думаем об этом, все работает из коробки ;)
xcp больше нет, следующая версия для xcp 1.6 -> Xenserver 6.2. Он теперь опенсорсный, кроме нескольких проприентарных компонент, без которых он всё равно работает.
И если вы надеетесь, что оно «из коробки всё работает и надёжно и под хайлоадом» — разочарую. Его нужно много и тщательно окучивать.
И если вы надеетесь, что оно «из коробки всё работает и надёжно и под хайлоадом» — разочарую. Его нужно много и тщательно окучивать.
Ой далеко там все раньше было из коробки(ну или было но работало неожиданно), и много вы развернули xcp хотя бы на тысячу виртуалок?
В xcp 1.1, было практически все, что необходимо. XCP 1.6 добавили много нового/открыли, и стало все еще лучше. В xcp есть одна беда — это если очень активно использовать снапшоты, могут появиться проблемы. И да, баги есть везде. Да.
А что значит очень активно использовать? Ну скажем ежедневный бекап?
Желательно бы ещё и инкрементальный.
Желательно бы ещё и инкрементальный.
Если вы читали посты селектела, почему они отказались от снапшотов, там amarao рассказывал, какие есть проблемы. XCP очень плохо следит за зависимостями и связностью снапшотов, и из за этого возникают проблемы. Очень активно, это если постоянно восстаналиваться со снапшота и делать снапшот снапшота, очень часто и очень много. А так там есть cow.
Спасибо за подробный отчет!
Черт, а Амазон-то не знает! Надо бы рассказать. :) Чего-то мне слабо верится, что проблемы с дровами сетевой карточки — это именно проблемы XEN-а. Может, просто производитель заточил дрова под RHEL и всё?
P.S. Использую XEN с 3-й версии, проблемы были, но всё решаемо.
P.S. Использую XEN с 3-й версии, проблемы были, но всё решаемо.
Разумеется, все решаемо, но в те стародавние времена, к сожалению, у нас не было ресурсов для исправления проблем драйверов.
Но дабы быть совсем честными — в те времена Amazon услуги такой еще не предоставлял, это было где-то около 2005 года, а Amazon EC2 был тестово запущен лишь в 2006 году.
Но дабы быть совсем честными — в те времена Amazon услуги такой еще не предоставлял, это было где-то около 2005 года, а Amazon EC2 был тестово запущен лишь в 2006 году.
У амазона вообще не особо то и xen, они же его переписали более чем под себя. От ванильного ксена я думаю они довольно далеко.
Короче, PCS костыль ;) Вы смотрели, например XCP?
Почему костыль? PCS — это примерно тоже самое, что XCP, но не на базе Xen, а на базе OpenVZ ;)
PCS, совсем далеко до XCP, очень далеко. Особенно в свете того, что xenserver будет бесплатным. Посмотрите на список фич xenserver и список того, что предоставляет PCS.
Давайте будем конкретны :) Что умеет XCP и чего не умеет PCS?
Из ключевых фич PCS:
Лайв миграция
Бэкапы/инкрементальные бэкапы
Централизованное хранилище
HA
Что кроме этого умеет XCP, чего ен умеет PCS?
Из ключевых фич PCS:
Лайв миграция
Бэкапы/инкрементальные бэкапы
Централизованное хранилище
HA
Что кроме этого умеет XCP, чего ен умеет PCS?
Да хотя бы размещать файлы клиентов на lvm, а не в файле? Все ключивые фичи, которые вы указали, давно есть в xcp и проверено в xenserver. Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.
Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…
Так же, сама система виртуализации: нормальная vs расширенный чрут.
Вам openvz видимо нравится вот по этой причине:
?
Если уж оверселить, с той же памятью, можно например взять — www.redhat.com/products/cloud-computing/virtualization/, если я ничего не путаю, в kvm из коробки можно оверселить память. И это на нормальном гипервизоре.
Можно понять, когда люди используют контейнеры для разработки, такое может быть удобно. Но когда начинают использовать для предоставления массовых услуг, как-то не понятно эта мотивация.
Много времени прошло с debian 4, и выбирая сейчас, отталкиваться от совсем старого опыта, как-то странно.
Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…
Так же, сама система виртуализации: нормальная vs расширенный чрут.
Вам openvz видимо нравится вот по этой причине:
Плотность контейнеров получилась больше, чем на OpenVZ и других платформах
Экономим ОЗУ и дисковое пространство
?
Если уж оверселить, с той же памятью, можно например взять — www.redhat.com/products/cloud-computing/virtualization/, если я ничего не путаю, в kvm из коробки можно оверселить память. И это на нормальном гипервизоре.
Можно понять, когда люди используют контейнеры для разработки, такое может быть удобно. Но когда начинают использовать для предоставления массовых услуг, как-то не понятно эта мотивация.
Много времени прошло с debian 4, и выбирая сейчас, отталкиваться от совсем старого опыта, как-то странно.
«Да хотя бы размещать файлы клиентов на lvm, а не в файле» — прочтите про ploop openvz.org/Ploop, это не совсем «ФС в файле», это полноценный менеджер логических устройств поверх файлов.
«Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…» — я боюсь, что аналоги продукта Parallels Cloud Storage могут предложить разве что Google да Amazon да и-то в весьма ограниченном виде. Попробуйте, это реально круто, ничего общего с NFS и прочими SAN/NAS!
Ну оверселлить можно и в Xen и в KVM и даже на уровне железа и переносить недобросовестность оператора на технологию — совсем не хорошо :)
А Debian у нас нету давно на нодах, мы не отталкиваемся :)
«Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…» — я боюсь, что аналоги продукта Parallels Cloud Storage могут предложить разве что Google да Amazon да и-то в весьма ограниченном виде. Попробуйте, это реально круто, ничего общего с NFS и прочими SAN/NAS!
Ну оверселлить можно и в Xen и в KVM и даже на уровне железа и переносить недобросовестность оператора на технологию — совсем не хорошо :)
А Debian у нас нету давно на нодах, мы не отталкиваемся :)
Google да Amazon? Да и-то в весьма ограниченном виде? Это могло быть правдой лет 5 назад, но сейчас это полная, некомпетентная и беспросветная херня :) Распределенных отказоустойчивых СХД есть вагон и маленькая тележка. В качестве ликбеза почитайте здесь. Там распределенные СХД перечислены на любой вкус, отказоустойчивые и обыкновенные, свободные и проприетарные, платные и бесплатные, ядерные и юзерспейсные, с поддержкой QEMU/Xen и прочего.
Даже сильные мира сего при работе с _распределенными_ ФС зачастую либо покупают компании, которые их разрабатывали или перехватывают разработчиков и это не «для красивой строки в разделе о компании», а совершенно оправданная цена — сложность таких ФС зашкаливает и возможность их внедрения без наличия специалистов (я не говорю про людей, которые три раза ставили ее на «тестовой ферме» и прочли две публикации на хабре, а про тех, кто досконально знает, как и в каком случае поведет себя определенная ФС) — процесс крайне чреватый полной потерей данных.
Ну и да — прочтите уж тех спецификацию на Parallels Cloud Storage — www.parallels.com/products/pcs/cloud-storage/. Это не пиар, мы его пока не используем, но это реально крутое и очень технологичное решение.
Ну и да — прочтите уж тех спецификацию на Parallels Cloud Storage — www.parallels.com/products/pcs/cloud-storage/. Это не пиар, мы его пока не используем, но это реально крутое и очень технологичное решение.
Ну зачем переводить вопрос в плоскость стоимости внедрения. Было утверждение, что аналог могут предложить в ограниченном виде только Amazon и Google. Вот это утвеждение ложно. Прямо здесь на хабре есть примеры использования Ceph, GlusterFS, GPFS в том числе от уважаемых компаний. Это если говорить о кластерных СХД, не говоря про shared СХД, среди которых например Нексента и прочие. Как итог задачи миграции / снимки / избыточность уже решаются кучей разных продуктов, причем решаются уже сейчас, вот прямо на практике, в продакшене. В отличие от Parallels Cloud Storage, который непонятно использует ли кто-то вообще в продакшене или нет. Спецификация — это ок, но пока нет реальных деплойментов она, что называется, doesn't make sense. Так что это все таки пиар.
Безусловно, у этого продукта есть большое практическое преимущество — врожденная интеграция с контейнерами. Именно о нем и стоит писать, чтобы не получать негатив.
Безусловно, у этого продукта есть большое практическое преимущество — врожденная интеграция с контейнерами. Именно о нем и стоит писать, чтобы не получать негатив.
Как же не переходить в плоскость внедрения, если мы сейчас обсуждаем комментарии к статье про опыт реального внедрения? :)
Безусловно, Вы правы, что есть и иные подходы и иные продукты и множество компаний оказывающих поддержку, но из всего того что я видел — Parallels Storage по нашим тестам мне нравится больше всего.
В том и дело, что интеграция с контейнерами там лишь подфича, никто не запрещает создать на сторадже свой видео архив, например, правда, нужно учитывать, что это не Posix файловая система.
Обращаю внимание, что при желании на Parallels Storage можно запустить OpenVZ, например, или KVM (тут даже не потребуется правка драйверов).
Безусловно, Вы правы, что есть и иные подходы и иные продукты и множество компаний оказывающих поддержку, но из всего того что я видел — Parallels Storage по нашим тестам мне нравится больше всего.
В том и дело, что интеграция с контейнерами там лишь подфича, никто не запрещает создать на сторадже свой видео архив, например, правда, нужно учитывать, что это не Posix файловая система.
Обращаю внимание, что при желании на Parallels Storage можно запустить OpenVZ, например, или KVM (тут даже не потребуется правка драйверов).
Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.
В OpenVZ довольно грамотный CPU scheduler. При этом, если CPU limits не выставлены и больше никто ничего не делает, то почему бы и не полностью загрузить хост? Если хотите организовать вариант «собака на сене» (пусть лучше CPU будет простаивать, но виртуалке не давать больше N%) — пожалуйста, используйте CPU limits. В противном случае есть cpu units, когда у каждого контейнера (и у хоста) есть свой вес, и шедалер раздаёт всем кванты пропорционально их весам. Можно, конечно, использовать и units, и limits, плюс к тому vcpu (ограничение по кол-ву процессорных ядер) и cpu affinity (привязка конкретных контейнеров к конкретным ядрам). Мне кажется, это практически все варианты покрывает. Или вы что-то другое имели в виду?
«Централизованное хранилище» — не совсем корректный термин. Имеется в виду не NFS или там какой-нибудь SAN/NAS, а кластерная распределённая файловая система Parallels Cloud Storage, которая входит в состав Parallels Cloud Server. Её смысл вкратце такой — дисковое пространство всех нод сливается в один кластер, на котором и лежат контейнеры. Там, конечно, есть и избыточность, подобная RAID-ам, и локальность данных, и (что особенно важно) высокая скорость. Можно посмотреть доклад Кирилла Коротаева на YAC2012 — video.yandex.ru/users/ya-events/view/813/user-tag/yac%202012/
Так же, хочу извиниться, что влез в обсуждения, с такими комментариями, все же это не правильно.
Сколько из перечисленных фич уже работают у вас в продакшене? Вот чтобы прямо сейчас можно было прийти и воспользоваться.
Централизованное хранилище (Parallels Cloud Storage), живая миграция уже в строю?
Централизованное хранилище (Parallels Cloud Storage), живая миграция уже в строю?
Это все в строю уже по меньшей мере год. Вообще все и лайв миграция и клауд сторадж. А в последнем релизе месяц назад и поддержка HA приехала :)
А здесь вы пишете что еще не используете. Таки да или нет?
habrahabr.ru/company/parallels/blog/190524/#comment_6627942
habrahabr.ru/company/parallels/blog/190524/#comment_6627942
Хранилище мы не используем в продакшене, но у нас есть крупная тест-инсталляция с ним, которую мы уже почти месяц очень тщательно изучаем в разных ситуациях. Лайв миграция есть и с Parallels Storage и без него (ну и, к слову, она есть даже в openvz и очень даже неплохая), она работает в обоих случаях и уже используется нами (да — для клиентов, да — в продакшене).
А VMWare как вариант рассматривался?
Зря не используете в шейпере хэш-таблицы для фильтров.
А можно поподробнее? Можно в ЛС.
Там ничего особенного в целом. Но выигрыш в производительности может быть колоссальным. Грубо говоря, потребление процессора перестает зависеть от числа фильтров.
Первоисточник тут lartc.org/howto/lartc.adv-filter.hashing.html
Первоисточник тут lartc.org/howto/lartc.adv-filter.hashing.html
Спасибо, не слышал про такой вариант. Но как быть, когда у нас идут сплошняком IP из блоков 159.253.X.X и 5.9.X.X? Тут уже не похешируешь по последнему октету :(
В OpenVZ, насколько я понимаю, есть проблема при создании бэкапа со стороны пользователя. Я так и не разобрался, как его можно сделать. Хотелось бы что-то простое, типа
А в вашей системе виртуализации с этим как?
dd if=/dev/sda1 of=/backup.imgА в вашей системе виртуализации с этим как?
Проблемы в целом никакой нету, что в OpenVZ, что в PCS (что в ploop, что в vzfs). Конкретно у нас бэкап делается ежесуточно и доступен в панели управления.
«Со стороны пользователя» — это значит «внутри контейнера»? Если так, то при использовании OpenVZ на ploop dd if=/dev/sda1 of=/backup.img изнутри контейнера вы сделать сможете (только девайс будет называться /dev/ploopNNNp1), но проблема в том, что /backup.img будет лежать на том же девайсе.
Поэтому бекап нужно или лить сразу в сеть, или (что совсем правильно) делать снаружи, с хост системы (для чего провайдер даёт какой-нибудь интерфейс, а вообще нормальные провайдеры делают бекап сами и по вашему запросу его восстанавливают полностью или частично).
По поводу бекапа на openvz в целом. Если не использовать ploop (файловая система в файле), то с точки зрения хоста контейнер — это просто каталог (какой-нибудь /vz/private/12345), его и надо бекапить. Если использовать ploop, то можно сделать очень изящные инкрементальные бекапы на блочном уровне с использованием ploop snapshots. Кое-что на эту тему тут openvz.org/Ploop
Поэтому бекап нужно или лить сразу в сеть, или (что совсем правильно) делать снаружи, с хост системы (для чего провайдер даёт какой-нибудь интерфейс, а вообще нормальные провайдеры делают бекап сами и по вашему запросу его восстанавливают полностью или частично).
По поводу бекапа на openvz в целом. Если не использовать ploop (файловая система в файле), то с точки зрения хоста контейнер — это просто каталог (какой-нибудь /vz/private/12345), его и надо бекапить. Если использовать ploop, то можно сделать очень изящные инкрементальные бекапы на блочном уровне с использованием ploop snapshots. Кое-что на эту тему тут openvz.org/Ploop
Спасибо. К сожалению у меня это именно каталог:
Просто меня настолько удивила разница между VirtualBox'ом и VPS на основе OpenVZ(отсутствие /dev/sd* /dev/hd*),
что очень захотелось услышать, что в PCS — виртуальный жесткий диск выглядит именно как виртуальный жесткий диск)
/vz/private/3377 on / type simfs (rw,relatime,usrquota,grpquota)
Просто меня настолько удивила разница между VirtualBox'ом и VPS на основе OpenVZ(отсутствие /dev/sd* /dev/hd*),
что очень захотелось услышать, что в PCS — виртуальный жесткий диск выглядит именно как виртуальный жесткий диск)
На ploop это дело выглядит примерно вот так:
Но если быть полностью честным — это полноценная ФС лишь на уровне аппаратной ноды, из контейнера подкрутить настройки ext4 или, например, сделать рисайз (хотя бы в меньшую сторону) не выйдет.
Тоже самое касается бэкапа.
k001, а реально ли из контейнера получить доступ на чтение блочного имаджа или это на грани фантастики?
cat /proc/mounts
/dev/ploop38074p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0
Но если быть полностью честным — это полноценная ФС лишь на уровне аппаратной ноды, из контейнера подкрутить настройки ext4 или, например, сделать рисайз (хотя бы в меньшую сторону) не выйдет.
Тоже самое касается бэкапа.
k001, а реально ли из контейнера получить доступ на чтение блочного имаджа или это на грани фантастики?
а реально ли из контейнера получить доступ на чтение блочного имаджа или это на грани фантастики?
Да, как обычно, надо лишь дать доступ к девайсу:
# vzctl set 1011 --devnodes ploop53835p1:rw --save
Setting devices
CT configuration saved to /etc/vz/conf/1011.conf
# vzctl enter 1011
entered into CT 1011
# file /dev/ploop53835p1
/dev/ploop53835p1: block special
# dd if=/dev/ploop53835p1 of=/file bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.105055 s, 99.8 MB/s
# file /file
/file: Linux rev 1.0 ext4 filesystem data, UUID=9b82bff8-c625-4c63-b550-9efe561cf3e9 (needs journal recovery) (extents) (large files) (huge files)
К сожалению у меня это именно каталог:
Почему «к сожалению»? Каталог, в нём файлы, берите и делайте бекап, хоть таром, хоть рсинком.
Чтобы создать ploop контейнер:
# yum install ploop
# vzctl create 12345 --layout ploop
Чтобы всегда по умолчанию создавались ploop контейнеры, нужно прописать
VE_LAYOUT=ploop в /etc/vz/vz.conf
А кто-нибудь IB внутрь виртуалок пробрасывать научился? Вроде Xen-то умеет, но у меня стойкое подозрение что он всю карту в монопольное использование отхватывает, а мне интересно разделение ресурса.
Я ваш клиент, но почему-то не ощутил изменений.
В частности VNC найти не смог.
И да. У вас на сайте до сих пор старая информация по используемой технологии.
В частности VNC найти не смог.
И да. У вас на сайте до сих пор старая информация по используемой технологии.
VNC работать должен 100%, уточните номер услуги/тикета? Все решим обязательно.
Про технологию вся информация имеется прямо в самом заголовке: fastvps.ru/fast-private-servers/
А по поводу изменений — даже бэкапы не заметили в Power Panel? :)
Про технологию вся информация имеется прямо в самом заголовке: fastvps.ru/fast-private-servers/
А по поводу изменений — даже бэкапы не заметили в Power Panel? :)
опять реклама
А как себя ведет ploop когда пользователь меняет тариф (в частности, когда уменьшается доступное дисковое пространство)? И что происходит если у пользователя на момент уменьшения тарифа на диске было больше данных чем разрешено по новому тарифу?
О, а давайте замутим краткий мануал хав-ту по ploop?
- Чем вообще так крут ploop? Это быстрая миграция даже в случае миллионов файлов в контейнере! Это поддержка снапшотов и как следствие консистентного бэкапа. Возможность ресайза в любую сторону (уменьшение/увеличение).
- Сколько будет занимать диск моего контейнера, если я ему выделю 100 гб, но поставлю лишь чистую ОС? Занимать он будет около 600 мегабайт — вес чистой операцонной системы. Что будет если я скачаю 100 гб и удалю их сразу же? Образ контейнера будет занимать 100 гб, но посредством запуска утидиты vzctl compact (без остановки контейнера!) можно очень быстро привести размер образа к размеру файловой системы, что просто killer фича!
- Где хранятся все данные контейнера — в файле, в папке /vz/$CTID/private/
- Это raw (сырое) устройство, которое можно смонтировать через loop? Нет — используется собственный формат хранения и нужна поддержка в ядре
- Используется ли какая-либо специфическая файловая система или используется что-то свое? Используется проверенный временем ext4.
- Как осуществляется изменения размера файловой системы? Стандартными утилитами resize2fs
- Как осуществляется создание файловой системы? Стандартной утилитой mkfs.ext4
- На какой файловой системе могут размещаться образы виртульных машин? Гарантированно поддерживаются ext4 и Parallels Storage, по поводу остальных — нужно уточнять
- Что будет, если файловая система ext4 внутри контейнера попросит fsck? ploop проверить его автоматически и исправит все возможные проблемы
А вот еще добавочка:
- Что будет, если попытаться уменьшить размер жесткого диска контейнера до размера, который меньше общего количества данных внутри контейнера? Да ошибка будет и все, ничего не сотрется, ничего не потеряется :)
На какой файловой системе могут размещаться образы виртуальных машин? Гарантированно поддерживаются ext4 и Parallels Storage,
плюс ещё nfs3 (и nfs4 — в тестировании)
А nfs4 уже в контексте новой ветки ядра 3.X.X?
Так, я попутал поддержку NFSv4 внутри контейнера и для ploop. Ploop, если мне опять не изменяет память, работает поверх nfs — 3 или 4.
NFSv4 для контейнера уже есть, но выключена по дефолту, потому что недотестирована. From openvz.org/Download/kernel/rhel6-testing/042stab078.7/changes:
NFSv4 для контейнера уже есть, но выключена по дефолту, потому что недотестирована. From openvz.org/Download/kernel/rhel6-testing/042stab078.7/changes:
[nfs] NFSv4 support inside a CT has been added/corrected/enhanced, plus online migration of such CTs is supported now (PSBM-17798, PSBM-17795)
NOTE: NFSv4 inside CT is currently disabled by default, can be enabled via nfs4_ct_enable sysctl on the HN.
Sign up to leave a comment.
FastVPS: Как мы меняли платформы виртуализации