Virtualizovaný cluster (diskuse)

[Marek 'marx' Grác]

Možno by sa ti mohlo hodiť, že na inštalovanie clustru je možné použiť puppet manifesty.

[Aleš Kapica]

To lze pochopitelně použít v rámci odladěných enterprise řešení. Jenže mě zajímají vývojové verze, a to nejenom Pacemakeru a jeho nástrojů, ale také Pupetu. Díky tomu jsem pak připravený na případné záludnosti, když aktualizuji produkční prostředí.

[citanus]

troska nevyhoda je v tom, ze kdyz se hlavni klastr odporouci, tak uz nemam nacem ozkouset DR : )

[Aleš Kapica]

Co si mám představit pod "hlavni klastr odporouci"? Od září 2012, co jsem přešel na diskless nebylo celkově víc než 20 výpadků. Podchyceno mám monitoringem jich mám 13 (předtím nebylo toto clusterové prostředí monitorované). 3 loňské než jsem si konečně napsal vlastního agenta pro KVM virtuály byly v řádech hodin - protože k nim došlo z neděle na pondělí, když jsem byl mimo. V těch 10 zbylých jsou asi dvě plánované odstávky a u toho zbytku nebyl výpadek delší než 10 minut. To je slušné na školní infrastrukturu která se používá 24/7/365, ne?

[Max]

A duvody vypadku byly jake? Jen tak informativne, pokud to neni tajne.
diky
Zdar Max

[Aleš Kapica]

Nemám s tím problém, alespoň dostane zdejší osazenstvo lepší představu o tom jak takový problém vypadá a vzniká.. Sepsal jsem je v e-mailu, který jsem posílal 9.5.2014. Od té doby proběhly už jen dva výpadky - jedním byla plánovaná odstávka při revizi trafostanice 3.7.2014, v průběhu dopoledne a tím druhým asi dvouminutový výpadek, v pátek před mým odchodem na dovolenou, kdy jsem potřeboval zopakovat chování Pacemakeru při onom zmíněném problém s DRBD agentem, abych mohl kolegům popsat jak by měli v takovém případě postupovat.

Z těch předchozích si vybavuji tři:

• Jeden způsobil vypadlý větrák, který pak honil teplý vzduch v bedně jednoho ze strojů, dokud se neuvařil.
• Za druhým se skrývala vyhořelá pojistka na jednom z okruhů v hlavním rozvaděči
• A poslední před zahájením monitoringu byl při letní pražském blackoutu 2013, kdy vyhořela trafačka za Prahou.

Ovšem jako plnohodnotný cluster, u kterého jsou komplet všechny zdroje řízené Pacemakerem to jede až od 7. ledna 2014. Předtím fungovaly stroje C a D jako datové a E pouze jako virtualizační. Takové řešení je z uživatelského hlediska mnohem stabilnější a robustnější, ale příkaz zněl jasně - přesunout všechno na nové dva stroje. Že se i nadále pro některé věci využívají i ty původní tři je věc jiná.

Jen tak pro zajímavost jsem z logů vyhrabal veškeré záznamy spojené s nějakým výpadkem. Virtuální stroje support a moodle jsou monitorovány přes munin na stroji rtime od února 2013, a za tu dobu byly zaznamenány tyto výpadky:

2013 1.září 2:10 (Ne) - 2. září 2:20 (Po) Výpadek stroje moodle cca 24 hodin

2013 29.září 2:04 (Ne) - 30. září 8:58 (Po) cca Výpadek stroje moodle cca 31 hodin

2013 23.prosince 1:07 (Po) - 24.prosince 1:09 (Út) Vánoční výpadek. Cca 24 hodin Vyhnil datový stroj, ale neumřel zcela takže vyžadoval manuální zásah, který nakonec udělal Ondra.

2014 7.ledna nebyl žádný výpadek, ale od tohoto data jsou v ostrém provozu stroje DELL a přes Pacemaker jsou řízeny nejenom datové úložiště, ale i virtuální stroje a síťová konfigurace virtuálních switchů. To sebou přineslo i onu závislost na migraci IP adres.

