Bezpieczne, przystępne cenowo, wydajne cienkie klienty zaprojektowane dla wirtualnych pulpitów Windows

Proste we wdrożeniu i centralnie zarządzane cienkie klienty NComputing do obsługi chmur obliczeniowych zwiększają przystępność wdrożenia wirtualnego pulpitu Windows.

Idealne dla organizacji korzystających z Microsoft Windows Virtual Desktop w chmurze Azure, cienkie klienty serii RX są gotowe do pracy w chmurze, zaprojektowane i zoptymalizowane specjalnie dla Windows Virtual Desktop.

Windows Virtual Desktop zmienia sposób, w jaki uzyskujemy dostęp do wirtualnych pulpitów, umożliwiając korzystanie z wielu sesji systemu Windows 10 bezpośrednio z chmury dzięki platformie Azure. Windows Virtual Desktop umożliwia również informatykom wdrażanie systemu Windows 7, a migracja z istniejących usług Remote Desktop Services i lokalnych wdrożeń Windows Server na platformę Azure oferuje ujednolicone zarządzanie infrastrukturą.

Rozwiązania typu cienki klient firmy NComputing zdecydowanie obniżają całkowity koszt posiadania (TCO) – są przystępne cenowo i zbudowane tak, aby spełnić wymagania zarówno użytkowników jak i administratorów.

Niezależnie od tego, czy potrzebujesz obsługi dwóch monitorów (RX420-RDP), czy tylko jednego (RX-RDP+), dostęp do wirtualnego pulpitu systemu Windows jest prosty i łatwy. Niewielkie rozmiary urządzeń z serii RX, montowanych z tyłu monitora, na biurku lub stole, umożliwiają elastyczne wdrażanie w ciasnych pomieszczeniach, w zakładach produkcyjnych lub punktach sprzedaży, a także w innych zastosowaniach, takich jak praca w domu. Dwuzakresowe połączenia WiFi i gigabitowy ethernet zapewniają funkcjonalność komputera PC w małym, energooszczędnym urządzeniu.

Wdrażanie i bieżąca administracja są uproszczone dzięki scentralizowanemu zarządzaniu urządzeniami (PMC). Urządzenia z serii RX są bardzo bezpieczne, zbudowane na zamkniętej platformie Linux, chroniącej przed złośliwym oprogramowaniem i wirusami.

Proste połączenia w niewielkiej obudowie umożliwiają wdrożenie systemu Windows Virtual Desktop w dowolnym miejscu.

Jak to działa?

Dodaj klawiaturę, mysz, monitor (lub dwa) oraz połączenie z Internetem. Wybieraj spośród pojedynczych aplikacji lub pełnego systemu operacyjnego i korzystaj z wydajnego wirtualnego pulpitu Windows – wszystko to na urządzeniu, które mieści się w dłoni.

Zoptymalizowany dla Windows Virtual Desktop

Gotowe do pracy w chmurze cienkie klienty serii RX, zaprojektowane do pracy z wirtualnymi pulpitami Microsoft oferują najwyższą wydajność i bezpieczeństwo, zapewniając wrażenia podobne do komputera PC w przystępnym cenowo, energooszczędnym urządzeniu.

Scentralizowane Zarządzanie

Cienkie klienty z serii RX są łatwo konfigurowane przez użytkownika końcowego lub zdalny personel IT za pomocą oprogramowania do zarządzania urządzeniami PMC firmy NComputing. Oprogramowanie PMC umożliwia automatyczne wykrywanie urządzeń, ich rejestrację, konfigurację oraz zdalne aktualizacje oprogramowania sprzętowego.

Łatwe wdrożenie

Cienkie klienty z serii RX są łatwo konfigurowane przez użytkownika końcowego lub zdalny personel IT za pomocą oprogramowania do zarządzania urządzeniami PMC firmy NComputing. Oprogramowanie PMC umożliwia automatyczne wykrywanie urządzeń, ich rejestrację, konfigurację oraz zdalne aktualizacje oprogramowania sprzętowego.

Korzyści z korzystania z rozwiązań NComputing dla WVD

Zweryfikowane rozwiązanie Windows Virtual Desktop
NComputing jest oficjalnym partnerem Windows Virtual Desktop dla zintegrowanych rozwiązań cienkiego klienta z systemem Linux, zweryfikowanym przez Microsoft.

Proste, wydajne, przystępne cenowo
NComputing ma 20-letnie doświadczenie w wirtualizacji desktopów. W miarę jak nasze potrzeby obliczeniowe przenoszą się do chmury, zmienia się również sposób interakcji z systemami i aplikacjami. Jeśli potężne serwery obsługują wszystko za Ciebie, nie ma już potrzeby korzystania z typowego sprzętu PC i związanych z nim problemów. Ale nadal potrzebujesz jakiegoś sposobu na podłączenie klawiatury, myszy i monitora do chmury, aby pracować.

Cienkie klienty serii RX spełniają tę potrzebę.

Podłącz swoje urządzenia peryferyjne, sieć i odpal sesję – to naprawdę wszystko. Oprogramowanie zarządzające PMC pozwala na centralne zarządzanie wszystkimi urządzeniami przez personel IT, wymuszając aktualizacje firmware’u i kontrolując dostęp w razie potrzeby.

Niższy całkowity koszt posiadania
Cienkie klienty z serii RX obniżają TCO wdrożenia Windows Virtual Desktop. Dla firm, które chcą odświeżyć lub nabyć nowe urządzenia końcowe, cienkie klienty z serii RX są tańsze niż tradycyjne komputery PC i laptopy, a przy tym zapewniają wydajność zbliżoną do komputerów PC. Scentralizowane zarządzanie urządzeniem, minimalna liczba ruchomych części i brak obaw o dane lokalne pozwalają ograniczyć bieżące wydatki na konserwację i bezpieczeństwo urządzeń.

Cienkie klienty z serii RX eliminują wiele problemów związanych z typowymi wdrożeniami sprzętowymi, takimi jak bezpieczeństwo danych, awarie komponentów czy zużycie energii.

 

O współpracy Microsoft i NComputing

“Obsługa Windows Virtual Desktop w cienkich klientach NComputing serii RX jest możliwa dzięki naszej bliskiej współpracy z firmą Microsoft, wspartej 20-letnim doświadczeniem NComputing na rynku cienkich klientów. Wdrażając bezpieczne, niedrogie i wydajne cienkie klienty dla Windows Virtual Desktop, klienci obniżają całkowity koszt posiadania i umożliwiają szersze zastosowanie rozwiązania. Jest to zgodne z naszą misją dostarczania wydajnych, przystępnych cenowo rozwiązań typu cienki klient dla wszystkich małych i dużych klientów” – mówi Young Song, dyrektor generalny firmy NComputing.

Informacje o programie Windows Virtual Desktop

Windows Virtual Desktop oferuje usługę wirtualnego pulpitu na platformie Azure. Windows Virtual Desktop umożliwia organizacjom dostarczanie wirtualnego pulpitu i aplikacji zdalnych na dowolne urządzenie. Microsoft 365 i Azure zapewniają użytkownikom wielosesyjne maszyny Windows 10 – z wyjątkową skalowalnością i zmniejszonymi kosztami IT

NComputing

Założona w 2003 roku firma NComputing jest wiodącym na świecie dostawcą rozwiązań cienkich klientów linuksowych, obsługującym ponad 70 000 klientów w 140 krajach. Nasze rozwiązania obejmują bezpieczne, niedrogie i wydajne cienkie klienty zoptymalizowane pod kątem Microsoft RDS i Windows Virtual Desktop. Dzięki unikalnej formule łączącej prostotę i wydajność, zintegrowane rozwiązania firmy NComputing obsługują globalnych klientów w kluczowych sektorach, takich jak edukacja, produkcja, opieka zdrowotna i administracja rządowa.

Interesują Cię rozwiązania NComputing? Zapraszamy do kontaktu na adres terminale@fen.pl

Cienki klient na x86 czy ARM?

Czy zastanawialiście się kiedyś, dlaczego NComputing buduje prawie wszystkie swoje urządzenia Thin Client na architekturze ARM, zamiast korzystać z rozwiązań x86 jak wszyscy inni? 

Tradycyjne urządzenia typu cienki klient są zazwyczaj sprzedawane z obietnicą małej obudowy, niższego zużycia energii i – co najważniejsze – prostszego, bezpiecznego systemu operacyjnego umożliwiającego dostęp do środowisk VDI (Virtual Desktop Infrastructure). Podstawową ideą jest scentralizowanie całej mocy obliczeniowej i przechowywania danych w centrum danych, tworząc w ten sposób́ środowisko pracy bezpieczniejsze i bardziej elastyczne niż w tradycyjnym modelu Serwer-PC.  

Kiedy na rynku pojawiły się cienkie klientyktóre miały stanowić urządzenia dostępowe (endpoints) dla tych scentralizowanych rozwiązań IT, miały być prostsze, bezpieczniejsze i bardziej efektywne kosztowo niż komputery PC.  Producenci więc zaczęli opracowywać dostosowane systemy operacyjne i klienty dla różnych protokołów oparte głównie na jądrze Linux i uzupełnili je o pakiety zdalnego zarządzania, aby łatwo zarządzać tymi cienkimi klientami. Jednak przy tworzeniu tego oprogramowania programiści stanęli przed problemem. Dla jakiej architektury tworzyć oprogramowanie? W tamtym czasie, wiele lat temu, jak i dzisiaj, mieli oni do wyboru: stworzyć własny sprzęt oparty na jednej z kilku dostępnych architektur procesorów lub wybrać powszechnie stosowaną standardową architekturę. Niestety, wtedy na rynku istniała tylko JEDNA standardowa platforma… PC, oparta na procesorach x86! 

I tak właśnie się stało, a my do dziś płacimy cenę za tę decyzję. Architektura PC jest zbyteczna dla prawie wszystkich potrzeb cienkiego klienta. Nie jest zoptymalizowana do tego zadania i kosztuje często więcej niż komputer PC. W efekcie nie tylko płacimy za rozbudowaną strukturę serwerową, licencję na oprogramowanie do wirtualizacji, ale także musimy zapłacić co najmniej cenę komputera PC, aby uzyskać dostęp do architektury VDI. W niektórych przypadkach firmy używają nawet systemu operacyjnego Microsoft na tych “ukrytych komputerach”, co zwiększa złożoność, ponieważ personel IT musi teraz utrzymywać złożone środowisko serwerowe ORAZ podatny na błędy i złośliwe oprogramowanie system operacyjny na każdej końcówce. 

Przez kilka lat innowacyjni producenci szukali innego rozwiązania i próbowali pozycjonować własne platformy jako cienkie klienty. Wszystkie te próby zakończyły się jednak raczej znikomym sukcesem, ponieważ oprogramowanie oferowane przez firmy trzecie, takie jak klienty czy sterowniki urządzeń peryferyjnych nie nadążały za zmianami 

Na szczęście, w ciągu ostatnich kilku lat pojawiła się nowa standardowa platforma oparta na wydajnej i niedrogiej architekturze. Bazujące na ARM rozwiązanie Raspberry Pi (obecnie czwartej generacji), zostało sprzedane w milionach sztuk i jest wspierane przez tysiące twórców oprogramowania dla szerokiego zakresu zastosowań. Oferuje wszystkie optymalizacje wymagane do zbudowania idealnego cienkiego klienta, takie jak: 

  • sprzętowa akceleracja wideo, 
  • wsparcie najnowszych kodeków, takich jak H.265,  
  • obsługa dwóch monitorów w rozdzielczości 4K, 
  • porty USB 3.1 
  • moc obliczeniową do uruchomienia dowolnego klienta dla dowolnego protokołu. 

Firma NComputing bardzo wcześnie dostrzegła możliwość opracowania wysokowydajnych i ekonomicznych cienkich klientów na platformie Raspberry Pi i wykorzystała ją we wszystkich swoich dzisiejszych rozwiązaniachSą one dostępne dla protokołów , Microsoft RDS, Microsoft WVD, CitrixVMWare i są w pełni obsługiwane przez dostawców technologii wirtualizacji. Ofertę uzupełniają kompleksowe pakiety do zarządzaniaktóre obsługują Pi i wiele różnych platform, w tym x86.  

Obecnie użytkownicy mają wybór między ekonomicznymi cienkimi klientami opartymi na procesorach Pi a „tradycyjnymi” rozwiązaniami opartymi na komputerach PC. 

Interesują Cię rozwiązania NComputing? Zapraszamy do kontaktu na adres terminale@fen.pl

Praca w domu, teraz i w dłuższej perspektywie.

Być może oba te cele można osiągnąć w tym samym czasie – zrealizować je szybko i cieszyć się nimi długo.

Ponieważ z powodu obecnej pandemii coraz więcej osób pracuje w domu, specjaliści IT mają do czynienia z kilkoma wyzwaniami. Czy wdrażają oni szybkie lecz niedoskonałe rozwiązania, aby zaspokoić natychmiastową potrzebę, czy też raczej powinni brać pod uwagę perspektywę długoterminową, rozumiejąc, że korzystanie z biur domowych stało się de facto standardem, a profesjonalne rozwiązanie jest wymagane? 

Każda firma ma nieco inne potrzeby w tym zakresie. Niniejszy dokument skupia się na małych i średnich przedsiębiorstwach (SMB), gdzie prawdopodobnie zastosowanie mają trzy opisane niżej scenariusze.

  1. Komputery i serwery: Firma działa w tradycyjnym środowisku, w którym większość aplikacji działa lokalnie na komputerach PC lub laptopach, a niektóre aplikacje SaaS są dostępne za pośrednictwem przeglądarki internetowej. Dane są dostępne lokalnie i na serwerach.
  2. Usługi terminalowe: Firma przeniosła większość lub wszystkie aplikacje na serwery i uzyskała do nich dostęp za pomocą komputerów PC, zazwyczaj poprzez Usługi Pulpitu Zdalnego (RDS) firmy Microsoft. Połączenie aplikacji uruchamianych lokalnie i usług terminalowych jest możliwe, o ile użytkownicy końcowi pracują na komputerach z systemem Windows.
  3. Infrastruktura Virtual Desktop Infrastructure (VDI): Firma całkowicie przestawiła się na rozwiązanie do wirtualizacji komputerowych stanowisk pracy, takie jak platformy oferowane przez Citrix, VMware lub Microsoft. Wszystkie aplikacje są uruchomione w centrum przetwarzania danych lub są dostępne jako SaaS.

