Jak czeski mikro-MSP zastąpił odsprzedaż AWS platformą Apache CloudStack, aby zwiększyć marże hostingowe z 5% do 60%

3

Czytaj 14 min.

Gdy firma sprzedaje nie serwery, lecz efekt końcowy — działające systemy klientów — jej infrastruktura musi charakteryzować się przewidywalnymi kosztami i umożliwiać zarządzanie bez zbędnych czynności ręcznych. Niniejsze studium przypadku pokazuje, w jaki sposób dostawca zarządzanych usług IT z Czech przeniósł systemy swoich klientów z platformy hiperskalowej na pojedynczy wynajęty serwer dedykowany z prywatną chmurą Apache CloudStack. Firma uzyskała stałą wysokość rachunku, izolację klientów oraz wbudowane monitorowanie wykorzystania, jednocześnie obniżając koszty infrastruktury ponad czterokrotnie lub pięciokrotnie.

Kontekst

Klientem jest dostawca zarządzanych usług IT z Czech. Firma obsługuje kilkudziesięciu klientów B2B w regionie i zarządza całym ich środowiskiem IT: wsparciem dla stacji roboczych i serwerów, kopiami zapasowymi, monitorowaniem, pocztą elektroniczną, systemami księgowymi, siecią VPN oraz aplikacjami wewnętrznymi. Zasoby obliczeniowe są raczej narzędziem niż produktem: systemy klientów działają na maszynach wirtualnych, a dostawca usług zarządzanych (MSP) odpowiada za nie w ramach umów serwisowych.

Systemy po stronie serwerowej klientów były hostowane w publicznej chmurze AWS w regionie Frankfurtu. MSP udostępniało infrastrukturę oddzielnie dla każdego klienta i wliczało jej koszt do miesięcznej opłaty za wsparcie, stosując marżę wynoszącą średnio około 5%, jak podaje klient.

Cele i wyniki

Cele projektu pilotażowego były następujące:

Problem

Dla MSP infrastruktura w chmurze publicznej stanowiła koszt przenoszony na klienta. Rachunek składał się z dziesiątek pozycji i zmieniał się z miesiąca na miesiąc: opłaty godzinowe za procesor i pamięć, oddzielne opłaty za ruch wychodzący, pamięć masową i migawki. Nie dało się podać klientowi dokładnej kwoty przed końcem miesiąca. Zmiany cen były pokrywane przez dostawcę usług zarządzanych (MSP), podczas gdy zyski z części umów dotyczącej infrastruktury były ograniczone do marży wynoszącej około 5%.

Drugim problemem było zarządzanie. Niektórzy klienci chcieli tworzyć, zatrzymywać i przywracać swoje maszyny wirtualne bez kontaktowania się z pracownikami MSP. Udzielenie klientom dostępu do wspólnej infrastruktury chmurowej MSP było nie do przyjęcia, natomiast oddzielne konta dla każdego klienta wymagały indywidualnych konfiguracji uprawnień, osobnego rozliczania oraz osobnej księgowości dla każdego klienta.

MSP zwróciło się do firmy INTROSERV z prośbą o realizację projektu pilotażowego: wynajęcie serwera dedykowanego w europejskim centrum danych i wdrożenie na nim gotowej do użycia chmury prywatnej jako zamiennika hiper-skalera dla typowych systemów klientów, z opcją późniejszej rozbudowy do wielu węzłów.

Konfiguracja infrastruktury

Firma INTROSERV zapewniła serwer dedykowany umieszczony w centrum danych klasy Tier III w Holandii, z gwarantowaną dostępnością sieci na poziomie 99,99%.

Serwer główny:

• Procesor: 2x Intel Xeon Gold 6130 — 32 rdzenie fizyczne, 64 wątki, częstotliwość bazowa 2,10 GHz, turbo do 3,70 GHz

• Pamięć RAM: 256 GB REG ECC DDR4, z możliwością rozszerzenia do 1 TB

• NVMe: 2x 3,84 TB w programowym macierzy RAID 1 — 3,84 TB lokalnej pamięci masowej na dyski maszyn wirtualnych

