Vlákno názorů k článku Databázový server na platformě Intel 32bit od Yenya - Kdyz uz tady mame flame war IDE versus...

Kdyz uz tady mame flame war IDE versus SCSI, je zajimave, ze nikdo nenapadl autorovo tvrzeni o RAIDech:

- RAID-1 se pry prilis nepouziva. Ja myslim ze na DB server je RAID-1 jedina volba (nepocitam ruzne kombinace 1+0 nebo 0+1).

- Autorovo "rozhodne HW RAID" bych zmenil na "rozhodne SW RAID", aspon pokud je OS Linux. DB server nedela presuny velkych bloku dat, takze nevadi, kdyz data pujdou po sbernici vickrat. No a abyste meli HW RAID srovnatelne rychly se SW RAIDem v Linuxu, museli byste mit na RAID radici tolik pameti, kolik ji v beznem provozu Linux pouziva jako cache. A pamet do radicu je typicky drazsi nez RAM pocitace. Z vlastni zkusenosti vim, ze treba RAID-5 na HW RAID radici s 32MB RAM byl asi o 30% pomalejsi nez SW RAID-5 na stejnem radici a stejnych discich - proste proto, ze Linuxovy RAID mel jakoby "vetsi cache". U HW RAIDu s cache je treba myslet na to, co se stane kdyz vypnou proud (tedy co s daty, ktera jsou ve write-back cache a o kterych si OS mysli, ze uz jsou bezpecne na disku). Ma vas HW RAID radic nejakou solid-state pamet? Pokud ne, mate problem.
Navic SW RAID je IMHO flexibilnejsi (muzete na jednom disku kombinovat ruzne RAID-1 a RAID-5 a dalsi nad ruznymi partisnami tehoz disku. Tohle udelate jen na high-end diskovych polich (HP EVA).

- pri zapisu na RAID-5 neni treba nacist cely stripe. Zapis funguje takto: nactu stara data, nactu starou paritu, pomoci "stara data" xor "stara parita " xor "nova data" spoctu novou paritu, a zapisu novou paritu a nova data. Nic me nenuti nacitat cely stripe (ale porad jsou to dve cteni a dva zapisy na jednu zapisovou operaci).

- proc je pro RAID-0 optimalni pouziti tri disku?

Prijde mi, ze cely clanek je o tom "jak si myslim ze bych postavil DB server, aniz vim cokoli o typu zateze, ktera na nem pobezi".

Mam zkusenosti s podobnymi servery a jedine co o ladeni vykonu muzu rict je, ze je to specificke pro konkretni aplikaci. Je treba pocitat s tim, ze typicky 7500RPM disk udela cca 70-130 operaci za sekundu (a je temer jedno - aspon pro databaze - jak velke operace se delaji). Rychlejsi disky delaji umerne vic. No a z tohoto je treba vyjit pri rozhodovani kolik koupit disku a do jakych RAIDu je pospojovat.

-Yenya

>>U HW RAIDu s cache je treba myslet na to, co se >>stane kdyz vypnou proud (tedy co s daty, ktera >>jsou ve write-back cache a o kterych si OS mysli, >>ze uz jsou bezpecne na disku). Ma vas HW RAID >>radic nejakou solid-state pamet? Pokud ne, mate >>problem.

A co UPS a komunikace serveru s UPS ?? Samozrejmosti je mit pripojeny takovyto server na UPS a mit nakonfigurovany nejaky ten automaticky shutdown pri vybiti napr 20 %. Server se korektne shodi. Nehlede na to ze spousta HW radicu ma v sobje baterii, ktera data podrzi po dobu vypadku.

>>Navic SW RAID je IMHO flexibilnejsi (muzete na
jednom disku kombinovat ruzne RAID-1 a RAID-5 a dalsi nad ruznymi partisnami tehoz disku. Tohle udelate jen na high-end diskovych polich (HP EVA).

To neni tak uplne pravda, napr RAID radice od HP to umeji od rady 5 (5i,5xxx atd.) a ty sou ve standartni vybave kazdeho proliantu.

Co se cache tyce i zde bych byl opatrny, napr u Vami zminene HP EVA HP tvrdi, ze velka cache neni potreba, protoze vykonostne radic HSV100 vse ustiha. Je fakt ze defaultni velikost cache u EVY je relativne nizka(256MB) oproti starsim radicum HSG80 (512MB)

> A co UPS a komunikace serveru s UPS ??

UPS prichazeji a odchazeji. Solid-state nebo baterii zalohovana write-back cache je proste nutnost.

> Co se cache tyce i zde bych byl opatrny, napr u Vami zminene HP EVA HP tvrdi, ze velka cache neni potreba, protoze vykonostne radic HSV100 vse ustiha.

Checht. A to ten radic pouziva nejakou magii pro to,
aby pri stejnych discich byl stejne rychly jako radic s dvojnasobkem cache? Pokud nemaji nejakou HW kompresi, tak si nedovedu predstavit, kdy by libovolne dobry radic s polovinou pameti byl stejne rychly jako (napriklad) SW RAID na Linuxu s dvojnasobkem pameti. Samozrejme v pripade, kdy testovaci zatez skutecne celou tu cache vyuzije.

-Yenya

>>
Checht. A to ten radic pouziva nejakou magii pro to,
aby pri stejnych discich byl stejne rychly jako radic s dvojnasobkem cache? Pokud nemaji nejakou HW kompresi, tak si nedovedu predstavit, kdy by libovolne dobry radic s polovinou pameti byl stejne rychly jako (napriklad) SW RAID na Linuxu s dvojnasobkem pameti. Samozrejme v pripade, kdy testovaci zatez skutecne celou tu cache vyuzije.

Ano to mate samozrejme pravdu. Jen sem tim chtel rict ze rychlost HW RAIDu neni vzdy o velikosti cache. Pokud budu mit HSG80 s 512MB cache a HSV100 s 256 pak HSV bude pravdepodobne rychlejsi, protoze architektura obou radicu je uplne odlisna (EVA umi VRAIDY, je plne 2Gbitova, jine disky atd atd.)

Nemám to ověřené, neboť na databázových server SW-RAID nepoužívám, ale domnívám se, že objem cache není zdaleka všechno. Navíc použitím HW raidu přece o výhody systémové cache nepřijdete.

Jako největší nevýhodu SW-RAIDu považuji nutnost posílat stejná data po systémové i SCSI sběrnici vícekrát podle toho, kolik máte mirrorů/disků, čímž se omezuje dostupné pásmo a zvyšuje režie celého přenosu. V případě konfigurací kde se dopočítává parita (RAID5) může zase onboard procesor odlehčit nejen hlavnímu procesoru, ale serveru jako celku. Paritní ani redundatdní informace neopouštějí SCSI subsystém, není potřeba je přenášet po sběrnici, ukládat do paměti, zaneřádit jimi cache, dopočítavat XOR a to samé nazpět. I když to není výpočetně náročná operace, tak to všechno stojí cenný procesorový čas a hlavně I/O cykly, které zejména v případě většího zatížení budou chybět.

HW řadiče mají obvykle daleko lépe ošetřené havarijní stavy nebo hot-swap, bývají propojené se systémy pro management, dokáží operační systém zcela oprostit od problémů s polem, reportovat problémy prostřednictvím různých kanálů, což si všechno v případě SW-RAIDu musíte realizovat pomocí vlastních skriptů individuálně. Představte si, když se staráte o desítky takových serverů...

Poznamka ze neni potreba nacitat pri zapisu cely strip-size u raid-5 mne
velice zaujala. Napsal jsem si tento testovaci soft, mrknete se na to,
vyzkousejte a poslete vysledky.
U meho HW Raidu to ale cely stripe nacita, protoze rychlost zapisu s
rostouci velikosti stripsize primo umerne klesa.

#! /usr/local/bin/python
import time
FILESIZE=500 #in MB
NAME="test.tmp"
SKIPBYTES=65536

try:
f=open(NAME,"r+")
except Exception:
print "creating",FILESIZE,"MB test file"
f=open(NAME,"w")
for i in xrange(1,FILESIZE*1024):
f.write('1'*1024)
f.close()
f=open(NAME,"r+")

STEPS=FILESIZE*1024*1024/SKIPBYTES
print "Write 1 byte every",SKIPBYTES,". Total",STEPS,"writes."
raw_input("Enter to start write-test..")

start=time.time()
for i in xrange(0,FILESIZE*1024*1024,SKIPBYTES):
f.write('3')
f.seek(i)

f.close()
needed=time.time()-start
print "Total time",needed,"seconds.",STEPS/needed,"Writes per second."

Nejak nerozumim, co tim programem chcete testovat. Na otestovani n+1-nasobneho RAID-5 byste potreboval radove n procesu/threadu ktere by cetly nebo n/2 procesu ktere by zapisovaly.

Mimochodem, ja netvrdim, ze by nacteni celeho stripe
bylo nejak nevyhodne - to neni. Jen ze neni nutne
cely stripe nacitat, pokud radic nechce.

-Yenya

Chtel jsem testovat zda kdyz budu zapisovat 1 bajt bez toho aniz bych cetl
predtim cely stripsize a postupne zvetsovat stripsize na hw raidu tak zda to
ovlivni rychlost zapisu ci ne. V mem pripade to s rostouci velikosti stripsize
umerne brzdi, takze to vypada, ze se nacita cely.

jinak ohledne toho mozneho castecneho nacitani mate pravdu. V dokumentaci k
raidu jsem nasel:

When the amount of data being written is less than a full stripe worth, the
`small write' problem occurs. Since a `small write' means only a portion of
the stripe on the components is going to change, the data (and parity) on the
components must be updated slightly differently. First, the `old parity' and
`old data' must be read from the components. Then the new parity is
constructed, using the new data to be written, and the old data and old parity.
Finally, the new data and new parity are written. All this extra data
shuffling results in a serious loss of performance, and is typically 2 to 4
times slower than a full stripe write (or read). To combat this problem in the
real world, it may be useful to ensure that stripe sizes are small enough that
a `large IO' from the system will use exactly one large stripe write.

Dale pisi, ze tohleto neimplementuji.