HP MSA P2000 G3 - jak jsme přišli o pěkný balík peněz

2.10.2017 10:58 | Přečteno: 3731× | plky

Je to už nějaký pátek, co jsem psal o nemilé příhodě s jedním HP MSA P2000G3 : HP MSA P2000 G3 - je to v háji. Mno, tentokrát jsme dopadli podobně, resp. hůř :-/.

Produkce down

Inu, bylo nebylo, kolem 9h (stalo se před pár týdny) měla přítelkyně telefonát, abych se vrátil z dovolené do práce. Já spal a měl u telefonu vypnuté vyzvánění a když se po 2 hodinách nedovolali, sehnali si číslo na přítelkyni.

První zpráva byla, že Oracle má problém s transakčními logy. Druhá zpráva byla, že asi odešel řadič na poli. Chvilku jsme řešili různé tipy od Oracle, zda z toho nějak vybruslit. Nakonec padlo rozhodnutí překlopit vše na backup.

Jdi už do prdele HP MSA P2000 G3

Když mám pole s duálním controllerem, tak očekávám, že tam k něčemu bude. To ale evidentně není případ HP. Když chcípnul řadič, tak se všechno zesralo. Kontrolní soubory oracle, transakční logy, db soubory a celá db chcípla a už byla nenahoditelná a neopravitelná. Dle logů prostě nebyl schopen řadič převzít rozjetou práci od chybného řadiče (chyba syncu cache atd.). Výsledkem byl nemilý čaj na takové úrovni, že to Oracle nedal. Tady uvedu menší poznámku, že provozujeme RAC (2x oracle server s jedním společným úložištěm, kde je db, servery připojeny přes FC)

To už je tedy čtvrtý incident s tímto druhem pole. Nejdříve problémy s flashnutím, kdy to nezkousnulo velký skok mezi verzemi a řadič chcípnul, což bylo popsáno až někde v KB, když člověk hledal důvod.
Další problém s tím, že problémy s diskama to hlásí jen jako "info", nikoli "warning" či "error", opakované chyby s diskama a jejich opravy pak vedly k nestabilnímu serveru. Pak tu máme incident, kdy vypadl proud a půlka disků byla GlobalSpare a support se moc nevyznamenal (KB od HP radilo neflashovat, support radil zaktualizovat fw, výsledkem byla ztráta záloh s tím, že to se prostě prý při výpadku stává). Mno a teď tohle. A to máme jen vytvořených pár volume připojených přes FC, neděláme snapshoty, replikaci, prostě nic "extra". Pravdou jen je, že máme trochu dost starý fw (celé řešení bylo dodáno jako all-in-one a na backend se moc nesahá, před předáním jsme si náhodné vyndavání řadičů zkoušeli a vždy se vše převedlo ok).
A teď k tomu ještě přibylo uzavírání HP do sebe, kdy už povětšinou není možné sosnout firmware pro zakoupený hw bez placeného supportu. Je vyžadována registrace na HP, registrace produktu, hledáním kontraktů a zadáváním do webu a ve výsledku trvá proces vydolování fw z HP delší dobu, než odstávka serveru a update fw.

Špatně nasizovaný backup storage

Mno, nakonec se ještě zjistilo, že backup storage posledních pár let vývoje jaksi nezvládá zátěž, takže některé operace byly v řádu minut. Příkladem budiž jedno nalučování, při kterém se mění primární klíč asi ve 20 tabulkách (změna primárního klíče = lock tabulky, pokud tuto akci dělá více lidí najednou a akce trvá v řádu minut, tak je problém na světě). Ano, špatně navržená db, což je dáno historií IS, postupně se věci napravují, ale spousta zákeřností zůstává. Problém ale nakonec nebyl ve výkonu storage, ale v tom, že je backup připojen přes iSCSI a to už linka nedala.

Další pešek do hrobu

Aby toho nebylo málo, tak kromě naší neplánované odstávky probíhá plánovaná denní odstávka celníků v Německu, takže docela problém se časově vejít do zbývajícího okna a dohnat zpoždění, které nastalo.

Já idiot

Nejhorší na tom je, že máme nový storage, nový server, ale kvůli pressu nebyl čas zmigrovat (není to jen migrace, ale i celkový sw upgrade + změna konceptu db). Kdybych neměl skluz v řádu měsíců, tak by to nenastalo :-/.

Čas, ten čas

Nejhorší jsou ty drbačky okolo. Chcípne primár, tak jde standby do write režimu, což je nevratná operace. Oracle začne generovat logy znovu od nových čísel. Aby se nahodila produkce, musí se udělat dump aktuálně běžící db, ten pak naimportovat do plánované produkce, která bude prozatím v režimu standby. Následně flush logů na storage, import do zamýšlené produkce (aktuálně ve standby režimu) a pak stopnout zálohu, přepnout produkci ze standby do write. Mno a když to je, tak je potřeba rozjet zase nějakou standby. Takže u aktuální produkce udělat opět dump a s ním rozjet novou standby. My máme standby dvě, jednu používám na zálohy (datapump), abych nezatěžoval produkci, druhou jako backup produkce.

Ano, jde to udělat i jinak. Tím jinak je Enterprise edice Oracle. Má to háček v podobě ceny, která je řády jinde, viz : Oracle : dostáváme na prdel (2). Ale třeba se k tomu také někdy dostaneme :). Takový funkční flashback by náš malý problém vyřešil hnedle jedle.

Výměna vadného controlleru je problém

Problém je v tom, že celé řešení bylo dodáno all-in-one a na backend moc nesahám, což se teď ukazuje jako né moc dobrá věc. Důvod je prostý milý Watsone, rozdílná verze fw mezi stávajícím zdravým controllerem a tím, co dodá support. Navíc nejde jednoduše srovnat verze jedním upgradem, protože je potřeba postupovat postupně podle major verzí (nejde moc přeskakovat). Jeden update žere 15-20min času a v našem případě bylo potřeba udělat update 3 s tím, že dodaný řadič jsem hodil do jiného storage a upgradnul jsem si u něj fw jinde. Každopádně první upgrade fw na primárním controlleru nedopadl moc dobře, byla tam asi nějaká chyba, takže jsme čekali, až doběhne timeout (pokusů bylo 20 po 2min, takže místo 15min upgrade trval první asi hodinu). Výsledkem bylo, že při první odstávce jsme nestihli okno a provedli jsme jen upgrade toho řadiče, co přežil. Při druhé odstávce jsme tam dodali i supportem dodaný řadič ve shodné verzi, ale mělo to háček, nechytily se u něj FC. Celý problém se mi podařilo nasimulovat i na druhém, shodném, storage. Tam se vyndaný a vyměněný řadič choval stejně. Nakonec jsem si na méně důležitém storage vyzkoušel, že řešením je otočit celé pole (ano, bavíme se o aktuálním fw).
Následovala další odstávka, kdy jsem na primáru otočil celé pole a FC se u vyměněného controlleru chytly, šlo u nich měnit nastavení atd.

Trochu pozitiva

Pozitivní je, že jsme přežili s nulovou ztrátou dat, backup funguje, čas překlopení zpět na produkční servery je ok, průběh taktéž ok. Příště líp naddimenzovat backup storage, líp proškolit support, aby se zlepšila odezva a bude to cajk :). Další bonus je, že jsem dostal jasný rozkaz, nedělat First Level Support a všechno přehazovat na kolegy a věnovat se vývoji, takže snad byl toto můj poslední výkřik : First level support - už mi z toho jebe.

Rekapitulace

- výpadek řadiče pole evidentně zvládá jen v případě simulovaného pádu (to jsme si zkoušeli, když nám řešení bylo dodáno)
- výpadek proudu může zapříčinit to, že se celé pole rozpadne, protože FW označí půlku disků jak Global Spare (nice featurka, doporučuji, i když možná už byla s posledním fw odebrána, nevím)
- když chcete vyměnit řadič, tak počítejte s tím, že to online nepůjde, i když manuál tvrdí opak
- upgrade fw online nezkoušejte, když jsem to dělal naposledy (z relativně nové verze na nejnovější s vypnutými VM, jen připojeným storage), tak jsem skončil na tom, že všechny volume byly odstaveny a dány do karantény (=odpojeny, nedostupné a vyndání z karantény jedině z cli)
- s pokročilými featurkami jako snapshoty, replikace atd. nemám zkušenosti, ale vzhledem k tomu, že to pole nezvládá ani základní věci, bych do toho asi nešel (navíc je tam asi jen linux s lvm, takže snapshot = smrtící nároky/pomalost)

Závěr

Nepamatuji si, že bychom někdy měli takový výpadek, ale to není ten důvod, proč jsem to sepsal. Tím důvodem je ten storage od HP a to, že co se nesere, do toho se musí sahat, protože když už se to má posrat, tak aspoň plánovaně a né neplánovaně.
Každopádně tento storage už se neprodává a dožívá, takže spíš než varování je to jen výkřik do tmy :-/.

Zdar Max        

Komentáře

[jiwopene]

To mi přřipomíná Win, který po pádu v logu má tu chybu často jako Info/Varování, ale to, že se spustil ze špatně odpojeného disku je Kritické (nebo tak nějak).

[R]

Jednoducho HP... Stacilo mi, ked som daval dokopy server DL380 G6 z jedneho zruseneho systemu. Zhanat firmware na nefunkcnom webe HP (404 not found), aby sa server nahodne nerestartoval.

Mame uz 10 rokov dve EMC CX3 a tam redundancia funguje perfektne. Raz odisiel storage procesor, cez multipath to pokracovalo bez vypadku s druhym. Pri jeho vymene netreba riesit verziu firmware - ak nesedi, automaticky sa preflashuje. Ak zacne niektory disk vykazovat vyssiu chybovost, tak sa automaticky nakopiruje na hot-spare este predtym ako uplne zlyha (nemusi sa robit rebuild). Upgrade FW diskov aj pola sa da robit bez vypadku.

Je vhodne mat osadene dva SPS moduly (interna UPS), pretoze ich zivotnost je obmedzena a v pripade poruchy sa vypne write cache. Vadny modul sa nemusi vymienat, staci ho rozobrat a vymenit (olovene) baterie za rovnaky typ.

Takze to funguje celkom pekne aj napriek tomu, ze vnutri su nejake embedded Windows. Toto plati aj pre radu VNX.

[malé chlupaté zvířátko]

Inu, bylo nebylo, kolem 9h (stalo se před pár týdny) měla přítelkyně telefonát, abych se vrátil z dovolené do práce. Já spal a měl u telefonu vypnuté vyzvánění a když se po 2 hodinách nedovolali, sehnali si číslo na přítelkyni.

někdo Ti to píše pod každým druhým blogem a musím se přidat: najdi si zaměstnavatele, který respektuje své zaměstnance a neselhává v řízení podniku

[Max]

Stažení z dovolené máš zadrátováno v zákoně. Zaměstnanec s velkou odpovědností na to pak může někdy narazit (když nastane nějaký velký průser). Mně se to stalo poprvé, ale vím, že třeba náš ředitel už svou dovolenou několikrát přerušil a vrátil se z ciziny.
Já byl v tu dobu naštěstí poblíž, ale klidně tě mohou stáhnout třeba i ze zahraničí, jen ti pak musí proplatit spoustu věcí.
Zdar Max

[malé chlupaté zvířátko]

no a co že to je v zákoně

zaměstnavatel selhal v tom, že spoléhá na jedinou děvku pro všechno

předchozí blog "už mi z toho jebe" hodně vypovídá

[trekker.dk]

Já bych se spíš pídil po tom, jak si sehnali telefonní číslo na přítelkyni...

[Max]

Zná se s několika lidmi z firmy včetně jednoho šéfa, takže nic tajného.
Zdar Max

[?]

A víš o té povinnosti dopředu? Co kdybys odjel na dovolenou někam do pralesa a neexistovala možnost tě kontaktovat? Znamená to, že dokud jsi v zaměstnaneckém poměru, tak na skutečnou dovolenou prostě nemáš nárok a musíš být k zastižení? Neřeknu, kdyby to tak bylo vzájemně dohodnuté, ale jestli je to tak implicitně pro každého, tak je to trochu WTF.

