Comments 24
Очень интересный подход. Можно немного подробнее о времени перезагрузки и влиянии на него различных параметров системы?
У меня есть данные эксперимента.
Сервер (4xX5650 24Gb), 100 контейнеров (centos 6 x86_64).
Обычный ребут занимает 105 секунд (от момента запуска команды reboot, до момента входа по ssh), минимальный, максимальные, средний простой контейнеров: 194 сек, 833 сек, 290 сек.
Новый ребут занимает 30 сек, максимальный, минимальный, средний простой контейнеров: 70 сек, 72 сек, 70.3 сек.
Видно, что максимальное время простоя контейнера уменьшилось на порядок!
Сервер (4xX5650 24Gb), 100 контейнеров (centos 6 x86_64).
Обычный ребут занимает 105 секунд (от момента запуска команды reboot, до момента входа по ssh), минимальный, максимальные, средний простой контейнеров: 194 сек, 833 сек, 290 сек.
Новый ребут занимает 30 сек, максимальный, минимальный, средний простой контейнеров: 70 сек, 72 сек, 70.3 сек.
Видно, что максимальное время простоя контейнера уменьшилось на порядок!
Можно подробнее? Можно ли отследить изменения связанные с сохраняемыми данными, т.е. какие контейнеры сейчас уже заработали в текущей версии? Какие подсистемы сохраняют работоспособность без сбоев по результатам эксперимента?
С какими проблемами столкнулись?
Как-то мало информации для «сочувствующих» и, главное, без исходников.
И, конечно, огромное спасибо за работу!
С какими проблемами столкнулись?
Как-то мало информации для «сочувствующих» и, главное, без исходников.
И, конечно, огромное спасибо за работу!
Все подсистемы сохраняют свою работоспособность. Есть некоторые ограничения на контейнеры, но они связаны не с этой технологией, а с ограничениями по саспенду (suspend) контейнеров. Этих ограничений очень мало. Я даже сразу пример привести не могу. Может быть мы еще не умеет сохранять контейнеры с NFS сервером внутри.
Основная фишка этого подхода kexec и миграция контейнеров. Исходные кода обоих технологий открыты.
Задавайте конкретные вопросы, ответим.
Основная фишка этого подхода kexec и миграция контейнеров. Исходные кода обоих технологий открыты.
Задавайте конкретные вопросы, ответим.
Ещё раз перечитал. Тогда, немного, непонятно что сохраняется. Были же утилиты по профилированию загрузки, сохраняющие необходимый кеш...
У меня, довольно, частая проблема при использовании kexec — это потеря разрешения консоли, что-то от ядра недополучает драйвер nvidia (скорее-всего сброса питания / чистки памяти, т.к. считает горячую перезагрузку гибернацией), всё едет, хотя, ядро и драйвер считаю, что так и надо.
По аналогии. Например, будет проблема с контроллером raid из-за загрузки firmware нового, а контейнер будет хранить в буфере команды для старой версии.
Можно ли обработать подобную ситуацию или это, теперь, будет на откуп патче-писателям?
У меня, довольно, частая проблема при использовании kexec — это потеря разрешения консоли, что-то от ядра недополучает драйвер nvidia (скорее-всего сброса питания / чистки памяти, т.к. считает горячую перезагрузку гибернацией), всё едет, хотя, ядро и драйвер считаю, что так и надо.
По аналогии. Например, будет проблема с контроллером raid из-за загрузки firmware нового, а контейнер будет хранить в буфере команды для старой версии.
Можно ли обработать подобную ситуацию или это, теперь, будет на откуп патче-писателям?
Это проблемы драверов, они не всегда написаны качественно. Подобные проблему могут возникать и мы их предотвратить не можем. Будем решать по мере поступления.
Всё-таки это новый уровень технологий, надо предлагать какие-то инструменты для их быстрого и стандартного решения. Железячнику, совсем, не очевидно будет, что система должна работать с «горячей» перезагрузкой.
Очевидные пути — встраивать в ядро обработку коллизий, рядом с ioctl, или сортировать патчи и обвешивать скриптами проверки совместимости с kexec. Какой путь в parallels предпочитают?
Очевидные пути — встраивать в ядро обработку коллизий, рядом с ioctl, или сортировать патчи и обвешивать скриптами проверки совместимости с kexec. Какой путь в parallels предпочитают?
А для чего это в Cloud?
Что мешает смигрировать все контейнеры на другую ноду, отребутить ее и смигрировать назад.
На то же оно и облако чтобы это проблемой не было.
Что мешает смигрировать все контейнеры на другую ноду, отребутить ее и смигрировать назад.
На то же оно и облако чтобы это проблемой не было.
UFO just landed and posted this here
В идеальном мире все так, на деле не совсем. У большинства юзеров контейнеры и виртуалки не лежат на шареном сторедже и сеть у инх зачастую 1Gb и уже достаточно загружена, да и дисковая загрузка то же не в чести.
Теперь подсчитайте сколько по времени будут мигрировать контейнеры со ноды с количеством памяти в 128Гб и диском в несколько теробайт? Какую нагрузку они создадут на инфраструктуру? Может лучше даунтайм в 2-3 минуты?
Теперь подсчитайте сколько по времени будут мигрировать контейнеры со ноды с количеством памяти в 128Гб и диском в несколько теробайт? Какую нагрузку они создадут на инфраструктуру? Может лучше даунтайм в 2-3 минуты?
128Гб ОЗУ и говносеть в 1Гбит? Это шутка?
Сейчас 10Гбит Infiniband копейки стоит, а у нормальных облаков 40Гбит опорная сеть.
К тому же еще запулить сжатие на миграцию…
И выходит что намного быстрее и правильнее сделать миграцию и ребут.
Без левых приблуд в ядре.
Сейчас 10Гбит Infiniband копейки стоит, а у нормальных облаков 40Гбит опорная сеть.
К тому же еще запулить сжатие на миграцию…
И выходит что намного быстрее и правильнее сделать миграцию и ребут.
Без левых приблуд в ядре.
Повторю еще раз, на практике нормальных облаков не много. Приблуды в ядре получились очень маленькие, а профита дали достаточно. Я не понимаю о чем мы спорим. Миграция тоже есть, железо все поддерживается. Можно и не использовать все это, если ресурсы позволяют.
Я просто помню о том как реагировало сообщество на поделки Parallels, как на старые, так и на новые.
Потому и говорю о левых приблудах…
Потому и говорю о левых приблудах…
У меня есть совершенно обратное ощущение. За последний год компанией Parallels не мало было влито в ядро: развитие memory managmenta, контейнерезация NFS, checkpoint/restore, оптимизации, бак фиксинг. Отношение сообщества к нам дружеское. Обсуждаем, делаем свое дело. Иногда возникают недопонимания, но не больше чем у других. Все они быстро забываются и люди продолжают дальше работать.
ps: Двое работников Parallels вошли в 30 Linux developers: www.linux.com/news/special-feature/linux-developers
ps: Двое работников Parallels вошли в 30 Linux developers: www.linux.com/news/special-feature/linux-developers
Это рабочий процесс, нормальный рабочий процесс. Задачи ребята взяли сложные, вот и высказывали многие в сообществе (и Торвальдс, тоже) скепсис.
UFO just landed and posted this here
Подойдет всем, кто умеет делать снапшоты. Почему у вас возникло сомнение по поводу OpenVZ? В Parallels Cloud Server встроена продвинутая версия OpenVZ (Virtuozzo, Parallels Containers) и на ней уже сейчас все прекрасно работает. Когда я говорю контейнеры, то я имею ввиду именно то, что запускает OpenVZ;)
UFO just landed and posted this here
У ksplice, не смотря на недостатки, есть одно веское преимущество — это отсутствие простоя сервера. Его основная задача закрывать дырки безопасности, на больше он не претендует. Кроме того ничего не мешает использовать эти решения совместно.
Не пилит, а тесно интегрирует со своими продуктами. Да, сейчас нельзя пользоваться KSplice на RHEL/CentOS (хотя если вы купили подписку до покупки KSplice Oracle вы можете и дальше пользоваться им под RHEL/CentOS или же месяц теста с последующим предложением переехать на Oracle Linux). Но причина вполне понятна, Oracle выпускает свой дистрибутив (пытаясь откусить от редхата кусок их кастомеров) и 0-downtime апдейт одна из фич.
Я в свое время интересовался вопросом быстрой (теплой) перезагрузки Linux, но до сих пор ответа так и не нашел.
Sign up to leave a comment.
Обновляем ядро без перезагрузки