Proxmox HA

[Gość Kamikadze]

Ktoś konfigurował w nowym proxmoxie HA?

 

Chcę osiągnąć aby 1 VM jak padnie na jednej matce to uruchamia się na drugiej.

Po konfiguracji HA jest tak że jak zgaśnie VM na matce to za chwilę automat go uruchamia jeszcze raz na obecnej.

 

Czytałem że trzeba chyba jeszcze coś skonfigurować. Miejsce sieciowe czy coś.

 

 

Ktoś coś doradzi jak to rozwiązać w "domowych" warunkach?

[Bartosz Z 236]

Wydaje mi się, że dyski VM powinny stać na udziale współdzielonym przez obie "matki".

[Gość Kamikadze]

OK a mam pytanie jeszcze. Co się dzieje w przypadku padnięcie współdzielonego miejsca. Raczej w tedy VMki nie działają.

 

[theONE 526]

No nie działają

[mcbarlo 61]

Sensowne HA można osiągnąć minimum na 5 serwerach. 3 node'y obliczniowe i 2 na storage współdzielony z replikacją w locie.

 

Na Proxmoxie to działa tak jak chcesz, sprawdzone organoleptycznie. Dodatkowo masz jeszcze migrację live.

[Gość Kamikadze]

Ok, będę testował.

 

Co do migracji live to przy 2 serwerach nie działa.

[Bartosz Z 236]

Przy 2 serwerach obliczeniowych i współdzielonej przestrzeni na dyski, nie da się zrobić migracji na żywo?

[Gość Kamikadze]

Współdzielonej przestrzeni co prawda jeszcze nie mam bo dopiero co sobie postawiłem i na razie testuje partycjonowanie dysków.

lxc live migration is currently not implemented

[Bartosz Z 236]

Zgadza się - wsparcie jest tylko dla wirtualnych maszyn, nie dla kontenerów:

 

Proxmox VE support live migration of Virtual Machines via web interface. To migrate from one physical host to another, you need at least two Proxmox VE servers, see Proxmox_VE_Cluster. To make this work, virtual machine must be stored on shared network storage (NFS, iSCSI, ...) accessible from all cluster nodes.

Niestety jeszcze nie miałem tylu blach pod ręką, żeby stestować klaster Proxmoxa

[Chmurka.pl 3]

Nie potrzeba oddzielnych maszyn typu "storage". Zakładając, że zintegrujesz dowolne wspierane rozwiązanie storage, to aby mieć klaster Proxmox, potrzebujesz logicznie minimum 2 maszyn.

 

Natomiast aby mieć automatyczną migrację (failover), potrzebujesz już 3 maszyn - jedna robi za arbitra. Wtedy dowolne 2 maszyny, które mogą się ze sobą prozumieć, ustalają, że ta trzecia padła.

 

W przeciwnym wypadku, będziesz miał split-brain - padnie sieć pomiędzy dwiema maszynami, obie "pomyślą", że ta druga nie działa i przejmą usługę. Oczywiście, zakładając, że masz możliwość fizycznego przekierowania ruchu automatycznie (przepięcie IP, czy podobne zabiegi).

[Gość Kamikadze]

Trudno w takim razie sobie raczej odpuszcze

[mcbarlo 61]

Klaster to nie HA. Możesz mieć 10 serwerów w klastrze bez HA. To tak jeśli chodzi o ścisłość.

 

To o czym mówisz jest możliwe kiedy rozproszysz storage na node'y obliczeniowe. Przy 2 jeszcze ma to sens, ale to tylko pseudo-HA. Przy 3 to już marnacja miejsca. Musisz mieć zreplikowane wszystkie dane wszędzie, bo nigdy nie wiesz, która maszyna zechce się zepsuć. Jak masz mało danych to może ujdzie, ale potem inwestycja w dyski (szczególnie SSD) może być nieopłalna i lepiej dorzucić serwerów.

 

Do ustalenia co zdechło potrzebne jest quorum i wszystkie serwery w klastrze głosują na tego kogo wyłaczyć. Dlatego bardzo ważna jest nadmiarowa sieć. Określanie quorum w Proxmoxie (nie wiem jak w innych rozwiązaniach) odbywa się za pomocą multicastu i trzeba to wziąć pod uwagę kupując switche. Choć teraz to większość ogarnia IGMP.

 

BTW do testów można zrobić sobie taki klaster spokojnie w wirtualkach.

[Gość Kamikadze]

Dzięki za info.

[Gość Kamikadze]

A teraz to w ogóle zgłupiałem.

 

 

 

 

 

Muszę je wcześniej sformatować czy co?