Wirtualizacja komputerowych stanowisk pracy (nr 3. powyżej) pozostaje najlepszym scenariuszem dla domowego biura, ponieważ oferuje bezpieczeństwo, centralne zarządzanie, spójność danych oraz strategię tworzenia kopii zapasowych. Jednakże, te rozwiązania VDI mogą być bardzo kosztowne i skomplikowane dla wielu małych i średnich przedsiębiorstw. Dla firm korzystających ze starszych scenariuszy, takich jak 1. lub 2., gdzie wykorzystywane są lokalne komputery PC, nierozwiązanym problemem pozostają zagrożenia bezpieczeństwa, możliwość uszkodzenia danych lub spowodowania ich niespójności. Niektóre małe i średnie przedsiębiorstwa przeszły na rozwiązania typu cienki klient. Tutaj urządzenie końcowe działa poprzez zdalne podłączenie do środowiska komputerowego opartego na serwerze. Większość aplikacji i wszystkie poufne dane są przechowywane na serwerze (serwerach) w celu zapewnienia bezpiecznej pracy w środowisku domowym.

Dla małych i średnich przedsiębiorstw, które nadal korzystają ze scenariusza 1. lub 2., najprostszym sposobem zwirtualizowania aplikacji jest prawdopodobnie przejście na rozwiązanie Terminal Service, takie jak Microsoft RDS. Usługi te są częścią dobrze znanych i zrozumiałych serwerów Microsoft, łatwych do opanowania przez dział IT.

W zależności od obciążenia pracą i liczby użytkowników domowego biura, istniejący sprzęt serwerowy może być wystarczający do obsługi dodatkowego obciążenia. Znaczny wzrost liczby użytkowników będzie jednak wymuszał inwestycję w serwery, chyba że firma będzie chciała szybko przejść do infrastruktury opartej na chmurze, takiej jak Azure lub AWS.

Przechodzenie na usługi w chmurze ma tę zaletę, że jest szybko adaptowalne i skalowalne do przyszłych potrzeb. Jednakże, długoterminowe koszty ochrony danych i utrzymania systemu przewyższą nakłady inwestycyjne wymagane dla wewnętrznej infrastruktury serwerowej.

Usługi terminalowe są doskonałym sposobem na wirtualizację aplikacji lub nawet komputerów stacjonarnych, gdzie użytkownicy korzystają z podobnego zestawu aplikacji. Jeżeli użytkownicy mają różne wymagania i korzystają z różnych aplikacji, wskazane byłoby zastosowanie rozwiązania lepiej naśladującego pracę z komputerem PC. Prawdziwe środowisko VDI, takie jak Citrix czy VMware, miałoby więcej sensu. Firmy te oferują bardzo wydajne rozwiązania VDI, jak również rozwiązania do wirtualizacji aplikacji dla dużej liczby użytkowników (nawet dla tysięcy), opierające się o technologie klasy korporacyjnej dla zarządzania i zdalnego dostępu. O ile nie są one już dostępne, ich wdrożenie oraz opanowanie w stopniu pozwalającym na efektywną administrację wymaga jednak dłuższego czasu.

Po podjęciu decyzji o zwirtualizowaniu środowiska, priorytetem staje się znalezienie bezpiecznego sposobu połączenia biur domowych z centrami przetwarzania danych.

Powinno pojawić się kilka pytań:

  1. Czy centralne zarządzanie urządzeniami używanymi w domu jest wymagane?
  2. Jak doświadczeni są użytkownicy domowi w zakresie konfigurowania połączeń VPN i urządzeń?
  3. Czy dozwolone jest połączenie użytku osobistego i biurowego, a tym samym połączenie danych prywatnych i firmowych?
  4. Jaki rodzaj zarządzania danymi uwierzytelniającymi już istnieje i jakie są wymagania w tej dziedzinie?
  5. Jak ważne jest korzystanie z multimediów za pośrednictwem sieci firmowej?

Dla większości firm odpowiedź pytanie numer 3. będzie jednoznacznym “nie”, co oznacza, że potrzebny jest dodatkowy sprzęt w postaci dedykowanego komputera roboczego, laptopa lub cienkiego klienta. Chociaż laptopy mogą być uważane za logiczny wybór, nie należy zapominać o ich wadach. Przede wszystkim są to pełne komputery, które wymagają osobistej uwagi informatyków. Są one podatne na ataki złośliwego oprogramowania i mają większą moc obliczeniową niż jest to konieczne w przypadku środowiska zwirtualizowanego. Ponadto, ich forma sprawia, że trudno jest z nich korzystać przez dłuższy czas, chyba że są wyposażone w większy ekran, zewnętrzną klawiaturę i mysz. Wszystko to razem powoduje, że jest to dość kosztowna propozycja.

Korzystanie z cienkich klientów ma natomiast kilka zalet, w tym minimalną interakcję dla personelu IT, znacznie mniejszą podatność na ataki złośliwego oprogramowania oraz gwarantowane rozdzielenie danych osobowych i aplikacji firmowych. Urządzenia typu cienki klient występują w wielu różnych formach, ale istnieją tylko dwie istotne architektury:

  • x86: Urządzenia typu cienki klient oparte o architekturę PC x86 mają podobną strukturę kosztów jak pełne komputery PC, niekiedy są nawet droższe.
  • ARM: Urządzenia oparte o platformy takie jak Raspberry Pi oferują znacznie niższe koszty sprzętu, zapewniając jednocześnie podobną wydajność i możliwości. Mają niewielką obudowę i są łatwiejsze do zainstalowania w domu lub w miejscu pracy zdalnej. W niektórych przypadkach, urządzenia wykorzystujące architekturę ARM mogą nie posiadać specjalnych sterowników urządzeń, które są niezbędne do poprawnej obsługi niektórych urządzeń peryferyjnych. Taka sytuacja jest jednak mało prawdopodobna w środowisku domowego biura.

Cienkie urządzenia klienckie są wdrażane po wstępnym skonfigurowaniu przez dział IT i nie wymagają wiedzy na temat konfiguracji i zarządzania na miejscu przez użytkownika końcowego po podłączeniu ich do sieci. Odpowiednio dobrane urządzenia mogą być również zarządzane i obsługiwane zdalnie.

Połączenie klientów z centrum przetwarzania danych w chmurze lub wewnątrz firmy może być bezpiecznie realizowane za pośrednictwem wbudowanych klientów VPN lub za pomocą bramek dostarczanych przez wszystkich głównych dostawców, takich jak Citrix, VMware i Microsoft.

Podsumowując, stosunkowo szybkim i łatwym sposobem wdrożenia, zdolnych do użytku także w przyszłości, domowych przestrzeni biurowych dla małych i średnich przedsiębiorstw, jest:

  • Przeniesienie wszystkich istotnych aplikacji do rozwiązań wirtualizacyjnych, takich jak Usługi Pulpitu Zdalnego (RDS) firmy Microsoft, lokalnie lub w chmurze.
  • Skonfigurowanie oprogramowanie do zarządzania klientami jako aplikacji wirtualnej, aby umożliwić zdalne zarządzanie.
  • Wybranie zarządzanie uprawnieniami (np. YubiKey).
  • Wybranie najbardziej wartościowy cienkiego klienta, który umożliwi proste i szybkie wdrożenie.

Prawidłowo wykonane rozwiązanie to bezpieczne, łatwe w użyciu, standaryzowane rozwiązanie dla domowego biura, które otwiera drzwi do bardziej elastycznej, skalowalnej i przyszłościowej infrastruktury IT.Oryginał dokumentu dostępny tutaj: Praca zdalna

Interesują Cię rozwiązania NComputing? Zapraszamy do kontaktu na adres sales@fen.plO autorze:

Jochen Polster jest weteranem branży, który spędził ponad 25 lat w sprzedaży i marketingu systemów i półprzewodników w Europie, Stanach Zjednoczonych i Azji. W NComputing pełni funkcję wiceprezesa ds. sprzedaży i marketingu w Europie.

O NComputing:

NComputing jest wiodącym dostawcą rozwiązań do wirtualizacji komputerowych stanowisk pracy, obsługującym ponad 70 000 firm w 140 krajach. NComputing specjalizuje się w dostarczaniu przystępnych cenowo, łatwych do wdrożenia, centralnie zarządzanych i wysokowydajnych rozwiązań dla cienkich klientów opartych na Raspberry Pi. RX-RDP jest gotowym do pracy w chmurze, bazującym na Raspberry Pi 3, urządzeniem typu cienki klient zaprojektowanym i zoptymalizowanym specjalnie dla Usług Pulpitu Zdalnego (RDS) firmy Microsoft. RX-RDP zapewnia bogate wrażenia, przypominające wrażenia z pracy na komputerze PC, w przystępnym cenowo, energooszczędnym urządzeniu o niewielkich rozmiarach. Nowy cienki klient RX420(RDP) zapewnia najwyższą wydajność z natywną obsługą dwóch ekranów. Bazuje na najnowszym modelu Raspberry Pi 4B. Oba rozwiązania typu cienki klient zapewniają pełnoekranowe odtwarzanie multimediów HD, obsługują Microsoft RemoteFX i NComputing vCAST Streaming, łączność Wi-Fi oraz umożliwiają przekierowanie urządzeń USB, zapewniając niezrównaną obsługę urządzeń peryferyjnych.

Jak w prosty sposób zautomatyzować procesy backupu, replikacji i weryfikację wykonanych kopii zapasowych w oparciu o rozwiązanie Nakivo Backup & Replication.

Jednym z zagadnień z którym borykają się administratorzy jest to w jaki sposób uprościć i zautomatyzować procesy odpowiedzialne za zapewnianie bezpieczeństwa i ciągłości pracy w firmach. Wyzwanie to szczególnie dotyka większe przedsiębiorstwa charakteryzujące się dynamicznie zmieniającym się środowiskiem IT oraz zarządzaniem rozdzielonym pomiędzy różnych specjalistów. Rozdział pomiędzy osoby o różnych kompetencjach jest naturalny jednak w wypadku braku odpowiednich procedur może prowadzić do obniżenia bezpieczeństwa np. poprzez brak kopii zapasowych dla nowych zasobów.

Wyobraźmy sobie sytuację, w której administrator odpowiedzialny za konfigurację środowiska wirtualnego dodaje maszynę, na której instalowana jest baza danych dla właśnie wdrażanej aplikacji. Ponieważ nie jest jasne czy maszyna zostanie na stałe czy też będzie wykorzystana tylko w czasie testów, administrator nie informuje o tym fakcie specjalisty odpowiedzialnego za backup środowiska wirtualnego.

Po pewnym czasie maszyna z testowej staje się produkcyjną, aplikacja zyskuje na popularności, a baza danych wypełnia się ważnymi rekordami. Pechowo macierz wykorzystywana jako datastore dla środowiska wirtualnego ulega awarii i rozsynchronizowuje się grupa RAID w którą połączone były dyski. Specjalista od backupu przystępuje do odtwarzania maszyn w środowisku zapasowym, pomijając kwestie czasu potrzebnego na odtwarzanie środowiska i brak ciągłości operacyjnej firmy, wszyscy są dobrej myśli, bo przecież backup środowiska był wykonywany i mamy się z czego odtwarzać. Na koniec dnia okazuje się, że działa wszystko poza nową aplikacją i wymaganą przez nią bazą danych która od czasu wdrożenia stała się jednym z ważniejszych narzędzi.

Oczywiście ten scenariusz można uznać za przekoloryzowany, który w organizacji o odpowiednich procedurach nie mógłby mieć miejsca, ale przypadków, w których ktoś zapomniał lub świadomie nie wykonał backupu, bo przecież u nas nic złego się nie wydarzy znaleźć można znacznie więcej i dotyczą one zarówno mniejszych firm jak i dużych korporacji.

Automatyczny backup i replikacja – Policy Based Data Protection

Automatyzacja zadań backupu i replikacji to jeden z elementów na który rozwiązanie Nakivo kładzie duży nacisk. Podstawą planowania procesów automatycznych jest odpowiednie ustawienie harmonogramów kopii zapasowych lub replikacji, w tym celu Nakivo oprócz możliwości utworzenia kilku harmonogramów w jednym zadaniu, udostępnia tzw. Calendar Dashboard dzięki któremu widzimy już zaplanowane zadania i łatwiej planować okna serwisowe.

Rys. 1 Widok kalendarza z perspektywy nowo tworzonego zadania.

Globalny widok kalendarza jest dostępny również bezpośrednio z menu głównego, na nim możemy nie tylko podejrzeć, ale również edytować zadania lub generować raporty.

Rys. 2 Widok kalendarza globalny umożliwiający edycję i generowanie raportów dla już zaplanowanych zadań.

Kluczowym elementem obok odpowiedniego zaplanowania okien serwisowych jest jednak możliwość realizacji zadań backupu nie dla pojedynczych maszyn, ale dla całych ich grup lub kontenerów, w których się znajdują. W tym celu w trakcie tworzenia zadania mamy do wyboru kilka opcji widoku środowiska, które zamierzamy backupować. Widok podstawowy pozwala nam wybrać konkretne maszyny, kontenery lub hosty, których zasoby zamierzamy backupować lub replikować.

Rys. 3 Widok podstawowy wyboru maszyn do zadania backupu lub replikacji: Hosts&Clusters

Widok VMs&Templates, umożliwia nam wybranie maszyn w zależności od ich przypisania do DC na poziomie vCenter, bez względu na to na którym z hostów działają maszyny, sprawdzi się w środowiskach, gdzie maszyny są przenoszone dynamicznie.

Rys. 4 Widok wyboru maszyn do zadania backupu lub replikacji: VMs&Templates

Najciekawszym jest jednak tryb Policy based, w momencie wywołania harmonogramu, zanim backup lub replikacja się rozpoczną administrator może wcześniej zaplanować jakie warunki mają być spełnione, aby zadanie zostało zrealizowane. Warunki można ze sobą łączyć, tworząc bardziej złożone scenariusze uzależniające wykonanie zadania od takich elementów jak: nazwa maszyny wirtualnej, lokalizacja maszyny wirtualnej, datastore wykorzystywany przez maszynę wirtualną, rozmiar maszyny wirtualnej, a także jej aktualny stan. Zastosowanie warunków umożliwia utworzenie zadań, które będą w zautomatyzowany sposób weryfikowały w trakcie wywołania harmonogramu czy nowe zasoby wymagające ochrony nie pojawiły się w naszej infrastrukturze, a jeżeli tak aby je objąć ochroną automatycznie.

