Jaderné noviny – 13. 6. 2013: Hotplug paměti

1. 7. 2013 | Luboš Doležel | Jaderné noviny | 4576×

Aktuální verze jádra: 3.10-rc5. Citáty týdne: Russell King, Linus Torvalds, Arjan van den Ven. Plány na přidávání a odebírání paměti za běhu.

Obsah

• Aktuální verze jádra: 3.10-rc5
• Citáty týdne: Russell King, Linus Torvalds, Arjan van den Ven
• Plány na přidávání a odebírání paměti za běhu

Aktuální verze jádra: 3.10-rc5

Aktuální vývojová verze jádra je 3.10-rc5 vydaná 8. června. Linus dal v oznámení jasně najevo, že nemá moc radost z patchů, které dostával ke konci cyklu. Pánové, pánové. Jesli mi nepřestanete posílat nekritické věci, tak budu zase muset začít klít. Takže jestli další žádost o přetažení bude obsahovat „pročištění“ nebo nesmyslný šum, tak si vás vezmu do úst a vymyslím nové způsoby, jak urazit vás, vaši matku a vašeho mrtvého křečka.

Stabilní aktualizace: 7. června vyšlo pět stabilních jader: verze 3.9.5, 3.4.48 a 3.0.81 od Grega Kroah-Hartmana, Kamal Mostafa vydal ze stabilních stromů Canonicalu verzi 3.8.13.2 a Luis Henriques pak verzi 3.5.7.14.

Verze 3.9.6, 3.4.49 a 3.0.82 se aktuálně revidují. Jejich vydání lze čekat 13. června nebo později.

Citáty týdne: Russell King, Linus Torvalds, Arjan van den Ven

Pokud se firmy vrhnou na vývoj hranatého kola a *kvůli tomu* přijdou o možnost začleňovat zpět do hlavní řady jádra, kvůli čemuž budou mít mnohem těžší přechod k novějším verzím, pak ano, *máme* z toho radost.

-- Russell King

Nebýt nahodile schopen se VŮBEC připojit k bezdrátovým sítím bych nenazýval platným modelem „řízení rychlosti“.

-- Linus Torvalds

V první řadě bychom měli přestat uvažovat o volbě frekvence [CPU] (alespoň na x86). Tato myšlenka je už 6 let mrtvá.

-- Arjan van de Ven

Plány na přidávání a odebírání paměti za běhu

Yasuaki Ishimatsu z Fujitsu na japonském LinuxConu hovořil na téma stavu hotplugu paměti se zaměřením na to, co je pro podporu přidávání i odebírání paměti nutné. Když se vám v laptopu nebo desktopu rozbije paměť, tak ji můžete jednoduše vyměnit, ale u serverů, hlavně pak těch, co musí trvale běžet, je to složitější. Kromě toho by možnost přidávat a ubírat paměť umožnila dynamickou rekonfiguraci systémů, kde je hardware rozčleněn mezi dvěma nebo více virtuálními stroji.

Práce na hotplugu paměti se zaměřuje na oba scénáře: rozbitý hardware a dynamickou rekonfiguraci. Podle Ishimatsua bude hotplug paměti podporován v KVM. Aktuálně to zvládá několik operačních systémů, ale Linux to ještě úplně neumí. Náprava je cílem této práce.

Hotplug paměti má dvě fáze: fyzické přidání nebo odebrání paměti a logická změna dostupné paměti v systému (přepnutí paměti do stavu online nebo offline). Obě fáze musejí být dokončené dřív, než může Linux paměti používat a přepnutí do stavu offline je nutné před fyzickým odebráním.

Subsystém správy paměti spravuje fyzickou paměť pomocí dvou struktur. Tabulky stránek obsahují přímé mapování mezi virtuálními a fyzickými adresami. Mapa virtuání paměti spravuje struktury stránek. Pro odpojení paměti je nutné jakoukoliv paměť přesunout pryč a tyto datové struktury zaktualizovat. Stejně tak když se paměť přidává, tak je nutné přidat nové položky do tabulky stránek a mapy virtuální paměti.

Stránky se spravují v zónách a při používání paměťového modelu s dírami (sparse memory model) u systémů s hotplugem jsou zóny rozděleny do sekcí po 128 MB. Sekce se do stavu offline z online a obráceně přepínají pomocí souboru /sys/devices/system/memory/memoryX/state. Zapsáním offline nebo online do tohoto souboru se stránky v této sekci změní na použitelné nebo nepoužitelné.

Od jádra 3.2 je přidávání paměti plně podporováno. Logické odpojování je podporováno s omezeními a fyzické odebrání není podporováno vůbec. V červenci 2012 byly spuštěny práce na odstranění omezení odpojování a podpoře fyzického odebrání.

