===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]]