Wirtualizacja - OpenVZ - początek

Dzisiejszy wpis, a raczej seria wpisów będzie poświęcona mojemu serwerowemu ego.

Nie są to bardzo trudne operacje, ale minimalna wiedza z zakresu obsługi terminala będzie bardzo wskazana.

Nie będę też wszystko opisywał screenami - skupię się na najważniejszych elementach i poleceniach, żeby proces był prawie kopiuj-wklej.

Konfiguracje wszystkich systemów są podstawowe. Należy jest dostosować w późniejszych krokach pod swoje oczekiwania.

Należy również pamiętać o ustawieniu nazw domen / subdomen pod siebie. Tutaj są tylko przykładowe.

Dołożyłem wszelkich starań, aby po drodze było jak najmniej niepodziewanych błędów, jednak nie wykluczam, że coś gdzieś może nie działać.
Proszę wtedy ewentualnie napisać a może uda się rozwiązać problem :)

Jestem posiadaczem dedykowanego serwera Kimsufi w wersji KS2 - fajna sprawa mieć za 50 zł dedyka :) Niestety mam starsze wydanie, które posiada 2 GB RAMu, co jest dla mnie trochę mało.
W związku z tym kupiłem kolejną wersję Kimsufi KS2 i chcę teraz "przemigrować"" z jednego na drugi.
Nie jest on demonem prędkości, jeśli chodzi o procesor, natomiast bardziej mi zależało na powierzchni dyskowej i pamięci RAM.

Serwer wykorzystuję do kilku celów:

  • testowanie aplikacji WWW (nginx, apache2)
  • TeamSpeaka dla kolegów z gry Ghost Recon Phantom
  • repozytorium GIT - GitLab
  • pobieranie i udostępnienia dużych plików
  • chmura plików - SeaFile
  • backup dla innego serwera

To wszystko siedzi teraz na jednym serwerze pod wspólną konfiguracją.
Teraz chcę to wszystko przenieść na nowy serwer. No właśnie, przenieść... jak ? Jak to zrobić łatwo, szybko i przyjemnie ?

Na to nie ma prostego i jedynego rozwiązania. Można w jakiś sposób zsynchronizować wszystkie pliki z nowym serwerem (rsync), ale jest ryzyko, że coś może nie działać.

Swojego czasu chciałem się pobawić wirtualizacją - kontenery LXC - ale kernel mi na to nie pozwalał.

Teraz pomyślałem, że taką wirtualizację można wykorzystać przy migracji, a raczej postawieniu wszystkiego od nowa.
Nie będę wykorzystywał kontenerów LXC, natomiast OpenVZ , które stosują firmy hostingowe do swoich VPS .

Dla każdego celów określonych wcześniej można stworzyć osobny kontener, który będzie niezależny od siebie.
Dzięki temu przeniesienie w przyszłości na nowy serwer to klika kliknięć i mamy gotowy system. Ponadto tworzenie backupów takich kontenerów jest banalnie proste i pozwala bardzo szybko przywrócić poprzednią wersję.

Angedotka: ile nerwów i czasu straciłem podczas update'u GitLaba, gdzie nagle nie chciał się uruchomić z niewiadomych dla mnie przyczyn (potem znalazłem problem, ale zajęło mi to dużo czasu).

 

Angedotka 2: pisząc tą serię chciałem przetestować rozwiązania, żeby nie być gołosłownym. W połowie moich prac, ktoś zhackował mój serwer (hasło admin nie jest najlepszym hasłem :P )i miałem problem, żeby przywrócić wszystko do życia. Mogłem sobie skopiować tylko pliki – tyle mi wystarczyło, żeby wszystko postawić „od nowa” w przeciągu 30 min (najwięcej czasu zajęło mi kopiowanie obrazów OpenVZ).

Dodatkowo dla każdego kontenera można nałożyć restrykcje do zasobów - ilość RAMu, dysku czy procesora. Wygodne do kontroli zasobów.

Niestety nie ma róży bez kolców.

Z wad jakie przychodzą mi teraz na myśl, to zużycie dodatkowych zasobów dla zarządzania tymi kontenerami oraz konfiguracją sieciową (o tym później).

Ok, tyle wystarczy na początek. W następnym wpisie zaczniemy zastanawiać się w jaki sposób zaprojektować naszą VPSową infrastrukturę.