Jaderné noviny 15. 3. 2012 – konzervativní přístup v enterprise

26. 3. 2012 | Luboš Doležel

Články - Jaderné noviny 15. 3. 2012 – konzervativní přístup v enterprise  

Aktuální verze jádra: 3.3-rc7. Citáty týdne: Andrew Morton, Linus Torvalds, Borislav Petkov. Greg KH: Linux 2.6.32. Návrh plánu pro řídící skupiny. Jádra v enterprise sféře.

Obsah

• Aktuální verze jádra: 3.3-rc7
• Citáty týdne: Andrew Morton, Linus Torvalds, Borislav Petkov
• Greg KH: Linux 2.6.32
• Návrh plánu pro řídící skupiny
• Jádra v enterprise sféře

Aktuální verze jádra: 3.3-rc7

Aktuální verze jádra je 3.3-rc7 vydaná 10. března; vyšla navzdory tomu, že Linus už další předverze vydávat nechtěl. Žádná z oprav není sama o sobě tak děsivá, ale bylo jich prostě moc a byly napříč různými subsystémy. Síťování, správa paměti, ovladače a tak dále. A namísto toho, abychom tentokrát měli méně commitů než v -rc6, tak jich máme ještě více. Takže má přání, že se věci uklidní, se prostě nenaplnilo.

Stabilní aktualizace: verze 3.2.10 a 3.0.24 byly vydány 12. března; obě obsahují spoustu důležitých oprav. Verze 3.2.11 vyšla o den později, opravuje chybu při sestavování.

Aktualizace 2.6.34.11, která zahrnuje téměř dvě stovky oprav, se nyní reviduje.

Citáty týdne: Andrew Morton, Linus Torvalds, Borislav Petkov

Programování není jen otázkou toho říkat počítači, co má dělat, ale i způsobem, jak ostatním programátorům říci, co jste chtěli, aby počítač dělal. Obojí je důležité a tomu druhému je třeba věnovat péči.

-- Andrew Morton

Hergot, neustále mě překvapují *idioti*, kteří nechápou, že binární kompatibilita je jednou z naprosto nejdůležitějších věcí. *Jediným* důvodem, proč vůbec jádro OS existuje, je hlavně sloužit uživatelskému prostoru. Jádro nemá samo o sobě žádný smysl. Rozbíjení existujících binárek – bez následného uznání, jak příšerný nápad to byl – je snad *nejhorším* hříchem, který může jaderný vývojář spáchat.

-- Linus Torvalds

Jaderní vývojáři mají tlusté hlavy, ve většině případů tlustší, než jsou návody k procesorům.

-- Borislav Petkov

Greg KH: Linux 2.6.32

Greg Kroah-Hartman se probírá historií stabilní verze jádra 2.6.32 a důvody, proč ji přestal podporovat. Když se jádro 2.6.32 stalo základem pro dlouho udržované enterprise distribuce, tak se původně odhadovalo, že tu s námi zůstane po mnoho let. Ale můj původní argument, proč u enterprise distribuce přecházet na novější jádro, se konečně uchytil u 2 ze 3 největších hráčů. Distribuce Oracle Linux i SLES 11 ve svých vydáních během posledních pár měsíců přešly na jádro 3.0, ačkoliv se ostatních částí distribuce skoro ani nedotkli. Udělali to proto, aby využili lepší podpory hardwaru, nových funkcí, nových souborových systémů a stovek tisíc různých změn, které se ve vydáních na kernel.org udály od roku 2009.

Návrh plánu pro řídící skupiny

Po diskuzi o budoucnosti řídících skupin, která proběhla ke konci února, shrnul Tejun Heo všechny připomínky a dospěl k určitým závěrům ohledně toho, jak by chtěl, aby tento subsystém vypadal budoucnu. Jedním z prvních závěrů je to, že podpora vícero hierarchií to má z dlouhodobého hlediska spočítané:

Alespoň mně připadá, že nikdo nedokázal dostatečně odůvodnit podporu vícero hierarchií, takže ano, pokud se něco nezmění, začnu plánovat vyřazení jejich podpory. Toto je věc na dlouho (na roky), takže není třeba začít hned panikařit, protože životní plány se mohou změnit a nemusí se nikdy uskutečnit, ale mám alespoň v plánu se této věci odklonit.

Jednoho dne tedy budeme mít jedinou hierarchii řídících skupin. Nebude ale svázaná se stromem procesů; půjde o nezávislý strom skupin, který bude umožňovat to, aby procesy byly libovolně kombinovány.

