Системный программист
0,0
рейтинг
26 ноября 2012 в 09:30

Администрирование → Обновляем ядро без перезагрузки

Сегодня я хочу рассказать о моей самой любимой фиче в последнем релизе Parallels Cloud Server — rebootless update, или обновление без перезагрузки.

Перезагрузка — это простой сервера и потеря состояния текущих активностей. Она нежелательна для сервера, которым пользуется большое количество людей. На данный момент есть популярная технология Ksplice, где изменения накатываются на живую систему. Это ненадежно, не каждое обновление удается так накатить. И вообще, нет гарантий, что проблемный код не успел наследить. Еще одна немаловажная проблема в том, что разработчики с неохотой берутся за баги после таких обновлений. Кто его знает, что в этой солянке варилось.

Мы в Parallels подошли к проблеме с другой стороны и решили сделать все по-честному. По-честному — значит перезагрузить ядро, но так чтоб этого никто не заметил. Самый быстрый способ накатить новое ядро — воспользоваться kexec. Теперь вспомним, что и контейнеры, и виртуальные машины умеют сохранять свое состояние (suspend/resume, dump/restore, snapshot, etc). Таким образом если мы усыпим все виртуальные окружения, быстро перезагрузим ядро и восстановим окружения, пользователь заметит лишь небольшую задержку в обслуживании, которая будет похожа на проблемы сети. В первом приближении, так работает rebootless update.

Разработчики Parallels пошли дальше и существенно уменьшили время простоя виртуальных машин. В первую очередь была создана файловая система PramFS, похожая на tmpfs, но ее состояние сохраняется между перезагрузкой ядра через kexec. На эту файловую систему складываются состояния виртуальных машин и контейнеров. PramFS на несколько порядков быстрее диска, следовательно время сохранения и восстановления окружений существенно уменьшилось.

Сохранение состояния контейнера подразумевает сохранение всех его объектов (открытых файлов, сокетов, пайпов; таймеров; состояния процессов и т.д.) и пользовательской памяти. Следующий шаг оптимизации позволил оставить пользовательскую память и кэши файловых систем на том же месте, где они была до перезагрузки. Этот шаг так же позволил сократить время сохранения и восстановления контейнеров и сократить время простоя.

В итоге после такого обновления, на сервере загружается новое ядро без следов старого. Все объекты ядра создаются заново и их состояния восстанавливаются. Пользовательская память и кеши файловых систем остаются не тронутыми. Время перезагрузки сервера уменьшилось в несколько раз, по сравнению с обычной перезагрузкой.

На данный момент эта фича доступна только пользователям Parallels Cloud Server, но у нас есть планы предложить эту функциональность Linux-сообществу. А сохранение и восстановление состояния контейнеров будет реализовано в рамках проекта CRIU.