Rys. 5 Widok wyboru maszyn do zadania backupu lub replikacji: Policy

Takie podejście zabezpiecza nas przed wspomnianym wcześniej przykładem, w którym nie było komunikacji pomiędzy specjalistami od środowiska wirtualnego i backupu, ponieważ nowa maszyna zostałaby w tym przypadku automatycznie wykryta i dodana do zadania a jej ochrona zostałaby zapewniona.

Automatyczna weryfikacja kopii zapasowej – Automatic Screenshot Verification

Kolejnym pytaniem, które zadajemy sobie czasami w kontekście rozwiązań do backupu jest to czy nasza kopia zapasowa jest użyteczna, czyli czy będziemy mieli z czego się odtwarzać jeżeli będzie taka konieczność. Dobrą praktyką jest cykliczne testowanie backupów pod kątem możliwości odtworzenia i uruchomienia chronionych maszyn. Nakivo upraszcza jednak również ten proces, dzięki Automatic Screenshot Verification, funkcja ta ma za zadanie w sposób całkowicie automatyczny po wykonaniu zadania backupu przeprowadzić próbę odtwarzania chronionej maszyny.

W trakcie procesu Nakivo wykorzystuje protokół iSCSI żeby backup maszyny podpiąć bezpośrednio z deduplikowanego i skompresowanego repozytorium do hosta wskazanego jako cel odtwarzania, w ten sposób maszyna uruchamiana jest w trybie tymczasowym bez kopiowania jej zawartości na odtwarzanego hosta. Po odtworzeniu maszyny wykonywany jest zrzut ekranu z konsoli środowiska wirtualnego dla odtworzonej maszyny, zrzut taki może zostać wysłany przez email lub dodany do raportu dotyczącego chronionego zasobu.

Rys. 6 Konfiguracja funkcji Automatic Screenshot Verification.

W trakcie konfiguracji funkcji możemy wskazać zasób, na który testowe odtwarzanie będzie wykonywane, ile maszyn możemy przetestować jednocześnie, aby uniknąć nadmiernego obciążenia środowiska, jakie będzie opóźnienie wykonania zrzutu ekranu od uruchomienia maszyny oraz jaki jest akceptowalny czas odtwarzania.

Automatyczna kopia backupu – Backup Copy

Dobre praktyki backupu jako wzór często wskazują strategię 3-2-1, czyli przechowywanie minimum 3 kopii zapasowych, na przynajmniej 2 nośnikach(urządzeniach) przy czym 1 z nich powinno znajdować się innej lokalizacji. Opisałem już jak zautomatyzować procesy backupu korzystając z Nakivo, nie odnieśliśmy się jednak jeszcze do możliwości archiwizacji wykonanego backupu lub jego przechowywania w innej lokalizacji. Jedną z metod którą można by wykorzystać jest stworzenie kilku zadań backupu wraz ze wskazaniem różnych repozytoriów jako obiektów docelowych.

Nakivo jako repozytorium może wykorzystać dyski lokalne modułu transporter (jeden z modułów funkcjonalnych rozwiązania), dyski podłączone do transportera po iSCSI, dyski sieciowe wykorzystując protokoły CIFS lub NFS oraz repozytoria chmurowe poprzez instalację modułu transporter w środowiskach AWS, Google Cloud lub Azure.

Takie podejście ma swoje wady, kilka zadań backupu realizowanych na tej samej maszynie powoduje niestety dodatkowe obciążenie hostów produkcyjnych koniecznością wykonywania wielokrotnie migawek chronionej maszyny, w środowiskach o znacznym obciążeniu lub gdy chcemy ograniczyć ilość przesyłanych danych istnieje możliwość wykonania kopii z już wykonanego backupu, dzięki czemu środowisko produkcyjne obciążane jest tylko raz, a jednocześnie dane możemy przechowywać w wielu lokalizacjach.

Rys. 7 Konfiguracja funkcji Backup Copy.

W ramach konfiguracji funkcji Backup Copy, możemy wybrać opcję tworzenia kopii wg ustalonego (odrębnego harmonogramu) lub uzależnić wykonanie kopii od już wykonywanych zadań, automatyzując proces archiwizacji. W ten sposób ukończone prawidłowo zadanie backupu danej maszyny może wywoływać zadanie utworzenia kopii, w którym również możemy skorzystać z wcześniej opisanego mechanizmu Screenshot Verification aby upewnić się, że ta kopia również będzie użyteczna.

Planowanie i testowanie procesów odtwarzania – Site Recovery

Zwieńczeniem automatyzacji procesów backupu i odtwarzania w Nakivo jest mechanizm Site Recovery. Mechanizm Site Recovery umożliwia utworzenie zestawu akcji, które mają być realizowane przez oprogramowania w określonej przez administratora kolejności w wypadku gdy dojdzie w środowisku do awarii, planowany jest serwis wirtualnej infrastruktury lub musimy udowodnić dla potrzeb wszelkiego rodzaju audytów wewnętrznych i zewnętrznych jak skutecznie i szybko jesteśmy w stanie odtworzyć nasze środowisko.

Proces tworzenia scenariuszy Site Recovery zaczynamy od planowania i jest to jeden z najważniejszych elementów od którego będzie zależała skuteczność i szybkość naszej procedury odtwarzania. Dodatkowo scenariusz będzie indywidualny w każdym środowisku i w dużej mierze będzie zależał od tego co chcemy uzyskać w jego wyniku.

Rys. 8 Tworzenie Scenariusza Site Recovery

Wśród akcji dostępnych w ramach tworzenia scenariuszy Site Recovery znajdziemy akcje wspólne, tj. takie które można wykonywać niezależnie od chronionego środowiska oraz akcje dedykowane poszczególnym środowiskom jak Vmware czy Hyper-V.

Przykładowe akcje wspólne to: wywołanie lub zatrzymanie wcześniej utworzonych zadań, wykonanie skryptu, podłączenie lub odłączenie repozytorium, wysłanie wiadomości email (w celu poinformowania o realizowanej procedurze odtwarzania), odczekanie określonego czasu lub sprawdzenie warunków dotyczących chronionego środowiska.

Przykładowe akcje dedykowane dla środowiska to: procedura Failover, czyli przeniesienia maszyn produkcyjnych na środowisko zapasowe, w ramach procedury możemy wyłączyć maszyny produkcyjne jeżeli działały w momencie uruchomienia procedury oraz uruchomić maszyny na środowisku zapasowym, włączając w to re-mapowanie niezbędnych interfejsów sieciowych oraz re-adresacje maszyn; procedura Failback, czyli odwrotność procedury Failover mechanizm pozwalający zsynchronizować maszyny zapasowe z maszynami produkcyjnymi i przerzucenie obciążenia z powrotem na środowisko produkcyjne; uruchomienie lub zatrzymanie określonych maszyn w środowisku.

Akcje wspólne i charakterystyczne dla środowiska łączymy w ciąg zdarzeń, który zostaje wywołany podczas testowania lub ręcznego wywołania procedury przez administratora.

Poszczególne z akcji mają możliwość określenia, które z nich będą wykonywane tylko w czasie awaryjnego odtwarzania, a które w czasie procedury testowej, dzięki czemu możemy zasymulować odtwarzanie środowiska bez szkody dla środowiska produkcyjnego.

Rys. 9 Uzależnienie wykonania akcji w ramach procedury odtwarzania od warunków uruchomienia procedury Site Recovery.

Testowanie odtwarzania może odbywać się zgodnie z zaplanowanym przez administratora harmonogramem, co zapewnia cykliczną aktualizację danych dotyczących skuteczności procedury w kontekście planowanego RTO (planowego czasu odtworzenia) dla naszego środowiska.

P2V czyli szybkie odtwarzanie serwerów fizycznych

Ostatni akapit nie jest szczególnie związany z automatyzacją procesów backupu ale mimo wszystko warto poświęcić mu jeszcze chwilę. Nakivo od początku swojego istnienia skupiło się na ochronie środowisk wirtualnych, Vmware, Hyper-V, Nutanix i instancje EC2 w AWS to (były) ich specjalności, od niedawna w oprogramowaniu doszła nam jednak możliwość ochrony środowisk fizycznych, a dokładniej backup Windows Server.

Korzystając już w tym wypadku z agenta (backup dla środowisk wirtualnych nie wymaga instalacji agenta na maszynach) tworzymy pełną kopię dysków maszyny fizycznej. Możemy z niej później wyciągnąć pliki, obiekty dla MS SQL, Exchange czy AD ale również odtworzyć taką maszynę w środowisku wirtualnym. Wspominam o tym dlatego, że bazując tylko na maszynach fizycznych, prędzej lub później każde środowisko będzie migrowało się do środowiska wirtualnego, a akurat tą funkcjonalność możemy wykorzystać w tym procesie migracji jak również, aby szybko  odtworzyć swój fizyczny serwer w środowisku wirtualnym bez konieczności oczekiwania na dostarczenie przez serwis jego sprzętowego zamiennika.

Zaczynamy od zainstalowania na serwerze fizycznym agenta, czyli specjalnej wersji transportera Nakivo, od tej chwili mamy możliwość realizacji zadania backupu maszyny fizycznej.

Backup maszyny fizycznej podobnie jak backupy maszyn wirtualnych trafia do repozytorium z którego możemy odtwarzać wspomniane wcześniej pliki lub obiekty podłączając ten zasób bezpośrednio do Directora Nakivo(moduł odpowiedzialny za zarządzanie całym rozwiązaniem) lub wskazanego w sieci serwera docelowego na który chcemy  odtworzyć elementy. Alternatywą do tego trybu odtwarzania jest jednak możliwość eksportu obrazu dysków z formatu przeznaczonego dla maszyn fizycznych do formatów przeznaczonych dla środowisk wirtualnych jak Vmware czy Hyper-V. Takie podejście daje nam elastyczność w odtwarzaniu nie tylko środowisk wirtualnych, ale również ważnych danych na fizycznych maszynach.

Podsumowanie

Omówione mechanizmy czynią z jednej strony pracę specjalistów od backupu wygodniejszą, a z drugiej zapewniają większe bezpieczeństwo dla chronionego środowiska. Istotnym czynnikiem, który warto brać pod uwagę na etapie wyboru rozwiązania jest dostępność takich mechanizmów oraz zasady ich licencjonowania, ponieważ często to one warunkują użyteczność produktu. Decydując się na Nakivo Backup & Replication jako rozwiązanie do ochrony środowiska często okazuje się, że koszty licencji są nawet połowę niższe w porównaniu do rozwiązań podobnej klasy, z jednej strony to pozwala ograniczać koszty operacyjne, a z drugiej skorzystać z oprogramowania o większych funkcjonalnościach. W Nakivo większość elementów związanych z automatyzacją dostępna jest w licencjach typu Enterprise Essentials oraz Enterprise.

O NAKIVO

Nakivo to amerykański producent oprogramowania skierowanego głównie do ochrony środowisk wirtualnych Vmware, Hyper-V, AWS oraz Nutanix niezależnie od tego czy chcesz robić backup, replikację czy odtwarzanie całego zestawu maszyn wirtualnych, Nakivo ma wbudowane niezbędne mechanizmy do realizacji tych celów. Cechami charakterystycznymi Nakivo oprócz elastycznej, modułowej budowy są zaawansowane funkcje pozwalające oszczędzać przestrzeń dyskową jak deduplikacja, ochrona danych z wykorzystaniem szyfrowania oraz unikalne rozwiązania, takie jak Screenshot Verification czyli możliwość automatycznej weryfikacji poprawności wykonanego backupu czy VM Flash Boot umożliwiająca awaryjne uruchomienie maszyny wirtualnej bezpośrednio z repozytorium backupu, bez konieczności kopiowania jej dysków do środowiska wirtualizacji. Nakivo pomimo oferowanego ogromu funkcjonalności często okazuje się nawet połowę tańsze w porównaniu do rozwiązań konkurencyjnych dzięki czemu świetnie wpisuje się w trend ograniczania kosztów w firmach różnej wielkości.

Więcej o rozwiązaniach Nakivo, na stronie nakivo.fen.pl

Nakivo Backup & Replication v9.0 – czas oficjalnie przywitać funkcjonalność backupu serwerów fizycznych

Z przyjemnością informujemy że wersja 9.0 oprogramowania Nakivo Backup & Replication jest już oficjalnie dostępna. Ostatnia wersja umożliwia oprócz rozbudowanych możliwości backupu i replikacji dla środowisk wirtualnych takich jak Vmware, Hyper-V, AWS czy Nutanix backup (plików i obiektów) dla fizycznych serwerów Windows. Drugą z funkcjonalności wyczekiwaną przez część klientów jest wsparcie dla Hyper-V 2019, dzięki czemu oprogramowanie pozwala chronić środowiska korzystające z ostatniej wersji tego hypervisora.

Backup serwerów fizycznych Windows

W Nakivo backup serwerów Windows Server wykonywany jest w trybie application-aware, zapewniającym spójność danych z aplikacji i baz danych (Microsoft Exchange, Active Directory, SharePoint, Oracle i inne) uruchomionych na Twoim serwerze. Backup wykonywany jest w trybie inkrementalnym, co oznacza, że tylko zmodyfikowane bloki danych są przenoszone przy kolejnych zadaniach backupu, to zapewnia krótszy czas backupu oraz bardziej efektywne wykorzystanie zasobów dyskowych.

Nakivo w celu oszczędności czasu może dodatkowo korzystać z akceleracji sieciowej, kompresji danych oraz deduplikacji czyli przechowywania jedynie unikalnych bloków danych. Pełne bezpieczeństwo zbackupowanych informacji zapewniają algorytmy szyfrowania umożliwiające szyfrowanie danych zarówno w trakcie transportu jak i spoczynku.

Ostatnim ale nie mniej ważnym usprawnieniem jest wprowadzenie zaawansowanej funkcjonalności P2V umożliwiającej odzyskiwanie danych (plików i obiektów) z serwerów fizycznych w środowisku wirtualnym Vmware lub Hyper-V.

Wsparcie Hyper-V 2019

