Z końcem roku wygasa moje ostatnie konto hostingowe, czyli hosting współdzielony. Zostaną mi tylko konta opłacane bezpośrednio przez niektórych klientów (coś o tym będzie niebawem). Wprawdzie z takim zamiarem nosiłem się od dawna, to cały czas utrzymywałem 2 ostatnie konta tego typu, na których trzymałem „spokojniejsze strony”. Pierwsze konto pożegnałem we wrześniu, za kilka dni pożegnam ostatnie. Nie będę ukrywał, że w podjęciu decyzji pomogła mi firma hostingowa (o tym też będzie niebawem). Niezależnie od powodów, całkowita rezygnacja z hostingu współdzielonego oznacza, że musiała rozwinąć się moja flota serwerów VPS…
Spis treści w artykule
Rsync i SSH, czyli VPS2VPS
W pewnym momencie, dzięki procedurom i automatyzacji niektórych czynności konfiguracja kolejnego serwera staje się rutyną, to jednak są pewne zadania, które trzeba wykonać, i które zajmują czas, który w innym przypadku można by przeznaczyć na inne zadania (lub rozrywki ;-)). Stąd w tym gorącym okresie (Święta Bożego Narodzenia + pożegnanie hostingów) postanowiłem maksymalnie zautomatyzować całą operację.
Jeśli dostawca usług pozawala, to najprościej wykonać to za pomocą przygotowanego wcześniej obrazu systemu, dzięki czemu cała operacja nie dość, że jest szybka i wygodna, to raczej na pewno nie spotkają nas w jej trakcie jakieś nieprzewidziane przygody. Tak zazwyczaj robię np. w przypadku serwerów w DigitalOcean.
Tym razem jednak takiej opcji nie mam, bo wprawdzie „ten konkretny dostawca usługi” ogólnie posiada coś takiego, ale tylko w najwyższych planach, z których nie skorzystałem – tym razem postanowiłem rozdzielić strony na kilka mniejszych maszyn, choćby po to by móc je wzajemnie synchronizować. Dlatego postanowiłem skorzystać z programu Rsync, za pomocą którego bezpiecznie (z wykorzystaniem SSH) przeniosłem wszystkie dane między maszynami.
Wykluczeni i wykluczone
Zanim zaczniemy kopiowanie musimy określić katalogi, które wykluczymy z tej operacji, bo nawet w sytuacji takiej jak moja, czyli kopiowanie w obrębie maszyn o identycznej konfiguracji programowo-sprzętowej u tego samego dostawcy inaczej wystąpią problemy.
W moim przypadku standardowa lista wykluczonych katalogów dla VPSa na Debianie wygląda tak:
/boot
/dev
/media
/mnt
/proc
/run
/sys
/tmp
Do tego kilka plików:
/initrd.img
/vmlinuz
/etc/fstab
/etc/network/interfaces
/etc/hostname
/etc/hosts
Do tego zazwyczaj dochodzą jakieś pojedyncze katalogi związane np. z kopiami zapasowymi (BackUp), ale to już każdy z Was musi określić je samodzielnie.
Kopiowanie, czyli synchronizacja
Następnym krokiem jest synchronizacja plików za pomocą programu Rsync (powinien być zainstalowany na obu maszynach), z wykorzystaniem bezpiecznego połączenie przez SSH.
Z racji tego, że pliki będę kopiował na świeżutki serwer zdalny, to mogę skorzystać z takiego polecenia:
sudo rsync -aHlxvz --numeric-ids --progress --delete --exclude=/boot/* --exclude=/dev/* --exclude=/media/* --exclude=/mnt/* --exclude=/opt/* --exclude=/proc/* --exclude=/run/* --exclude=/sys/* --exclude=/tmp/* --exclude=/initrd.img --exclude=/vmlinuz --exclude=/etc/fstab --exclude=/etc/network/interfaces --exclude=/etc/hostname --exclude=/etc/hosts /* -e ssh root@Adres_IP_docelowego_serwera:/
W przypadku, gdyby serwer docelowy był już po wstępnej konfiguracji, i np. usługa SSH działa na innym porcie niż domyślny (zalecam), to polecenie trzeba lekko zmodyfikować, dodając numer portu:
sudo rsync -aHlxvz --numeric-ids --progress --delete --exclude=/boot/* --exclude=/dev/* --exclude=/media/* --exclude=/mnt/* --exclude=/opt/* --exclude=/proc/* --exclude=/run/* --exclude=/sys/* --exclude=/tmp/* --exclude=/initrd.img --exclude=/vmlinuz --exclude=/etc/fstab --exclude=/etc/network/interfaces --exclude=/etc/hostname --exclude=/etc/hosts /* -e "ssh -p PORT" root@Adres_IP_docelowego_serwera:/
Gdy oprócz zmiany domyślnego portu dla połączenia SSH do docelowego serwera łączymy się dodatkowo z wykorzystaniem pliku certyfikatu (również zalecam), do polecenia należy dodać kolejny parametr:
sudo rsync -aHlxvz --numeric-ids --progress --delete --exclude=/boot/* --exclude=/dev/* --exclude=/media/* --exclude=/mnt/* --exclude=/opt/* --exclude=/proc/* --exclude=/run/* --exclude=/sys/* --exclude=/tmp/* --exclude=/initrd.img --exclude=/vmlinuz --exclude=/etc/fstab --exclude=/etc/network/interfaces --exclude=/etc/hostname --exclude=/etc/hosts /* -e "ssh -p PORT -i /ścieżka/do/klucza/prywatnego" root@Adres_IP_docelowego_serwera:/
Po tej operacji drugi serwer powinien pod względem konfiguracji odpowiadać serwerowi źródłowemu, z którego kopiowaliśmy pliki. Oczywiście w wielu przypadkach nie obejdzie się bez kilku ręcznych korekt, ale to już zależy od konfiguracji serwera (serwerów).
Indywidualne zabezpieczenia
Ze względów bezpieczeństwa zalecam by na „sklonowanych maszynach” dokonać zmiany haseł dla poszczególnych użytkowników, oraz – jeśli korzystacie – wygenerować nowe klucze (certyfikaty) SSH, oraz tokeny dla uwierzytelnienia dwuskładnikowego (2FA).
Reszta ustawień – tak jak napisałem w jednym z poprzednich akapitów – zależy od Waszej indywidualnej konfiguracji źródłowej.
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
czyli wszystkie swoje strony I strony klientów utrzymujesz na jedymj lub kilku VPSach? Nie lepiej klientow i siebie na 1 dedyku?
Dedyki to dawno temu, gdy jeszcze pracowałem na etacie, no chyba, że Raspberry Pi uznać za dedyka, to wtedy cały czas mam kilka… ;-)
Tak, wolę kilka VPSów niż jednego dedyka, nawet jeśli sumarycznie VPSy zaczną zbliżać się cenowo do 1 dedyka. Nie dość, że odpadają mi jako takie awarie sprzętowe (matki nie liczę, bo to inna bajka), to mam też do wyboru różne lokalizacje, skalowanie zasobów i – co jednak się przydaje – w razie konieczności mogę właściwie w dowolnym momencie przenieść stronę z jednego serwera na inny (Cloudflare jako szybki DNS się przydaje). Czy to by wykonać jakieś poważniejsze prace serwisowe, czy też dlatego, że akurat jakiś VPS padł (bez znaczenia, czy kwestia po stronie samego VPSa, matki, czy całego DC).
Pomijam tutaj pewne sytuacje, gdy faktycznie dedykowany serwer sprawdzi się lepiej niż VPS, bo obecnie takich (potrzeb) nie mam. Choć kto wie, może kiedy(ś) jakiś „poważniejszy” dedyk trafi do mojej floty…
Wszystkich moich klientów (około 100) staram się umieszczać na moim serwerze dedykowanym i nie wyobrażam sobie umieszczania ich na oddzielnych hostingach, za bardzo upierdliwe. Myślę przy większej ilości klientów że 1 dedyk jest lepszym rozwiązaniem nic kilka VPSów.
Zalety dedyka wzgędem VPS:
– wyższa wydajność, wirtualiacja zawsze zjada trochę zasobów.
– jestes niezależny od innych VPSów na matce, inny VPS nie zajeżdża dysku
– dopasowana konfiguracja w swoich potrzeb
– ryzyko awarii sprzętowej jest zawsze, ale od tego jest support aby wymienić.
– wszystkie dane w 1 miejscu – wygoda :)
– samemu możesz zadbać o kopie bezpieczeństwa
VPS też się przydaje, to taka bezpieczniejsza forma dedykowanego.
Mam świadomość zalet dedyka, czy też „wszystkie maszyny na jednym pokładzie”, i tak naprawdę z większością Twoich argumentów mogę zgodzić, ale… ;-)
Odnosząc się bezpośrednio do Twoich argumentów/zalet dedyka, zgadzam się, że wirtualizacja ma swój narzut, ale kupując VPSa biorę pod uwagę jego parametry, które mam już bez tego narzutu (sprawdzam też co tam za matka siedzi, i ogólnie, korzystam z firm, gdzie wiem, że mnie nie robią…). Oczywiście sporo zależy też od typu wirtualizacji (np. Webinsider.pl działa na XEN z HitmMe.pl, do tego mam np. KVM w DigitalOcean), bo często tu jest „pies pogrzebany”. Konfiguracja dostosowana – niby tak, ale tu też wiele zależy od wirtualizacji, choć nie ma aż takiej dowolności jak w przypadku dedyka. Do tego nowe technologie wirtualizacji (cloud ;-)) pozwalają właściwie dowolnie i prawie w nieskończoność dokładać zasobów. Na pewno dużo szybciej i chyba taniej, niż w przypadku dedykowanego serwera.
Wszystko w jednym miejscu to wygoda, zgadzam się. Ale jest to też pojedynczy punkt awarii, i w razie „odpukać” wszystko leży. Kopie bezpieczeństwa ważna rzecz, i wierz mi, że „nawet na VPSach” sporo do tego przykładam uwagi (skrypty, S3, kopie bezpośrednie CMSów, migawki, itp.). Ogólnie staram się jak najwięcej „zarządzania” zautomatyzować, dzięki czemu nie ma aż takiego dużego narzutu w związku z większą ilością serwerów.
No i by nie było, że jakiś wariat ze mnie – to nie jest tak, że każdy klient, to oddzielny VPS. Oczywiście zdarzają się i takie sytuacje, ale są to wyjątkowe sytuacje. W większości przypadków na jednym VPSie jest kilka stron (i usług, bo nie tylko WWW tam jest), i w razie konieczności raczej skaluję zasoby niż maszyny.
Nie próbuję Cię przekonać, że dedyk to zło i tylko VPSy są OK. Nie próbuję, bo tak nie uważam. Wiele zależy od potrzeb, możliwości, czy… przyzwyczajeń. No i VPS wydaj mi się troszkę bardziej skalowalny finansowo – zawsze mogę ściąć wydatki, gdy z jakichś przyczyn w danym momencie nie potrzebuję „aż takiej mocy”. Zresztą pewnie nawet gdybym zdecydował się na dedyka, to i tak w tle działałby jakiś VPS, by w razie co mógł szybko przejąć jego rolę (tak samo jak nie korzystam tylko z jednego VPSa).
Idealnie byłoby gdyby połączyć zalety VPSa (skalowalność, brak siwych włosów z powodu możliwej awarii) i dedyka (konfigurowalność, cena, wydajność IO, separacja zasobów) ….
Czyli „chmura”, ale one są droższe niz dedyk, są awaryjne (kiedys duża awaria w Oktawave), mnie konfigurowalne i na razie nie mam do nich zaufania.
Idea jest fajna, ale ja poczekam.
PS. webinsider.pl – fajna i ciekawa strona, tak trzymaj.
Wiesz, określenie „chmura” (cloud) cały czas jeszcze w wielu przypadkach jest mocno naciągane. Kilka dni temu trafił pod moje skrzydła „Business Cloud” w Home.pl – nie wiem co to ma wspólnego z chmurą, ale – moim zdaniem/w moim odczuciu – funkcjonalnie plasuje się to gdzieś w okolicach mocno wykastrowanego hostingu współdzielonego, ale już cenowo w okolicach solidnego VPSa. I niestety, ale przez jakiś czas przyjdzie mi się chyba z tym potworkiem pomęczyć.
Na szczęście są też firmy/oferty, gdzie pojęcie chmura (cloud) nie robi za lep na
muchynaiwnych, i faktycznie zastosowane rozwiązania związane m.in. ze skalowaniem i ogólnie zarządzaniem infrastrukturą to właściwie bajka. A do tego ceny nie odstraszają (oczywiście o ile ktoś ich nie porównuje z hostingiem za 10-20 zł rocznie ;-)).Co do PSa – dzięki, staram się. Choć z powodu różnych „dodatkowych” (;-)) projektów obecnie czasu trochę jakby mniej, doba nie chce się wydłużyć, i lista tematów do opisania systematycznie się rozrasta… Chyba będę musiał poważnie zastanowić się w 2018 nad dodatkowymi rękami do pisania…
Panie Patryku, jak Pan sądzi, czy w ten sposób można wykonywać kopie (backupy) serwerów vps? Wiele z nich nie posiada tzw. migawki (lub jest dodatkowo płatna), czy w ten sposób skopiowane dane na lokalnego linuksa można przesłać z powrotem na serwer odzyskując całkowicie jego konfigurację?
Można, w końcu Linux to głównie pliki. Warto tylko dobrze wybrać co kopiować/klonować, a czego nie ruszać. Zwłaszcza gdyby transfer miał być między różnymi platformami (np. różna wirtualizacja). Zresztą w pewnym sensie ten artykuł o czymś takim jest. Zobacz też na dedykowane rozwiązania tego typu, może któreś będzie pasować.