Práce na fyzickém odebrání byla začleněna do verze 3.9. Zneplatňuje položky tabulky stránek a mapy virtuální paměti odpovídající odebírané paměti. Ale protože paměť musí být nejprve odebrána logicky než je odstraněna fyzicky, tak omezení vztahující se k přepnutí do stavu offline stále znemožňují fyzické odebrání.

Jakmile paměť, která se má odebrat, obsahuje data, pak tato data jsou přesunuta do jiné paměti v systému. Ale jediné stránky, které lze takto přesunout, jsou cache stránek a anonymní stránky, které jsou také známé jako „přesunutelné“ stránky. Pokud paměť obsahuje nepřesunutelnou paměť, kterou Ishimatsu nazývá „jaderná paměť“, pak tuto sekci nelze přepnout do stavu offline.

Jsou zvažovány dva způsoby, jak tento problém vyřešit. Prvním je podporovat přesun jaderné paměti. Výhodou je to, že všechnu paměť lze přepnout do stavu offline a také nulový výkonnostní dopad na systémy NUMA, protože nevznikají žádná omezení na typy alokací, které lze dělat. Na druhou stranu se ale musí zcela změnit vztah mezi fyzickými a virtuálními jadernými adresami. Alternativou je učnit veškerou paměť uzlu přesunutelnou, což by znamenalo znovupoužití stávající funkčnosti přesunutelné paměti, ale znamenalo by i to, že by tam bylo možné ukládat jen paměť cache stránek a anonymních stránek, což by mělo dopad na výkon daného uzlu NUMA.

Ishimatsu řekl, že osobně dává přednost první variantě, ale jako první krok zatím implementují to druhé: tedy vytvoření uzlu, který obsahuje pouze přesunutelnou paměť. Linux zná přesunutelné zóny (neboli ZONE_MOVABLE), ale zóny tohoto typu nejsou vytvářeny automaticky. Pokud se uzel skládá jen z přesunutelné paměti, pak je možné ji všechnu přesunout jinam a uzel pak může být přepnut do stavu offline.

Nová bootovací volba movablecore=acpi, která se aktuálně vyvíjí, použije strukturu přidruženosti paměti (memory affinity) v tabulce statické přidruženosti prostředků ACPI (SRAT) ke zvolení toho, které uzly budou sestaveny z přesunutelné paměti. Nyní lze movablecore použít k nastavení určitého množství paměti, která bude v systému přesunutelná, ale dochází k rovnoměrnému rozdělení napříč uzly namísto soustředění na vybraných uzlech. Příznak „hotplugovatelnosti“ u uzlu ve SRAT bude použit k výběru cílových uzlů v novém uzlu.

Použití příznaku online_movable v souboru state ve sysfs (namísto prostého online) umožňuje administrátorovi přikázat systému, aby daná paměť byla přesunutelná. Bez toho je online paměť považována za ZONE_NORMAL, takže může obsahovat jadernou paměť a nemusí být možné ji přepnout do stavu offline. Funkce online_movable byla začleněna do verze 3.8. To redukuje stávající omezení, ale stále na tom ještě zbývá práce.

Kromě přidání bootovací volby movablecore=acpi (a snad i sysctl vm.hotadd_memory_treat_as_movable) existují i další plány. Hledání cesty, jak stránky paměti a mapy virtuální paměti vložit do čerstvě přidané paměti je něco, co by Ishimatsu rád viděl, protože by to na daném uzlu zlepšilo výkon, ale zase by bez možnosti přesunu těchto datových struktur pak nebylo možné uzel přepnout do stavu offline. Aktuálně přemýšlí nad možnými řešeními. Přesun dat vmalloc() na jiné uzly při přepnutí uzlu do stavu offline je další funkcí, která je zvažována.

Přesun jakékoliv jaderné paměti z uzlu je něco, co by rád Ishimatsu viděl, ale řešení jsou ještě nejistá. Účastníci konference byli vyzváni, aby se účastnili diskuze a pomohli najít řešení.

       

Komentáře

[M.]

Můžete mi někdo uvést příklad "serveru který musí trvale běžet"?

