Migracja maszyn fizycznych na Proxmoxa

[mbl]

Cześć,

 

mam 4 fizyczne serwery, jeden osobny do mysql i 3 z róznymi usługami. Chce to wszystko zwirtualizować, dalej w taki sposób że osobna vm będzie do bazy i 3 lub więcej vm + jakieś kontenery może z usługami (kilka www, cacti/zabbix, poczta)

 

Gdzie najlepiej jest umieścić serwer mysql (na osobnej wydzielonej pod ten cel vm) względem reszty vm - serwerów usług co będą z tej bazy korzystać?

Na tym samym storage ?

 

Czy może jest jakieś storage co gwarantuje szybszy czas odpowiedzi dla bazy, a reszta vm może być / powinna być na innym storage ?

 

Czy umożliwienie ewentualnej rozbudowy w przyszłości o dodatkowy węzeł i jakąś synchronizację dysków między fizycznymi serwerami zmienia coś względem poprzednich pytań? 

 

Jakie są w ogóle najlepsze praktyki do tego? Chcę postawić serwer kilka vm zużycie 10 rdzeni wyjdzie , 2-3 tb łącznie w raid1 na 4 lub więcej jak będzie potrzebne na 2 storage

 

Z góry dzięki za pomoc

 

 

 

 

 

 

Edytowane 14 Października 2022 przez mbl

[Poziomecki]

Duża ta baza? Dużo zasobów potrzebuje? Jeżeli masz możliwość to najlepiej VM z DB wrzucić sobie na zasób dyskowy SSD. Reszte typu zabbix / poczta trzymaj nawet na HDD (o ile nie przewidujesz całości na SSD co będzie pewnie lepsze).

 

Zależnie od ilości dysków. Możesz sobie np. 2 dyski w RAID 1 (a najlepiej 10 jeśli jest więcej dysków) wrzucić pod VMki i kolejne 2 dyski SSD w RAID 1 pod DB. W proxmoxie stworzysz po prostu osobny zasób.

 

Najlepiej jak napiszesz czy bierzesz jakiś gotowiec w dzierżawę czy myślisz o własnym blaszaku.

 

 

edit: monitoring typu zabbix wrzuciłbym w ogóle w osobny VPS gdzieś w osobnym DC. Koszt znikomy w porównaniu z dedykiem, ale jeśli padnie ci lokalizacja nadal będziesz miał wgląd chociażby co się działo tuż przed awarią i jak się zachowywały wirtualki.

Edytowane 14 Października 2022 przez Poziomecki

[mbl]

59 minut temu, Poziomecki napisał:

Duża ta baza? Dużo zasobów potrzebuje? Jeżeli masz możliwość to najlepiej VM z DB wrzucić sobie na zasób dyskowy SSD. Reszte typu zabbix / poczta trzymaj nawet na HDD (o ile nie przewidujesz całości na SSD co będzie pewnie lepsze).

 

Teraz są 4 rdzenie po 2.4 GHz, 4 GB ramu i to wystarcza do operacji bazy. Nie za dużo, nie za mało. Kilkadziesiąt GB danych ma baza więc chyba użyje 128 GB SSD w RAID 1. 

 

 

59 minut temu, Poziomecki napisał:

 

Zależnie od ilości dysków. Możesz sobie np. 2 dyski w RAID 1 (a najlepiej 10 jeśli jest więcej dysków) wrzucić pod VMki i kolejne 2 dyski SSD w RAID 1 pod DB. W proxmoxie stworzysz po prostu osobny zasób.

 

Tak, na VMki chcę 4 dyski HDD w RAID10 . I albo na tym będzie ta vm'ka z mysql, albo zrobię na osobnych dwóch SSD w RAID 1.

 

A jakie to powinny / najlepiej być typy storage pod vmki i pod ssd z mysql? Zalezy mi na robieniu snapshotow zarówno zwykłych vm oraz maszyny z mysql (oczywiscie backup samej bazy osobno, snaphot osobno).

 