Co vim, tak specialisti to tak maj všude, zajistit povinnou zastupitelnost.
Druhá věc je, když má někdo práci jen jako zaměstnání ...

[Max]

Povinnost platí pro každého, je to obecný zákon. Online musíš být jen v případě pohotovosti (tu mám od minulého měsíce také), to se pro dovolenou nevztahuje. Když tě zaměstnavatel nesežene, jeho problém.
Když tě stáhne z dovolené a vzniknou ti v návaznosti na to nějaké náklady, zaměstnavatel je povinen ti je uhradit.
Zdroj viz třeba :
Vrať se z dovolené do práce, volá šéf. Náklady musí firma proplatit
Zaměstnanec z dovolené být odvolán může, nebude to ale zadarmo
Zákoník práce § 217
Zdar Max

[ehm]

Takže by bývalo stačilo přítelkyni říct, ať oznámí, že se ti taky nedovolala, a v klidu spát dál?

[xvasek]

Nepřemýšleli jste o nějakých high-availability řešeních na úrovni virtualizace? Pravda sice je, že zrovna ke storage se při HA řešeních často přistupuje s tím, že "to je tak drahé, že už se to posrat nemůže", ale tak to už je na vás si to pošéfovat.

[Max]

HA je pořešeno více nody, ale je ještě třeba HA pro storage. Jenomže HA storage v rámci dvou lokalit má trochu větší požadavky. Člověk si nevystačí s dvěma optickými páry, ale potřebuje aspoň 4 páry a nejlépe ještě dvěma trasama.
Mno, uvidíme příští rok.
Zdar Max

[R]

Problem je v tom, ze tie najdrahsie a najviac enterprise riesenia sa dokazu posrat casto dost nestastnym sposobom. SW je zabugovany a nikto ho netestuje... Nam sa v novej instalacii v priebehu mesiaca posrali dve redundantne veci - padol cely VMware cluster a prestal fungovat cely reundantny Cisco switch.

Takze aby bola redundancia skutocna a nielen virtualna, pridal sa jeden stary 1U server a DHCP a DNS bezi redundantne na nom a na virtuali z toho VMware. Takze ked teraz cely VMware spadne, funguje aspon siet (mne to staci, ostatne si vyzerie dodavatel).

[Heron]

SW je zabugovany a nikto ho netestuje...

Asi tak, 2x za dva měsíce se nám sekly Cisco 10Gbe switche s cenovkou 2x100tis. Po prvním pádu jsme přeflašli firmware. Opravené bugy půl stránky, známé neopravené bugy 3 stránky. Po druhém pádu už nebylo co flashovat, protože login na web rozhranní se zasekne na 70% a dál nejde. Přístup přes ssh naštěstí funguje.

[R]

Ten nas switch bol tiez nieco velke a drahe. Pocul som uz pred rokmi od cloveka, co robil len s Ciscami: cim vyssi model, tym vacsie problemy.

[Pan_Filuta]

Osobně doporučuji Cisco řadu switchů SG300, switch za 15 000 Kč a ve firmwaru měl skvělou vlastnost, že po určitém počtu hodin se vykašlal na ARP tabulku a přepnul do HUB módu - všechnu komunikaci posílal na všechny porty.

Zjišťovat proč během zálohování kolabují tiskárny a WIFI routery byla zábava

[trekker.dk]

Tohle jsem u nějakých Juniperů viděl taky. Zpracování přebytečných paketů na strojích, co v tom byly připojené, žralo výkon 3 procesorů.

[Max]

A pamatuješ si verzi FW, u které to dělalo, nebo u které to opravili?
Díky
Zdar Max

[pc2005]

OMG

[deda.jabko]

jedno nalučování, při kterém se mění primární klíč asi ve 20 tabulkách

Nejak nechapu dve veci. Co je to nalučování a proc se pritom meni primarni klic ve 20 tabulkach?

[xvasek]

Moje odpověď: „V odpověď na otázku: „Co je to nalučování a proc se pritom meni primarni klic ve 20 tabulkach?““ Piš větší! „…je řada termínů, jež je třeba definovat. Co je to klíč, proč se mění, proč je primární a proč je tak často spojován s nalučováním?“

[Max]

Je to pojmenování firemního procesu, pro účel blogu nepodstatná věc. Primární klíč se při této akci mění proto, protože špatný návrh db, který je dán historií vývoje.
Uvedu příklad : máš třeba českou poštu, která ti vygeneruje nějaké číslo zásilky. Mno a v našem případě je toto číslo zásilky primární klíč na nemálo místech. Když tedy chceš něco s tím číslem provést (třeba změnit), tak je pak problém na světě. Struktury jsou tak složité (resp. i místa, kde je to zadrátováno), že změna na snesitelnější schema nejde jen tak lehce udělat a je třeba spousty změn bokem. Samozřejmě se k tomu míří, ale spousta věcí ještě chybí.
Zdar Max

[Salamek]

Uh vy mate externi identifikatory jako primarni klice ? Kterej debil to navrhoval ? Mam snad vlastni primarni klic (ID nebo UUID) a externi identifikatory v UNIQUE sloupci vedle... ID/UUID pouzivam pri praci v internim IS a externi identifikator jen pro praci s externi sluzbou

[snajpa]

OpenZFS. A pokud chces osobniho ZFS negra na telefonu, tak Nexenta. Proc kdo dneska kupuje takovyhle smesny hracky?

[snajpa]

Nedocetl jsem to uplne cely, zasekl jsem se u toho "neupgradovat firmware v pripade problemu" a to samotny mi teda prijde... no nevim, ja tohle kupovani takovychhle poli proste nechapu. Nevidel jsem dost dlouhou dobu use-case, ktery by ZFS nepokrylo. Ale docela rad bych videl, jestli nahodou nekdo nema realny technicky duvod takovou vec koupit.

[Max]

Je to železo na výměnu, máme to 5let. Nově jsme šli do NetAppu. Poptával jsem i Nexentu a jen za licence bez železa si řekli o víc, jak milion. Fakt nechápu, co hulí a komu dělají konkurenci, resp. kdo to kupuje. NetApp byl mnohem levnější jak Nexenta a taktéž byl levnější, jak storage od HP.
Storage se ZFS mám jeden, asi 70TiB pole, na zálohy a pár dalších věcí, je to docela vytížený (běží mi tam backup oracle + se tam točí zálohy VM a další věci), mám v tom sata disky 4TB WD RE4. Mám tam na zkoušku jak Pool poskládaný z mirrorů, tak i RAID-Z3.
Každopádně ten server se ZFS mi jednou za x měsíců padne a nevěděl jsem proč, logy mlčely. Po forwardování na vzdálený syslog to zatím vypadá, že problém je s řadičem (Areca-1883, nejnovější fw, disky v passthrough, cache taktéž v passthrough).
Komunikoval jsem s výrobcem řadiče, ale nic kloudného jsem se nedozvěděl. Nasimulovat se mi to nedaří.
Co ty používáš za řadiče v serveru pro ZFS?
Zdar Max

[Heron]

Areca-1883 se nám sekala (fw 1.52) při velké zátěži. Po update na fw 1.53 nebo 1.54 už se nám to neporařilo shodit. Jestli se to seká i při novým fw, tak už vážně netuším, co používat.

[Max]

Mno, mám podezření, že to možná bude nadměrným zatížením. Jednou se to vysralo v týdnu, to mi nepřišlo nějak zatížené, ale dočetl jsem se, že by mohla mít Areca problémy se SMARTem, tak jsem ho vypnul. Ale nepomohlo. A o víkendu probíhá dump jedné 5TiB databáze a Veeam počítá syntetický full backup z rozdílových záloh.
Asi to nakonec skončí koupí čistě HBA od LSI, těch 5kkč bez DPH nebude problém schválit.
Jenomže ty nejedeš ZFS, takže potřebuješ řadič s cache, baterií atd., co ti sníží IOPs na diskách, ne? Já jedu ZFS, takže tam je naopak cache na řadiči nežádoucí. Používám tedy jen RAID1 na dvou diskách pro systém, zbytek jedu ZFS v passthrough.
A nejvíc mně štve, že při flashi řadiče ztratí řadič částečně nastavení. Prostě jsem měl 40 disků v passthrough a po flashi byly všechny venku, jen ty, co byly v RAIDu řadič nadetekoval správně, ty původně v passthrough jsem musel znovu naklikat. Při takovém počtu je to pak zbytečný voser.
Zdar Max

[Heron]

Jenomže ty nejedeš ZFS, takže potřebuješ řadič s cache, baterií atd., co ti sníží IOPs na diskách, ne?

Nejsem oprávněn popisovat infrastrukturu ve firmě, takže sorry. Stejně bych to nepopisoval, protože to není (jen) moje dílo a s kdečím nesouhlasím.

Na soukromé účely bych si HW raid (po všech těch zkušenostech) nikdy nepořídil. Tam jedu čistě HBA a zbytek softwarově.

A nejvíc mně štve, že při flashi řadiče ztratí řadič částečně nastavení.

Tož to se nám nestalo a těch areca řadičů se flashovalo už docela dost.

[trekker.dk]

Na soukromé účely bych si HW raid (po všech těch zkušenostech) nikdy nepořídil. Tam jedu čistě HBA a zbytek softwarově.

Na to zrovna u toho zmíněného LSI za 5kKč (v Linuxu driver megaraid_sas) bacha - v JBOD režimu má tendence tuhnout.

[snajpa]

Za jakych podminek? Nenarazil jsem na to ani jednou. Pokud teda mluvime o tech LSIckach, ktere jsem zminoval - coz asi ne - protoze muj driver je mpt2sas.

[Max]

Dle google je ten driver pro řadič, který umí HW raid, nejedná se o HBA, takže se Trekker asi spletl.
Zdar Max

[trekker.dk]

Abych se přiznal, já tomu nerozumím. Podle toho, co jsem našel, HBA znamená, že každé fyzické zařízení je v OS vidět jako jeden disk. To tenhle řadič - je to Avago 3108* - splňuje, když se přepne do JBOD režimu. Pokud to tak není, tak sorry

* AFAIK je to prakticky totéž, co LSI - třeba podle autora toho mpt2sas řadiče v modinfo

[R]

megaraid_sas je driver pre full RAID radice od LSI, cize tie, co maju na doske RAM, podporuju RAID 5, 6, cache, bateriu. Tieto radice sa nedaju pouzit ako skutocny HBA, pristup ide vzdy cez firmware radica. Patria sem napr. DELL PERC5, PERC6 aj perc H7xx.

Potom su jednoduche radice od LSI - bez RAM, bez cache, bez baterie. Mozu mat nahraty FW iT alebo iR. Ak tam je iR, tak podporuju RAID1, pouziva sa driver mptsas (radic sa nazyva napr. DELL SAS 5/iR). S firmwarom iT nepodporuju ziadny RAID a tvaria sa ako obycajny radic (HBA) pre jednotlive disky. Tento mod je vhodny pre pouzitie SW raidu, ZFS alebo pre testovanie diskov.

[Max]

A cena je poloviční, není problém s funkčností SMARTu, teplotama atd.
Zdar Max

[trekker.dk]