Jeżeli już korzystasz lub właśnie rozważasz aktualizacje swojego środowiska wirtualizacyjnego do wersji Hyper-V 2019, Nakivo jest w stanie ochronić Twoje maszyny a Ty możesz korzystać z najnowszych funkcji dostępnych w tej wersji.

Źródło: https://www.nakivo.com/blog/nakivo-backup-replication-v9-0-windows-backup/

Synchroniczna kontra asynchroniczna strategia replikacji

Współczesny świat biznesu rozwija się z każdą sekundą, co oznacza, że ​​stale rośnie liczba krytycznych danych, które muszą być chronione. W razie katastrofy każda firma musi dysponować zestawem strategii odzyskiwania, aby jak najszybciej chronić i przywracać kluczowe procesy. W związku z tym pojawia się potrzeba zdalnej replikacji, która zakłada wysyłanie krytycznych danych biznesowych poza miejsce pracy w celu niezawodnego przechowywania i szybkiego odzyskiwania.

Co to jest replikacja zdalna?

Zdalna replikacja jest istotną częścią ochrony i odzyskiwania danych. Wcześniej replikacja była najczęściej używana do kopiowania i przechowywania danych aplikacji w lokalizacjach poza siedzibą. Jednak z biegiem czasu technologia ta znacznie się rozszerzyła. Obecnie replikacja umożliwia utworzenie zsynchronizowanej kopii maszyny wirtualnej na zdalnym hoście docelowym. Kopia VM jest nazywana repliką i działa tak jak zwykła maszyna wirtualna dostępna na hoście źródłowym. Repliki VM można przenosić i uruchamiać na dowolnym, sprawnym sprzęcie. Mogą zostać włączone w ciągu kilku sekund w przypadku awarii oryginalnej maszyny wirtualnej. Technologia ta może znacznie zmniejszyć przestoje, a także ograniczyć potencjalne ryzyko biznesowe i straty związane z katastrofą.

Przed uruchomieniem zadania replikacji należy wziąć pod uwagę następujące czynniki:

  • Odległość – im większa odległość między lokalizacjami, tym większe opóźnienie.
  • Przepustowość – szybkość internetu i połączenie sieciowe powinny być wystarczające, aby zapewnić zaawansowane połączenie dla szybkiego i bezpiecznego transferu danych.
  • Szybkość transmisji danych – szybkość transmisji danych powinna być niższa niż dostępna przepustowość, aby nie przeciążać sieci.
  • Technologia replikacji – zadania replikacji powinny być uruchamiane równolegle (jednocześnie) w celu efektywnego wykorzystania sieci.

Czynniki te pomagają określić, który typ replikacji jest lepszy, gdy mamy do czynienia z określonym rodzajem katastrofy.

Strategie replikacji

Można wyróżnić dwa główne typy replikacji danych: synchroniczne i asynchroniczne.

Replikacja synchroniczna

W tym przypadku dane są replikowane do dodatkowej lokalizacji zdalnej w tym samym czasie, gdy nowe dane są tworzone lub aktualizowane w głównym centrum danych. Umożliwia to niemal natychmiastową replikację, co pozwala zachować repliki danych zaledwie kilka minut starsze niż materiał źródłowy. Zasadniczo zarówno źródło hosta, jak i źródło docelowe pozostają całkowicie zsynchronizowane, co ma kluczowe znaczenie dla skutecznego przywracania systemu po awarii (DR).

Ze względu na to, że dane są atomowo aktualizowane w wielu lokalizacjach zdalnych, wpływa to na wydajność i dostępność sieci. Operacje atomowe są definiowane jako sekwencja operacji, które muszą być zakończone bez przerwy przed wykonaniem innego zadania. W kontekście synchronicznej replikacji oznacza to, że zapis jest uważany za zakończony tylko wtedy, gdy oba lokalne i zdalne magazyny potwierdzają jego zakończenie. Dlatego gwarantowana jest zerowa utrata danych, ale ogólna wydajność jest spowolniona.

Replikacja asynchroniczna

W takim przypadku replikacja nie jest wykonywana w tym samym czasie, co zmiany w pamięci podstawowej. Dane są replikowane tylko we wcześniej określonych przedziałach czasowych (może to być godzina, dzień lub tydzień). Replika może być przechowywana w zdalnej lokalizacji DR, ponieważ nie musi być synchronizowana z pierwotną lokalizacją w czasie rzeczywistym.

Przy replikacji asynchronicznej dane nie są aktualizowane atomowo w wielu lokalizacjach, co oznacza, że ​​aplikacja kontynuuje pisanie danych, które nie są jeszcze w pełni zreplikowane. W związku z tym zapis uznaje się za zakończony, gdy tylko pamięć lokalna go potwierdza.

Replikacja asynchroniczna poprawia wydajność i dostępność sieci bez wpływu na przepustowość. Wynika to z faktu, że repliki nie są aktualizowane w czasie rzeczywistym. Minusem jest to, że w scenariuszu katastrofy strona DR może nie zawierać ostatnio wprowadzonych zmian, więc niektóre krytyczne dane mogą zostać utracone.

Replikacja synchroniczna vs. asynchroniczna: główne różnice

Co jest lepsze: replikacja synchroniczna lub asynchroniczna?

Na to pytanie nie ma jednoznacznej odpowiedzi; wybór zależy całkowicie od priorytetów biznesowych. Asynchroniczna replikacja działa najlepiej w przypadku projektów obejmujących duże odległości, którym przydzielony jest minimalny budżet. Jest także odpowiednia dla firm, które mogą sobie pozwolić na częściową utratę danych. Z drugiej strony replikacja synchroniczna jest wykonywana, gdy wymagane jest niezawodne i długoterminowe przechowywanie, a firma nie może pozwolić sobie na utratę krytycznych danych. Jest to przydatne, gdy RTO i RPO są krótkie.

Istnieje jednak pole pośrednie: można używać zarówno synchronicznych, jak i asynchronicznych strategii replikacji na różnych poziomach infrastruktury. Na przykład replikacja synchroniczna może być używana do przesyłania i zabezpieczania danych przez sieć lokalną (LAN), podczas gdy replikacja asynchroniczna wysyła krytyczne dane do zdalnej lokalizacji DR.

Replikacja w NAKIVO Backup&Replication

Tryb replikacji

Replikacja w NAKIVO Backup&Replication jest zawsze przyrostowa . Pierwsza replikacja kopiuje pełną maszynę wirtualną, ale następujące zadania replikacji będą zapisywać tylko zmiany danych w replice (przyrostach). Ponadto po każdym zadaniu replikacji tworzony jest punkt odzyskiwania odwołujący się do wszystkich bloków danych wymaganych do odtwarzania maszyny wirtualnej. Ten tryb replikacji zapewnia mniejsze obciążenie sieci i oszczędza czas, który w innym przypadku zostałby poświęcony na pełne zadania replikacji.

Zgodne platformy

NAKIVO Backup & Replication oferuje szybkie wdrażanie na różnych platformach sprzętowych i programowych:

  • VMware VA. Wstępnie skonfigurowany VMware Virtual Appliance można łatwo pobrać, a następnie zaimportować do VMware vSphere.
  • Instalując NAKIVO Backup & Replication bezpośrednio na urządzeniu NAS, można stworzyć własne urządzenie do tworzenia kopii zapasowych VM.
  • AWS AMI. Oprogramowanie NAKIVO Backup & Replication można wdrożyć w chmurze Amazon jako wstępnie skonfigurowany obraz Amazon Machine Image (AMI).
  • Oprogramowanie NAKIVO Backup & Replication można zainstalować na fizycznej lub wirtualnej maszynie z systemem Linux za pomocą jednego polecenia.
  • Oprogramowanie NAKIVO Backup & Replication można zainstalować na fizycznym lub wirtualnym komputerze z systemem Windows za pomocą jednego kliknięcia.

Funkcje replikacji

Migawki

Migawka rejestruje stan systemu w określonym momencie. Za pomocą NAKIVO Backup & Replication repliki VM są tworzone za pomocą migawek VM, które służą do pobierania aktualnych danych maszyn wirtualnych. Za każdym razem, gdy wykonywane jest zadanie replikacji, pobierana jest tymczasowa migawka maszyny wirtualnej, zmienione dane są identyfikowane, a wszystkie aktualizacje są dodawane do repliki. Po zakończeniu zadania migawka zostaje usunięta.

Changed block tracking

Oprogramowanie NAKIVO Backup & Replication wykorzystuje VMware CBT (Changed Block Tracking) i Hyper-V RCT (Resilient Change Tracking) do identyfikowania i kopiowania zmian, które zostały wprowadzone w maszynie wirtualnej od czasu ostatniej replikacji. Ta technologia znacząco poprawia szybkość replikacji. Jeśli CBT i RCT są niedostępne, NAKIVO Backup & Replication używa wbudowanej zastrzeżonej metody śledzenia zmian.

Obsługa aplikacji na żywo

NAKIVO Backup & Replication to rozwiązanie obsługujące aplikacje. Maszyny wirtualne są używane do uruchamiania wszelkiego rodzaju aplikacji o znaczeniu krytycznym, takich jak Microsoft Exchange, Active Directory, SQL, SharePoint itp. W przypadku tych programów z częstym wprowadzaniem i generowaniem danych istotne jest zapewnienie, że dane aplikacji są zawsze spójne, szczególnie gdy zadanie replikacji jest uruchomione. Tak więc po utworzeniu migawki aplikacje wewnątrz maszyny wirtualnej przechowują wszystkie transakcje w pamięci, aby nie zakłócać żadnych działających operacji.

Ochrona kontenera

Program NAKIVO Backup & Replication ułatwia ochronę krytycznych maszyn wirtualnych, umożliwiając ich uporządkowanie w kontenerach, takich jak pule zasobów, foldery lub klastry. Cały kontener można dodać do określonego zadania replikacji. Można łatwo dodawać lub usuwać elementy z kontenera, które to zmiany są automatycznie odzwierciedlane w odpowiednich zadaniach replikacji. Funkcja jest elastyczna; można również wykluczyć niektóre maszyny wirtualne z kontenera z zadania replikacji. W takim przypadku cały kontener zostanie objęty ochroną z wyjątkiem wykluczonych maszyn wirtualnych.

Screenshot verification

Ta funkcja umożliwia automatyczne sprawdzenie, czy replikacja maszyn wirtualnych zakończyła się pomyślnie. Zaraz po zakończeniu zadania replikacji sieć w replice jest wyłączona, a replika jest chwilowo włączona, aby wykonać zrzut ekranu. Replika jest następnie wyłączana i powracana do najnowszego punktu odzyskiwania. Użytkownik otrzymuje raport e-mail ze zrzutem ekranu z testowanego systemu operacyjnego.

Grupowanie zadań

NAKIVO Backup & Replication pozwala organizować zadania replikacji w grupy (foldery), aby rozmieścić aplikacje, usługi i lokalizacje w strukturach logicznych. Ponadto akcje zbiorcze można łatwo wykonać dla wszystkich lub wybranych zadań dla grupy.

Automatyczne raporty

Jeśli chcemy być informowani o statusie zadań replikacji, NAKIVO Backup & Replication może powiadomić nas o tym, wysyłając automatyczne raporty e-mailem, według harmonogramu lub na żądanie.

Harmonogram zadań

Program NAKIVO Backup & Replication umożliwia konfigurowanie zadań replikacji uruchamianych na żądanie lub zgodnie z harmonogramem (codziennie, co tydzień, co miesiąc i co rok). Możesz nawet skonfigurować zadania, aby działały według niestandardowego harmonogramu, który odpowiada konkretnym potrzebom biznesowym, np. co 20 minut, co 5 dni lub w pierwszy wtorek każdego miesiąca. Możesz także określić okna czasowe, w których zadanie powinno się rozpoczynać i kończyć.

Etapowa replikacja VM (wysiewanie)

Początkowa (pełna) replikacja większych maszyn wirtualnych może zająć dużo czasu ze względu na ich rozmiar. Aby przyspieszyć proces, NAKIVO Backup & Replication może przeprowadzić etapową replikację maszyn wirtualnych. Ta funkcja umożliwia przeniesienie (“seed”) początkowych replik VM na nośniki wymienne. Następnie repliki te można przetransportować do nowej witryny, gdzie nowe zadanie replikacji jest uruchamiane przy użyciu przesłanych maszyn wirtualnych. Następnie wykonywana jest tylko przyrostowa replikacja.

Punkty odzyskiwania

Punkt odzyskiwania reprezentuje maszynę wirtualną w określonym momencie, która następnie jest używana do odzyskiwania VM. Za pomocą narzędzia NAKIVO Backup & Replication można przechowywać do 30 punktów odzyskiwania na replikę maszyny wirtualnej. Produkt umożliwia zapisywanie punktów przywracania zgodnie z zasadami przechowywania Grandfather-Father-Son (GFS), jak opisano poniżej. Ta metoda zapewnia, że ​​punkty odzyskiwania repliki VM są zapisywane w witrynie DR z wyznaczonymi częstotliwościami (np. codziennie, co tydzień, co miesiąc i co rok).

  • Zachowaj jeden punkt przywracania na tydzień przez X tygodni: Ostatni punkt odzyskiwania każdego tygodnia jest przechowywany przez określoną liczbę tygodni.
  • Zachowaj jeden punkt odzyskiwania miesięcznie przez X miesięcy: Ostatni punkt odzyskiwania każdego miesiąca jest przechowywany przez określoną liczbę miesięcy.
  • Zachowaj jeden punkt odzyskiwania rocznie przez X lat: Ostatni punkt odzyskiwania każdego roku jest przechowywany przez określoną liczbę lat.
  • RTO i RPO

Cel punktu odzyskiwania (RPO) to limit najwcześniejszego momentu, w którym maszyna wirtualna powinna zostać przywrócona podczas DR. W ten sposób określa ilość danych, które można utracić, nie powodując nieuzasadnionych szkód dla Twojej firmy. Replikacja może pomóc w spełnieniu krótszych RPO, ponieważ zadania replikacji można uruchamiać według potrzeb za pomocą niestandardowych harmonogramów ustawionych dla nich.

Replikacja maszyn wirtualnych może również pomóc w osiągnięciu krótkich czasów odzyskiwania (RTO). RTO to określony czas, w którym operacje biznesowe muszą zostać odzyskane po katastrofie. Dzięki replikacji maszynę wirtualną można natychmiast przywrócić, uruchamiając replikę.

Przypadki zastosowań

