Comments 25
Аж слюни потекли.
Обязательно пощупаю на виртуальных машинах. Насчет поддержки Debian/Ubuntu — очень актуально. Многие не используют RHEL и его производные.
Тоже надо будет попробовать. Действительно это актуальная проблема. В OpenStack при использовании Fuel тоже идет раворачивание с образа, но без торента.
Мне часто хочется плакать от опренстека и как там все сделано. :)
Была идея впилить это все в опенстек и разворачивать qcow2 образ вместо тарбола, но это довольно накладно — запихать распаковщик в initrd образ.
Была идея впилить это все в опенстек и разворачивать qcow2 образ вместо тарбола, но это довольно накладно — запихать распаковщик в initrd образ.
Если я правильно понял. Fuel разливает образы а потом накатывает паппетовые конфиги. Не сильно большой шаг вперед по сравнению с xCAT. В том место паппета — баш скрипты. Представим что нам надо поставить 100 нод. Каждая из них сначала стянет образ а потом будет долго и печально ставить все с помощью apt/yum. А если еще и перезагрузка для нового ядра требуется? А если драйвера поставить для нового ядра и еще одна перезагрузка?
Luna сразу позволяет создать образ со всем необходимым на берегу и накатить на ноду. Приблизительно, как если бы разворачивали ноду из бекапа.
Luna сразу позволяет создать образ со всем необходимым на берегу и накатить на ноду. Приблизительно, как если бы разворачивали ноду из бекапа.
Там проблема в вариативности. Есть 10 ролей для ноды, соответственно набор пакетов разный. Именно этот набор и ставится с помощью папет. А база раскатывается с образа.
Да, принято. Когда для каждой ноды свой набор пакетов — не очень логично держать 10 практически идентичных образов. Но в общем-то и луне никто не запрещает раскатать базу и сверху заполировать паппетом или анзиблем :)
Причем за «базу» можно взять образ со всеми возможными пакетами — это не скажется на скорости установки, только на используемом месте. А паппет только включит нужные.
Причем за «базу» можно взять образ со всеми возможными пакетами — это не скажется на скорости установки, только на используемом месте. А паппет только включит нужные.
Fuel генерит один образ(архив) и потом его раварачивает на ноде, а папет ставит недостающие пакеты, да и это большой минус что во Fuel`е не прикрутили торрент ибо PXE сервер слушает обычно на 1Г интерфейсе в админ сети и на бОльшом энве провижион(раскатка образа) нод занимает достаточное время.
На мой bashizm похоже. Только я для тестирования OS в KVM это использую.https://github.com/kayrus/deploy-vm
А для деплоя серверов пока только такой костыль с initramfs: https://github.com/kayrus/rescue-initramfs
Есть такие хостинги, которые за переустановку OS берут бабло и не поддерживают некоторые дистрибутивы. Вот и приходится выкручиваться.
Есть вот такой замечательный проект
Что мешает использовать ansible для pre/post скриптов?
>Однажды, инсталлируя очередной кластер с помощью xCAT и фрустрируя на бесконечные пост-скрипты на баше возникло жгучее желание написать свое и лучше.
https://github.com/xcat2/xcat-core/commit/471d9471716c0010612599487cd0814828652e7a
>Идею с торрентом мне подкинул один из заказчиков из Швеции.
>Однажды, инсталлируя очередной кластер с помощью xCAT и фрустрируя на бесконечные пост-скрипты на баше возникло жгучее желание написать свое и лучше.
https://github.com/xcat2/xcat-core/commit/471d9471716c0010612599487cd0814828652e7a
>Идею с торрентом мне подкинул один из заказчиков из Швеции.
Что мешает использовать ansible для pre/post скриптов?
Надо тащить питон в initrd. Тогда он будет не 50 мегабайт как сейчас а 300, как инсталлятор анаконды.
https://github.com/xcat2/xcat-core/commit/471d9471716c0010612599487cd0814828652e7a
Я видел этот коммит, но уже после того как начал копать в эту сторону.
Но ребята из xcat почему-то не сказали где должен находится торрент-трекер и как его интегрировать. По сути они просто добавили еще один бинарь в initrd без интеграции с остальным xcat-ом. Точнее даже не добавили а «дали возможность добавить». Даже документации нет.
Open Source.
>Точнее даже не добавили а «дали возможность добавить». Даже документации нет.
>Точнее даже не добавили а «дали возможность добавить». Даже документации нет.
Ну да. xCAT сам по себе не плох если у тебя один кластер и ты каждыйы день его видишь. Ты знаешь где какие скрипты у тебя лежат. Где что запускается и откуда вызывается. Но когда у тебя новый кластер каждый месяц и еще порядка 50 на поддержке это превращается в ад. Тут и там какие-то грязные хаки, недетерминированность и код на баше, перле, питоне и авке, причем в одном файле. Это все инсталлируется разными инженерами с разным уровнем опыта и видением «как правильно». Даже когда ты заглядываешь в свой код годовой давности хочется делать рука-лицо, а тут еще и умножается.
«Во-вторых, заказчик может позволить включать ноды только когда для них есть работа»
Богатые у Вас заказчики, видимо. Обычно при включении-выключении выходит из строя некоторый процент нод, потому стараются питанием не баловаться без совсем уж крайней необходимости. Даже в S3.
То же самое с дисками — Яндекс на Хабре давал оценку в 10-15% выхода дисков из строя при сбое питания, хотя, конечно, разум с трудом принимает эту цифру
Богатые у Вас заказчики, видимо. Обычно при включении-выключении выходит из строя некоторый процент нод, потому стараются питанием не баловаться без совсем уж крайней необходимости. Даже в S3.
То же самое с дисками — Яндекс на Хабре давал оценку в 10-15% выхода дисков из строя при сбое питания, хотя, конечно, разум с трудом принимает эту цифру
Ну я лично тоже не сильно в восторге от идеи включения/выключения нод. Но во-первых на больших кластерах бывает так что вот прямо в конкретный момент не нужны все ноды и дешевле держать ЗИП, чем жечь электричество, а во-вторых дисков там часто просто нет — рамдиск. Спасибо образу операционки — не надо ничего ставить дополнительно, развернул и в бой. Ну и в-третьих, кто я такой, что бы указывать заказчику, что ему делать с его железом :)
что ему делать с его железом
Которое, к тому же и на гарантии, прошу заметить. Сгорела нода? Запросим у вендора новую и вышлем почтой.
Ну да, а тебе надо деплоить сегодня, а не ждать когда доставят/смонтируют/скомутируют
Я говорю об HPC. Если речь идет о выключениях то это обычно кластер от 100 нод. Обычно — около 500 Выход из строя пары-тройки год вообще не проблема. Ну уменьшит пользователь количество MPI ранков — ничего страшного. Применительно к более приземления вещам это могут быть, я не знаю, аппликейшн-сервера в новогодний период. Если у тебя их сотни, при выходе одного из строя на оставшиеся возрастет нагрузка. Но, честно говоря, в этих ваших деплоях вообще не специалист. Но очевидно, что если пара серверов — это проблема, не стоит использовать эту фичу :)
Всегда хотел поработать с HPC. Работа с чистой математикой как-то повышает самооценку. А кто заказщики? Банки? Можно, так сказать, обзор примерный обзор рынка?
Могу сказать, что с моей стороны математики не сильно много. Я занимаюсь системными вещами и иногда перфомансом. «Выше» по стеку находится MPI (тоже моя тема часто, как минимум знать как запускать) и математические библиотеки: BLAS, MLK. Еще выше сидит уже софт заказчиков — здесь и начинается матан. Это уже их сфера ответственности. Заказчики, как правило, универы. Чистая наука: физика, биомед, геофизика, погода. Они разрабатывают алгоритмы и гоняют на этих кластерах.
Скажите, Дмитрий, в Luna только утилиты командной строки, или есть и Web-API? И второй вопрос в догонку: нет ли наработок по docker'изации Luna (да, я знаю, что там DHCP/BOOTP/TFTP)?
Спасибо.
Спасибо.
Sign up to leave a comment.
Luna. Высокоскоростная установка операционных систем