My to dostáváme jako kompletní balení s celým serverem - Supermicro. Že bych z toho měl nějakou radost, to nemám - mně by snad klidně stačil normální SATA řadič integrovaný na desce, kdyby teda někdo dělal nějaký s 12 porty (nebo 24 pro 2.5" disky)

Ale se smartem problém teda nemám, akorát se při kontrole návratové hodnoty smartctl musí ignorovat jeden bit.

[trekker.dk]

#38

Řekl bych, že za normálních podmínek. Prostě se to v poklidu fláká, podle muninu nic moc provoz řekněme 100iops na SSD SW RAID, načež ten server vytuhne, load vyskočí na pár stovek, což se po chvíli opraví samo. Žádné chyby v dmesg, nikde nic. Metodou zkusíme do něčeho šťouchnout a možná se něco stane jsem pro ty disky nastavil queue_depth na 1, což - zdá se, aspoň zatím - pomáhá.

[Max]

Chápu, nicméně z toho, že používáte Arecy, jsem usoudil, že ZFS asi nejedete, protože jsou pro něj zbytečný. Já jsem koupil Arecu jednak kvůli doporučením, ale také jsem chtěl používat její hw raid pro pár disků a nějaké pokusy.
Ohledně ztráty nastavení, disky, co byly v raidu se neztratily, šlo fakt jen o disky v passthrough, ale i tak je to oser.
Zdar Max

[Heron]

Tak my nemáme jen jeden storage server, takže kromě areca toho používáme trochu víc. To je asi patrné i z mých dřívějších komentářů, kde jsem nadával asi tak na 20 různých hw raidů. Včetně toho megaraid (to byl tuším Adaptec), u něhož se nám kdysi stalo, že po failu jednoho disku (v raid 5) tam nový disk prostě přidal, aniž by se obtěžoval resyncnout pole.

Jinak poslední rok se testoval CEPH (což teda moc nedopadlo, to se nám taky vždy podařilo na počkání shodit - všechny tři poslední stable verze z čehož teda 11 byla jednoznačně nejhorší). (Nehledě teda na to, že když to zrovna náhodou jelo, tak výkon byl dost nic moc a z toho HW samotného by se normálně podařilo vytáhnout tak cca 9x tolik (a to nepočítám ty ssd co tam byly jako osd cache). Takže máme toho víc, testujeme, hledáme, něco nasazujeme, něco ne. Dřív či později se to všechno dostane na můj blog (pokud to má význam vůbec zmiňovat).

Já nejsem moc přítel toho, co máš ve worku ty, tedy více méně osamělé nabušené stroje, já raději stavím více do jisté míry nezávislých strojů, které jsou schopné se za určitých okolností zastoupit. Podle mě se dá infra stavět i jinak, ale musí to být stavěno od spodu, tedy i včetně aplikací (někdo se tady ptal na možnost HA pomocí virtualizace, do toho bych třeba vůbec nešel).

[trekker.dk]

to se nám taky vždy podařilo na počkání shodit

Nějaký postup, co si laskavý čtenář může vyzkoušet doma?

někdo se tady ptal na možnost HA pomocí virtualizace, do toho bych třeba vůbec nešel

Proč ne? AFAIK třeba VMware tohle má zabudované a neslyšel jsem, že by si na to někdo stěžoval.

[Heron]

Nějaký postup, co si laskavý čtenář může vyzkoušet doma?

Hledali jsme nejlepší způsob, jak ten storage dostat do vmware. Zkoušelo se připojit RBD přes iSCSI (a ve vmware vmfs a na tom vmka). Potom jsme testovali rbd přímo v těch vmkách (tj vmka bootovala z malého disku a potom si připojila rbd a na tom byl oddíl pro data). Potom s verzí ceph 11 a 12 se testoval cephfs, jednak přes NFS, vmware a vmka na tom NFS a opět přimountovat přímo cephfs do těch vm.

No, během toho se tam pouštěly testy na těch vmkách (paralelně třeba na 12 vm), zejména pgbench (to používám jako univerzální test - mám v hlavně tps různých systémů a kolik je tak typická hodnota). A v podstatě stačilo počkat pár hodin a potom ceph lehl. A to v jakékoliv konfiguraci připojení těch vm (nfs, iscsi, rbd, cephfs). Potom teda kolega přešel na testy rovnou z fyzického stroje, hodil tam bonie++ a za pár hodin to opět lehlo.

Kde "to" byla nejspíš nějaká vrstva mezi OSD a klienty (možná librados).

Navíc ono to ani nefungovalo správně. Od verze 11, kde je cepfs považován za stabilní byl ale stále doporučován jeden metadata server s tím, že by se měl po jeho pádu automaticky nahodit druhý. Nikdy se nenahodil. Metadata server spadl a cephfs prostě nebyl. Od verze 12 by mělo být možné používat více metadata serverů.

Takže recept je nejspíš několikahodinová vysoká zátěž náhodných přístupů.

[trekker.dk]

Potom jsme testovali rbd přímo v těch vmkách (tj vmka bootovala z malého disku a potom si připojila rbd a na tom byl oddíl pro data).

Pokud to bylo kernelovým /dev/rbd, tak jestli si správně pamatuju, na loňských Linux Days to někdo nedoporučoval - že prej při jejich testování ten kernel dokázal deadlocknout souběžný přístup ze dvou procesů na jedno blokové zařízení (nebo to bylo z jednoho procesu?) Pochopil jsem to tenkrát tak, že vývojáři cephu se rozhodli, že vyvíjet pro kernel je těžké, a na kernelového RBD klienta se víceméně vykašlali. Ale to je jenom moje spekulace, nic víc.

Zkoušelo se připojit RBD přes iSCSI

Jestli to znamená /dev/rbd v nějakém linuxovém stroji, který to pak exportuje jako iSCSI, tak je to vlastně totéž jako předchozí případ.

Od verze 11, kde je cepfs považován za stabilní byl ale stále doporučován jeden metadata server s tím, že by se měl po jeho pádu automaticky nahodit druhý. Nikdy se nenahodil. Metadata server spadl a cephfs prostě nebyl.

No, pokud se pamatuju, tak podle dokumentace "měl by se" znamená, že tam má být (třeba) pacemaker, který to udělá. Já jsem to neřešil, protože pacemaker úplně nemusím, cephfs pro mě není kritický, takže jsem si počkal, než budou podporovat i víc souběžných metadata serverů.

Takže recept je nejspíš několikahodinová vysoká zátěž náhodných přístupů.

To by se asi vyzkoušet dalo. Já na tom momentálně mám akorát jedno (K)VM, které má integrovanou podporu pro RBD - běží to stabilně, ale moc to nedělá - munin (takže brát s rezervou) ukazuje řádově stovky iops při práci se zálohami, ale je to nárazové a mezitím se neděje nic.

[Heron]

Tak jestli je tohle pravda, tak je ceph prakticky nepoužitelný. Nevím, jak je na tom ten objektový přístup (ten S3 REST API), to se u nás nevyužije, ale pokud nefunguje RBD ani CephFS, tak je to je na nic. Navíc teď jsem někde četl, že ten objektový přístup moc dobře neškáluje (ale to nemám jak otestovat).

Já na tom momentálně mám akorát jedno (K)VM, které má integrovanou podporu pro RBD - běží to stabilně, ale moc to nedělá - munin (takže brát s rezervou) ukazuje řádově stovky iops při práci se zálohami, ale je to nárazové a mezitím se neděje nic.

Implementace RBD pro KVM je jiná než v kernelu?

No naše testy běžely kolem 3tis. iops. Včetně SSD OSD cache. Což je teda dost bída. 3 stroje (jo, to je docela málo), 6xSSD (každý stroj dvě) a disky (každý stroj cca 24 disků), pro každou skupinu disků jedno SSD. Co se týče RAM, tak 128GB+192GB+192GB (takže min. čtení bych očekával z cache - ani to se nepotvrdilo). Vše na 10GBe síti. Sekvenčně to dalo z jednoho RBD cca 400MB/s, když se to pustilo paralelně, tak 800MB/s. To se dá považovat za maximum na dané síti. Proč má jedno RBD tam malý výkon nevím. Ale sekvenční testy jsou celkem na nic. Random testy z toho dokázaly vytáhnout max 3tis. iops. To už to jedno SSD dá mnohem víc.

[Max]

Jen pro info, nějakých 5000 IOPs dám na tom jednom NetAppu na 24xSAS diskách.
Zdar Max

[Heron]

Jo, to odpovídá. 15k SAS má nějakých 250iops. 5000/24 = 208.

Při stavbě storage pro jednoduchost počítám s SATA 100iops, SAS 200iops. Ono to umí víc, alespoň jsou tam rezervy.

[Max]

No, hlavně to není jen o diskách, ale i tom, že ten storage má v sobě nějaký ssd a další věci, které pomáhají vyrovnat zátěž stejně jako to dělá ZFS s ram a přídavným SSD pro slog, dopředné a zpětné cachování atd.
Rezerva by tam tedy měla být. Každopádně NetApp mně i v některých věcech zklamal, ale to pak vydám v podobě článku.
Zdar Max

[MP]

Pokud pri 3 strojich je repl=3 a data jsou ulozena jen na jednom pg (resp. spise osd), tak vykon toho rbd by tomu i odpovidal - cte se jen z jednoho osd (6gbps sata/sas per osd) (az na ty iops).

Ja delal testy s ceph jewel na pure ssd (sata S3510/nvme S3610, 2 per node, no osd cache) a bylo tezce znat, jak se ovlivnuje vykon tim, ze tam bylo xfs a ne bluestore, zvlaste pri randrw. Pozor, testy jsou repl=2.

napr:

NVME disky pres 10G network, 4x VM (data per VM -> per 4x VM):

read: bw=190MBps, iops 46k -> ~800MBps, 180k iops

write: bw=25MBps, iops 6k -> ~100MBps, 24k iops

rw: bw=37/12MBps, iops 9k/3k -> ~148/48Mbps, 36k/12k iops.

Data byla defakto ulozena na jednom osd per node z tech dvou osd. Zmerena hodnota pro pure NVMe bez cephu atd byla read/write/rw 302k(quickspec 450k)/291k(?? quickspec 50k)/167k+55k(quickspec 130k) iops.

[trekker.dk]

Tak jestli je tohle pravda, tak je ceph prakticky nepoužitelný.

No, co se chlubí, tak to firmy používají ve velkém, takže tady možná chybí "pro nás"

Implementace RBD pro KVM je jiná než v kernelu?

Jo. Knihovna pro RBD v Qemu block-rbd.so podle ldd používá librados.so.2, tj. čistě user space kód, který se nejspíš trochu víc vyvíjí a udržuje. Host ty disky vidí jako SCSI disky, takže jeho jaderné RBD vůbec nepřijde ke slovu.

No naše testy běžely kolem 3tis. iops. Včetně SSD OSD cache.

Co přesně byla ta "OSD cache"? Z toho "pro každou skupinu disků jedno SSD" mi to zní, že to nebyla cache, ale journal device - pro každý disk jeden oddíl na tom SSD. Nebo to skutečně byla cache, tj. tohle http://docs.ceph.com/docs/jewel/rados/operations/cache-tiering/ ?

[trekker.dk]

To ticho zní jako zákaz přiznat se

[Heron]

Přiznat se k čemu konkrétně?

No, co se chlubí, tak to firmy používají ve velkém, takže tady možná chybí "pro nás"

Tak v původní větě byl kondicionál. Pokud je pravda to, co jsi tvrdil ty, tak je to nepoužitelné. Ano, z mého pohledu. Komentář vždy píšu z mého pohledu.

Knihovna pro RBD v Qemu block-rbd.so podle ldd používá librados.so.2, tj. čistě user space kód

Ok, ale to by nám aktuálně nepomohlo, my jsme ta data potřebovali exportovat z toho clusteru, takže NFS nebo iSCSI.

Co přesně byla ta "OSD cache"?

XFS journal.

[trekker.dk]

Komentář vždy píšu z mého pohledu.

To nejspíš každý - ale i tak je mezi "ceph je prakticky nepoužitelný" a "ceph je pro nás prakticky nepoužitelný" docela rozdíl.

XFS journal.

OSD cache a XFS journal mi teda přijdou jako dvě docela různé věci

Každopádně jsem se chtěl dobrat k těm 3tis. iops - mně to totiž jako tak slabý výkon nepřijde, vzhledem k tomu, že při dostatečně dlouhém testování u zápisu nakonec zaplníte jakoukoliv cache a zápis se omezí na rychlost těch rotačních disků, kde dá nějakých 100 iops jeden. Tj. maximální teoretická hodnota je nějakých 2400 iops pro 3 repliky a 3600 iops pro 2 repliky. Z vašeho popisu (nebo teda spíš absence popisu) není jasné, jestli tam bylo nebo nebylo dedikované journal device pro OSD, ale jestli ne, tak IIRC s filestore nejdřív zapisujete do žurnálu a pak na trvalé umístění (obojí na stejném disku), takže 3000iops nakonec není tak špatná hodnota.

[Heron]

No ve srovnání s tím, co z toho HW lze vytáhnout jiným způsobem mě osobně 3tis. iops přijde dost málo.

3*24 15k SAS disků by v hrubém výkonu (250 iops na jeden disk) mělo dát 18tis. iops. Pokud budu počítat 200 iops (což ty disky dají víc), tak je to stále nějakých 14 tis. iops.

Náš běžně používaný storage (který je na tom hw mnohem hůř, jak ten testovaný ceph cluster) dá přes NFS 10 tis. iops.

A to vůbec nemluvím o těch SSDkčách. Intel SSD 3700 dá s prstem v nose samo 20tis. iops.

Takže když to spočítám, hrubý výkon všeho by se dal odhadovat na 134400 iops. Jesti z tohoto HW ceph vytáhne jen 3tis. tak je to (opět z mého soukromého pohledu), dost málo. To ten HW jsem schopen využít jinak a lépe.

[trekker.dk]

3*24 15k SAS disků by v hrubém výkonu (250 iops na jeden disk) mělo dát 18tis. iops. Pokud budu počítat 200 iops (což ty disky dají víc), tak je to stále nějakých 14 tis. iops.

Tohle jsou ale přece hrušky a jablka, číslo relevantní akorát pro raid 0. Ve chvíli, kdy z těch disků poskládáte raid 10, jste pro 2 kopie dat u zápisu na nějakých 7 tisících (dělím těch 14.) Pro 3 kopie na teoretickém maximu 4800 iops. Ceph ve výchozím nastavení ukládá všechna data ve 3 kopiích, takže jste na těch 4800 přinejlepším - když nemáte dedikované journal device, tak mezi 4800 a polovinou z toho.

A to vůbec nemluvím o těch SSDkčách. Intel SSD 3700 dá s prstem v nose samo 20tis. iops.

Jenže ho používáte jako cache nebo XFS journal nebo co, takže při dlouhém testu nevyhnutelně dojdete do stavu, kdy na něm dojde místo, protože writeback na rotační disky nestíhá - to už jsem psal. Samozřejmě si pomůžete na tom, že se přehází jednotlivé I/O operace, ale realisticky se výkonem budete pohybovat na straně toho rotačního disku.

Takže když to spočítám, hrubý výkon všeho by se dal odhadovat na 134400 iops. Jesti z tohoto HW ceph vytáhne jen 3tis. tak je to (opět z mého soukromého pohledu), dost málo. To ten HW jsem schopen využít jinak a lépe.

To máte dobré, ale i tak bych se zdráhal vynášet soudy - protože z dostupných informací bych rohodně nedal ruku do ohně za to, že jste ten Ceph měli dobře nastavený.

[Heron]

Tohle jsou ale přece hrušky a jablka

Je to ukazatel toho, co je teoreticky dostupné a lze to porovnávat s tím, co je dostupné i prakticky. Jestliže se dosáhne na polovinu toho (RAID10 - 100% výkon při čtení, 50% výkon při zápisu), tak je to pořád lepší než 20% při zápisu a nepřesvědčivé čtení.

To máte dobré, ale i tak bych se zdráhal vynášet soudy - protože z dostupných informací bych rohodně nedal ruku do ohně za to, že jste ten Ceph měli dobře nastavený.

No to já taky ne, ale i to ukazuje na kvalitu cephu. Kdyby bylo po mém, tak se celé testování cephu zastaví hned v počátku (a ušetřím si i tuto diskusi), protože podle oficiální "quick start" dokumentace to nebylo vůbec možné nainstalovat (příkazy měly jiné parametry, některé ani neexistovaly apod.) Už jen toto je v mém hodnocení stopka pro nasazení něčeho tak důležitého, jako je storage "pro všechno". Když není v pořádku ani dokumentace, tak podle čeho se potom chcete řídit v provozu, když se něco stane.

Kolega, co měl větší trpělivost, to nakonec rozjel do stavu, kdy už to teda fungovalo. Jako co se týče integrity dat, trápili jsme to hodně, vytahovali disky, vypínali nody, killovali procesy, všechno ustál. Klobouk dolů. V té době jsem k tomu už dostával důvěru, ale přišlo na řadu testování napojení na okolní svět a to se teda nepodařilo spolehlivě zařídit.

[trekker.dk]

RAID10 - 100% výkon při čtení, 50% výkon při zápisu

33% výkon při zápisu. Buď to, nebo řekněte, že jste měli v tom cephu přenastavený počet replik. Jasně, 33% je taky lepší než 20%, ale už ne o moc, něco vás stojí fakt, že to není raid, a taky jsme se pořád ještě nevypořádali s potenciálními chybami v návrhu/nastavení.

Kdyby bylo po mém, tak se celé testování cephu zastaví hned v počátku (a ušetřím si i tuto diskusi)

Tak jestli vám vadí diskuze, tak se na ni můžeme vykašlat. Svět se nezboří.

protože podle oficiální "quick start" dokumentace to nebylo vůbec možné nainstalovat

Jo, na něco takového si vzpomínám taky. Zase tak velký problém jsem s tím neměl, protože ten quickstart návod mi přišel, že to udělá něco nějak a já nebudu mít tušení, co - nic moc výchozí pozice právě pro ty případy, kdy se něco stane. Takže instalovat podle kapitoly o manuální instalaci mi zase tak nevadilo. Navíc takhle zpětně mi přijde, že ten quickstart je návod pro někoho, kdo si s tím chce jenom pokusně hrát.

V té době jsem k tomu už dostával důvěru, ale přišlo na řadu testování napojení na okolní svět a to se teda nepodařilo spolehlivě zařídit.

Jo, jestli hledáte něco pro VMWare a cephfs vám nefunguje ani na verzi 12, tak ceph není pro vás. Aspoň než si výrobci komerčních věcí všimnou a dopíšou podporu.

[Heron]

33% výkon při zápisu

RAID10 má 50% výkon při zápisu.

Buď to, nebo řekněte, že jste měli v tom cephu přenastavený počet replik.

Ne, počet replik byl defaultní, tedy 3. Akorát nevím, proč bych měl každé číslo vztahovat k tomu, jak to zrovna má ceph.

Jo, jestli hledáte něco pro VMWare a cephfs vám nefunguje ani na verzi 12, tak ceph není pro vás.

Tak ono to není o vmware. Sám jsi v této diskusi psal, že RBD v kernelu se může seknout. Tím se fakticky vylučuje export blokového zařízení (takže i věci jako iscsi, nebo třeba gfs2 nebo ocfs2 - mít nad tím blockdevice clustrový fs). Dál zbývá jen cephfs a ten objektový přístup (ten se mi koncepčně líbí úplně nejvíc, ale taky pro něj nemáme využití). No CephFS ve verzi 10 měl pouze jeden metadata server (to mi pro produkční prostředí nepřijde úplně nejlepší) a ve všech testovaných verzích se nám ho podařilo shodit (ale podrobnosti nevím, já to nedělal). Takže bez ohledu na vmware, se z toho prakticky ta data nedají dostat.

Aspoň než si výrobci komerčních věcí všimnou a dopíšou podporu.

Viz výše. Nevím, co by ta podpora měla zahrnovat. iSCSI používám běžně i mezi linuxama, je to prostě univerzální prostředek jak dostat blokové zařízení po síti někam jinam. (O NBD samozřejmě vím, ale to stále neřeší problém RBD v jádře).

[trekker.dk]

Ne, počet replik byl defaultní, tedy 3. Akorát nevím, proč bych měl každé číslo vztahovat k tomu, jak to zrovna má ceph.

Tak jako hlavní důvod bych viděl, aby se srovnávalo srovnatelné. Ten RAID má 2 kopie dat, když vám jeden disk umře a během resyncu umře druhý*, tak jste přišel o data. Ceph má s výchozím nastavením 3 kopie, tj. poskytuje větší redundanci a to má logicky nějakou cenu.

Když si sestavíte RAID 10 (nebo jak se to pak bude jmenovat) se 3 kopiemi dat, aby se srovnávalo srovnatelné, tak na těch 50% výkonu taky nedosáhnete.

Takže bez ohledu na vmware, se z toho prakticky ta data nedají dostat.

No to je právě to, co záleží na prostředí. Virtualizace s QEMU/KVM třeba nemá problém. A samozřejmě jsou tu věci specifické pro konkrétní aplikace, třeba nedávno na té suse akci prezentovaný storage modul pro Dovecot, který Ceph využívá jako key-value databázi na ukládání mailů.

Nevím, co by ta podpora měla zahrnovat.

No kde bych primárně očekával, že se podpora objeví, by mohl být ten VMWare. I když ti vlastně AFAIK nějakou vlastní softwarově definovanou storage mají taky, takže se do toho možná hnát nebudou, protože proč si podkopávat vendor lock-in. Ale jinak když mohou existovat iSCSI karty, klidně by mohly existovat i RBD karty (ne že bych to viděl jako pravděpodobné, ale šlo by to.)

* automaticky počítám s tím, že to bude "ten správný", protože zákon schválnosti**

** no dobře, tady by se dalo namítnout, že u RAID10 mám šanci, že umře jiný disk a o data nepřijdu, zatímco u cephu, když při 2 replikách umřou dva disky, tak se nějaká data ztratí stoprocentně. Na druhou stranu u toho RAID10 se musí synchronizovat celý disk na jiný disk, zatímco ceph bude synchronizovat z každého zbývajícího disku jednu část dat a souběžně. Pro tu 3x24 konfiguraci to vychází, jestli se nepletu, na 1/48 podíl na každý relevantní disk, tj. pro 1TB disky každý zbývající disk musí přečíst 21GB dat. IMO se ty pravděpodobnosti katastrofy vyrovnají.

[Heron]

Tak jako hlavní důvod bych viděl, aby se srovnávalo srovnatelné.

Tak taky se na ten systém můžu podívat jako na black box. Tady máš data, nějak je ulož. Nehledě na to, že existují systémy s možností více replik dat, ale potvrzený zápis se klientovi vrátí dřív, třeba při provedených zápisech na dvě zařízení (a další repliky si to udělá asynchronně).

Virtualizace s QEMU/KVM třeba nemá problém. A samozřejmě jsou tu věci specifické pro konkrétní aplikace, třeba nedávno na té suse akci prezentovaný storage modul pro Dovecot, který Ceph využívá jako key-value databázi na ukládání mailů.

Jo, ta prezentace německé pošty je pěkná. Akorát nevím, jestli je skutečně cílem cephu to, aby si každý psal vlastní konektor do cephu a ten cephfs a rbd (a ostatně i ten objektový přístup - v té prezentaci se píše, že to příliš neškáluje) jsou tam jen na ozdobu.

[trekker.dk]

Tak taky se na ten systém můžu podívat jako na black box.

Tak to bych si u sebe dovedl představit akorát u něčeho, na čem mi nezáleží Když si teda můžu vybrat

Akorát nevím, jestli je skutečně cílem cephu to, aby si každý psal vlastní konektor do cephu a ten cephfs a rbd (a ostatně i ten objektový přístup - v té prezentaci se píše, že to příliš neškáluje) jsou tam jen na ozdobu.

No, vzato kolem a kolem, rbd a cephfs jsou taky konektory do cephu - u RBD je klíčem identifikátor bloku, hodnota je ten blok. Cephu je to jedno, rozdíl je akorát to, že oproti osatním jsou tyhle dva způsoby využití trochu rozšířené přímo v tom, co ceph dodává - cephfs má metadata servery a RBD nástroje na správu těch blokových zařízení. Takže bych řekl, že je to přesně záměrem - nevyhovuje ti nic, co máme zabudované? Udělej si vlastní implementaci.

[Max]

Nemám osamělé nabušené stroje. Současný stav je, že mám dva Netapp storage, mezi nimiž běží replikace (replikuji SVM - virtuální server včetně všech volume, který v rámci NetAppu zajišťuje NFS službu a další). Nad tím primárním mám ESXi cluster ze třech nabušených serverů, jeden může jít down a zbývající dva to utáhnou. V záložní lokalitě mám další ESXi cluster, kde mám dva nabušené stroje a přibyde další. V případě pádu primární lokality se aktivuje SVM na backupu, čímž se nahodí IP a vše okolo a nastartují se VM v záložní lokalitě na záložním clusteru.
Taktéž není problém spouštět VM v záložní lokalitě z primárního storage a naopak.
Pak mám backup storage, ze kterého je možné taktéž spouštět VM.
Bokem je Oracle RAC ze dvou serverů, který se replikuje pomocí transakčních logů do vzdálené lokality, kde běží standby.
Největším problémem jsou licence. Ty hází klacky pod nohy neuvěřitelně. A těm se přizpůsobuje hw řešení. To ty s Postgresem asi neznáš. Je to smutné, ale dělat s tím nic nejde. Resp. jsou tři možnosti. Buď utratit kvantum peněz za licence, které se reálně ani nevyužijí, nebo se přejde kompletně na OSS, nebo se musí hw řešení HA a dalších věcí přizpůsobovat licencím.
Pokud se používá klientská APP, co si umí HA řešit, tak je to také řešení, ale to taktéž není náš případ :-/.
Zdar Max
PS: osamělé stroje vlastně mám, slouží jako testovací

[trekker.dk]

Největším problémem jsou licence. Ty hází klacky pod nohy neuvěřitelně.

<napřesdržku>Tak, je to Oracle, to za ty peníze stojí, protože nikdo jiný tak dobrou databázi vyrobit neumí, ne?</napřesdržku>

[Max]

Ale nejde jen o OracleDB, máš pak Oracle Aplikační server, který je také na CPU, pak máš MSSQL, která je také na CPU atd. atd. Těch produktů, kde je třeba hlídat licence, je mnohem více.
Zdar Max

[Heron]

Současný stav je, že mám dva Netapp storage, mezi nimiž běží replikace (replikuji SVM - virtuální server včetně všech volume, který v rámci NetAppu zajišťuje NFS službu a další). Nad tím primárním mám ESXi cluster ze třech nabušených serverů, jeden může jít down a zbývající dva to utáhnou. V záložní lokalitě mám další ESXi cluster, kde mám dva nabušené stroje a přibyde další.

Ano. Tohle moc dobře znám . Tohle je klasický minimální setup s ESX s nějakou tou minimální licencí. Cokoliv vějš je už nesmyslně drahé, takže hromada firem končí na tomto. Dva stroje pro storage (protože prej redundace), 3 stroje esx, protože víc už tam licenčně nejde dát. Ze začátku to stačí, postupně to stačit přestává. Původní redundance ESX 2+1 přestává fungovat, protože ty tři stroje mají co dělat, aby to zvládly.

Tohle jsem za těch x let viděl několikrát. Tomuhle říkám více méně osamělé stroje, protože se s tím prakticky nedá hnout.

Největším problémem jsou licence. Ty hází klacky pod nohy neuvěřitelně. A těm se přizpůsobuje hw řešení.

Jo.

To ty s Postgresem asi neznáš.

Neznám.

[Max]

Máme 12x ESXi socket standard, nepoužíváme ten essential kit (je to pro nás málo), který je omezen na 3ks. Takže v klidu můžeme dokupovat další licence a rozšiřovat. 2+1 na primáru zatím stačí, až nebude, dokoupíme server a další licence.
Na druhou stranu, výkon jde kupředu, CPU se flákají, jde většinou o ram a storage, nic víc.
Zdar Max

[Max]

Asi jsem možná objevil důvod, proč se ta Areca hryzala. Měl jsem teorii, že za to budou moci ty SATA disky. Teorie byla v tom smyslu, že nebudou třeba úplně fit a budou se chovat nějak nepředvídatelně a Areca s tím bude mít problém.
Poté, co jsme koupili HBA od LSI, tak storage běží naprosto stabilně a disky, které se u Areca řadiče tvářily jako ok, se najednou rozsvítily jako vánoční stromeček (chyby ve SMARTu, u některých neprochází LONG test apod.).
Občas Areca nějaký disk vyhodil, ale bylo to vždy, když server padnul. A né, nevyhodil ho vždy při každém pádu systému a skoro pokaždé vyhodil řadič jiný disk. Když jsem ho pak kontroloval přes arecacli, tak se disk tvářil ok.
Celkově z toho mám tedy pocit, který jsem zmínil na začátku, tj. že to má nějaký problém s nedobře fungujícími SATA disky a většinou se to pak projevilo při zátěži.
Připomínám, že všechny disky jsou WD RE4 4TB (takže žádné home šidítka). Jen dva na systém jsou WD Green 2TB, ale je tam jen systém, jsou jako mirror a oba jsou ok. Prostě jsem neměl poruce něco obstojnějšího, a na systém to plně stačí (měl jsem v plánu, že je ještě použiji na pár jailů s 0% režií).
Zdar Max

[snajpa]

Zasadne jenom HBAcka, typicky LSI 9207/9300, zatim nebyl problem s zadnym z nich. Ta cena za licence se mi nezda, co jsi chtel za featury a jakej level supportu? Schvalne checknu s kamosem, kolik plati za tu posledni all-flash bestii.

[Max]

Chtěl jsem dva storage 30TB SAS, snapshoty a async. replikace mezi nima s rollbackem 10min. V jedné lokalitě tedy jeden 30TB a replikaci do záložní lokality, kde by byl další 30TB (RAID10, nebo dle doporučení).
U primárního pole jsem chtěl navíc ještě 2TB v SSD s možností připojit přes FC.
SAS pole připojeno pomocí NFS, případně iSCSI - přes 10Gbit optiku.
Možnost rozšířit do budoucna obě pole na 60TiB
Pak přišel dotaz, kolik se změní dat během dne (kvůli té replikaci), odpověděl jsem, že né víc jak 30GiB.
Poptával jsem na "thomas-krenn.com".
Pani obratem volala a do telefonu mi řekla hrubý odhad něco přes milion jen licence bez hw s tím, že jestli má vypracovávat podrobnější nabídku s přesnou částkou. Tak jsem poděkoval a dal jí pápá.
Zdar Max

[Max]

Jinak dodám, že teď máme 2x NetApp FAS-2552, každý připojený 2x10Gbit do HPE FlexFabric 5700.
Na primáru 2x HPE 5700 a v záloze 1x HPE 5700, všechny v jednom stacku.
Servery také přes 2x10Gbit do téže switchů. Vše připojeno přes NFS4.1
Zdar Max

[snajpa]

No, tak to je teda raketa, mel bys byt tak na polovine. Muzu ti dat kontakt s referenci primo na typka od Nexenty, tipoval bych, ze by ses mel dostat tak na 15-20k evri max; jestli ne, tak bych mel rekalibrovat svoje vnimani Nexenty. Ale prijde mi to fakt turbo-hodne, to neni normalni cena za Nexenti licence.

[Max]

Jak říkám, koupili jsme NetApp, takže toto už neřeším.
Zdar Max

[Max]

Jinak díky za tip, nad něčím podobným jsem přemýšlel, resp. jsem přemýšlel, že tu Arecu vyhodím a pořídím čistě jen nějaké HBA od LSI.
Jinak ještě dotaz, jedeš SAS disky a multipath, nebo jedeš SATA a tím pádem duální řadič a další věci neřešíš?
Zdar Max

[snajpa]

Jsou to zalohovaci pole, ne centralni aplikacni uloziste, takze SATA disky staci, cili sam za se za to zarucit nemuzu, ale co sleduju v ZoL komunite, neni multipath nic moc vyjimecneho, takze by to chodit melo v poho.

[Bystroushaak]

Nebylo to náhodou v Krajské v Ústí?

[Max]

Myslíš na finančáku? Ne, sice v Ústí máme dva provozy, ale nic státního.
Zdar Max

[Bystroushaak]

Nemocnice. Mám tam bývalého kolegu, který zmiňoval, že před pár týdny jim tam kleklo pole od HP po přechodu na generátory, když zloději ukradli kabely:

• Ústecká nemocnice je kvůli zlodějům kovů bez proudu, sestry čeká noční v čelovkách
• Ústecká nemocnice omezila návštěvy na rizikových odděleních
• Ústecká nemocnice musí omezit provoz, zloději poškodili přívod elektřiny

[Bystroushaak]

Nejmenovaný zdroj:

Morgoši ukradli kabely. ČEZ to dneska opravuje. Celá nemocnice běží na dieslech. A kolem 17. hodiny jeden zakolisal a odpalil ups a padlo celý Datacentrum...

Odeslo cely diskovy pole, takze top specialista z hp sedl a letel sem. A kdyz obnovoval to pole po castech, tak to padlo znovu. Ted bezi ze zalozni lokality.

[Max]

Tak to je taky pěkný. Každopádně by mně fakt zajímalo, co to bylo za UPS, že to nezvládlo blbý výkyv z dieselu.
V Ostravě máme občas delší odstávky kvůli servisu trafostanice a vždy tam zařídí na tu dobu nějaký diesel agregátor a na UPSce vidíme, jak to lehce kolísá a připojený je na to všechno včetně stolních PC, tiskáren atd. a ještě se nám nestalo, že by něco odešlo, natož UPS, která má být na takové věci dělaná.
Zdar Max

[pc2005]

Navíc nejde jednoduše srovnat verze jedním upgradem, protože je potřeba postupovat postupně podle major verzí (nejde moc přeskakovat).

To je smutný když nemaj něco jako boot sektor, kterej se nemění (třeba jako uboot partišna v embedded) :-/.

Jeden update žere 15-20min času a v našem případě bylo potřeba udělat update 3 s tím, že dodaný řadič jsem hodil do jiného storage a upgradnul jsem si u něj fw jinde.

Kolik gigabajtů ten firmware má? :-O Nebo se to tam cpe po nějakým UARTu?

[Max]

Nevím, jak se to tam cpe. Firmware má asi 50MiB a můžeš ho tam hodit přes ftp, nebo web ksicht. Jakým způsobem se pak láduje dál netuším.
Zdar Max

[pc2005]

web ksicht

OMG flashovat firmware řadiče přes web .

ftp

o_O

[xvasek]

Náhodou proč ne? Pokud už někde TCP stack je, tak malý http server má jednotky kB a výhodou je, že je to hodně univerzální co se týká klienta.

[ehm]

Nevýhodou je, že webové technologie jsou ketus. Kéž by už konečně došlo k ustanovení ideologické policie, která by na takové věci dohlížela. Pak by výrobci takový hnus nikdy nemohl projít, aniž by každý zúčastněný riskoval 15 let nucených těžkých prací na open-source.

[Max]

Co je na tom špatného? Místo https web ksichtu by jsi raději upřednostňoval třeba tftp jako mívají např. switche?
Nebo by se ti líbilo sftp, nebo co? Vyjádři se, neboj se toho, sděl nám své tužby a představy :).
Zdar Max

[R]

tftp na hnus, to je protokol vhodny akurat tak do bootloaderu na recovery.

[pc2005]

JTAG

[pc2005]

Jestli https tak aspoň něco. Ale všechny mé routery/modemy maj to webový rozhraní tak divný, že programování nacvaknutím kolíčku na TSOP8/16 čip s firmware by mělo vyšší šanci na bezchybný update.

Každopádně pokud se spouští TCP stack a web, tak nejspíš update firmware obsahuje i novější verzi toho stacku a webu, takže hrozí, že porucha vyřadí zařízení z činnosti (protože si pod sebou uřeže větev - viz ty nepodařené updaty v blogu). Update firmware u něčeho co stojí až 1 megaKč bych čekal, že bude robustní, což nejde řešit stylem chicken vs egg (pochopil bych to u modemu za 500Kč).

[Max]

Nerozumím, většinou to snad funguje tak, že se prostě někde zaktualizuje base image, provede se restart a následně boot z nového image. Následují nějaké post upgrade akce (konverze konfiguráků atd.). To je celkem standardní a dělá to tak spoustu zařízení. Nechápu, jak by pak mohlo dojít k tomu podřezání větve.
Zdar Max

[pc2005]

No ale pokud se aktualizuje base image špatně, tak už nemá po restartu co bootovat. A vrátit zpět to nemůžeš, protože ten interface by byl součástí toho nového base image (a i kdyby ten interface fungoval, tak to na starší verzi nepojede, protože současná major verze nepodporuje starší major verzi ).

[xvasek]

Třeba ten firmware předtím testují.

[pc2005]

Kámošův ADSL modem se zaseknul i když se na něj jen přihlásil .

[Max]

Jak si představuješ takový flash na dálku s JTAG?
Zdar Max

[pc2005]

a v našem případě bylo potřeba udělat update 3 s tím, že dodaný řadič jsem hodil do jiného storage a upgradnul jsem si u něj fw jinde

Tu kartu jsi teda držel v ruce ne? To je pro JTAG vzdálenost víc než dostačující.

Nebo tys tím webem a ftp myslel obecný přístup pro dopravu libovolného souboru na počítač hostující tu kartu? (já myslel na blackbox stroj asi jako DSL modemy, kde je přímo flashovací webový formulář a jiné soubory se uploadovat nedají). To pak asi jo, ale to s bezpečností ftp by tam platilo stejně .

Jinak k tomu JTAGu:

pokusů bylo 20 po 2min, takže místo 15min upgrade trval první asi hodinu

u JTAGu to je nezávislé na tom jak se interní OS v řadiči vyspí (=když má každá major verze vlastní standard updatu), protože je to JTAG, kdo přímo zapisuje instrukce CPU. Dále ve specifikaci PCI/PCIe karty jsou přímo piny na JTAG, takže karta by se ani nemusela vytahovat z (ideální) desky.

[Max]

1) Upgrade fw jsem dělal vždy na dálku, nevidím smysl u toho čumět do zdi 20min.
2) Používal jsem flashovací aplikaci, která tam ládovala data přes ftp, tato aplikace měla ten timeout. Aplikaci jsem použil kvůli tomu, že umožňovala lokální logování celého procesu. Kdybych použil web, nebo ftp, tak bych se musel spolehnout na logy v rámci storage, ale asi bych nemusel čekat na nějaký timeout
3) Případný sniff loginu a pw z ftp komunikace se fakt nebojím, protože uzavřená mgmt vlan