Replikacja maszyn wirtualnych może chronić usługi o kluczowym znaczeniu dla biznesu przed wieloma problemami, w tym powodowanymi przez krytyczną utratę VM/awarię maszyny wirtualnej, awarię hosta/magazynu danych lub klęski żywiołowe. Replikacja maszyn wirtualnych jest zwykle używana, gdy projekty działają z danymi wrażliwymi i/lub tolerują utratę danych zerowych. Replikacja jest odpowiednia dla tych przypadków, ponieważ odzyskiwanie VM może być wykonane łatwo i prawie natychmiast po wystąpieniu awarii.

Funkcja replikacji jest używana w następujących przypadkach:

  1. Odzyskiwanie po awarii z repliką

Za pomocą NAKIVO Backup & Replication można w znacznym stopniu złagodzić negatywne skutki awarii systemu, takie jak przestoje i utrata dochodów. Dzięki replikacji maszyn wirtualnych możesz niemal natychmiast odzyskać całą maszynę wirtualną za pomocą jej repliki, zapewniając w ten sposób wysoką dostępność usług biznesowych.

  1. Przełączanie awaryjne oraz powrót po awarii

Kiedy katastrofa pozbawi nas podstawowej bazy danych, firma może zostać poważnie dotknięta – chyba że mamy efektywny plan DR. Tutaj przydatne jest przełączanie awaryjne. Przełączanie awaryjne, to proces przełączania ze źródłowej maszyny wirtualnej na replikę maszyny wirtualnej w celu przeniesienia obciążeń o znaczeniu krytycznym z witryny, której dotyczy problem, do witryny DR.

Po przywróceniu głównej lokacji możesz przełączyć operacje biznesowe z powrotem na oryginalną maszynę wirtualną. Ten proces nazywany jest funkcją powrotu po awarii i umożliwia synchronizację danych między lokacją główną a witryną DR.

  1. Odzyskiwanie lokalizacji

Za pomocą narzędzia NAKIVO Backup & Replication można tworzyć przepływy pracy (zadania) odzyskiwania lokalizacji, które są łatwymi w konfiguracji niestandardowymi algorytmami do automatyzacji i orkiestracji procesu DR. Ręczna realizacja planu odzyskiwania po awarii może być czasochłonnym i wymagającym dużej ilości zasobów zadaniem. Na szczęście, NAKIVO Backup & Replication pozwala organizować akcje w zadania odzyskiwania lokalizacji, które można uruchomić za pomocą zaledwie kilku kliknięć. Możesz utworzyć specjalne zadania Site Recovery, aby poradzić sobie z dowolnym zdarzeniem DR.

Poniższe działania i warunki można uwzględnić w przepływach pracy odzyskiwania lokalizacji:

  • Przełączanie awaryjne maszyn wirtualnych. Przejście do już utworzonej repliki VM.
  • Powrót po awarii maszyn wirtualnych. Przeniesienie obciążeń z powrotem z repliki maszyny wirtualnej w witrynie DR do źródłowej maszyny wirtualnej w miejscu produkcji.
  • Uruchomienie maszyn wirtualnych. Uruchamiamy jedną lub wiele maszyn wirtualnych.
  • Zatrzymanie maszyn wirtualnych. Zatrzymanie jednej lub wielu maszyn wirtualnych.
  • Uruchomienie zadań. Uruchomienie zadań ochrony danych (tworzenie kopii zapasowych, replikacja itd.), które już zostały utworzone dla maszyn wirtualnych.
  • Zatrzymanie zadań. Zatrzymanie zadań ochrony danych VM, które są uruchomione.
  • Uruchomienie skryptu. Uruchomienie własnego skryptu przed lub po zadaniu na komputerze z systemem Windows lub Linux.
  • Załączenie repozytorium. Dołączenie repozytorium kopii zapasowych.
  • Odłączenie repozytorium. Odłączenie dołączonych repozytorium kopii zapasowych.
  • Wysyłanie e-maili. Otrzymywanie powiadomień e-mail z informacją o wynikach po wykonaniu określonej czynności.
  • Czekać. Zaczekaj na określony czas przed rozpoczęciem następnej akcji.
  • Sprawdź stan. Sprawdź, czy istnieje zasób, czy uruchomiony jest zasób, lub czy adres IP/nazwa hosta są osiągalne przed przejściem do następnej czynności.

Wnioski

Każda firma może paść ofiarą niespodziewanej katastrofy lub awarii systemu, która może zagrozić integralności ważnych dla firmy danych. To sprawia, że ​​posiadanie efektywnego planu DR jest absolutnie niezbędne w nowoczesnym świecie biznesu, gdzie wysoka dostępność i ciągłość biznesowa są najważniejsze.

Replikacja może stać się nieocenionym narzędziem dla DR. Synchroniczne i asynchroniczne strategie replikacji powinny być wdrażane inteligentnie, w zależności od priorytetów i potrzeb biznesowych. Asynchroniczna replikacja to opłacalna strategia, która wymaga mniejszej przepustowości i braku dodatkowego sprzętu. Może być używany do przechowywania mniej wrażliwych danych i przesyłania danych na duże odległości. Chociaż replikacja synchroniczna jest wysoce zależna od połączenia sieciowego i opóźnień, gwarantuje zerową utratę danych i pozwala natychmiastowo przywrócić operacje o znaczeniu krytycznym.

NAKIVO Backup & Replication to szybkie i elastyczne rozwiązanie, które może replikować maszyny wirtualne do jednej lub więcej zdalnych lokalizacji w celu niezawodnego przechowywania. Dzięki rozwiązaniu można po prostu włączyć repliki podczas awarii, unikając w ten sposób utraty przychodów i długotrwałego wyłączania.

Odzyskiwanie po awarii vs wysoka dostępność vs tolerancja uszkodzeń – NAKIVO

Jeśli chodzi o utrzymanie infrastruktury informatycznej organizacji przez 24 godziny na dobę, 7 dni w tygodniu, nadal istnieją pewne niejasności między trzema głównymi terminami używanymi w tej dziedzinie. Te podstawowe pojęcia to: wysoka dostępność (HA – high availability), tolerancja uszkodzeń (FT – fault tolerance) i odzyskiwanie po awarii (DR – disaster recovery). Terminy te są często używane zamiennie, ponieważ na pozór wszystkie mają na celu osiągnięcie ciągłości systemu informatycznego. Ważne jest jednak, aby pamiętać, że każde z tych terminów ma swoje własne specyficzne definicje, metodologie i role.

W tym artykule w praktyce określimy znaczenie wysokiej dostępności, tolerancji uszkodzeń i odzyskiwania po awarii. Sprawdzimy, jak te terminy się pokrywają, a także dlaczego warto je wdrożyć.

Wysoka dostępność

Wysoka dostępność jest cechą systemu, który ma na celu zapewnienie uzgodnionego poziomu wydajności operacyjnej, zwykle nieprzerwanego działania, przez okres dłuższy niż normalny.

HA to koncepcja, która przejawia się wyłącznie dzięki technologii. Celem projektu HA jest dostarczenie 99,999% czasu pracy bez przestojów. Niemniej jednak ważne jest, aby podkreślić, że HA nie zapewnia 100% czasu działania, a czas przestoju (do 5,26 minuty/rok) jest akceptowalny.

Jak działa wysoka dostępność?

Cel “pięciu dziewiątek” osiąga się przez wyeliminowanie pojedynczego punktu awarii w systemie. W tym celu można wdrożyć komponenty redundancji i przełączania awaryjnego, które są skonfigurowane do obsługi obciążeń bez interwencji człowieka w przypadku awarii komponentu podstawowego.

W wirtualizacji można zaprojektować wysoką dostępność za pomocą technologii klastrowych. Na przykład, gdy jeden z hostów lub maszyn wirtualnych (VM) w klastrze ulegnie awarii, inna maszyna wirtualna przejmuje i utrzymuje właściwą wydajność systemu.

Kiedy ważna jest wysoka dostępność?

Przemyślana architektura HA jest ważna dla każdej firmy, która dąży do zminimalizowania przestojów. Według statystyk, w 2017 r. koszt godzinnego przestoju wynosił od 301 do 400 tys. USD dla dużej liczby (24%) przedsiębiorstw na całym świecie. Oznacza to, że nawet dopuszczalna ilość przestojów – 5,26 minut – kosztuje biznes do 35 tysięcy USD.

Oprócz znacznych strat finansowych, przestoje mogą mieć inne poważne konsekwencje, takie jak utrata wydajności, niemożność terminowego dostarczania usług, utrata reputacji firmy i tak dalej. Wysoce dostępne systemy pomagają uniknąć takich scenariuszy poprzez automatyczne rozwiązywanie awarii i na czas.

Co sprawia, że ​​system jest wysoce dostępny?

Posiadanie komponentów redundantnych jest podstawowym warunkiem zapewnienia wysokiej dostępności, jednak posiadanie tych komponentów nie wystarcza, aby system mógł być uważany za wysoce dostępny. System wysoce dostępny to taki, który zawiera zarówno nadmiarowe komponenty i mechanizmy wykrywania awarii, jak i przekierowanie obciążenia. Mogą to być elementy równoważące obciążenie lub hypervisor.

Tolerancja uszkodzeń

Tolerancja uszkodzeń jest właściwością, która umożliwia systemowi prawidłowe działanie w przypadku awarii niektórych (jednego lub więcej błędów wewnątrz) jego komponentów.

Mówiąc prościej, tolerancja uszkodzeń, to bardziej rygorystyczna wersja wysokiej dostępności. HA skupia się na zapewnieniu minimalnych przestojów, a FT idzie dalej, zapewniając zero przestojów. Jednak w modelu tolerancji uszkodzeń zdolność systemu do zapewnienia wysokiej wydajności w przypadku awarii nie jest priorytetem. W przeciwieństwie, oczekuje się, że system może utrzymać wydajność operacyjną, ale na obniżonym poziomie.

Jak działa tolerancja uszkodzeń?

Podobnie jak w przypadku wysokiej dostępności, tolerancja uszkodzeń działa również na zasadzie nadmiarowości. Taka nadmiarowość może zostać osiągnięta poprzez jednoczesne uruchomienie jednej aplikacji na dwóch serwerach, co umożliwia jednemu serwerowi natychmiastowe przejęcie drugiego, jeśli mu się nie powiedzie.

W wirtualizacji nadmiarowość jest osiągana poprzez utrzymywanie i uruchamianie identycznych kopii danej maszyny wirtualnej na osobnym hoście. Wszelkie zmiany lub dane wejściowe, które mają miejsce na podstawowej maszynie wirtualnej, są duplikowane na wtórnej maszynie wirtualnej. W ten sposób, w przypadku uszkodzenia maszyny wirtualnej, tolerancja na awarie jest zapewniona poprzez natychmiastowy transfer obciążeń z jednej maszyny wirtualnej do jej kopii.

Kiedy ważna jest tolerancja uszkodzeń?

Tolerancja uszkodzeń jest niezbędna do wdrożenia, jeśli Nasz system IT nie toleruje żadnych przestojów. Jeśli istnieją krytyczne aplikacje, które wspierają operacje biznesowe, a nawet najmniejszy czas przestoju może przełożyć się na nieodwracalne straty, powinniśmy rozważyć skonfigurowanie swoich komponentów IT z myślą o FT.

Czym jest system tolerujący uszkodzenia?

System tolerujący uszkodzenia, to system, który obejmuje dwa ściśle połączone elementy, które odzwierciedlają się nawzajem, zapewniając nadmiarowość. W ten sposób, jeśli podstawowy komponent zostanie wyłączony, drugi jest zawsze gotowy do natychmiastowego przejęcia.

Odzyskiwanie po awarii

Odzyskiwanie awaryjne obejmuje zestaw zasad, narzędzi i procedur umożliwiających odzyskiwanie lub kontynuację infrastruktury i systemów infrastruktury o podstawowym znaczeniu w następstwie katastrofy naturalnej lub wywołanej przez człowieka.

Co to jest odzyskiwanie po awarii?

Zwykle DR wymaga posiadania dodatkowej lokalizacji, w której można przywrócić krytyczne dane i obciążenia (całkowicie lub częściowo) w celu wznowienia wystarczającej działalności biznesowej po wystąpieniu zakłócającego zdarzenia. Aby przenieść obciążenia do zdalnej lokalizacji, konieczne jest włączenie odpowiedniego rozwiązania do odtwarzania po awarii. Takie rozwiązanie może w porę zająć się operacją przełączania awaryjnego przy niewielkim lub zerowym wkładzie ze strony użytkownika, co pozwala osiągnąć wyznaczone cele czasu przywracania.

Jak działa odzyskiwanie po awarii?

Zwykle DR wymaga posiadania dodatkowej lokalizacji, w której można przywrócić krytyczne dane i obciążenia (całkowicie lub częściowo) w celu wznowienia wystarczającej działalności biznesowej po wystąpieniu zakłócającego zdarzenia. Aby przenieść obciążenia do zdalnej lokalizacji, konieczne jest włączenie odpowiedniego rozwiązania do odtwarzania po awarii. Takie rozwiązanie może w porę zająć się operacją przełączania awaryjnego przy niewielkim lub zerowym wkładzie ze strony użytkownika, co pozwala osiągnąć wyznaczone cele czasu przywracania.

Jakie są elementy odzyskiwania po awarii?

W przeciwieństwie do HA i FT, odzyskiwanie po awarii jest znacznie szerszą i bardziej złożoną koncepcją, która odnosi się do strategii z obszernym zestawem komponentów, w tym: ocena ryzyka, planowanie, analiza zależności, zdalna konfiguracja lokalizacji, szkolenie personelu, testowanie, konfiguracja automatyzacji i tak dalej. Odzyskiwanie po awarii wykracza poza wysoką dostępność i tolerancję uszkodzeń, ale może i powinno uwzględniać te czynniki w jego projekcie technologicznym.

Kiedy odzyskiwanie po awarii jest ważne?

Termin katastrofa odnosi się nie tylko do klęski żywiołowej, ale także do wszelkich zakłóceń, które prowadzą do znaczących przestojów, takich jak ataki cybernetyczne, przerwy w zasilaniu, błędy ludzkie, awarie oprogramowania i inne incydenty. Oznacza to, że takie wydarzenia mogą odbywać się w dowolnym miejscu i czasie, co sprawia, że ​​organizacje wszystkich typów i rozmiarów są potencjalnymi ofiarami. Podczas gdy w większości przypadków katastrofy są niemożliwe do przewidzenia lub uniknięcia, organizacje mogą i powinny podejmować działania w celu wzmocnienia gotowości do odzyskiwania po awarii, a także regularnie optymalizować swoje strategie DR.

