Błędy uruchomienia, migracje – XEN cz.4

Część 4 konfiguracji XEN.





10) Błąd uruchomienia:

Załóżmy, że Node2 został wyłączony, co za tym idzie Inst1 nie będzie odpowiadał.


Node1:

gnt-instance list



Node2 widnieje jako master.



Wyłączmy inst1:


gnt-instance failover inst1.example.com 



na pojawiające się pytanie wpisujemy y.


Listujemy nasze maszyny


gnt-instance list


powinien się pokazać Inst1 oraz Node1.

Następnie:

gnt-instance shutdown inst1.example.com 

gnt-instance startup –extra „xencons=tty1 console=tty1” 

          inst1.example.com



Node2:


shutdown -h now



Node1:


gnt-instance failover inst1.example.com



na pytanie odpowiadamy y.


Musimy podmienić dysk z Node2 na Inst1:


gnt-instance replace-disks -s inst1.example.com



Następnie:


gnt-instance failover inst1.example.com




Node2 powinien stać się masterem:


gnt-instance list



Następnie wykonujemy ponownie:


gnt-instance shutdown inst1.example.com

gnt-instance startup –extra „xencons=tty1 console=tty1”  

inst1.example.com




11) Migracja:

Przenosimy instancje między węzłami.



Node1:



gnt-instance migrate inst1.example.com


na pytanie odpowiadamy y



gnt-instance list


widziamy inst1 oraz node1 jako master.


Migracja:


gnt-instance migrate inst1.example.com


na pytanie odpowiadamy y



gnt-instance list


teraz widzimy inst1 oraz node2 jako master.




12) Backup instancji (Inst1 na Node1):

Node1:


gnt-backup export -n node1.example.com inst1.example.com



backup będzie przechowywany tutaj:


ls -l /var/lib/ganeti/export/inst1.example.com/



Jeżeli chcemy przenieść backup na inny węzeł, np.3 (jedno polecenie):


gnt-backup import -n node3.example.com -t drbd –src- 

node=node1.example.com –src-

       
    dir=/var/lib/ganeti/export/inst1.example.com/
         inst1.example.com




13) Uszkodzenie Node1 – master’a:

Node2:


gnt-cluster masterfailover

gnt-cluster getmaster


nowym masterem będzie Node2.


Node1:


Jeżeli Node1 się „podniesie” będzie sądził że dalej jest masterem w klastrze


gnt-cluster getmaster



dlatego musimy go uświadomić, że node2 teraz rządzi:


chmod 600 /var/lib/ganeti/ssconf_master_node 


nano /var/lib/ganeti/ssconf_master_node



dodajemy:


node2.example.com




chmod 400 /var/lib/ganeti/ssconf_master_node



sprawdzamy, czy zmiany zostały wprowadzone:


gnt-cluster getmaster


powinniśmy w odpowiedzi dostać Node2.



Jeżeli Node1 ma być znów master’em, na Node1 uruchamiamy poniższe polecenie, dodatkowo obydwa 


węzły muszą działać poprawnie:


gnt-cluster masterfailover



Klaster zostanie „zabity” i Node1 będzie działał jako główny węzeł. 



Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.

Link do formularza tutaj: https://beitadmin.pl/pomysly

Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).

Dodaj komentarz

beitadmin.pl - Droga Administratora IT