2011. június 6.

Linux: Redundáns tárolórendszer tervezése - 4. Az alaprendszer kialakítása

Telepítés

A tárolórendszer node-jai CentOS 5.6 operációs rendszerrel lesznek telepítve.

A CentOS (és egyébb RHEL deriváns rendszerek) esetében a telepítést nagymértékben leegyszerűsíti és automatizálja a Kickstart szoftver. Az eljárás lényege, hogy a telepítendő rendszer paramétereit (hosztnév, hálózati beállítások, root jelszó stb.) egy fájlban megadjuk a Kickstart-nak, ami aztán automatikusan feltetepíti az operációs rendszert (unattended installation).

Ennek a módszernek - az automatizáláson kívül - vannak egyéb előnyei is:

  • flexibilitás: a telepítendő OS image-et és a Kickstart fájlt is tetszőleges adattárolón/megosztáson keresztül tehetjük elérhetővé a telepítéshez (USB Pendrive, HTTP/NFS/FTP megosztás, stb.),
  • öndokumentáló módszer: a Kickstart konfigurációs fájlt a rendszer telepítése után a telepítési dokumentációba illeszthetjük.

A node-okat tehát Kickstart módszerrel telepítettem, az alábbi konfiguráció szerint (nfs1 node):

# nfs1 kickstart file
# install options
reboot
text
install
url --url=http://install.server.local/centos32bit

# configuration options
lang hu_HU
keyboard hu
timezone Europe/Budapest
network --device eth0 --ip=192.168.151.11 --netmask=255.255.255.0 --gateway=192.168.151.254 --nameserver=192.168.151.254 --hostname=nfs1 --bootproto=static
skipx
bootloader --location=mbr
zerombr
key --skip

# security
auth --useshadow --enablemd5
rootpw --iscrypted $1$GvTZBQO2$hJWl9aH8DO1fOQ5soJwfR1
firewall --disabled
selinux --permissive

# partitioning
clearpart --drives=cciss/c0d0 --all --initlabel
clearpart --drives=cciss/c0d1 --all --initlabel

part raid.11 --size 10240 --ondisk cciss/c0d0
part raid.12 --size 2048 --ondisk cciss/c0d0
part raid.13 --size 1024 --ondisk cciss/c0d0 --grow

part raid.21 --size 10240 --ondisk cciss/c0d1
part raid.22 --size 2048 --ondisk cciss/c0d1
part raid.23 --size 1024 --ondisk cciss/c0d1 --grow

raid / --level 1 --fstype ext3 --device md0 raid.11 raid.21
raid swap --level 1 --fstype swap --device md1 raid.12 raid.22

# software
%packages --nobase
openssh
openssh-clients
openssh-askpass
openssh-server

# scripts
%post
#!/bin/bash

# Installing grub to the MBR at the end of install:
/sbin/grub --batch --device-map=/dev/null <
<EOGRUB
device (hd0) /dev/cciss/c0d0
root (hd0,0)
setup (hd0)
quit
EOGRUB

/sbin/grub --batch --device-map=/dev/null
<<EO2GRUB
device (hd0) /dev/cciss/c0d1
root (hd0,0)
setup (hd0)
quit
EO2GRUB

A konfigurációs fájl egy-két beállítása magyarázatra szorul:

  • konfigurálás: a node-ok nevei és a SAN hálózathoz tartozó IP címeik az előző blogbejegyzésben szerepelnek;
  • biztonság: a root jelszó: password;
  • partícionállás: a root és swap fájlrendszerek RAID1 tömbre kerülnek, a fennmaradó partíciókat (raid.13, .23) adattárolásra fogom használni és a telepítés után konfigurálom azokat;
  • szoftverek: csak egy minimális rendszert telepítek fel (core szoftvercsomag a base csomag nélkül) és csak az SSH-val egészítem ki;
  • szkriptek: a telepítés után (%post szekció) futtatok le egy szkriptet, mely mindkét merevlemezre kiírja a GRUB-ot (e beállítások nélkül, boot-oláskor, problémák adódnának).

Névfeloldás

Miután feltelepült a rendszer, első lépésként be kell állítani a névfeloldást, hogy a tárolórendszer node-jain futó szoftverek név alapján azonosíthassák egymást (/etc/hosts):

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6

192.168.151.11 nfs1
192.168.151.12 nfs2

192.168.152.101 nfs1-ha
192.168.152.102 nfs2-ha

Szoftverforrások

A különféle szoftverkomponensek (Heartbeat, Pacemaker, stb.) eléréséhez további szoftverforrásokra van szükség - konkrétan az EPEL és CLUSTERLABS repository-kra -, telepítsük ezeket:

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
# wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo

Következő lépés

Miután a tárolórendszer node-jain elindult az operációs rendszer, elkezdhetjük feltelepíteni a kalszterszoftvereket.


2011. február 27.

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.

2011. február 7.

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.