Community-list July 2016

community-list@lists.vpsfree.cz

46 participants
16 discussions

by kuba＠ufiseru.cz

ahoj, líbila by se mi featura mít defaultní SSH klíč někde ve vpsadminu, kterej by se sypal do všech (re)instalovaných VPS. Je to dobreje nápad, nebo blbej nápad, nebo jakej je to nápad? A v který komponentě na githubu tomu mam udělat issue? -miky.

8 years, 4 months

Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

by Jiří Pucherna

Ahoj, 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. Jirka -- ------------------------------------------------- Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01 Telefon: +420 724 330 493 | Web: http://www.reklalink.cz 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(a)lists.vpsfree.cz, na outage-list se musi prispevky > schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne > diskuze. > > /snajpa

8 years, 4 months

Re: [vpsFree.cz: community-list] NAS read-only, poskozeny filesystem

by bacu＠centrum.cz

Ahoj, pls 10Gbit Jan Macík PS: (pokud nekdo znáte poctivého politika tak mě na něj prosím pošlete kontak) ______________________________________________________________ > Od: open(a)2devnull.work > Komu: community-list(a)lists.vpsfree.cz > Datum: 29.07.2016 11:55 > Předmět: [vpsFree.cz: community-list] NAS read-only, poskozeny filesystem > 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 <http://lists.vpsfree.cz/listinfo/outage-list> > >>> > >> > >> > >> > >> _______________________________________________ > >> Outage-list mailing list > >> Outage-list(a)lists.vpsfree.cz > <mailto:Outage-list@lists.vpsfree.cz> > >> http://lists.vpsfree.cz/listinfo/outage-list <http://lists.vpsfree.cz/listinfo/outage-list> > >> > > > > > > > > _______________________________________________ > > Outage-list mailing list > > Outage-list(a)lists.vpsfree.cz > <mailto:Outage-list@lists.vpsfree.cz> > > http://lists.vpsfree.cz/listinfo/outage-list <http://lists.vpsfree.cz/listinfo/outage-list> > > > > > _______________________________________________ > Outage-list mailing list > Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz> > http://lists.vpsfree.cz/listinfo/outage-list <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 <http://lists.vpsfree.cz/listinfo/community-list> > > > > > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list> _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>

8 years, 4 months

Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

by Marek Fabian

Za mna zvyseniena 10 Gbit. Marek Fabo Fabian 2016-07-28 14:24 GMT+02:00 Pavel Snajdr <snajpa(a)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, 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 > >>> http://lists.vpsfree.cz/listinfo/outage-list > >>> > >> > >> > >> > >> _______________________________________________ > >> Outage-list mailing list > >> Outage-list(a)lists.vpsfree.cz > >> http://lists.vpsfree.cz/listinfo/outage-list > >> > > > > > > > > _______________________________________________ > > Outage-list mailing list > > Outage-list(a)lists.vpsfree.cz > > http://lists.vpsfree.cz/listinfo/outage-list > > > > > _______________________________________________ > Outage-list mailing list > Outage-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/outage-list > > -- *Marek Fabian* Email: marekfab(a)gmail.com Skype: marek.fabian

8 years, 4 months

Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

by Vojtěch Knyttl

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(a)goout.cz +420 607 008 510 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(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) > > > http://lists.vpsfree.cz/listinfo/outage-list > > > > > > > > > > > > > _______________________________________________ > > 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) > http://lists.vpsfree.cz/listinfo/outage-list > >

8 years, 4 months

Re: [vpsFree.cz: community-list] NAS read-only, poskozeny filesystem

by Jindřich Sadílek

