Zarządzanie ciągłością biznesową w rozwiązaniach firmy ......SharePoint, dla kolejnych SAP, Oracle lub poczta Exchange, a dla pozostałych jeszcze inny system biznesowy. Wyniki

Zarządzanie ciągłością biznesową w rozwiązaniach firmy

Microsoft

2

CHMURA PUBLICZNA MICROSOFT

Rok 2014. okazał się być przełomowym na rynku rozwiązań sieci bezprzewodowych. Wszystko to za sprawą zatwierdzenia przez organizację IEEE nowego standardu 802.11ac, który szybko zyskuje na znaczeniu wśród klientów indywidualnych i korporacyjnych. Namacalnym dowodem potwierdzającym tę tezę jest zauważalny wzrost wolumenu sprzedaży urządzeń obsługujących tę technologię.

Zarządzanie ciągłością biznesową w rozwiązaniach firmy Microsoft

które mają wpływ na funkcjonowanie biznesu, a przynajmniej wiele z nich chciałoby takie zasady i narzędzia mieć wdrożone u siebie.

Krytyczne aplikacje biznesoweCo w praktyce oznacza zachowanie ciągłości biznesowej i czym są tak zwane krytyczne aplikacje biznesowe? To zależy od firmy. Dla jednych krytyczną aplikacją będzie Microsoft SharePoint, dla kolejnych SAP, Oracle lub poczta Exchange, a dla pozostałych jeszcze inny system biznesowy. Wyniki badania IDC „QuickPoll Survey 2013” potwierdzają, że aplikacja krytyczna z perspektywy danej firmy wcale nie musi być tak ważna dla innej. Większość osób wymienia SAP jako krytyczny system biznesowy przedsiębiorstwa, ale jest też grupa respondentów (co prawda w mniej-szości, ale zauważalnej) mających odmienne zdanie, przekonanych o tym, że chwilowa dys-funkcja tej aplikacji nie wywoła negatywnych skutków dla organizacji. To samo dotyczy do-stępności serwera Exchange. Wśród ankieto-

Tematem artykułu z cyklu „Chmura publicz-na” jest zarządzanie ciągłością biznesową na bazie rozwiązań firmy Microsoft. Na kolejnych stronach omawiamy, jakie wyzwania stają przed przedsiębiorstwami w kontekście ko-nieczności zapewnienia nadmiarowych, nieza-wodnych systemów IT centrów przetwarzania danych oraz jak technologie Microsoft mogą pomóc w realizacji tych celów.

Zacznijmy od przewrotnego pytania: czy współczesna firma może funkcjonować w przypadku awarii serwerowni? Odpowiedź wydaje się oczywista: zdecydowanie nie. COMPAREX to międzynarodowa korporacja, w której większość obszarów IT realizowanych jest centralnie, a duża część z nich objęta jest odpowiednimi mechanizmami zapewnienia ciągłości biznesowej. Dzięki temu nie boryka-my się z przerwami w dostępie do usług IT.

W tym kontekście można przypuszczać, że większość firm stosuje rozwiązania z zakre-su zapewnienia nieprzerwanego dostępu do usług i danych w systemach informatycznych,

PROWADZĄCY

Michał Jędrzejczak, COMPAREX, architekt i konsultant projektów w obszarze technologii

Microsoft, w tym rozwiązań chmurowych.

Waldemar Skrzypiec, Microsoft, zajmuje się technologiami

chmurowymi, odpowiedzialny za platformę Microsoft Azure.

3


wanych znalazły się osoby, dla których poczta elektroniczna stanowi podstawowe narzędzie pracy, i takie, które nie uważają tej usługi za krytyczną dla funkcjonowania ich biznesu.

Gwałtowny przyrost danychGłównym powodem problemów, a raczej wyzwań stawianych przed działami IT w za-kresie zachowania ciągłości biznesowej jest gwałtowny przyrost danych. Zwiększająca się ilość danych prowadzi do powstawania coraz większej liczby powiązań między nimi, a to przy braku zasad i narzędzi zapewnienia ciągłości działania nierzadko skutkuje bra-kiem możliwości odtworzenia tych danych w sytuacji awaryjnej. Z uwagi na fakt, że danych w przedsiębiorstwie jest coraz wię-cej, nie wszystkie z nich mogą zostać objęte wymaganą ochroną, a jeśli już zostaną, to na zbyt krótki czas.

Wzrost ilości danych w przedsiębiorstwie przekłada się bezpośrednio na zwiększe-nie czasochłonności zarządzania nimi. Przykładowo, czas wykonania kopii zapaso-wej na taśmie magnetycznej zależy wprost od liczby danych, które chcemy objąć ochroną. Dotarcie do potrzebnej taśmy i odtworzenie

z niej kopii zajmie więcej czasu, jeśli w organi-zacji przechowywanych i przetwarzanych jest coraz większa liczba danych.

Gwałtowny przyrost danych może prowa-dzić do sytuacji, w której co prawda mamy zaimplementowane lub dopiero zamierzamy wdrażać rozwiązania klasy disaster recovery (DR), ale nie są one testowane. W tym obsza-rze można znaleźć przykłady wielu klientów, których plany przywracania systemów po katastrofie na nic się zdały, właśnie z uwagi na brak ich dokładnego testowania w czasie. Oto przykład.

