Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem
Ahoj,
za me idealne oboje :).. rychly + zalohovany. A pokud si musim vybrat, tak momentalne radeji rychlejsi s prustrelnejsi zalohou.
NAS od zacatku pouzivame s vedomim nezalohovani. Mame tam >500G read-only dat (video sharing) + nejaky tempy. Takze, kdyz to zdechne, tak pocitam s tim, ze to tam uploadnu znova.
Obcas muzeme delat nejaky spicky na trafic ... kdyz se sejdou lidi. Proto ta propustnost.
Toz tak, -Igor
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@lists.vpsfree.cz, na outage-list se musi prispevky schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne diskuze.
/snajpa
Ja jsem na tom stejne - jsem pro posileni site. Na nas mam treti repliku zaloh, plus nejaky tempy, takze to me fakt netrapi a rychlejsi sit bude urcite lepsi reseni :)
h00ked
Odesláno z iPhonu
28. 7. 2016 v 14:48, Szoke Igor igor@szoke.cz:
Ahoj,
za me idealne oboje :).. rychly + zalohovany. A pokud si musim vybrat, tak momentalne radeji rychlejsi s prustrelnejsi zalohou.
NAS od zacatku pouzivame s vedomim nezalohovani. Mame tam >500G read-only dat (video sharing) + nejaky tempy. Takze, kdyz to zdechne, tak pocitam s tim, ze to tam uploadnu znova.
Obcas muzeme delat nejaky spicky na trafic ... kdyz se sejdou lidi. Proto ta propustnost.
Toz tak, -Igor
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@lists.vpsfree.cz, na outage-list se musi prispevky schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne diskuze.
/snajpa
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
Miroslav Marcišin -
Szoke Igor