<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ahoj,<br>
<br>
za nas se taky priklanime spise k upgradu site. NAS pouzivame take s
vedomim toho ze to neni zalohovane a nijak nas to momentalne
netrapi.<br>
<br>
Jirka<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------------
Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01
Telefon: +420 724 330 493 | Web: <a class="moz-txt-link-freetext" href="http://www.reklalink.cz">http://www.reklalink.cz</a> </pre>
<br>
<br>
On 07/28/2016 02:24 PM, Pavel Snajdr wrote:
<br>
<blockquote type="cite" style="color: #000000;">Prave bezi posledni
dosyncnuti dat, odhadem za 2-3 hodiny prepneme
<br>
mounty read-only na backuper, znovu vytvorime pool na nasboxu s
<br>
bezpecnejsi konfiguraci.
<br>
Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
<br>
benchmarky tech konfiguraci, co mne napadaji jako prijatelne a
uvidime,
<br>
co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
<br>
backuper, abychom se vyhnuli stejne situaci v budoucnu na
backuperu.
<br>
<br>
K tomu, proc jsou v tom poolu disky se slabou redundanci, ie.
3-diskove
<br>
RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox
vznikly s
<br>
malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich
VDEVu
<br>
bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned
ten
<br>
druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
<br>
<br>
Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by
tragicky
<br>
nestihalo na IOPS.
<br>
<br>
A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam
prebylo
<br>
zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror
zaloham
<br>
a nechteli jsme ho nechat valet jen tak, proto jsme ho
zpristupnili vsem
<br>
a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to
pole
<br>
vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina
udelala, ale...
<br>
<br>
Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data
a ted
<br>
je cekalo velmi neprijemne prekvapeni.
<br>
<br>
Cili ted stojime pred rozhodnutim, jestli investovat do redundance
NASu
<br>
(a backuperu s tim), nebo jit podle puvodniho planu a upgradovat
sit na
<br>
10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli
kdumpu;
<br>
a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
<br>
<br>
Co si o tom myslite? Investovat do storage a nechat to zatim na
2Gbit
<br>
siti (ktera je, nutno rict, sem tam, uz pekne na hrane s
propustnosti)?
<br>
<br>
Poznamecka: prosim ujistete se, ze v odpovedi je To:
<br>
<a class="moz-txt-link-abbreviated"
href="mailto:community-list@lists.vpsfree.cz">community-list@lists.vpsfree.cz</a>,
na outage-list se musi prispevky
<br>
schvalovat a mely by tam jit jenom relevantni informace o
vypadcich, ne
<br>
diskuze.
<br>
<br>
/snajpa
<br>
</blockquote>
</body>
</html>