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

29 Jul 2016

Ahoj,
pls 10Gbit

Jan Macík
PS: (pokud nekdo znáte poctivého politika tak mě na něj prosím pošlete kontak) 
______________________________________________________________
...
  Od: open(a)2devnull.work
 Komu: community-list(a)lists.vpsfree.cz
 Datum: 29.07.2016 11:55
 Předmět: [vpsFree.cz: community-list] NAS read-only, poskozeny filesystem
 Za mna tiez zvysenie siete na 10 Gbit.

 Oto

 _______________________________________
 Dňa 29.07.2016 o 0:09 Marek Palatinus napísal(a):
...
  10 Gbit. Podminky NASu jsou pro neprodukcni data a
zalohy zaloh uplne
 dostatecne.

 Marek

 2016-07-28 21:51 GMT+02:00 Marek Fabian &lt;marekfab(a)gmail.com
 <mailto:marekfab@gmail.com>>:

     Za mna zvyseniena 10 Gbit.

     Marek Fabo Fabian

     2016-07-28 14:24 GMT+02:00 Pavel Snajdr &lt;snajpa(a)snajpa.net
     <mailto:snajpa@snajpa.net>>:

         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(a)lists.vpsfree.cz
         <mailto:community-list@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(a)lists.vpsfree.cz         
<mailto:Outage-list@lists.vpsfree.cz>
 >>
http://lists.vpsfree.cz/listinfo/outage-list
<http://lists.vpsfree.cz/listinfo/outage-list>
>>
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz         
<mailto:Outage-list@lists.vpsfree.cz>

http://lists.vpsfree.cz/listinfo/outage-list
<http://lists.vpsfree.cz/listinfo/outage-list>

 _______________________________________________
 Outage-list mailing list
 Outage-list(a)lists.vpsfree.cz          <mailto:Outage-list@lists.vpsfree.cz>
  http://lists.vpsfree.cz/listinfo/outage-list
<http://lists.vpsfree.cz/listinfo/outage-list>

         _______________________________________________
         Outage-list mailing list
         Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
         http://lists.vpsfree.cz/listinfo/outage-list
<http://lists.vpsfree.cz/listinfo/outage-list>

     -- 
     *Marek Fabian*
     Email: marekfab(a)gmail.com <mailto:marekfab@gmail.com>
     Skype: marek.fabian

     _______________________________________________
     Community-list mailing list
     Community-list(a)lists.vpsfree.cz
     <mailto:Community-list@lists.vpsfree.cz>
     http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>

 _______________________________________________
 Community-list mailing list
 Community-list(a)lists.vpsfree.cz
 http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>  
 _______________________________________________
 Community-list mailing list
 Community-list(a)lists.vpsfree.cz
 http://lists.vpsfree.cz/listinfo/community-list
<http://lists.vpsfree.cz/listinfo/community-list>