Předtím běžely virtuály vždy pouze na jednom stroji a datové služby poskytovaly střídavě zbylé dva stroje. Tam jsem ovšem narážel na opačný problém - pokud chcípnul fyzický stroj pouze částečně, bylo nutné ho manuálně restartovat, aby uvolnil IP adresy pro NFS server (AMD stroje nemají IPMI, aby to bylo možné udělat vzdáleně). To byla příčina vánočního výpadku

2014 15.února 1:25 (Pá) - 18.února 1:34 (Po) Víkendový výpadek stroje support o délce 3 dny, zapříčiněný vyhnilým připojením na Novell

2014 10.března 13:30 (Út) Šlo pouze o krátkodobý výpadek v trvání několika minut. Zapříčinila ho výše uvedená závislost IP adres na NFS - to bylo poprvé co jsem na tento problém narazil a způsobilo ho nahození agenta pro Pacemaker na stroji Linus (AMD)

2014 4.dubna 11:00 (Pá) Šlo o relativně krátkodobý výpadek cca v trvání 10 minut. Bohužel jako problém byl vnímán proto, že k němu došlo v průběhu výuky. Zapříčinila ho výše uvedená závislost IP adres na NFS - to bylo podruhé co jsem na tento problém narazil a způsobilo ho tentokrát nahození agenta pro Pacemaker po restartu stroje patty (DELL!). Bohužel problém

2014 7.dubna 00:05 - 8:57 (Po) Výpadek celé infrastruktury Peanuts v délce 8 hodin zapříčiněný vybitím UPS v racku 9 strojem kepler

2014 29.dubna 16:03 - 18:02 Výpadek v délce 2 hodin zapříčiněný výše uvedenou závislostí IP adres na NFS. Předchozí výpadky, které nastaly z důvodu této závislosti svým trváním nepřekročily půl hodiny, proto je munin ani nezaregistroval. Spouštěčem pro tento výpadek bylo nahození agenta pro pacemaker po restartu na stroji snoopy (AMD).
Stroj linus, který jsem podezříval už byl v tom okamžiku ve stavu kdy nenajížděl. Díky vadnému disku nedošlo ke správné instalaci zavaděče. Problém tak nastal až ve chvíli kdy, jsem sešel dolů do serverovny zkontrolovat zda není stejný problém i na stroji snoopy. Jenže ten mezitím najel, nahodil Pacemaker (a tím vyvolal problém). Já nic netuše ale mezitím řešil stroj linus. Proto trval výpadek tak dlouho.

Nicméně bych chtěl upozornit, že nasazení clusterové infrastruktury prakticky eliminovalo víkendové výpadky, které vyžadovaly manuální zásah administrátora - byť realizovaný vzdáleně po síti. A průměrná délka výpadků, ke kterým došlo sice nepředvídaně, ale během plánovaných operací se tak - v porovnání s minulým rokem - výrazně zkrátila.

A také bych chtěl zdůraznit, že oproti předchozím létům je CELÁ infrastruktura - tj. od datových úložišt, přes virtuální switche až po virtuální stroje automatizována a spravována přes Pacemaker, tudíž není nutné lézt na jednotlivé fyzické stroje a k jejímu řízení stačí přístup k CRM konzoli na jednom z nich a její standardní příkazy. Což tedy především umožňuje - v případě nutnosti - rychlou kontrolu a správu i přes SSH připojení z mobilního telefonu.

[Aleš Kapica]

Ty lépe orientované by možná mohlo zaujmout, že se moje řešení podobá tomu, co se skrývá pod komerčním názvem XenServer. Jen z mého pohledu transparentnější, protože se jednotlivé komponenty neschovávají za jedno grafické GUI a vše je dokumentováno v rámci manifestů Puppetu a také v naší wiki.