Jinak ten controller, to není nic jiného, než kompletní PC, které se zasune do šasi. Napájení je v šasi, bez něj tedy nefunguje. Má to tak spousta řešení externích polí včetně NetAppu.
Tak nějak předpokládám, že web ksicht funguje jen k nahrání souboru s img a následně pak spustí nějaký lokální cli příkaz pro update. Když web chcípne, což zachvíli chcípne, tak update běží dál. Po prvním otočení web ksichtu pak vyskočí okno, kde je vidět stav flashování a konkrétní úkony. Novější verze toho web ksichtu tedy neslouží jen k uploadu souboru, ale i k zobrazování online průběhu a zobrazuje ho i když se soubor nahraje přes ftp, nebo jinak.
Zdar Max

[pc2005]

1,2) No mě jde právě o to, že sis tou nekvalitní flashovací aplikací prodloužil downtime stroje. Misto toho abys použil nějakej univerzální interface. 3) Šifrovaná? Tak to pak OK. Ale i tak FTP je fuj protokol, to už radši ten http(s) .

ten controller, to není nic jiného, než kompletní PC

Jo ale těch 50MB určitě nebude obraz nějaký openwrt distribuce. To bude firmware nějakýho RISC CPU na řadiči SCSI/SATA/SAS atd. Mám tu například starou SCSI kartu, kde je am29k, a byly i s i960.