Klient regularnie wykonywał backup bazy danych, ale proces ten nie był uzupełniony o testy przywracania. Kiedy doszło do awarii, okazało się, że firma musi cofnąć stan swoje-go systemu o pół roku. Dane zostały utracone, ponieważ kopie zapasowe były tworzone niewłaściwie, i nie były stosowane procedury testów odtworzeniowych.

Przykład ten pokazuje, jak ważna jest dbałość o kompletność całego rozwiązania backupu, począwszy od identyfikacji źródeł pochodzenia danych, które należy objąć ochroną, nakreślenia obostrzeń i wymagań biznesowych, aż po wdrożenia samego syste-

Przyrost danych prowadzi do:• zwiększenia liczby powiązań,

problemów i pomyłek,

• zbyt dużej ilości danych objętych niewystarczającą ochroną,

• zbyt krótkim przechowywaniem danych,

• zwiększeniem czasochłonności zarządzania danymi,

• nietestowania rozwiązań typu disaster recovery (DR),

• wzrostu kosztów.

4


mu zabezpieczeń oraz procedur dotyczących wykonywania kopii zapasowych i prowadze-nia testów odtworzeniowych. To właśnie testy dają gwarancję, że wdrożone rozwiązanie działa poprawnie, a dane przedsiębiorstwa są dobrze chronione. Niestety, wraz ze wzrostem liczby danych, które należy objąć ochroną, ro-sną koszty wdrożenia i utrzymania tego typu rozwiązań, a więc i wydatki związane z za-pewnieniem ciągłości biznesowej w firmie.

Zarządzanie backupem a ciągłość biznesowaNajważniejszym sposobem na poradzenie so-bie z wyzwaniami, jakie wiążą się z zarządza-niem kopiami zapasowymi jest automatyzacja procesu backupu oraz zwiększenie integracji pomiędzy systemem (aplikacją), który chcemy poddać ochronie, a rozwiązaniami disaster

recovery. Podejście to, oprócz uproszczenia samego procesu backupu, pozwoli na objęcie większej ilości systemów planem przywraca-nia po katastrofie. W idealnym rozwiązaniu zakłada się także wyeliminowanie z procesu backupu taśm magnetycznych, co pozwoli zmniejszyć ilość czasu poświęcanego na za-rządzanie danymi. Kluczową kwestią w kon-tekście zarządzania backupem danych jest wprowadzenie testowalnych rozwiązań, tak abyśmy mogli w dowolnej chwili spróbować odtworzyć środowisko, nie przerywając pracy systemu produkcyjnego. Ostatnim elementem tej strategii jest wybór rozwiązania optymal-nego kosztowo, które spełni wymagania dane-go przedsiębiorstwa.

Transformacja działów ITW tym miejscu postawmy śmiałą tezę, że nie wszystkie obecnie dostępne na rynku rozwią-zania disaster recovery (DR) są przygotowane na zmiany związane z transformacją dzia-łów IT oraz centrów przetwarzania danych. Mówimy tutaj o systemach i technologiach, które swoim zasięgiem muszą objąć fizyczną infrastrukturę klienta oraz rozwiązania chmu-rowe, rozszerzając zakres ochrony o systemy pośrednie, a więc środowiska zwirtualizowane i infrastrukturę chmury hybrydowej.

Microsoft dysponuje rozwiązaniem, które jest w stanie zapewnić ochronę centrum prze-twarzania danych w każdym z tych stanów (infrastruktura fizyczna, fizyczna plus wirtu-alna, chmura hybrydowa, chmura publiczna). Producent ma w ofercie szereg komplementar-nych technologii, pozwalających na wdrażanie

Zarządzanie backupem a ciągłość biznesowa

• automatyzacja,

• zwiększona integracja między aplikacją a rozwiązaniem DR,

• objęcie większej liczby aplikacji systemem DR,

• wyeliminowanie taśm,

• wprowadzenie testowalnych rozwiązań,

• wykorzystanie rozwiązania optymalnego kosztowo.

5


planów zarządzania ciągłością w środowisku Datacenter, przy czym wybór każdej z nich podyktowany jest celami biznesowymi zabez-pieczania danych i ich odtwarzania.

Warto przypomnieć, że czym innym jest wykonywanie kopii zapasowych i archiwizacja danych w celach ich przechowywania w dłuż-szym okresie, np. na potrzeby audytowania systemów finansowo-księgowych, a czym innym wdrożenie scenariusza przywracania po katastrofie (disaster recovery), w którym należy założyć możliwość utraty wszystkich danych w podstawowym centrum przetwarza-nia i konieczność ich szybkiego odtworzenia od zera.

Clustering ServiceOmówienie technologii ochrony systemów rozpoczynamy od rozwiązań stosowanych wewnątrz własnego centrum danych (on premises). Podstawowym rozwiązaniem w tym obszarze jest obecna od dłuższego czasu w systemie Windows Server techno-logia Clustering Service. Z perspektywy infrastruktury zaprojektowanej w modelu Infrastructure as a Service mechanizm ten zapewnia ochronę maszyn wirtualnych w śro-dowisku wirtualizacji Microsoft Hyper-V. Awaria fizycznego komputera (hosta), na którym uruchamiane są maszyny wirtualne, nie prowadzi do dłuższej przerwy w ciągłości działania tych maszyn. Clustering Service automatycznie przenosi instancję wirtualną jako obiekt logiczny na inny, sprawny węzeł klastra, startuje ją, a po chwili wszystkie uruchamiane w niej usługi sieciowe i aplika-cje biznesowe stają się ponownie dostępne dla odbiorców końcowych. Nie można zapo-minać, że jeżeli maszyna fizyczna ulegnie awarii, wszystko, co było w jej pamięci, nagle zniknie. Nie powinno to mieć jednak znacze-nia z perspektywy zapewnienia ciągłości działania biznesowej całej usługi.