Jen tak pro zajímavost - 3 původní stroje C,D a E jsou desktopové AMD stroje s cenou do 50 tisíc před pěti lety. Takže podobnou infrastrukturu lze vybudovat - jak vidno - i za relativně malý peníz - za předpokladu, že slevím z nároku na dostupnost.

[Max]

Mno, rozvody a el., vecny to problem. My jsme nastesti revizi trafacky prezili, UPS to udrzely pres 4h a jeste mely 2h rezervu.
Nejvetsi vypadek, co se mi kdy stal, byl vypadek email sluzeb na 16h, kdy nasi dcerince po migrace domeny t-online znepristupnil veskere sluzby a odstranil i veskere emaily apod.
Vetsi vypadek jsem snad nezazil, diky bohu.
Jinak servery jedeme HP DL380 a zatim zadny nezklamal, ani po 6 letech provozu.
Ted jsme si slozili jeden server na supermicro a libi se mi to, levne, ale bezpecne.
Zdar Max

[Aleš Kapica]

Nechat to v běhu by nemělo žádný valný smysl. Stejně by se na to nikdo nedostal a jenom by to zbytečně žralo už tak omezené nouzové zdroje.

Pokud jde o železo - já na ty AMD nedám dopustit. Bohužel jsou to jen obyčejné desktopové desky bez IPMI (na PDU mi je připojili až poonom vánočním výpadku). IBM serverů už jsme se chválabohu zbavili. Energeticky příšerně drahá a nevýkonná topná tělesa z druhé ruky. Nebýt toho že byly za směšnou cenu, tak nevím. Aktuálně preferujeme DELL a spokojenost. S HP mám co do činění jinde, ale u iLO4 oproti Dracu se mi nepodařilo rozběhat přístup na grafickou konzoli. Supermicra s tím jeho ipmi máme taky, ale to si spravuje kolega. ALe zrovna nedávno řešil nějakou bezpečnostní díru toho jejich ipmi.

[alkoholik]

Jestli to nebude tim, ze grafickou konzoli si musis zaplatit extra..
:)
BTW: IPMI je derave by design.

[Aleš Kapica]

Jestli to nebude tim, ze grafickou konzoli si musis zaplatit extra..
:)
BTW: IPMI je derave by design.

Ad ta konzole - nejsem si jist. Ve widlích funguje. Ale není můj stroj - neřeším.

[Max]

Už to neplatí úplně zcela. S iLO4 grafická konzole funguje, ale jen asi 10, nebo 15s. Neomezeně dlouhou dobu pak jen v případě, že si koupíš licenci na iLO.
Zdar Max

[Aleš Kapica]

Co je nutné k tomu - kromě zakoupení licence - aby ti ta grafická konzole na linuxu jela?

[Max]

javu, nic víc. Buď využiješ KVM, co je napsaný v net.frameworku, nebo ten v jave. U iLO4 mají obě varinty dostupné, stačí ťuknout na odkaz v iLO rozhraní. Normálně to funguje (Arch Linux + Firefox + java), jen je třeba povolit javu.
Zdar Max

[Aleš Kapica]

Javu mám. U Dracu mi to funguje bez problému, ale iLO4 ne.

[Max]

Teď jsem to zkoušel a bez problémů. Ťuknu, ale nic se nestane, protože ve FF je vlevo nahoře java blokavaná, ťuknu, povolím, okno vyskočí a ok.
Zdar Max

[Aleš Kapica]

Tak u mě FF (iceweasel) neudělá vůbec nic, a chromium chce instalovat javu, přes to, že ji mám nainstalovanou (jinak by nefungoval ani Drac)

[Max]

Já mám čistý firefox 30.0 + jdk 7.51-1 (oracle verze kvůli kompatibilitě s korporátními app, openjdk tedy nepoužívám)
Pokud vím, v chromium nemůže java fungovat, protože od verze 35 byla odstraněna podpora NPAPI a zůstala jen PPAPI. Ale těžko říci, jakou verzi máš ty.
Zdar Max

