Már hosszú ideje kutatok egy olyan nyílt forrású NAS megoldás után, melyet a szabadon elérhető VMware ESXi hypervisor-hoz lehetne illeszteni. Az ESXi és a tárolórendszer segítségével magas rendelkezésreállású virtualizációs infrastruktúrát lehetne építeni, szabad szoftveres komponensekből. Az így kapott rendszer tesztelési célokat szolgálna, ám ha bebizonyosodik, hogy megbízthatóan működik, éles telepítésekben is használnám.
Mivel nem sikerült a követelményeknek megfelelő NAS szoftvert találnom elhatároztam, hogy tervezek egy saját rendszert. Melyek ezek a követelmények? Az alábbiakban részletezem.
A tárolórendszerrel szemben támasztott elvárások
VMware ESXi kompatibilitás
A VMware ESXi alapesetben két külső adattárolási protokollt támogat:
- iSCSI: az Internet Small Computer System Interface protokoll IP hálózaton keresztül történő, blokk szintű adattárolásra szolgál,
- NFS: a Network File System az egyik legősibb fájlmegosztási protokoll.
A korszerű, nyílt forráskódú NAS szoftverek (Openfiler, FreeNAS, NexentaStor, stb.) mindegyike ismeri a két protokollt, így bármelyiket fel lehetne használni a tárolórendszer alapjául.
Redundancia, hibatűrés
A NAS tervezése során a legfontosabb szempont a redundancia, ami a készülő rendszer valamennyi összetevőjénél megjelenik: redundancia a háttértáraknál (RAID), redundancia a hálózati kapcsolatoknál (EtherChannel) és redundancia a NAS eszközök terén is (Failover Cluster). A redundancia teszi lehetővé, hogy a rendszer hibatűrő legyen, azaz fel tudjon állni a bekövetkező hibákból. Komoly hiba lehet például a rendszer egy hardver vagy szoftver komponensének kiesése, melyet a rendszernek automatikusan korrigálnia kell.
Az fentebbi szoftverek közül az Openfiler az, amelyik HA modult (Heartbeat) tartalmaz. A modult konzolról kell konfigurálni, nem az elsődlegesen használt webes felületről. További probléma az is, hogy a stabil Openfiler (2.3-as verzió a bejegyzés írásakor) a Heartbeat egy régebbi, már elavultnak tekinthető verzióját tartalmazza. A régebbi verzió nem képes például a klaszter erőforrásainak monitorozására, csak a klaszterkomponensek kiesését veszi észre. Ezen felül a felépített rendszer menedzsmentje nehézkes és nem is működik stabilan...
Blokk szintű replikáció
A kialakítandó rendszert több (egész pontosan kettő) NAS eszközből álló klaszterként képzelem el, melyek között blokk szintű adatreplikáció történik. Ez azért fontos szempont, mert így a rendszer egyik node-jának kiesése esetén a másikon gyorsabban lehet helyreállítani az adattárolási szolgáltatást, mintha mentésekből probálnánk megtenni azt.
Az említett NAS szoftverek közül egyedül az Openfiler tartalmaz alapkiépítésben blokk szintű replikációs modult (DRBD). A modul konfigurálását konzolról kell végezni, nem a NAS szoftverek esetén elsődleges menedzsment interfésznek számító webes felületről. Ez a vegyes menedzselési módszer kissé nehézkessé teszi a felépített rendszer használatát.
Egyszerű menedzsment
A tárolórendszerrel szemben nem várom el, hogy bonyolult webes felülettel rendelkezzen, elég ha soros konzolról és SSH kapcsolaton keresztül menedzselhető. A kevesebb néha több (KISS elv).
Modularitás
Ha a kész rendszer moduláris, a felmerülő igényeket (pl.: hiba esetén üzenet küldése a hálózatfelyügyeleti rendszer számára) könnyebben implementálhatjuk rá. A modularitás segít abban is, hogyha valamely szoftverkomponens nem működik megbízhatóan, jó eséllyel ki tudjuk cserélni egy másikra.
Konklúzió
Mivel a fent megfogalmazott kritériumok mindegyikének egyaránt megfelelő NAS szoftvert nem találtam, magam készítem el a szám ízének megfelelő tárolórendszert. A következő bejegyzésben bemutatom, hogy milyen szoftverekből építem fel azt.
Nincsenek megjegyzések:
Megjegyzés küldése