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.
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:
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