Differences

This shows you the differences between two versions of the page.

--- progetti:cloud-areapd:best_practices:storage_external [2015/05/15 07:26] – fcosta@infn.it
+++ progetti:cloud-areapd:best_practices:storage_external [2016/11/30 15:52] (current) – fcosta@infn.it
@@ Line 1: / Line 1: @@
+===Storage external to the cloud===
+Si presenta ls necessita` di accedere a dischi dati esterni alla cloud. La macchina che ospita lo storage e` una macchina linux su cui si puo` installare il software di livello due di neutron, percio` puo` entare a far parte degli agent della cloud e accedere alle vm.
+Configurazione
+  * Installazione del software openstack-utils, openvswitch, openstack-neutron-openvswitch con tutte le loro dipendenze
+  * Configurazione solo della parte di neutron livello 2. Si possono copiare da un compute node i files /etc/neutron/neutron.conf e /etc/neutron/plugins/ml2/openvswitch-agent.ini. In quest'ultimo si sostituisce a local_ip l'indirizzo della rete data della propria macchina.
+  * Start di openvswitch e neutron-openvswitch-agent
+A questo punto lo storage e` entrato a far parte della cloud. Si puo` verificare con: (previo la creazione e source del file keystone_admin.sh):
+     neutron agent-list
+che il servizio sia attivo, e dallo storage:
+     ovs-vsctl show
+che esista il bridge br-tun e ci siano tutti i tunnel gre verso gli altri elementi della cloud.
+  * Creazione dell'interfaccia per comunicare con la cloud da aggiugere al bridge di interconnessione
+     ovs-vsctl add-port br-int nfs0
+     ovs-vsctl set interface nfs0 type=internal
+  * Assegnazione alla vlan interna: bisogna trovare il valore di segmentation_id della rete che si vuole raggiungere. Si fa con il comando:
+      neutron net-show network-name
+il network-name lo si trova con il comando neutron net-list
+il numero individuato coincide con l'id del tunnel gre di quella rete. Per comodita` assegno lo stesso numero al vlan tag della porta. Supponendo che provider:segmentation_id sia 4
+     ovs-vsctl set port nfs0 tag=4
+  * Assegnazione indirizzo ip e route statica. Se la vm da cui voglio fare il mount sta sulla rete 10.62.1.0
+     ip addr add 10.62.1.250/24 dev nfs0
+     ip link set promisc on
+     ip link set nfs0 up
+  * Configurazione dei flussi di br-tun
+E` necessario definire i percorsi tra i tunnel gre e modificare il vlan tag in id-tunnel. I comandi sono:
+     ovs-ofctl add-flow br-tun "table=22, priority=1, dl_vlan=4, action=strip_vlan, set_tunnel:0x4,output:3,output:4 (ecc.)"
+     ovs-ofctl add-flow br-tun "table=3, priority=1, tun_id=0x4, actions=mod_vlan_vid:4, resubmit(,10)"
+Dove la prima linea viene eseguita se il numero della vlan vale 4, quindi proviene dallo storage, toglie il tag, mette il tunnel id=4, (corrisponde al segmentation_id gia` trovato) e fa uscire il flusso su tutti i tunnel gre. Se ne puo` selezionare anche uno soltanto, per esempio se la porta 3 fosse quella del tunnel tra lo storage e la macchina che ospita la vm basterebbe mettere output:3.  Il numero della porta si vede con
+     ovs-ofctl show br-tun
+La seconda linea serve per il percorso inverso, quello che arriva con tunnel-id 4, viene cambiato in vlan id 4 per poter passare dall'interfaccia nfs0.
+Per rendere stabile la configurazione dello storage devono partire al boot openvswitch e neutron-openvswitch-agent; devono essere creati i files /etc/sysconfig/network-scripts/ifcfg-nfs0 e /etc/sysconfig/network-scripts/routes-nfs0, il primo per l'assegnazione dell'indirizzo, il secondo per la route statica se serve. Anche i comandi per i flussi vanno ripetuti al boot.
+=== Procedura automatica per i flussi ===
+Si puo` scaricare il tar file [[http://wiki.infn.it/_media/progetti/cloud-areapd/best_practices/gre.tar| GRE-Icehouse.tar]] oppure [[http://wiki.infn.it/_media/progetti/cloud-areapd/best_practices/gre-k.tar|GRE-Kilo.tar]] e installare rapidamente.
+<code>
+    cd /root
+    tar xvf gre.tar
+    cd GRE
+    ./install.sh
+</code>
+Vengono chiesti la directory di installazione e i segmentation_id. Lo script configura i flussi, prepara lo script da eseguire al boot e lo mette in /etc/rc.local, mette nel cron lo script di controllo se ci sono nuovi tunnel e manda un mail a cloud-support se fa delle modifiche.
+=== Debugging ===
+Se qualche cosa non funziona, la prima cosa da verificare e` se la vm riesce a pingare l'ip dell'interfaccia nfs0. Se non ci riesce e` possibile che il tunnel gre tra lo storage e il compute node che ospita la vm in questione non sia stato stabilito.
+Le azioni da fare sono:
+  * Individuare l'ip del compute node
+  * Verificare l'esistenza del tunnel loggandosi sullo storage e dando il comando:
+<code>
+    ovs-vsctl show | grep -A1 "type: gre"
+</code>
+    ottengo cosi` la lista dei tunnel con i relativi indirizzi ip
+  * Se il compute node che mi interessa non compare nella lista, faccio ripartire il servizio che dovrebbe crearmi il tunnel mancante e aggiorno i flussi:
+<code>
+    service neutron-openvswitch-agent restart
+    /root/ovs-gre/run-control
+</code>
+Per la lista degli storage e degli indirizzi ip: [[progetti:cloud-areapd:operations:production_cloud:debugging|cliccare qui]]