Spis treści
Proces ten, czyli tzw. cloud repatriation, nie oznacza automatycznie całkowitej rezygnacji z chmury publicznej. W praktyce jest to ponowna ocena miejsca uruchamiania poszczególnych obciążeń i przeniesienie tych, dla których serwerowa infrastruktura własna lub kolokowana zapewnia lepszy bilans kosztów, wydajności, kontroli i ryzyka. Szczególnie dobrze sprawdzają się systemy działające 24/7, o przewidywalnym obciążeniu i dużym zapotrzebowaniu na pamięć lub transfer danych. Z tego artykułu dowiesz się, jak krok po kroku ocenić opłacalność repatriacji, zaprojektować środowisko docelowe i przeprowadzić migrację infrastruktury krytycznej IT bez utraty ciągłości działania.
Kiedy repatriacja infrastruktury krytycznej IT się opłaca?
Pierwszym błędem przy szacowaniu opłacalności jest porównywanie wyłącznie miesięcznej faktury za usługi chmurowe z ceną sprzętu komputerowego i jego utrzymania. Należy policzyć łącznie koszty TCO (Total Cost of Ownership) obu wariantów w perspektywie przynajmniej 24–36 miesięcy.
W przypadku korzystania z chmury trzeba uwzględnić nie tylko koszt wynajmu mocy obliczeniowej, ale wszystkie opłaty związane z działaniem infrastruktury, w tym:
- wynajem zasobów obliczeniowych i ich średnie wykorzystanie,
- przestrzeń na dane i jej przewidywany przyrost,
- kopie zapasowe i dodatkowe,
- transfer danych poza chmurę oraz między poszczególnymi usługami,
- opłaty za licencje,
- dodatkowo płatne usługi zarządzane,
- rozwiązania zapewniające wysoką dostępność i odtwarzanie systemu po awarii,
- koszty obsługi, administracji i wsparcia technicznego.
Po stronie kolokacji do kosztów zakupu lub leasing sprzętu dochodzą m.in. takie kwestie jak amortyzacja, opłaty za energię, miejsce w szafie rack, łącza, licencje, wykonywanie backupu oraz administrację. W zamian otrzymujesz jednak znacznie większą kontrolę nad zasobami i bardziej przewidywalny model kosztowy. W Sprint Data Center kolokacja serwerów obejmuje m.in. gwarantowane zasilanie, UPS i agregat, redundantne chłodzenie, monitoring, ochronę fizyczną, łącza różnych operatorów oraz wsparcie techniczne 24/7/365.
Rezygnacja z chmury na rzecz własnej infrastruktury IT ma najwięcej sensu wtedy, gdy system jest przez większość doby równomiernie obciążony, a potrzebne zasoby są wykorzystywane niemal cały czas. Trudniej uzasadnić takie rozwiązanie w przypadku systemów, w których zapotrzebowanie na moc obliczeniową mocno się zmienia, występują sezonowe wzrosty ruchu albo aplikacja intensywnie korzysta z usług dostępnych wyłącznie u konkretnego dostawcy chmury.
Dlatego decyzję o przeniesieniu wszystkiego, z chmury do własnej infrastruktury warto podejmować dla każdego systemu lub obciążenia osobno, zamiast traktować całą infrastrukturę jako jeden zestaw.
Przygotowanie do migracji serwera krok po kroku
Przygotowanie do migracji warto rozpocząć od dokładnego sprawdzenia obecnego środowiska, a nie od zakupu nowych serwerów. Najpierw trzeba wiedzieć, jakie aplikacje i usługi działają w firmie, z jakich danych korzystają i jakie inne systemy są od nich zależne. Dla każdej aplikacji warto więc ustalić, z jaką bazą danych współpracuje, ile zajmuje miejsca, jak dużo danych przesyła, z jakimi systemami się łączy, jak użytkownicy się do niej logują oraz z jakich usług chmurowych korzysta.
Następnie należy określić, które systemy są najważniejsze dla działalności firmy. Dla każdego z nich warto sprawdzić:
- Ile potrzebuje mocy obliczeniowej, pamięci, miejsca na dane i przepustowości sieci.
- Jak duże jest jego typowe obciążenie i jak zachowuje się podczas największego ruchu.
- Ile danych przechowuje i jak szybko ich przybywa.
- Jak szybko system musi zostać przywrócony po awarii i jak dużą ilość danych można w takiej sytuacji utracić.
- Od jakich innych aplikacji i usług zależy jego działanie.
- Czy dane muszą być przechowywane w określonym kraju lub zgodnie z konkretnymi zasadami bezpieczeństwa.
- Czy system można bez większych zmian uruchomić poza obecnym dostawcą chmury.
Ważne jest również sprawdzenie, jak wykorzystanie zasobów zmienia się w czasie. Nie warto projektować nowego środowiska wyłącznie na podstawie pomiarów wykonanych tuż przed migracją. Lepiej przeanalizować dane z kilku miesięcy, zwracając uwagę zarówno na typowe obciążenie, jak i okresowe wzrosty ruchu. Dzięki temu można uniknąć sytuacji, w której nowa infrastruktura jest wystarczająca w zwykły dzień, ale nie radzi sobie podczas największego obciążenia.
Osobno należy sprawdzić, czy aplikacje nie są silnie uzależnione od konkretnego dostawcy chmury. Jeżeli system korzysta z usług, których nie da się łatwo odtworzyć we własnej infrastrukturze, migracja może wymagać zmian w aplikacji. Dotyczy to między innymi zarządzanych baz danych, usług uruchamiających kod bez potrzeby zarządzania serwerem, specjalistycznych interfejsów oraz automatycznego zwiększania zasobów. Czas i koszt takich zmian trzeba uwzględnić w planie całego przedsięwzięcia.
Na końcu warto sprawdzić kwestie bezpieczeństwa i zgodności z wymaganiami prawnymi oraz wewnętrznymi zasadami firmy. Należy ustalić, gdzie mogą być przechowywane dane, kto ma do nich dostęp, jak rejestrowane są operacje wykonywane na danych, jak długo kopie danych powinny być przechowywane oraz kiedy i w jaki sposób można je usunąć.
Trzeba również określić, co stanie się w przypadku poważnej awarii. Nie wystarczy zapisać w dokumentacji, że system powinien zostać przywrócony w określonym czasie. Te wymagania należy przełożyć na konkretne rozwiązania, takie jak kopie zapasowe, dodatkowe serwery czy przechowywanie danych w niezależnej lokalizacji. Dzięki temu plan migracji uwzględnia nie tylko samo przeniesienie systemu, ale również jego dalsze, bezpieczne działanie.
Wybór modelu i dostawców przy migracji serwera
Pełne przeniesienie systemów z chmury do własnej infrastruktury ma sens przede wszystkim wtedy, gdy większość z nich jest przez długi czas obciążona na podobnym poziomie i nie korzysta w dużym stopniu z usług dostępnych wyłącznie u dostawcy chmury.
W praktyce częściej sprawdza się połączenie własnej infrastruktury z chmurą. Do serwerowni zewnętrznej można przenieść systemy, które wymagają stałej i przewidywalnej wydajności, np. główne aplikacje, duże bazy danych czy informacje zajmujące dużo miejsca. W chmurze można natomiast pozostawić systemy, których obciążenie często się zmienia i które potrzebują możliwości szybkiego zwiększania lub zmniejszania dostępnych zasobów.
Wybór operatora kolokacji
Operator kolokacyjny powinien być oceniany nie tylko według ceny za 1U. Dla infrastruktury krytycznej IT sprawdź przede wszystkim zasilanie, chłodzenie, łączność, monitoring, fizyczną ochronę, dostęp serwisowy oraz możliwość obsługi awarii bez obecności własnego zespołu na miejscu.
Istotnym elementem analizy jest BYOL (Bring Your Own License). Nie zakładaj, że każdą licencję kupioną wcześniej dla środowiska chmurowego można automatycznie przenieść na własny sprzęt. Zasady zależą od producenta, rodzaju licencji, umowy i konkretnego modelu wdrożenia. Przed migracją należy więc zinwentaryzować licencje, sprawdzić prawa do ich przeniesienia oraz policzyć ewentualny zakup nowych licencji.
Projekt architektury w kolokacji serwerów
Architekturę projektuj od wymagań aplikacji, a nie od dostępnych modeli serwerów. Warstwa compute powinna zapewniać zapas mocy dla normalnej pracy oraz kontrolowany margines na wzrost obciążenia. Przy przenoszeniu wielu systemów na własną infrastrukturę IT dobrym rozwiązaniem może być środowisko wirtualne, w którym na tych samych serwerach uruchamianych jest wiele niezależnych maszyn wirtualnych. Dzięki temu można oddzielić od siebie poszczególne systemy, łatwiej przenosić je między maszynami oraz lepiej wykorzystać dostępną moc obliczeniową CPU i pamięć RAM.
Jeżeli wymagania są bardziej przewidywalne lub potrzebna jest maksymalna kontrola nad zasobami, można zastosować odpowiednio skonfigurowane serwery dedykowane. Nasza firma, jako cenione polskie data center, oferuje szeroki wybór konfiguracji sprzętowych, w tym rozwiązania AMD EPYC przeznaczone do wymagających zastosowań.
Przestrzeń do przechowywania danych należy dobrać nie tylko pod względem pojemności, ale również szybkości zapisu i odczytu oraz tego, jak system ma działać w przypadku awarii dysku lub innego elementu infrastruktury. Warto pamiętać, że RAID nie zastępuje kopii zapasowej. Dane powinny być dodatkowo kopiowane do niezależnej lokalizacji lub osobnego środowiska, a możliwość ich przywrócenia należy regularnie sprawdzać w praktyce.
Sieć, łącza i segmentacja
Sieć powinna zostać zaprojektowana jeszcze przed migracją serwera. Rozdziel przynajmniej ruch administracyjny, produkcyjny, backupowy i storage, stosując odpowiednie VLAN-y, ACL oraz reguły firewall.
Jeżeli środowisko hybrydowe pozostaje aktywne, potrzebne jest stabilne połączenie pomiędzy kolokacją a chmurą. Trzeba uwzględnić przepustowość, opóźnienia, redundancję operatorów i sposób routingu.
Warto również zaplanować segmentację, czyli podzielić infrastrukturę IT na odseparowane części. Dzięki temu ewentualne przejęcie jednego systemu lub serwera nie powinno automatycznie umożliwiać dostępu do pozostałych elementów środowiska.
HA/DR w architekturze docelowej
Aspekty związane z HA, czyli wysoką dostępnością i DR, a więc odtwarzaniem systemu po awarii, rozwiązują dwa różne problemy. Pierwszy z nich ma ograniczać skutki awarii pojedynczego elementu infrastruktury IT – np. serwera, dysku czy połączenia sieciowego. Drugi natomiast dotyczy sytuacji, w których przestaje działać większa część infrastruktury i konieczne jest przywrócenie usług z kopii zapasowych.
Dla systemu krytycznego można zastosować redundantne serwery, zasilanie, sieć i pamięć masową, ale nadal potrzebna jest niezależna kopia danych. Jeżeli firma zakłada, że w razie awarii może utracić dane z maksymalnie 15 minut wstecz, wykonywanie jednej kopii zapasowej dziennie nie wystarczy. W takiej sytuacji potrzebne jest znacznie częstsze tworzenie backupu albo bieżące kopiowanie danych do drugiego środowiska.
Plan migracji serwera i bezpieczne przełączenie systemu (cutover)
Migrację najlepiej rozpocząć od uruchomienia systemu testowego, którego ewentualna awaria nie spowoduje poważnych problemów dla firmy. Najpierw należy przygotować nowe środowisko, skonfigurować sieć, monitoring, kopie zapasowe i zabezpieczenia. Dopiero gdy wszystko działa prawidłowo, można rozpocząć przenoszenie danych i systemów na serwer.
Przed cutoverem przygotuj szczegółowy plan działania, który krok po kroku określi, jakie rzeczy należy zrobić podczas migracji. Powinien on obejmować m.in.
- kolejność zatrzymywania i uruchamiania usług,
- sposób synchronizacji danych,
- moment przełączenia DNS lub routingu,
- procedury kontroli integralności danych,
- osoby odpowiedzialne za poszczególne etapy,
- kryteria uznania migracji za udaną,
- procedurę rollbacku, czyli powrotu do poprzedniego środowiska w przypadku wystąpienia problemów.
Dla baz danych i systemów wymagających wysokiej dostępności dobrym rozwiązaniem jest wcześniejsza replikacja danych i możliwie krótkie okno przełączenia. Rollback musi być zaprojektowany przed migracją serwera, a nie dopiero w sytuacji awarii.
Testy i walidacja po migracji serwera z chmury
Po przełączeniu systemu nie wystarczy sprawdzić, czy serwer odpowiada na zapytania. Walidacja powinna obejmować także wszystkie aplikacje, dane, integracje, wydajność i bezpieczeństwo. Warto przeprowadzić również kontrolowany test awarii. Dopiero wtedy można potwierdzić, że zaprojektowane HA/DR działa w praktyce.
Cloud repatriation warto więc traktować nie jako proste „przeniesienie serwerów z chmury”, ale jako dobór najlepszego miejsca do uruchamiania poszczególnych systemów. O powodzeniu całego przedsięwzięcia decydują przede wszystkim rzetelne porównanie kosztów, analiza zależności między systemami, odpowiednio zaprojektowana infrastruktura oraz dobrze przygotowane i przeprowadzone przełączenie na nowe środowisko.
Jeżeli planujesz przeniesienie stabilnych i wymagających systemów z chmury, Sprint Data Center oferuje kolokację w profesjonalnym centrum danych, z gwarantowanym zasilaniem, łącznością, monitoringiem i całodobowym wsparciem technicznym. Możesz także kupić u nas nowoczesny serwer dedykowany, którego konfigurację precyzyjnie dopasujesz do swoich potrzeb – zapoznaj się z ofertą już dziś.
FAQ – odpowiedzi na często zadawane pytania
1. Czy przeniesienie systemów na fizyczne serwery oznacza całkowitą rezygnację z chmury?
Nie. W wielu przypadkach lepszym rozwiązaniem jest połączenie własnej infrastruktury z chmurą. Systemy o stałym obciążeniu można przenieść do zewnętrznej serwerowni, a te, które potrzebują dużej elastyczności i często zmieniają zapotrzebowanie na zasoby, pozostawić w chmurze.
2. Jak sprawdzić, czy przeniesienie systemów z chmury będzie opłacalne?
Należy porównać wszystkie koszty obu rozwiązań w dłuższej perspektywie, najlepiej obejmującej co najmniej 2–3 lata. Trzeba uwzględnić między innymi koszt serwerów, przestrzeni na dane, kopii zapasowych, transferu danych, licencji, energii, serwerowni, administracji oraz samego przeprowadzenia migracji.
3. Czy do przeniesienia systemów z chmury potrzebne są własne serwery?
Nie. Można kupić własne serwery i umieścić je w zewnętrznej serwerowni, ale możliwe jest również wynajęcie gotowych maszyn. Wybór zależy przede wszystkim od wymagań systemów, przewidywanego obciążenia i kosztów.
4. Czy zewnętrzna serwerownia w ramach kolokacji daje większą kontrolę nad infrastrukturą niż chmura?
Tak, szczególnie jeśli firma korzysta z własnych serwerów. Ma wtedy większą kontrolę nad sprzętem, jego konfiguracją i środowiskiem, w którym działają aplikacje. Jednocześnie może korzystać z profesjonalnego obiektu wyposażonego w zasilanie awaryjne, chłodzenie, ochronę fizyczną i łącza internetowe.
5. Co dzieje się z kopiami zapasowymi po przeniesieniu systemów z chmury?
Kopie zapasowe trzeba zaplanować na nowo, uwzględniając między innymi częstotliwość ich wykonywania, czas przechowywania danych oraz maksymalną ilość informacji, którą firma może utracić w przypadku awarii. Sama nadmiarowość serwerów czy zastosowanie kilku dysków nie zastępuje niezależnych kopii zapasowych.
6. Ile czasu może zająć przeniesienie ważnych systemów z chmury?
Nie ma jednej uniwersalnej odpowiedzi. Czas zależy między innymi od liczby przenoszonych systemów, ilości danych, powiązań między aplikacjami oraz tego, czy konieczne jest wprowadzenie w nich zmian. Znaczenie ma również to, jak długo firma może pozwolić sobie na ograniczenie działania systemu podczas przełączania na nowe środowisko.