Od serwera fizycznego do maszyny wirtualnej w DRC

Dziś chcielibyśmy się podzielić z Wami case study które hipotetycznie mogło się gdzieś u kogoś wydarzyć… Bo jak doskonale wiadomo w dzisiejszych czasach wszechobecnej technologii i uzależniania od usług elektronicznych nietrudno sobie wyobrazić chaos, jaki może nastąpić przy ich niedostępności. Wielokrotnie słyszeliśmy o sytuacjach, gdy na jakimś obszarze nie ma prądu albo duży dostawca usług w internecie ma problemy z dostępnością swoich usług.

Trudno sobie wyobrazić firmę, która by nie korzystała chociażby z poczty elektronicznej czy bankowości internetowej. Coraz więcej spraw urzędowych można załatwić przez internet – choćby rozliczanie podatku.

Firmy, które chcą korzystać z takich usług muszą mieć łącze internetowe oraz chociaż jeden komputer. Jeśli dostęp do internetu staje się usługą krytyczną, to zazwyczaj pojawia się drugie łącze, udostępniane chociażby przez operatorów telefonii komórkowej.

Gdy firma zaczyna w większym stopniu korzystać z komputerów, a praktycznie każdy pracownik posiada swoje własne urządzenie (czy to PC, laptop czy tablet) i sytuacja staje się coraz bardziej skomplikowana. Pojawia się potrzeba komunikacji za pomocą poczty elektronicznej, łatwego, szybkiego składowania plików. Znienacka w sieci instalowane są systemy klasy ERP wokół których budowane są wszelkie procesy w firmie. Oczywiście gdzieś po drodze są też klienci, którzy chcą zadzwonić, czy wysłać e-mail – niektórzy pojawiają się nawet osobiście.

Zależności pomiędzy systemami coraz bardziej się komplikują, pojawiają się partnerzy, którzy mają dostęp do naszego systemu lub dają dostęp do własnego. Wszystko działa z reguły świetnie, czasem tylko zepsuje się komuś komputer albo telefon. Czasem również niewłaściwie działa system, jednak pomimo tego podążamy naprzód.

Poniższe ćwiczenie ma pokazać podejście do infrastruktury DRC dla hipotetycznej infrastruktury organizacji z sektora MSP, etapy postępowania i reakcje na występujące problemy.

Pojawia się jednak taki moment, gdy ktoś zauważa, że dłuższy przestój będzie kosztowny. Istotne jest jednak, kto to zauważy… Jeśli ktoś z wewnątrz (np świadomy zagrożeń zarząd), zostanie to zrobione dokładnie, jeśli jest to ktoś z zewnątrz – jakiś “nadzorca” – istnieje obawa, że podejście do rozwiązania problemu będzie minimalistyczne.

Niezależnie od wybranego rozwiązania, pewne kroki muszą być podjęte, w wyniku których przygotowany zostaje plan odtworzenia działalności firmy po poważnej awarii. W ramach przygotowanego planu możemy:

• nie robić nic – zaakceptować ryzyko, ewentualnie się ubezpieczyć na wypadek strat
• wynająć/zarezerwować lokalizację zapasową, w której coś może być przygotowane (nowe komputery, serwery). Oczywiście w wyniku poważnej awarii przygotowanie lokalizacji zapasowej do pracy może potrwać bardzo długo (dni, tygodnie), szczególnie w przypadku, kiedy katastrofa dosięgnie nie tylko obszaru technologii a również wymusi konieczność przeprowadzenia załogi
• przygotować możliwie dużo (sprzętu, oprogramowania…), aby zminimalizować czas uruchomienia lokalizacji zapasowej. Przy wyborze tego scenariusza pojawiają się dodatkowe możliwości, czyli przełączenie częściowe – ale to już wymaga największego wysiłku i planowania

W dalszej części opiszę ewolucje trzeciego podejścia – z całkowitego przełączenia do selektywnego.

Jedna lokalizacja

Zaczynamy od sytuacji, gdy nie ma centrum zapasowego.

Lista usług/serwerów:

