Česká pobočka SUSE se přestěhovala
Firma SUSE patří mezi ty největší a nejznámější „linuxové“. Vyvíjí komerční linuxové distribuce (hlavně SUSE Linux Enterprise Server a SUSE Linux Enterprise Desktop), poskytuje k nim podporu včetně integrace do dalších systémů, v neposlední řadě úzce spolupracuje s firmou SAP, pro jejíž systém připravuje speciální verzi linuxového systému (která mj. slouží jako referenční pro všechny systémy kromě Windows).
SUSE vyvíjí také úložiště SUSE Enterprise Storage. Nová verze je založena na technologii Ceph.
Nějakou dobu byla firma součástí společnosti Novell, po jejím rozdělení je samostatnou dceřinnou společností firmy Micro Focus (zatímco ostatní značky, jako je například Novell budou postupně utlumeny a bude se používat už jen Micro Focus). Celosvětově má cca 800 zaměstnanců ve třech pobočkách – v Německu, USA a ČR.
Přečtěte si, jak spolu nyní souvisejí komerční distribuce SUSE Linux Enterprise a komunitní openSUSE.
Právě česká pobočka se před pár dny přestěhovala do nových prostor (které ještě nejsou úplně dokončeny, proto je oficiální otevření naplánováno až na červenec). Nově sídlí v budově Corso II v pražském Karlíně. A právě při příležitosti tohoto přestěhování firma uspořádala krátké představení jedné novinky vyvinuté v poslední době – opravy linuxového jádra za běhu (live patching).
Miroslav Kořen hovoří o firmě SUSE a stěhování do nových prostor
Podívejte se, jak vypadala česká pobočka SUSE v roce 2011.
O live patchingu obecně
Myšlenka oprav běžícího jádra operačního systému není vůbec nová. Již od počátku operačních systémů znamenala instalace opravy vždy restart systému, což je nepříjemná komplikace u systémů, které musí běžet nepřetržitě a i krátký výpadech znamená problémy a finanční ztráty.
Typickým případem je nepřetržitá just-in-time výroba (kdy se prakticky nevyužívají sklady – materiál se naváží přímo do výroby a stejně tak se hned odvážejí výrobky), která se dnes v průmyslu využívá zcela běžně a je velmi citlivá na výpadky, protože se pak rozpadne celý řetězec a vzniklé ztráty jsou enormní.
Proto je žádoucí, aby se běžící systém restartovat nemusel. Ale jak to udělat, když je v jádře nalezena chyba, která může také způsobit problémy, pokud by se neopravila? Řešením je oprava za běhu. Původní jádro běží dál, jen se v něm opraví to, co je vadné.
Pro Linux dlouho takové řešení neexistovalo – nikdo se do vyvinutí něčeho takového nehrnul. Mezi důvody patřilo i to, že se na tuto oblast vztahuje několik patentů (v té části světa, kde platí softwarové patenty) a kromě problematiky technické tedy bylo třeba se věnovat i problematice právní.
Řešení pro live patching Linuxu
V posledních letech se ale objevilo hned několik řešení. Nejstarší z nich je Ksplice (rok 2008), které stvořili studenti jako svou diplomovou práci a následně pokračovali ve vývoji v založené firmě. Tuto firmu v roce 2011 získala společnost Oracle, která si technologii Ksplice chtěla „nechat pro sebe“ (samozřejmě v rámci možností daných licencí GNU GPL) a nepodporovat jiné distribuce než svou vlastní.
Další dvě řešení vznikla přibližně ve stejné době: kpatch a kGraft. První je dílem firmy Red Hat, druhé vzniklo ve firmě SUSE. Obě byla představena počátkem roku 2014 a nedlouho poté navržena k začlenění přímo do hlavního stromu linuxového jádra. Nakonec byla (do verze 4.0) začleněna pouze minimalistická implementace, která neřeší všechny aspekty oprav za běhu.
Live patching v podání SUSE
Firma SUSE své implementaci (kGraft) a všemu dalšímu okolo natolik věří, že své řešení poskytuje k linuxovým distribucím s komerční podporou. Zvlášť zdůrazňuje využití pro systémy, kde běží SAP HANA – v případě nutnosti běžící systém ukončit a restartovat server by to mohlo v závislosti na datech znamenat až několikahodinový výpadek, než by se vše vrátilo do původního stavu.
Martin Zikmund popisuje live patching
Pro správné fungování live patchingu samozřejmě nestačí implementace v jádře, která opravy za běhu zajistí. Je potřeba také náležitě připravovat samotné opravy, aby vše proběhlo hladce. Relativně jednoduché je to v případě, že se mění pouze kód (instrukce) – z původní posloupnosti se „odbočí jinam“ a tam se potom pokračuje (v novém kódu, případně ještě ve starém, viz dále).
Není přitom potřeba dělat změny atomicky. Pro uživatelské procesy již zaběhlé do jádra a pro aktuálně běžící jaderná vlákna a obslužné rutiny přerušení se použije původní kód (zkopírovaný – RCU), pro ostatní případy už kód nový (opravený).
Chování opraveného jádra (V4711, CC BY-SA 4.0)
Složitější situace nastává, pokud je potřeba provést zásah do datových struktur. Jak vysvětlil Vojtěch Pavlík, jenž vede oddělení výzkumu a vývoje SUSE Labs a věnuje se kromě jiného právě live patchingu, je potřeba se na to připravovat už předem, tedy například si nechávat v datových strukturách rezervu. To se ale u distribučních jader dělalo už dříve (pro běžné opravy), aby bylo zajištěno stabilní jaderné ABI pro externí moduly.
Animované video k live patchingu