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.

Nincsenek megjegyzések:

Megjegyzés küldése