Table des matières

Openstack

Haute-dispo

Rabbitmq

Il y a un ptit bug dans le RA qui pose problème au stop lorsque le FS n'est pas monté. Pour corriger le problème il faut éditer le fichier /usr/lib/ocf/resource.d/rabbitmq/rabbitmq-server et modifier la méthode rabbitmqctl_action() : 

case "$rc" in ... => "2)"

devient “1|2)”.

Filesystem

Le RA Filesystem peut poser problème lors qu'il manque le module kernel scsi_hostadapter. Il tente de le monter alors que c'est complètement inutile. Pour corriger le problème il suffit de commenter les lignes suivantes dans le fichier /usr/lib/ocf/resource.d/heartbeat/Filesystem, méthode Filesystem_start() : 

#       if [ "X${HOSTOS}" != "XOpenBSD" ];then
#               # Insert SCSI module
#               # TODO: This probably should go away. Why should the filesystem
#               # RA magically load a kernel module?
#               $MODPROBE scsi_hostadapter >/dev/null 
#
#               if [ -z "$FSTYPE" -o "$FSTYPE" = none ]; then
#                       : No FSTYPE specified, rely on the system has the right file-system support already 
#               else
#                       # Insert Filesystem module
#                       $MODPROBE $FSTYPE >/dev/null 
#                       grep -e "$FSTYPE"'$' /proc/filesystems >/dev/null
#                       if [ $? -ne 0 ] ; then
#                               ocf_log err "Couldn't find filesystem $FSTYPE in /proc/filesystems"
#                               return $OCF_ERR_INSTALLED
#                       fi
#               fi
#       fi

Neutron LBaaS agent

Une primitive LBS fait très bien l'affaire mis à part le faire que le script init ne tuera pas au stop les instance haproxy. Il faut donc légèrement modifier la configuration init pour gérer cela. Pour cela éditer le fichier /etc/init/neutron-lbaas-agent.conf et ajouter le bloc suivant à la bloc : 

post-stop script
        HAPROXY_PID=$(/bin/ps -e | grep haproxy | awk '{print $1}')
        [ -n "$HAPROXY_PID" ] && kill $HAPROXY_PID
        exit 0
end script

Ensuite déclarer la primitive dans pacemaker : 

primitive p_neutron-lbaas-agent lsb:neutron-lbaas-agent \
        op monitor interval="30s"

Neutron DHCP Agent

Une primitive LBS fait très bien l'affaire mis à part le faire que le script init ne tuera pas au stop les instance dnsmask. Il faut donc légèrement modifier la configuration init pour gérer cela. Pour cela éditer le fichier /etc/init/neutron-dhcp-agent.conf et ajouter le bloc suivant à la bloc : 

post-stop script
        DNSMASQ_PID=$(/bin/ps -e | grep dnsmasq | awk '{print $1}')
        [ -n "$DNSMASQ_PID" ] && kill $DNSMASQ_PID
        exit 0
end script

Ensuite déclarer la primitive dans pacemaker : 

primitive p_neutron-dhcp-agent lsb:neutron-dhcp-agent \
        op monitor interval="30s"

Neutron L3 agent

Une primitive LBS fait très bien l'affaire mis à part le faire que le script init ne tuera pas au stop les instance neutron-ns-metadata-proxy. Il faut donc légèrement modifier la configuration init pour gérer cela. Pour cela éditer le fichier /etc/init/neutron-l3-agent.conf et ajouter le bloc suivant à la bloc : 

post-stop script
        NEUTRON_NSMP_PID=$(/bin/ps -e | grep neutron-ns-meta | awk '{print $1}')
        [ -n "$NEUTRON_NSMP_PID" ] && kill $NEUTRON_NSMP_PID
        exit 0
end script

Ensuite déclarer la primitive dans pacemaker : 

primitive p_neutron-l3-agent lsb:neutron-l3-agent \
        op monitor interval="30s"

Mise en place de l'accès SSH entre les hyperviseurs pour la gestion des migrations d'instances

Il est nécessaire que les utilisateurs nova des hyperviseurs puissent se connecté entre eux. Pour cela, il faut :

  1. passer le shell de l'utilisateur nova en /bin/bash
  2. mettre en place une clé SSH unique et commune entre les hyperviseurs pour l'utilisateur nova : 
    su - nova
ssh-keygen
cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys
  3. établir une première connexion SSH vers tout les hyperviseurs sur chaque hyperviseurs en tant que l'utilisateur nova (le plus simple étant de le faire sur l'un et de partagé ensuite le fichier ~/.ssh/known_hosts)

Mise en place de l'agent de metadata

Cette explication est valable dans le cas d'une utilisation de Neutron.

Il faut à la fois agir sur Neutron qui à pour rôle de relayer les requêtes jusqu'au service de metadata et sur Nova qui héberge le service de metadata en lui même.

Il faut donc installer sur le Network Node le paquet neutron-metadata-agent puis éditer le fichier /etc/neutron/metadata_agent.ini :

  1. Configurer les informations de connexion à Keystone (auth_url, admin_tenant_name, …)
  2. Définir nova_metadata_ip qui correspond à l'IP (ou nom d'ĥote) du serveur API Nova
  3. Définir metadata_proxy_shared_secret qui est le secret partagé entre le Neutron (le proxy) et Nova (le service)

Il faut ensuite sur le serveur d'API Nova éditer le fichier /etc/nova/nova.conf et :

  1. vérifier que le service metadata est bien activé. Pour cela, vérifier que metadata est bien cité dans la variable enabled_apis
  2. définir la variable service_neutron_metadata_proxy à True
  3. définir la variable neutron_metadata_proxy_shared_secret comme sur le Network node

Il faudra ensuite redémarrer les services nova-api et neutron-metadata-agent.

Accès VNC aux consoles des instances

Il faut :