hardware hibatures

Security-all

hardware hibatures

  • 913 megtekintés

( trey | 2004. 07. 13., k – 07:25 )

[quote:4dac1cc8e3="pete"]Jól hangzik. Annyit tudnék hozzátenni, hogy ha időkritikus rendszered van(vagyis nem csak statikus oldalak, hanem pl. adatbázisban tárolt állandóan frissülő/változó adatok) , akkor a cold iron helyett egy melegtartalék jobb lehet. Ugyanis az 1. vas elszállásakor az utsó mentés és az elszállás pillanatában levő állapot között értékes, vissza nem nyerhető adatok vesznek el.

Ezt ugy hivjak, hogy cluster. Ha a rendszered valoban idokritikus. Meg egy jo failover clusternel is elofordul, hogy a failover procedura 5 percid tart (amig a szolgaltatasok "atvonulnak" a hibas node-rol az epre. Pl. egy nagy adatbazisnal ez siman megtortenhet.

( pe2hu | 2004. 07. 13., k – 11:34 )

Ha tenyleg a nagy rendelkezesre allas a fontos, akkor csak a cluster szoftver segit.

A leallasi idot, a megfelelo szoftverek alkalmazasaval lehet minimalizalni.

Olyan szoftvereket kell hasznalni, amik eleve ugy vannak tervezve, hogy tobb vason fussanak parhuzamosan, es egy szerver kiesese ne okozza a rendszer leallasat.

Peldak az uzleti szoftverek kozul.

1. Oracle a 9.2-es verzio ota kinal Oracle Real Application Cluster nevezetu csodat. Ebben az esetben kozos fajlrendszeren es tobb szerveren fut az adatbazis. Ha egyik szerver megdoglik, akkor az adatbazis fut tovabb. Csak az adott szerveren eppen futo tranzakciok szakadnak meg, meg a teljesitmeny csokken, de nincs leallas!

2. SAP. A 6.30-as kernel verzioval atalakitottak kicsit a koncepciot, hogy csokkentsek azon komponensek szamat, amik SPOF (Single Point Of Failure - nem tudom van-e ra magyar szo) jelentenek a rendszerben. Ha kihal a kozponti instancia alatt a vas, akkor masik applikacios szerver at tudja venni a szerepet. (Nincs leallas, csak az adott vason eppen futo tranzakciok halnak le)

Szoval szerintem a kovetkezo a lenyeg egy hibaturo konfiguracional:

1. Vegyel hibaturo (ez draga) NAS vagy SAN tarolo rendszert (attol fuggoen, hogy milyen IO teljesitmenyre van szukseged) Ilyeneket gyart IBM, EMC, azonban vannak mas alternativak is. (Legutobb mi a Network Appliance - NetApp Filer nevezetu szerveret probaltuk ki. - nagyon meggyozo)

2. Tobb szervert hasznalj, es a hibaturo tarolorendszert kosd redundansan a szervereidhez.

3. Olyan szoftvert hasznalj ami kepes magatol tobb szerveren futni, es egy szerver leallasa kovetkezteben nem all le az egesz rendszer.

Ilyenkor szerintem tok mindegy milyen vasat hasznalsz szervernek. Egyedul a NAS/SAN szerver, es ha fibre channel kapcsolat van hozzajuk, akkor a fibre channel kartyak/eszkozok, dragak.
Egy szerver tobb napig torteno javitasa csak teljesitmeny csokkenest okoz, nem leallast.

( Névtelen (nem ellenőrzött) | 2004. 07. 13., k – 13:31 )

[quote:ad3b283020="pe2hu"]1. Oracle a 9.2-es verzio ota kinal Oracle Real Application Cluster nevezetu csodat. Ebben az esetben kozos fajlrendszeren es tobb szerveren fut az adatbazis. Ha egyik szerver megdoglik, akkor az adatbazis fut tovabb. Csak az adott szerveren eppen futo tranzakciok szakadnak meg, meg a teljesitmeny csokken, de nincs leallas!

Aha. És mi van, ha a shared tároló hal meg?
Ebből a szempontból bizony jobb a mysql 4.1-ben levő cluster, ami gépenként saját adatbázis-példányt tart fent, és csak a lekérdezéseket osztja széjjel, a módosításokat az összes gép végrehajtja. Na, EZ hibatűrő. :)