NAKIVO Backup&Replication dla odzyskiwania po awarii

NAKIVO Backup & Replication to szybkie, niezawodne i przystępne cenowo rozwiązanie, które łączy w sobie wysoką ochronę danych, a także funkcję odzyskiwania po awarii w jednym pakiecie oprogramowania. Funkcja Site Recovery została zaprojektowana z myślą o prostocie i automatyzacji operacji odzyskiwania po awarii.

Jeśli mamy skonfigurowaną witrynę zdalną, zgodnie z najlepszymi praktykami DR, możemy całkowicie polegać na NAKIVO Backup & Replication jako narzędziu do odzyskiwania po awarii. Funkcja przywracania lokalizacji jest łatwa w obsłudze i konfiguracji, ale umożliwia tworzenie złożonych przepływów pracy odzyskiwania.

Można połączyć do 200 działań w jednym przepływie pracy (zadaniu), aby dopasować się do różnych scenariuszy katastrofy i służyć do różnych celów, w tym: monitorowania, migracji centrów danych, awaryjnego przełączania awaryjnego, planowanego przełączania awaryjnego, powrotu po awarii itd. W razie katastrofy utworzone przepływy pracy można natychmiast wdrożyć, za pomocą jednego kliknięcia, co pozwala firmom osiągnąć jak najkrótszy czas na odzyskanie danych.

Dzięki funkcji Site Recovery możemy przeprowadzać automatyczne, niezakłócone testy DR. W ten sposób możemy upewnić się, że przepływy pracy odzyskiwania lokalizacji są poprawne i odzwierciedlają wszystkie ostatnie zmiany, które miały miejsce w naszej infrastrukturze IT, w celu wykluczenia ewentualnych słabości przed rzeczywistymi trafieniami po katastrofie.

Statystyki pokazują, że większość informatyków uważa nowoczesne rozwiązania DR za nieosiągalne luksusy, a nie niezbędny element w ich strategii ochrony i odzyskiwania danych. NAKIVO dokonało niezawodnego odzyskiwania po awarii, dostępnego dla wielu firm, oferując NAKIVO Backup & Replication z Site Recovery za ułamek kosztów w porównaniu do konkurentów.

Wniosek

Podczas gdy wysoka dostępność i tolerancja na uszkodzenia są wyłącznie technologiczne, odzyskiwanie po awarii obejmuje znacznie więcej niż tylko elementy oprogramowania/sprzętu. HA i FT koncentrują się na rozwiązywaniu pojedynczych awarii w systemie IT. DR przeciwnie, zajmuje się problemami o znacznie większym zasięgu, a także konsekwencjami takich awarii. Włączenie wysokiej dostępności lub tolerancji na uszkodzenia nie może zapewnić ochrony przed katastrofami, ale obie z nich mogą skutecznie uzupełnić strategie odzyskiwania po awarii.

NAKIVO Backup & Replication z Site Recovery to rozwiązanie “pod klucz”, które zapewnia zintegrowaną ochronę przed utratą danych. Włączając rozwiązanie do swojego środowiska, możemy zapewnić szybkie odzyskiwanie danych w wielu witrynach niezależnie od okoliczności.

Kornelia Szlósarczyk

Site Recovery w NAKIVO Backup & Replication Część 6: Failback

Site Recovery to nowa zaawansowana funkcja, która została wydana wraz z NAKIVO Backup & Replication 8.0. Dzięki funkcji Site Recovery można łatwo utworzyć plan przywracania po awarii dla danego środowiska i przywrócić maszyny wirtualne przy użyciu odpowiednich obciążeń. W poprzednim artykule dotyczącym Site Recovery analizowaliśmy awaryjne przełączanie VM, które może być użyte jako działanie dla zadania Site Recovery i może przełączyć się ze źródłowej maszyny wirtualnej na replikę maszyny wirtualnej. Dzisiejszy artykuł obejmuje akcję powrotu po awarii (która jest odwróceniem do pracy awaryjnej), rolę powrotu po awarii dla odzyskiwania lokalizacji i sposób wykorzystania działania powrotu po awarii.

Informacje na temat powrotu po awarii

Przełączanie awaryjne oznacza przeniesienie obciążeń maszyny źródłowej VM na replikę maszyny wirtualnej, która jest identyczną kopią źródłowej maszyny wirtualnej w odpowiednim momencie. Można to zrobić, ponieważ miejsce produkcji (gdzie zlokalizowana jest źródłowa maszyna wirtualna) zostało naruszone przez jakąś katastrofę lub z wyprzedzeniem, jeśli przewiduje się katastrofę. Replika maszyny wirtualnej zazwyczaj znajduje się w tymczasowej, geograficznie oddzielnej lokalizacji zwanej witryną odzyskiwania po awarii (DR). Kiedy źródłowa maszyna wirtualna przestaje działać, a proces przełączania awaryjnego jest używany, wszystkie zmiany po przełączeniu awaryjnym są zapisywane w replice maszyny wirtualnej, ale nie w źródłowej maszynie wirtualnej. Po utworzeniu kopii zapasowej witryny produkcyjnej i ponownym uruchomieniu źródłowej maszyny wirtualnej zmiany wprowadzone do repliki maszyny wirtualnej od momentu przełączenia awaryjnego muszą zostać przesłane do źródłowej maszyny wirtualnej. W związku z tym dane są ponownie synchronizowane z replikacją wsteczną.

Powrót awaryjny jest procesem przywracania maszyn wirtualnych w ich rzeczywistych stanach do miejsca produkcji z witryny DR i zwracania obciążeń do miejsca produkcji, które pierwotnie sobie z nimi radziło. Ewentualnie można przenieść obciążenia do nowej witryny produkcyjnej z funkcją powrotu po awarii. Zastanówmy się, w jaki sposób dane są przesyłane za pomocą przykładu.

  1. Istnieją dwie witryny: strona produkcyjna i strona odzyskiwania po awarii (DR). Maszyna wirtualna jest replikowana z witryny produkcyjnej do witryny DR. Źródłowa maszyna wirtualna znajduje się w miejscu produkcji, podczas gdy jej replika VM znajduje się na stronie odtwarzania po awarii. Dane na dyskach wirtualnych źródłowej maszyny wirtualnej i repliki maszyny wirtualnej są identyczne po replikacji. Po wystąpieniu awarii następuje przełączenie awaryjne na replikę maszyny wirtualnej.
  1. Po przeprowadzeniu przełączenia awaryjnego na replikę maszyny wirtualnej zadania zostały przeniesione do witryny odzyskiwania po awarii. Wszelkie dalsze zmiany maszyny wirtualnej (np. transakcje dodane do bazy danych, gdy klienci dokonują zakupów online) są zapisywane na wirtualnym dysku repliki maszyny wirtualnej podczas działania. Niektóre bloki są zapisywane, a niektóre bloki są kasowane. Dysk wirtualny źródłowej maszyny wirtualnej nie uwzględnia tych transakcji.Wszystkie zmiany są zapisywane w replice maszyny wirtualnej po przywróceniu systemu po awarii i przełączeniu awaryjnym.
  1. Szkody spowodowane przez katastrofę zostały rozwiązane (lub zagrożenie minęło). Zakład produkcyjny jest znowu funkcjonalny i, odpowiednio, obciążenia muszą zostać zwrócone do miejsca produkcji ze strony DR. Zaktualizowane dane z repliki VM muszą zostać przesłane z powrotem do źródłowej maszyny wirtualnej. Maszyny wirtualne muszą zostać ponownie zsynchronizowane z replikacją wsteczną w ramach procesu powrotu po awarii.

Zalety powrotu awaryjnego

Korzystanie z funkcji powrotu po awarii wbudowanej w NAKIVO Backup & Replication zapewnia następujące korzyści:

  • Dane maszyny wirtualnej pozostają aktualne po przełączeniu z witryny DR do miejsca produkcji.
  • Możemy zautomatyzować proces migracji danych i obciążeń z powrotem do miejsca produkcji. Nie ma konieczności usuwania starych maszyn wirtualnych z miejsca produkcji i ręcznego kopiowania danych z każdej repliki maszyny wirtualnej z witryny DR do zakładu produkcyjnego.
  • Automatyzacja minimalizuje przestoje podczas migracji obciążeń z witryny DR do miejsca produkcji.

W jaki sposób działa funkcja powrotu po awarii w kopii zapasowej i replikacji NAKIVO?

W celu umożliwienia powrotu po awarii, muszą być spełnione następujące warunki:

  • Replika maszyny wirtualnej istnieje i znajduje się w stanie pracy awaryjnej (tzn. replika przejęła obciążenie z oryginalnej maszyny wirtualnej).
  • Oryginalna wirtualna maszyna źródłowa istnieje lub określono nową lokalizację.

Powrót awaryjny można wykonać w trybie produkcyjnym lub w trybie testowym. Zastanówmy się, jak każdy przypadek działa w szczegółach.

Realizacja zwrotu produkcji

Wykonanie powrotu po awarii wiąże się z następującymi punktami:

  • Wyłączanie źródłowej maszyny wirtualnej (jeśli istnieje i jest włączona).
  • Tworzenie ochronnej migawki źródłowej maszyny wirtualnej (jeśli źródłowa maszyna wirtualna jest funkcjonalna). Utworzenie tej migawki pozwala przywrócić stan przed awarią źródłowej maszyny wirtualnej w przypadku, gdy niepowodzenie powrotu nie może być wykonane prawidłowo.
  • Uruchamianie replikacji przyrostowej (jeśli pierwotna źródłowa maszyna wirtualna jest w trybie online w miejscu produkcji) lub pełnej replikacji (jeśli maszyna wirtualna jest odzyskiwana do nowej witryny produkcyjnej) z repliki maszyny wirtualnej do źródłowej maszyny wirtualnej jednokrotnie.
  • Wyłączanie repliki VM (opcjonalnie).
  • Ponowne uruchomienie przyrostowej replikacji z repliki VM do źródłowej maszyny wirtualnej. Po tym kroku delta (różnica w danych) między repliką maszyny wirtualnej a źródłową maszyną wirtualną powinna być znacznie mniejsza.
  • Łączenie oryginalnej wirtualnej maszyny wirtualnej z nową siecią za pomocą mapowania sieciowego (opcjonalnie).
  • Modyfikowanie statycznego adresu IP oryginalnej źródłowej maszyny wirtualnej za pomocą Re-IP (opcjonalnie).
  • Włączanie oryginalnej wirtualnej maszyny wirtualnej.

Po zakończeniu powrotu po awarii następuje czyszczenie. Algorytm czyszczenia różni się w zależności od wyniku operacji powrotu po awarii.

Oczyszczanie po pomyślnym przełączeniu awaryjnym

Aby wykonać czyszczenie po pomyślnym uruchomieniu, należy wykonać trzy kroki:

  • Ochronna migawka jest usuwana z oryginalnej źródłowej maszyny wirtualnej.
  • Zadanie replikacji jest rekonfigurowane, aby użyć nowo utworzonej maszyny wirtualnej podstawowej (źródłowej) zamiast starej (opcjonalnie, dotyczy sytuacji, w której nie powiodło się przejście na nową maszynę wirtualną).
  • Przełączanie repliki maszyny wirtualnej ze stanu przełączenia awaryjnego (operacyjnego) na stan normalny.

Po pomyślnej operacji powrotu po awarii zarówno źródłowa maszyna wirtualna, jak i replika maszyny wirtualnej istnieją w normalnych stanach.

Czyszczenie po nieudanym powrocie po awarii

Jeśli operacja powrotu po awarii nie zostanie pomyślnie wykonana, z dowolnego powodu, wykonywane są trzy inne kroki w celu przywrócenia stanu środowiska do stanu sprzed powrotu po awarii:

  • Przywracanie źródłowej maszyny wirtualnej do utworzonej migawki ochronnej.
  • Usuwanie ochronnej migawki ze źródłowej maszyny wirtualnej.

Ponowne włączanie repliki VM.

Testowy powrót po awarii

Testowanie po awarii jest wykonywane po uruchomieniu zadania Site Recovery, które obejmuje działanie powrotu po awarii w trybie testowym ręcznie lub gdy zadanie odzyskiwania lokacji działa zgodnie z harmonogramem. Procedura testowego powrotu awaryjnego różni się od procedury powrotu po awarii. Po ponownym uruchomieniu testu wszystkie zmiany w środowisku wirtualnym wykonane przez działanie powrotu po awarii są przywracane do stanu sprzed powrotu po awarii.

Procedura testowego powrotu awaryjnego wygląda następująco:

  • Wyłączanie oryginalnej wirtualnej maszyny wirtualnej (jeśli jest funkcjonalna i włączona).
  • Tworzenie ochronnej migawki oryginalnej wirtualnej maszyny wirtualnej (jeśli jest funkcjonalna).
  • Uruchamianie replikacji przyrostowej (jeśli oryginalna wirtualna maszyna źródłowa istnieje) lub pełna replikacja z repliki maszyny wirtualnej do nowej wirtualnej maszyny źródłowej.
  • Podłączanie źródłowej maszyny wirtualnej do odizolowanej sieci (opcjonalnie).
  • Modyfikowanie statycznego adresu IP źródłowej maszyny wirtualnej (opcjonalnie).
  • Włączanie źródłowej maszyny wirtualnej.

Jak widać, podczas testowego powrotu po awarii replika maszyny wirtualnej służy do obsługi obciążeń roboczych i nie jest wyłączona, co kontrastuje z procedurą powrotu po awarii produkcji. Replikacja z repliki VM do oryginalnej maszyny wirtualnej VM (lub nowej wirtualnej maszyny produkcyjnej) jest wykonywana raz, a nie dwa razy, ponieważ jest to wystarczające do celów testowych. W takim przypadku źródłowa maszyna wirtualna może zostać podłączona do odizolowanej sieci, tak aby nie było żadnych zakłóceń w środowisku produkcyjnym.

Testowe czyszczenie po powrocie po awarii

Testowe czyszczenie po powrocie po awarii nieznacznie różni się od czyszczenia po powrocie po awarii.

Jeśli źródłowa maszyna wirtualna nie istniała przed uruchomieniem testowego powrotu po awarii:

  • Usuwanie źródłowej maszyny wirtualnej.

