VPS zarządzany czy niezarządzany: co wybrać?

Zarządzany czy niezarządzany VPS: krótka odpowiedź

Wybór między zarządzanym a niezarządzanym VPS dotyczy zakresu obowiązków, a nie produktu. W przypadku VPS niezarządzanego użytkownik odpowiada za instalowanie poprawek, zaporę sieciową, kopie zapasowe, monitorowanie oraz ponowne uruchomienie serwera o 2:00. W przypadku VPS zarządzanego dostawca wykonuje część tych zadań. Zakres tej części może się znacznie różnić w zależności od usługodawcy. Jedynym użytecznym sposobem porównania jest zestawienie zadań przejmowanych przez każdy plan z liczbą własnych godzin pracy i ceną usługi.

Nie istnieje standardowa definicja określenia zarządzany. U jednego usługodawcy oznacza ono instalowanie poprawek systemu operacyjnego oraz obsługę zgłoszeń przez pracownika. U innego oznacza zainstalowany panel sterowania, podczas gdy za wszystko powyżej tego poziomu odpowiada użytkownik. U trzeciego oznacza pisemną umowę o świadczenie usług z określonym czasem reakcji. Dwa plany opisane tym samym określeniem mogą różnić się pod każdym istotnym względem. Dlatego przed zapoznaniem się z ceną należy przeczytać dokument określający zakres usługi. Jeśli nadal nie ustalono, do czego ma służyć serwer, lepszym pytaniem, od którego należy zacząć, jest co właściwie można zrobić za pomocą VPS.

Zadania, za które ktoś musi odpowiadać

Każdy uruchomiony serwer wymaga wykonania tego samego zestawu zadań. W planie niezarządzanym odpowiada się za nie samodzielnie. W planie zarządzanym płaci się za przejęcie części tych obowiązków. Należy przejść przez listę i przypisać każdemu zadaniu osobę odpowiedzialną.

• Aktualizowanie systemu operacyjnego oraz ponowne uruchomienia wymagane przez aktualizacje jądra.
• Reguły zapory sieciowej, które należy aktualizować po dodaniu lub usunięciu usług. Podstawy zapory ufw dla VPS opisują początkowy zestaw reguł.
• Dostęp SSH: obsługa kluczy, wyłączenie logowania za pomocą hasła, unieważnienie klucza po odejściu użytkownika oraz sposób odzyskania dostępu po zablokowaniu sobie dostępu.
• Kopie zapasowe, kopia przechowywana poza serwerem oraz przywracanie, które zostało faktycznie przeprowadzone.
• Monitorowanie, czyli sprawdzanie, czy serwer jest osiągalny, na dysku jest wystarczająca ilość miejsca, usługa nadal działa, a certyfikat nie wygasł.
• Przeglądanie logów oraz reagowanie na nieprawidłowości wykryte w tych logach.
• Konfiguracja usług serwera WWW, bazy danych, reverse proxy oraz kolejki, jeśli jest używana.
• Odnawianie certyfikatów oraz naprawa problemów występujących po zatrzymaniu automatycznego odnawiania.
• Wydajność i pojemność, czyli wykrywanie wyczerpania pamięci, zanim zrobi to mechanizm out of memory (OOM) killer.
• Reagowanie na incydenty, czyli dostępność i możliwość kontaktu o godzinie, której nie można samodzielnie wybrać.

Większość tych zadań jest rutynowa i można ją przekazać skryptowi. Reagowania na incydenty nie można jednak w ten sposób zautomatyzować, ponieważ wymaga osoby zdolnej do podjęcia decyzji. To jest właściwa usługa oferowana w ramach planu zarządzanego. Dlatego na dalszej liście kontrolnej większość pytań dotyczy zakresu wsparcia, a nie aktualizowania systemu.

Czego zwykle nie obejmuje zarządzanie

W tym obszarze klienci często otrzymują mniej, niż oczekują, dlatego należy ustalić zakres dokładnie. Umowa zarządzana zwykle obejmuje system operacyjny i oprogramowanie zainstalowane przez dostawcę. Zakres kończy się na granicy aplikacji.