Když web chcípne, což zachvíli chcípne, tak update běží dál.

Jo takže to běží nejspíš na tom PC a updatuje to diskový řadič. U modemů/routerů to ale updatuje ten samej hw, na kterým to běží.

Dokázala by to ta vzdálená utilita opravit, kdyby v půlce flashování vypadl proud?

[Max]

Pleteš se. Vesměs to je vždy nový obraz systému, který obsahuje i sadu firmware na konkrétní komponenty. Flash controlleru u pole pak znamená, že se do toho PC naleje nový systém + se provede upgrade firmware na některých hw komponentách (třeba na 4).
Pole má dva controllery, tedy dva PC/plně soběstačné jednotky. Každý PC může mít rozdílnou verzi firmware/os, fungovat by to mělo, ale doporučované to zrovna není.
Mezi těmi controllery/PC běží online sync cache a další věci, aby v případě výpadku jednoho controlleru/PC nedošlo k výpadku pole. Tento proces u nás chcípl.
Začít si představovat, že bych to měl dělat přes JTAG, někde shrbený v serverovně, to je fakt úchylárna největšího kalibru.
Flashování se posere nesprávným postupem (jako jsem udělat před hafec lety skok mezi verzema), v takovém případě máš druhý controller a čekáš nbd na nový controller od supportu.
Zdar Max

