diskove pole pro webhosting

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Úterý Únor 12 18:57:43 CET 2008


On Fri, 8 Feb 2008, Michal Krajčírovič wrote:

> Pole bude sice samozrejme na zalohovanem napajeni atd., ale i tak muze
> dojit k vytuhnuti, nutnosti fyzickeho restartu, vypadku proudu atd. a
> samozrejme je naprosto prioritni, aby se neposkodila zadna data a
> nemuselo se treba restaurovat cele pole nekolik hodin.

Záleží, co myslíte pod "restaurovat celé pole", ale mám špatný pocit, že
u linuxového sw RAIDu se přepočítávání parity po neočekávaném restartu
nevyhnete. Dá se to jedině trochu omezit, když budete mít pole, kam se
zapisuje jen málo často, a použijete "safe mode".

Cosi jako "RAID s žurnálem" umí afaik jen dm-mirror při zrcadlení. Ovšem
v kombinaci s žurnálovým fs je to stejně poněkud overkill, tady má
koncepčně dost navrch solarisové ZFS, které má redundanci zabudovanou do
souborového systému. (Na druhou stranu jsem před časem diskutoval s
jakýmsi potenciálním dodavatelem storage systému, který měl být postaven
na sunovských serverech a ZFS, a moje představa, že ten systém by měl být
neustále v provozu a funkční a jen se budou občas vyměňovat porouchané
disky s pravděpodobností ztráty dat zanedbatelně malou, se zřejmě dost
lišila od toho, jak si to představovali oni. Tak nevím.)

Možná strčit žurnál od fs na samostatné pole (raději RAID1 než RAID5/6),
nechat žurnálovat i zápisy dat (což tedy umí jen ext3 s data=journal)
a pole, kde budou data normálně umístěna, nějakým kladivem přesvědčit,
že si nemusí paritu přepočítávat, protože se to automaticky spraví, když
bude fs čistit transakční log.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."




Další informace o konferenci Linux