• SATA: 4 x 14 TB w programowym macierzy RAID 10 — 28 TB na kopie zapasowe i pamięć pomocniczą

• Sieć: dwa porty 25 Gb/s, nieograniczony ruch; prywatna sieć VLAN 10 Gb/s

• Zarządzanie: iDRAC

• Ochrona przed atakami DDoS: 20 Gb/s

• Redundantne zasilanie

Serwer rezerwowy dla maszyn wirtualnych jest podłączony do serwera głównego za pośrednictwem prywatnej sieci VLAN o przepustowości 10 Gb/s.

Usługa tworzenia kopii zapasowych firmy INTROSERV, oparta na rozwiązaniu NAKIVO Backup & Replication, kosztuje 49 euro miesięcznie za 5 TB. Tworzona jest kopia zapasowa całego serwera: systemu operacyjnego hosta, konfiguracji CloudStack oraz bazy danych serwera zarządzającego. W przypadku awarii serwera system jest wdrażany na nowym sprzęcie na podstawie tej kopii zapasowej, po czym maszyny wirtualne są przywracane z serwera kopii zapasowych.

Konfiguracja spełnia wymagania dotyczące odporności na awarie na poziomie pojedynczego komputera:

• Sieć: dwa niezależne porty o przepustowości 25 Gb/s są połączone w łącze odporne na awarie. Awaria jednego portu lub łącza nie powoduje przerwania działania maszyn wirtualnych.
• Zasilanie: dwa zasilacze. Awaria jednego z nich nie powoduje wyłączenia serwera.
• Dyski: wszystkie dyski są skonfigurowane w macierzach RAID. Awaria jednego dysku NVMe lub jednego dysku SATA nie powoduje utraty danych ani przestoju serwera.
• Pamięć masowa: dyski maszyn wirtualnych są przechowywane w lokalnej macierzy NVMe bez konieczności korzystania z pamięci sieciowej pomiędzy hiperwizorem a danymi. Zapewnia to minimalne opóźnienia wejścia/wyjścia dla baz danych i systemów księgowych klientów.
• Kopie zapasowe: kopie zapasowe maszyn wirtualnych są przesyłane na oddzielny serwer fizyczny przez prywatną sieć o przepustowości 10 Gb/s, bez korzystania z portów zewnętrznych i bez ponoszenia opłat za transfer danych. Pełna kopia zapasowa serwera jest przechowywana w pamięci masowej usługi kopii zapasowych o pojemności 5 TB.

Rachunek za serwer obejmuje wszystko, co w przypadku dostawcy hiperskalowego byłoby rozliczane osobno: ruch sieciowy, redundantną sieć i zasilanie, odporność na awarie dysków, szybką pamięć lokalną, prywatną sieć łączącą z serwerem kopii zapasowych oraz zdalne zarządzanie za pośrednictwem iDRAC. Dwie pozycje związane z kopiami zapasowymi są pozycjami o stałym koszcie.

Rozwiązanie

Zespół INTROSERV wdrożył Apache CloudStack na serwerze w konfiguracji jednowęzłowej: serwer zarządzający i host KVM działają na tej samej maszynie. Prace zostały wykonane w ramach usługi administrowania systemem rozliczanej godzinowo, po czym zarządzanie platformą zostało przekazane klientowi.

Dlaczego Apache CloudStack zamiast Proxmox VE

Obie platformy są oprogramowaniem typu open source i działają w środowisku KVM. Proxmox VE jest dystrybuowany na licencji AGPLv3 i działa bezpłatnie; płatna subskrypcja za każdy gniazd procesora jest wymagana jedynie w celu uzyskania dostępu do repozytorium aktualizacji dla przedsiębiorstw oraz wsparcia technicznego od dostawcy. Apache CloudStack jest dystrybuowany na licencji Apache License 2.0 bez opłat za gniazda, rdzenie lub maszyny wirtualne. Licencjonowanie nie było czynnikiem decydującym. Kluczowymi czynnikami były cztery funkcje wbudowane w CloudStack, które w Proxmox VE wymagają narzędzi zewnętrznych:

• Wielodostępność. Domeny, konta i projekty z limitami zasobów i przydziałami dla każdego klienta. Klienci, którzy chcieli zarządzać własną flotą maszyn wirtualnych, otrzymali własne konto z dedykowaną rolą: mogą widzieć wyłącznie swoje zasoby, tworzyć i zatrzymywać maszyny wirtualne oraz wykonywać migawki i przywracanie stanu w ramach przydzielonego limitu. Egzekwowanie limitów odbywa się za pośrednictwem platformy, a nie w ramach procesu ręcznego.
• Śledzenie wykorzystania. Wbudowany serwer Usage Server rejestruje zużycie procesora, pamięci, dysku i ruchu dla każdego konta; wtyczka Quota utrzymuje salda w oparciu o plany cenowe. Dane do wewnętrznych obliczeń kosztów i rozliczeń z klientami są pobierane bezpośrednio z platformy, a nie gromadzone ręcznie.
• Kubernetes. Usługa CloudStack Kubernetes Service wdraża i aktualizuje klastry Kubernetes dla klientów z poziomu konsoli lub za pośrednictwem API, zapewniając skalowanie węzłów oraz możliwość podłączania dysków CloudStack jako woluminów klastra. Klienci korzystający z aplikacji kontenerowych otrzymują klaster bez konieczności korzystania z oddzielnej platformy.
• Usługi sieciowe. Izolowane sieci z wirtualnym routerem dla każdego klienta: zapora sieciowa, NAT, równoważenie obciążenia i VPN.

Dodanie nowego klienta stało się standardową operacją: utworzenie domeny i konta, izolowanej sieci z wirtualnym routerem, limitu oraz maszyn wirtualnych na podstawie gotowego szablonu. Wszystko można wykonać z poziomu konsoli lub za pośrednictwem API oraz dostawcy Terraform w ciągu kilku minut, zamiast poświęcać godziny na ręczną konfigurację w konsoli dostawcy usług chmurowych o ogromnej skali. Migawki zapewniają punkty przywracania przed aktualizacjami systemów klientów, a szablony zapewniają identyczne obrazy bazowe dla wszystkich klientów.

Poziom odporności na awarie

Dostępność systemu jest ważna dla klientów dostawcy usług zarządzanych (MSP), ale obciążenie — systemy księgowe, poczta elektroniczna i aplikacje wewnętrzne — nie wymaga wysokiej dostępności z automatycznym restartem maszyn wirtualnych na innym hoście w ciągu kilku minut. Pierwsza grupa klientów nie posiada systemów wymagających ciągłej pracy, w przypadku których kilkugodzinna przerwa w działaniu spowodowałaby bezpośrednie straty; dla nich akceptowalne jest zaplanowane okno konserwacyjne lub przywrócenie danych z kopii zapasowej.

W związku z tym klaster o wysokiej dostępności uznano za zbyt rozbudowany na potrzeby projektu pilotażowego: wymaga on wielu węzłów i współdzielonej pamięci masowej. Wybrano pojedynczy węzeł z redundancją na poziomie maszyny, a konfiguracja ta okazała się wystarczająca. Awarie komponentów są zabezpieczone na poziomie sprzętowym: dwa połączone porty 25 Gb/s, dwa zasilacze oraz wszystkie dyski w macierzach RAID. Pogorszenie stanu macierzy i niewystarczające zasoby hosta są monitorowane proaktywnie, a dyski są wymieniane, zanim problem wpłynie na maszyny wirtualne.

Całkowita awaria serwera jest zabezpieczona dwoma poziomami kopii zapasowych: kopia zapasowa hosta w NAKIVO przywraca system operacyjny i CloudStack na nowym serwerze bez konieczności ponownej konfiguracji, natomiast kopie zapasowe maszyn wirtualnych przywracają działanie systemów klientów. Wysoka dostępność jest zaplanowana na etap rozbudowy, kiedy infrastruktura powiększy się do wielu węzłów — dodatkowe hosty zostaną dodane do tej samej platformy CloudStack bez konieczności zmiany platformy.

Zakończone prace