Jeżeli bym chciał np umożliwić dorzucenie drugiego klastra w przyszłości, ale w taki sposób by dyski w tych klastrach synchronizowały się miedzy sobą (np osobnym łączem  10G między serwerami) to rozumiem że od razu muszę stawiać ceph i odpowiednie systemy plików?

 

 

59 minut temu, Poziomecki napisał:

 

Najlepiej jak napiszesz czy bierzesz jakiś gotowiec w dzierżawę czy myślisz o własnym blaszaku.

 

Mam już swojego blaszaka.

 

 

 

59 minut temu, Poziomecki napisał:

 

 

edit: monitoring typu zabbix wrzuciłbym w ogóle w osobny VPS gdzieś w osobnym DC. Koszt znikomy w porównaniu z dedykiem, ale jeśli padnie ci lokalizacja nadal będziesz miał wgląd chociażby co się działo tuż przed awarią i jak się zachowywały wirtualki.

 

Monitoring będzie obczajał sporo innych rzeczy w infrastrukturze poza proxmoxem, będących w LANie, więc na pewno jakiś system monitoringu będzie na tej maszynie lokalnie. Z zasobów tych maszyn też będą głównie korzystać userzy w  LANie.

 

 

 

 

[Poziomecki]

Tak musisz mieć w tedy ceph i z tego co pamiętam jeszcze ZFS musi być wdrożony.  W tedy możesz nawet wdrożyć coś w rodzaju FailOver że jak padnie serwer #1 to VMka wstaje na serwerze #2. Kiedyś to testowałem nawet działało. Minusem wdrożenia jest to że ZFS potrzebuje więcej ramu. Nie mogę znaleźć, ale tam jest jakiś przelicznik ile RAMu potrzeba na optymalne działanie VMki na ZFS (oblicza się na podstawie dysków). Tu masz info: https://pve.proxmox.com/wiki/ZFS_on_Linux

Na start potrzebuje 8GB RAM na "życie"

 

"ZFS uses 50 % of the host memory for the Adaptive Replacement Cache (ARC) by default. Allocating enough memory for the ARC is crucial for IO performance, so reduce it with caution. As a general rule of thumb, allocate at least 2 GiB Base + 1 GiB/TiB-Storage. For example, if you have a pool with 8 TiB of available storage space then you should use 10 GiB of memory for the ARC."

 

Pod DB Szczerze? Wygospodarowałbym jakieś dwa-cztery dyski pod kolejny raid 10 na SSD. W tedy nawet backup możesz robić lokalnie na HDD a później przerzucać go bezpośrednio z HDD na zewnętrzny zasób (żeby nie trzymać na jednym serwerze backupów).

 

Skoro zabbix na zewnętrznej usłudze odpada to trudno. Stawiaj go na zwykłej VMce.

 

Podsumowując - robisz dwa zasoby. Pierwszy - HDD raid 10 pod VMki i drugi SSD raid 1 lub 10 pod DB. Jeżeli nie chcesz wpędzać się w koszty możesz to zrobić później. Czyli stawiasz w pierwotnej wersji na HDD a w razie potrzeby rozbudowujesz o zasób SSD (do wyklikania w sumie wszystko, kwestia wpakować dyski). Później migracja na SSD, 5 minut i po wszystkim.

 

 

P.S. przy tworzeniu klastra pamiętaj tylko żeby druga maszyna, którą włączasz do klastra była pusta (bez VMek). Inaczej proxmox nie przyjmie ci "gościa".

 

P.S. 2 - jest jeszcze jeden myk, który robią niektórzy. Stawiają np. na jednym dysku proxmoxa (sam system) a pod kolejne storage podpinają tylko zasoby wyłącznie dla VMek.

[Spoofy]

Ogólnie - baza, bazie nie równa - zależnie od rodzaju operacji (read vs write), ich ilości, rodzaju konfiguracji (cache?), ewentualnego HA etc. - lecz najważniejsze, jaka to baza i jakie oprogramowanie, co determinuje inne czynniki dotyczące tejże konfiguracji, zarówno pod kątem softu jak i hw.