Já se docela dost pohybuju v podnikové sféře, například se staráme o credit card processing jedněch velkých aerolinií, kde každá minuta offline stojí nehorázné peníze, děláme i pro banky a telco firmy, ale nikde jsem nepotkal jeden konkrétní server jenž by musel běžet nepřetržitě. U těch opravdu důležitých systémů se vždy jedná o redundantní clustery, když spadne jeden uzel tak se doslova nic neděje, když vypadne celé datacentrum tak je to trochu víc práce ale v podstatě se jede hned dál. V dnešní době snad nikdo nenavrhne důležitý systém tak aby záležel na funkčnosti jednoho konkrétního HW prvku?? Jasně máme i servery které nejsou v clusteru, a jejichž ztráta by byla nepříjemná, ale rozhodně se nejedná o kritické systémy kde by nebylo možné naplánovat odstávku a vyměnit vadnou pamět nebo upgradovat jádro (hello ksplice - smysl tvé existence jsem taky nikdy nechápal).

Takže kým jsou tyhle non-stop fičury vyžadované?

[Bedňa]

Je dobré keď taká možnosť existuje.

[Ondra]

Staci chvili googlit:

ATM networks, banks, stock exchanges, telephone switching centers, and other similar commercial transaction processing applications requiring maximum uptime and zero data loss.

Dale treba zeleznice, jaderna zarizeni, atd...

Viz treba HP NonStop servers, Tandem, Fault tolerant systems, atd.

[M.]

Odpovídáš hezky ale na jinou otázku. Neptal jsem se které systémy musí nepřetržitě běžet, ale který jednotlivý server (= nějaký konkrétní kus HW) musí nepřetržitě běžet. V naprosté většině toho cos vyjmenoval se bude jednat o nějaké clustery navržené tak aby nezáleželo na funkčnosti jednoho konkrétního serveru, procesoru, paměti, switche, UPS, klimatizační jednotky, atd.

[Ales Hakl]

Ono jde o to, ze OLTP a podobne veci ve vsi obecnosti nejak distribuovat pres vice uzlu clusteru a bez byt kratkeho vypadku nebo ztraty dat moc rozumne nejde, protoze neni obvykle dulezite co se stalo a ze to bude "eventually consistent", ale transakce ktere se provadi maji nejake pevne dane a pro danou aplikaci kriticke poradi.

Typicke reseni je, ze sice existuje nejaky cluster nejakych unixu, ale ten jenom resi v podstate I/O (napr. k tomu dela webove rozhranni, pripadne predem odhaduje vysledky) pro nejaky specializovany hardware (NonStop, System z...) ktery dela vlastni transakcni zpracovani.

Tyhlendty pocitace jsou sice z HW pohledu casto nekde na pul cesty mezi ccNUMA a clusterem, ale je to vicemene jedna fyzicka krabice a pro uzivatele se jevi jako jeden pocitac na kterem bezi jeden operacni system (resp. obvykle jedno virtualizacni reseni, nicmene vysledene virtualni stroje muzou ale nemusi mit nic spolecneho s tim, jak je ten HW realne pospojovan). Smyslem veci jako RAM a CPU hotplug je neco takoveho postavit na linuxu na nejakem primerene PC-like hardware.

[Filip Jirsák]

Myslím, že „server, který musí trvale běžet“ je zkratka – psát to přesně „server, u kterého je požadována minimální doba odstávek“ by bylo zbytečně dlouhé a nesrozumitelné.

Ve vašem případě přece taky bude mnohem lepší, když jednomu uzlu clusteru na chvíli jen odeberete část paměti, než když musíte uzel úplně vypnout, ne? Nebo třeba poskytovatelé nízkonákladových webhostingů nebo VPS – moc devítek negarantují takže nějakou migraci za běhu nepoužívají. Ale když dokážou vyměnit vadný paměťový modul za běhu, také to pro ně bude lepší.

[j]

Jak lepsi? Kdyz prepnu vmware do servisniho rezimu, tak se "lusknutim prstu" zmigrujou vsechny virtualy na ostatni HW, a pak si ho muzu v klidu vypnout a rejpat se v nem klidne celej den. Nikdo to nepozna.

Navic se bavime o odebrani RAMky, coz se dela jen kdyz je vadna ... a tu vadu musi neco nejak zcela korektne detekovat ... jeste v okamziku, kdy ta vada neni kriticka (je opravitelna), jinak se to stejne cely slozi. Dellu trvala detekce chybneho modulu 3/4 roku a hledali jej metodou pokus omyl (misto aby na HW se zaplacenym gold supportem ty moduly vymenili vsechny). Fakt sem zvedav, jak kernel urci, ktery z 32(nebo vice) modulu je ten spravny vadny ...

[Atom321]

Hodí se to na přidávání/ubírání paměti právě toho virtuálního stroje. Na fyzickém stroji se RAM odebírá třeba při výměně modulu za větší/rychlejší.

No hlavně je to krásná hračka

[2X4B-523P]