Reakce na Tejunovy závěry se převážně týkaly detailů (jako jak ošetřovat řadiče, které plně nepodporují hierarchii). Nevypadá to, že by proti rozhodnutí odstranit podporu vícero hierarchií v době, kdy bude možné to udělat bez porouchání stávajících systémů, byl nějaký silný odpor.

Jádra v enterprise sféře

Jaderní vývojáři rádi reptají na jádra, která jsou dodávána v enterprise distribucích. Tato jádra jsou obvykle spravována způsobem, který ignoruje ty nejlepší vlastnosti vývojového procesu Linuxu; někdy to samozřejmě vypadá, že jdou přímo proti němu. Ale enterprise jádra a systémy na nich postavené jsou také platformou, na které se vydělává na vývoj jádra, takže si vývojáři stěžují jen odsud – potud. Po celé roky to vypadalo, že se na „enterprise přístupu“ nic nezmění, ale v poslední době se ukazuje, že se něco přece jen mění.

Podívejme se na Red Hat Enterprise Linux 6; jeho jádro je údajně založené na verzi 2.6.32. Jenže jádro dodávané Red Hatem se od 2.6.32 liší přibližně 7700 patchi. Řada z nich jsou opravy, ale jiné jsou zásadní nové funkce, často backportované z novějších vydání. Proto „RHEL“ Linux 2.6.32 zahrnuje funkce jako skupinové plánování podle sezení, receive packet/flow steering, transparentní velké stránky, pstore a samozřejmě i podporu pro spoustu hardwaru, která nebyla v době vydání 2.6.32 hotová. Přidejte k tomu pár odděleně spravovaných funkcí (například SystemTap) a výsledkem je jádro, které má k tomu, co najdete na kernel.org, hodně daleko. To je důvod, proč Red Hat už pár let nemá pro stabilní řadu jádra 2.6.32 využití.

Není těžké pochopit, proč to Red Hat dělá; společnost se snaží poskytovat svým zákazníkům kombinaci stability dobře uleželého softwaru a funkcí, oprav a zlepšení výkonu z nejčerstvějších jader. Pokud tento proces pracuje správně, tak má zákazník k dispozici to nejlepší z obou světů. Na druhou stranu se výsledná jádra od komunitního projektu dost liší, nebyla komunitou testována a neobsahují poslední funkce, které nebyly pro backport vybrány. Je také dosti nákladné je připravovat; za skupinou významných jaderných hackerů Red Hatu stojí celá armáda vývojářů, kteří mají za úkol backportovat funkce a zajišťovat, že výsledné jádro bude stabilní a bezpečné.

Když vývojáři remcají na enterprise jádra, jde jim ve skutečnosti hlavně o to, že by enterprise distribuce mohly více profitovat z toho, kdyby prostě přešly na aktuálnější jádra. Tím by získali všechny funkce, vylepšení a opravy chyb z dílny komunity, a to v podobě, jak byly vyvinuty a testovány komunitou. Enterprise distributoři s aktuálními jádry by se tak zbavili velké části nákladů na podporu a mohli by využít sdílené údržby stabilních vydání jádra. Odpovědí na tento názor je obvykle to, že enterprise zákazníci mají obavy ze změn ve verzi jádra (ačkoliv masivní změny skryté za změnou drobného číslíčka na konci zjevně problém nejsou) a také z chyb, které nová verze jádra přinese. Náklady na stabilizaci nové verze jádra by prý mohly překonat náklady na backportování některých funkcí.

Vzhledem k tomuto je zajímavé pozorovat, jak oba ostatní enterprise distributoři přecházejí na nová jádra. Jak SUSE Linux Enterprise Server 11 Service Pack 2, tak Oracle Unbreakable Enterprise Kernel Release 2 nabízejí mnohem novější jádra – 3.0.10 a 3.0.16. V obou případech stojí za přechodem na novější jádro snaha nabídnout zajímavější distribuci; vypadá to, že jsme svědky začínajících změn ve způsobu uvažování ve vedení enterprise distribucí.

Se SUSE to vypadá, že je nastálo na druhém místě co do tržního podílu, hned za Red Hatem. Následkem toho je, že se snaží najít způsoby, jak se od RHEL odlišit. SUSE navíc zcela jistě nemá prostředky, které Red Hat potřebuje k údržbě svých jader, takže se bude snažit najít levnější způsob, jak poskytnout funkce, které obstojí v konkurenci. Jedním zjevným způsobem, jak toho dosáhnout, je lépe využívat práci komunity. Tím, že vydávají novější verze, se SUSE vyhýbá backportování oprav a funkčnosti a také může využít dlouhodobé údržby, která je v případě jádra 3.0 plánována. V tomto světle není překvapivé, že SUSE opakovaně posouvá zákazníky kupředu k novým jádrům, nejprve ze 2.6.27 na 2.6.32 v SP1, pak na 3.0.