Za własny kod odpowiada użytkownik. Błąd 500 generowany przez aplikację nie jest awarią serwera. Dostawca potwierdzi, że proces serwera WWW działa, i przekaże zgłoszenie z powrotem użytkownikowi. Jest to uzasadniona granica odpowiedzialności. Jest to również największa różnica między oczekiwaniami klientów a faktycznie zakupioną usługą.

Problemy na poziomie aplikacji zwykle nie są objęte zakresem. Powolne zapytanie do bazy danych, plugin uszkodzony podczas aktualizacji, nieprawidłowo skonfigurowana pamięć podręczna lub kolejka pocztowa, która przestała się opróżniać, znajdują się powyżej tej granicy, nawet jeśli dostawca zainstalował oprogramowanie, od którego zależą.

Odzyskiwanie większości danych nie jest objęte zakresem. Kopie zapasowe dostawcy chronią obraz całego serwera utworzony przez dostawcę i są przeznaczone na wypadek awarii sprzętu hosta. Rzadko są przygotowane na sytuację, w której usunięto wiersz, wykonano nieprawidłową migrację lub uszkodzono plik sześć tygodni temu, a problem zauważono dopiero dziś. Należy ustalić okres przechowywania kopii, możliwość odzyskania pojedynczego pliku oraz to, kto wykonuje przywracanie.

Za zainstalowane przez użytkownika oprogramowanie odpowiada użytkownik. Po zainstalowaniu Docker dostawca zwykle odpowiada za hosta, a użytkownik za wszystko, co znajduje się wewnątrz kontenerów.

Ręczne zmiany mogą unieważnić wsparcie. Niektóre umowy wyłączają dany komponent z zakresu wsparcia, gdy klient bezpośrednio zmodyfikuje jego konfigurację. Należy to sprawdzić przed planowanym dostrajaniem konfiguracji.

Wyceń własny czas względem miesięcznej różnicy

Weź obie przedstawione oferty i zapisz miesięczną różnicę. Ta kwota odpowiada opłacie pobieranej przez dostawcę za usunięcie pozycji z powyższej listy. Następnie określ wartość pracy po swojej stronie.

• Ile wart jest jedeną godzina Twojego czasu i ile godzin miesięcznie zajmuje ta lista po zautomatyzowaniu?
• Ile kosztuje jedna godzina przestoju usługi działającej na tym serwerze?

Stabilny serwer Ubuntu z automatycznymi aktualizacjami i monitorowaniem zewnętrznym wymaga bardzo niewiele rutynowej uwagi. W większości miesięcy nie wymaga jej wcale. Po przekazaniu rutynowych zadań skryptowi ich obsługa jest tania. Kosztowne są przerwy w pracy, a właśnie obsługę takich przerw sprzedaje plan zarządzany. Jeśli serwer obsługuje projekt hobbystyczny, awaria nic nie kosztuje, więc oczywistym wyborem jest serwer niezarządzany. Jeśli serwer obsługuje zamówienia, należy dokładnie sprawdzić, czy umowa wsparcia rzeczywiście skraca czas trwania awarii. Dostawca zarządzany nadal musi przeczytać zgłoszenie, odtworzyć problem i podjąć działania.

Różnica rośnie także wraz z liczbą serwerów. Opłaty za zarządzanie są zwykle naliczane za każdy serwer, natomiast automatyzację tworzy się raz i kopiuje. Drugi serwer zmniejsza o połowę efektywny koszt skryptu napisanego dla pierwszego. Przed zaakceptowaniem opłaty za każdy serwer należy przeczytać jak zarządzać wieloma serwerami Linux. Wartość bazowa po obu stronach porównania jest określona w artykule ile VPS faktycznie kosztuje miesięcznie, a porównanie VPS z serwerem dedykowanym ma znaczenie, gdy obciążenie jest na tyle duże, że dodatkowy koszt zarządzania stanowi błąd zaokrąglenia.

Pytania, które należy zadać hostingodawcy przed opłaceniem zarządzanej usługi premium

Pytania należy zadać przed dokonaniem płatności i poprosić o odpowiedzi na piśmie. Strona sprzedażowa nie jest dokumentem zakresu usług.