[Heron]

Mě celkem překvapuje, že mezi výpadky počítáš i plánované odstávky a odstávky způsobené třetí stranou (například na straně dodavatele elektřiny). Za to přece ta tvoje technologie nemůže a pokud nebyla požadován schopnost běhu i za těchto podmínek (což asi nebyla), tak bych to mezi výpadky vůbec nepočítal.

[Aleš Kapica]

Ano. Tak to vidíš ty, tak to vidím já. Uživatelé to ovšem vidí jinak. Bylo by to na pěkně hořký rozhovor. Ostatně i ten přehled vzniknul jenom a pouze z toho důvodu abych objasnil proč se nehodlám vracet do počítačového pravěku a vzdát se infrastruktury, díky níž máme dostupnost srovnatelnou s komerční sférou a robustní ochranu dat.

[pavlix]

Aneb musíš počítat každý výpadek právě proto, abys vysvětlil, že je způsobený třetí stranou.

[Aleš Kapica]

Tak tohle sdělení jsem nějak nepobral.

To s čím tady bojuju, je obyčejná nedůvěra vůči neznámému. Rozepsal bych se víc, ale nerad bych tím vrhnul špatné světlo na jinak pohodové lidi, co mají pouze tu mouchu, že si neradi připouští jak jim ujíždí vlak.

[pavlix]

Tak tohle sdělení jsem nějak nepobral.

Měl jsem za to, že je to jen shrnutí důvodů, proč musíš počítat i externě způsobené výpadky.

[Heron]

Především je to o terminologii

Já (a možná i Aleš) slovem výpadek chápu neplánovanou, neočekávanou odstávku poskytované služby. (Pokud poskytuju web, tak spadne-li apache, je to neočekávaný problém na mé straně.) Rozhodně bych však slovem výpadek neoznačil jev, kdy někde na cestě mezi serverem a klientem dojde k přerušení sítového spojení, nebo někdo (na koho já nemám vliv) odpojí přívod elektřiny k danému serveru.

Ono to možná zní jako slovíčkaření, ale lidé hrozně rádi hážou odpovědnost na někoho, kdo ji nemá. A pokud ten někdo o událostech s nimiž nemá nic společného ještě hovoří jako o výpadku, tak tím vlastně poskytuje bič sám na sebe.

[Aleš Kapica]

Ono je to spíš obráceně - za výpadek to považují ti co nemají šajna o vzájemných souvislostech. Typicky: Během odstávky trafačky běží některé služby ze záložního zdroj. Jenže uživatelé nechápou, že energetická kapacita záložního zdroje nestačí k tomu aby mohly jet všechny stroje, čímž je to stejně na kočku, protože se k těm svým službám stejně nedostanou, jelikož jsou závislé zase na jiných službách, které nemusí být dostupné.

[pavlix]

Podle mě do toho uživatelům nic není. Pokud se jedná o plánovanou odstávku, mělo by stačit ji prostě oznámit. Pokud se jedná o nějaké zásadní riziko výpadků, tak se taky může oznámit. Jinak je to výpadek jako každý jiný, ke kterému může dojít z jakékoli příčiny.

[pavlix]

nebo někdo (na koho já nemám vliv) odpojí přívod elektřiny k danému serveru.

O lecčems se dá polemizovat, ale pokud server přijde o elektřinu nebo úplně přijde o konektivitu, služba neplánovaně neběží, a to považuju za jednoznačný výpadek služby. Terminologie, kdy za výpadek neoznačuješ výpadek z vnějších příčin, mi přijde nesmyslná.

Ono to možná zní jako slovíčkaření, ale lidé hrozně rádi hážou odpovědnost na někoho, kdo ji nemá.

A stejnětak se lidé rádi zbavují odpovědnosti, kterou mají. Ale to, zda nastane výpadek nebo nenastane je podle mě věc objektivní, nikoli subjektivní a tedy není určen tím, kdo má za něj zodpovědnost.