Scenariusz ten wykorzystuje się w przy-padku nieplanowanej awarii fizycznego hosta. Sytuacja wygląda odmiennie, kiedy mamy do czynienia z oknem serwisowym i chcemy np. zaktualizować system i ponownie uruchomić serwer wirtualizacji. Technologia Clustering Service umożliwia przeniesienie maszyn wir-tualnych, a więc i działających w nich usługi i aplikacji, na inny węzeł klastra, bez przery-wania ich pracy. W tym przypadku żadne dane nie zostaną utracone.

Przenoszenie maszyn między hostamiClustering Service jest tylko jedną z techno-logii Microsoft, która pozwala na migrację instancji wirtualnych w węzłach bez przerywa-nia pracy. Obecna wersja Hyper-V implemen-tuje dwa rozwiązania: Storage Live Migration i Share Nothing Live Migration, które umożli-wiają przenoszenie maszyn wirtualnych mię-dzy hostami wirtualizacji, bez konieczności wdrażania pełnego klastra z przeznaczoną do tego celu macierzą dyskową. Podejście to jest często stosowane w przypadku konieczności obsłużenia mniejszych obciążeń, np. w od-działach zamiejscowych organizacji (branch offices), gdzie budowanie złożonej infrastruk-tury klastra jest nieuzasadnione finansowo. Innymi słowy, scenariusz ten zakłada migrację maszyn wirtualnych pomiędzy wolno stoją-cymi serwerami, które mogą mieć przypisane wyłącznie lokalne zasoby dyskowe, bez ko-nieczności wdrażania centralnej macierzy. Z drugiej strony administrator korzysta z wszystkich zalet wirtualizacji w zakresie zdalnego manipulowania instancjami wirtu-alnymi, tworzenia zrzutów obrazu maszyny itp. Dzięki mechanizmom replikacji Hyper-V opisane tutaj scenariusze mogą zostać zre-alizowane na pojedynczych serwerach, bez budowania klastra niezawodnościowego.

Guest ClusteringW tym miejscu wróćmy do technologii klastro-wych. Usługa Clustering Service wdrażana jest na poziomie hostów wirtualizacyjnych, a zatem w tym wariancie przełączaniu pod-lega cała maszyna (instanacja) wirtualna. Uzupełnieniem rozwiązania jest mechanizm Guest Clustering. Mamy tutaj do czynienia z tą samą technologią klastrową Windows Server, ale integrowaną wewnątrz instancji wirtual-nych. W ten sposób możemy objąć ochroną różnego rodzaju aplikacje dostosowane do pracy z Clustering Service, np. serwer bazoda-nowy SQL Server, aby zapewnić odporność na awarię na poziomie aplikacji wewnątrz syste-mu gościa.

Innymi słowy, jeśli używamy technolo-gii Clustering Service na poziomie hosta wirtualizacyjnego (dotyczy to wirtualizacji Microsoft i innych producentów), przenie-sienie maszyny gościa, który uległ awarii na inny węzeł w klastrze, nie usuwa de facto przyczyny awarii. Aby rozwiązać problem,

Czym innym jest wykonywa-nie kopii zapasowych i archiwizacja danych w celach ich przechowywa-nia w dłuższym okresie, np. na potrzeby audytowa-nia systemów finansowo--księgowych, a czym innym wdrożenie scenariusza przywracania po katastrofie (disaster recovery).

6


musimy zastosować technologię Guest Clustering, która jest świadoma obciążeń wewnątrz maszyny wirtualnej i pozwala od-zyskać sprawność operacyjną aplikacji, np. na poziomie serwera bazy danych.

Rozwiązania aplikacyjneKolejną grupą technologii, które należy roz-patrywać w kontekście tworzenia systemów wysokiej dostępności, a więc i planów ciągło-ści działania, stanowią różnego rodzaju roz-wiązania aplikacyjne. Przykładem jest usługa katalogowa Microsoft Active Directory – ba-zuje ona na wielu rozproszonych, równorzęd-nych kontrolerach domeny, z których każdy przechowuje własną replikę katalogu. Awaria któregokolwiek z węzłów Active Directory nie powoduje przestojów w dostępie do usługi, bo zadania obsługi klientów przejmują inne, sprawne kontrolery w domenie.

W obszarze serwerów aplikacyjnych Microsoft Exchange i SQL Server mamy do dyspozycji technologie Database Availability Group (DAG) oraz SQL Database Mirroring i AlwaysOn, które umożliwiają wprowadzenie mechanizmów wysokiej dostępności bez-pośrednio na poziomie protokołu aplikacji, w tym przypadku dostępu do bazy danych. Podejście to wymaga, aby aplikacja, na której bazie dostarczamy usługi i dane odbiorcy końcowemu, sama w sobie wspierała mecha-nizmy wysokiej dostępności. Dodajmy, że nie tylko Exchange i SQL Server, ale i wiele innych aplikacji wspiera tego typu technologie.