[mcbarlo 61]

Miałem taki komunikat jak wrzuciłem 2 dyski 1 TB różnych producentów. Z dwoma takimi samymi mi się nie zdarzyło.

[Gość Kamikadze]

Odpaliłem parted magic i skasowałem wszystkie partycje i poszło.

[Kszysiu 136]

Musisz mieć zreplikowane wszystkie dane wszędzie, bo nigdy nie wiesz, która maszyna zechce się zepsuć.

To nie tak działa... Nie musisz mieć wszędzie kopii wszystkiego.

 

Wystarczy użyć jakiegoś roproszonego rozwiązania. Ceph, drbd (w drbd9 możesz zrobić coś w stylu raid10), nawet glustera.

Ceph nie jest zadowalający wydajnościowo wg mnie (nie nadaje się pod sporą ilość vm na małej ilości dysków), drbd ma wydajność mniej więcej jak software raid, drbd9 nie używałem, a gluster jest też w miarę szybki, ale na dwóch dyskach ssd i replikacji x2 nie przekraczałem 6kiops/6kiops (zapis i odczyt jednocześnie po 6k - z RDMA po infinibandzie robiłem około 10kiops/10kiops).

[Gość Kamikadze]

Ok.

 

Na razie odpuszczę bo dopóki nie kupię większych

[mcbarlo 61]

Jak nie masz współdzielonego storage i nie replikujesz wszystkiego wszędzie to co się stanie jak padnie node, który nie ma zreplikowanych danych? Raczej wirtualki z niego nie będą miały się z czego odpalić na innym nodzie.

 

Ceph czy drbd to m.in. replikacja danych w klastrze.

Edytowano Maj 17, 2016 przez mcbarlo (zobacz historię edycji)

[Kszysiu 136]

Jak nie masz współdzielonego storage i nie replikujesz wszystkiego wszędzie to co się stanie jak padnie node, który nie ma zreplikowanych danych? Raczej wirtualki z niego nie będą miały się z czego odpalić na innym nodzie.

 

Ceph czy drbd to m.in. replikacja danych w klastrze.

 

Czy 5 node ceph/glustera (drbd to ciut co innego, chyba że w wersji 9) znaczy, że wszystkie 5 nodów ma zreplikowane te same dane? Nie - dane są rozproszone - najczęściej ustawia się 2-3 repliki i tyle. Nie oznacza to, że jak masz 5 maszyn to zajmujesz 5 tego co normalnie. zajmujesz tyle razy więcej co ustawisz sobie replik. Użycie x maszyn nie wymusza x replik, co wynika z twojej wiadomości.

 

Możesz mieć 5 maszyn storage z replikacją 2 i wtedy mimo że zajmujesz tylko 2x tyle (nie musisz np. używać raida w cephie więc wychodzi ci tak jakby raid 10) i dane są dostępne ze wszystkich maszyn podpiętych do cepha/glustera/moosefs'a i innych temu podobnych.

 

A możesz też ustawić sobie erasure coding np. 4+2 na sześciu maszynach i zajmujesz wtedy x1,5 a możesz bez problemu stracić tyle co przy 3 replikach.

[Gość Kamikadze]

Zastanawiam się czy takie rozwiązanie by działało:

 

 

MVM1 <-> MVM2 (matki VMek)

+

HD1 <-> HD2

 

Czyli 2 matki serwerów + dwie "macierze" z replikacją.

 

Jak padnie jeden z elementów to reszta powinna działać dalej?

[Kszysiu 136]

A czy HA może być "widoczne" wewnątrz VM?

 

Ja chyba bym zrobił tak (nazwy xenserwerowe, bo jego najbardziej znam):

Dwa serwery nas wystawiające nfs/iscsi (co kto lubi).

Oba dodaje dla xena jako oddzielne SR (storage repository - zbiory dysków dla vm)

Do każdej VM dodaję dwa VDI - po jednym z każdego SR.

Na VM stawiam software raid1

 

Jak padnie matka - stawiasz vm na drugiej

jak padnie storage, to po prostu rozsynchronizuje się raid, który się odbuduję jak wróci NAS i karzesz vm się odbudować.

[Gość Kamikadze]

Też to jakieś rozwiązanie. Będę miał więcej sprzętu to sobie potestuje

[Kszysiu 136]

Myślę, że to najwydajniejsze rozwiązanie

[mcbarlo 61]

Całkiem pomysłowe rozwiązanie. Tylko jest jakiś mechanizm, który odpali VM-ke automatycznie na drugim nodzie czy trzeba to zrobić ręcznie?