největší sranda je vyměnit jeden vadný modul za nový, který je také vadný, to dokáže člověku zamotat hlavu

[j]

Virtualnimu stroji dam klidne 10x vic, nez realne potrebuje, neb ve skutecnosti bude mit tu pamet taky jen virtualne. Sak se staci mrknout, kolik mam prideleno RAMeti tady ... cca 300GB celkem, pricemz realne je 128GB. A z toho je jeste 1/2 volna.

BTW: widle se vopupinkujou uz ze zmeny poctu procesoru ... a to ani nemusi bejt za chodu ...;D

[Atom321]

Trochu jiná situace je u pronajatého VPS, kde se za každý GB navíc platí měsíční paušál.

[xkucf03]

Jenže pokud tu VPS někomu pronajímáš, tak by ti vyžral 10× víc RAM , než zaplatil, což asi nechceš. Nebo to můžeš našvindlovat a tvářit se před VPS, že jí dáváš RAM a ve skutečnosti jí dát část RAM a část swapu a jejich poměr měnit podle toho, jak zákazník platí… Ale proč to dělat takhle, když uvnitř toho virtuálu může být krásně vidět, co je RAM a co swap a půjde je přidávat/ubírat za chodu?

[j]

1) pokud to je na kseft, tak si dotycny neco plati a to ma 2) pokud si neplatis konektivitu garant, tak to taky mas 1:bambilion, nedelal bych si iluze, ze za levnej virtual to nebude stejny (= dostanes trebas 4GB, ale realne se o ne delis jeste se 4ma dalsima).

BTW: Onehda sem neco nekde zahlid... a nabizeli tam 256MB RAM ... na tom uz ani ten tucnak pomalu nenastartuje, natoz aby se stim dal provozovat nejakej server ... Mam tu tuxe kterej nic defakto nedela, jen na tom bezi firewall + postfix, a papa to gigo (+dalsi cache).

[xkucf03]

pokud to je na kseft, tak si dotycny neco plati a to ma

Jenže vtip je v tom, že takhle si může připlatit a hned mu naskočí RAM (nebo naopak klesne, když chce snížit cenu), jednou klikne na tlačítko „přidat RAM“, strhne se mu to z kreditu a nic víc neřeší.

