NetApp DR megoldások 2. rész – SVM DR
A következő cikksorozat gyakorlati jelleggel igyekszik megmagyarázni a disaster recovery (DR) megoldásokat és az azokkal járó nehézségeket. Természetesen a való életben minden DR egyedi kihívásokat jelent, ezért mindig fontos, hogy a saját igényeinknek megfelelően kezeljük ezeket.
2. Storage Virtual Machine Disaster Recovery (SVM DR)
Az SVM DR egy olyan megoldás, amely replikálja a konfigurációkat és az adatokat azokon a volume-okon, amelyek adott VM-hez tartoznak. A hozzáadott új volume-ok pedig automatikusan védelmet kapnak.
A NetApp SVM DR a DR képességet az SVM-en belül teszi lehetővé. Itt lehetőség van az SVM volume adatok helyreállítására és a teljes SVM konfiguráció helyreállítására egyaránt. A megoldás magába foglalja az SVM identity és namsepace védelmét is!
Miután az SVM DR kapcsolat létrejött, manuálisan csak a művelet meghibásodása esetén szükséges beavatkozni. Minden egyéb eseteben előre be kell állítanunk a folyamatokat és a rendszer önállóan működik. A bankok pl.: általában olyan rendszerrel rendelkeznek, amelyben az elsődleges telephely meghibásodása esetén az I/O kéréseket a távoli vagy a közeli telephelyre irányítják át.
Lehetőségünk van SnapMirror parancsokat alkalmazni az SVM DR kapcsolatok menedzselésére is. Ezt megtehetjük klasszikusan a CLI-ben, vagy pedig az UI-bázisú ONTAP System Manager-en keresztül is. Kétféle konfigurációs lehetőséget biztosít a rendszer az optimális DR megoldás eléréséhez:
- ONATP 9.7-es (vagy újabb) verziónál REST API-kat használhatunk
- ONATP 9.9.1-es (vagy újabb) verziónál az SVM DR támogatja a FlexGroup volume-okat
A DR folyamatok automatizálása abban az esetben a legegyszerűbb, ha a forrás- és a célklaszterek ugyanabban az alhálózatban vannak (az SVM képes a LIF IP-címek újbóli megadására). Mielőtt az SVM DR kapcsolat beállításra kerül, a két klasztert és a storage VM-et ellenőrizni kell!
Első lépésként létre kell hozni egy DP storage VM-et, amely az SVM DR kapcsolat célállomása. Az SVM DR kapcsolat beállítása elindítja az inicailizálás folyamatát, vagy a kiindulópont létrehozását az összes volume és a konfiguráció számára (ezen a ponton minden volume-ot ugyanaz az RPO védi). Az alábbi példa mutatja az új volume létrehozását a forrás storage VM-en belül:
Ha a forrás storage VM elérhetetlenné válik, a cél storage VM aktiválódik. Amikor a LIF-ek online állapotba kerülnek, automatikusan elkezdődnek a host I/O kérési folyamatok. NFS esetében nincs szükség remount-olásra, mert a célállomáson lévő kötet megtartja a forrás MSID-t.
Az SVM DR védelmet nyújt minden olyan esemény ellen, amely miatt egy alkalmazás bármilyen okból működésképtelenné vagy elérhetetlenné válik. A kiválasztott kliensek és hosztok esetében létrehozhatunk és konfigurálhatunk egy cél storage VM-et a célklaszterben. Ezután replikálhatjuk az adatokat és a konfigurációt a forrás storage VM-ről a cél storage VM-re.
Ha már van egy meglévő SnapMirror kapcsolatunk a volume-ok között a storage VM-en belül, könnyedén alkalmazhatjuk ezeket az SVM DR kapcsolatoknál is. Ennek feltétele, hogy megbizonyosodjunk róla, hogy az összes tükrözött volume célállomása azonos storage VM-en belül van. Ezt követően a SnapMirror Create segítségével meg kell adnunk a kapcsolat forrás storage VM-jét, és újra kell szinkronizálnunk az új kapcsolatot. Ezen a ponton pedig már a kapcsolat SVM DR kapcsolattá válik. A folyamat nagy előnye, hogy a Snapshot másolatokat megtartja és nincs szükség fizikai adatmásolásra.
Amennyiben a forrás storage VM nem képes adatszolgáltatásra adatsérülés, véletlen adattörlés, vagy offline állapot miatt, akkor szükséges aktiválnunk a cél storage VM-et. Miután ez megtörtént, nekünk kell biztosítani az adatelérést addig, amíg a forrás storage VM-en az adatok helyre nem állnak. Mint a SnapMirror volume-ok esetében, ez az folyamat megállítja a SnapMirror adatmozgást és megszakítja a SnapMirror kapcsolatot is mindaddig, amíg a forrás storage VM helyre nem áll.