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

Thu Jul 28 15:21:58 CEST 2016

Jinak pro predstavu, co by znamenala redundance NASu:

Soucasny nasbox je pro redundanci nevhodny, protoze ma SATA disky a ty
umi jenom jednoho hosta, cili kdyz upadne head node toho storage, je
potreba SAS disku, aby mohl zacit servovat data druhy head node.

SAS umozni tedy pripojit k jednomu disku dva servery (v tomhle pripade,
jak bychom ho pouzili).

Soucasny nasbox by se pak pouzil na zalohy dat z SAS NASu a zrejme i
backuperu, cili by byla data na SAS NASu, a na soucasnem hw, ktery dela
NAS, by byla near-realtime kopie (par minut stara data, periodicky
send/recv).

Tady pri te replikaci bychom ovsem asi vyrazne breceli bez 10Gbit site.

Pokud vezmeme variantu 10Gbit site, tak by NAS zustal, jak je, backuper
to same (pricemz je oba dostaneme na prijatelnejsi konfiguraci datove
redundance na urovni disku, ale budou mit vzdycky jenom jeden head node).

Celkove muzu rict, ze s heady tech storage poli az tak problem neni a
pokud budou data ulozene bezpecneji, nez jsou ted (ie. jina konfigurace
disku v ramci toho pole), tak jedine, co tem polim realne hrozi do
budoucna je to, ze upadne head node.

All said, mame taky moznost ten SAS NAS postavit casem, az po 10Gbit siti.

/snajpa

On 07/28/2016 02:24 PM, 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, 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
>>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/outage-list
>>
> 
> 
> 
> _______________________________________________
> Outage-list mailing list
> Outage-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/outage-list
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20160728/11734b07/attachment.sig>