Migawki maszyn wirtualnychZrzut maszyn wirtualnych (snapshot) na po-ziomie hosta wirtualizacji zapewnia dostęp do starszej wersji danych przechowywanych w pamięci masowej (wersjonowanie), ale w środowisku produkcyjnym migawki powinny być wykorzystywane raczej do wykonywania zadań administracyjnych, np. wgrywania ak-tualizacji systemu, niż jako alternatywa dla specjalnych mechanizmów backupu danych.

Windows Server BackupKolejnym mechanizmem zapewnienia ciągło-ści biznesowej, tym razem stricte związanym z tworzeniem kopii zapasowych, jest narzę-dzie Windows Server Backup wbudowane w system Windows Server. Mamy tutaj do czy-nienia z klasycznym rozwiązaniem backupu. Tworzymy kopie systemu i danych maszyny

wirtualnej, przenosimy je na zewnętrzny no-śnik, a czynność tę powtarzamy w regularnych odstępach czasu. Warto dodać, że Windows Server Backup wyposażono w funkcje wersjo-nowania wykonywania kopii, a zatem istnieje możliwość wygodnego odtwarzania danych historycznych, kiedy będą potrzebne, np. w trakcie audytu księgowego.

Narzędzie to możemy wykorzystać do backupu danych serwerów fizycznych i ma-szyn wirtualnych z zainstalowanym syste-mem Windows Server. Ta sama technologia pozwala także „zabierać” maszyny z hosta wirtualizacji. Za każdym razem dotyczy do jednak pojedynczych serwerów – fizycznych lub gościa.

Aplikacje LOBW praktyce obciążenia aplikacji LOB (Line of Business) rozkładane są między wiele maszyn wirtualnych. Typowe rozwiązanie obejmuje trzy warstwy: danych, logiki biznesowej oraz interfejsu użytkownika. Każda z tych warstw to oddzielny zestaw maszyn wirtualnych w klastrze. W przypadku warstwy danych mamy do czynienia z klastrem bazodanowym, który tworzą dwie instancje maszyn wirtual-nych skonfigurowanych do pracy w technolo-gii SQL AlwaysOn Availability Groups. W tym kontekście redundancja danych zapewniana jest w warstwie danych.

W logice biznesowej może to być zestaw maszyn wirtualnych, które mają wspólną konfigurację i obsługują logikę tego, co dzieje się w aplikacji LOB. Z kolei warstwę interfejsu użytkownika (fronted) może tworzyć portal webowy obsługiwany przez kilka instancji wirtualnych niezależnych od siebie, ale za to ze spójną konfiguracją lub zintegrowanych w ramach farmy serwerów z wdrożonym mechanizmem równoważenia obciążeń sie-ciowych Network Load Balancing. Za każdym razem należy pamiętać, że wybór konkretnej technologii zapewniania ciągłości działania zależy od celów, jakie zamierzamy osiągnąć, ale także od architektury, w której zaprojek-towano aplikację LOB. W jaki sposób chronić aplikacje kluczowe z perspektywy zachowania ciągłości działania?

Data Protection ManagerData Protection Manager (DPM) to rozwiąza-nie firmy Microsoft, które umożliwia w spo-sób spójny nakładanie reguł (polisy) ochrony

Windows Server Backup to mechanizm zapewnienia ciągłości biznesowej, stricte związany z tworze-niem kopii zapasowych.

7


dla aplikacji LOB złożonych z różnych ele-mentów i dostarczanych na różnych maszy-nach wirtualnych. Data Protection Manager jest częścią pakietu Microsoft System Center 2012 R2 i ściśle integruje się ze środowi-skiem Windows Server i Hyper-V. W momen-cie utworzenia grupy zabezpieczeń Data Protection Manager może wszystkie dane chronionej aplikacji LOB przenieść w sposób spójny do chmury.

Windows Server Backup oraz Data Protection Manager pozwalają na odkłada-nie kopii zapasowych na macierzy dyskowej oraz w chmurze Microsoft Azure. Dla uzu-pełnienia dodajmy, że DPM może zapisywać dane również na bibliotece taśmowej. Nie to będzie jednak tematem naszych dalszych rozważań, a fakt, że automatyczne przeno-szenie kopii zapasowych do chmury to nic innego jak backup danych do zewnętrznej lokalizacji (off-site).

Backup off-siteWiększość firm ma uwzględnione w proce-durach zasady retencji taśm. W ustalonych odstępach czasu taśmy z kopiami zapasowy-mi należy zebrać i wynieść do zewnętrznej lokalizacji. Proces ten wymaga zaangażowa-nia człowieka, jest podatny na błędy, a przy tym kosztowny. Wady i ograniczenia tego podejścia możemy w prosty sposób wyelimi-nować, integrując narzędzia Windows Server Backup lub Data Protection Manager z chmurą Microsoft Azure. Wszystko, czego potrzebu-jemy, to łącze internetowe. Transmisja kopii zapasowych do chmury jest zaszyfrowana tak samo jak wszystkie dane przechowywane po stronie Azure.

