29 Jul
2016
29 Jul
'16
9:55 a.m.
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 <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 <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
>>
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz
<mailto:Outage-list@lists.vpsfree.cz>
_______________________________________________
Outage-list mailing list
Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
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
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list