ze za levnej virtual to nebude stejny (= dostanes trebas 4GB, ale realne se o ne delis jeste se 4ma dalsima

Takové virtuály nebrat – nevíš, co za svoje peníze dostaneš a pravděpodobně to bude ve výsledku dost drahé. Slušnější poskytovatelé ti dají garantovanou RAM a na fyzický stroj pustí jen tolik virtuálů, aby měli na pokrytí všech fyzickou pamětí.

Něco jiného je výkon CPU – tam dává sdílení větší smysl, protože potřeby můžou být nárazové nebo se ty požadavky hezky poskládají za sebe a efektivně se to alokuje (to u RAM moc nehrozí, protože tu spotřebováváš dlouhodobě).

BTW: Onehda sem neco nekde zahlid... a nabizeli tam 256MB RAM ... na tom uz ani ten tucnak pomalu nenastartuje, natoz aby se stim dal provozovat nejakej server ... Mam tu tuxe kterej nic defakto nedela, jen na tom bezi firewall + postfix, a papa to gigo (+dalsi cache).

Tak to máš nějakého „tlustého tuxe“ – mám tu aktuální Debian GNU/Linux, kde běží SSH a D-Bus a žere to jen 44 MB. Co si tam spustíš za programy a kolik ti to sežere už je na tobě, zaplnit se dá jakákoli RAM, ale je blbost říkat, že 256 MB je málo – i na tom se dá dneska provozovat server s pár užitečnými službami.

[j]

Hele, kdyz chces tahat extremy, mam tu P100 se 8MB (tenkrat primo nepredstavitelny mnoztvi pameti) a tucnak na tom taky jede - ocesanej na kost a vykon tomu odpovida. Ale bavime se o cemkoli rozumnym ... Navic pri cenach 1k/8GB ...

[Jendа]

Navic pri cenach 1k/8GB ...

Bavíme se pořád ještě o VPS? Odkaž. Já mám tohle za 50 korun měsíčně.

[stn]

Ty cesky VPS hostingy jsou nehorazne predrazeny, teda skoro jako vsechno u nas... :-/

[Jendа]

Koukal jsem se i do zahraničí a nepřijde mi, že by byl někdo o moc levnější než třeba ten Finaltek nebo We DoS.

[Jendа]

BTW: Onehda sem neco nekde zahlid... a nabizeli tam 256MB RAM ... na tom uz ani ten tucnak pomalu nenastartuje, natoz aby se stim dal provozovat nejakej server ... Mam tu tuxe kterej nic defakto nedela, jen na tom bezi firewall + postfix, a papa to gigo (+dalsi cache).

Tak to máš rozbitý. Mně žere LAMP (ve špičce 1 req/s) + postfix + dovecot + IRC klient 89 MB.

[trekker.dk]

Hádám, že to "gigo" bude tak ze tří čtvrtin slab (SReclaimable v /proc/meminfo)

[Kvakor]

Na stroji s 256MB jsem provozoval Postfix s Dovecotem, plus LAMP na konfiguraci přes web (byl otevřený jen dovnitř, tj. minimální provoz) a chodilo to bez swapování. Pokud jen tohle spotřebobává giga paměti, tak je něco špatně, typoval bych to spíš na problém firewallu než Postfixu, nejlepší by bylo prohlídnout co kolik opravdu používá, včetně věcí jádra /proc/slabinfo.

[Jendа]

Pardon, je to LLMP (lighttpd), ale to je jedno…

[R]

Kernel to urci podla EDAC - jednak sa dozvie, ze sa v pamati vyskytla chyba (bud opravitelna alebo nie) a tiez aj v ktorom module.

[Filip Jirsák]

Pokud ve vašem pojetí „nízkonákladový“ znamená VMware s migrací na jiný HW, jak potom u vás vypadá enterprise řešení?

[stn]

Velci kluci pouzivaji treba IBM LPAR na pSeries strojich . Jo, VMWare je opravdu lowend/lowcost hracka .

[j]

Dovedu si predstavit ze tohle se muze tykat HW nekde kolem urychlovacu ... tam kdyz ti neco zdechne behem pokusu ... tak mas miliardy v trapu ...

Ale na druhou stranu, i pomerne "levny" zelezo (celkem bezny servery) umi v RAMce udelat zrcadlo (cimz se samo zredukuje na polovinu) a pak tu RAMet muzes vpohode za chodu vymenit, protoze se jednoduse pouziva ten druhej modul, aniz by to aplikace zjistila.

Ono to stejne nakonec zbuchne proto, ze ti RAMka dojde ;D.

Takze tohle mi prijde jako vymejsleni levnyho "serverovyho" reseni pro domaci HW, pricemz 99,9999% useru stejne nevi, kde RAMku maj.

BTW: Ono ve finale zjistis, ze ten provoz, co musi bejt zajistenej 24/7, se nepodela, kdyz to celej den nepojede vubec.

[sachy]

Existují systémy/servery které z principu hardwarem řízených transakcí běží na jednom stroji. Když jde o důvěryhodnost časových razítek a správně zpracované transakce, tak si nemůžeš v databázích dělat zmatek více stroji... každý zámek pro zápis jiného procesu/stroje je overhead a potenciální příčina deadlocku. Když zálohuješ/obnovuješ databázi tak tam taky nemůže "hrabat" víc systémů najednou...

Nonstop dostupnost vyžadují banky, přepravní společnosti, vlády (finančák a celníci)... typicky všichni kdo stále investují těžké prachy do mainframů, protože se jim to pořád vyplatí.

[Peter S.]

Su systémy ktoré nemusia trvalo bežať, cluster by bol overkill ale vybaviť odstávku je dosť komlikované a zdlhave. A v takýchto prípadoch sa toto môže hodiť...

[j]

Pokud je pro nekoho overkill 100k v penezich (ceskych) tak rozhodne nepotrebuje provoz 24/7. Pokud potrebuje, tak je vpohode schopen investovat castky o dva rady vyssi.

[Peter S.]

a čo takto účtovnícke a podobné systémy, kde 24/7 nie je objektívne nutné ale na druhej strane nemôžeš ich v priebehu dna len tak zhodiť na 30 minut. A čo sa týka toho že aké jednoduché je ich urobiť ako cluster - no neviem - často su to in-house aplikácie... takže nemyslím si že by to skončilo na 100 CZK.

[R]

Pri uctovnictve staci pockat na noc. Kto bude uctovat o pol tretej rano? Nehovoriac o tom, ze vsetko uctovnicke bezi na Windows.

[pavlix]

Nehovoriac o tom, ze vsetko uctovnicke bezi na Windows.

Jistě :D.

[Pindal]

A kdo bude chodit v půl třetí ráno do firmy měnit vadný modul?

Kdyby za tím stál nějaký nadšený studentík, řeknu hračka, ale stojí za tím Fujitsu, takže na to asi mají od svých zákazníků požadavky.

[M.]

A kdo bude chodit v půl třetí ráno do firmy měnit vadný modul?

Tak to děláme celkem běžně. Pokud si zákazník platí patřičnou úroveň supportu tak se mu budu věnovat klidně v půl třetí ráno. (A navíc celkem rád protože takovouhle extra práci mám dost dobře zaplacenou).

[Peter S.]

a) všetko učtovnícke nebeží na windows. b) v noci funguje napríklad expedícia. c) aj na nočnú odstávku potrebuješ schválenie.