Azure Site RecoveryDotychczas nasza uwaga skupiała się na klasycznych rozwiązaniach backupu, nie-wiele mówiąc o technologiach związanych z przywracaniem systemów i danych po ka-tastrofie (disaster recovery). Rozwiązaniem disaster recovery opartym na chmurze publicznej Microsoft Azure jest Azure Site Recovery. Usługa ta integruje się z elemen-tami infrastruktury centrum przetwarzania danych i asynchronicznie replikuje dane produkcyjne do centrum zapasowego lub chmury Azure.

Azure Site Recovery pozwala wdrażać sce-nariusze odzyskiwania systemu po katastrofie

w dwóch modelach. W pierwszym scenariuszu obciążenia systemów odtwarzane są we wła-snym ośrodku zapasowym. Drugi model zakła-da odtworzenie wszystkich lub krytycznych dla funkcjonowania firmy systemów i danych w chmurze Microsoft Azure. Mamy więc tutaj do czynienia z przeniesieniem obciążeń do instancji wirtualnych chmury uruchamianych w modelu IaaS.

Automatyzacja procesu odtwarzania danychData Protection Manager to pierwsze scentra-lizowane (serwerowe) narzędzie do zarządze-nia ciągłością działania systemów IT, które pozwala na backup krytycznych aplikacji do chmury oraz na automatyzację procesu prze-łączania systemów IT do zapasowego centrum danych przedsiębiorstwa. Pierwsza wersja tej aplikacji została wprowadzona na rynek już w 2006 r. Obecne wydanie nosi numer 2012 R2 i zawiera wtyczkę integrującą to narzędzie z chmurą publiczną Microsoft Azure.

Natywny agent usługi Data Protection Manager integruje się z systemem Windows Server oraz Windows Client (stacje robo-cze i laptopy). Oprogramowanie umożliwia backup krytycznych aplikacji biznesowych, takich jak Exchange, SharePoint, Dynamics czy SQL Server oraz innych aplikacji LOB uruchamianych na platformie Windows Server. W przypadku integracji z hostem wirtualizacji na bazie Hyper-V (chmura pry-watna) Data Protection Manager pozwala na wyniesienie do centrum zapasowego lub chmury Azure całej instancji wirtual-nej, przy czym może to być także maszyna z zainstalowanym systemem Linux. Wynika to z faktu, że na platformie Azure istnieje możliwość uruchamiania instancji maszyn wirtualnych z Linuksem.

Data Protection Manager ściśle integru-je się z pozostałymi modułami środowiska Microsoft System Center, m.in. w zakresie zarządzania i monitorowania. Przykładem takiej integracji jest współpraca Data Protection Managera z narzędziem System Center Orchestrator, które służy do projekto-wania przepływów i automatyzacji czynności administracyjnych w infrastrukturze cen-trum przetwarzania danych. System Center Orchestrator warto wykorzystać zwłaszcza do zautomatyzowania testów odtworzeniowych w planach zachowania ciągłości biznesowej.

Data Protection Manager to pierwsze scentralizowa-ne (serwerowe) narzędzie do zarządzenia ciągłością działania systemów IT, które pozwala na backup krytycznych aplikacji do chmury oraz na automaty-zację procesu przełączania systemów IT do zapasowe-go centrum danych przed-siębiorstwa.

8


Chmura hybrydowaKolejnym rozwiązaniem związanym z cią-głością pracy systemów aplikacyjnych jest ochrona maszyn wirtualnych uruchamianych w rozwiązaniach hybrydowych. Scenariusz ten dotyczy sytuacji, w której część obcią-żeń obsługiwana jest w lokalnym ośrodku przetwarzania przedsiębiorstwa i do niej możemy stosować rozwiązania ochrony omówione dotychczas, natomiast druga połowa tych aplikacji uruchamianych jest na maszynach wirtualnych w modelu IaaS po stronie chmury publicznej Microsoft Azure. W drugim wariancie mechanizmy backupu i zarządzania planami odtworzeniowymi zaszyte są w logikę chmury. Wymaga to jedynie instalacji agenta wewnątrz takiej maszyny wirtualnej. W zamian otrzymamy możliwość wersjonowania tych kopii, a więc odkładania danych historycznych aplikacji przedsiębiorstwa i ich przywracania, jeśli jest to wymagane.

Microsoft StorSimpleDotychczas omawiane technologie bazowa-ły na protokołach aplikacyjnych z agentem usługi instalowanym wewnątrz systemu ope-racyjnego lub na hoście wirtualizacji. To nie wszystkie produkty tego typu dostępne na rynku. Innym ciekawym rozwiązaniem związa-nym z planami zachowania ciągłości działania jest StorSimple, czyli hybrydowa macierz dyskowa (Hybrid SAN) Microsoftu.

StorSimple to macierz dyskowa instalowa-na w ośrodku przetwarzania danych klienta. Urządzenie ma wysokość 2U, jest w pełni redundantne, składa się z zestawu dysków półprzewodnikowych (SSD) i magnetycznych. Oprogramowanie StorSimple wyposażono w algorytmy warstwowego przechowywania danych (tiering). Najczęściej używane dane (gorące bloki) składowane są w warstwie półprzewodnikowej, a te, z których rzadko się korzysta, poddawane są kompresji i dedupli-kacji, a następnie są zapisywane na klasycz-nych dyskach magnetycznych. Bloki zimne, czyli te, do których nie odwołujemy się prak-tycznie wcale, po pewnym czasie przenoszone są do chmury publicznej Microsoft Azure.