A pokud ten někdo o událostech s nimiž nemá nic společného ještě hovoří jako o výpadku, tak tím vlastně poskytuje bič sám na sebe.

Pokud někdo tvrdí, že výpadek nenastal (a nekonstatuje ani plánovanou odstávku), znamená to podle mě, že služba běží. Pokud provozovatel tvrdí, že služba běží a trvá na tom, a přitom neběží, tak to znamená, že je provozovatel buď lhář a nebo neschopný idiot. Nemyslím si, že by to byl o moc lepší obrázek, než že služba prostě občas z různých příčin vypadne.

[Heron]

Terminologie, kdy za výpadek neoznačuješ výpadek z vnějších příčin, mi přijde nesmyslná.

Mě přijde jako nesmyslná tvoje argumentace, která by v praxi nutně vedla k tomu, že se taxativně vyjmenuje (pochopitelně neúplný) seznam toho, jaká konkrétní situace výpadek je a která nikoliv.

Pokud někdo tvrdí, že výpadek nenastal (a nekonstatuje ani plánovanou odstávku), znamená to podle mě, že služba běží.

Služba běží (proces na nějakém serveru běží, server je v plném běhu), ale nikdo se k ní nedostane protože dodavatel konektivity odpojil síť. To, podle mě, výpadek není, pokud někdo nestanovil vyšší míru redundance síťového spojení, což je pro mnoho lidí a firem zcela mimo možnosti (asi těžko si můžu k hostingovému centru vykopat další optiku, že).

[pavlix]

Mě přijde jako nesmyslná tvoje argumentace, která by v praxi nutně vedla k tomu, že se taxativně vyjmenuje (pochopitelně neúplný) seznam toho, jaká konkrétní situace výpadek je a která nikoliv.

To přesně mě přijde nesmyslné na tvé argumentaci, kde je něco výpadek nebo není v závislosti na tom, kdo je za to zodpovědný.

Služba běží (proces na nějakém serveru běží, server je v plném běhu), ale nikdo se k ní nedostane protože dodavatel konektivity odpojil síť.

Podle mě je vcelku jedno, zda při výpadku služba neběží nebo ztratí možnost spojení s uživateli.

To, podle mě, výpadek není, pokud někdo nestanovil vyšší míru redundance síťového spojení

Podlemě vyšší redundance spojení cílí na eliminaci výpadků, tedy pokud nikdo takový požadavek nestanovil, tak jsou takové výpadky zjevně v toleranci, ale netvrdil bych, že to nejsou výpadky. Mám za to, že by slovo výpadek pak bez náhrady ztratilo svůj smysl a bylo by synonymní s pádem či selháním služby.

[Heron]

je něco výpadek nebo není v závislosti na tom, kdo je za to zodpovědný

No jistě. Je to výpadek toho, kdo je za danou technologii odpovědný. Co je na tom divného? Tohle je naopak zcela jasná definice. Jestliže rozvodným závodům neohlášeně neočekávaně shoří trafo a nedodávají elektřinu, je to jejich výpadek. Nikoho jiného. Co je na tom divného?

[Marek]

Nikoli, je to jejich výpadek a zároveň buď službu ohrožující stav, nebo výpadek všech navázaných služeb, které danou službu vyžadují ke svému běhu.

[lmbot]

Nekrmte trolly. Dekujeme.

[pavlix]

Nebylo by lepší napsat alespoň něco k věci, jako to dělá Heron?

[Aleš Kapica]

Služba běží (proces na nějakém serveru běží, server je v plném běhu), ale nikdo se k ní nedostane protože dodavatel konektivity odpojil síť. To, podle mě, výpadek není,..

Výpadek to je, ale pokud by došlo na případné lepení škody, zůstalo by máslo na hlavě někomu jinému než tobě.

[pavlix]

V tom případě se ve významu toho slova my dva shodujeme.

[pavlix]

A co koukám níže, tak nejen my dva.

[Marek]

