Index

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)”.

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

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"

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"

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"

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

passer le shell de l'utilisateur nova en /bin/bash
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
```
é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)

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 :

Configurer les informations de connexion à Keystone (auth_url, admin_tenant_name, …)
Définir nova_metadata_ip qui correspond à l'IP (ou nom d'ĥote) du serveur API Nova
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 :

vérifier que le service metadata est bien activé. Pour cela, vérifier que metadata est bien cité dans la variable enabled_apis
définir la variable service_neutron_metadata_proxy à True
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.

Il faut :

Sur les hyperviseurs : mettre les paramètres suivant dans le fichier /etc/nova/nova.conf :

vncserver_listen=[IP local de l'hyp data network]
vncserver_proxyclient_address=[IP local de l'hyp data network]
novncproxy_base_url=[URL public horizon]:6080/vnc_auto.html => exemple : http://openstack.exemple.com:6080/vnc_auto.html
vnc_keymap =   => volontairement vide, c'est à dire en mode automatique, il n'y que comme ça que ça marche bien !

Sur le noeud de management :
- Installer les paquets nova-consoleauth et nova-novncproxy
- Mettre le bloc suivant dans /etc/nova/nova.conf :
```
# VNC Console
novncproxy_host=0.0.0.0 (ou IP publique d'accès = IP d'Horizon)
novncproxy_port=6080
```