«OpenVZ будет как-то мелковато — памяти-то много.» — А какие ограничения по памяти есть у OpenVZ?
«И то же самое можно сделать на OpenVZ (даже внутри LXC)» — это как? Я смогу внутри контейнера LXC запустить контейнер OpenVZ?
«Очевидные пути — встраивать в ядро обработку коллизий, рядом с ioctl» — расшифруйте подробнее, что вы тут имели ввиду.
Мы предпочитаем исправлять проблемы.
Это проблемы драверов, они не всегда написаны качественно. Подобные проблему могут возникать и мы их предотвратить не можем. Будем решать по мере поступления.
У меня есть совершенно обратное ощущение. За последний год компанией Parallels не мало было влито в ядро: развитие memory managmenta, контейнерезация NFS, checkpoint/restore, оптимизации, бак фиксинг. Отношение сообщества к нам дружеское. Обсуждаем, делаем свое дело. Иногда возникают недопонимания, но не больше чем у других. Все они быстро забываются и люди продолжают дальше работать.
Все подсистемы сохраняют свою работоспособность. Есть некоторые ограничения на контейнеры, но они связаны не с этой технологией, а с ограничениями по саспенду (suspend) контейнеров. Этих ограничений очень мало. Я даже сразу пример привести не могу. Может быть мы еще не умеет сохранять контейнеры с NFS сервером внутри.
Основная фишка этого подхода kexec и миграция контейнеров. Исходные кода обоих технологий открыты.
У ksplice, не смотря на недостатки, есть одно веское преимущество — это отсутствие простоя сервера. Его основная задача закрывать дырки безопасности, на больше он не претендует. Кроме того ничего не мешает использовать эти решения совместно.
Повторю еще раз, на практике нормальных облаков не много. Приблуды в ядре получились очень маленькие, а профита дали достаточно. Я не понимаю о чем мы спорим. Миграция тоже есть, железо все поддерживается. Можно и не использовать все это, если ресурсы позволяют.
Подойдет всем, кто умеет делать снапшоты. Почему у вас возникло сомнение по поводу OpenVZ? В Parallels Cloud Server встроена продвинутая версия OpenVZ (Virtuozzo, Parallels Containers) и на ней уже сейчас все прекрасно работает. Когда я говорю контейнеры, то я имею ввиду именно то, что запускает OpenVZ;)
В идеальном мире все так, на деле не совсем. У большинства юзеров контейнеры и виртуалки не лежат на шареном сторедже и сеть у инх зачастую 1Gb и уже достаточно загружена, да и дисковая загрузка то же не в чести.
Теперь подсчитайте сколько по времени будут мигрировать контейнеры со ноды с количеством памяти в 128Гб и диском в несколько теробайт? Какую нагрузку они создадут на инфраструктуру? Может лучше даунтайм в 2-3 минуты?
Обычный ребут занимает 105 секунд (от момента запуска команды reboot, до момента входа по ssh), минимальный, максимальные, средний простой контейнеров: 194 сек, 833 сек, 290 сек.
Новый ребут занимает 30 сек, максимальный, минимальный, средний простой контейнеров: 70 сек, 72 сек, 70.3 сек.
Видно, что максимальное время простоя контейнера уменьшилось на порядок!
Да, кстати, если действительно хочется понять принципы работы, то рекомендую книжку «Understanding the Linux Kernel, Third Edition», она есть в неплохом русском переводе.
>> Это означает, что соседний VPS, создав нагрузку на файловую систему большим количеством дисковых операций, создаст проблему и вызовет замедление работы вашего и всех остальных виртуальных серверов.
Эта проблема была решена и теперь OpenVZ работает с виртуальными дисками так же, как и виртуальные машины wiki.openvz.org/Ploop.
Сделать диски с изолированными файловыми системами можно было и раньше, просто по дефолту использовалась более гибкая схема. Никто не мешал нарезать диск девайсмапером и разместить каждый контейнер на своей файловой системе. Именно такую схему использует XEN.
>> Полный контроль над сокетами и процессами
Какой контроль над сокетами и процессами вам ограничен в OpenVZ?
>> Фактически, два единственных преимущества VPS на базе Virtuozzo это:
Вы забыли сказать про минимальные накладные расходы в OpenVZ, что позволяет сделать хостинг дешевле.
Виртуализация на базе гипервизора требует запуска новой ОС со своим ядром, которое съедает часть драгоценных ресурсов, за которые пользователь заплатил деньги.
Что касается цены, так это ключевой аргумент и именно он определяет лидерство контейнерной виртуализации, а вовсе не то что она была первой.
Пользователь хочет получить продукт, который удовлетворяет его запросам по минимальной цене. OpenVZ может удовлетворить более 90 процентов клиентов хостинг провайдеров, которым нужен сервер на Linux. Согласитесь, что свои модули нужно загружать очень ограниченному кругу лиц, свои ядра хотят грузить еще еще меньше людей.
Что на счет оверсейлинга, то это уже проблему вашего провайдера. Мы даем возможность оверсейлинга, а ваш провайдер решает использовать ее или нет. Если он ее будет использовать умно, то вы этого не заметите. К слову оверселинг есть во всех продуктах, кроме может быть XEN(по диску и памяти. По процессору есть у всех.).
>> Это гораздо более стабильная технология
Стабильное, потому что много разных ядер?
Я сам администрирую несколько интернет магазинов, один из них стоит на XEN вмке, и пара в OpenVZ и VZ контейнерах. Параметры серверов одинаковые, но бенчмарки и просто субъективные ощущения говорят, что OpenVZ контейнер работает быстрее. К слову его цена в полтора раза ниже. Делаем выводы.
Я понял о чем вы хотели сказать. Не думаю, что в «Фантоме» успели реализовать какие-то новые идеи. Ваш пример существует и используется в Virtuozzo во время живой миграции.
Да, чем-то напоминает, но в нашем случае нет возможности обновить приложение и потом его восстановить.
К слову 6 лет назад у нас уже была эта функциональность в OpenVZ. CRIU позволит избавиться от своего кода в OpenVZ ядре, который нам сейчас приходится поддерживать. В свою очередь это даст нам возможность сделать что-то новое.
Что значит немного другое дерево? В каждой системе дерево свое.
Есть проблема с изоляцией приложений. Мы сохраняем и восстанавливаем только те процессы, которые попросил пользователь. Проблема в том, что процессы могут быть связаны между собой и иметь некий двусторонний внутренний стейт, который зависит от логики приложения. В этом случае, если мы сохраним только одну сторону и потом ее восстановим, то формальная связь (unix сокет, fifo) будет восстановлена, но мы ничего не знаем о внутреннем состоянии.
Сохранение и восстановление контейнера целиком, гарантирует что мы собрали все зависимости и с большой вероятностью сможем его восстановить на другой системе.
Программа будет работать как раньше, никаких лишних segfault-ов быть не должно. Если файл будет удален, то его содержимое будет сохранено и на ресторе файл будет восстановлен, открыт и снова удален. С закрытым сокетом проблем еще меньше, достаточно на восстановлении создать сокет и закрыть его. С мьютексом проблемы совсем нет, его состояние хранится в памяти, а она восстанавливается.
Предупрежу дальнейшие вопросы. Мы не просто приоткрываемым сокеты, пайпы и т д, но и восстанавливаем их состояния. Для каждого объекта свой подход. Сначала мы стараемся использовать существующие механизмы, если не получается добавляем новые интерфейсы в ядро.
«И то же самое можно сделать на OpenVZ (даже внутри LXC)» — это как? Я смогу внутри контейнера LXC запустить контейнер OpenVZ?
Мы предпочитаем исправлять проблемы.
ps: Двое работников Parallels вошли в 30 Linux developers: www.linux.com/news/special-feature/linux-developers
Основная фишка этого подхода kexec и миграция контейнеров. Исходные кода обоих технологий открыты.
Задавайте конкретные вопросы, ответим.
Теперь подсчитайте сколько по времени будут мигрировать контейнеры со ноды с количеством памяти в 128Гб и диском в несколько теробайт? Какую нагрузку они создадут на инфраструктуру? Может лучше даунтайм в 2-3 минуты?
Сервер (4xX5650 24Gb), 100 контейнеров (centos 6 x86_64).
Обычный ребут занимает 105 секунд (от момента запуска команды reboot, до момента входа по ssh), минимальный, максимальные, средний простой контейнеров: 194 сек, 833 сек, 290 сек.
Новый ребут занимает 30 сек, максимальный, минимальный, средний простой контейнеров: 70 сек, 72 сек, 70.3 сек.
Видно, что максимальное время простоя контейнера уменьшилось на порядок!
vim '+:ts sys_mkdir'
На самом деле очень жаль, что подобные вещи постят на хабре и они собирют столько голосов.
Эта проблема была решена и теперь OpenVZ работает с виртуальными дисками так же, как и виртуальные машины wiki.openvz.org/Ploop.
Сделать диски с изолированными файловыми системами можно было и раньше, просто по дефолту использовалась более гибкая схема. Никто не мешал нарезать диск девайсмапером и разместить каждый контейнер на своей файловой системе. Именно такую схему использует XEN.
>> Полный контроль над сокетами и процессами
Какой контроль над сокетами и процессами вам ограничен в OpenVZ?
>> Фактически, два единственных преимущества VPS на базе Virtuozzo это:
Вы забыли сказать про минимальные накладные расходы в OpenVZ, что позволяет сделать хостинг дешевле.
Виртуализация на базе гипервизора требует запуска новой ОС со своим ядром, которое съедает часть драгоценных ресурсов, за которые пользователь заплатил деньги.
Что касается цены, так это ключевой аргумент и именно он определяет лидерство контейнерной виртуализации, а вовсе не то что она была первой.
Пользователь хочет получить продукт, который удовлетворяет его запросам по минимальной цене. OpenVZ может удовлетворить более 90 процентов клиентов хостинг провайдеров, которым нужен сервер на Linux. Согласитесь, что свои модули нужно загружать очень ограниченному кругу лиц, свои ядра хотят грузить еще еще меньше людей.
Что на счет оверсейлинга, то это уже проблему вашего провайдера. Мы даем возможность оверсейлинга, а ваш провайдер решает использовать ее или нет. Если он ее будет использовать умно, то вы этого не заметите. К слову оверселинг есть во всех продуктах, кроме может быть XEN(по диску и памяти. По процессору есть у всех.).
>> Это гораздо более стабильная технология
Стабильное, потому что много разных ядер?
Я сам администрирую несколько интернет магазинов, один из них стоит на XEN вмке, и пара в OpenVZ и VZ контейнерах. Параметры серверов одинаковые, но бенчмарки и просто субъективные ощущения говорят, что OpenVZ контейнер работает быстрее. К слову его цена в полтора раза ниже. Делаем выводы.
К слову 6 лет назад у нас уже была эта функциональность в OpenVZ. CRIU позволит избавиться от своего кода в OpenVZ ядре, который нам сейчас приходится поддерживать. В свою очередь это даст нам возможность сделать что-то новое.
Есть проблема с изоляцией приложений. Мы сохраняем и восстанавливаем только те процессы, которые попросил пользователь. Проблема в том, что процессы могут быть связаны между собой и иметь некий двусторонний внутренний стейт, который зависит от логики приложения. В этом случае, если мы сохраним только одну сторону и потом ее восстановим, то формальная связь (unix сокет, fifo) будет восстановлена, но мы ничего не знаем о внутреннем состоянии.
Сохранение и восстановление контейнера целиком, гарантирует что мы собрали все зависимости и с большой вероятностью сможем его восстановить на другой системе.
Предупрежу дальнейшие вопросы. Мы не просто приоткрываемым сокеты, пайпы и т д, но и восстанавливаем их состояния. Для каждого объекта свой подход. Сначала мы стараемся использовать существующие механизмы, если не получается добавляем новые интерфейсы в ядро.