Data Center Federation in OpenNebula

 Data Center Federation in OpenNebula

Nelle ultime versioni di OpenNebula è stato aggiunta una funzionalità per noi davvero interessante: il Data Center Federation.

Abbiamo già parlato più volte in passato di OpenNebula, un software OpenSource per gestire infrastrutture cloud basate su Xen, KVM o VMWare. Pochi giorni fa è stata rilasciata la versione 4.8 che migliora in maniera sensibile l’interfaccia utente perfezionando ulteriormente la funzionalità di Data Center Federation.

Ma di cosa si tratta?

Il data center federation permette di collegare tra loro le istanze di OpenNebula di più data center, in modo da poter usare un’unico entry point (via console o via interfaccia web sunstone) per controllare tutti i data center. Per utilizzare questa funzionalità è necessario che tutte le istanze di OpenNebula siano configurate per utilizzare MySQL come backend e non SQLite di default.

Si deve eleggere una installazione di OpenNebula come “Master” e, in quel sito, il database MySQL sarà configurato come Master di replica asincrona; tutte le altre installazioni di OpenNebula saranno considerate “Slave” e, analogamente, la configurazione della replica MySQL in queste sarà come Slave. La replica non interesserà tutte le tabelle del database MySQL ma solo quelle relative alla lista utenti, ai gruppi, ai permessi degli utenti e le zone.

Lato OpenNebula, bisogna dichiarare nel file di configurazione oned.conf se si tratta del master o di uno slave e, in questo secondo caso, qual è la URL delle RPC API del master; inoltre bisogna configurare attraverso Sunstone o a riga di comando, l’elenco dei server OpenNebula che fanno parte della federazione.

A questo punto, operativamente, cosa avviene:

  • se si esegue una operazione riguardante il datacenter OpenNebula locale (ad es. la creazione di un template, di una rete, di una VM, ecc.), essa viene eseguita localmente ed utilizzato il DB locale per mantenere le informazioni;
  • se si esegue una operazione che riguarda gli utenti, i gruppi, i permessi o le zone, si distinguono due casi:

 

  1. se l’operazione viene eseguita sull’OpenNebula “Master”, essa viene eseguita direttamente per poi essere replicata a tutti i data center attraverso la replica asincrona di MySQL;
  2. se l’operazione viene eseguita su uno degli OpenNebula “Slave”, essa viene intercettata dall’OpenNebula locale e viene lanciata una API sul master che esegue il comando come se avvenisse in locale; successivamente, come nel caso 1, il risultato viene scritto sul database MySQL Master locale per poi essere propagato a tutta la federazione.

 

Dalla versione 4.8, a tutto ciò viene aggiunta un’utile funzionalità: i messaggi di log contengono l’ID dell’OpenNebula che ha eseguito l’operazione. Pertanto è possibile utilizzare un syslog centralizzato per raccogliere tutti i messaggi di log, che però sono facilmente distinguibili attraverso l’ID del server.

 

In caso di update di OpenNebula, ovviamente bisogna eseguirlo manualmente in tutti i datacenter della federazione, però questo approccio permette di mantenere comunque il controllo anche durante la fase di upgrade: difatti le tabelle replicate sono retrocompatibili, pertanto più versioni di OpenNebula possono coesistere all’interno di una federazione.

 

Quindi, riassumendo, il data center federation permette di utilizzare un’unica installazione di Sunstone per comandare più datacenter con OpenNebula, semplicemente switchando il datacenter da controllare attraverso un popup. L’utilizzo di sistemi di replica asincrona come le RPC API e la replica asincrona di MySQL, rende questo sistema adatto anche in caso di datacenter distanti con elevata latenza.

Leave a Reply

Your email address will not be published. Required fields are marked *

diciassette − cinque =