[Max]

Jinak část logu při flashování viz (neobsahuje spoustu věcí, které se dělají před i po aplikaci fw) :

23:37:25.395   Checking if controller is UP after restart .. 

23:37:25.457  >  ***.***.***.*** login: admin
23:37:25.504  >  Password: 
23:37:26.426  >  HP StorageWorks MSA Storage P2000G3 FC/iSCSI
23:37:26.426  >  System Name: Primary
23:37:26.426  >  System Location: Uninitialized Location
23:37:26.426  >  Version: TS250P003
23:37:26.426  telnet: set cli-parameters api pager disabled (1)
23:37:26.442  
 Attempt : 0 

23:37:26.442  Controller is Reachable ..

23:37:26.442  Controller Status Check 
23:37:26.520  >  ***.***.***.*** login: admin
23:37:26.567  >  Password: 
23:37:27.176  >  HP StorageWorks MSA Storage P2000G3 FC/iSCSI
23:37:27.176  >  System Name: Primary
23:37:27.176  >  System Location: Uninitialized Location
23:37:27.176  >  Version: TS250P003
23:37:27.176  telnet: set cli-parameters api pager disabled (1)
23:37:27.207  Flashing Array to firmware version : TS252P005
23:37:27.286  Starting Controller Flash: this will take approximately 30 mins. The actual time may vary depending on your configuration.