1. Przygotowanie serwera: instalacja systemu operacyjnego, macierze RAID oparte na oprogramowaniu (RAID 1 na NVMe, RAID 10 na SATA), połączenie dwóch portów 25 Gb/s w łącze odporne na awarie oraz konfiguracja prywatnej sieci VLAN do serwera kopii zapasowych.

2.Instalacja serwera zarządzającego CloudStack oraz agenta KVM na pojedynczym węźle, konfiguracja bazy danych i maszyn wirtualnych systemu.

3. Utworzenie strefy, poda i klastra; pamięć podstawowa na macierzy NVMe, a pamięć pomocnicza na macierzy SATA.

4. Model sieciowy: izolowane sieci z wirtualnym routerem dla każdego klienta, zakres adresów IP publicznych, reguły zapory sieciowej oraz NAT.

5. Szablony systemów operacyjnych (Ubuntu, Debian, AlmaLinux, Windows Server) oraz oferta usług dla trzech standardowych rozmiarów maszyn wirtualnych.

6. Tworzenie kopii zapasowych maszyn wirtualnych na oddzielnym serwerze kopii zapasowych za pośrednictwem prywatnej sieci o przepustowości 10 Gb/s; podłączenie serwera do usługi tworzenia kopii zapasowych firmy INTROSERV opartej na rozwiązaniu NAKIVO wraz z harmonogramem tworzenia pełnych kopii zapasowych serwerów.

7. Domeny i konta dla klientów MSP, role i limity zasobów, aktywacja wtyczki Usage Server i Quota; aktywacja usługi CloudStack Kubernetes oraz rejestracja obrazów ISO zawierających pliki binarne Kubernetes.

8. Proaktywne monitorowanie: stan systemu operacyjnego hosta (procesor, pamięć, miejsce na dysku, interfejsy sieciowe, usługi systemowe) oraz macierze dyskowe (stan RAID, wskaźniki SMART dysków), z wysyłaniem powiadomień do inżynierów INTROSERV.

9. Testowanie: testowanie maszyn wirtualnych we wszystkich trzech rozmiarach, migawek i przywracania stanu poprzedniego, dostępu do sieci zewnętrznej, tworzenia kopii zapasowych maszyn wirtualnych oraz tworzenia pełnych kopii zapasowych serwerów.

10. Przekazanie klientowi: konsola CloudStack, klucze API, dokumentacja konfiguracyjna oraz dostęp do iDRAC.

Całkowity zakres prac wyniósł 16 godzin. Po przekazaniu systemu firma INTROSERV zapewnia wsparcie techniczne w oparciu o alerty monitorujące lub zgłoszenia klientów: wymiana dysków, aktualizacje hiperwizora i serwera zarządzającego oraz rozszerzenie konfiguracji.

Umieszczanie maszyn wirtualnych

W trakcie projektu pilotażowego na węzeł przeniesiono 20 maszyn wirtualnych obsługujących systemy klientów w trzech standardowych rozmiarach. Pamięć jest przydzielana bez nadmiernego przydziału: 64 GB pozostaje dostępne dla serwera zarządzającego, maszyn wirtualnych systemu oraz kolejnych systemów klientów. Wszystkie dyski maszyn wirtualnych znajdują się w lokalnej macierzy NVMe serwera, co zapewnia każdej maszynie wirtualnej wydajność dyskową, za którą zgodnie z cennikiem pamięci masowej dostawcy hiperskalowego za gwarantowaną liczbę operacji IOPS naliczono by oddzielną opłatę.

Wirtualne procesory są przydzielane z minimalnym nadmiernym przydziałem — 72 vCPU dla 64 wątków — podczas gdy rzeczywiste wykorzystanie procesora w godzinach pracy nie przekracza 50%. Na macierzy NVMe pozostaje około 700 GB wolnego miejsca. Projekt ma charakter pilotażowy, a ta rezerwa pojemności została zaplanowana celowo: dodatkowe systemy klientów można dodawać do tego samego węzła bez zmiany konfiguracji, a rozszerzenie pamięci do 1 TB i dodanie dysków kilkukrotnie zwiększa pojemność węzła.

Infrastruktura jako przewaga strategiczna

