W dzisiejszych czasach budując własne rozwiązania typu Disaster Recovery często sięgamy po rozwiązania bazujące w części na replikacji danych pomiędzy macierzami dyskowymi. Jednym z takich rozwiązań (dodajmy że najtańszym) jest EMC MirrorView. Jest to bardzo prosta i łatwa w konfiguracji usługa doskonale współpracująca z VMware Site Recovery Manager (SRM). Replikacja LUN może się odbywać synchronicznie lub asynchronicznie, w ramach przyswajania teorii i nazewnictwa odsyłam Was do bloga StorageFreak gdzie kolega Tomek dokładnie wszystko opisał. My skupimy się na konfiguracji Mirror View bezpośrednio na macierzach VNX, w moim przypadku są to VNX 5200 i VNX 5300.
W ramach przygotowań należy zestawić (Zony) połączenia (Fabric) SAN pomiędzy macierzami. Łączymy ze sobą porty opisane jako Mirro View, port A-0 SPA w pierwszej macierzy do portu A-0 SPA drugiej macierzy (i odpowiednio SPB). Porty którymi będzie odbywała się replikacja nie mogą być użyte w Storage Groups hostów (czyli do zwykłego serwowania danych). Jeśli są wykorzystywane do komunikacji z hostami, należy je usunąć z Storage Group zanim zestawimy połączenia Fabric (inaczej czeka nas restart kontrolerów macierzy i sporo nieprzyjemnych komunikatów).
Po połączeniu macierzy weryfikujemy czy zobaczyły się poprawnie, przechodzimy do sekcji Hosts –> Initiators.
VNX 5200: 
VNX 5300: 
Jak widać, połączenie jest zestawione poprawnie. Aby można było wykonywać operacje typu Mirror, obydwie macierze muszą o sobie wiedzieć, czyli znajdować się w tej samej Domenie lub w dwóch różnych Demenach (Lokalnej i Zdalnej).
Tę operację przeprowadzamy z macierzy nowszej lub o wyższym numerze firmware, czyli w moim przypadku z poziomu VNX 5200 dodaję VNX 5300 (w drugą stronę to nie zadziała spotkamy się z komunikatem o niewspieraniu danej macierzy).
W tym momencie mam na VNX 5200 dwie domeny, Local i Remote, na VNX 5300 jest tylko domena Local.
Z poziomu VNX 5200 można zarządzać jednocześnie oboma macierzami płynnie przełączając się pomiędzy nimi z poziomu klienta Unisphere.
W następnej kolejności, jeśli jeszcze tego nie mamy, stworzymy LUNa dla “Write intent logs”. Ten log pomoże macierzy w odwracaniu problemów które mogłyby się pojawić przy replikacji (coś jak log transakcyjny). Sam LUN nie musi być duży, minimalne wymaganie to 128GB, jednak nie możemy go stworzyć w ramach Puli, musi to być RAID Grupa. Dodatkowo takie logi muszą być dwa, po jednym dla każdego SP. W sekcji Storage—>Storage Configurations—>RAID Groups tworzymy dwie nowe grupy i zakładamy na nich LUNy.
Teraz w sekcji Data Protection klikamy w “Configure Mirror Write Intent Log” i dodajemy naszego LUNa. Write Intent Log nie jest niezbędny do replikacji, jeśli nie mamy wolnych dysków z których moglibyśmy stowrzyć RAID Grupę to możemy ten krok pominąć (jego istnienie zwiększa jednak bezpieczeństwo).
Następnie tworzymy pulę rezerwowych LUN (Reserved LUN Pool), RLP są używane przy snapshotach i do prezentowania LUN do ESXi w trakcie testów SRM. Są także niezbędne przy asynchronicznej replikacji. Same LUNy nie muszą być duże (zależne jest to od ilości zmian w wolumenach produkcyjnych które się odłożą pomiędzy kolejnymi interacjami asynchronicznej kopii). Ja stworzyłem trzy LUNy po 512GB (LUNy te nie mogą być Thin). Dodajemy je w sekcji Data Protection—>Reserved LUN Pool.
Używając VMware SRM możemy dokonywać przełączeń w obie strony, dlatego podobny zestaw rezerwowych LUN tworzymy też na drugiej macierzy.
Teraz przechodzimy do skonfigurowania replik, tworzymy nowe LUNy (lub wybieramy stare) i z menu wybieramy “Create Remote Mirror”.
W zależności od odległości wybieramy czy ma to być kopia synchroniczna (opóźnienie nie większe niż 10ms) lub asynchroniczna (opóźnienie nie większe niż 200ms).
I tak po kolei dla każdego LUNa. Teraz przechodzimy na zdalną macierz i przystępujemy do konfiguracji (tworzymy odpowiedniki LUN z macierzy podstawowej). Po tej operacji wracamy na macierz podstawową i sprawdzamy w LUN Mirrors czy wszystko jest ok (Aktywne).
Wybieramy LUN i klikamy “Add Secondary”, wcześniej przygotowany LUN na zdalnej macierzy musi być tej samej wielkości co źródłowy i nie może być przypisany do żadnej “Storage Groups”.
W tym momencie mamy zdefiniowane odbicie lustrzane naszego wolumenu (i włączoną synchronizację).
Jeżeli mamy większą ilość wolumenów które będą podlegały synchronizacji i dodatkowo te wolumeny będą działały jako jeden klaster DRS po stronie vSphere, to warto połączyć te LUNy w jedną grupę konsystencji (Mirror Consistency Group).
Dzięki temu wszystkie operacje synchronizacji będą przeprowadzane równocześnie na wszystkich LUN.
Dodatkowo Consistency Groups przekłada się wprost na VMware SRM Protection Group. Na tym etapie konfiguracja Mirror View została zakończona, opisany tu przypadek dotyczy replikacji w jedną stronę. Możliwa jest też replikacja w obie strony (BI-Directional), konfiguracja jest bardzo podobna. Oczywiście w przypadku BI-Directional mówimy o replikacji dwóch różnych zestawów LUN z każdej macierzy jednego, replikowanego do drugiej macierzy (możemy mieć wtedy dwa aktywne DC replikowane do drugiej lokalizacji).