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

Thu Jul 28 15:00:32 CEST 2016

A use-case, na jaky to bylo puvodne mysleny, jsi uplne odignoroval: ie.
tvoje zaloha-zalohy. Coz je btw, jak to vetsina clenu ted pouziva a je
to tak legit.

Cili pokud by vetsina byla ok s tim, ze se to bude pouzivat dal na
zalohy-zaloh podle clenova vlastniho gusta, neospravedlnilo by to
investici do redundance, naopak by to vsem takovym uskodilo, protoze by
to zpomalilo, co mohli mit driv - 10Gbit sit.

/snajpa

On 07/28/2016 02:57 PM, Vojtěch Knyttl wrote:
> 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
> 
> 
> 
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-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/9bf88992/attachment.sig>