Hele produkční data tam nemám, ale to neznamená, že o ty data chci přijít :-) Jakože pak je tam vůbec ani nemusim dávat :-)On Thursday 28. July 2016 at 14:54, Pavel Snajdr wrote:
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 umrelv kernel panicu a podobne, protoze budeme mit kdump).Jak jsem psal, NAS od zacatku nemel byt redundantni, takze pokud hoprave ted vyuzivas na produkcni data, delas to spatne a tenhle hlas bychtedy vubec nemel pocitat.A tak uvidime, co reknou dalsi :)/snajpaOn 07/28/2016 02:29 PM, Vojtěch Knyttl wrote:Za mě určitě platí, že data bez redundance (ať produkční neboneprodukční), jako by jich nebylo. Za mě klidně budu mít míň storage,ale bezpečnou.Vojtěch Knyttl+420 607 008 510On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepnememounty read-only na backuper, znovu vytvorime pool na nasboxu sbezpecnejsi konfiguraci.Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejakebenchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,co z toho vyleze, stejna konfigurace se potom casem pouzije i probackuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskoveRAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly smalo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVubychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned tendruhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragickynestihalo na IOPS.A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylozalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zalohama nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsema od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to polevyuzijete 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 tedje 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 na10Gbit (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 2Gbitsiti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?Poznamecka: prosim ujistete se, ze v odpovedi je To:<mailto:community-list@lists.vpsfree.cz>, na outage-list se musi prispevkyschvalovat a mely by tam jit jenom relevantni informace o vypadcich, nediskuze./snajpaOn 07/27/2016 04:18 AM, Pavel Snajdr wrote:Je odkopirovano 9.5 TB z 22 TB./snajpaOn 07/26/2016 02:22 PM, Pavel Snajdr wrote:Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11 hodin, odhademto 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 melojit rychleji (backuper ma vic disku, nez na kolika ma data soucasnynasbox, cili zpatky to pojede rychleji).Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo vsechnadata zahodit a vyrobit na nem pool znova - a to, i kdyz vsude piseme, zeneni zalohovany, nam prislo jako mnohem horsi varianta, nez ho odstavitna par dni jako read-only.Odkopirujte si prosim data na VPSky, pokud je aplikace potrebuji, kdokvuli tomu potrebujete docasne zvednout misto na disku, napiste napodporu 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, opravdujenom 58 souboru (a to jeste ne uplne, ale maji poskozenych par bitu,coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne)./snajpaOn 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) poumrtijednoho disku, kdy dalsi disk ze stejneho vdevu zacal hlasit chyby pricteni. Evidentne od posledniho scrubu (cca mesic zpatky) na nem vzniklyneopravitelne oblasti, ktere nejdou precist.Zatim vime o 58 neobnovitelnych souborech, je to ve stavu, kdy ten diskdava nejaka data, cili to nevypada ze by bylo po datech, ale vic sedozvime, jakmile dobehne sync z nasboxu na backuper.Prepnul jsem nasbox do readonly rezimu, aby se predeslo dalsimuposkozovani dat a mezi tim se data syncuji na backuper (aktualne tojedeokolo 150MB/s a je to 22TB dat).Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu sbezpecnejsikonfiguraci, aby se podobne situaci predeslo a pool vydrzel umrti vicdisku ve vsech pripadech.Tem, co se jich poskozena data tykaji, napiseme behem dne mail seseznamem poskozenych souboru.Budu dal updatovat o prubehu, jakmile bude dalsi progress./snajpa_______________________________________________Outage-list mailing list_______________________________________________Outage-list mailing list_______________________________________________Outage-list mailing list_______________________________________________Outage-list mailing list_______________________________________________Community-list mailing list_______________________________________________Community-list mailing list
_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list