Комментарии 31
Да это прямо сказка какая-то!
Так скоро Windows грузанём вручную :D
Так скоро Windows грузанём вручную :D
Без проблем. Вам нужно найти паравиртуализированное ядро windows. Такое в природе есть, т.к. в своё время Xensource проводил совместный эксперимент с Microsoft. К сожалению, Microsoft не согласилась с публичным релизом этого ядра. А так — без проблем.
(hint: если windows выглядит как фантастика, то подружить freebsd и grub — выглядит уже более реалистично).
(hint: если windows выглядит как фантастика, то подружить freebsd и grub — выглядит уже более реалистично).
Вы же писали, что для миграции машин в облаке нужна адекватная поддержка со стороны гостевого ядра, а потому возможности загрузки своих ядер не будет.
Вам же написали /… является максимальная свобода администратора при работе с облачной машиной./
Такая концепция мне нравится больше.
Такая концепция мне нравится больше.
Человек правильно говорит, действительно, одно время у нас была проблема с дефолтными ядрами дебиана (легендарное 2.6.26, у которого вики-страница на 20 листов испещрена описаниями багов и workaround'ов). На тот момент мы обсуждали проблему, и решили, что проще всего запретить пользователю грузить что-то, кроме нашего ядра (проще всего нам). Практика показала, что людям это не всегда удобно, иногда нужно собрать ядерные модули (flashcache, drbd, iscsi и т.д.) или использовать какие-то специфичные ситуации, когда требуется изменить ядро.
Тогда родилась новая концепция — разрешить пользователю стрелять себе в ногу (но обеспечить логгирование порядка выстрела для дальнейшего выяснения кто виноват). Вот в эту сторону мы и движемся.
Собственно, до достижения финала нам осталось только реализовать bootcd с возможностью собрать свой LFS (или просто починить капитально сломанную систему) — и оно есть в планах (не самых близких, увы).
Тогда родилась новая концепция — разрешить пользователю стрелять себе в ногу (но обеспечить логгирование порядка выстрела для дальнейшего выяснения кто виноват). Вот в эту сторону мы и движемся.
Собственно, до достижения финала нам осталось только реализовать bootcd с возможностью собрать свой LFS (или просто починить капитально сломанную систему) — и оно есть в планах (не самых близких, увы).
Мы решили дать свободу стрелять себе в ногу. Если клиент загружает «непонятно что», собранное вручную с своими патчами и настройками, и это не поддерживает саспенд при миграции, то клиент получает странные зависания при LB и ответ саппорта «используйте ядро по-умолчанию». А уж какое ядро клиент загрузил, мы можем 100% узнать — у нас специальные патчи для определения реального загружаемого ядра и смухлевать не получится.
Тогда хотелось бы получить «эталонные» конфиг и сырцы ядра, гарантированно работающие в вашем облаке.
Эталонный конфиг: /boot/config*
Эталонные сырцы: мы используем ядро из OpenSUSE (за вычетом центос5, у которого своё нормальное -xen ядро) — это rpm'ка с сырцами, она есть в репозиториях openSuse. Конфиг их, патчи их.
Прямую ссылку искать лениво, саппорт обучен в тикетах её давать по первому запросу.
Эталонные сырцы: мы используем ядро из OpenSUSE (за вычетом центос5, у которого своё нормальное -xen ядро) — это rpm'ка с сырцами, она есть в репозиториях openSuse. Конфиг их, патчи их.
Прямую ссылку искать лениво, саппорт обучен в тикетах её давать по первому запросу.
Я слышал, что вы собираетесь в неизвестном будущем вводить новый пул, где можно будет размещать виртуальные машины гарантированно на физически разных серверах. Есть новости по этой фиче?
НЛО прилетело и опубликовало эту надпись здесь
В опциях ядра можно поставить чужой корневой раздел?
Можно. Ядро запустится, попытается подмонтировать корневой раздел, который вы передали. Дальше вопрос в том, будет ли у вас этот раздел на подключенных дисках или нет.
Упреждая вопрос: нет, подключить чужой диск вы не можете.
Паравиртуализация подразумевает, что гость сам обживается в виртуальной среде как хочет (может). Эти строчки — всего лишь параметры командной строки для ELF-файла у программы по имени 'linux'. Эта программа первой загружается в домен и может делать там что захочет. В пределах домена.
Упреждая вопрос: нет, подключить чужой диск вы не можете.
Паравиртуализация подразумевает, что гость сам обживается в виртуальной среде как хочет (может). Эти строчки — всего лишь параметры командной строки для ELF-файла у программы по имени 'linux'. Эта программа первой загружается в домен и может делать там что захочет. В пределах домена.
Не с этими ли новшествами связаны периодические тормоза машин в облаке на прошлой неделе?
Например, вчера часа в 3-4 по Москве у меня минут 20 сервер вообще не отзывался, и не только у меня.
Или мне это все только показалось?
Например, вчера часа в 3-4 по Москве у меня минут 20 сервер вообще не отзывался, и не только у меня.
Или мне это все только показалось?
Какие планы по апгрейду машин?
Например в старом облаке пачка машин живущих со старыми ядрами установленными извне. Софт внутри обновляется, ядро — нет.
Будет ли какой-нить roadmap как жить, как часто будут доступны новые ядра и т.п.?
Например в старом облаке пачка машин живущих со старыми ядрами установленными извне. Софт внутри обновляется, ядро — нет.
Будет ли какой-нить roadmap как жить, как часто будут доступны новые ядра и т.п.?
В старом пуле, к сожалению, апгрейдов не будет. Основная причина — я не могу «подложить» модули от новых ядер пока хотя бы одна машина держит их подмонтированными.
В новом обновления проходят внутри машины и контролируются пользователем. 3.1 мы подключенных (по-умолчанию) репозиториях обновляем.
В новом обновления проходят внутри машины и контролируются пользователем. 3.1 мы подключенных (по-умолчанию) репозиториях обновляем.
Старый пул оставлен на растерзание? Без возможности апгрейда ядра смысл в нем пропадет уже через год-два, а вариантов автоматической миграции машин не предусмотрено.
А с ядрами в новом пуле что будет? Как долго будут доступны устаревшие внешние ядра? Как часто будут появляться новые? Предусмотрены оповещения пользователей, если окажется, что какое-то из ядер содержит ошибку?
А с ядрами в новом пуле что будет? Как долго будут доступны устаревшие внешние ядра? Как часто будут появляться новые? Предусмотрены оповещения пользователей, если окажется, что какое-то из ядер содержит ошибку?
Старый пул планируется к миграции в новый. Сейчас мы просто ждём естественного перетока для уменьшения множества тех, кого нужно будет переносить
В новом пуле всё просто — внешние ядра на наше усмотрение, они не являются штатным режимом работы и предназначены для восстановления наломанных дров в grub'ом, кривым конфигом и т.д. Оповещать не будем, обновлять — изредка. Штатным режимом является ядро внутри виртуалки, а оно обновляется yum/apt/zypper и т.д.
ЗЫ Внешние ядра всё равно для работы в штатном режиме не покатят, т.к. у них нет соответствующих модулей (например, для iptables). Т.е. это исключительно ремонтный набор и требования обновления к нему примерно такие же, как и к livecd.
В новом пуле всё просто — внешние ядра на наше усмотрение, они не являются штатным режимом работы и предназначены для восстановления наломанных дров в grub'ом, кривым конфигом и т.д. Оповещать не будем, обновлять — изредка. Штатным режимом является ядро внутри виртуалки, а оно обновляется yum/apt/zypper и т.д.
ЗЫ Внешние ядра всё равно для работы в штатном режиме не покатят, т.к. у них нет соответствующих модулей (например, для iptables). Т.е. это исключительно ремонтный набор и требования обновления к нему примерно такие же, как и к livecd.
Я бы предпочел иметь внешние ядра, что бы доверять вам ядро с гарантированной настройкой паравиртуализованых дров и не заниматься самостоятельной пересборкой каждый апдейт. Да и модули нужны далеко не всегда и не всем.
Ну, я понимаю, с gentoo возникают некоторые нюансы. Но уж раз свой конструктор — то до самого конца.
Кстати, любое pv_ops ядро >3.2 будет работать нормально, только память будет показываться кривовато (TotalMem будет меньше того, за что мы деньги берём). Так что можно брать апстримовое и работать с ним. Я очень надеюсь, что там придут к какой-либо фиксированной зависимости и её можно будет предусмотреть. Основная причина, почему у нас до сих пор -xen, а не pv_ops — фигня с памятью.
Насчёт того, чтобы переложить на нас обслуживание ядра… А почему только ядра? В принципе, мы можем следить и за патчами в nginx, например. Или обновлять SQL… Только это уже какой-то PaaS получается.
Кстати, любое pv_ops ядро >3.2 будет работать нормально, только память будет показываться кривовато (TotalMem будет меньше того, за что мы деньги берём). Так что можно брать апстримовое и работать с ним. Я очень надеюсь, что там придут к какой-либо фиксированной зависимости и её можно будет предусмотреть. Основная причина, почему у нас до сих пор -xen, а не pv_ops — фигня с памятью.
Насчёт того, чтобы переложить на нас обслуживание ядра… А почему только ядра? В принципе, мы можем следить и за патчами в nginx, например. Или обновлять SQL… Только это уже какой-то PaaS получается.
Конструктор — не страшно. Но теперь придется изучить ньюансы.
Почему — только потому, что изначально дизайн облака был именно такой — ядра ваши и снаружи. Потом «вдруг» сменился на «пусть стреляют в ногу» — а нам тут перепривыкать. Вот и хотелось роадмапов — чего дальше ждать?
Почему — только потому, что изначально дизайн облака был именно такой — ядра ваши и снаружи. Потом «вдруг» сменился на «пусть стреляют в ногу» — а нам тут перепривыкать. Вот и хотелось роадмапов — чего дальше ждать?
Ну ты хочешь, чтобы я сказал «сделали фигню»? Ок, говорю: сделали фигню. Внешнее ядро оказалось ошибочным решением и мне пришлось исправлять это.
Да наоборот, мне после сравнения так и сяк внешнее ядро как раз понравилось.
И я расстроен, что вместо нормальной поддержки хотя бы полугодичного цикла смены «гарантированных» ядер от вас, теперь я должен заниматься этим сам с шансами выстрелить себе в ногу.
Так что претензий нет, есть небольшое сожаление.
И я расстроен, что вместо нормальной поддержки хотя бы полугодичного цикла смены «гарантированных» ядер от вас, теперь я должен заниматься этим сам с шансами выстрелить себе в ногу.
Так что претензий нет, есть небольшое сожаление.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление загрузкой виртуальных машин