1. Co dokładnie obejmuje usługa? Należy poprosić o listę zadań, a nie o materiał reklamowy.
2. Czy pomoc techniczna obejmuje oprogramowanie instalowane przeze mnie, czy tylko oprogramowanie zainstalowane przez hostingodawcę?
3. Czy poprawki są instalowane automatycznie? Czy serwer jest uruchamiany ponownie w związku z aktualizacjami jądra bez uprzedniego pytania o zgodę?
4. Kto ponosi odpowiedzialność, jeśli zastosowana poprawka spowoduje awarię aplikacji?
5. Czy wykonywane są kopie zapasowe? Gdzie są przechowywane, jak długo są przechowywane i kto wykonuje przywracanie?
6. Czy ostatnio przywracano serwer klienta? Ile czasu to zajęło?
7. Jaki jest czas odpowiedzi na zgłoszenie? Czy różni się on o 03:00 w niedzielę?
8. Czy zachowywany jest dostęp do konta root? Czy korzystanie z niego ogranicza zakres obsługi?
9. Czy opłata jest naliczana za serwer, czy za konto?
10. Co można przenieść po zakończeniu współpracy? Konfiguracja znajdująca się w autorskim panelu sterowania może być trudna do wyeksportowania.

Pytanie 5 rozstrzyga większość pozostałych kwestii. Hostingodawca, który udziela na nie precyzyjnej odpowiedzi, pokazuje, że wcześniej wykonywał takie operacje. Niejasna odpowiedź oznacza, że przywracanie nigdy nie było testowane, a nietestowana kopia zapasowa jest tylko kopią. Pytanie 5 ma również wymiar lokalizacyjny: miejsce fizycznego przechowywania kopii jest w równym stopniu kwestią prawną i techniczną, a to, co naprawdę ma znaczenie przy wyborze kraju hostingu zostało omówione w tym kontekście.

Rozwiązanie pośrednie: plan niezarządzany i automatyzacja

Większość odbiorców technicznych nie chce żadnej ze skrajności. Potrzebny jest plan niezarządzany, w którym rutynowe zadania wykonuje maszyna, a użytkownik zajmuje się tym, czego maszyna nie potrafi ocenić. Należy skonfigurować to pierwszego dnia. Pierwsze dziesięć minut na nowym VPS to praktyczny punkt wyjścia dla każdego, kto wybiera plan niezarządzany. Zabezpieczanie dostępu SSH należy wykonać podczas tej samej pierwszej sesji.

Automatyczne aktualizacje zabezpieczeń

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Ten plik powinien teraz zawierać APT::Periodic::Update-Package-Lists "1"; oraz APT::Periodic::Unattended-Upgrade "1";. Brak pliku albo 0 w którymkolwiek wierszu oznacza, że nic się nie wykonuje i nie zostanie wyświetlone żadne powiadomienie.

Należy przetestować konfigurację bez zmieniania systemu. Pakiet ma nazwę unattended-upgrades, natomiast polecenie występuje w liczbie pojedynczej:

sudo unattended-upgrade --dry-run --debug

Dane wyjściowe zawierają listę wszystkich rozpatrywanych pakietów i kończą się wierszem takim jak No packages found that can be upgraded unattended, gdy nie ma oczekujących aktualizacji. Rzeczywiste wykonania są zapisywane w /var/log/unattended-upgrades/unattended-upgrades.log, dlatego należy sprawdzać ten plik zamiast zgadywać.

Aktualizacja jądra nie zacznie działać przed ponownym uruchomieniem maszyny, ponieważ uruchomione jądro jest ładowane podczas rozruchu. Plik /var/run/reboot-required pojawia się, gdy wymagane jest ponowne uruchomienie. Można monitorować ten plik albo pozwolić maszynie obsłużyć to automatycznie w /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" wstrzymuje ponowne uruchomienie, gdy ktoś jest zalogowany. Jest to bezpieczniejsze na serwerze używanym interaktywnie i bezużyteczne na serwerze, do którego nikt się nie loguje. Pełna konfiguracja unattended upgrades w Ubuntu opisuje składnię listy blokowanych pakietów oraz opcje poczty elektronicznej.

Monitorowanie wykonywane poza serwerem

Monitor działający na serwerze nie może poinformować, że serwer jest niedostępny, ponieważ sam również jest wtedy niedostępny. Kontrolę należy umieścić na drugim hoście albo w zewnętrznej usłudze. Uptime Kuma do monitorowania dostępności to standardowe rozwiązanie self-hosted. Powinno działać na innej maszynie niż monitorowany serwer.