Zaletą StorSimple jest możliwość przecho-wywania dużej ilości danych. Dla przykładu, LUN logiczny, czyli dysk przypisywany do maszyny fizycznej lub hosta wirtualizacji (Hyper-V, VMware itd.), może być bardzo duży.

W rozwiązaniu Microsoft nie jesteśmy ograni-czeni pojemnością pamięci masowej zainsta-lowanej w lokalnym centrum przetwarzania danych, mając na uwadze trzecią warstwę składowania danych w chmurze obliczenio-wej. To właśnie chmura gwarantuje praktycz-nie nieograniczoną – jak na współczesne wymagania aplikacyjne – przestrzeń dyskową na dane, których kopie mogą być dodatkowo rozmieszczone w wielu lokalizacjach na całym świecie (georedundancja).

Wszystkie dane, które umieścimy w urzą-dzeniu StorSimple, mogą podlegać operacji migawki (snapshot), a więc techniki wersjo-nowania znanej choćby z rozwiązań wirtu-alizacyjnych. W tym przypadku celem jest wykonanie migawki całego LUN-a maszyny wirtualnej przechowywanej na macierzy dys-kowej StorSimple.

StorSimple umożliwia wykonywanie mi-gawek dwóch typów. Pierwszy to migawka lokalna, która jest lokalnym archiwum danych w pewnym punkcie w czasie. Taką migawkę wykorzystamy do cofnięcia zmian w maszynie wirtualnej, odzyskania z niej danych archiwal-nych czy sklonowania na inny system. Druga opcja to migawki chmurowe. Pełna kopia da-nych, przechowywanych wewnątrz logicznego wolumenu, odkładana jest po stronie chmury publicznej Microsoft Azure.

Dzięki temu podejściu oprócz standardo-wego rozwiązania backupu i wersjonowania danych zyskujemy mechanizmy odzyskiwania po katastrofie (disaster recovery) na poziomie przechowywania danych. Wszystko to odbywa się w pełni automatycznie dzięki logice zaszytej w chmurze Azure. Ochroną mogą zostać objęte pliki maszyn wirtualnych, bazy danych i pliki.

Odtwarzanie do zapasowego centrum danychStorSimple pozwala na przygotowanie dwóch wariantów planu odtwarzania po awarii pod-stawowego centrum danych. Pierwszy zakłada przekierowanie konfiguracji logicznych wo-lumenów do zapasowego centrum przetwa-rzania, także z zainstalowanym urządzeniem StorSimple. Zapasowe urządzenie StorSimple łączy się do chmury Azure i udostępnia lo-giczne wolumeny serwerom uruchamianym w rezerwowym ośrodku przetwarzania. W tym momencie możemy już uruchamiać serwery i aplikacje w centrum zapasowym. Bloki dys-kowe wolumenów pobierane są sukcesywnie

StorSimple umożliwia wykonywanie migawek dwóch typów. Pierwszy to migawka lokalna, druga opcja to migawki chmurowe.

9


z chmury publicznej aż do momentu, gdy wszystkie dane wymagane przez zapasowe instancje wirtualne będą dostępne na lokal-nych dyskach macierzy (półprzewodnikowych i magnetycznych).

Oczywiście, proces ten wymaga czasu, ale w końcu osiągniemy stan, kiedy wszystkie go-rące bloki dyskowe, niezbędne do pracy apli-kacji biznesowych, zostaną zapisane lokalnie w zapasowym centrum danych, a infrastruk-tura osiągnie pełną wydajność. Zaletą tego podejścia jest brak konieczności przenosze-nia taśm między podstawowym i zapasowym centrum danych (backup off-site) oraz szyb-kość, z jaką możemy przełączyć infrastrukturę do alternatywnego ośrodka przetwarzania. W podstawowym zakresie operacja ta wy-maga 15 minut – mniej więcej tyle trwa syn-chronizacja metadanych między urządzeniem StorSimple i chmurą publiczną Azure.

Odtwarzanie do chmuryDrugi wariant planu odzyskiwania po kata-strofie zakłada wykorzystanie mocy obli-czeniowej i zasobów chmury publicznej jako alternatywy dla budowy własnego centrum zapasowego. W tym przypadku na czas awarii dla krytycznych aplikacji biznesowych aloko-wane są zasoby chmury.

Od strony technicznej całego rozwiąza-nia wymaga to powołania obiektu Virtual Appliance StorSimple, który odzwierciedla logikę biznesową urządzenia zainstalowanego w podstawowym centrum przetwarzania da-nych w formie maszyny wirtualnej po stronie chmury Azure.

W praktyce polega to na zamapowaniu wolumenów (LUN), które poddawane były migawkom chmurowym do instancji maszyn wirtualnych. Oznacza to możliwość szybkiego odtworzenia pełnej infrastruktury w bardzo krótkim czasie na podstawie ostatniej wersji danych przekazanej do chmury. W ten sposób możemy uruchamiać i udostępniać usługi serwera plików czy bazy danych odbiorcom końcowym przez internet lub wydzieloną sieć wirtualną.

Wymaga to nakreślenia i wdrożenia w scenariuszu odzyskiwania po katastrofie nadmiarowych (redundantnych) połączeń sieciowych do chmury Azure. W tym obszarze chmura Microsoft oferuje wiele możliwości, przede wszystkim mowa tutaj o tunelach VPN zestawianych w trybie site-to-site oraz point-