Já (a možná i Aleš) slovem výpadek chápu neplánovanou, neočekávanou odstávku poskytované služby.

Tak chápeš nekonzistentě s ITIL ITSM frameworkem a nejbežnější definicí availability metriky. Ale chápu, to by bylo až příliš customer a service oriented.

Zákazníka však v konečném důsledku nezajímá kdo výpadek způsobil a proč, ale to, že služba nebyla dostupná, nebo nebyla dodána v očekávané kvalitě.

Jiná věc je samozřejmě Root Cause Analysis, v rámci které se může ukázat, že nedostupnost měřené služby byla způsobena nedostupností jiné služby, pak se samozřejmě otevře daný service contract a zkontroluje se SLA s dodavatelem (interním, externím) dané služby a případně se budou uplatňovat sankce.

Ale nedostupnost služby se samozřejmě meří z pohledu koncového zákazníka vůči poskytované službě a je úplně jedno jestli byl problém na straně BT, AT&T, ČEZ, aplikace, aplikačního clusteru, hardware, nebo nějaké jiné infrastrukturní součásti.

Výpadek je absolutní ukazatel, který nemá prostor pro výklad, to zda-li došlo, nebo nedošlo k porušení SLA to se dá interpretovat v souvislosti se zněním daného SLA, nikoli to zda-li došlo, nebo nedošlo k výpadku.

[lmbot]

Myslim ze si asi never heard termin Force majeure. A ze service availability je relative term a byva specified bud v general conditions nebo vymezen primo v contract.

Tak az dojde k blackoutu, vypadku na pateri nebo lost of connectivity v miste klienta unrelated to a service vendor, muzes si to pridat do list of failures pri zachrane world.

[Marek]

Pleteš se...

ITILv3 definice...

Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service.

Availability = ((Agreed Service Time) - (Down Time))/(Agreed Service Time) * 100

S tím, že service time je 7x5 Po-Pá, nebo 24x7x365, nebo nějaký jiný specifikovaný čas, třeba každý první den v měsíci. Nikoli "když služba zrovna něbeží kvůli tomu, že nemáme elektřinu", to však samozřejmě neznamená, že se veškeré výpadky započítávají do SLA.

Je to podobné jako s náklady na reprezentaci, všechny tyto náklady se započítávají do hospodářského výsledku, ale nikoli však do základu daně. Úplně stejně tedy všechny výpadky snižují dostupnost služby, nemusí však již snižovat SLA pokud pro ně byla v SLA kontraktu vyjednána vyjímka.

[xkucf03]

Rozhodně bych však slovem výpadek neoznačil jev, kdy někde na cestě mezi serverem a klientem dojde k přerušení sítového spojení

Ano, to je chyba klienta (pokud nejsem zároveň jeho ISP)…

nebo někdo (na koho já nemám vliv) odpojí přívod elektřiny k danému serveru.

…to už záleží na tom, jakou službu poskytuji a k čemu jsem se zavázal. Když budu poskytovat hosting/housing a zavážu se k nějaké dostupnosti, tak si mám vybrat takové dodavatele a takové záložní zdroje, abych to byl schopný splnit. Zákazníka pak nezajímá, jestli jsem to rozbil já, nebo mám neschopného dodavatele – od toho by měl být odstíněný.

Ale zase pokud je to v práci a v rámci jedné firmy, tak by měly být jasné kompetence a lidi by měli vědět, že správce odpovídá za servery a za dodávky proudu ručí zase někdo jiný.

[xkucf03]

P.S. ale (neplánovaný) výpadek služby je to tak jako tak – jen za něj může a ručí někdo jiný.

[Heron]

Ano a jako takový si jej nebudu psát do deníčku výpadků mé technologie (čímž celý thread začal).

[Käyttäjä 11133]

Jako takový jej budu zapisovat do deníčku výpakdů mé SLUŽBY.

[pavlix]

+1

Vzhledem k tomu, že jsem od začátku explicitně psal o službě.