Re: [tech] jak wygladaja dane przy span volume kiedy padnie dysk

On Thu, 4 Aug 2005 22:54:05 +0200, PAndy wrote:

> "Piotr Smerda" <piotrs00@go2hell.pl> wrote in message
> news:1hirv8i530zuv$.1boj8r7skfxzi$.dlg@40tude.net...
>> On Thu, 4 Aug 2005 16:27:12 +0200, PAndy wrote:
>
>>> Zrob backup 1.2TB... :D - pytam sie o span set volume bo mam iles dyskow
> i
>>> chce wiedziec jakie jest ryzyko uwalenia danych na wszystkich dyskach
> jesli
>>> padnie tylko jeden dysk dla span set. co do stripingu zdaje sobie sprawe
> ze
>>> padniecie jednego niszczy wszystko ale span to sklejenie w jedna
> przestrzen
>>> roznych dyskow, nie jest jasno okreslone czy uszkodzeniu ulegna dane na
>>> uszkodzonym dysku + zakladki - czy poleci caly span set.
>>> Problem nie w danych ktore sa backupowane tylko w predkosci ich
> ewentualnego
>>> odtwarzania a co z tym zwiazane zablokowania pracy
>>
>> Hmmm a co to za problem? 1.2TB to 12 taśm LTO Ultrium-1, tyle backupów
> robi
>> się około 1.5 dnia zakładając że backupuje się 10MB/sek. Przy takich
>> pojemnościach macierzy wydatek nawet 10tys. na napęd zewnętrzny jest mały.
>
> Problem jest ze moze nawet firma by kupila LTO 400GB na kasetce bez
> kompresji mimo kosztow ale imo taniej wyjdzie kupno dyskow 400GB i zrobienie
> mirrora
>

Pewnie by wyszło taniej, ale dyski nie służą do *archiwizacji* - na dyskach
miałbyś jedną, dwie ostatnie kopie i co dalej? A jak ktoś będzie chciał
wersję dokumentu sprzed 2 tygodni? Odeślesz do /dev/bambus?
Poza tym obecnie stosuje się np taką metodę backupu :

dane oryginalne -> dysk backupowy -> taśma

>> Poza tym robienie tak wielkiej macierzy na span czy stripe jest pomysłem z
>> zasady chorym - jak można pozwolic sobie na tak wielkie ryzyko?
>
> Chodzi o to by miec jeden dysk widziany w sieci a zlozony z kilku fizycznych
> dyskow. a dyskach skaldowne sa pliki ktore zazwyczaj sa na plytach DVD i CD
> wiec to nie o radyklana utrate danych chodzi ale wygode dostepu stad pomysl
> by zrobic span.
> Maszyna zrobiona jest na XP pro i sluzy jako fileserver dla malej grupy
> roboczej - sepcyfika jest taka, duzo kopiowania plikow gdzie najmniejszy to
> sto kilkadziesiat MB a najwieksze dochodza do 8GB... co jakis czas pojawiaja
> sie nowe pliki ktore zazwyczaj sukcesywnie nagrywane sa na DVD.
>

Jeśli dane masz na CD/DVD to może zamiast inwestować w olbrzymie macierze
(do których i tak dostęp po sieci ma drugorzędne znaczenie) warto byłoby
kupić jukeboxa np na 200 płyt DVD i podłączyć to coś do sieci? Szybkość ta
sama, pewność większa (bo dysk Ci nie padnie, a kopię DVD możesz mieć w
szafie i na szybko wymienić).
Poza tym do takich danych które są często używane lepiej jednak zrobić
RAIDa i nie kombinować ze spanem ... o oczywistym podziale na kilka
wolumenów nie wspominam.

>> A co do backupów - problemem nie jest czas, problemem jest dobre
>> zaplanowanie backupów, wykorzystanie okien backupowych itp. Przy takich
>> pojemnościach trzeba to _DOKŁADNIE_ przemyśleć.
>
> Tu nei ma czegos takeigo jak krytyczna baza danych - wieksozc z danych
> dostpena jest na nosnikach CD i DVD - czesc mzona odtowrzyc robiac jej na
> nowo wiec tez nie klopot.
>

No to nie widzę potrzeby robienia backupów spana - skoro i tak masz
wszystko na płytach. W razie czego odzyskasz dane z całego spana :>

>> Do pełnych backupów baz danych o pojemnościach powyżej 100GB powinno się
>> stosować zmieniarki taśm/roboty z więcej niż jednym napędem i najlepiej
>> podłączone do sieci SAN lub chociaż po FC.
>
> Za drogo - maszyny spiete sa GigaEthernetem i jest ok.
>