23:37:27.426  ftp state is : 1
23:37:27.426  ftp state is : 2
23:37:27.426  ftp state is : 3
23:37:27.442  Connected to the controller.
23:37:27.442  Setting FTP session max time duration to 90 Minutes
23:37:27.504  ftp state is : 4
23:37:27.504  Logged into the controller.
23:37:33.583  File uploaded, bytes written: 38563840
23:37:33.583  File uploaded, bytes written:
23:37:41.630  ftp: socket disconnect
23:37:41.662  FTP >> File Transfer Complete. Starting Operation:
23:37:44.287  FTP >> Checking component list
23:37:44.349  FTP >> mc bundle component check passed.
23:37:44.349  FTP >> Checking bundle integrity...
23:37:55.334  FTP >> Initial mc file integrity checks passed.
23:37:55.334  FTP >> Checking system health.
23:38:01.522  FTP >> System health check complete. Health state: Degraded
23:38:01.553  FTP >> Stopping Management Controller applications.
23:38:09.148  FTP >> Starting message server
23:38:09.367  FTP >> Initial connection to SC successful.
23:38:09.538  FTP >> STATUS: Updating Expander Controller firmware.
23:38:09.663  FTP >> Updating Expander Controller firmware. (bus ID = 0, target ID = 31)
23:38:09.663  FTP >> Loading Expander (0:31)
23:38:09.663  FTP >> Sending Expander firmware to Storage Controller buffer
23:38:09.710  FTP >> Updating EC Image:Remaining size 1092021
23:38:10.757  FTP >> Updating EC Image:Remaining size 928181
23:38:11.804  FTP >> Updating EC Image:Remaining size 764341
23:38:12.851  FTP >> Updating EC Image:Remaining size 600501
23:38:13.882  FTP >> Updating EC Image:Remaining size 436661
23:38:14.914  FTP >> Updating EC Image:Remaining size 272821
23:38:15.961  FTP >> Updating EC Image:Remaining size 108981
23:38:16.648  FTP >> Firmware has been sent to the Storage Controller buffer. Beginning EMP update.
23:38:16.648  FTP >> Sending firmware from SC buffer to device 0:31
23:38:16.976  FTP >> Updating EMP Image:Remaining size 1100213
23:38:19.102  FTP >> Updating EMP Image:Remaining size 1034677
23:38:21.211  FTP >> Updating EMP Image:Remaining size 969141
23:38:23.305  FTP >> Updating EMP Image:Remaining size 903605
23:38:25.399  FTP >> Updating EMP Image:Remaining size 838069
23:38:27.524  FTP >> Updating EMP Image:Remaining size 772533
23:38:29.633  FTP >> Updating EMP Image:Remaining size 706997
23:38:31.743  FTP >> Updating EMP Image:Remaining size 641461
23:38:33.884  FTP >> Updating EMP Image:Remaining size 575925
23:38:36.009  FTP >> Updating EMP Image:Remaining size 510389
23:38:38.118  FTP >> Updating EMP Image:Remaining size 444853
23:38:40.197  FTP >> Updating EMP Image:Remaining size 379317
23:38:42.322  FTP >> Updating EMP Image:Remaining size 313781
23:38:44.431  FTP >> Updating EMP Image:Remaining size 248245
23:38:46.541  FTP >> Updating EMP Image:Remaining size 182709
23:38:48.650  FTP >> Updating EMP Image:Remaining size 117173
23:38:50.776  FTP >> Updating EMP Image:Remaining size 51637
23:38:52.713  FTP >> Expander Controller firmware was updated successfully.
23:38:52.713  FTP >> Finished updating EC firmware.
23:38:52.916  FTP >> STATUS: Updating expansion-module firmware.
23:38:52.994  FTP >> Performed rescan at the beginning of the expansion-module firmware update. Waiting a few seconds...
23:39:03.026  FTP >> No expansion enclosures were found.
23:39:03.026  FTP >> Finished updating expansion-module firmware.
23:39:03.886  FTP >> STATUS: Updating Storage Controller firmware.
23:39:03.948  FTP >> Controller current bundle: TS250P003,loading bundle TS252P005
23:39:03.948  FTP >> Instructing SC to shut down and reboot when finished updating
23:39:36.513  FTP >> Waiting 5 seconds for SC to shutdown.
23:39:41.560  FTP >> Shutdown of SC successful.
23:39:41.560  FTP >> Sending new firmware to SC.
23:39:41.748  FTP >> Updating SC Image:Remaining size 6845206
23:39:42.732  FTP >> Updating SC Image:Remaining size 6517526
23:39:43.732  FTP >> Updating SC Image:Remaining size 6189846
23:39:44.717  FTP >> Updating SC Image:Remaining size 5862166
23:39:45.717  FTP >> Updating SC Image:Remaining size 5534486
23:39:46.701  FTP >> Updating SC Image:Remaining size 5206806
23:39:47.686  FTP >> Updating SC Image:Remaining size 4879126
23:39:48.686  FTP >> Updating SC Image:Remaining size 4551446
23:39:49.670  FTP >> Updating SC Image:Remaining size 4223766
23:39:50.670  FTP >> Updating SC Image:Remaining size 3896086
23:39:51.655  FTP >> Updating SC Image:Remaining size 3568406
23:39:52.639  FTP >> Updating SC Image:Remaining size 3240726
23:39:53.639  FTP >> Updating SC Image:Remaining size 2913046
23:39:54.624  FTP >> Updating SC Image:Remaining size 2585366
23:39:55.624  FTP >> Updating SC Image:Remaining size 2257686
23:39:56.608  FTP >> Updating SC Image:Remaining size 1930006
23:39:57.608  FTP >> Updating SC Image:Remaining size 1602326
23:39:58.593  FTP >> Updating SC Image:Remaining size 1274646
23:39:59.577  FTP >> Updating SC Image:Remaining size 946966
23:40:00.577  FTP >> Updating SC Image:Remaining size 619286
23:40:01.546  FTP >> Updating SC Image:Remaining size 291606
23:40:02.421  FTP >> Waiting for Storage Controller to complete programming.
23:40:47.580  FTP >> Please wait...
23:41:18.067  FTP >> Storage Controller has completed programming.
23:41:18.067  FTP >> Updating SC Image:Remaining size 0
23:41:18.067  FTP >> Waiting for SC reboot.
23:42:02.785  FTP >> Please wait...
23:42:23.083  FTP >> .
23:42:23.083  FTP >> Storage Controller has rebooted.
23:42:23.083  FTP >> Storage Controller has been updated, proceeding to next step.
23:42:23.990  FTP >> STATUS: Updating Management Controller firmware
23:42:23.990  FTP >> MC current version: L250R027-01,loading version L252R021-01
23:42:24.287  FTP >> Checking sub-bundle integrity...
23:42:25.068  FTP >> Sub-bundle management controller file integrity checks passed
23:42:25.084  FTP >> Raising MC shields
23:42:31.912  FTP >> Successfully unmounted /app filesystem
23:42:31.912  FTP >> Starting message server
23:42:34.287  FTP >> Loading the Management Controller Loader
23:42:34.303  FTP >> Loader sector write detected.
23:42:34.303  FTP >> Flash /mnt/ramdisk/mc/components/ARMLoader.bin to /dev/mtdblock0
23:42:34.303  FTP >> Comparing Sector 0, size 19 KiB
23:42:34.334  FTP >> Flash image is the same, no need to re-flash.
23:42:34.334  FTP >> Finished loading Management Controller Loader
23:42:34.334  FTP >> Loading the Management Controller Loader
23:42:34.350  FTP >> Loader sector write detected.
23:42:34.350  FTP >> Flash /mnt/ramdisk/mc/components/ARMLoader.bin to /dev/mtdblock1
23:42:34.350  FTP >> Comparing Sector 0, size 19 KiB
23:42:34.381  FTP >> Flash image is the same, no need to re-flash.
23:42:34.381  FTP >> Finished loading Management Controller Loader
23:42:34.428  FTP >> Loading the Management Controller Kernel
23:42:34.444  FTP >> Flash /mnt/ramdisk/mc/components/kernel.bin to /dev/mtdblock2
23:42:34.444  FTP >> Comparing Sector 0, size 128 KiB
23:42:34.522  FTP >> Flash needs to change.....doing the reprogramming
23:42:34.522  FTP >> Flashing Sector 0 of 39
23:42:34.569  FTP >> Flashing Sector 1 of 39
23:42:35.537  FTP >> Flashing Sector 2 of 39
23:42:37.147  FTP >> Flashing Sector 3 of 39
23:42:38.210  FTP >> Flashing Sector 4 of 39
23:42:39.350  FTP >> Flashing Sector 5 of 39
23:42:40.491  FTP >> Flashing Sector 6 of 39
23:42:41.335  FTP >> Flashing Sector 7 of 39
23:42:43.022  FTP >> Flashing Sector 8 of 39
23:42:44.054  FTP >> Flashing Sector 9 of 39
23:42:45.007  FTP >> Flashing Sector 10 of 39
23:42:46.398  FTP >> Flashing Sector 11 of 39
23:42:47.444  FTP >> Flashing Sector 12 of 39
23:42:48.335  FTP >> Flashing Sector 13 of 39
23:42:49.523  FTP >> Flashing Sector 14 of 39
23:42:50.460  FTP >> Flashing Sector 15 of 39
23:42:51.304  FTP >> Flashing Sector 16 of 39
23:42:52.679  FTP >> Flashing Sector 17 of 39
23:42:53.586  FTP >> Flashing Sector 18 of 39
23:42:54.554  FTP >> Flashing Sector 19 of 39
23:42:55.867  FTP >> Flashing Sector 20 of 39
23:42:56.836  FTP >> Flashing Sector 21 of 39
23:42:57.773  FTP >> Flashing Sector 22 of 39
23:42:58.961  FTP >> Flashing Sector 23 of 39
23:42:59.914  FTP >> Flashing Sector 24 of 39
23:43:00.836  FTP >> Flashing Sector 25 of 39
23:43:02.180  FTP >> Flashing Sector 26 of 39
23:43:03.133  FTP >> Flashing Sector 27 of 39
23:43:03.961  FTP >> Flashing Sector 28 of 39
23:43:05.336  FTP >> Flashing Sector 29 of 39
23:43:06.227  FTP >> Flashing Sector 30 of 39
23:43:07.274  FTP >> Flashing Sector 31 of 39
23:43:08.462  FTP >> Flashing Sector 32 of 39
23:43:09.383  FTP >> Flashing Sector 33 of 39
23:43:10.243  FTP >> Flashing Sector 34 of 39
23:43:11.587  FTP >> Flashing Sector 35 of 39
23:43:12.571  FTP >> Flashing Sector 36 of 39
23:43:13.712  FTP >> Flashing Sector 37 of 39
23:43:14.743  FTP >> Flashing Sector 38 of 39
23:43:15.462  FTP >> Completed flashing image.
23:43:15.462  FTP >> Close mtd
23:43:16.087  FTP >> Done.
23:43:16.087  FTP >> Finished loading Management Controller Kernel
23:43:26.713  FTP >> Loading the Management Controller Application
23:43:26.744  FTP >> Flash /mnt/ramdisk/mc/components/app.squashfs to /dev/mtdblock8
23:43:26.760  FTP >> Comparing Sector 0, size 128 KiB
23:43:26.838  FTP >> Flash needs to change.....doing the reprogramming
23:43:26.853  FTP >> Flashing Sector 0 of 173
23:43:26.885  FTP >> Flashing Sector 1 of 173
23:43:27.869  FTP >> Flashing Sector 2 of 173
23:43:29.338  FTP >> Flashing Sector 3 of 173
23:43:30.400  FTP >> Flashing Sector 4 of 173
23:43:31.322  FTP >> Flashing Sector 5 of 173
23:43:32.869  FTP >> Flashing Sector 6 of 173
23:43:33.760  FTP >> Flashing Sector 7 of 173
23:43:34.604  FTP >> Flashing Sector 8 of 173
23:43:36.135  FTP >> Flashing Sector 9 of 173
23:43:37.104  FTP >> Flashing Sector 10 of 173
23:43:38.151  FTP >> Flashing Sector 11 of 173
23:43:39.339  FTP >> Flashing Sector 12 of 173
23:43:40.167  FTP >> Flashing Sector 13 of 173
23:43:41.136  FTP >> Flashing Sector 14 of 173
23:43:42.323  FTP >> Flashing Sector 15 of 173
23:43:43.151  FTP >> Flashing Sector 16 of 173
23:43:44.042  FTP >> Flashing Sector 17 of 173
23:43:45.495  FTP >> Flashing Sector 18 of 173
23:43:46.402  FTP >> Flashing Sector 19 of 173
23:43:47.542  FTP >> Flashing Sector 20 of 173
23:43:48.699  FTP >> Flashing Sector 21 of 173
23:43:49.745  FTP >> Flashing Sector 22 of 173
23:43:51.308  FTP >> Flashing Sector 23 of 173
23:43:52.339  FTP >> Flashing Sector 24 of 173
23:43:53.371  FTP >> Flashing Sector 25 of 173
23:43:54.761  FTP >> Flashing Sector 26 of 173
23:43:55.637  FTP >> Flashing Sector 27 of 173
23:43:57.074  FTP >> Flashing Sector 28 of 173
23:43:58.246  FTP >> Flashing Sector 29 of 173
23:43:59.184  FTP >> Flashing Sector 30 of 173
23:44:00.699  FTP >> Flashing Sector 31 of 173
23:44:01.699  FTP >> Flashing Sector 32 of 173
23:44:02.621  FTP >> Flashing Sector 33 of 173
23:44:04.012  FTP >> Flashing Sector 34 of 173
23:44:04.903  FTP >> Flashing Sector 35 of 173
23:44:05.825  FTP >> Flashing Sector 36 of 173
23:44:06.903  FTP >> Flashing Sector 37 of 173
23:44:07.809  FTP >> Flashing Sector 38 of 173
23:44:08.841  FTP >> Flashing Sector 39 of 173
23:44:09.872  FTP >> Flashing Sector 40 of 173
23:44:10.809  FTP >> Flashing Sector 41 of 173
23:44:12.200  FTP >> Flashing Sector 42 of 173
23:44:13.310  FTP >> Flashing Sector 43 of 173
23:44:14.216  FTP >> Flashing Sector 44 of 173
23:44:15.388  FTP >> Flashing Sector 45 of 173
23:44:16.450  FTP >> Flashing Sector 46 of 173
23:44:18.154  FTP >> Flashing Sector 47 of 173
23:44:19.263  FTP >> Flashing Sector 48 of 173
23:44:20.435  FTP >> Flashing Sector 49 of 173
23:44:21.482  FTP >> Flashing Sector 50 of 173
23:44:22.513  FTP >> Flashing Sector 51 of 173
23:44:24.154  FTP >> Flashing Sector 52 of 173
23:44:25.185  FTP >> Flashing Sector 53 of 173
23:44:26.029  FTP >> Flashing Sector 54 of 173
23:44:27.545  FTP >> Flashing Sector 55 of 173
23:44:28.561  FTP >> Flashing Sector 56 of 173
23:44:29.451  FTP >> Flashing Sector 57 of 173
23:44:30.842  FTP >> Flashing Sector 58 of 173
23:44:31.795  FTP >> Flashing Sector 59 of 173
23:44:32.748  FTP >> Flashing Sector 60 of 173
23:44:34.061  FTP >> Flashing Sector 61 of 173
23:44:34.952  FTP >> Flashing Sector 62 of 173
23:44:35.889  FTP >> Flashing Sector 63 of 173
23:44:37.217  FTP >> Flashing Sector 64 of 173
23:44:38.155  FTP >> Flashing Sector 65 of 173
23:44:39.124  FTP >> Flashing Sector 66 of 173
23:44:40.296  FTP >> Flashing Sector 67 of 173
23:44:41.311  FTP >> Flashing Sector 68 of 173
23:44:43.030  FTP >> Flashing Sector 69 of 173
23:44:44.015  FTP >> Flashing Sector 70 of 173
23:44:44.843  FTP >> Flashing Sector 71 of 173
23:44:46.546  FTP >> Flashing Sector 72 of 173
23:44:47.499  FTP >> Flashing Sector 73 of 173
23:44:48.640  FTP >> Flashing Sector 74 of 173
23:44:49.875  FTP >> Flashing Sector 75 of 173
23:44:50.906  FTP >> Flashing Sector 76 of 173
23:44:52.234  FTP >> Flashing Sector 77 of 173
23:44:53.281  FTP >> Flashing Sector 78 of 173
23:44:54.281  FTP >> Flashing Sector 79 of 173
23:44:56.000  FTP >> Flashing Sector 80 of 173
23:44:56.984  FTP >> Flashing Sector 81 of 173
23:44:58.078  FTP >> Flashing Sector 82 of 173
23:44:59.297  FTP >> Flashing Sector 83 of 173
23:45:00.235  FTP >> Flashing Sector 84 of 173
23:45:01.172  FTP >> Flashing Sector 85 of 173
23:45:02.469  FTP >> Flashing Sector 86 of 173
23:45:03.500  FTP >> Flashing Sector 87 of 173
23:45:04.485  FTP >> Flashing Sector 88 of 173
23:45:05.813  FTP >> Flashing Sector 89 of 173
23:45:06.813  FTP >> Flashing Sector 90 of 173
23:45:07.641  FTP >> Flashing Sector 91 of 173
23:45:08.860  FTP >> Flashing Sector 92 of 173
23:45:09.798  FTP >> Flashing Sector 93 of 173
23:45:10.563  FTP >> Flashing Sector 94 of 173
23:45:12.017  FTP >> Flashing Sector 95 of 173
23:45:13.017  FTP >> Flashing Sector 96 of 173
23:45:14.173  FTP >> Flashing Sector 97 of 173
23:45:15.423  FTP >> Flashing Sector 98 of 173
23:45:16.376  FTP >> Flashing Sector 99 of 173
23:45:17.704  FTP >> Flashing Sector 100 of 173
23:45:18.751  FTP >> Flashing Sector 101 of 173
23:45:19.642  FTP >> Flashing Sector 102 of 173
23:45:21.330  FTP >> Flashing Sector 103 of 173
23:45:22.549  FTP >> Flashing Sector 104 of 173
23:45:23.502  FTP >> Flashing Sector 105 of 173
23:45:24.924  FTP >> Flashing Sector 106 of 173
23:45:25.986  FTP >> Flashing Sector 107 of 173
23:45:27.033  FTP >> Flashing Sector 108 of 173
23:45:28.299  FTP >> Flashing Sector 109 of 173
23:45:29.127  FTP >> Flashing Sector 110 of 173
23:45:30.440  FTP >> Flashing Sector 111 of 173
23:45:31.393  FTP >> Flashing Sector 112 of 173
23:45:32.268  FTP >> Flashing Sector 113 of 173
23:45:34.174  FTP >> Flashing Sector 114 of 173
23:45:35.159  FTP >> Flashing Sector 115 of 173
23:45:35.940  FTP >> Flashing Sector 116 of 173
23:45:37.596  FTP >> Flashing Sector 117 of 173
23:45:38.628  FTP >> Flashing Sector 118 of 173
23:45:39.518  FTP >> Flashing Sector 119 of 173
23:45:40.972  FTP >> Flashing Sector 120 of 173
23:45:41.878  FTP >> Flashing Sector 121 of 173
23:45:42.878  FTP >> Flashing Sector 122 of 173
23:45:44.222  FTP >> Flashing Sector 123 of 173
23:45:45.066  FTP >> Flashing Sector 124 of 173
23:45:45.941  FTP >> Flashing Sector 125 of 173
23:45:47.238  FTP >> Flashing Sector 126 of 173
23:45:48.113  FTP >> Flashing Sector 127 of 173
23:45:49.019  FTP >> Flashing Sector 128 of 173
23:45:50.410  FTP >> Flashing Sector 129 of 173
23:45:51.238  FTP >> Flashing Sector 130 of 173
23:45:52.238  FTP >> Flashing Sector 131 of 173
23:45:53.426  FTP >> Flashing Sector 132 of 173
23:45:54.441  FTP >> Flashing Sector 133 of 173
23:45:55.285  FTP >> Flashing Sector 134 of 173
23:45:56.254  FTP >> Flashing Sector 135 of 173
23:45:57.613  FTP >> Flashing Sector 136 of 173
23:45:58.957  FTP >> Flashing Sector 137 of 173
23:46:00.207  FTP >> Flashing Sector 138 of 173
23:46:01.473  FTP >> Flashing Sector 139 of 173
23:46:02.598  FTP >> Flashing Sector 140 of 173
23:46:03.567  FTP >> Flashing Sector 141 of 173
23:46:04.895  FTP >> Flashing Sector 142 of 173
23:46:05.833  FTP >> Flashing Sector 143 of 173
23:46:06.801  FTP >> Flashing Sector 144 of 173
23:46:07.880  FTP >> Flashing Sector 145 of 173
23:46:08.786  FTP >> Flashing Sector 146 of 173
23:46:10.083  FTP >> Flashing Sector 147 of 173
23:46:11.192  FTP >> Flashing Sector 148 of 173
23:46:12.130  FTP >> Flashing Sector 149 of 173
23:46:12.989  FTP >> Flashing Sector 150 of 173
23:46:13.802  FTP >> Flashing Sector 151 of 173
23:46:15.130  FTP >> Flashing Sector 152 of 173
23:46:16.146  FTP >> Flashing Sector 153 of 173
23:46:17.162  FTP >> Flashing Sector 154 of 173
23:46:18.271  FTP >> Flashing Sector 155 of 173
23:46:19.162  FTP >> Flashing Sector 156 of 173
23:46:20.334  FTP >> Flashing Sector 157 of 173
23:46:21.349  FTP >> Flashing Sector 158 of 173
23:46:22.193  FTP >> Flashing Sector 159 of 173
23:46:23.553  FTP >> Flashing Sector 160 of 173
23:46:24.725  FTP >> Flashing Sector 161 of 173
23:46:25.646  FTP >> Flashing Sector 162 of 173
23:46:26.881  FTP >> Flashing Sector 163 of 173
23:46:27.787  FTP >> Flashing Sector 164 of 173
23:46:28.725  FTP >> Flashing Sector 165 of 173
23:46:30.053  FTP >> Flashing Sector 166 of 173
23:46:31.053  FTP >> Flashing Sector 167 of 173
23:46:31.928  FTP >> Flashing Sector 168 of 173
23:46:33.397  FTP >> Flashing Sector 169 of 173
23:46:34.913  FTP >> Flashing Sector 170 of 173
23:46:36.663  FTP >> Flashing Sector 171 of 173
23:46:38.225  FTP >> Flashing Sector 172 of 173
23:46:39.835  FTP >> Completed flashing image.
23:46:39.835  FTP >> Close mtd
23:46:41.085  FTP >> Done.
23:46:41.085  FTP >> Finished loading Management Controller Application
23:46:51.539  FTP >> Finished updating Management Controller firmware
23:46:51.617  FTP >> Updating system configuration files
23:46:52.398  FTP >> System configuration complete
23:46:52.430  FTP >> Lowering MC shields
23:46:52.492  FTP >> ==========================================
23:46:52.492  FTP >> Software Component Load Summary:
23:46:52.508  FTP >> MC Software: SUCCESSFUL
23:46:52.523  FTP >> SC Software: SUCCESSFUL
23:46:52.523  FTP >> EC Software: SUCCESSFUL
23:46:52.539  FTP >> Expansion Software: NOT ATTEMPTED
23:46:52.539  FTP >> ==========================================
23:46:53.117  FTP >> Code load completed successfully.
23:46:53.117  FTP >> Restarting Management Controller...
23:46:53.133  Device flash status for Controller A = 1
23:50:53.149  Sleep called...exiting
23:50:53.149  Wait for Ctrlr ready 