-to-site. Mechanizmy te pozwalają ustanowić bezpieczne połączenie do chmury dla konkret-nego urządzenia lub zewnętrznej lokalizacji, np. zapasowego biura, za pomocą specjalne-go linku sieciowego, tzw. Express Router.

Korzystanie z chmury wiąże się z koniecz-nością ponoszenia kosztów działania maszyn wirtualnych w wynajmowanej na czas awarii infrastrukturze IaaS. Mamy tutaj do czynienia z relatywnie krótkim okresem, gdyż celem przedsiębiorstwa jest możliwie szybkie usu-nięcie awarii i odtworzenie systemów i danych w podstawowej lokalizacji centrum przetwa-rzania danych.

Siedem warstw systemu DRNa rynku dostępnych jest wiele rozwiązań klasy disaster recovery pozycjonowanych według stopnia ochrony, automatyzacji zadań planowania, wdrażania i odtwarzania syste-mów po katastrofie oraz czasu potrzebnego na przywrócenie do działania systemów, apli-kacji i danych przedsiębiorstwa.

Rozważania na temat złożoności tego typu systemów należy rozpocząć od przedsię-biorstw, które nie mają wdrożonego żadnego rozwiązania typu disaster recovery. Wiele firm opiera scenariusze odzyskiwania po katastro-fie na bazie kopii zapasowych przechowywa-nych w zewnętrznej lokalizacji (off-site). Może to być skarbiec, skrytka bankowa, zamiejsco-wy oddział itd.

Poziom wyżej stawia się rozwiązania, w których kopia danych wynoszona jest do zapasowego centrum danych, przy czym procedura ta wymaga ingerencji człowieka. Proces można zautomatyzować, przesyłając kopie zapasowe do zewnętrznej lokalizacji lub zapasowego centrum danych przez łącze in-ternetowe. W tym przypadku mówimy o elek-tronicznym skarbcu.

Kolejnym stopniem zaawansowania rozwią-zania disaster recovery jest wdrożenie me-chanizmów, które pozwalają na przywrócenie stanu systemów biznesowych do konkretnego punktu w czasie. W wysokiej klasy rozwią-zaniu DR wymagane jest, aby mechanizmy odtwarzania zapewniały co najmniej tzw. integralność transakcyjną, a w idealnym wa-riancie nie dochodziło do żadnej lub co najwy-żej do minimalnej utraty danych. Najwyższy stopień zaawansowania można uzyskać do-piero wówczas, gdy całe rozwiązanie zostanie wysoce zautomatyzowane.

W wysokiej klasy rozwią-zaniu Disaster Recovery wymagane jest, aby me-chanizmy odtwarzania za-pewniały co najmniej tzw. integralność transakcyjną, a w idealnym wariancie nie dochodziło do żadnej lub co najwyżej do minimalnej utraty danych.

10


Jak na tym tle pozycjonuje się usłu-ga Azure Site Recovery? W rozwiązaniu Microsoft mamy do czynienia z wysoce zautomatyzowanym rozwiązaniem disaster recovery, charakteryzującym się możliwością utraty danych bliską zeru, zapewniających integralność transakcyjną, które pozwala przywrócić stan systemu do określonego punktu w czasie, a jednocześnie wysyła te dane do zewnętrznej lokalizacji (off-site) i robi to elektronicznie. Dodatkowo Azure Site Recovery jest tanim rozwiązaniem.

DR węzłów Hyper-VAzure Site Recovery to usługa chmurowa, a więc wymaga subskrypcji chmury pu-blicznej Microsoft Azure. Wdrożenie tego rozwiązania polega na powołaniu obiektów logicznych po stronie chmury, a następnie skojarzenie ich z obiektami węzła infrastruk-tury lokalnego ośrodka przetwarzania da-nych przedsiębiorstwa.

Takim węzłem może być host wirtualiza-cji Hyper-V. Podejście to pozwala korzystać z usługi Azure Site Recovery w prostych sce-nariuszach, np. w oddziałach firmy (branch offices), w których zastosowano wirtualizację Hyper-V, ale nie wdrożono mechanizmów kla-strowych ani scentralizowanej infrastruktury zarządzania. W usłudze Azure Site Recovery rejestrowany jest host wirtualizacji Hyper-V, natomiast wszystkie aspekty parametryzacji ochrony tego węzła definiowane są z poziomu panelu administracyjnego chmury Microsoft Azure przez przeglądarkę internetową.

W tle tego rozwiązania kryje się dobrze znana technologia Hyper-V Replica, która umożliwia asynchroniczne przesyłanie pli-ku (obrazu) maszyny wirtualnej przez sieć komputerową. Jak już zostało wspomniane wcześniej, mechanizm Hyper-V Replica wyko-rzystywany jest do ochrony lokalnych zaso-bów wewnątrz centrum przetwarzania danych przedsiębiorstwa. W odniesieniu do rozwią-

7 warstw systemu DR

Warstwa 0 Brak rozwiązania DR

Warstwa 1 Kopia off-site

Warstwa 2 Kopia w zapasowym DC

Warstwa 3 Elektroniczny Skarbiec

Warstwa 4 Kopie Point-In-Time

Warstwa 5 Integralność transakcyjna

Warstwa 6 Bliska zeru utrata danych

