company_banner

Отказ от NFS в облаке

    Извините за долгое молчание — много работы, грядут большие обновления. А пока немного о не очень крупном, но весьма заметном для наших клиентов изменении.

    Мы отказываемся от размещения модулей ядра на NFS. (И не только модулей, но клиенты заметят именно смену места хранения модулей).

    Как это должно было работать

    Виртуальные машины клиентов грузятся с использованием наших ядер (то есть код ядра хранится за пределами виртуальной машины). Ядрам нужны модули в процессе работы. /lib/modules подмонтирована по NFS, ядро само определяет из какого каталога грузить какие модули, нам легко их обновлять, клиенту легко получать доступ.

    Как это оказалось

    Во-первых, NFS-шары монтируются позже инициализации сети (это очевидно) и после монтирования всех остальных строчек в fstab. Ещё круче — в семействе debian/ubuntu они по-умолчанию монтируются асихнронно, так, что получается race condition с запуском rc.local.

    Итог: pre-up скрипты на интерфейсах работают не так, как ожидалось, нестандартные файловые системы из fstab не монтируются как положено. Дополнительно, NFS не самый надёжный сервис (особенно с учётом бага #538000), другими словами, неудобно.

    Как эту проблему решили

    Модули теперь находятся на ISO'шке, подключенной ко всем виртуальным машинам в виде отдельного диска /dev/xvdp. Модули монтируются сразу же после монтирования рута ('/') и позволяют легко выполнять все последующие операции (pre-up скрипты, нестандартные файловые системы и т.д.).

    Строчка монтирования (fstab) у всех выглядит одинаково:
    /dev/xvdp /lib/modules iso9660 ro 0 0
    

    Кстати, этот диск клиентами не оплачивается.

    Почему в read only?

    Во-первых, как было уже сказано, оно одно на всех. Совсем не хочется, чтобы ваш сосед подложил вам особую версию iptables, например. Во-вторых, модули (как и ядро) контролируется нашей системой управления. В ближайшее… ладно, в близкое будущее мы добавим возможность выбирать какое ядро использовать, но ядро будет из нашего списка. Причина проста — существует очень много не очень стабильных ядер под xen. Этим, например, страдает debian. Увы. Причём, часть багов будет видна далеко не сразу же — и нам очень хотелось избежать необходимости отвечать на вопросы о стабильности работы ядер, которые выбирали не мы. Паравиртуализация Xen'а подразумевает кооперацию ядра при выполнении многих операций (таких, как миграция) — и отказ от этой кооперации в середине процесса может приводить машину в нерабочее состояние. Так что ядра попадают в облако только после долгой и весьма занудной проверки на все возможные случаи использования.

    А свои модули можно грузить?

    Да, можно. Не смотря на то, что /lib/modules подмонтирован в readonly, загружать модули можно с помощью insmod из любого места. Единственное «но», ядра мы иногда обновляем, в этом случае обновляются и поставляемые нами модули. А вам придётся пересобирать модули самим. К счастью, обновления всегда явные и «случайно сломалось» не произойдёт.

    Почему iso9660?

    Это файловая система, использующаяся на CD (и ISO-образах) — для неё наиболее естественным является режим read only. Если бы мы использовали ext3, то возник бы соблазн перемонтировать в rw (этого нельзя было бы сделать и появилась бы куча ошибок). Вторая причина — iso9660 игнорируется инсталляторами ОС при установке (туда никто не попытается создать таблицу разделов).

    Как уйти от NFS к ISO

    Простой скрипт:

     sed -i /109.234.152.2/d /etc/fstab
     echo "/dev/xvdp /lib/modules iso9660 ro 0 0">>/etc/fstab
     umount /lib/modules
     mount /lib/modules
    


    Перезагрузка не требуется.

    На новых машинах модули монтируются уже именно так, как нужно.

    Разумеется, можно и не переходить, мы будем поддерживать текущую конфигурацию на NFS так долго, как потребуется (до последней машины с старой системой модулей). Те, кто перешёл на новую систему могут смело вырезать любые следы NFS — она больше не нужна.
    Selectel
    150,00
    ИТ-инфраструктура для бизнеса
    Поделиться публикацией

    Похожие публикации

    Комментарии 30

      0
      Очень логичный вариант. Только непонятно зачем вообще делать /lib/modules расшаренным. Если нужны только определенные ядра, можно же просто подкрутить инсталляторы debian/ubuntu/centos на эту тему.
        +1
        версия ядра меняется же после установки
          +3
          Я об этом думал. Если мы скопируем модули на клиентскую машину, то мы не сможем их обновлять синхронно с обоновлением ядра. Поскольку ядро находится в нашем ведении, логично, чтобы модули находились там же.
            0
            Ядро лежит в boot, который тоже подмонтирован и является общим?
              0
              Нет, ядро не лежит вообще в машине.

              Как работает любой xen? Программа по имени domain_builder создаёт домен, загружает туда содержимое, подключает устройства (то есть инициирует соответствующие программы в dom0), запускает.

              «Загружает содержимое» — это, собственно, и есть загрузка ядра (и initrd). Для этого domain_builder'у (который просто программа) нужно выдать файлы. Чаще всего для этого используется программа pygrub, которая подключает клиентский диск, читает menu.lst, скачивает в /tmp ядро и initrd. Процесс этот, мягко сказать, не самый надёжный и удобный. В нашем случае проще — мы указываем какие файлы ядра и initrd для какой машины грузить. Сами файлы хранятся вне машины (зачем нам хранить их в машине, когда удобнее хранить в собственной инфраструктуре?).
          +1
          Все найс, однако мне свои проекты с Селектела пришлось сдернуть по двум простым причинам:
          1. Пинг между инстансами нестабильный, иногда доходит до (sic!) 70 мс. При этом IP-адреса вроде в одной /24 подсети.
          2. Не совсем вина Селектела, но канал во внешний мир, в частности, в Азию — ужасающий. 10 КБ/сек — это еще хорошо.
          Вернулся на Хетцнер.
            +3
            Извините, можно я вам не поверю? У нас система мониторинга — и если узлы не отвечают за 10мс, то это повод написать мне в почту. Я такого не наблюдал. Если вы такое наблюдали, вас не затруднит описать условия воспроизведения?

            По поводу каналов в Азию — у нас нет прямых стыков с «Азией» (Кто такая вообще Азия, там как бы до Китая, Таджикистана и Японии маршруты несколько разные).
              +1
              Баланс уже отрицательный, так что сам проверить еще раз не могу. Условия простые — два инстанса: 46.182.30.230 и 46.182.30.229. Ubuntu Lucid Lynx (64). C 229 делаю ping 46.182.30.230.
                +1
                Я проверил. У меня 2 машины в их облаке, причем IP полностью разные. Но, думаю, что к расположению это отношения не имеет — все ВМ в одном ДЦ в Питере.

                83 packets transmitted, 83 received, 0% packet loss, time 82037ms
                rtt min/avg/max/mdev = 0.247/4.888/77.957/14.656
                  0
                  IP куда пинг был не скажете? Я про подобное первый раз слышу.
                    +1
                    Я скажу, но не хочу это делать здесь. Мне это вообще не существенно, а так как вам возможно будет полезно, создам тикет.
                      0
                      Спасибо
                    +2
                    Спасибо. Вот — максимум 78 мс. У меня динамические страницы должны за 10 мс отдаваться, а тут пяток запросов к мемкэшу могут полсекунды где-то в междумирье летать.
                      +1
                      Тоже самое…
                      44 packets transmitted, 44 received, 0% packet loss, time 43005ms
                      rtt min/avg/max/mdev = 0.222/6.354/101.308/19.316 ms
                +3
                что-то я не оценил скрытого наезда на debian…
                  +1
                  Он не скрытый. Багрепорт заслан, лежит незакрытый. Дебиановское -xen ядро — самое глючное, которое я видел в своей жизни.
                    +2
                    ядро отличное; это ксен — набор кривых патчей :)
                      0
                      думаю, что они будут ждать 2.6.40 =)
                    0
                    Приятное нововведение. Спасибо.
                    А планируется ли применение security патче к ядру? А то оно собрано еще прошлым летом, а ядерные сплойты, доступные публике, появляются достаточно часто.
                      +1
                      Перевод модулей на ISO запланирован был чуть позже, но пришлось ускорить. Управление ядрами (из клиентской панели) в ближайшее время будет.
                      0
                      Планируется ли поддержка чего-то отличного от семейства deb и centos?
                        +2
                        SUSE.

                        Потом будет do anything you want from scratches.
                        0
                        Как я понимаю, теперь открытые наружу сервисы portmap и prc.statd в Дебиане можно отключить?
                          +1
                          Если поменяли fstab, да, можно полностью выпиливать.
                          0
                          У меня сделано подключение модулей из squashfs-lzma образа на этапе инициализации initrd, до загрузки основной системы, которая находится в отдельном образе squashfs-lzma.

                          /cdrom/syslinux/2632v14rhel6ovz008.sq on /lib/modules type squashfs (ro,relatime)

                          Если необходимо добавить/удалить модули в образе, то для этого надо смонтировать aufs поверх squashfs-lzma, скопировать и пересоздать squashfs-lzma при помощи mksquashfs.

                          Ещё одним плюсом является сжатие в squashfs-lzma
                          14M /boot/2632v14rhel6ovz008.sq
                          46M /lib/modules/

                          С форматом iso9660 есть некоторые проблемы в именовании файлов/директорий. В последствии пришлось отказаться в пользу squashfs.
                            0
                            Мы используем rockride, имена, вроде бы, без проблем. Сжатие много не экономит — iso'шки примерно по 200-300Мб, там особо жать нечего. Про squashfs я думал, но оно менее «из коробки», а главное преимущество NFS по сравнению с ISO не возвращает (возможность «подкладывать» модули на ходу).

                            Кроме того, объявление VBD type=CD гарантирует, что инсталлятор не будет пытаться там таблицу разделов делать.
                            +2
                            Все это хорошо, но пока нет возможности менять размеры дисков облачных машин, нам у вас неинтересно :)
                              +2
                              Возможность есть, просто некоторым товарищам (не будем тыкать пальцами) очень нет времени докодить это в веб-панельке.

                              Постараемся в течение недели-двух дописать морду.
                              +1
                              Отличный подход, даже не к чему придраться! insmod, конечно, немного неудобен для клиента если много зависимостей, но, думаю, это мелочи.
                              Вообще, прочитал блог компании — много креативных творческих решений, мечта просто в такой работать. В список любимых)
                                0
                                спасибо.

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

                              Самое читаемое