[vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem
Jiří Pucherna
pucherna at reklalink.cz
Thu Jul 28 17:15:28 CEST 2016
Tak ja osobne nevidim duvod proc nemit na tom NASu treba prave ten
owncloud. Pokud to slouzi treba jako u nas pouze k synchronizaci a
stejne mam celej ten obraz na kazdem pc kde to pouzivam tak me vypadak
nebo i smazani nejak zavazne nezasahne.
J.
Dne 28.7.2016 v 15:36 Pavel Snajdr napsal(a):
> Samozrejme, ze to demokraticky nakonec rozhodne ten, kdo to odmaka a ma
> se o to pak starat, to je jasne :)
>
> Chtel jsem spis vedet, jak moc velky hlad je po redundantnim storage
> mimo VPS tak, aby mohl byt napr. sdileny mezi vice VPS pro produkcni data.
>
> Zatim to az tak nevypada.
>
> Napriklad mne zajimal prave nazor Igora, jelikoz ti tam maji, o cem vim,
> nejprodukcnejsi vec - kdyz nepocitam nejake ty firemni owncloudy,
> kterezto ale klidne mohly bezet rovnou z lokalnich disku u VPS (ale to
> by si ti dotycni museli priplatit za zalohovany disk space, ze...).
> Igor Szoke ma realny duvod nemit to lokalne, protoze je to hodne dat a
> kdyz ani on nema tezkou preferenci smerem k redundanci NASu, je, rekl
> bych, vcelku jasno, kterym smerem jit.
>
> /snajpa
>
> On 07/28/2016 03:30 PM, Miroslav Šedivý wrote:
>> Ahoj, za me urcite 10Gbit. Preci jen NAS je bonusova vec a ucpana sit
>> postihne vsechny. Neni to tak? Nejsem proti zálohování dat na NASu, ale
>> urcite az po upgrade sítě. Takovahle anketa je super, ale navzdory
>> demokratickým pravidlům, ktera ve vpsfree panuji by se to melo
>> rozhodnout s nadhledem a ne podle preferenci par diskutujících.
>>
>> Míra
>>
>>
>> Dne 28. 7. 2016 15:23 napsal uživatel "Michal Zobec (ZOBEC Consulting)"
>> <michal.zobec.news at gmail.com <mailto:michal.zobec.news at gmail.com>>:
>>
>> Mě by se taky hodilo zajistit bezpečnost dat na NAS. Sice si toho
>> jsem vědom, že teď nejsou zálohována, ale kapacita NAS se mi hodně
>> líbí (i když tak intenzivně ji nepoužívám).
>>
>>
>>
>> …
>>
>> s přátelským pozdravem | best regards
>>
>> Michal Zobec | Senior IT Consultant, Project Manager
>> Mobil: +420 608960987 <tel:%2B420%20608960987> | Email:
>> michal at zobec.net <mailto:michal at zobec.net>
>> LinkedIn | Na volne noze
>>
>> ZOBEC Consulting | Renneska trida 393/12, 63900 Brno, Czech Republic
>> web | blog | virtuální pc
>> Facebook | Twitter | LinkedIn | Google+
>>
>>
>>
>> Plánovaná nepřítomnost | Planned absence
>> (none)
>> …
>>
>>
>>
>>
>> -----Original Message-----
>> From: community-list-bounces at lists.vpsfree.cz
>> <mailto:community-list-bounces at lists.vpsfree.cz>
>> [mailto:community-list-bounces at lists.vpsfree.cz
>> <mailto:community-list-bounces at lists.vpsfree.cz>] On Behalf Of Pavel
>> Snajdr
>> Sent: Thursday, July 28, 2016 2:54 PM
>> To: vpsFree.cz Community list <community-list at lists.vpsfree.cz
>> <mailto:community-list at lists.vpsfree.cz>>
>> Subject: Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS
>> read-only, poskozeny filesystem
>>
>> 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 <tel:%2B420%20607%20008%20510>
>> >
>> > 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
>> <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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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
>>
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
--
-------------------------------------------------
Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01
Telefon: +420 724 330 493 | Web: http://www.reklalink.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20160728/3d4e1e6a/attachment-0002.html>
More information about the Community-list
mailing list