Linux: Redundáns tárolórendszer tervezése - 3. Rendszerterv

Rendszerterv

Az előzőekben felsorolt komponenseket rendszerré fogtam össze. Ehhez alapvetően két aspektusból kellett megvizsgálnom a készülő rendszert:

• a rendszeren futó szolgáltatások szemszögéből,
• a rendszer elemeinek kommunikációja szempontjából.
  

A szolgáltatások kialakítása

A tervezés során az alábbi rendszert alakítottam ki (a szolgáltatások közötti relációkat a Pacemaker dokumentációban használt sémák alapján vázoltam fel):

Amint a rajzon látható, a tárolórendszer node-jain egységes platformot alkot a klaszterszoftver kommunikációs (Heartbeat) és az erőforrás-kezelő (Pacemaker) rétege. Ezen a platformon épülnek ki (elindulási sorrendben) a különféle klaszter szolgáltatások.

A klaszter először a DRBD szolgáltatást indítja el, ami egy - a két node között Master-Slave üzemben replikált - virtuális blokkeszközt hoz létre (drbd0). (A redundancia növelése érdekében a drbd0 eszköz alá, mindkét node-on, RAID1 tömböket terveztem.)

Hogy az így létrehozott tárterület felosztható legyen, a drbd0 eszköz alapot képez az LVM szolgáltatás kialakítására (Physical Volume neve: drbd0). Az LVM szolgáltatás felépülése után (Volume Group neve: data) egy logikai kötet indul el (Logical Volume neve: export). Az adattár kialakítása a logikai kötetre épülő, Ext3 típusú fájlrendszer felcsatolásával (/export könyvtár) végződik.

Ha az adattár kialakításával kapcsolatos feladatok befejeződtek, a klaszter egy előre definiált, virtuális IP címet rendel az fájlmegosztó szolgáltatáshoz. Az NFS processz futásához néhány segédprogramra is szükség van, a klaszter ezeket is kezeli (portmapper).

Ha a teljes virtuális infrastruktúra (adattárolási és hálózati) kiépült, a klaszter elindítja a fájlmegosztó szolgáltatást (NFS).

A hálózat kialakítása

A tárolórendszer tervezése során többféle hálózati forgalommal kell számolnunk. Az egyes forgalmak karakterisztikája, valamint a hálózattal szemben támasztott igényeik nagyon eltérőek lehetnek. Vegyük sorra ezeket!

SAN hálózati forgalom

A SAN hálózaton keresztül közlekednek az adatblokkok a virtualizált rendszerek (VMware guest) és az NFS szerveren tárolt virtuális merevlemezeik (image) között. Értelemszerűen, ez a forgalom igényli a legnagyobb sávszélességet és a legkisebb késleltetést, ellenkező esetben a guest-eken jelentős lassulást fogunk tapasztalni a megnövekedett IOWait miatt.

Klaszter kommunikáció (Heartbeat)

A klaszter kommunikáció kis sávszélességet, de minél nagyobb redundanciát igényel a kommunikációs útvonalak tekintetében. A DRBD dokumentáció egyenesen így fogalmaz: az a klaszter, melynél a node-okat kettőnél kevesebb útvonal köti össze, nem klaszter (Heartbeat communication channels).

A blokk szintű replikáció (DRBD)

A tárolórendszer node-jai közötti blokk szintű replikáció a NAS forgalomhoz hasonló követelményekkel bír: nagy sávszélességet és alacsony késleltetést kíván.

Menedzsment forgalmak

A tárolók menedzsmentje SSH kapcsolaton keresztül történik, ez semmilyen különleges kritériumot nem támaszt a hálózattal szemben. Biztonsági szempontból azonban fontos, hogy el legyen szeparálva a NAS/Heartbeat/DRBD forgalmaktól (utóbbiakat célszerű L3 kijárat nélküli hálózati szegmensekbe terelni).

A felsorolt kritériumok alapján az alábbi hálózat tervét rajzoltam meg:

Jellemzők:

