Разработчики сервиса Ksplice (http://www.ksplice.com) объявили (http://www.ksplice.com/news/20100831-fedora) о начале бесплатной поддержки выпуска обновлений для Fedora Linux. Сервис позволяет обновлять содержимое Linux-ядра на лету, без временной остановки работы и перезагрузки системы. Код проекта ksplice распространяется свободно, но сервис распространения готовых обновлений доступен только для платных подписчиков. Ранее обновления распространялись бесплатно только для пользователей Ubuntu Desktop 9.04, 9.10 и 10.04 (http://www.ksplice.com/uptrack/download-ubuntu), отныне данная категория расширена дистрибутивом Fedora 13 (http://www.ksplice.com/uptrack/download-fedora).Для Red Hat Enterprise Linux, CloudLinux, Ubuntu Server, Debian GNU/Linux и CentOS обновления распространяются на коммерческой основе (http://www.ksplice.com/pricing), стоимость подписки составляет около 40 долларов в год. Для демонстрации работы системы любой желающий может подписаться на бесплатный 30-дне...
URL: http://www.ksplice.com/news/20100831-fedora
Новость: http://www.opennet.me/opennews/art.shtml?num=27811
Не понимаю честно говоря, когда может так одновременно "зачесаться" обновлять ядро без перезагрузки. Если работает - то зачем дергать либо обнови та перезапусти, минутное дело ведь.
>Не понимаю честно говоря, когда может так одновременно "зачесаться" обновлять ядро без перезагрузки. Если работает - то зачем дергать либо обнови та перезапусти, минутное дело ведь.Для серверов же вполне актуально.
> Для серверов же вполне актуально.Есть только одна проблема: Ubuntu Desktop 9.04, 9.10 и 10.04, и Fedora 13 - не серверные.
>Есть только одна проблема: Ubuntu Desktop 9.04, 9.10 и 10.04, и Fedora 13 - не серверные.Официально, а так, что мешает их "сервернуть" :)
Ээээ, может на постоянно используемом сервере, где ошибки безопасности лучше сразу лечить?
дырки в безопасности на лету лотать, очевидно же.
Латать
>дырки в безопасности на лету лотать, очевидно же.Вам тогда на ebay! %)
"Минутное дело" (а с учетом серверных рейдом - часто и более) может стоить очень дорого, особенно если это DB или NFS сервер (да или тот же VoIP transit). Да и шансы зависнуть в глючном биосе могут быть сильно больше 0.
Глючный BIOS, на критическом серваке, как так? :)
Запросто. У меня был весьма недешевый рейд контроллер от HP, который раз в н ребутов мог не загрузиться, причем повторяемость была крайне низкая. Еще вариант - батарейка в смосе сядет, и привет. Конечно, это можно отследить по IPMI, но далеко не везде заморачиваются подобным мониторингом.Ну и в целом - для войпа, например, стоимость минуты - крайне высока, а в случае стартапа денег на полное резервирование всего может просто не быть. Кстати, еще 1 вариант - хостинг сервер. Сотни (или больше) клиентов на каждом сервере, и каждый хочет 99.99% аптайм :)
Внеплановое обновление на критическом серваке вас удивляет больше?
>Внеплановое обновление на критическом серваке вас удивляет больше?Ну а если сервер зависнет при плановом ребуте - вам сильно легче станет? :)
плановый ребут?Виндоуз админ детектед
покажи свои аптаймы, ну
Показываю:# uptime
10:36AM up 352 days, 21:58, 1 user, load averages: 0.24, 0.16, 0.12
Мужики, кончайте меряться аптаймами, пока VMS-ники какие замшелые не пришли :)Плановый ребут -- это мозги детектед, потому что бывает множество заранее труднопредсказуемых деталей (и батарейки, и болванку с нарезкой в приводе забыли, и какой-нить из апдейтов поверх позапрошлогоднего именно на этой конфигурации привёл к фатальным для загрузки или подъёма сети последствиям), а шнурок в IPMI-порт воткнут совсем не всегда (на колокейшене ещё не встречалось вроде), и SoL или iKVM там настроен ещё более не всегда.
Так вот чтоб это выяснилось не тогда, когда все вводы спеклись, батарейки садятся и на дизель соскочили с перепадом (и весь личный состав и так озабочен по уши) -- а тогда, когда есть время, внимание и более-менее удобно выяснить, хост вообще планирует загрузиться или как.
только трУсы ребутятся!
Плановый ребут нормальная и необходимая практика, вне зависимости от используемых систем.С.
>Плановый ребут нормальная и необходимая практика, вне зависимости от используемых систем.
>
>С.Для мазохистов.
Fixed.
>плановый ребут?
>
>Виндоуз админ детектедВот вы готовы дать руку/ногу/голову на отсечение, что у вас все изменения в конфигурации так же (и без ошибок) сохранены в конфигах?
А если у вас в отделе несколько админов, вы за каждого готовы поручиться?)
Правильно ли сохранены настройки, хорошо видно после перезагрузки.
И лучше, если вы узнаете что-то новое для себя тогда, когда вам это удобно (и вы будете рядом).
А не когда будет аврал, скажем, изза питания (а вы где-нибудь в египте).
>Вот вы готовы дать руку/ногу/голову на отсечение, что у вас все изменения
>в конфигурации так же (и без ошибок) сохранены в конфигах?
>И лучше, если вы узнаете что-то новое для себя100% windows admin detected.
>100% windows admin detected.Вам годиков сколько, разрешите поинтересоваться? И стаж рутом не на локалхосте, пожалста.
А то светодиодик "прогуливают уроки" подозрительно помаргивает. :)
>Вам годиков сколько, разрешите поинтересоваться? И стаж рутом не на локалхосте,
>пожалста.
>А то светодиодик "прогуливают уроки" подозрительно помаргивает. :)Глючный он у вас, вот и помаргивает. Как что не понравилось - сразу на личности лезут. Годиков мне достаточно, а что до стажа... Несколько тысяч юзверей в постоянном онлайне, Cisco класса 76xx, 72xx, 53xxXM, ASA 55xx, Asterisk, FreeSWITCH, MariaDB, BIRD, кластерные системы (GlusterFS, NDB Cluster), OpenVZ - если наличие навыков во всех этих областях Вам что-то говорят, то мой стаж Вас с этого момента волновать не должен абсолютно.
>говорят, то мой стаж Вас с этого момента волновать не должен*говорит. очепяталсо.
Говорят, но тем более удивительны фразки вида "windows админ детектед".
>>Вот вы готовы дать руку/ногу/голову на отсечение, что у вас все изменения
>>в конфигурации так же (и без ошибок) сохранены в конфигах?
>>И лучше, если вы узнаете что-то новое для себя
>
>100% windows admin detected.А теперь слушайте.
Как раз в windows настройки сервисов сохраняются при изменении.
Там деваться некуда, там нет кнопки "применить, но не сохранить".А когда вы установите linux и поработаете в консоли, то поймете, что тот-же ifconfig можно конфигурить как угодно.
Но эти настройки проживут ровно до первой перезагрузки.
А чтобы они остались и после перезагрузки, нужно эти настройки прописывать в конфигах.
И какие-то конфиги можно проверить без перезагрузки - reload, restart, или даже configtest.
А какие-то конфиги (или скрипты) либо с перезагрузкой, либо с полным перезапуском всего и вся.
Конфиги Того-же grub, например.И внезапно обнаружить, что какая-то служба не запускается после перезагрузки - лучше во внерабочее время и рядом с сервером.
Чем во время отпуска за пару тыс. км.
Потому что чинить эти недоработки вы все равно будете.
Но лучше это делать, когда вам удобно.
>А когда вы установите linux и поработаете в консоли, то поймете, что
>тот-же ifconfig можно конфигурить как угодно.
>Но эти настройки проживут ровно до первой перезагрузки.Когда Windows-админы лезут в *nix, ровно так и получается. Ибо написать скрипты для загрузки конфигов забывают.
>Когда Windows-админы лезут в *nix, ровно так и получается. Ибо написать скрипты
>для загрузки конфигов забывают.Если бы. Среди линуксоводов тоже полно таких, кто не понимает -- "сперва пишем, потом тестим, а откат под screen на sleep, если что"...
если "реально дорого", есть HA, есть живая миграция. если, конечно, "реально дорого", а не "руководство щеки дует".
Я выше привел пример - масс хостинг. Строить HA - нерентабельно. А аптайм - весьма важен. 4 бакса за сервер в данном случае - вполне оправданная затрата, на мой взгляд.
> Строить HA - нерентабельно. А аптайм - весьма важен.взаимоисключающие параграфы детектед. либо ваши клиенты могут оплачивать HA, либо нет. если они не могут оплатить sla и соотв. число девяток - я не понимаю смысла обеспечивать им какой-то аптайм.
ha всяко предназначен не для бесперебойного сервиса, а для минимизации простоев сервиса. вам всяко же хотя бы раз в полгода нужно гасить систему, обновлять прикладное ПО, фирмварь.
>взаимоисключающие параграфы детектед. либо ваши клиенты могут оплачивать HA, либо нет.А также бэкап, рейд, дублированные блоки питания, etc. Есть куча вещей, которые могут несколько пересекаться по эффекту, но high availability в смысле организации failover -- это всё-таки не на четыре девятки вроде, а на пять-шесть осмысленно городить, нет? Если не пытаться одновременно сэкономить на спичках.
>если они не могут оплатить sla и соотв. число девяток -
>я не понимаю смысла обеспечивать им какой-то аптайм.Клиента любить надо. Вы к нему по-человечески -- и он к вам, а не к соседу.
>ha всяко предназначен не для бесперебойного сервиса, а для минимизации простоев сервиса.
Да.
>вам всяко же хотя бы раз в полгода нужно гасить систему,
>обновлять прикладное ПО,Проверяется на стенде, выкатывается проверенное.
>фирмварь.
Зачем? За исключением дырок в торчащем в сеть и каких-то глюков, которые не следовало пропускать на предзакупочной стадии -- не припоминаю смысла чинить то, что работает.
Из заметных исключений -- прошивка Mellanox 10GE, которые при включенном Intel VT-d способны без уважительных причин криво дропать трафик. Если этот VT-d понадобится, вот тогда придётся что-то думать и шить. И то в случае наличия out-of-band доступа и без необходимости ресетить железку по питанию можно обойтись без существенного даунтайма.
ну клиенту же пофигу, че и как я горожу. я обещал ему четыре девятки - это час простоя за год. пять девяток - это пять минут простоя в год. бэкапы и рейды - это все жыды придумали, чтобы клиентов смущать. если мой аплинк или горэнерго промуфлонило или у меня с бэкапом лажа вышла - интересно это клиенту или нет, кто именно облажался? у него есть sla, которое я ему гарантировал, а уж как я ему собираюсь гарантировать - это мои проблемы?>Клиента любить надо. Вы к нему по-человечески -- и он к вам, а не к соседу.
я его клиента просто обожаю. в рамках оплаченного. на десять баксов в месяц - так на десять. На тысячу баксов в месяц - так на тысячу. помнить, насколько тебе дорог тот или иной клиент - это важно. вряд ли я буду предлагать десятидолларовому клиенту даже четыре звездочки.
>Проверяется на стенде, выкатывается проверенное.
это - даже без вопросов, что на тесте проверяется. но если мне выкатили дизруптивный апдейт, я хоть усрись, а сервис передернуть придется.
>>фирмварь.
>Зачем? За исключением дырок в торчащем в сеть и каких-то глюков, которые не следовало пропускать на предзакупочной стадии -- не припоминаю смысла чинить то, что работает.если вам не нужен саппорт вендора - не вопрос, можно не обновлять. но если у вас внезапно фирмварь 12.34.55, а вендор поднял рекомендованный уровень до или уже поддерживает только 12.48.67 - чо как тогда?
>интересно это клиенту или нет, кто именно облажался?
>[...] а уж как я ему собираюсь гарантировать [...]Примерно это и пытался сформулировать, что есть _разные_ куски, зачастую влияющие схожим образом в одних ситуациях (но в принципе разным), и в сумме направленные на снижение времени простоя. Можно пережить потерю диска в рейде, можно восстановить из бэкапа одиночный, jedem das seine.
[ds3700: а]
>>фирмварь.
>
>Зачем? За исключением дырок в торчащем в сеть и каких-то глюков,
>которые не следовало пропускать на предзакупочной стадии -- не припоминаю смысла
>чинить то, что работает.да господи, чо я выдумываю-то. два месяца назад потребовалось поднять фирмварь на ds3700. глюки в мониторинге. дизруптив апдейт, остановите весь i/o плиз. пожалста вам, полка и два экстеншна - тридцать минут простоя всех подключенных хостов.
Ну и кстати даже при HA проблем будет много больше чем при подобном обновлении. Например - MySQL MASTER<-->MASTER HA - при переключении отгребем пустой кеш второго мискла (performance degradation). Или тот же memcache сервер (репликации штатными средствами нет, а тот патч что есть - крайне крив). В случае VoIP системы - мы практически гарантированно потерям активные сессии, а на загруженном тазике с мерой это может быть 300+ абонентов.
>Ну и кстати даже при HA проблем будет много больше чем при подобном обновлении. Например - MySQL MASTER<-->MASTER HA - при переключении отгребем пустой кеш второго мискла (performance degradation). Или тот же memcache сервер (репликации штатными средствами нет, а тот патч что есть - крайне крив). В случае VoIP системы - мы практически гарантированно потерям активные сессии, а на загруженном тазике с мерой это может быть 300+ абонентов.натурально, потеряете :) HA не средство для обеспечения _непрерывной_ работы сервиса. для этого есть более другие средства (и более дорогие). мой пойнт не в том, что HA какое-то волшебное средство, а в том, что за гарантированный аптайм обычно берут деньги, хотя бы окупающие средства гарантирования этого аптайма.
> может стоить очень дороготам где это может стоит очень дорого нужно ставить 2-3 или более одновременно рабочих сервера на подхвате друг у друга... а если сервер у вас сгорит не нароком... даже с самыми дорогими бывает вы что будете ждать 2-4 часа пока приедет гарантия и починит?
PS
а в стране которой живу я вообще сервера на подхвате или одновременно рабочие "там где дорого" ставят в разных точках страны потому как в любое место может бомба стукнуть а в ближайшем будущем может даже ядрёна :D
>Да и шансы зависнуть в глючном биосе могут быть сильно больше 0.kexec?
> Если работает - то зачем дергать либо обнови та перезапусти, минутное дело ведь.Когда деньги текут каждую секунду, минута простоя = потери клиентов и денег.
> Если работает - то зачем дергать
Риск взлома = риск простоя = потеря денег.
> Не понимаю честно говоря, когда может так одновременно "зачесаться" обновлять ядро без перезагрузки.Остановка некоторых серверов даже на секунды стоит немалых денег. Или возникают какие-то иные проблемы. Упомянутая технология позволяет сократить простои и перерывы в обслуживании.
У моей машинки аптайм 2 месяца. не хочется такие красивые циферки портить :)
>У моей машинки аптайм 2 месяца.Не смеши людей. ;)
>Не понимаю честно говоря, когда может так одновременно "зачесаться" обновлять ядро без
>перезагрузки. Если работает - то зачем дергать либо обнови та перезапусти,
>минутное дело ведь.Для домашнего использования, или просто для не особо критичных мест - согласен.
А в продакшене...
Никогда не засекали, сколько перезагружается какой-нибудь сервачок HP Proliant с рейд контроллером E200? =)
А если каждую минуту идут какие-нибудь важные данные (особенно, связанные с бабками)?
Вот в таких случаях вам предлагается избавиться от 7 из 8 перезагрузок за очень дешевую цену - 40$ в год.
а как они, к примеру, Ubuntu Desktop отличают от Ubuntu Server? PAE на x86? а на amd64?
P.S. или на слово верят?
>а как они, к примеру, Ubuntu Desktop отличают от Ubuntu Server? PAE
>на x86? а на amd64?
>P.S. или на слово верят?Ядра разные. Нахаляву дают скачать десктопное ядро или обновление к нему. Вариант - использовать десктопное ядро, но оно вам на сервере надо?
Очевидно что обновление на лету, более рискованно чем традиционным способом.Потому на важном сервере лучше уж ребутнуть после апдейта, чем чтобы потом полезли глюки от безперезагрузочного обновления.
Простой, при чем небольшой, лучше чем любая ошибка. Если будет kernel panic при апдейте - плохо, но хуже если после такого апдейта, может возникнуть скрытая ошибка, которая вылезет не сразу (попортит код ядра и файловую систему, или память пользовательских приложений).
Могу привести аналогию. Когда что-то сваливается, гораздо лучше остановить систему, абстрагироваться от того что все лежит и принять взвешенное решение, чем исправляя впопыхах по горячему еще больше запороть (так обычно и выходит).
Особенно круто стопарнуть сервер молотящий какие-нибудь там транзакции. А так - ну наверное если сервис платный, вливать клиентам апдейты вызывающие панику или ошибки было бы не умно и не в интенесах конторы. А если вы сами накосячите - так вы ССЗБ.ЗЫ кстати есть и иные варианты обновления системы без остановки работы. С виртуализацией например.
Никто ведь не говорит что нарочно кривые апдейты будут давать. Всякое может быть, патчить ядро в памяти это по большому счету хак и дополнительный риск по сравнению с ребутом. Стоит ли?Еще пример: демоны всегда надежнее рестартнуть, чем делать релоад конфиг, даже если такая функция поддерживается "от производителя". В одном случае, некоторые вещи не могут обновиться при перечитывании конфига и это документировано, в других случаях могут возникать непонятные/недокументированные глюки (либо демон чего-то не смог сделать и умолчал об этом - забиндить порт, или изменить юзера, либо файл не переоткрылся и пишет в уже удаленный и т.п.). Да и при работающих соединениях изменения конфига могут вызвать непонятное поведение.
Лучше проектировать так, чтобы ребут какого-то сервера не вызывал простой системы. Не обязательно автоматом, просто чтобы в ручную можно было вывести из работы сервер - спокойно его заапдейтить и потом включить обратно в работу.
Это не хак. На сайте достаточно подробно объяснено как происходит обновление, а сам модуль и инструменты для создания патчей - вполне себе доступно. Компания берет за это деньги, а список клиентов у нее достаточно впечатляющий. Кстати, я наверное порекомендую их для одного проекта с кучей вебнод, посмотрим как работает (там центос), самому интересно.
>Никто ведь не говорит что нарочно кривые апдейты будут давать.
>Всякое может быть, патчить ядро в памяти это по большому счету хак и
>дополнительный риск по сравнению с ребутом. Стоит ли?Вот за QA денег и хотят. Плюс ksplice априори не все случаи обрабатывает, там при сборке "патча" выполняется некоторое количество автопроверок.
>Еще пример: демоны всегда надежнее рестартнуть, чем делать релоад конфиг
Нет.
Гораздо лучше (в альте где добрался и получалось -- так и сделал) перед рестартом, да и релоадом, проверить пригодность конфига (у некоторых бывает -t или аналогичное).
При этом если такой возможности нет, то большинство софта при попытке reload'нуть кривой конфиг на него выругаются и продолжат по старой партитуре, а вот при restart'е получаем лихорадочное выяснение, что не так, потому что сервис уже лежит.
Поэтому если нет test, то reload и при удаче restart всё равно лучше, чем restart.
PS: до кучи -- если кто не пользуется monit, весьма рекомендую.
>PS: до кучи -- если кто не пользуется monit, весьма рекомендую.Сравнивали с nagios?
>>PS: до кучи -- если кто не пользуется monit, весьма рекомендую.
>Сравнивали с nagios?Лет пять-шесть тому сделал для себя вывод, что мониторинг предпочитаю активный локальный плюс пассивный распределённый -- monit прекрасно справляется в качестве первого.
>>>PS: до кучи -- если кто не пользуется monit, весьма рекомендую.
>>Сравнивали с nagios?
>
>Лет пять-шесть тому сделал для себя вывод, что мониторинг предпочитаю активный локальный
>плюс пассивный распределённый -- monit прекрасно справляется в качестве первого.О как.
Для этой цели - да)
>>Всё-таки до какой же степени линуксоидам в падлу перезагружаться... :-)
>
>что даже гибернацию десятилетиями допилить не могут. и не говорите...Допилили уже :)
Стоит кубунта на ноуте. При закрытии крышки ноут валит в suspend to RAM, при открытии пробуждается и снова полный вперед. Все это вообще без копания в системе. Я что-то делаю не так что у меня хибернация в оперативку прекрасно работает без плясок с бубнами?? И в чем состоит недопиленность? Вроде работает, логика вполне вменяема и конфигуряема. Что-то не так?
>Потому на важном сервере лучше уж ребутнуть после апдейта, чем чтобы потом
>полезли глюки от безперезагрузочного обновления.
>
>Простой, при чем небольшой, лучше чем любая ошибка. Если будет kernel panic
>при апдейте - плохо, но хуже если после такого апдейта, может
>возникнуть скрытая ошибка, которая вылезет не сразу (попортит код ядра и
>файловую систему, или память пользовательских приложений).Уже с год пользуюсь KSplice. Никаких кернелпаников и прочих ахтунгов не отмечено.
> Уже с год пользуюсь KSplice. Никаких кернелпаников и прочих ахтунгов не отмечено.Ну собственно год тут не показатель. Сколько раз за год пришлось использовать?
>> Уже с год пользуюсь KSplice. Никаких кернелпаников и прочих ахтунгов не отмечено.
>Ну собственно год тут не показатель. Сколько раз за год пришлось использовать?Где-то 12-15 обновлений за год, более чем на десятке машин.