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.
> 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)"
>>
>> 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:
>> 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-----
>> Snajdr
>> Sent: Thursday, July 28, 2016 2:54 PM
>> 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
>>>
>>>
>>>
>>> +420 607 008 510 <tel:%2B420%20607%20008%20510>
>>>
>>>
>>>
>>> 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:
>>>> 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 mailing list
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Outage-list mailing list
>>>> _______________________________________________
>>>> Outage-list mailing list
>>>
>>>
>>>
>>> _______________________________________________
>>> Community-list mailing list
>>>
>>
>> _______________________________________________
>> Community-list mailing list
>>
>> _______________________________________________
>> Community-list mailing list
>
> _______________________________________________
> Community-list mailing list
_______________________________________________
Community-list mailing list