Co najmniej należy monitorować cztery elementy: dostępność, wykorzystanie dysku, odpowiedzi aplikacji na jej rzeczywistym porcie oraz datę wygaśnięcia certyfikatu. Wykorzystanie dysku jest elementem, który często powoduje problemy. Plik dziennika lub baza danych, które codziennie zwiększają rozmiar, mogą zatrzymać serwer w chwili, której nie przewiduje żaden inny mechanizm. Pierwszym objawem jest często usługa, która nie może zapisywać danych i kończy działanie.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Należy także dodać heartbeat. Timer na serwerze wywołuje URL po każdej pomyślnej kopii zapasowej lub kontroli stanu, a monitor generuje alert, gdy wywołania przestają przychodzić. Dzięki temu niedostępny serwer sam powoduje alert. Kontrola wykonywana wyłącznie przez odpytywanie nie może tego zapewnić, gdy uszkodzeniu uległa ścieżka sieciowa.

Kopie zapasowe co najmniej raz odtworzone

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init wyświetla created restic repository <id> at sftp:... jeden raz. Uruchomienie tego polecenia względem istniejącego repozytorium kończy się błędem zamiast nadpisania danych. Jest to wymagane zachowanie. Kopię tego hasła należy przechowywać poza serwerem. Bez niego repozytorium jest nieczytelne i nie ma możliwości odzyskania danych.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots powinno wyświetlić właśnie utworzone zadanie z dzisiejszą datą. restic check sprawdza strukturę repozytorium i wyświetla no errors were found. Teraz należy wykonać krok, który większość osób pomija:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

Oczekiwany plik albo istnieje, albo go nie ma. Sprawdzenie tego teraz zajmuje dziesięć minut. Następnie należy uruchamiać zadanie za pomocą timera, aby nie zależało od użytkownika. Należy utworzyć /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Oraz /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers wyświetla następne uruchomienie oraz pozostały czas. Pusty wynik oznacza, że włączono usługę zamiast timera. Jest to najczęstszy błąd w tym miejscu. Persistent=true uruchamia pominięte zadanie po następnym rozruchu, dzięki czemu maszyna wyłączona przez noc nadal wykona kopię zapasową. Kopie zapasowe Restic na VPS dokładniej opisują układ repozytorium i zasady przechowywania danych. Usługi i timery systemd wyjaśniają pliki jednostek wiersz po wierszu.

Czego automatyzacja nie zapewnia

Automatyzacja nie zastępuje oceny sytuacji. Automatyczne ponowne uruchomienie o 02:00 nastąpi niezależnie od tego, czy aplikacja uruchomi się poprawnie. Należy więc potwierdzić, że każda usługa uruchamia się samodzielnie, a następnie celowo ponownie uruchomić system, gdy użytkownik może obserwować jego działanie:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade może także zainstalować pakiet, który uszkodzi działanie aplikacji. Żaden element procesu nie wykryje tego samodzielnie. Wykryje to monitor. Dlatego monitorowanie jest niezbędne, gdy aktualizacje są automatyczne. Maszyna obsługuje rutynowe zadania. Obsługa incydentu nadal należy do użytkownika.

Kiedy zarządzanie jest warte swojej ceny

Należy uczciwie ocenić usługę zarządzaną. W czterech sytuacjach jest ona właściwym wyborem.

• Nikt w zespole nie administruje systemem Linux, a zatrudnienie takiej osoby nie jest planowane.
• Wymóg zgodności wskazuje podmiot odpowiedzialny za instalowanie poprawek, a odpowiedzialność ta nie może spoczywać na użytkowniku.
• Stos technologiczny należy do specjalizacji dostawcy, więc jego zespół pomocy technicznej miał już do czynienia z podobną awarią.
• Osoba, która w przeciwnym razie wykonywałaby te zadania, jest najdroższym pracownikiem, a koszt jednej jej godziny przewyższa miesięczną opłatę za plan premium.