• A SAN adat és a DRBD replikációs forgalmakat külön hálózatokba terelem (VLAN 151 és 152 - A piros számok az adott interfészhez tartozó IP címet jelölik, míg a zöld szám a NFS szolgáltatáshoz tartozó szolgáltatás IP-t.)
• A Heartbeat/Pacemaker szoftver úgy lesz kialakítva, hogy az nfs1 és nfs2 node-ok mindkét VLAN-on keresztül tartsák a kapcsolatot (redundáns útvonal). A kapcsolattartás Multicast kommunikáció útján fog történni.
• Mivel az NFS szervereken csak két fizikai interfész van, ezért a menedzsment forgalom kialakításáról lemondtam - a konfigurálást a gépek konzoljáról fogom végzni (ez a forgalom, ideális esetben, külön interfészek felhasználásával, egy külön VLAN-on keresztül haladna).
  

Következő lépés

A tervezési fázisról ennyit szerettem volna mondani. A következő részekben bemutatom az implementáció lépéseit.

Linux: Redundáns tárolórendszer tervezése - 2. Komponensek

Hardver

A tároló kifejlesztéséhez külön tesztrendszert állítottam össze. Az alábbi szerver vasak (2 db) képezik a rendszer alapját:

• Szerver típusa: HP Proliant ML 330 G3,
• Processzor: Intel(R) Xeon(TM) CPU 2.40GHz (HT, 32bit),
• Memória: 1GB,
• Háttértár: 2x 36GB SCSI,
• Hálózat: 2x 3c905c (10/100)

Amint látható a gépek nem éles környezetre alkalmas eszközök, tesztelés céljára azonban megfelelnek. A VMware ESXi hoszt már komolyabb hardver:

• Szerver típusa: Dell PowerEdge T300,
• Processzor: Intel(R) Xeon(TM) X3323 CPU 2.50GHz (64bit, 4 core),
• Memória: 8GB,
• Háttértár: 4x 146GB SAS,
• Hálózat: 2x Broadcom NetXtreme (10/100/1000)
• ESXi verzió: 4.1

Az erős VMware hoszt biztosítja, hogy ne a virtualizáció legyen a szűk keresztmetszet, ha teljesítmény méréseket végzünk a tárolórendszeren. Minden bizonnyal a "SAN" hálózati eszköz sem von majd le további hasznos százalékokat a rendszer teljesítményéből:

• Switch: Cisco WS-C3550-24 L3 switch (24x 10/100 port, PowerPC)
• IOS verzió: 12.2(25)SEB4
• Feature set: C3550-IPBASE-M
  

Szoftver

OS

Linux. Az operációs rendszernek mindenképpen valamilyen UNIX-ból származtatott OS-t szerettem volna használni. Mivel már 12 éve foglalkozom Linux-szal, legjobban ezt az OS-t ismerem, így célszerűnek tűnt ezt választani. Természetesen vannak egyébb előnyei is a Linux-nak, de ezekről majd később.

A CentOS egy szabadon elérhető rendszer, melyet a Red Hat Enterprise Linux forráskódjából készítenek, minimális változtatásokkal (gyakorlatilag a márkára utaló információkat módosítják). Az RHEL nagyvállalati célra szánt disztribúció, így olyan kellemes tulajdonságai vannak, mint például az egyes szoftververziók 7 éven át történő támogatása. A belőle származtatott CentOS disztribúció jó választásnak tűnik egy magas rendelkezésreállású tárolórendszer kialakításához.

Hálózati adattárolási protokoll

A SAN protokoll kiválasztása már keményebb dió volt. Mint említettem az alap VMware ESXi alapvetően két variánst támogat: iSCSI-t és NFS-t (az utóbbiból a NFSv3 over TCP verziót). Mindkét protokollnak vannak előnyei és hátrányai:

