Отказ от 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 — она больше не нужна.