Celá tato diskusia je trochu absurdná. Na jednej strane je tu možnosť mať ZADARMO vec ktorú možno použiješ a možno nie, vs. riešenie ktoré stojí dodatočné peniaze...

Proste situácia nie je taká že bud máš riešenie ktoré MUSI bežať nonstop a manažement je ochotný za to cvakať alebo na druhej strane aplikácie ktoré si len tak cez den vypneš a nikto si to nevšimne...

[R]

Zadarmo to nie je ani nahodou, pretoze to musi HW serveru podporovat. A taketo servery nie su prave lacne.

Aby sme sa pochopili: ja som za, aby v Linuxe takato podpora bola. Ked si kupim za velke peniaze server, ktory podporuje memory hotplug, tak budem chciet, aby to aj fungovalo. Pravdepodobne si vsak taky server nikdy nekupim.

[j]

1) viz jinde, pokud potrebujes provoz 24/7, tak MUSIS mit druhy zelezo. A samo, z hlediska administrace je pak nasnade, ze (pokud to technicky neni problem), to pobezi virtualne.

2) me osobne neva ze to jako kernel bude umet, jen mi prijde, ze sou tu jiny, dulezitejsi veci, ktery by se mely resit, nez prave toto, protoze si myslim, ze toto nikomu a nicemu nepomuze (teda mozna si to jeden clovek nekdy nekde vyzkousi - v nejaky laborce, kde pujde o prd).

Ja bych totiz chtel opravdu videt admina, kterej bude riskovat vymenu naprosto cehokoli za chodu, s rizikem, ze dojde k poskozeni dat(pripadne zniceni serveru, pokud mu upadne sroubovak ...) - ktery navic, nemusis hned zjistit. Za chodu se menej tak mozna disky v poli - kde ale to pole je vpohode bezici i bez toho jednoho/dvou/... disku. Chci videt, jak budes demontovat sasi z racku, nejlip nekde v 30+Ucku na staflich ... a pak s prekvapenim zjistis, ze abys moh vymenit ten JEDEN modul, tak musis vytahnout celou raiser kartu (=X modulu), coz je neco mezi 25 - 100% RAMky, kterou v tom serveru mas.

[Stanislav Brabec]

Ne, nepotřebujete dvoje železo. A někdy ho ani nasadit nemůžete. HA stroje mívají vysokou míru redundance samy v sobě.

Asi jste nikdy neviděl železo, které umožňuje výměnu vadné paměti, PCIe karty, procesoru nebo dokonce zdroje za chodu.

Nepotřebujete k tomu šroubovat někde na desce a páčit paměti.

A rozhodně to není hračka, kterou by si někdo montoval do racku na štaflích. Často to má vlastní skříň, někdy i vlastní místnost.

[Jendа]

Z popsaného mi výměna dokonce zdroje přijde nejjednodušší.

[Bedňa]

Nejak ste odbočili od témy, je u prdele koľko peňazí máš a či máš cluster atď. Proste jebneš tam ramku a ideš, je to bonus.

[xkucf03]

Zajímavé mi to přijde u virtualizace – zaplatíš si za víc RAM, klikneš a máš ji hned. Nebo ti naopak klesnou nároky (např. po Vánocích) a zase můžeš nějakou tu RAM vrátit, aniž bys restartoval – tzn. čekal třeba i minuty, odpojoval uživatele… A totéž se hodí u fyzických strojů – ne že by restart byl nemožný¹, ale je to zbytečná nepříjemnost – proč to neřešit softwarově bez restartů, když to jde?

_{[1] souhlasím, že by systém měl být navržený tak, aby se vyrovnal s výpadkem/odstávkou}

[Stanislav Brabec]

Představte si třeba server řídící technologický proces. Nasazení clusteru je tam poněkud nesmyslné (výstupem je řízení fyzického hardware), a jakákoliv odstávka znamená zastavit továrnu. Tam se plánují odstávky několikrát ročně, a pouze během nich mohou správci počítačů dělat servis.

Ono i třeba takové vypadnutí serveru pokladního systému v hypermarketu je docela nepříjemné a drahé.

Pokud někdo vyžaduje 24/7 a ještě výkon, pořídí si třeba S390, které je plně servisovatelné za chodu. Dokonce si samo volá servisní techniky.

