serwer w chmurze

Serwer w chmurze to infrastruktura hostowana u zewnętrznego dostawcy, rozliczana według zużycia zasobów.

Jak działa serwer w chmurze

Serwer w chmurze to zasób obliczeniowy udostępniany przez zewnętrznego dostawcę w jego centrum danych. Użytkownik korzysta z procesora, pamięci operacyjnej, przestrzeni dyskowej oraz połączenia sieciowego bez konieczności kupowania fizycznej maszyny i instalowania jej we własnej serwerowni. Dostawca odpowiada za działanie infrastruktury fizycznej, zasilanie, chłodzenie oraz połączenia między urządzeniami. Klient otrzymuje natomiast określoną konfigurację systemu i dostęp administracyjny zgodny z wybranym modelem usługi.

Rozliczenie zwykle zależy od czasu pracy instancji, liczby przydzielonych jednostek procesora, ilości pamięci RAM, zajętej przestrzeni dyskowej oraz transferu danych. Poszczególne elementy mogą być naliczane osobno, dlatego koszt serwera nie zawsze wynika wyłącznie z jego miesięcznego czasu działania. Przykładowo, zatrzymanie instancji może ograniczyć opłatę za część obliczeniową, ale nie musi usuwać kosztu przypisanego do dysków lub kopii zapasowych. Szczegółowe zasady zależą od konkretnej platformy i jej cennika.

Elementy konfiguracji i dostęp sieciowy

Podstawowa konfiguracja serwera w chmurze obejmuje system operacyjny, liczbę wirtualnych rdzeni procesora, pojemność pamięci RAM, rodzaj dysku oraz parametry sieciowe. Dyski SSD zapewniają krótszy czas dostępu do danych niż klasyczne dyski talerzowe, ale ich wydajność może zależeć od limitu operacji wejścia i wyjścia określonego przez dostawcę. Przy wyborze zasobu należy uwzględnić nie tylko pojemność, lecz także przewidywaną liczbę operacji na plikach, wielkość transferu oraz zapotrzebowanie aplikacji na pamięć.

Serwer może otrzymać prywatny adres IP używany wewnątrz infrastruktury dostawcy oraz publiczny adres IP dostępny z internetu. Do zdalnego logowania w systemach Linux najczęściej stosuje się protokół SSH, standardowo obsługiwany przez serwer nasłuchujący na porcie TCP 22, choć port może zostać zmieniony w konfiguracji. W systemach Windows zdalny pulpit korzysta z protokołu RDP, którego domyślny port to TCP 3389. Otwarcie portów powinno być ograniczone do wymaganych usług, a reguły zapory sieciowej powinny określać dozwolone adresy źródłowe i kierunki ruchu.

Skalowanie, kopie i ciągłość pracy

Jedną z cech serwera w chmurze jest możliwość zmiany parametrów bez wymiany fizycznego komputera. Zwiększenie liczby rdzeni procesora lub pamięci może wymagać ponownego uruchomienia instancji, zależnie od platformy i rodzaju operacji. Rozbudowa przestrzeni dyskowej również może wymagać późniejszego powiększenia partycji oraz systemu plików wewnątrz systemu operacyjnego. Samo zwiększenie rozmiaru dysku przydzielonego przez dostawcę nie zawsze powoduje automatyczne udostępnienie dodatkowego miejsca aplikacjom.

Kopia zapasowa serwera jest oddzielnym mechanizmem od samego uruchomienia instancji. Może obejmować obraz całego dysku, migawkę określonego woluminu albo kopię wybranych plików. Migawka zapisana w tej samej infrastrukturze nie musi chronić przed każdą awarią, błędną konfiguracją lub przypadkowym usunięciem zasobu. Poprawny plan odtwarzania powinien określać częstotliwość kopii, czas przechowywania, miejsce ich składowania oraz sposób sprawdzenia, czy dane można rzeczywiście przywrócić. Istotne są także parametry RPO i RTO: pierwszy określa akceptowalną utratę danych wyrażoną w czasie, a drugi dopuszczalny czas przywrócenia usługi.

Diagnostyka problemów z serwerem w chmurze

Awaria serwera w chmurze może wynikać z problemu infrastruktury dostawcy, błędnej konfiguracji systemu, wyczerpania pamięci, przepełnienia dysku, przeciążenia procesora albo nieprawidłowej reguły sieciowej. Diagnostykę rozpoczyna się od sprawdzenia statusu instancji w panelu dostawcy, czasu wystąpienia problemu oraz komunikatów systemowych. W systemie Linux pomocne są między innymi polecenia uptime, free -h, df -h, top oraz journalctl. Pokazują one odpowiednio czas pracy, zużycie pamięci, dostępne miejsce, obciążenie procesora i wpisy dziennika systemowego.

Jeżeli serwer działa, ale aplikacja nie odpowiada, trzeba rozdzielić problem usługi od problemu sieciowego. Sprawdzenie rozwiązywania nazwy DNS, odpowiedzi na żądanie HTTP oraz nasłuchiwania portu pozwala ustalić, na którym etapie występuje błąd. Warto porównać obciążenie zasobów z okresem poprawnego działania i sprawdzić ostatnie zmiany w konfiguracji. Przy utracie dostępu administracyjnego należy zweryfikować reguły zapory, klucze lub hasła, stan dysku oraz dostępność konsoli awaryjnej udostępnianej przez operatora. Diagnostyka wymaga odróżnienia awarii samego serwera od niedostępności łącza, błędu DNS lub problemu po stronie aplikacji korzystającej z tego zasobu.