I Oracle má potřebu odlišit svou distribuci – tím spíš, že jde jen o RHEL s jiným názvem. V tomto směru se Oracle snaží protlačit některé ze svých vlastních funkcí, jako je třeba btrfs, které bylo v nedávné tiskové zprávě optimisticky označeno jako „vhodné pro produkční nasazení“. Pokud je btrfs skutečně vhodné pro produkční nasazení, tak se tak stalo teprve v posledních verzích; díky přechodu na jádro 3.0 může Oracle nasadit tuto funkčnost, aniž by to znamenalo příliš práce s backportováním nejnovějších oprav. Oracle toto jádro nabízí v Oracle Linuxu 5 a 6; pokud by Oracle zůstal u jádra RHEL 5, tak by uživatelé Oracle Linuxu 5 stále používali něco na bázi 2.6.18. Pro společnost, která se snaží za rozumnou cenu nabízet co do funkcí zajímavější distribuci, je nasazení aktuálního jádra krokem „za hubičku“.

A jak je to s nevýhodami nových jader – se všemi novými chybami? Obě společnosti se tomu snaží vyhnout tím, že nechali verzi 3.0 po 6 měsíců stabilizovat, než to nasadili u zákazníků. Do 24 aktualizací verze 3.0 se doposud dostalo více než 1500 oprav. Skutečným důkazem je ale teprve zkušenost zákazníka. Pokud uživatelé SLES nebo Oracle Linuxu budou narážet na chyby nebo horší výkon následkem změny verze jádra, může se stát, že brzy začnou hledat alternativu. V případě Oraclu je jasnou volbou původní jádro RHELu; u SUSE ale na výběr nemají.

Obě tyto distribuce by měly mít dostatek zákazníků na to, aby se nakonec ukázalo, zda byl přechod na novou verzi jádra v polovině období údržby distribuce chytrým krokem, nebo ne. Pokud se ukáže, že ano, tak budou obě distribuce moci profitovat z přílivu zákazníků, které už hybridní jádra RHELu nebaví. Pokud se ale ukáže, že nová jádra nejsou pro enterprise připravena, tak to může postavení RHELu ještě posílit. Co se nakonec stane, se nedozvíme hned. Pokud se ale Red Hat jednoho dne rozhodne dát zákazníkům nové jádro, tak budeme mít jistotu, jak to vlastně dopadlo.

Diskuse k tomuto článku

[Michal]

V enterprise sféře je vůbec legrace. Zrovna jsem měl diskuzi se zákazníkem ohledně nového clusteru pro Oracle RAC. Že prý to má být "RHEL 5.7 + latest patches". Říkám OK, takže chcete RHEL 5.8. A ni prý né né, musí to být 5.7 plus latest patches a nenechali si vysvětlit že ty latest patches z 5.7 udělají 5.8. Mám nutkání to prostě updatnout na 5.8 a vynechat jen kernel a redhat-release-5.8.rpm.

[Ruža Becelin]

Updatuj to na 5.8 a prepis /etc/redhat-release Tenhle soubor jsem bohuzel nuceny kvuli odpadu z Oraclu nucen fejkovat dost casto...

[Milan Jurik]

Ono to není až tak o odpadu. Ono je to o tom, že si Oracle kryje zadek. Protože prostě mají dojem, že "5.8" netestovali. A tak se budou snažit minimalizovat překvapení. Testování komunitou je super. Ale kolik lidí v komunitě testuje na velkých systémech poslední jádra? Kolik lidí z komunity pravidelně dělá na posledních jádrech zátěže na Fibre Channelu, nedejbože Infinibandu?

A pochybuju, že RH do RHELu bude dodávat novější jádra jinak než jako doplňková, tak jako OEL. Neboť první, kdo mu za to dá přes nos, bude Oracle. Protože nebude mít Oracle DB certifikovánu na novějším RHELím jádře. Pravda, OEL teď tlačí své jádro jako hlavní, neboť OEL stejné slouží jako podvozek pro Oracle produkty a tak si to otestují sami.

[Ruža Becelin]

Tady nejde jenom o jadro vs databazi, ale o dalsi veci jako SMO apod, ktere se slozi, pokud v /etc/redhat-release neni "presny" retezec, apod.

