Juju HA setup

Di default il backup puo’ farlo solo root, e root deve stare sul modello “controller”. Per far sì che un altro utente possa fare backup bisogna dargli il grant superuser, es:

$ juju grant maastest superuser

E poi deve essere admin del model controller.

$ juju grant maastest admin controller

Per lanciare il backup:

$ juju create-backup --filename "juju_ct1-juju2-01_admin_jujuprod_20161128" "backup VM overloaded"

Test1- Proviamo a ripristinare il backup su un altro controller.

Caso 1:

Controller è un clone del controller originale, quindi già bootstrappato.

Prendiamo nota dell’ip del controller originale:

$ juju gui --show-credentials
Opening the Juju GUI in your browser.
If it does not open, open this URL:
https://10.4.1.0:17070/gui/c097e4b2-c411-44bf-87b4-47bd932c1441/
Username: admin
Password: a4d5bf5a72fc576a8cf83396672baec0
Couldn't find a suitable web browser!
Set the BROWSER environment variable to your desired browser.

Caso 1. Partiamo dal clone della VM con juju (ba1-juju2-01-clone).

Con virsh edit cambiamo il mad address del clone con quello originale.

Facciamo partire la VM… dopo un po’ juju risponde!

Sembra abbia ripristinato tutto correttamente, non vediamo le ultime modifiche (model moodle)

Note

MAAS non aggancia la VM, vediamo la VM deployed e spenta.

Per ripristinare il backup:

$ juju restore-backup --file ./juju_ba1_20161128

Caso 2. HA

Come utente root e switchando sul model “controller”, dopo aver commissionato su maas le macchine ct1-juju2-02 e ct1-juju2-03:

$ juju enable-ha -n 3 --to ct1-juju2-02,ct1-juju2-03

Dopo il deploy juju machines mostra:

$ juju machines
Machine  StateDNS     Inst id  Series  AZ
0    started  10.3.1.04y3h8r   xenial  Catania
1    started  10.3.1.174  4y3kcr   xenial  default
2    started  10.3.1.175  4y3kcs   xenial  default

e:

$ juju show-machine
model: controller
machines:
"0":
juju-status:
current: started
since: 30 Nov 2016 16:19:30Z
version: 2.0.0
dns-name: 10.3.1.0
ip-addresses:
- 10.3.1.0
  instance-id: 4y3h8r
  machine-status:
current: running
message: Deployed
since: 21 Oct 2016 17:40:12Z
series: xenial
hardware: arch=amd64 cores=4 mem=12000M tags=virtual availability-zone=Catania
controller-member-status: has-vote
"1":
juju-status:
...
controller-member-status: has-vote
"2":
juju-status:
...
controller-member-status: has-vote

In particolare l’ha è abilitato quando i tre membri sono nello stato “has-vote”.

DEBUGGING (MongoDB)

Per essere sicuri che i database dei controller secondari del cluster siano sincronizzati con il database del controller primario bisogna eseguire alcuni comandi direttamente sulle istanze di mongodb. Per accedere alla console di mongodb prepare uno script con i seguenti comandi:

dialmongo() {
   agent=$(cd /var/lib/juju/agents; echo machine-*)
   pw=$(sudo cat /var/lib/juju/agents/${agent}/agent.conf |grep statepassword |awk '{ print $2 }')
   /usr/lib/juju/mongo3.2/bin/mongo --ssl --sslAllowInvalidCertificates -u ${agent} -p $pw localhost:37017/juju --authenticationDatabase admin
   }

ed eseguirlo sul controller del quale vogiamo controllare lo stato di sicnronizzazione del db. Una volta eseguito ci troveremo nella console di mongodb e potremo dare il seguente comando:

juju:SECONDARY> db.getReplicationInfo()
{
    "logSizeMB" : 1024,
    "usedMB" : 242.96,
    "timeDiff" : 12168,
    "timeDiffHours" : 3.38,
    "tFirst" : "Mon Jan 15 2018 11:25:38 GMT+0100 (CET)",
    "tLast" : "Mon Jan 15 2018 14:48:26 GMT+0100 (CET)",
    "now" : "Mon Jan 15 2018 14:48:27 GMT+0100 (CET)"
}

L’output del comando db.getReplicationInfo() ci restituisce informazioni sullo stato di sincronizzazione del db secondario con quello primario. Per ulteriori informazioni riguardo questo comando si rimanda alla pagina di reference di mongodb .

Per ulteriori dettagli e guide al troubleshooting di mongodb invece si rimanda alla pagina Troubleshoot Replica Sets di mongodb .

In caso di problemi ad un membro del cluster HA, si spegne la VM, se ne crea un’altra (o si rilascia la prima) e si ridà il comando enable-ha:

$ juju enable-ha --to ct1-juju2-04

In questo modo parte il processo di deploy sulla nuova macchina e la prima viene taggata come “demoted”.

Quando la nuova macchina è partita (stato Started) si puo’ dare di nuovo il comando enable-ha che rimuove la macchina “demoted” e la tagga come “removed”:

$ juju enable-ha

A questo punto si puo’ rimuovere definitivamente la VM da juju con:

$ juju remove-machine ID --force

(sembra occorra dare due volte il comando… alla seconda volta la macchina appare per qualche secondo come “started” e poi sparisce).