SSD != SSD, zarówno pod kątem bezpieczeństwa jak i szybkości. Tutaj też potrzebny jest konkretny wymóg wydajnościowy i konkretny benchmark, czy założone wartości są spełnione.

Dogłębnie znając i stosując LXC w rożnych aspektach, stawianie VM pod bliżej nieokreśloną bazę danych wydaje się marnotrawieniem zasobów. MySQL, MSSQL, ES, Mongo, Influx etc. - większość pójdzie bez problemu w bezpiecznej "przestrzeni nazw" i nie potrzebuje pełnej wirtualizacji.

Domyślam się, że wiesz jak działa Proxmox i jest to właściwie niemiecki Debian z pewną filozofią dotyczącą RAID i filesystemów. Istotniejszy jest wykorzystywany filesystem, niż ułożenie macierzy.

MySQL i snapshoty - czyli już jakiś konkret - snapshotting wspierany jest przez konkretne filesystemy, tak więc na Twoim miejscu, prędzej pytałbym np. czy LARC/ZVOL z dysków SSD mają znaczenie przy takich operacjach na macierzy HDD. W przypadku ZFS pamięć RAM i jej dostępność powinna zostać ujęta w rozplanowywaniu zasobów. Pan @Poziomeckiświetnie to opisał.

Oczywiście pamiętamy o złotej zasadzie: snapshot != backup .

 

CEPH na 10G to tylko do małych operacji. Tak jak wcześniej - tak, snapshotting dostępny jest tylko przy wybranych filesystemach.

 

8 godzin temu, mbl napisał:

Mam już swojego blaszaka.

 

Zapytałbym, jaki kontroler dysków jest wykorzystywany i w jaki sposób skonfigurowany - ma to zazwyczaj duże znaczenie wydajnościowe pod kątem baz danych. Przy ZFS musisz mieć raw dostęp do dysków lub JBOD/IT mode.

[spex]

Czemu snapshopt to nie backup? W sensie, czy to nie zależy od polityki kopi bezpieczeństwa. Jeśli wykorzystuję mechanizm snapshopu by zrobić kopię tu i teraz, a potem synchronizuję te snapshopty na inną maszynę, to nie będzie to jednak backup?

[Tweedlex]

Snapshoty mogą ulec uszkodzeniu, kiedy masz ich dużo to występuje spadek wydajności wirtualnej maszyny. Najlepiej to robić normalny backup w proxmoxie. Jeśli chodzi o backup mysql to najlepiej uruchamiać https://github.com/databacker/mysql-backup np. co godzinę zrzucając dane na wirtualny dysk na raid HDD podpięty jako drugi dysk to wirtualnej maszyny i dodatkowo robić jeszcze backup całej wirtualnej maszyny raz dziennie po stronie proxmoxa.

[Poziomecki]

21 godzin temu, spex napisał:

Czemu snapshopt to nie backup? W sensie, czy to nie zależy od polityki kopi bezpieczeństwa. Jeśli wykorzystuję mechanizm snapshopu by zrobić kopię tu i teraz, a potem synchronizuję te snapshopty na inną maszynę, to nie będzie to jednak backup?

 

Przy DB różnie bywa. Możesz mieć pełny backup, możesz mieć snapshota a przy przywracaniu nagle baza nie wstaje i jest rzeźba. Dlaczego nie wstało, co jest nie tak. Czasem może być tak że backup zrobi się po prostu "w złym" momencie. Nie raz miałem sytuacje co prawda na szczęście w strefie czysto deweloperskiej i testówkach że robiłem sobie snapshoty "co krok" np. po instalacji danego oprogramowania. Fajnie do tego się to idealnie nadaje, ale nie raz miałem sytuacje że po rollback nagle coś po drodze nie wstawało bo akurat coś się źle zrobiło, jakiś proces wisiał w tle i bęc dane w db mogą być w tedy niespójne.