[j]

Si predstav, ze takova vyrobni linka ma ty servery minimalne dva, a kazdy jeden je schopen okamzite pracovat zcela samostatne.

BTW: Ten samostatne zavolanej technik ti rekne, at mu to vypnes nez dorazi. Cokoli jinyho sou jen marketingovy zvasty.

[Stanislav Brabec]

Jak chcete, aby dva servery řídily stejné hardwarové porty? Myslíte, že naběhne dělník, vytahá kabeláž z jednoho serveru, a bleskově jí přestrká do jiného? Ne všechny úlohy jsou výpočetního charakteru, aby šly snadno předat na jiný stroj. Pokud to jde, pak je samozřejmě HA cluster (trvale zrcadlící, s rychlou migrací za chodu) levnější řešení než stroj navržený na práci bez výpadků.

Myslíte si, že firma, která vyžaduje chod 24/7, by si najala tak neschopného technika, a koupila takový hardware, kdy kvůli závadě na serveru musí zastavit výrobu?

A co třeba realtime nasazení, kdy se bojuje o každou mikrosekundu latence. Tam je nasazení virtualizace prakticky nemyslitelné. A pokud ještě vyžadujete 24/7 provoz, také vám nezbyde nic jiného, než hardware navržený na opravy za chodu.

S390 se nevypíná, a opravuje se za chodu. Většina nasazených S390 nemá za dobu své životnosti ani jeden výpadek vyžadující vypnutí nebo restart (MTBF je kolem 50 let). Ono u stroje za miliony jsou trochu jiná měřítka spolehlivosti.

Ostatně i dedikovaný síťový hardware má uvnitř OS navržený na 24/7 provoz. A pokud je na páteřní síti, tak je výpadek průšvih.

[j]

Pokud mam nejaky low level zarizeni (tady se pak ovsem nebavime ani o PC ani o kernelu, protoze to ma svuj zakazkovy SW), tak se zcela bezne dela to, ze zarizeni ma 2(spis 3-4) TOTOZNE desky, a v kritickych pripadech dokonce trebas 3 bezi stale - a vzajemne se kontroluji. Kdyz jedna zacne haprovat, ostatni dve ji odpoji ("hlasovani") a aktivuji nahradni. Pak samo nekdy (trebas za tejden) dorazi od vyrobce dalsi presne totozna deska (a tady se opravdu nebavime o jine "revizy") a technik proste vyskubne tu vadnou a vrazi tam novou, a oznaci ji jako "nahradni".

BTW: Od IBM bych si nekoupil s jejich supportem ani sroubovak. Ne ze by to jinde bylo vyrazne lepsi, ale to co sem mel tu cest snima ...

BTW2: Pokud vypadne na pateri switch nebo router, tak se nedeje defakto vubec nic, protoze vedle nej v racku bude minimalne jeste druhej.

[Atom321]

Na ovládání hardwarových portů jsou specializované řídící automaty. To je taková pixla s několika porty, RISC CPU s několika KB RAM na chipu. No a ty pomalejší nebo výpočetně/datově náročnější věci řeší (zálohované) PC, spojené s touhle krabičkou přes RS485, CAN, nebo Ethernet.

[R]

A ten automat sa nemoze pokazit? Niektore automaty su len x86 PC s vhodnymi portami.

[xkucf03]

Automat může být celkem levný, jednoduchý a vyměnitelný, můžeš jich mít pár v zásobě a když se pokazí, tak dáš nový a jede se dál. Nicméně pokazit se ti může i elektronika ve stroji, který řídíš, může nastat mechanická závada nebo ti továrnu vyplaví povodeň… všechno asi zálohovat nejde.

[Atom321]

Jistěže se ten automat může pokazit. Je to ale mnohem méně pravděpodobné, než kdyby tam byl Linuxový stroj, ve kterém se dají měnit RAM za provozu.

[Michal Vyskočil]

S390 se nevypíná, a opravuje se za chodu.

No zrovna s390 je v tomto kontextu dost nešťastný příklad, protože to je v podstatě cluster v krabici. A kde je navíc redundatní a virtuální prakticky všechno.

[Salamek]

Ale prd vyrobni linky jsou vetsinou rizene jednim strojem

[pc2005]

ale rozhodně se nejedná o kritické systémy kde by nebylo možné naplánovat odstávku a vyměnit vadnou pamět nebo upgradovat jádro (hello ksplice - smysl tvé existence jsem taky nikdy nechápal).

No odpověd klidně může být: Because we can - desky to podporujou, tak by bylo dobrý aby to podporoval i software a taky je to analogické odebrání uzlu u clusteru (pouze v měřítku jednoho stroje).

