Zarządzany czy niezarządzany VPS: 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.

Złoty środek: serwer niezarządzany z automatyzacją

Większość czytelników technicznych nie szuka skrajności. Oczekują planu niezarządzanego, w którym rutynowe zadania wykonuje maszyna, a uwaga administratora skupia się na kwestiach, których maszyna nie potrafi ocenić. Konfigurację należy przeprowadzić pierwszego dnia. Pierwsze dziesięć minut na nowym VPS to praktyczny punkt wyjścia dla każdego, kto wybiera model niezarządzany, a zabezpieczanie dostępu SSH powinno być częścią tej samej sesji.

Automatyczne aktualizacje bezpieczeństwa

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

Plik ten powinien teraz zawierać APT::Periodic::Update-Package-Lists "1"; oraz APT::Periodic::Unattended-Upgrade "1";. Brak pliku oznacza, że nic nie działa, a użytkownik nie otrzyma powiadomienia. Te dwie linie pełnią różne funkcje. 0 w drugiej linii oznacza, że żadne aktualizacje nie będą instalowane. 0 w pierwszej linii jedynie wstrzymuje odświeżanie list pakietów, przez co aktualizacje są uruchamiane na podstawie nieaktualnych list i po cichu przestają wykrywać nowe poprawki bezpieczeństwa. Żaden z tych błędów nie generuje komunikatu o błędzie.

Przetestuj konfigurację bez wprowadzania zmian w systemie. Zwróć uwagę, że pakiet to unattended-upgrades, podczas gdy polecenie jest w liczbie pojedynczej:

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

Dane wyjściowe wyświetlają listę wszystkich sprawdzonych pakietów i kończą się linią No packages found that can be upgraded unattended and no pending auto-removals, jeśli nie ma żadnych oczekujących aktualizacji. Rzeczywiste uruchomienia są zapisywane w /var/log/unattended-upgrades/unattended-upgrades.log, więc należy sprawdzać ten plik, zamiast zgadywać.

Aktualizacja jądra nie przynosi zmian do czasu restartu maszyny, ponieważ uruchomione jądro to to, które zostało załadowane podczas startu systemu. Plik /var/run/reboot-required pojawia się, gdy wymagany jest restart. Należy monitorować ten plik lub pozwolić maszynie obsłużyć to 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 restart, gdy ktoś jest zalogowany, co jest bezpieczniejsze na maszynie używanej interaktywnie, ale bezużyteczne na serwerze, na który nikt się nie loguje. Pełna konfiguracja unattended-upgrades w Ubuntu omawia składnię listy blokad oraz opcje powiadomień e-mail.

Monitorowanie działające na zewnętrznym hoście

Monitor działający na serwerze nie powiadomi o jego awarii, ponieważ sam również przestanie działać. Umieść sprawdzanie na drugim hoście lub w zewnętrznej usłudze. Uptime Kuma do monitorowania statusu to standardowe rozwiązanie typu self-hosted, które powinno znajdować się na innej maszynie niż ta, którą monitoruje.

Monitoruj co najmniej cztery parametry: dostępność, wykorzystanie dysku, czy aplikacja odpowiada na właściwym porcie oraz datę wygaśnięcia certyfikatu. Wykorzystanie dysku to najczęstsza pułapka. Plik dziennika lub baza danych, które rosną każdego dnia, mogą doprowadzić do awarii w najmniej oczekiwanym momencie, a pierwszym objawem jest często usługa, która nie może zapisać danych i kończy działanie.

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

Dodaj również mechanizm heartbeat. Licznik na serwerze wywołuje adres URL po każdej udanej kopii zapasowej lub teście sprawności, a monitor wysyła alert, gdy wywołania przestają docierać. W ten sposób serwer, który przestał odpowiadać, sam generuje alert, czego nie potrafi test typu pull, jeśli awarii uległa ścieżka sieciowa.

Kopie zapasowe, które przynajmniej raz przywrócono

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 drukuje created restic repository <id> at sftp:... jednorazowo. Uruchomienie tego polecenia dla istniejącego repozytorium kończy się błędem zamiast nadpisania, co jest pożądanym zachowaniem. Przechowuj kopię hasła poza serwerem: repozytorium jest nieczytelne bez niego i nie ma ścieżki odzyskiwania.

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ć ostatnie uruchomienie z dzisiejszą datą. restic check weryfikuje strukturę repozytorium i drukuje no errors were found. Teraz wykonaj 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 tam jest, albo go nie ma, a sprawdzenie tego teraz kosztuje dziesięć minut. Następnie ustaw uruchamianie na timerze, aby proces nie zależał od Ciebie. Utwórz /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 pokazuje następne uruchomienie i pozostały czas. Pusty wynik oznacza, że włączono usługę zamiast timera, co jest najczęstszym błędem. Persistent=true uruchamia pominięte zadanie po następnym starcie systemu, dzięki czemu maszyna, która była wyłączona przez noc, nadal wykona kopię zapasową. Kopie zapasowe Restic na VPS szczegółowo omawia strukturę repozytorium i retencję, a usługi i timery systemd wyjaśniają pliki jednostek linia po linii.

Czego nie zapewnia automatyzacja

Nie zapewnia ona osądu. Automatyczny restart o 02:00 nastąpi niezależnie od tego, czy aplikacja uruchomi się poprawnie, dlatego potwierdź, że każda usługa startuje samodzielnie, a następnie wykonaj restart celowo, będąc przy komputerze:

systemctl is-enabled nginx docker
sudo reboot

Automatyczna aktualizacja może również zainstalować pakiet, który uszkodzi aplikację, a żaden element potoku o tym nie wie. Monitor wykryje ten stan, dlatego monitorowanie nie jest opcjonalne, gdy aktualizacje są automatyczne. Maszyna zajmuje się rutyną. Incydent pozostaje Twoją odpowiedzialnością.

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.