• Teljesítmény: eltérő véleményeket lehet olvasni arról, hogy ki-melyik protokollt tartja jobbnak VMware-es környezetben. Az biztos, hogy a TCP/IP protokoll jelentős többletterhelést ró a SCSI adatforgalomra, de az NFS esetében is növekszik a késleltetés és csökken a sávszélesség a TCP megbízható adattovábbítási módszerei miatt. Az iSCSI-hoz ráadásul léteznek kliens oldali, hardveres gyórsító kártyák melyek tovább növelik a teljesítményét.
• Használhatóság: az NFS hatalmas előnye, hogy a virtuális gépek image-ei fájlokként jelennek meg az NFS szerveren, így sokkal egyszerűbbé válik például a mentés.
• Megbízhatóság: az NFS kliens és szerver oldalon is cache-eli a fájlrendszer írási adatait és a két cache-t folyamatosan szinkronban tartja. Ez azt jelenti, hogy a kliens kiesése esetén megmaradnak a lemezre még ki nem írt adatok. Az iSCSI esetében viszont a kliens oldalán van csak fájlrendszer cache, melynek a tartalma csak meghatározott időközönkét (asszinkron módon) íródik a blokk eszközre így a kliens kiesése esetén elveszhet a tartalma.

A felsorolt érvek és ellenérvek alapján az NFS protokollt választottam.

Blokk szintű replikáció

Mint már említettem az előző blogbejegyzésben, a Linux tartalmaz merevlemezek közötti (RAID) és gépek közötti (DRBD) blokk replikációs modult is. A készülő rendszerben mindkét modult fel szeretném használni, hogy növeljem a tároló hibatűrését.

Logikai kötetkezelés

A tárolórendszer egyik legfontosabb ismérve, hogy dinamikusan változó méretű partíciókat tudunk rajta létrehozni, amire azért van szükség, hogy a folyamatosan változó tárolási igényeknek ne szabhasson gátat a merevlemezek mérete. Erre szolgálnak a különféle Logical Volume Management (LVM) megoldások.

A módszer lényege, hogy a fizikai lemezeket (Physical Volume, PV) beletesszük egy nagy logikai tárolóba (Volume Group, VG) majd a logikai tárolóból különféle szeleteket hasítunk ki, adattárolás céljára (Logical Volume, LV). Ez a módszer nagyon dinamikusá teszi az adattárolást, mert az LV-k mérete folyamatosan változtatható és ha helyszűkében vagyunk, bármikor további fizikai lemezeket (PV) adhatunk a logikai tárolókhoz (VG).

Napjaink egyik legjobb LVM implementációja a ZFS, ami logikai kötetkezelő és fájlrendszer is egyben. Olyan finomságokkal van felvértezve, mint a blokk szintű replikáció (például RAID-Z) vagy a blokk szintű deduplikáció (ez utóbbi nagyon jól jön virtualizált környezetben). Sajnos a ZFS Linux alatt még gyerekcipőben jár, ezért a Linux LVM megoldását fogom használni.

HA modul

A fentebb felsorolt szoftverek indulásának/leállásának vezérlését, működésének felügyeletét és hiba esetén a szükséges ellenintézkezések végrehajtását, mint egy karmester hangolja össze a klaszter szoftver. Linux alatt többféle klaszter is elérhető, én a Heartbeat/Pacemaker párost favorizálom.

A LinuxHA projekt hozta létre a Heartbeat klaszer keretrendszert és üzenetküldési réteget. A Heartbeat elsődleges feladata, hogy kiépítse és menedzselje a klaszert alkotó gépek közötti kommunikációt és létrehozza a klaszter infrastruktúrát.

A LinuxHA-ból kivált Pacemaker projekt létrehozott egy Cluster Resource Manager (CRM) modult, mely a klaszter különféle erőforrásait (fájlrendszerek, IP címek, szolgáltatások stb.) kezeli. A Pacemaker egy központi adatbázisban (CIB) tárolja a klaszter állapotát és minden egyes állapotváltozásra meghatározott módon reagál. A Pacemaker teljes mértékben testreszabható és nagyon komplex klaszterek alkíthatóak ki vele.

A következő fázis

Ebben a bejegyzésben bemutattam, hogy milyen hadverekből és szoftverekből tervezem megépíteni a tárolórendszert. A következő lépésben elkészítem a rendszer tervét.