Hehe ... a FC to niby dużo szybciej? 2.5Gb to tylko ok.3 razy szybciej niż
Gigabit Ethernet. A wąskim gardłem i tak będą dyski.

>> Miło by było przetestować także odtwarzanie - spotkalem się z przypadkiem
>> gdzie odtwarzanie trwało 5 razy dłużej niż backup. Samo składowanie danych
>> było bardzo szybkie - odtwarzanie było koszmarnie wolne. Obie te czynności
>> były wykonywane na macierzy RAID-5, w której zapis i liczenie sum
>> kontrolnych było bardzo wolne, odczyt był błyskawiczny.
>
> Taki urok RAID-5 zapis jest wolniejszy niz na pojedynczym - odczyt potrafi
> byl o kilkanascie % szybszy od pojedynczego - zalezy od kontrolera
>

Hmmm pisałem o zapisie. Ale zależy to głównie od kontrolera RAID. Są takie
które mają efektywniejsze algorytmy liczenia sum kontrolnych (jak np Mylex)
a są takie (jak niektóre PERCe Della) które się ślimaczą niemiłosiernie.

>> Poza tym jak wyobrazasz sobie spójność danych po padzie kawałka spanu? Jak
>> system ma wiedzieć czy padł akurat kawałek A czy C? MFT jest co prawda
>> porozrzucane, ale odbudowa tego i sprawdzenie który plik jest gdzie
>> zajełoby wiele czasu, dochodzi do tego fragmentacja plików itp.
>
> I tu dochodzimy do sedna - zakladam ze przechowywana jest informacja o
> fizycznej lokalizacji pliku w roznych miejscach
>

A co Ci da taka informacja (nawet nadmiarowa, w kilku miejscach) jak
będziesz miał sfragmentowane pliki tak że w najgorszym przypadku (a takie
należy jako pierwsze rozważać) będziesz miał w *każdym* kawałku spana po
kawałku z każdego pliku? Domyśl się co będzie jak Ci padnie choćby
najmniejszy kawałek tego spana...

>> O ile dobrze pamiętam to nawet tak dobre systemy plików jak VxFS nie
>> poradzą sobie z padem kawałka dysku ze spanu ...
>
> No i tu jest klopot - mzoe na kazdym dysku poeinna byc kopia wszystkich
> tablic?
>

A po co? Patrz wyżej.

>> Przemyśl przemigrowanie danych z wynalazków typu span i stripe na porządne
>> RAIDy typu 0+1 lub w ostateczności RAID-5.
>
> Tu jest problem ze to powinno wygladac jak jedna spojna przestrzen, w tej
> chwili mysle nad RAID5 na SATA - ale kontrolery sa abstrakcyjnie drogie - za
> 12 kanalowy 3000zl to duzo... dyski 400GB sa po ok 1200zl - moze nie przejsc
> u szefostwa a scalenie deyskow w jedna spojna przestrzen jest korzystne z
> punktu widzenia zarzadzania danymi i korzystania z nich.

Jeśli coś do czego ludzie dostają się przez sieć ma wyglądać jak jeden
spójny obszar (logicznie) to może warto zainteresować się DFSem? Możesz
"porozrzucać" dyski po różnych maszynach co pozwoli Ci uniknąć przestojów
przy padzie całej macierzy, da lepsze transfery w sieci bo dane będą słane
z różnych maszyn, oszczędzi dyski itp.

> Jak mowie nie zalezy mi na wyszukanym backupie ale na tym by po ewentualnej
> awarii odtworzyc jak najszybciej dane teraz ok 1.2TB w przyszlosci pewnie
> 2 - 4TB i dalej ma puchnac.

Jeśli to serwer plików i to takich które się na ogół trzyma też na DVD/CD
to lepszym rozwiązaniem wg mnie jest pozostawienie tej nieszczęsnej 1.2TB
maszyny i dokupienie jukeboxa. Będzie taniej i wygodniej niż rozbudowywać
macierz z dyskami i drżeć "bo coś może się popsuć"

> Co do do LTO to chyba firma bedzie czekac dopoki nie pojawi sie sie cos co
> wciagnie wiecej niz 1.2TB na kasetke... (ile to moze byc? rok - dwa?)
> pozdrawiam

A jeśli nawet się takie coś pojawi to musisz też rozważyć jak szybko dane
będą przesyłane z dysku na taśmę. Na razie SCSI to max 320MB (teoretycznie)
tak więc na zapełnienie 1.2 TB musiałbyś czekać 1.2h zakładając maksymalną
przepustowość co jest na razie abstrakcją. No i weź pod uwagę chore ceny od
razu po pojawieniu się taiego napędu na rynku ...

-- 
Pozdrawiam
Piotrek