Мы отказываемся от размещения модулей ядра на 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 — она больше не нужна.