• PROXY serwer – pośredniczy w nawiązywaniu połączenia użytkowników do usług w internecie – lokalne sprzętowe rozwiązanie
• DNS, DHCP – – usługi rozwiązywania nazw i konfiguracji sieci dla komputerów – lokalne sprzętowe rozwiązanie
• DC – Kontroler domeny Microsoft Windows
• WDS/WSUS – Lokalny serwer do wdrażania nowych stacji roboczych oraz ich aktualizacji
• PROFILES – serwer z profilami mobilnymi
• FILE SERVER – serwer plików współdzielonych, drukarek, plików na potrzeby systemu ERP oraz kilku innych aplikacji,
• TERMINAL SERWER – serwer usług terminalowych pozwalający użytkownikom z poza lokalnej sieci na dostęp do systemu ERP (system opiera się na grubym kliencie i wymaga dostępu do lokalnych dysków sieciowych oraz bazy danych)
• BAZA DANYCH – baza danych dla systemu ERP
• BACKUP SERWER – serwer odpowiedzialny za tworzenie kopii bezpieczeństwa oraz zarządzanie nimi
• stacje robocze, laptopy i drukarki

Analiza lokalizacji pod kątem DRC

Lokalizacja zapasowa składałaby się z następujących elementów:

• PROXY serwer
• DNS DHCP
• DC
• WDS/WSUS
• PROFILES
• FILE SERWER
• BACKUP SERWER
• BAZA DANYCH
• stacje robocze, laptopy, drukarki

Wymagania stawiane centrum zapasowemu:

• umożliwienie pracy 20% personelu
• testowanie nie może powodować zakłóceń lokalizacji podstawowej
• minimalizacja budżetu
• brak potrzeby jednoczesnej pracy obu lokalizacji, czy wsparcia lokalizacji podstawowej lokalizacją zapasową

Etap I – Uruchomienie najważniejszych usług w DRC

Przy tak postawionych wymaganiach elementy, z których składa się centrum zapasowe, możemy podzielić na dwie grupy:

• infrastruktura niezbędna do pracy i konserwacji stacji roboczych, jak i same stacje robocze i drukarki
• usługi rdzeniowe biznesu

W pierwszej grupie znajdą się: PROXY, DNS, DHCP, WDS/WSUS, PROFILES.

W drugiej: FILE SERWER, BAZA DANYCH.

Zdecydowano o uruchomieniu i konfiguracji w centrum zapasowym następujących usług:

• Serwery PROXY, DNS, DHCP, WDS/WSUS oraz stacje robocze i drukarki
• Serwery FILE SERWER i BAZA DANYCH – dane kopiowane regularnie z centrum podstawowego.
• PROFILES – regularnie kopiowane pliki, problem z utrzymaniem listy udostępnianych zasobów względem lokalizacji podstawowej
• Wszelkie dyski sieciowe wymagają ponownej konfiguracji mapowania na stacjach
• Profile mobilne – podłączą się z serwera w lokalizacji podstawowej, nadpisujemy adresy dns w lokalnej konfiguracji stacji, aby wymusić korzystanie z lokalnych serweró
• Aplikacja ERP uruchamiana na końcówkach – skonfigurowana, aby korzystała z nazw DNS, w wyniku nadpisania adresów DNS – korzysta z serwerów w DRC.

Podjęto decyzję o nieuruchamianiu dostępu z zewnątrz, co implikuje rezygnację w centrum zapasowym z TERMINAL SERVER’a

Zdecydowano o takiej realizacji centrum zapasowego, która spełnia wymagania, choć jednocześnie ogranicza liczbę scenariuszy, w których możemy się nim wesprzeć. Obie siedziby nie mogą ze sobą współpracować – nie mogą być aktywne jednocześnie. Dodatkowo nie ma możliwości wspierania się pojedynczymi elementami (komputery, serwery) w celu ogólnego zwiększenie wydajności czy liczby aktywnych pracowników. Zaplanowana architektura wygląda następująco:

Etap II – Wirtualizacja lokalizacji podstawowej

Czas biegnie nieubłaganie i w naszej hipotetycznej lokalizacji podstawowej kończy się miejsce na serwerach PROFILE i FILE SERWER. Na potrzeby nowych projektów trzeba by wykorzystać dodatkowy serwer bazodanowy.

Zamiast inwestować w nowe serwery, zakupujemy macierz do składowania plików maszyn wirtualnych:

• serwery WDS/WSUS, PROFILES, FILE SERVER – po rozbudowaniu pamięci RAM stają się teraz hypervizorami
• BACKUP SERWER otrzymuje dodatkową rolę – BAZA DANYCH 2, służąca do testowania nowych rozwiązań
• TERMINAL SERVER – zostaje skonwertowany do wirtualnej maszyny – fizyczny sprzęt jest zbyt stary do ponownego wykorzystania
• pojawia się macierz udostępniająca dane dla hypervizorów oraz nowy serwer (vCenter – zarządzający hypervizorami)