Jeśli źródłowa maszyna wirtualna istniała już przed uruchomieniem testowego powrotu po awarii:

  • Przywracanie źródłowej maszyny wirtualnej do jej stanu po zrobieniu ochronnej migawki.
  • Włączanie źródłowej maszyny wirtualnej (jeśli była wyłączona).

Usuwanie ochronnej migawki ze źródłowej maszyny wirtualnej.

Przygotowanie do powrotu po awarii

Najpierw należy utworzyć zadanie przywracania lokalizacji obejmujące działania przełączania awaryjnego. Proces ten został szczegółowo opisany w poprzednim artykule z serii Site Recovery. Zadanie replikacji i replika maszyny wirtualnej są wymagane do wykonania przełączania awaryjnego. Zadanie przywracania lokalizacji musi zawierać działanie przełączania awaryjnego w celu wykonania powrotu po awarii. Repliki VM muszą znajdować się w stanie przełączania awaryjnego; w związku z tym można wykonać procedurę powrotu po zakończeniu przełączania awaryjnego. Kiedy wszystkie problemy spowodowane przez katastrofę zostaną rozwiązane w miejscu produkcji, możemy przygotować się na powrót do źródłowych maszyn wirtualnych.

Uruchomienie powrotu po awarii

Wykorzystajmy przykład instruktażowy, jak wykonać powrót po awarii przy pomocy NAKIVO Backup & Replication. Najpierw upewniamy sięę, że przełączanie awaryjne zostało uruchomione jako część zadania Site Recovery (powinno to już zostać utworzone).

Następnie tworzymy nowe zadanie Site Recovery; akcje powrotu awaryjnego mogą zostać włączone do tego zadania. Na stronie głównej interfejsu sieciowego NAKIVO Backup & Replication klikamy „Utwórz> Site recovery job”

Uruchomiony zostanie Kreator nowego zadania Site Recovery.

1. Działania. W lewym panelu interfejsu „Actions” klikamy opcję „Failback VMware VMs „(platforma VMware jest rozważana w tym przykładzie, ale można również obsługiwać funkcję powrotu po awarii tak samo łatwo w innych środowiskach – Hyper-V lub instancji EC2).

Wybieramy repliki VM, do których ma zostać zastosowana operacja przełączania awaryjnego. Klikamy „Następny”.

Wybieramy lokalizację powrotu po awarii – może to być oryginalna witryna produkcyjna lub nowa lokalizacja. Klikamy „Następny”.

Wybieramy opcje pracy. Zaznaczamy pole wyboru „Wyłączaj repliki VM”, jeśli to konieczne. Klikamy „Zapisz”, gdy będziemy gotowi do kontynuowania.

Po dodaniu akcji powrotu po awarii zadanie przywracania lokalizacji wygląda następująco (zrzut ekranu poniżej). Klikamy „Następny”.

  1. Sieci. Zaznaczamy pole wyboru, jeśli chcemy włączyć mapowanie sieciowe dla tego zadania. Klikamy „Następny”.
  1. Re-IP. Zaznaczamy pole wyboru, jeśli chcemy włączyć Re-IP dla tego zadania. Klikamy „Następny”.
  1. Harmonogram testów. Konfigurujemy opcje planowania, a następnie klikamy przycisk „Dalej”.
  1. Opcje. Określamy opcje zadania odzyskiwania lokalizacji i wprowadzamy nazwę zadania. Klikamy przycisk „Zakończ”, aby sfinalizować tworzenie nowego zadania przywracania lokalizacji z funkcją powrotu po awarii.

Teraz możemy uruchomić zadanie Site Recovery, aby wykonać awarię maszyny wirtualnej: po prostu klikamy prawym przyciskiem myszy nazwę zadania Site Recovery, wybieramy „Uruchom zadanie” i wybieramy „Przetestuj zadanie przywracania lokalizacji” lub „Uruchom zadanie odzyskiwania lokalizacji” zgodnie z potrzebami.

Wniosek

Powrót po awarii jest krytycznie ważną czynnością dla większości przepływów pracy odzyskiwania lokalizacji. Wykonuje się go w celu przywrócenia obciążeń do miejsca produkcji, przenosząc zaktualizowane dane z replik VM, które zostały użyte do odzyskiwania po awarii z powrotem do oryginalnych maszyn wirtualnych (lub do nowej maszyny wirtualnej w bardziej stałej lokalizacji). Funkcja powrotu po awarii pozwala zachować bieżące dane maszyny wirtualnej, zautomatyzować proces przesyłania danych i zminimalizować przestoje podczas migracji z witryny DR do miejsca produkcji.

Ten artykuł kończy naszą serię dotyczącą funkcji Site Recovery w NAKIVO Backup & Replication.  Jest to Złożona, ale przyjaznna dla użytkownika funkcja, dzięki której można elastycznie wdrożyć plan odzyskiwania po awarii i chronić środowisko wirtualne przed katastrofami.

Kornelia Szlósarczyk

Site Recovery w NAKIVO Backup & Replication Część 5: Przełączanie awaryjne

W poprzednich artykułach z serii o Site Recovery analizowaliśmy planowanie przepływów pracy odzyskiwania lokalizacji, tworzenie zadań Site Recovery z operacjami przełączania awaryjnego oraz testowanie tych zadań. Działania przełączania awaryjnego są integralną częścią większości zadań związanych z odzyskiwaniem lokalizacji. Dzisiejszy artykuł zawiera opis działania przełączania awaryjnego, w tym sposób pracy awaryjnej, rodzaje przełączania awaryjnego i wymagania dotyczące przełączania awaryjnego. Zawiera się w nim również instrukcja konfiguracji i uruchamiania pracy awaryjnej w ramach zadania Site Recovery w NAKIVO Backup & Replication.

Co to jest przełączanie awaryjne?

W kontekście środowisk zwirtualizowanych przełączanie awaryjne jest procesem przełączania się z wirtualnej maszyny źródłowej (produkcyjnej) na replikę maszyny wirtualnej w celu przenoszenia obciążeń. Replika maszyny wirtualnej to identyczna kopia źródłowej maszyny wirtualnej w odpowiednim momencie. Przełączanie awaryjne pozwala uzyskać wysoką dostępność, co jest cechą opisującą czas pracy maszyn wirtualnych jako procent.

Źródłowa maszyna wirtualna znajduje się w miejscu produkcji, podczas gdy replika maszyny wirtualnej jest często umieszczona w geograficznie oddzielnej lokalizacji odzyskiwania po awarii (DR). Przełączanie awaryjne jest trybem pracy, który sprawia, że ​​systemy o znaczeniu krytycznym są wysoce dostępne dzięki redundancji zapewnianej przez repliki VM.

Rodzaje pracy awaryjnej

Istnieją trzy typy przełączania awaryjnego: zaplanowane przełączanie awaryjne, testowe przełączanie awaryjne i awaryjne przełączanie awaryjne. Przyjrzyjmy się każdemu bardziej szczegółowo.

Zaplanowane przełączanie awaryjne – służy do przełączania obciążeń roboczych na replikę maszyny wirtualnej z zerową utratą danych. Tego typu przełączanie awaryjne może być używane proaktywnie, gdy potencjalna katastrofa jest przewidywana lub podejrzewana – na przykład firma elektryczna powiadomiła nas o planowanej awarii zasilania w biurze głównym w poniedziałek lub prognoza pogody ostrzega przed zagrożeniem powodziowym. Replikacja źródłowej maszyny wirtualnej jest wykonywana bezpośrednio przed planowanym przełączeniem awaryjnym w celu utworzenia nowego punktu przywracania.

Testowe przełączanie awaryjne jest używane w celu zapewnienia, że ​​maszyny wirtualne mogą się zepsuć i migracja zadań zakończyła się pomyślnie. Testowe przełączanie awaryjne działa podobnie do planowanego przełączania awaryjnego. Przeprowadzając testowe przełączanie awaryjne, możemy wyszkolić swoich pracowników do wykonywania operacji odzyskiwania po awarii, sprawdzić, czy plan odzyskiwania lokalizacji jest możliwy do wykonania i sprawdzić, ile czasu potrzeba na przeprowadzenie przełączenia awaryjnego.

Awaryjne przełączanie awaryjne jest używane do szybkiego przełączania obciążeń ze źródłowej maszyny wirtualnej na replikę maszyny wirtualnej, jeśli źródłowa maszyna wirtualna przestanie działać. Brak transferu danych. Replikacja nie jest wykonywana w celu dodania nowego punktu przywracania podczas inicjowania awaryjnego przełączania awaryjnego, ponieważ dane na źródłowej maszynie wirtualnej mogą być niespójne w tym momencie (lub maszyna wirtualna może być całkowicie nieosiągalna).

Uruchomienie pracy awaryjnej

Zastanówmy się, jak wykonać przełączanie awaryjne w ramach zadania Site Recovery. Aby utworzyć działanie przełączania awaryjnego, należy najpierw utworzyć zadanie przywracania lokalizacji. Ze strony głównej NAKIVO Backup & Replication klikamy „Create> Site recovery job”.

  1. Działania.W lewym panelu pierwszego ekranu Kreatora Site Recovery można wyświetlić listę czynności, które można uwzględnić w przepływie pracy. Klikamy „Failover VMware VMs”. (W obecnym przykładzie używana jest platforma wirtualizacji VMware, podobnie można wybrać awaryjne maszyny wirtualne Hyper-V lub AWS EC2, jeśli używane jest jedno z tych wirtualnych środowisk.)

Zostanie wyświetlony ekran konfiguracji dla działania przełączania awaryjnego. Z lewego panelu wybieramy replikę maszyny wirtualnej z odpowiedniego zadania replikacji. Ta replika ma być używana do przełączania awaryjnego. Na tym etapie możemy wybrać wiele replik VM. W prawym panelu wybieramy punkt przywracania. Ostatni punkt odzyskiwania jest używany domyślnie. Naciskamy „Next” by kontynuować.

Wybieramy opcje akcji. W razie potrzeby możemy zaznaczyć pole wyboru „Wyłącz zasilanie maszyn wirtualnych” i klikamy przycisk „Zapisz”.

Możemy wykonywać akcje więcej niż raz podczas tworzenia przepływów pracy odzyskiwania lokalizacji. W ten sposób można dodać kolejne działanie przełączania awaryjnego w tym zadaniu funkcji Site Recovery w celu wykonania przełączenia awaryjnego innej maszyny wirtualnej (lub zestawu maszyn wirtualnych) po tych, które zdefiniowano w pierwszym działaniu awaryjnym. Klikamy ponownie „Failover VMware VMs”.

Wybieramy replikę maszyny wirtualnej do przełączania awaryjnego, tak jak w przypadku pierwszego działania awaryjnego. Klikamy „Następny”.

Podobnie jak w przypadku pierwszej akcji, wybieramy opcję przełączania awaryjnego i klikamy przycisk „Dalej”.

To zadanie Site Recovery zawiera teraz dwie akcje. Klikamy „Dalej”, aby kontynuować.

  1. Zaznaczamy pole wyboru „Włącz mapowanie sieciowe”, jeśli mamy różne sieci VM w miejscu produkcji i lokalizacji odzyskiwania po awarii (DR). Klikamy „Dalej”, aby kontynuować.
  2. Re-IP. Zaznaczamy pole wyboru „Włącz Re-IP”, jeśli różne adresy są używane w sieciach IP w naszej lokalizacji produkcyjnej i DR. Klikamy „Następny”.
  3. Harmonogram testów. Konfigurujemy opcję planowania, jeśli chcemy automatycznie przeprowadzać okresowe testy zadań przywracania lokalizacji. Klikamy „Następny”.
  4. Opcje. Ustawiamy opcje zadań. Wprowadzamy nazwę dla nowego zadania (w tym przykładzie – zadanie przywracania w miejscu pracy – przełączanie awaryjne). Definiujemy cel czasu przywracania do celów testowych. Klikamy przycisk „Zakończ”, aby sfinalizować konfigurację zadania Site Recovery.

Teraz możemy użyć zadania Site Recovery, jeśli wystąpi awaria i wykonać przełączenie awaryjne na repliki maszyny wirtualnej.

Dodatkowe zabezpieczenie środowiska

Kiedy maszyny wirtualne ulegają awarii, a obciążenia są migrowane do witryny DR, należy chronić maszyny wirtualne działające w witrynie DR. Dzieje się tak, ponieważ jeśli replika VM uruchomiona po przełączeniu awaryjnym zawiedzie, nie będzie można szybko przywrócić tych danych i obciążeń. Funkcja Site Recovery pozwala na ponowne zabezpieczenie środowiska wirtualnego natychmiast po przywróceniu systemu po awarii.

Aby ponownie zabezpieczyć maszyny wirtualne działające w witrynie DR, należy najpierw zreplikować te maszyny wirtualne w inne bezpieczne miejsce. W ten sposób, jeśli maszyna wirtualna uruchomiona w witrynie DR zawiedzie, możesz szybko przejść do nowej repliki VM. Funkcja Site Recovery umożliwia dodanie działania zadania ”Run job” w istniejącym zadaniu Site Recovery  za pomocą którego można dodać istniejące zadanie replikacji. W ten sposób można skonfigurować zadanie przywracania lokalizacji, tak że po zakończeniu przełączania maszyny wirtualnej replikacja maszyn wirtualnych uruchomionych po przełączeniu awaryjnym jest wykonywana automatycznie, zapewniając odpowiedni poziom ochrony.

Oto przykładowy sposób ponownego zabezpieczenia maszyn wirtualnych za pomocą zadania Site Recovery.

Tworzenie zadania replikacji

