Comments 20
В Windows Server драйверы все еще монтируются в виртуальную машину во время установки
А зачем? Почему не интеграция в образ?
Предполагаю, что вы имеете в виду DISM, как способ доставки драйверов в образ. Способ хороший, но у него есть особенность - для его использования нужна Windows, а у нас в инфраструктуре она не используется. Вместо этого, мы монтируем каталог с драйверами в виртуальную машину, и добавляем в unattend.xml использование модуля Microsoft-Windows-PnpCustomizationsNonWinPE.
Зачем такой сложный путь, если в ironic изначально все это есть? У вас все перемешалось. Посмотрите внимательнее ironic state machine и что на каком этапе происходит.
Решение с ironic не проще. В ironic изначально нет возможности управлять рейд и хба контроллерами, например. Уверен, что там с горку наберется и других железоспецифичных проблем. Тем более это решение для клиентских услуг, а не для внутренних, а значит и железо должно поддерживаться от разных вендоров.
Про рейды прям точно? https://docs.openstack.org/ironic/latest/admin/raid.html
Залез специально в код python-ironic, чтобы проверить еще раз. Не вижу там упоминания ни arcconf, ни megacli для работы с рейд и хба контроллерами. Да, mdadm поддерживается, но это не то, что нужно.
Можно погуглить, есть патч.
Дописали бы кусок и поделись с сообществом.
Весь ваш флоу есть в ironic, зачем переизбрать велосипед?
Из вашей статьи совершенно непонятно, что вы поизучали и пришли к тому нет ничего близко похожего, и вот оно ваше уникальное решение.
Я не писал статью и в этой компании не работаю :)
Сетап и конфигурация железа - это лишь капля в море. Все-таки главная проблема заключается в интеграции айроника в текущие процессы и инфраструктуру. Тут либо изначально надо было поверх айроника все строить, либо с болью переходить на него и переводить на него все процессы. И если это возможно в маленьких проектах, то в больших - вы и сами понимаете. Под процессами я имею в виду, как минимум, биллинг и менеджмент. Практический пример - научить идентифицировать каждый конкретный сервер, чтобы управлять его статусом, когда биллинг уже имеет вагон своих сущностей, с которыми работает, а айроник ожидает других и работает со своими. Два разных мира, которые надо подружить. В общем, я к тому, чтобы пришлось бы сильно модифицировать айроник. Да и для сообщества ценности это не несет, так как написано для конкретной компании.
Мне нравится путь Equinux. Но они пошли еще дальше. Написали и свой dhcp, и образ загрузочный, и тулзы для сборки установочных образов для клиентов - там куча всего. И конкретно в их системе это работает прекрасно. Тут же нечто похожее.
А в вакууме (или если решать задачу с нуля) - тут, да, ironic будет хорошим решением. Может быть даже сам хотел бы сделать именно так, но, увы, нужно помнить и о наследстве.
Ironic не поддерживает разное железо? Только 1 шт волшебной спецификации?
Хотелось бы более подробнее также услышать о Ваших тестов ОС, это какие-то скрипты или же все ручками и что в него входит?
Я коротко описал это в статье, используем Ansible, inventory которого автоматически генерируем, используя API. Проверяем разметку дисков(соответствует ли нашей разметке по-умолчанию), пароль, доставку SSH-ключей, пакетные зеркала, список установленных пакетов, версию ОС, список пользователей с интерактивными сессиями. Сейчас проверяем сами, глазами, экспортируя лог выполнения Ansible на серверах в артефакты GitLab. Скорее всего в будущем будем автоматизировать и этот этап.
Интегрированы ли какие либо предварительные тесты железа перед установкой OS?
Именно перед установкой мы только проверяем что железо в сервере фактически соответствует тому, что у нас записано в БД бэкэнда. После сборки сервера(но перед его передачей в пул доступных для клиентов) мы проводим подробное тестирование комплектующих, включая стресс-тесты ЦП/ГП, тесты памяти, температурные тесты и тесты дисков(SMART, скорость чтения/записи). Между арендами проверяем SMART'ы дисков, версии прошивок устройств и коротким стресс-тестом(около 10 минут) проверяем процессоры на перегрев/тротлинг.
32 ГБ для Windows Server
Как вы такой большой образ винды умудрились сделать???
На самом деле хороший вопрос, но честно говоря - я уже не помню :) Посмотрел сейчас, упакованный gzip образ занимает 6.6ГБ. Вероятно, раньше мы его не так сильно сжимали, либо из-за того, что складывали его в память + накладные расходы на сервисную ОС и у нас получилось больше 16ГБ, поэтому в требования написали 32ГБ.
Наверное кидали его в /dev/shm )
Вот кстати, хотелось бы отметить, что образы не только винды получаются жирными, мы даже сами писали удаление мусорных пакетов, которые не входят в стандартную поставку ОС. Тот же минимальный образ Ubuntu 22.04 в Hetzner содержит намного меньше лишних пакетов.
Ну и все еще вопросики к разметке дисков, ESP в конце до сих пор не поправили.
Device Start End Sectors Size Type
/dev/sda1 2048 1953791 1951744 953M Linux filesystem
/dev/sda2 1953792 11718655 9764864 4.7G Linux filesystem
/dev/sda3 11718656 935544831 923826176 440.5G Linux filesystem
/dev/sda4 935544832 935739391 194560 95M EFI System
/dev/sda5 935739392 935933951 194560 95M Linux filesystem
Верно ли я понимаю, что Win это клон системы с одним и тем же кодом продукта и другими данными которые сохраняются при клонировании?
Я, как почти обычный пользователь, люблю почитать подобные истории, обычно они интересны. Но в данном случае, прям со вступления ожидал, что итогом станет, вместо долгой и правильной установки, сквозь все шаги - накатывание образа. Как мы, почти обычные пользователи вин и делаем, года эдак с 2012, как появились удобные автозагрузочные акронисы. Делаем образ системы сор всеми необходимыми драйверами и софтом и быстро накатываем, особенно когда куча однотипных компов с одними и теми же задачами.
Увы в этот раз разочарован и не удивлён. Могу понять печаль разномастного железа с 100500 конфигураций и доп опций.
Я приверженец разумного ограничения выбора. Считаю вредным 25-50 вариантов, когда самыми ходовыми являются 3-4, а покрывающими 90% 7-8. Больше - спец опции со спец ценником и ручной работой и проверкой.
Ярый противник стрельбы себе в ногу и героического решения созданной проблемы. Текущая статья напоминает именно такое геройстование и превозмогание.
Старое железо и отсуствие драйверов, особенно для сетевых карт, для изначально сетевой системы, такой как Линукс - для меня звучит как дикая дичь и опять таки стрельба себе в ногу, когда из ядра не выпиливается совместимость с i486. Мне казалось это из Мелкософта несовместимость драйверов в старших системах принудительный отказ от совместимости и поддержки.
Основная причина медленной установки Debian/Ubuntu в медленной распаковке пакетов, вызванной чрезмерно частыми вызовами fsync().
Это можно отключить с помощью eatmydata.
https://www.linux.org.ru/news/debian/16195513
https://bitbucket.org/ValdikSS/debian-iso-fastinstall/src/master/
Вторая причина — .deb-пакеты в Debian сжаты lzma (xz), и распаковываются не только долго, но еще и в один поток. Современные версии Ubuntu используют zstd с многопотоковым распаковщиком, но не Debian. Исправить можно кастомным dpkg, запускающим pixz отдельным процессом, но решение не идеальное.
Как мы ускорили автоустановку ОС в четыре раза