[vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

Thu Jul 28 14:57:36 CEST 2016

Hele produkční data tam nemám, ale to neznamená, že o ty data chci přijít :-) Jakože pak je tam vůbec ani nemusim dávat :-)

Vojtěch Knyttl  

knyttl at goout.cz  
+420 607 008 510
https://goout.cz

On Thursday 28. July 2016 at 14:54, Pavel Snajdr wrote:

> Jo, ale to mas pravdu, ze je to za tebe, na ukor rychle site pro vsechny
> (a s tim spojene vyhody, ze budeme konecne tusit, proc nam server umrel
> v kernel panicu a podobne, protoze budeme mit kdump).
>  
> Jak jsem psal, NAS od zacatku nemel byt redundantni, takze pokud ho
> prave ted vyuzivas na produkcni data, delas to spatne a tenhle hlas bych
> tedy vubec nemel pocitat.
>  
> A tak uvidime, co reknou dalsi :)
>  
> /snajpa
>  
> On 07/28/2016 02:29 PM, Vojtěch Knyttl wrote:
> > Za mě určitě platí, že data bez redundance (ať produkční nebo
> > neprodukční), jako by jich nebylo. Za mě klidně budu mít míň storage,
> > ale bezpečnou.
> >  
> > Vojtěch Knyttl
> >  
> >  
> > knyttl at goout.cz (mailto:knyttl at goout.cz)
> >  
> > +420 607 008 510
> >  
> > https://goout.cz
> >  
> >  
> > On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:
> >  
> > > Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> > > mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> > > bezpecnejsi konfiguraci.
> > > Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> > > benchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,
> > > co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> > > backuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.
> > >  
> > > K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskove
> > > RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly s
> > > malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVu
> > > bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned ten
> > > druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
> > >  
> > > Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragicky
> > > nestihalo na IOPS.
> > >  
> > > A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylo
> > > zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zaloham
> > > a nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsem
> > > a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to pole
> > > vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina udelala,
> > > ale...
> > >  
> > > Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data a ted
> > > je cekalo velmi neprijemne prekvapeni.
> > >  
> > > Cili ted stojime pred rozhodnutim, jestli investovat do redundance NASu
> > > (a backuperu s tim), nebo jit podle puvodniho planu a upgradovat sit na
> > > 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli kdumpu;
> > > a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
> > >  
> > > Co si o tom myslite? Investovat do storage a nechat to zatim na 2Gbit
> > > siti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?
> > >  
> > > Poznamecka: prosim ujistete se, ze v odpovedi je To:
> > > community-list at lists.vpsfree.cz (mailto:community-list at lists.vpsfree.cz)
> > > <mailto:community-list at lists.vpsfree.cz>, na outage-list se musi prispevky
> > > schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne
> > > diskuze.
> > >  
> > > /snajpa
> > >  
> > > On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
> > > > Je odkopirovano 9.5 TB z 22 TB.
> > > >  
> > > > /snajpa
> > > >  
> > > > On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
> > > > > Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11 hodin, odhadem
> > > > > to znamena, ze se bude syncovat jeste cca dalsich 30 hodin.
> > > > >  
> > > > > Behem toho je NAS dostupny jenom jako read-only.
> > > > >  
> > > > > Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz uz by melo
> > > > > jit rychleji (backuper ma vic disku, nez na kolika ma data soucasny
> > > > > nasbox, cili zpatky to pojede rychleji).
> > > > >  
> > > > > Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo vsechna
> > > > > data zahodit a vyrobit na nem pool znova - a to, i kdyz vsude piseme, ze
> > > > > neni zalohovany, nam prislo jako mnohem horsi varianta, nez ho odstavit
> > > > > na par dni jako read-only.
> > > > >  
> > > > > Odkopirujte si prosim data na VPSky, pokud je aplikace potrebuji, kdo
> > > > > kvuli tomu potrebujete docasne zvednout misto na disku, napiste na
> > > > > podporu a pokusime se to nejak vyresit.
> > > > >  
> > > > > Pokud ta data nepotrebuji aplikace k behu, tak na to prosim nesahejte,
> > > > > od toho to syncujeme na backuper, abychom zachranili, co se da.
> > > > >  
> > > > > Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda se, opravdu
> > > > > jenom 58 souboru (a to jeste ne uplne, ale maji poskozenych par bitu,
> > > > > coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne).
> > > > >  
> > > > > /snajpa
> > > > >  
> > > > > On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
> > > > > > Ahojte,
> > > > > >  
> > > > > > na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu s daty.
> > > > > >  
> > > > > > Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-pole) po
> > > > > > umrti
> > > > > > jednoho disku, kdy dalsi disk ze stejneho vdevu zacal hlasit chyby pri
> > > > > > cteni. Evidentne od posledniho scrubu (cca mesic zpatky) na nem vznikly
> > > > > > neopravitelne oblasti, ktere nejdou precist.
> > > > > >  
> > > > > > Zatim vime o 58 neobnovitelnych souborech, je to ve stavu, kdy ten disk
> > > > > > dava nejaka data, cili to nevypada ze by bylo po datech, ale vic se
> > > > > > dozvime, jakmile dobehne sync z nasboxu na backuper.
> > > > > >  
> > > > > > Prepnul jsem nasbox do readonly rezimu, aby se predeslo dalsimu
> > > > > > poskozovani dat a mezi tim se data syncuji na backuper (aktualne to
> > > > > > jede
> > > > > > okolo 150MB/s a je to 22TB dat).
> > > > > >  
> > > > > > Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s
> > > > > > bezpecnejsi
> > > > > > konfiguraci, aby se podobne situaci predeslo a pool vydrzel umrti vic
> > > > > > disku ve vsech pripadech.
> > > > > >  
> > > > > > Tem, co se jich poskozena data tykaji, napiseme behem dne mail se
> > > > > > seznamem poskozenych souboru.
> > > > > >  
> > > > > > Budu dal updatovat o prubehu, jakmile bude dalsi progress.
> > > > > >  
> > > > > > /snajpa
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > _______________________________________________
> > > > > > Outage-list mailing list
> > > > > > Outage-list at lists.vpsfree.cz <mailto:Outage-list at lists.vpsfree.cz>
> > > > > > http://lists.vpsfree.cz/listinfo/outage-list
> > > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > > _______________________________________________
> > > > > Outage-list mailing list
> > > > > Outage-list at lists.vpsfree.cz <mailto:Outage-list at lists.vpsfree.cz>
> > > > > http://lists.vpsfree.cz/listinfo/outage-list
> > > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > _______________________________________________
> > > > Outage-list mailing list
> > > > Outage-list at lists.vpsfree.cz <mailto:Outage-list at lists.vpsfree.cz>
> > > > http://lists.vpsfree.cz/listinfo/outage-list
> > > >  
> > >  
> > > _______________________________________________
> > > Outage-list mailing list
> > > Outage-list at lists.vpsfree.cz <mailto:Outage-list at lists.vpsfree.cz>
> > > http://lists.vpsfree.cz/listinfo/outage-list
> > >  
> >  
> >  
> >  
> >  
> > _______________________________________________
> > Community-list mailing list
> > Community-list at lists.vpsfree.cz (mailto:Community-list at lists.vpsfree.cz)
> > http://lists.vpsfree.cz/listinfo/community-list
> >  
>  
>  
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz (mailto:Community-list at lists.vpsfree.cz)
> http://lists.vpsfree.cz/listinfo/community-list
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20160728/b4f78081/attachment-0002.html>