( pe2hu | 2004. 07. 13., k – 16:03 )

Azert egy terrabajtos adatbazisnal megneznem a gepenkenti mysql adatbazis peldanyt :)

( Névtelen (nem ellenőrzött) | 2004. 07. 12., h – 19:22 )

Sziasztok!

Napokban meghibasodott szerver helyreallitasanal vetodott fel bennem a kerdes:

Milyen hadware elemekebol celszeru felepiteni egy allandoan mukodo szervert ha a feltetelezzuk hogy a hardwerek minden mas egyeb kovetelmenynek megfelelnek(teljesitmeny, tamogatottsag...) es legfontosabb szempont a minel kevesebb munkan kivol toltott ido? (legnagyobb rendelkezesreallas, es hardware hiba eseten minel gyorsabb szerviz es indulas)

1. Tutti, meregdraga, markas, esetleg nehezenbeszerezheto, emiatt ritka eszkozok
2. olcso viszonylag meg megbizhato, akarhol megveheto tucattermekek, amiket szinte _minden_ oprendszer alapbol ismer.

A konkret problema eseteben (1 Raid vezerlo szallt el) az elso pont szerint gondolkodtak a vasarlok.
A meghibasodott vezerlot nem lehetett kapni mar, nem garancialis komplemensekhez nincs driver/azok sem beszerezhetok stb... ezen okok miatt a meregdraga (es bombabiztosra tervezett) gep pihenni kenyszerult, anyagi karokat okozva ezaltal.

Szoval a konkret pelda alapjan a masodik verzio tunik eletkepesebbnek, egy cluster kiegeszitessel.

Kivancsi lennek non-stop szervereket uzemelteto rendszergazdiknak mi errol a velemenyuk?

Meng

( STP | 2004. 07. 12., h – 19:54 )

1. Függ attól, hogy milyen applikációk futnak a vason. (Merthogy hozzájuk igazírja az ember a vasat, és nem fordítva.)
2. ECC RAM, bika hűtés, HW monitor(ok)/management, duál táp, UPS (külön szépség a dupla UPS független betápokról a duál tápokhoz :-)), RAID 5 vagy 10 , klimatizált szerver szoba... alapban
3. Ha (nagyon) kritikus alkalmazások futnak és nincs cluster, akkor cold iron, azaz még egyszer (majdnem) ugyan az a vas pihenget a "polcon".
4. Mit értesz tucat termék alatt? Egy Intel alaplap (amit az ASUS gyárt[ott eddig]) minek minősül nálad?
5. Full (tesztelt!!!!!!) mentés, amivel rövid idő alatt vissza lehet lökni az adatokat egy másik - jó esetben a hideg - vasra.

Cluster és cold iron hiányában én úgy szoktam megoldani, hogy az elsődleges vas(ak) valami combos jószág(ok) pl ProLiant v. PowerEdge, a tartalék szerverek (más alaplap, más kontroller, akár SATA HDD, ...) pedig Intel v. Asus alapra épülnek. Max!! 2 napig kell bírniuk.
(Ha az ember unatkozik :-) csinálhat visszatöltési tesztet a "várakozó" vasakra. Lehetnek meglepetések, amivel jobb ekkor szembesülni, mint élesben.)

Ja, és olyan vas kell elsődleges gépnek aminek 3 év helyszini garija van. 3 év után azonnal cserélni kell!!! (Igy lesz hozzá RAID vezérlő is)

Első nekifutásra ennyi.

( pete | 2004. 07. 12., h – 23:10 )

Jól hangzik. Annyit tudnék hozzátenni, hogy ha időkritikus rendszered van(vagyis nem csak statikus oldalak, hanem pl. adatbázisban tárolt állandóan frissülő/változó adatok) , akkor a cold iron helyett egy melegtartalék jobb lehet. Ugyanis az 1. vas elszállásakor az utsó mentés és az elszállás pillanatában levő állapot között értékes, vissza nem nyerhető adatok vesznek el.