Usługa zarządzana nie jest automatycznie bezpieczniejsza. Plany zarządzane rzeczywiście umożliwiają szybsze instalowanie poprawek niż w przypadku nieuwagi właściciela. Jest to realna korzyść. Dostawcy często instalują również panel sterowania. Jest to duża aplikacja dostępna z sieci, z własną stroną logowania i historią podatności. Taki kompromis może być uzasadniony, ale nadal jest to kompromis.

Decyzja zawsze sprowadza się do tej samej listy. Należy zapisać dziesięć zadań, wskazać osobę odpowiedzialną za każde z nich przy każdej ofercie, a następnie porównać różnicę z wartością jednej godziny własnej pracy. Większość czytelników technicznych, którzy to zrobią, wybiera ostatecznie usługę niezarządzaną i przekazuje rutynowe zadania do wykonania przez timer. Jest to uzasadniona decyzja, a nie tylko tańsza opcja.

FAQ

Jaka jest różnica między zarządzanym a niezarządzanym VPS?

Niezarządzany VPS zapewnia maszynę i nic więcej, dlatego za aktualizacje, firewall, kopie zapasowe, monitorowanie oraz ponowne uruchomienie po aktualizacji jądra odpowiada użytkownik. W przypadku zarządzanego VPS część tych zadań przejmuje dostawca, zwykle w zakresie systemu operacyjnego i oprogramowania zainstalowanego przez dostawcę. Dokładny zakres ustala każdy dostawca indywidualnie, a nie samo określenie usługi. Przed porównaniem dwóch cen należy poprosić na piśmie o zakres odpowiedzialności określony dla poszczególnych zadań.

Czy zarządzany VPS oznacza, że nie potrzebuję własnych kopii zapasowych?

Nie. Kopie zapasowe dostawcy zwykle chronią obraz całego serwera przechowywany przez dostawcę i służą na wypadek awarii hosta. Rzadko pomagają, gdy usunięto plik, wykonano nieudaną migrację albo uszkodzono dane kilka tygodni temu i zauważono to dopiero dziś. Należy ustalić, jak długo przechowywane są snapshoty, czy można przywrócić pojedynczy plik oraz kto wykonuje przywracanie. Następnie należy przechowywać własną kopię poza środowiskiem dostawcy, korzystając na przykład z narzędzia restic, i przetestować ją za pomocą restic restore latest --target /tmp/restore-check, aby potwierdzić jej działanie.

Czy zarządzany VPS jest bezpieczniejszy niż niezarządzany?

Nie z samej definicji. Zarządzany plan umożliwia szybsze instalowanie poprawek niż w przypadku właściciela, który nigdy się nie loguje, co rzeczywiście zmniejsza ryzyko. Wiele zarządzanych planów instaluje również panel administracyjny. Panel jest rozbudowaną aplikacją dostępną z sieci, z własną stroną logowania i własną historią podatności. Niezarządzany serwer z automatycznymi aktualizacjami zabezpieczeń, zamkniętym firewallem, dostępem SSH wyłącznie za pomocą klucza oraz bez dodatkowych usług nasłuchujących stanowi mniejszy cel niż zarządzany serwer z uruchomionym panelem.

Czy mogę rozpocząć od VPS niezarządzanego i później przełączyć się na zarządzany?

Zwykle tak, choć rzadko sprowadza się to do zaznaczenia jednego pola. Dostawcy często przeprowadzają audyt serwera albo go przebudowują, zanim przejmą za niego odpowiedzialność, ponieważ nie będą wspierać konfiguracji, której nie mogą sprawdzić. Należy ustalić, co obejmuje wdrożenie, czy wymagana jest ponowna instalacja oraz czy elementy skonfigurowane samodzielnie pozostaną później poza zakresem usługi.

Czy na zarządzanym VPS zachowuję dostęp root?

W przypadku większości zarządzanych planów VPS tak, ale dostęp root wpływa na zakres wsparcia. Niektórzy dostawcy ograniczają wsparcie lub wyłączają je dla komponentu zmodyfikowanego ręcznie. Inni mogą odtworzyć serwer na podstawie własnego szablonu, jeśli realizacja zgłoszenia będzie wymagała głębokiej ingerencji. Przed wprowadzaniem zmian należy uzyskać tę zasadę na piśmie. Pliki konfiguracyjne należy przechowywać w systemie kontroli wersji, aby przebudowa serwera trwała godzinę zamiast całego weekendu.