10Gbit Mám tam jednu z destinací crashplanu, přišel bych nejspíše o X předchozích verzí souborů dozadu + smazaných, co jsem neposlal do crashplaního cloudu - ale orig data mám, takže krom mrzení s přenastavením crashplanu bych asi ani moc nebrečel... J Dne Čt, 28. červenec 2016 v 16:25 h uživatel David Kopecký napsal: > Ahoj, > > rozhodne puvodni plan, 10Gbit. I kdyz jsem se chystal vyuzit NAS na > trochu citlivejsi "produkcni" veci v nasledujici dobe, tak kdyz to > nebude rychle pristupne, je to stejne prd platne. > > Dik, > David > > čt 28. 7. 2016 v 15:54 odesílatel <kuba(a)ufiseru.cz> napsal: >> Za mě momentálně raději síť, ale redundantní NAS hned po tom. A >> důležité je to slovo "redundantní", aby si to někdo omylem nevyložil >> jako "zálohovaný" :) >> >> -m. >> >> >> >> July 28 2016 3:37 PM, "Pavel Snajdr" <snajpa(a)snajpa.net> wrote: >> > 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(a)gmail.com >> >> <mailto:michal.zobec.news@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(a)zobec.net <mailto:michal@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(a)lists.vpsfree.cz >> >> <mailto:community-list-bounces@lists.vpsfree.cz> >> >> [mailto:community-list-bounces@lists.vpsfree.cz >> >> <mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of >> >> Pavel >> >> Snajdr >> >> Sent: Thursday, July 28, 2016 2:54 PM >> >> To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz >> >> <mailto:community-list@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(a)goout.cz <mailto:knyttl@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(a)lists.vpsfree.cz >> >> <mailto:community-list@lists.vpsfree.cz> >> >>>> <mailto:community-list@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> >> >> <mailto:Outage-list@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> >> >> <mailto:Outage-list@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> >> >> <mailto:Outage-list@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> >> >> <mailto:Outage-list@lists.vpsfree.cz >> >> <mailto:Outage-list@lists.vpsfree.cz>> >> >>>> http://lists.vpsfree.cz/listinfo/outage-list >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 <mailto:Community- >> >> list(a)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 >> > >> > _______________________________________________ >> > Community-list mailing list >> > Community-list(a)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 > _________________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list

8 years, 4 months

Komerční VPS hosting v Česku - doporučení

by Nikos Timiopulos

Ahoj, můžete se prosím podělit o své dlouhodobější zkušenosti s našimi komerčními poskytovateli vpsek a některé doporučit? Co jsem se tak letmo díval na některá srovnání, tak úplně důvěryhodně nevypadají. Není to prosím provokace směrem k vpsfree a výpadkům, tady naopak za sebe musím kluky co se starají pochválit, ale potřebuji pro jeden projekt vps s SLA. Osobně mám zkušenost se 2: digitalocean.com - 20$/měsíčně, 2x Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz, 2GB RAM, 40GB SSD I když relativně krátkou dobu (půl roku), až na jeden restart z jejich strany na začátku jsem zatím nezaznamenal žádný výpadek, ale výkon CPU mi přijde nic moc (ale to jsem asi zhýčkaný vpsfree) a taky mě nebaví posílat peníze mimo ČR + asi o 17ms vyšší odezva do Frankfurtu. wedos.cz :-) - 160 Kč / měsíc bez DPH, 1x CPU blíže neurčený Xeon 1.7GHz, 2GB RAM, 15GB SSD Zkušenost mám zhruba rok, co 2 měsíce to výpadek kolem 5min, výkon chabý (ale asi odpovídá parametrům). Když jsem objednával, byla to nejlevnější varianta s SSD, za IPv4 (která není součástí) chtěli 30 nebo 40 kaček měsíčně navíc, dnes ale mají v ceníku 1 Kč. Jinak z mého chabého gůglení jsem déle času strávil nad https://www.zonercloud.cz/produkty/cloud-server-linux/ <https://www.zonercloud.cz/produkty/cloud-server-linux/>, jestli s nimi má někdo zkušenost, prosím podělte se. Díky, Nikos

8 years, 4 months

Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

by Pavel Snajdr

