====== 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 : - 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//) ===== 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// : - 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//. ===== Accès VNC aux consoles des instances ===== 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