Backup działa w takiej samej architekturze (agentowej, chronimy tylko bazy danych i serwery PROFILES i FILE SERWER).

Serwery, które wcześniej nie były chronione kopiami bezpieczeństwa, a które teraz są maszynami wirtualnymi, są chronione vSphere Data Protection (VDP).

VDP – niestety w wykorzystywanej wersji nie wspiera replikacji przechowywanych kopii bezpieczeństwa, co utrudnia zabezpieczenie przed poważną awaria.

Pojawia się nowy problem, tj. pełny backup serwera PROFILE oraz FILE SERWER trwa ponad 24 godziny (każdego z osobna). Backup na taśmy bardzo wydłuża proces odzyskiwania plików z żądanego punktu w czasie.
Przejście ma backup D2D2T (backup na dyski, następnie na taśmy celem wywiezienia do zewnętrznego archiwum) bardzo usprawniłoby ten proces.

Umożliwiłby to zakup dedykowanej macierzy. Na tej macierzy również można by umieścić VDP.

W miarę rozwoju wdrożona zostaje kolejna aplikacja która wymaga kolejnych serwerów App1, App2 (które mogą być maszynami wirtualnymi).

W ramach dodatkowych zabezpieczeń pojawia się firewall.

Na tym etapie infrastruktura wygląda następująco:

Etap III – Cała infrastruktura serwerowa zabezpieczona w DRC

Na serwerach fizycznych w centrum zapasowym kończy się miejsce, pojawia się także zapotrzebowanie na uruchomienie nowej aplikacji w centrum zapasowym, jak i na zwiększenie liczby scenariuszy, w których można by skorzystać z DRC – np. uruchomienie tylko jednego z serwerów w drugiej lokalizacji i pracy na nim z lokalizacji podstawowej.

W celu spełnienia tych wymagań, wdrożymy wirtualizację w centrum zapasowym, wykorzystamy zawarty w licencji mechanizm vSphere Replication, który pozwoli w regularnych odstępach czasu kopiować maszyny wirtualne. W wyniku tych działań pojawią się wirtualne maszyny vREPLICATION1 i vREPLICATION2 jedna dla każdej lokalizacji.

Dzięki tym działaniom zniknie potrzeba utrzymywania osobnych serwerów PROFILES i FILE SERWER w centrum zapasowym, gdyż będą one replikowane i uruchamiane w razie potrzeby.

W centrum zapasowym wykorzystywane są inne adresy IP, co wymaga odpowiednego przygotowania się do uruchomiania tam kopiowanych serwerów. Zmiana adresów IP dla serwerów, zmiana adresów IP w konfiguracji serwerów DNS. Jak już wszystkie aplikacje będę korzystać z nazw DNS, a nie adresów IP, przełączanie nie będzie nastręczać problemów.

Etap IV – Cała infrastruktura serwerowa i backupowa w DRC

Ostatnim etapem do osiągnięcia pełnego zabezpieczenia w DRC jest: backup wszystkich danych i serwerów na dyski i replikowanie tych danych do centrum zapasowego oraz zapewnienie zdalnego dostępu do TERMINAL SERVER

Kwestia ta wymaga zakupu odpowiedniej przestrzeni dyskowej oraz przejścia na vSphere w wersji 6. W VDP będzie wówczas możliwość, w ramach licencji, replikowania danych pomiędzy instancjami VDP. Pozwoli to w centrum zapasowym mieć dostępne te same dane, co w lokalizacji podstawowej.

Kwestia backupu serwerów fizycznych wymaga uruchomienia nowej wirtualnej maszyny odpowiedzialnej za backupy na dyski i na taśmy. Serwer ten także będzie replikowany do centrum zapasowego.

Stacje robocze pozostają fizyczne, nieplanowane jest wdrożenie VDI.

Wnioski

Rozwój infrastruktury jest procesem ciągłym. Wszelkie modyfikacje powinny od razu zawierać plan odtworzenia w centrum zapasowym. Niedopełnienie tych działań powoduje, że powstaje szybko powiększająca się wyrwa, którą z każdym rokiem jest coraz trudniej załatać. Licencjonowanie wszelkich produktów nieustannie się zmienia, co może powodować problemy, lecz także je rozwiązywać. Zaniedbanie tych działań może mieć katastrofalne skutki w krytycznej chwili, a bez przetestowanego planu opanowanie kryzysowej sytuacji może być niemożliwe.