Jinak pro predstavu, co by znamenala redundance NASu: Soucasny nasbox je pro redundanci nevhodny, protoze ma SATA disky a ty umi jenom jednoho hosta, cili kdyz upadne head node toho storage, je potreba SAS disku, aby mohl zacit servovat data druhy head node. SAS umozni tedy pripojit k jednomu disku dva servery (v tomhle pripade, jak bychom ho pouzili). Soucasny nasbox by se pak pouzil na zalohy dat z SAS NASu a zrejme i backuperu, cili by byla data na SAS NASu, a na soucasnem hw, ktery dela NAS, by byla near-realtime kopie (par minut stara data, periodicky send/recv). Tady pri te replikaci bychom ovsem asi vyrazne breceli bez 10Gbit site. Pokud vezmeme variantu 10Gbit site, tak by NAS zustal, jak je, backuper to same (pricemz je oba dostaneme na prijatelnejsi konfiguraci datove redundance na urovni disku, ale budou mit vzdycky jenom jeden head node). Celkove muzu rict, ze s heady tech storage poli az tak problem neni a pokud budou data ulozene bezpecneji, nez jsou ted (ie. jina konfigurace disku v ramci toho pole), tak jedine, co tem polim realne hrozi do budoucna je to, ze upadne head node. All said, mame taky moznost ten SAS NAS postavit casem, az po 10Gbit siti. /snajpa 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(a)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 >>>> http://lists.vpsfree.cz/listinfo/outage-list >>>> >>> >>> >>> >>> _______________________________________________ >>> Outage-list mailing list >>> Outage-list(a)lists.vpsfree.cz >>> http://lists.vpsfree.cz/listinfo/outage-list >>> >> >> >> >> _______________________________________________ >> Outage-list mailing list >> Outage-list(a)lists.vpsfree.cz >> http://lists.vpsfree.cz/listinfo/outage-list >> > > > > _______________________________________________ > Outage-list mailing list > Outage-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/outage-list >

8 years, 4 months

Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

by Silvestr Hašek

Podle mne určitě upgrade síťové infrastruktury. Vždycky bylo deklarováno jak NAS funguje a pokud to někdo ignoruje, no co na to říct. Osobně v tomto kroku pozoruji více výhod pro celý projekt a jeho rozvoj, zvláště pokud bude mít tenhle krok (kdump,...) vliv na vylepšení produkčního prostředí, o to by mělo jít v první řadě. ETNyx 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(a)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 >>>> http://lists.vpsfree.cz/listinfo/outage-list >>>> >>> >>> >>> _______________________________________________ >>> Outage-list mailing list >>> Outage-list(a)lists.vpsfree.cz >>> http://lists.vpsfree.cz/listinfo/outage-list >>> >> >> >> _______________________________________________ >> Outage-list mailing list >> Outage-list(a)lists.vpsfree.cz >> http://lists.vpsfree.cz/listinfo/outage-list >> > > > _______________________________________________ > Outage-list mailing list > Outage-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/outage-list

8 years, 4 months

Re: [vpsFree.cz: community-list] [vpsFree: outage-list] NAS read-only, poskozeny filesystem

by Petr Líbal

Ahojte, myslím že pravidla ohledně zálohování, teda spíš nezálohování NASu + backuperu.. jsou jasně daný, upozornění je všude dost a tak se k tomu musí člověk chovat, já osobně v tom nevidím žádný omezení/problém a rozhodně bych raději uvítal "původní" cestu: "...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)..." --- S pozdravem Petr Líbal 734 622 701| libal(a)volfsystems.cz Dne 2016-07-28 14:24, Pavel Snajdr napsal: > 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, 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 >>>> http://lists.vpsfree.cz/listinfo/outage-list >>>> >>> >>> >>> >>> _______________________________________________ >>> Outage-list mailing list >>> Outage-list(a)lists.vpsfree.cz >>> http://lists.vpsfree.cz/listinfo/outage-list >>> >> >> >> >> _______________________________________________ >> Outage-list mailing list >> Outage-list(a)lists.vpsfree.cz >> http://lists.vpsfree.cz/listinfo/outage-list >> > > > _______________________________________________ > Outage-list mailing list > Outage-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/outage-list

8 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list July 2016