Doufam, ze RHEL nebude dodavat novejsi jadra, protoze to, co dela Oracle, nema s produkcni stabilitou nic spolecneho.

[Leinad]

Opravdu je to tak špatné s novějšími jádry a tak dobré s backporty do starých jader? Nevyznám se v serverové oblasti a RHELu, ale když jsem si zkoušel dát desktopovou verzi na notebook, tak mi na mé grafice Intel X4500M v RHEL 6.0 problikával občas obraz (chyba v 2.6.32, opravená tuším v 2.6.65), ale v RHEL 6.1 už problikávání přestalo a rovnou mi počítač po pěti minutách zamrzal (proces i915 sežral všechen výkon procesoru - či jen chyba xorgu nezávislá na kernelu?). Takže minimálně z pohledu desktopu to vypadalo, že přechod na vyšší minor verzi Red Hatu není zrovna úplně bezpečný (mnohem nebezpečnější, než nová minor verze Ubuntu LTS či Debianu)

[David Jaša]

Co to bylo za notebook? Máš přístup k 6.2, jestli se to tam taky projevuje?

[Ruža Becelin]

Desktopova edice stala do release 5 za prd, ale od release 6 (a dneska 6.2) je mnohem pouzitelnejsi. Zkus posledni updaty...

[Milan Jurik]

Zkuste to a pak vám třeba zákazník dá přes nos, protože mu Oracle odmítne support RACu. Možná, třeba.

[Ruža Becelin]

Spis se nabizi otazka, proc Oracle nenabizi podporu 5.8? Anebo jeste lepsi, proc Oracle necertifikoval RHEL6 pro databaze, ktery tu je uz pres dva roky, takze jsme nuceni zustat na jadre 2.6.18? Docela zajimave, ze Oracle nabizi OEL6, ale Oracle DB na ni nema podporu?

A to nemluvim o tom, ze se nas snazili presvedcit, ze si mame zkompilovat na produkcnim (!) server driver pro PosgreSQL 9, protoze nenabizi RPMko

[Milan Jurik]

Netuším, proč Oracle nenabízí podporu pro 5.8, nebo 6. Tedy raději nechci tušit. Kdo chtěl Oracle DB, má ho mít. Nezávidím.

[Ruža Becelin]

Kdo chtěl Oracle DB, má ho mít. Nezávidím.

Diky za vyjadrenou soustrast :-P

[Michal]

proč Oracle nenabízí podporu pro 5.8, nebo 6.

Nabízí. Podle našich DBA je Oracle certifikován na všech RHEL 5 bez uvedení minor verze. A už asi týden i na RHEL 6, taktéž na celé řadě bez uvedení minor verze. Takže tam problém není.

Že někteří zákazníci chtějí být "one version behind" že prý kvůli stabilitě mi prostě hlava nebere. To je by dávalo malinký smysl dejme tomu u trvání na RHEL5.x místo nasazení RHEL6.x protože 5.x je pořád aktivně podporováno. Ale trvat na RHEL 5.7 místo RHEL 5.8 je pitomost protože 5.8 je prostě 5.7 s posledními updaty.

Ale corporate policy je holt corporate policy a jakkoliv je nesmyslná tak žádné argumenty protí ní nemají šanci.

[Ruža Becelin]

Tak to musi byt nove, protoze si pamatuji, jak jsem bojoval za update 5.3 -> 5.4, protoze v dokumentaci Oracle byla uvedena pouze 5.3

Ona cela ta sranda s verze X.Y + posledni patche vychazi z dob velkych UNIXu a dneska je potreba vedeni/zakaznikovi vysvetlit, ze verze X je release a Y je patchset (nebo service pack, to je jeste lepsi). Takhle jsem to udelal ja a mam pokoj...

[maddoxik]

Ad certifikace DB a OEL6/RHEL6 - už na tom zapracovali http://www.oracle.com/us/corporate/press/1563775

[Ruža Becelin]

Tak ted uz verim, ze i ten Hurd jednou vyjde...

[Milan Jurik]

Tak od té doby, co maká pro Oracle...

[Ruža Becelin]

[Milan Jurik]

Řekněte wow, sice to ještě oddalují, ale zjevně tlak a hrozby fungují

[Petr Ježek]

Na čem že to běhá londýnská burza? Že by s nonSQL?

[nda-breaker]

nechtej vedet

divil by ses jak moc se pouziva treba csv ale psst

[Michal Kubeček]

Pokud je mi známo, LSE používá SLES, takže nechápu, jak to souvisí s příspěvkem, na který reagujete.