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.