Riprendiamo il precedente articolo per modificare l’installazione di un nodo di calcolo Gentoo Xen per utilizzarlo con il nuovo Cloud Controller ridondato OpenNebula la cui configurazione potete trovare qui.
Innanzi tutto modifichiamo il file hosts rendendolo simile a quello presente sul cloud controller, ma levando le impostazioni relative alla rete 172.17.0.0 inacessibile dai nodi:
/etc/hosts 172.16.0.1 cloud-01.lan.local cloud-01 172.16.0.2 cloud-02.lan.local cloud-02 172.16.0.3 cloud-03.lan.local cloud-03 172.16.0.250 cloud-cc.lan.local cloud-cc 172.16.0.251 cloud-cc01.lan.local 172.16.0.252 cloud-cc02.lan.local
Installiamo i pacchetti di base per l’integrazione con il cloud controller: prestiamo attenzione al pacchetto aggiuntivo aoetools per montare i dischi LVM:
emerge ruby nfs-utils aoetools lvm2 sudo
Una volta terminata l’installazione dei pacchetti, aggiungiamo la seguente riga nel file /etc/hosts
172.16.0.250:/srv/cloud/one /srv/cloud/one nfs rw,_netdev,hard,intr,rsize=8192,wsize=8192 0 0
E creiamo le directory con il mountpoint:
mkdir -p /srv/cloud/images mkdir -p /srv/cloud/one
Il mountpoint in questo caso è /srv/cloud/one invece che solo /srv/cloud in quanto il disco DRBD sul server Cloud Controller è montato in /srv/cloud/one per cui esportando la directory padre il disco montanto non verrebbe visto correttamente dai client nfs.
Ultima cosa importante è che di default sarà utilizzato NFS4 per cui è necessiario che sia il server sia il client abbiano la medesima configurazione del dominio all’interno del file /etc/idmapd.conf:
/etc/idmapd.conf [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = lan.local # Modificare questo valore [Mapping] Nobody-User = nobody Nobody-Group = nobody
Attiviamo il demone NFS in modo da far partire statd per il locking sul server:
/etc/init.d/nfs start rc-update add nfs default
Se nel kernel non avete compilato i moduli per il server NFS riceverete un errore, però potete soprassedere in quanto a noi server NFS client e il demone serve solo per far poartire il servizio ident. Quindi, montiamo il disco nfs con:
mount /srv/cloud/one
Riguardo al demone AoE, Gentoo non richiede alcuna configurazione, pertanto è sufficiente controllare il funzionamento con aoe-stat.
Prestare inoltre attenzione al fatto che i domini LVM devono essere online (è possibile controllarlo con lvdisplay). Nel caso in cui non siano visti online, è necessario lanciare:
vgchange -a y
Al limite inserire questo comando in rc.local per eseguirlo automaticamente ad ogni avvio.
Nel caso in cui sia una nuova installazione, ricordiamoci di creare l’utente oneadmin e il gruppo cloud:
groupadd --gid 1001 cloud useradd --uid 1001 -g cloud -d /srv/cloud/one -s /bin/bash oneadmin
A questo punto, possiamo provare a passare nella modalità non privilegiata con:
su - oneadmin
e modifichiamo il file /srv/cloud/one/.ssh/authorized_keys, duplicando la riga relativa a cloud-cc e impostando il nome host a cloud-01. ad es:
ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx oneadmin@cloud-cc ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx oneadmin@cloud-01 ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx oneadmin@cloud-02
Spostiamoci un attimo sul cloud controller e proviamo ad accedere in SSH sul nodo di calcolo:
su - oneadmin ssh cloud-01
Non deve chiedere la password (al primo login chiederà di salvare la chiave, rispondere di si), altrimenti c’è qualcosa che non quadra.
Torniamo sul nodo di calcolo e, come utente root, modifichiamo il file /etc/sudoers:
/etc/sudoers %cloud ALL=(ALL) NOPASSWD: /usr/sbin/xm * %cloud ALL=(ALL) NOPASSWD: /usr/sbin/xentop * %cloud ALL=(ALL) NOPASSWD: /sbin/lvcreate * %cloud ALL=(ALL) NOPASSWD: /sbin/lvremove * %cloud ALL=(ALL) NOPASSWD: /sbin/lvs *
Sul Cloud Controller, infine, aggiungiamo il server al cloud con:
onehost create cloud-01 im_xen vmm_xen tm_lvm onehost create cloud-02 im_xen vmm_xen tm_lvm
Ultima cosa alla quale bisogna prestare attenzione è che XEN 4.1 include un nuovo comando (xl) che progressivamente andrà a sostituire il comando xm con il quale si amministra l’hypervisor xen. Xm è mantenuto comunque in questa versione, però non è funzionante il sottocomando “sched-cred” per cui è necessario modificare il file xenrc e sostituire
export XM_CREDITS="sudo $XM_PATH sched-cred"
con
export XM_CREDITS="sudo /usr/sbin/xl sched-cred"
Personalmente ho provato a sostituire globalmente xm con xl modificando la variabile XM_PATH, però evidentemente non è compatibile.