Na stronie głównej interfejsu WWW NAKIVO Backup & Replication klikamy opcję „Utwórz> Zadanie replikacji VMware vSphere”.

  1. Wybieramy repliki VM, które są używane jako cele przełączania awaryjnego w witrynie DR, zaznaczając pola obok ich nazw. W bieżącym przykładzie wybraliśmy dwie VM, które zostały użyte do obsługi obciążenia po przełączeniu awaryjnym w zadaniu Site Recovery opisanym powyżej. Klikamy „Następny”.
  1. Miejsce docelowe. Wybieramy kontener docelowy (host lub klaster), na którym ma zostać uruchomiona maszyna wirtualna, oraz magazyn danych, w którym można umieścić pliki maszyny wirtualnej. Na potrzeby tego przykładu używamy hosta ESXi 10.10.10.51 i datastore1 (który jest dołączony do tego hosta ESXi). Klikamy „Następny”.
  1. Zaznaczamy pole wyboru „Włącz mapowanie sieciowe” – jeśli mamy różne sieci VM w witrynie źródłowej (witryna DR, w której działają maszyny wirtualne, które przeszły przez awarię) i nowa witryna docelowa. Klikamy „Następny”.
  2. Re-IP. Zaznaczamy pole wyboru „Włącz Re-IP”, jeśli adresy używane w sieciach różnią się między witryną źródłową (naszą witryną DR) a nową lokalizacją docelową. Klikamy „Następny”.
  3. Konfigurujemy harmonogram, jeśli chcemy okresowo uruchamiać zadanie replikacji. Klikamy „Następny”.
  4. Definiujemy ustawienia przechowywania. Klikamy „Następny”.
  5. Konfigurujemy opcje zadania replikacji, w tym wprowadzenie nazwy zadania. W tym przykładzie zadanie replikacji nosi nazwę „Vmware replication job Re-protection”. Klikamy przycisk „Zakończ”, aby sfinalizować tworzenie zadania replikacji.

Edytowanie zadania Site Recovery

Po utworzeniu nowego zadania replikacji można dodać działanie „Uruchom zadanie” do zadania Site Recovery. W ten sposób można automatycznie replikować maszyny wirtualne działające w witrynie DR. Ponieważ pierwotne produkcyjne maszyny wirtualne są teraz w trybie offline, nasze repliki w witrynie DR są teraz jedynymi funkcjonalnymi kopiami, więc jest to ważne dla niezawodnej ochrony danych.

Na stronie głównej interfejsu WWW klikamy prawym przyciskiem myszy nazwę ostatnio utworzonego zadania przywracania lokalizacji. Klikamy „Edytuj” w menu kontekstowym.

Możemy zobaczyć teraz dwie akcje przełączania awaryjnego dodane do zadania Site Recovery opisane wcześniej. Szukamy i klikamy opcję „Uruchom zadania” z listy działań znajdującej się w lewym panelu ekranu  „Działania”  Site Recovery.

Wybieramy odpowiednie zadanie replikacji z listy zadań (tej, którą właśnie utworzyliśmy). Wybieramy opcje akcji jak zwykle i klikamy „Zapisz”.

Dodajemy akcję „Czekaj” między operacją przełączania awaryjnego i zadaniem replikacji. To daje replice maszyny wirtualnej trochę czasu na uruchomienie i załadowanie systemu operacyjnego (nie można zreplikować wyłączonej maszyny wirtualnej). Z listy „Czynności” na lewym panelu klikamy „Czekaj”.

Wybieramy czas oczekiwania – do tych celów wystarcza 5 minut. Wybieramy opcje akcji i klikamy „Zapisz”.

Po dodaniu akcji jest ona dołączana na końcu listy akcji. Klikamy „Przenieś w górę” i przenosimy akcję „Czekaj” z czwartej pozycji na trzecią – musi to nastąpić przed replikacją.

Teraz działania są uporządkowane w odpowiedniej kolejności.

Na koniec zadanie Site Recovery jest gotowe do użycia w celu wykonania przełączania awaryjnego maszyny wirtualnej i automatycznego ponownego zabezpieczenia replik VM używanych do przełączania awaryjnego. Klikamy prawym przyciskiem myszy nazwę zadania Site Recovery na stronie głównej i klikamy polecenie „Uruchom zadanie” w menu kontekstowym.

Wniosek

Będąc ważną częścią odzyskiwania lokalizacji, przejście awaryjne maszyny wirtualnej do repliki to proces przełączania z uszkodzonej źródłowej maszyny wirtualnej na replikę maszyny wirtualnej, która jest dokładną kopią źródłowej maszyny wirtualnej w odpowiednim punkcie czasowym.

Zaawansowana funkcja Site Recovery dodana do NAKIVO Backup & Replication w wersji 8.0 zawiera czynność przełączania awaryjnego. Ta elastyczna funkcja umożliwia tworzenie niestandardowych zadań Site Recovery z różnymi kombinacjami działań w celu ochrony środowiska produkcyjnego. Można również skonfigurować te same zadania do automatycznego ponownego zabezpieczenia środowiska DR po awarii maszyn wirtualnych w miejscu produkcji.

Site Recovery w NAKIVO Backup & Replication Część 4: Przeprowadzanie testowania odzyskiwania witryny

Poprzedni artykuł z naszej serii o odzyskiwaniu lokalizacji wyjaśnił utworzenie logicznego procesu odzyskiwania danych po awarii i podał instrukcję konfiguracji zadania przywracania lokalizacji. Po utworzeniu planu przywracania odzyskiwania danych po awarii i skonfigurowaniu odpowiednich zadań przywracania lokalizacji nie możemy zapomnieć o ich przetestowaniu. Testowanie pomaga upewnić się, że jesteśmy gotowi do odzyskania po wystąpieniu awarii i że wszystkie wybrane komponenty można odzyskać pomyślnie w odpowiednim czasie. NAKIVO Backup & Replication zapewnia opcję testowania dla zadań Site Recovery, tj. można uruchomić dowolne zadanie Site Recovery w trybie testowym.

Dlaczego potrzebujemy testowania?

Testowanie zadania Site Recovery jest ważną częścią przygotowywania do odzyskiwania po awarii. Zwiększa prawdopodobieństwo szybkiego i pomyślnego powrotu w przypadku katastrofy.

Testy są potrzebne następujących powodów:

  • Aby upewnić się, że wszystko można odzyskać pomyślnie. Załóżmy, że opracowaliśmy plan odzyskiwania danych po awarii, a następnie odpowiednio skonfigurowaliśmy zadanie przywracania lokalizacji, ale go nie przetestowaliśmy. Może to spowodować następujący scenariusz: gdy nastąpi awaria i nadejdzie czas na uruchomienie zadania odzyskiwania lokalizacji, zadanie się nie powiedzie i nie będzie można odzyskać niektórych maszyn wirtualnych. Wymagałoby to znacznie więcej czasu na przywrócenie funkcjonalności infrastruktury wirtualnej (np. konieczne może być przywrócenie kopii zapasowych i ręczne wdrożenie wprowadzonych zmian). Kiedy testujemy swój plan Site Recovery i odkryjemy, że coś idzie nie tak, możemy rozwiązać problemy, zanim spowodują one poważne problemy w prawdziwym scenariuszu kryzysu.

Aby upewnić się, że wartości RTO mogą zostać spełnione. Zadanie Site Recovery może zakończyć się pomyślnie, ale w czasie przekraczającym wartość docelową RTO (czas odzyskiwania). Może to mieć negatywny wpływ na procesy biznesowe. Testowanie zadania Site Recovery pozwala sprawdzić, czy obciążenia mogą zostać odzyskane w odpowiednich RTO. Test odzyskiwania lokalizacji można uruchomić ręcznie na żądanie lub automatycznie, zgodnie z harmonogramem, co sprawia, że ​​proces jest bezbolesny i oszczędza czas.

Różnice między awaryjnym testowaniem, a awaryjnym działaniem produkcyjnym

Działanie przełączania awaryjnego ma kluczowe znaczenie dla większości przepływów pracy odzyskiwania lokalizacji. Mechanizm wykonywania pracy awaryjnej różni się w zależności od tego, czy zadanie Site Recovery jest uruchamiane w trybie testowym czy produkcyjnym. Podział kroków dla każdego trybu pokazano w poniższej tabeli.

Jak widać, drugi i trzeci punkt różnią się między produkcyjnymi i testowymi przepływami pracy. Wynika to z faktu, że można uruchomić replikację ze źródłowej maszyny wirtualnej w trybie testowym podczas pracy maszyny źródłowej. W większości przypadków, gdy nastąpi awaria, źródłowa maszyna wirtualna przestaje działać, a zatem nie można wykonać replikacji. Sieci połączeń VM można zdefiniować osobno w opcjach mapowania sieciowego dla trybu produkcji i trybu testowego podczas konfigurowania zadania przywracania lokalizacji (patrz poprzedni artykuł na blogu).

Testowanie pracy awaryjnej odbywa się po wykonaniu zadania Site Recovery w trybie testowym. Replika maszyny wirtualnej jest wyłączana i przywracana do stanu sprzed przejścia awaryjnego za pośrednictwem migawki (migawka repliki maszyny wirtualnej jest wykonywana przed wykonaniem czynności przełączania awaryjnego). Replika jest następnie przełączana ze stanu przełączania awaryjnego do stanu normalnego, a replikacja z obiektu źródłowego do repliki jest ponownie włączana.

Najlepsze praktyki

W celu przeprowadzenia skutecznego testowania zadania Site Recovery należy emulować różne punkty awarii i regularnie sprawdzać plan odzyskiwania danych po awarii.

Emulacja różnych punktów awarii do testowania

Należy symulować sytuacje, w których zawodzą różne komponenty naszego środowiska. Można emulować na przykład awarię sieci, awarię różnych maszyn wirtualnych, awarię wszystkich hostów ESXi, awarię serwera vCenter lub awarię jednego lub więcej urządzeń pamięci masowej. Sprawdzamy, czy nasz plan przywracania po awarii jest możliwy do zrealizowania dla różnych sytuacji, które mogą powstać w racjonalny sposób. Jeśli nie, tworzymy kolejny plan przywracania po awarii, aby pasował do konkretnego scenariusza, który nie jest uwzględniany. W ten sposób możemy mieć plany przywracania po awarii dostosowane do określonych sytuacji.

Regularne testowanie planu odzyskiwania lokalizacji

Infrastruktura może się zmieniać w czasie – niektóre maszyny wirtualne można dodać, niektóre role można migrować z jednej maszyny wirtualnej na drugą, a konfiguracja sieci może zostać zmieniona. Powinnismy regularnie testować plan przywracania lokalizacji, aby sprawdzić, czy działa w twoim obecnym stanie i czy spełnia określone przez nas wartości RTO. Jeśli coś pójdzie nie tak należy go odpowiednio zmodyfikować.

Jak przetestować zadanie Site Recovery w NAKIVO Backup&Replication

Po zapoznaniu się z teorią testowania odzyskiwania lokalizacji można przystąpić do testowania zadania Site Recovery w oprogramowaniu NAKIVO Backup & Replication. Pokrótce omówimy kluczowe punkty funkcjonalności testowania wbudowanej w produkt.

Sprawdzanie działań zawartych w testowaniu

Przejrzyjmy logikę naszych działań dodanych do zadania przywracania witryny. Sprawdzamy, czy działania są uporządkowane w odpowiedniej kolejności i upewniamy się, że nie mogą utworzyć nieskończonej pętli. Możemy edytować opcje zadania przywracania lokalizacji, gdy zadanie nie jest uruchomione: zmieniać kolejność działań, dodawać akcje, usuwać działania lub edytować opcje akcji, jeśli to konieczne.

Sprawdzanie sieci

Sprawdzamy, czy nasza sieć działa poprawnie. Połączenie VPN może być używane między witryną produkcyjną, a witryną odzyskiwania po awarii (DR), ale tego połączenia nie można okresowo rozłączać w stanie normalnym. Sieć na stronie DR musi również działać bez zakłóceń. Sprawdzamy ustawienia Network Mapping i Re-IP, które zostały użyte do skonfigurowania przełączania awaryjnego i powrotu po awarii. Jeśli maszyna wirtualna jest skonfigurowana dla niepoprawnej sieci, połączenie sieciowe może nie zostać ustanowione. To samo dotyczy ustawień IP.

Ustawianie harmonogramu testów

Testowanie zadania Site Recovery można zaplanować w opcjach planowania zadania Site Recovery. Otwieramy interfejs WWW instancji NAKIVO Backup & Replication. W lewym panelu strony głównej klikamy prawym przyciskiem myszy nazwę swojego zadania i klikamy „Edytuj” w menu kontekstowym. W tym menu możemy także zmienić nazwę, wyłączyć, usunąć lub uruchomić zadanie.

Klikamy „Testuj harmonogram” i określamy ustawienia harmonogramu. W przykładzie wykorzystanym dotego artykułu, test pracy Site Recovery będzie uruchamiany w każdy dzień roboczy o 2:00.

Uruchomienie testu na żądanie

Zadanie Site Recovery można uruchomić w trybie testowym ręcznie. Wystarczy przejść do strony głównej produktu, wybrać zadanie odzyskiwania lokalizacji według nazwy, kliknąć „Uruchom zadanie”, a następnie kliknąć „Przetestuj zadanie Site Recovery”.

Ustawiamy RTO i klikamy „Testuj”.

Test zadania Site Recovery jest już uruchomiony. Możemy zobaczyć całkowity pasek postępu i pasek postępu dla każdej działającej akcji. Czekamy na zakończenie testu.

Sprawdzanie wyników testu

Po zakończeniu testu możemy sprawdzić wyniki. Klikamy nazwę testowanego zadania, dla którego chcemy sprawdzić wyniki. W tym przypadku nasze zadanie przywracania lokalizacji zostało pomyślnie zakończone. Możemy zobaczyć szczegóły w sekcji „Wydarzenia”.

Na poniższym zrzucie ekranu widać również, że inny test zadania Site Recovery nie powiódł się. Czerwona ikona wykrzyknika wskazuje na niepowodzenie. Możemy zapoznać się z sekcją „Zdarzenia”, aby uzyskać szczegółowe informacje o źródle awarii. W tym przypadku czerwony kolor wskazuje, że nie można wysłać e-maila. Sprawdzamy zatem ustawienia sieci, konfigurację działania „Wyślij wiadomość e-mail” i sprawdzamy, czy adres grupy e-mail jest poprawny. Naprawiamy problemy po ich zidentyfikowaniu, a następnie próbujemy ponownie uruchomić test.

Wniosek

Testowanie zadania Site Recovery jest ważnym procesem, który pomaga zapewnić, że plan odzyskiwania lokalizacji działa. Testowanie pozwala również określić, czy maszyny wirtualne można odzyskać wystarczająco szybko, aby spełnić wartości RTO. Zaleca się regularne testowanie odzyskiwania danych po awarii aby upewnić się, że nie wystąpią żadne niespodzianki, gdy nastąpi katastrofa i że nasze środowisko wirtualne może zostać odzyskane zgodnie z planem.