Disaster Recovery - spójrzmy prawdzie w oczy
Ostatnie problemy z usługami w chmurze firmy Amazon (EC2, EBS) to dobra okazja by zastanowić się od strony praktycznej nad Disaster Recovery, High Availability oraz Business Continuity. Niezależnie od tego gdzie przetwarzamy dane powinniśmy jednak pamiętać, że są to NASZE dane.
Rosnąca w szybkim tempie popularność usług typu cloud spowodowała, że część firm scedowała konieczność zapewnienia odpowiedniej ochrony danych na dostawców. Przykład koncernu Amazon, który nie jest bynajmniej odosobniony, pokazuje, że związane z bezpieczeństwem danych hasła, DR (Disaster Recovery), HA (High Availability) czy BC (Business Continuity) powinny być rozpatrywane, jako nieodłączna część sektora usług cloud computing, niezależnie od tego, kto i gdzie je świadczy.
Wspomniane terminy mają kilka wspólnych cech, co pozwala rozpatrywać je łącznie, jako zestaw komplementarnych rozwiązań. Są one niezbędne do prawidłowego zabezpieczenia działania aplikacji o kluczowym znaczeniu dla działalności firmy. Pochłaniają przy tym znaczne ilości środków finansowych, co często bywa dla nich dyskwalifikujące. Często są również trudne do zaakceptowania przez zarządy spółek, które niejednokrotnie składają się z osób uzdolnionych biznesowo, ale o ograniczonej wiedzy technicznej.
Aby przybliżyć rolę każdego ze składników systemów zabezpieczeń (DR, HA, BC) posłużymy się przykładami trzech usług o krytycznym znaczeniu dla ciągłości działania wielu innych procesów.
Pierwszy przykład to typowy serwer SQL, który obsługuje zapytania użytkowników. Drugi obejmuje serwer dedykowany wirtualizacji zasobów, korzystający z pamięci masowej SAN. Wirtualne maszyny to serwery aplikacji, plików, kontrolery domeny itp. Ostatnim przykładem jest linuksowy serwer webowy hostowany przez AWS (Amazon Web Services). Każde z zaproponowanych rozwiązań różni się pod względem infrastrukturalnym (dwa stacjonarne, jedno w chmurze), ale sposoby ich zabezpieczeń są do siebie podobne.
Wysoka dostępność
High Availability (HA) oznacza maksymalne uodpornienie usług przed poważną awarią. Koncepcja polega na tworzeniu dodatkowych elementów, które musiałyby łącznie ulec uszkodzeniu, by cały system przestał funkcjonować. Dążenie do uzyskania wysokiej dostępności jest ograniczone - fizycznie i finansowo, trzeba mieć także świadomość, że nawet po dołożeniu wszelkich starań, awaria i tak może nastąpić.
Większość serwerów SQL wyposażona jest w redundantne systemy zasilania, macierze RAID czy systemy korekcji błędów pamięci. Trudno jednak zabezpieczyć się przed awarią płyty głównej lub zawieszeniem się systemu. Rozwiązaniem jest zakup dodatkowej maszyny i uruchomienie ciągłej replikacji danych czy wręcz klastrowania usług (współdzielona pamięć SAN).
Podobnie jak dla SQL dobrym rozwiązaniem dla serwera wirtualizacji może być stworzenie klastra. Wówczas najsłabszym ogniwem infrastruktury pozostanie współdzielona pamięć SAN. Niewiele firm zdecyduje się (ze względu na koszty) na dodatkową sieć SAN i uruchomienie synchronicznej replikacji danych. Bardziej prawdopodobnym rozwiązaniem będzie zakup dodatkowych kontrolerów i przełączników.
Kwestia uzyskania wysokiej dostępności w modelu cloud jest ściśle uzależniona od dostawcy. W przypadku firmy Amazon, jeśli korzystamy z węzła EC2 , zaś nasze dane są na dysku EBS, w razie awarii węzła, nasza instancja jest uruchamiana na innym węźle, zaś bloki dysków EBS są replikowane w ramach sieci EBS.
Komentarze (1)
Mocno ogólnikowy artykuł. Tak się składa że od 2 lat pracuje w projekcie, budowy infrastruktury z DR, HA i BC "przez ocean". Backupy migawkowe to obecnie chyba jedyny sposób efektywnego tworzenia i odtwarzania backup-ów, nie wyobrażam sobie zrzucania na taśmę 100 czy 200 TB danych co noc, nie mowiąc już o czasie przywracania. Tasiemka może w takich przypadkach być wyłącznie trzecim stopniem backup-u - bezpieczne archiwum z długim czasem retencji. Dodatkowo trzeba pamiętać że jesli wykonujemy migawkę wolumenu, na którym są dane jakiejś aplikacji transakcyjnej (podana tu baza *SQL) platforma backup-owa musi w 100% współpracować z daną aplikacją (bazą). Chodzi tu o wstrzymanie wszystkich transakcji tak by w momencie wykonywania migawki, baza była w spójnym stanie. To samo zresztą dotyczy systemu operacyjnego, podniesienie zwykłego Windows-a, na którym zrobiono migawkę w momencie, gdy wykonywała się jakaś zmiana w krytycznej sekcji rejestru, może być co najmniej trudne.
- Prawo Moore’a zagrożone?
- Bezpieczeństwo WiFi - bezprzewodowe testy penetracyjne
- Wirtualizacja: obsługa SMB na czterech U
- Prawdziwe powody powstania Microsoft Open Technologies
- Open source: zmierzch ery GPL? Nie do końca...
- ROVER - prosty sposób na słabość BGP?
- Zaawansowane stacje Wi-Fi Ruckus Wireless
- Rozstanie z Javą nie będzie proste
- Google Drive uwypukla słabe strony publicznych chmur obliczeniowych
- Serwery "zombie" w centrum danych
Reklama
Huawei celuje w rynek biznesowy
Huawei nieustannie rozwija się jako dostawca infrastruktury dla branży telekomunikacyjnej. W tym roku chiński koncern zamierza umocnić swoją pozycję również na rynku rozwiązań Enterprise.
Polecane
Koniec Windows XP początkiem problemów?
Microsoft oficjalnie potwierdził, że za dwa lata definitywnie zakończy się era Windows XP - systemu operacyjnego,...
Spokój i luz administratora
Wymagania wobec pracowników działów IT rosną proporcjonalnie do stopnia rozwoju teleinformatyki. Oczekuje się, że...