Warstwa 7 Wysoce zautomatyzowane rozwiązanie

11


zania Azure Site Recovery funkcja Hyper-V Replica replikuje dane do zapasowego cen-trum danych lub chmury publicznej Azure. W obu przypadkach dane kopii składowane są w zewnętrznej lokalizacji, skąd mogą zostać użyte w przypadku awarii podstawowego centrum przetwarzania.

To doskonały przykład, w jaki sposób wirtualizacja Hyper-V w połączeniu z usługą chmury Azure może zostać wykorzystana do wprowadzenia pełnego planu disaster recove-ry dla usług działających wewnątrz chronione-go hosta, bez konieczności budowy drogiego w utrzymaniu centrum zapasowego. To jednak nie wszystko.

DR chmury prywatnej przedsiębiorstwaUsługa Azure Site Recovery może objąć planem odtwarzania po katastrofie chmurę prywatną w centrum przetwarzania danych przedsiębiorstwa. Dotyczy to firm, które zaim-plementowały w swojej infrastrukturze zarzą-dzania rozwiązanie Microsoft System Center, a właściwie jeden z modułów tego pakietu: Virtual Machine Manager. Oprogramowanie umożliwia wysyłanie wszystkich lub wybra-nych instancji wirtualnych chmury prywatnej do zapasowego centrum przetwarzania da-nych lub chmury publicznej Azure.

W ostatnim czasie Microsoft udostępnił technologię replikacji, która pozwala za-bierać obciążenia centrum przetwarzania danych nie tylko z hostów Hyper-V, ale także ze środowisk wirtualnych VMware oraz ma-szyn fizycznych. Technologia ta jest częścią oferty Azure Site Recovery. Innymi słowy, za pomocą tego mechanizmu możemy przenosić maszyny wirtualne pracujące na hostach VMware do zewnętrznej lokalizacji, a więc zapasowego centrum danych z analogiczną infrastrukturą wirtualizacji VMware lub bez-pośrednio do chmury publicznej Azure. To samo dotyczy migracji hostów fizycznych, kiedy w centrum danych korzystamy nadal z maszyn fizycznych.

Wymaga to wskazania listy obiektów, które chcemy objąć ochroną w zapasowym centrum danych lub w chmurze Azure. Na tym etapie możemy zdefiniować zasady tej ochrony, czyli z jakim maksymalnym opóźnieniem chcemy replikować dane kopii do chmury, ile wersji obrazów zamierzamy utrzymywać w zewnętrz-nej lokalizacji itd.

Usługa Azure Site Recovery pozwala na definiowanie planów awaryjnych, które zo-staną zastosowane w przypadku problemów w podstawowym centrum danych na poziomie pojedynczej maszyny lub całego ośrodka przetwarzania. Azure Site Recovery automa-tyzuje proces przenoszenia aplikacji do za-pasowego centrum danych oraz odtwarzanie maszyn wirtualnych w chmurze publicznej Azure. W drugim przypadku mamy do czynie-nia z przełączeniem systemów biznesowych przedsiębiorstwa do chmury, ponieważ kopie maszyny wirtualnych są na bieżąco replikowa-ne do Azure.

Administrator ma wpływ na przebieg pro-cesu odtwarzania po awarii. Ma on do dyspo-zycji narzędzia, które pozwolą mu zdecydo-wać, w jakiej kolejności będą uruchamiane kolejne maszyny w chmurze, oraz nadzorować przebieg replikacji danych z podstawowego centrum danych do zapasowego centrum, chmury lub obu tych lokalizacji jednocześnie. Dodajmy, że chmura Azure ma wbudowane mechanizmy georedundancji, tak więc awaria centrum danych Microsoft nie zagraża utratą danych, które mogą być przechowywane na innym kontynencie.

PodsumowanieAzure Site Recovery to usługa chmurowa, która umożliwia objęcie ochroną maszyn fizycznych i wirtualnych centrum przetwa-rzania danych przedsiębiorstwa. W połą-czeniu z Windows Azure Backup planem odtwarzania po katastrofie mogą zostać objęte także instancje wirtualne urucha-miane w chmurze Azure.

Projektanci rozwiązań wysokiej dostępności mają do dyspozycji duży wybór technologii, po-cząwszy od technologii klastrowych, narzędzia backupu systemów i danych z pojedynczych źródeł, po zaawansowane rozwiązania, głów-nie Data Protection Manager, które umożliwiają ochronę całych złożonych struktur aplikacji LOB uruchamianych w centrum danych firmy.

Dopełnieniem tego portfolio jest usługa chmurowa Azure Site Recovery, która auto-matyzuje proces przełączenia do zapasowego centrum danych lub chmury, pozwalając sku-tecznie chronić nasze obciążenia w przypadku katastrof. Dodajmy, że Microsoft oferuje roz-wiązanie hybrydowe, które umożliwia ochronę hostów wirtualizacji Hyper-V, maszyn fizycz-nych oraz środowisk wirtualnych VMware.

Usługa Azure Site Recovery może objąć planem odtwarzania po katastrofie chmurę prywatną w centrum przetwarzania danych przedsiębiorstwa.

Documents

Zarządzanie ciągłością biznesową w rozwiązaniach firmy ......SharePoint, dla kolejnych SAP, Oracle lub poczta Exchange, a dla pozostałych jeszcze inny system biznesowy. Wyniki