Výsledkem flashování je pak ještě druhý log soubor, do kterého se zapíše, že vše proběhlo úspěšně + časy :

---------------------------------------------------------------------------
Setup Session Beginned on **/**/2017 - 23:33:01 PM
---------------------------------------------------------------------------
Command Line Parameters Given: /s 
Controller IP is  :***.***.***.***
Name:            Online ROM Flash Component for Windows - HPE P2000 G3 MSA
Arrays
New Version:     TS252P005
Beginning Silent Session...
The software is installed but is not up to date.
 
Current Version: TS250P003
 
 
  - the component will be updated to the new version
Device flash Successful - P2000G3 FC/iSCSI : Controller A
Detailed log in :MSA2000_***_***_***_***.log
The operation was successful.
---------------------------------------------------------------------------
Session Ended on **/**/2017 - 23:51:17 PM
---------------------------------------------------------------------------

Zdar Max

[pc2005]

23:42:34.522  FTP >> Flashing Sector 0 of 39
...
23:43:15.462  FTP >> Completed flashing image.

Těch 19 sekund se muselo zdát jako věčnost .

[pc2005]

Aha controller != řadič jako je třeba 16C550, nebo USB OHCI. To jsem chtěl vědět. To je pak ale stejný jako ty DSL modemy, buď se ti zařízení (při poruše) brickne a nebo musíš implementovat nějaký žurnálování zda se opravdu zapsalo OK.

v takovém případě máš druhý controller a čekáš nbd na nový controller od supportu.

No právě že musíš čekat než se uráčí výrobce poslat přeinstalovanou verzi. To není moc robustní řešení, ideální by bylo vyřešit to svépomocí (hlavně by se nečekalo nbd). Do toho nbd pak běží zařízení se sníženou redundancí.

JTAG nejde transportovat přes TCP?

[Max]

Můžeš si zaplatit dražší support. Netapp má myslím i 4h.
Zdar Max

[Käyttäjä 11133]

I 2h.

[pc2005]

BTW nedaj se u FTP triviálně odposlouchávat na síti hesla? (takže ti tam může kdokoliv uploadovat rootkit)

Update pomocí webu se nedá automatizovat.

[Filip Jirsák]

Update pomocí webu se nedá automatizovat.

Proč by ne? Naopak původně webové technologie se pro automatizaci používají velice často – webové služby, REST přes HTTP(S) apod.

[pc2005]

OK tak dá, ale jen za předpokladu, že:

potom od seba uploadnut do pola cez debilne HTML rozhranie plne javascriptu, ktore pocas uploadu hadze stale nejake timeouty. Potom spustis upgrade a ten skonci s nejakou nezmyselnou chybou, ktora nikde na webe neexistuje. No a pre istotu sa ten uploadnuty subor vymaze, takze pre dalsi pokus ho musis uploadovat znovu...

Nehledě na to že u toho řadiče jsem to pochopil tak, že se flashuje (PCIe?) karta v počítači, ale pro flashování je nutný webserver hostitelského počítače?

[R]

Flashuje sa interny radic diskoveho pola cez web rozhranie diskoveho pola.

[pc2005]

Jasný, tak tuhle část jsem pochopil správně, něco jako tahle karta že?. A ten EMC Unity s 2GB firmwarem? To bude už "firmware" (jako OS) hostitelskýho počítače ne?

[R]

V EMC Unity su dva storage processory. Kazdy z nich je x86 PC dost silnej konfiguracie s FC sietovkami, SAS radicmi a dalsimi vecami. Bezi to na Linuxe, asi nejaky upraveny RedHat alebo co. Viac som sa v tom nerypal.

Viac som sa rypal v starom CX3. Tam su storage processory tiez x86 PC - CPU je P4 Xeon, RAM je DDR1 ECC. Ma to upraveny BIOS, vystup je na seriovy port (nema to VGA). Vo flash je len BIOS a nejaky bootloader. V poli diskov su prve 4 oznacene ako "vault". Tieto obsahuju OS (Windows XP Embedded), z ktoreho storage processory bootuju. Dalej sa na tieto disky uklada write cache v pripade vypadku napajania. Zvysok kapacity tychto diskov je volny a da sa pouzit pre data.

[pc2005]

Tak mě napadá ... proč se tyhle specializovaný x86 "PC" vlastně neupdatují přes intel AMT.

[R]

V CX3 ziadne AMT nie je (ma to tusim klasicky serverovy 6300ESB) a predpokladam, ze v Unity je tento paskvil vypnuty alebo nejako inak zneskodneny.

[pc2005]

Aha 2004, tak ten to nejspíš ještě neměl no. Kompletně vypnutý to nebude nikdy. Nejlepší výsledky dostali zatím tak, že zapnuli NSA mód (kterej si NSA prej objednala, kvůli vyšší bezpečnosti) v konfiguraci toho firmware. A i tak může být stále možné, že ten management hardware může ovládat systém. Potenciál na to má. I když to by se asi pro správu serveru moc nehodilo.

[Heron]

To je smutný když nemaj něco jako boot sektor, kterej se nemění (třeba jako uboot partišna v embedded) :-/.

Ono je to mnohdy ještě horší. Třeba update firmware u arecy probíhá tak, že tam postupně naláduješ 4 soubory (dle manu je možno v libovolném pořadí), ale musíš vždy všechny, jinak už nenajede. Proč to nemají jako jeden soubor s fw fakt netuším. Takže to tam naláduješ, dáš reboot, a když to naběhne, tak jsi to asi udělal dobře.

[pc2005]

Asi předpokládaj, že když ty řešení stojej stovky tisíc, tak nemá majitel problém sehnat čas na upgradovací downtime [frustrovaný joke]

Když to nenajede, jak se to pak opravuje?

[Heron]

Když to nenajede, jak se to pak opravuje?

Blbě

[R]

Nejaky boot block urcite maju. Preskakovat verzie pravdepodobne nejde preto, ze sa v niektorych verziach meni format nejakych (konfiguracnych?) dat a tie sa skonvertuju do noveho formatu az ked sa spusti dana verzia FW.

"Parada" je EMC Unity. Firmware ma 2 GB. Najprv ho musis stiahnut z EMC k sebe, potom od seba uploadnut do pola cez debilne HTML rozhranie plne javascriptu, ktore pocas uploadu hadze stale nejake timeouty. Potom spustis upgrade a ten skonci s nejakou nezmyselnou chybou, ktora nikde na webe neexistuje. No a pre istotu sa ten uploadnuty subor vymaze, takze pre dalsi pokus ho musis uploadovat znovu...

[pc2005]

Z konverze mezi zápisy v xml formáty jsem měl zkoušku . Předpokládám že firma s milionovými obraty zvládne udělat univerzální konvertor. Nehledě na to, že konfigurák by mohl být exportovaný na řídící OS a konvertován mimo proces updatu firmware.

Já bych stejně radši ten hw po updatu nastavil komplet od nuly.

debilne HTML rozhranie plne javascriptu, ktore pocas uploadu hadze stale nejake timeouty

děsivé

No a pre istotu sa ten uploadnuty subor vymaze, takze pre dalsi pokus ho musis uploadovat znovu

Tak to už je jen třešnička na dortu

[R]

Firma s milionovymi obratmi nezvladne urobit ani vlastny web. Takze sa vobec nedivim, ze im nefunguje ani HW ani SW.

[pc2005]