NetApp DR megoldások 3. rész – szinkron SnapMirror (SM-S)

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.

Szinkron SnapMirror (SM-S)

Az SM-S volume szintű, szinkron adatreplikációt biztosít, amelyre a vállalatoknak biztonsági mentés, katasztrófa utáni helyreállítás, adatmobilitás, vagy folyamatos rendelkezésre állás miatt lehet szükségük.

A szinkron mirror kapcsolat lehetővé teszi, hogy időszakos Snapshot másolatokat készítsünk az adatokról egy volume-on; átmásoljuk ezeket a Snapshot másolatokat egy cél volume-ra (amely általában egy másik klaszteren található); vagy akár megtartsuk ezeket a Snapshot másolatokat. A cél volume-okon lévő másolatok gyorsan elérhetők és lehetővé teszik az adatok helyreállítását a legutóbb készült Snapshotból, amennyiben a forrás volume adatai sérültek, vagy elvesztek. A mirror kapcsolatok működéséhez a cél klaszteren megegyező, vagy magasabb verziójú ONTAP szoftvernek kell futnia, mint a forrás klaszteren.

Az SM-S technológia szorosan integrálódik a Snapshot technológiával. Az SM-S megszakítja az alkalmazások írási folyamatait, mielőtt azok elérnék az elsődleges WAFL-t. Ezután felosztja az írást, hogy a WAFL külön-külön dolgozza fel azt NVRAM-naplózással és konzisztencia-ellenőrzési ciklusokkal a forrás- és a cél tárolórendszereken. A szinkron replikáció egyedi I/O-n alapul, és nem Snapshot másolás alapú.

Az SM-S volume szinten biztosítja a hatékony, szinkron replikációs tárolási megoldásokat, amelyre a vállalatoknak biztonsági mentés, katasztrófa utáni helyreállítás, vagy az adatok mobilitása során lehet szükségük. A megoldás költséghatékony és könnyen használható adatreplikálást tesz lehetővé nagy sebességű LAN vagy MAN (metro-area network) hálózatokon. Az SM-S csökkenti az üzemeltetési terheket és egyszerűsíti az adatvédelmet zero-data-loss adatreplikációval. A megoldás nulla RPO-val rendelkezik, valamint a klaszterben lévő kötetek védelmét is biztosítja. A replikáció különböző modellek ONTAP-alapú tárolórendszerei között is megvalósulhat. A különböző SnapMirror feladatok beállítása, mint pl.: létrehozás, törlés és meglévő SM-S kapcsolatok kezelése, az ONTAP System Manager használatával történik. 

Sync és StirctSync módok

Sync módban az elsődleges tárolón létrejövő I/O folyamatok először a másodlagos tárolóra kerülnek és azután íródnak csak az elsődleges tárolóba majd pedig egy visszaigazolást küldenek az I/O-t kibocsátó alkalmazásnak.

Ha a másodlagos tárolóra történő írás bármilyen okból nem fejeződik be, az alkalmazás folytathatja az írást az elsődleges tárolóra. Sync módban az RPO nulla, az RTO pedig nagyon alacsony, amíg a másodlagos replikáció hibája nem következik be. Ha a másodlagos replikáció meghibásodik, az RPO és az RTO nem ismert, de megegyeznek a másodlagos replikáció meghibásodását okozó probléma javításának és az újraszinkronizálás befejezésének idejével. A hibaállapot kijavítása után az SM-S technológia automatikusan újraszinkronizál a másodlagos tárolóval, és szinkronizálási módban folytatja a replikációt az elsődleges tárolóról a másodlagos tárolóra.

StrictSync üzemmódban az SM-S replikáció nem válaszol az alkalmazás I/O-jára, amíg az elsődleges és a másodlagos tároló nem frissül. Ez pedig további késleltetést fog okozni az alkalmazás I/O-nál. StrictSync üzemmódban az RPO mindig nulla, az RTO pedig nagyon alacsony. Sync és StrictSync mód esetében is az elsődleges és a másodlagos tároló közötti round-trip time (RTT) a legkritikusabb szempont.

SM-S létrehozására (többek között) az alábbi esetekben van lehetőségünk:

  • ha az alkalmazás munkaterhelése megfelelő, és a másodlagos adatközpont rövid távolságon belül elérhető, lehetőség van az alkalmazás összes adatának szinkron replikálására a másodlagos adatközpontba, nulla adatvesztéssel és nagyon alacsony helyreállítási idővel
  • lehetőség van szinkron és aszinkron replikáció létrehozására két adatközpont között is: beállíthatunk például egy szinkron kapcsolatot a volume-ok számára egy helyi másodlagos adatközpontba, amely az elsődleges adatközponttól eltérő hibazónában van. Ezzel egyidejűleg pedig létrehozhatunk egy aszinkron kapcsolatot a rendszeres adatok számára az elsődleges adatközpontból egy távolabbi, harmadlagos adatközpontba.