www.parallels.com/products/pcs
en.wikipedia.org/wiki/Kexec
en.wikipedia.org/wiki/Ksplice
criu.org/Main_Page
Вагин Андрей @avagin
карма
54,0
рейтинг 0,0
Системный программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (24)

  • +2
    Очень интересный подход. Можно немного подробнее о времени перезагрузки и влиянии на него различных параметров системы?
    • +2
      У меня есть данные эксперимента.

      Сервер (4xX5650 24Gb), 100 контейнеров (centos 6 x86_64).

      Обычный ребут занимает 105 секунд (от момента запуска команды reboot, до момента входа по ssh), минимальный, максимальные, средний простой контейнеров: 194 сек, 833 сек, 290 сек.

      Новый ребут занимает 30 сек, максимальный, минимальный, средний простой контейнеров: 70 сек, 72 сек, 70.3 сек.

      Видно, что максимальное время простоя контейнера уменьшилось на порядок!
      • 0
        Можно подробнее? Можно ли отследить изменения связанные с сохраняемыми данными, т.е. какие контейнеры сейчас уже заработали в текущей версии? Какие подсистемы сохраняют работоспособность без сбоев по результатам эксперимента?
        С какими проблемами столкнулись?
        Как-то мало информации для «сочувствующих» и, главное, без исходников.
        И, конечно, огромное спасибо за работу!
        • 0
          Все подсистемы сохраняют свою работоспособность. Есть некоторые ограничения на контейнеры, но они связаны не с этой технологией, а с ограничениями по саспенду (suspend) контейнеров. Этих ограничений очень мало. Я даже сразу пример привести не могу. Может быть мы еще не умеет сохранять контейнеры с NFS сервером внутри.

          Основная фишка этого подхода kexec и миграция контейнеров. Исходные кода обоих технологий открыты.

          Задавайте конкретные вопросы, ответим.
          • 0
            Ещё раз перечитал. Тогда, немного, непонятно что сохраняется. Были же утилиты по профилированию загрузки, сохраняющие необходимый кеш...
            У меня, довольно, частая проблема при использовании kexec — это потеря разрешения консоли, что-то от ядра недополучает драйвер nvidia (скорее-всего сброса питания / чистки памяти, т.к. считает горячую перезагрузку гибернацией), всё едет, хотя, ядро и драйвер считаю, что так и надо.
            По аналогии. Например, будет проблема с контроллером raid из-за загрузки firmware нового, а контейнер будет хранить в буфере команды для старой версии.
            Можно ли обработать подобную ситуацию или это, теперь, будет на откуп патче-писателям?
            • 0
              Это проблемы драверов, они не всегда написаны качественно. Подобные проблему могут возникать и мы их предотвратить не можем. Будем решать по мере поступления.
              • +1
                Всё-таки это новый уровень технологий, надо предлагать какие-то инструменты для их быстрого и стандартного решения. Железячнику, совсем, не очевидно будет, что система должна работать с «горячей» перезагрузкой.
                Очевидные пути — встраивать в ядро обработку коллизий, рядом с ioctl, или сортировать патчи и обвешивать скриптами проверки совместимости с kexec. Какой путь в parallels предпочитают?
                • 0
                  «Очевидные пути — встраивать в ядро обработку коллизий, рядом с ioctl» — расшифруйте подробнее, что вы тут имели ввиду.
                  Мы предпочитаем исправлять проблемы.
  • +1
    А для чего это в Cloud?
    Что мешает смигрировать все контейнеры на другую ноду, отребутить ее и смигрировать назад.
    На то же оно и облако чтобы это проблемой не было.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      В идеальном мире все так, на деле не совсем. У большинства юзеров контейнеры и виртуалки не лежат на шареном сторедже и сеть у инх зачастую 1Gb и уже достаточно загружена, да и дисковая загрузка то же не в чести.
      Теперь подсчитайте сколько по времени будут мигрировать контейнеры со ноды с количеством памяти в 128Гб и диском в несколько теробайт? Какую нагрузку они создадут на инфраструктуру? Может лучше даунтайм в 2-3 минуты?
      • +2
        128Гб ОЗУ и говносеть в 1Гбит? Это шутка?
        Сейчас 10Гбит Infiniband копейки стоит, а у нормальных облаков 40Гбит опорная сеть.
        К тому же еще запулить сжатие на миграцию…
        И выходит что намного быстрее и правильнее сделать миграцию и ребут.
        Без левых приблуд в ядре.
        • –1
          Повторю еще раз, на практике нормальных облаков не много. Приблуды в ядре получились очень маленькие, а профита дали достаточно. Я не понимаю о чем мы спорим. Миграция тоже есть, железо все поддерживается. Можно и не использовать все это, если ресурсы позволяют.
          • 0
            Я просто помню о том как реагировало сообщество на поделки Parallels, как на старые, так и на новые.
            Потому и говорю о левых приблудах…
            • +1
              У меня есть совершенно обратное ощущение. За последний год компанией Parallels не мало было влито в ядро: развитие memory managmenta, контейнерезация NFS, checkpoint/restore, оптимизации, бак фиксинг. Отношение сообщества к нам дружеское. Обсуждаем, делаем свое дело. Иногда возникают недопонимания, но не больше чем у других. Все они быстро забываются и люди продолжают дальше работать.

              ps: Двое работников Parallels вошли в 30 Linux developers: www.linux.com/news/special-feature/linux-developers
            • 0
              Это рабочий процесс, нормальный рабочий процесс. Задачи ребята взяли сложные, вот и высказывали многие в сообществе (и Торвальдс, тоже) скепсис.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Подойдет всем, кто умеет делать снапшоты. Почему у вас возникло сомнение по поводу OpenVZ? В Parallels Cloud Server встроена продвинутая версия OpenVZ (Virtuozzo, Parallels Containers) и на ней уже сейчас все прекрасно работает. Когда я говорю контейнеры, то я имею ввиду именно то, что запускает OpenVZ;)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      У ksplice, не смотря на недостатки, есть одно веское преимущество — это отсутствие простоя сервера. Его основная задача закрывать дырки безопасности, на больше он не претендует. Кроме того ничего не мешает использовать эти решения совместно.
    • 0
      Не пилит, а тесно интегрирует со своими продуктами. Да, сейчас нельзя пользоваться KSplice на RHEL/CentOS (хотя если вы купили подписку до покупки KSplice Oracle вы можете и дальше пользоваться им под RHEL/CentOS или же месяц теста с последующим предложением переехать на Oracle Linux). Но причина вполне понятна, Oracle выпускает свой дистрибутив (пытаясь откусить от редхата кусок их кастомеров) и 0-downtime апдейт одна из фич.
      • 0
        Это не так. Старые клиенты могут активировать новые лицензии ksplice на машины под управлением любой ОС. То есть привязка, фактически, не к дате покупки подписки, а к дате заведения аккаунта (когда речь идёт о неединичном заказе)
  • 0
    Я в свое время интересовался вопросом быстрой (теплой) перезагрузки Linux, но до сих пор ответа так и не нашел.
    • 0
      kexec?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.