Online rekonfigurace je častější a častější. Nikomu by se dnes nelíbilo, kdyby při připojení USB tiskárny/disku musel rebootovat počítač (heh mám dojem, že můj jeden vypatlanej Sony Ericsson se při zapojení na usb musel rebootovat do mass storage módu ). Ještě u IDE bylo minimálně zvláštní připojit kabel za běhu OS. U (e)SATA to nikomu nepřijde ani trochu zajímavý. Všechny ty karty (PCMCIA/PCcard/další ani už nevím ) jsou taky plug'n'play a jejich bloky RAM mohou být přímo adresované (tedy vlastně RAM modul).

[Ivan]

Napriklad se jedna o prostredi kde se mate spatny support model. Napr. mate na jednom serveru databaze pro Kuvajt, Izrael a vychodni Evropu. Zakaznici z tehle zemi se nidky na downtime nedohodnou.

Anebo se jedna o "doslova" celo-zemekoulovy system. U takoveho se dohodnout downtime jedine v dobe kdy slunce prechazi pres Tichy ocean. Ten je nastesti dost velikej.

No a pak samozrejme virtualni servery.

[Bill Gates]

Facebook :D. Nekteri jsou schopni si to hodit kdyz to nejede.

[Gilhad]

Vida - to zni jako zajimave a uzitecne reseni :) A pridat tam modul, co to bude vypinat nepravidelne, aby se dostalo na vsechna casova pasma.

[lazywriter]

Asi ještě potřebujete něco dostudovat. Znám příklad serveru (v Čechách), který má 4TB operační paměti a typické úlohy se na něm počítají řádově dny. Takže výpadek není pár desítek minut potřebných na výměnu, ale třeba několik dní výpočtů (z bezpečnostních/paranoidních důvodů je vyžadováno u přerušených výpočtu nové opakování od začátku).

[Atom321]

Rozumím dobře, že jde o výpočetní stroj se 4TB RAM, který není cluster, výpočty se na něm nesmí přerušit a přitom je možné měnit RAM za chodu? To mě zajímá, hoďte sem odkaz na nějaké studijní materiály.

[Honza]

Je, no konecne to sem nekdo napsal...

dik moc.

PS: Tak kdepak to HPC provozujete? :)

[Max]

Ale unplug už funguje delší dobu, ne? Já jsem se o to moc nezajímal, ale vím, že třeba IBM servery běžně pži detekci chyby na paměťovým modulu modul odpojí a v systému ram ubyde jako by se nic nedělo.
Zdar Max

[Peter S.]

no ale pri IBM je to niečo iné. Pokiaľ tomu rozumiem, firmware dokáže presmerovať OS na inú (fyzicky) pamät bez toho aby si bol OS niečoho vedomy. Samozrejme predpokladáme že OS práve nepoužíva všetku fyzicky dostupnú pamäť na stroji...

samotné AIXy dokážu uvoľnovať a prijmať RAM pamäť aj za jazdy, toto linux (čítaj RedHat Linux) neviem či dokáže...

[j]

Tohle se da resit vice zpusoby - bud tak, ze mas zapojeny pole v RAM (V principu to muze byt cokoli, stejne jako u disku, ale bezne seervery umi zrcadlo) a pak muze vypadnout "az" polovina modulu. Nebo se to resi podobne jako u SSD - proste mas 1-2 moduly "plonkovy", na ktery se to premapuje.

Tohle vsehno ale funguje jen v okamziku, kdy jde o chybu opravidelnou. Jinak uz mas poskozeny data a neni co zmigrovat => stejne ti to cely padne na hubu.

[victor8]

Dovod preco je odoberanie a pridavanie RAM za chodu sikovna vec - prachsprosty dynamicky LPARing na IBM System p masinkach.

Pokial mi v LPARe bezi AIX, viem za chodu odoberat a pridavat takmer vsetok HW, ktory ma LPAR prideleny - od CPU, RAM, cez virtualne adaptery az po fyzicke adaptery (karty) a zbernice.

Nie som si isty ci to dokaze aj LPAR s linuxom (nepouzivame), ale urcite by to bola zaujimava feature.

[Ivan]

LPAR s Linuxem na to ma nejaky spesl driver od IBM. V praxi jsem to ale nikdy nezkousel.

[stativ]

To s tím ARMem je docela husté. Ale jsem rád, že jsou vývojáři nekompromisní (viz citát Russella Kinga).

[Bill Gates]

Ja bych rekl ze strategicky daleko lepsi nez zavislost na serveru a honba za jeho uptimem je umet byt na nem zcela nezavisly.