Rozwiązanie wdrożone przez zespół INTROSERV zastąpiło dostawcę typu hyperscaler jako źródło zasobów obliczeniowych dla systemów klientów dostawcy usług zarządzanych (MSP). Pojedynczy wynajęty serwer z oprogramowaniem Apache CloudStack przejął obsługę pierwszej grupy 20 maszyn wirtualnych, zapewniając możliwość rozbudowy oraz poziom odporności na awarie odpowiedni do obciążenia.

Klient zyskał możliwości, które nie były dostępne w chmurze publicznej: izolację klientów i śledzenie wykorzystania na poziomie platformy, samoobsługę dla klientów posiadających własne konta, klastry Kubernetes zarządzane z tej samej konsoli oraz proaktywne monitorowanie hosta i macierzy dyskowych. W koszt serwera wliczone są: nadmiarowość sieciowa i zasilania, dyski chronione w macierzy RAID, lokalna pamięć NVMe, nieograniczona liczba portów o przepustowości 25 Gb/s oraz ochrona przed atakami DDoS.

Aspekty ekonomiczne

Większość ruchu przechodzi przez serwery VPN klientów: ruch wychodzący z węzła wynosi 20–35 TB miesięcznie. Równoważny zestaw zasobów od poprzedniego dostawcy — 20 maszyn wirtualnych o tym samym profilu, pamięć masowa, migawki oraz ten sam wolumen ruchu wychodzącego przy obecnych stawkach obowiązujących w regionie Frankfurtu — kosztuje około 4 000–5 100 euro miesięcznie, czyli około 54 000 euro rocznie. Z tej kwoty od 1 500 do 2 600 euro przypada na ruch: u dostawcy hiperskalowego każdy gigabajt przesyłany przez VPN do pracowników klientów jest rozliczany osobno.

INTROSERV kosztuje 1 017 euro miesięcznie: 671 euro za serwer główny, 157 euro za serwer zapasowy, 49 euro za pełną kopię zapasową serwera, a pozostała kwota pokrywa administrację na żądanie oraz amortyzację jednorazowego wdrożenia. W cenie wynajmu serwera zawarte są dwa porty o przepustowości 25 Gb/s z nieograniczonym ruchem, więc ruch wychodzący generowany przez systemy klienta nie ma wpływu na wysokość rachunku, niezależnie od tego, czy wynosi on 35, czy 50 TB miesięcznie.

Podstawa kosztowa jest od czterech do pięciu razy niższa, kwota jest stała i znana przed początkiem miesiąca. Pozwoliło to klientowi uwzględnić infrastrukturę w stałej opłacie za wsparcie, zaoferować klientom korzystniejsze warunki oraz zwiększyć rentowność części umów dotyczącej infrastruktury. Wraz z rozwojem portfela klientów różnica w stosunku do dostawców hiperskalowych rośnie — rachunek za serwery nie zależy od ruchu ani zmian cen instancji. Klient był w pełni zadowolony z kosztów rozwiązania.

Kolejne kroki

Otwarta platforma bez opłat licencyjnych rozwiązała kwestię skalowalności: rozszerzenie pamięci do 1 TB kilkakrotnie zwiększa pojemność węzła, a drugi węzeł można dodać do istniejącego klastra CloudStack bez konieczności zmiany narzędzi. Dane klientów pozostają na dedykowanych serwerach w europejskim centrum danych, w obszarze kontrolowanym przez klienta. Dla firmy obsługującej klientów w UE zgodnie z wymogami RODO jest to warunek obowiązkowy. Po zakończeniu fazy pilotażowej dostawca usług zarządzanych (MSP) podejmie decyzję, czy przenieść kolejne grupy systemów klientów na platformę CloudStack.

Czy Twoja infrastruktura u dostawcy hiper-skalowalnego kosztuje więcej niż powinna, a wysokość rachunku pozostaje niemożliwa do przewidzenia? Powierz migrację zespołowi INTROSERV: dobierzemy odpowiednią konfigurację serwerów, wdrożymy Apache CloudStack i przekażemy gotową do użycia chmurę prywatną.