Encapsulation d'une VM dans un service

Introduction

La gestion des VM en tant que service OpenSVC amène de nombreux avantages :

  • Same start/stop/status commands accross non-virtualized services on different operating systems and services encapsulating virtual machines from different technologies (kvm, xen, docker, esx, hpvm, zone, lxc, vz, ...). This is very convenient for people responsible of production run because they are always capable of standard management tasks (start/stop/status), regardless of the virtualisation/container technologies that are used in your company
  • Mélange de service virtualisés et non-virtualisés sur un même hôte sans accroîssement de la complexité (excepté xen, ldom, esx)

  • Intégration transparente des hyperviseurs au plan de reprise d'activité unifié par OpenSVC

  • Bénéfice des pilotes de réplication de données de OpenSVC

  • Benefit from the OpenSVC Collector compliance features, performance monitoring, obsolescence management, alarming, and more.

L'installation de OpenSVC sur un hyperviseur existant est un processus trivial qui ne requiert pas d'arrêt de service. Ce guide détaille les étapes de ce processus :

  • Installer un paquet

  • Configurer les autorisations de clé ssh

  • Configurer le fichier configuration du noeud (un mot)

  • Configurer le fichier env du service (~15 lignes)

Installation de l'agent

Suivre le guide agent.install.

Création du service

Suivre le guide Création d'un service.

Configurer le fichier env du service

A typical VM service env file should look like:

[default]
app = ERP
comment = recette gen db #2
service_type = DEV
nodes =  node109 node110 node111 node112
autostart_node = node109

[container#1]
name = vm188
type = hpvm

[ip#1]
ipname = vm188
ipdev = lan0

[vmdg]
scsireserv = false

name

Si ce paramètre n'est pas configuré, le nom de la VM prend pour valeur le nom du service. Quand la VM encapsulée est déjà existante, il est probable qu'il soit nécessaire d'utiliser ce paramètre pour s'adapter au nom de la VM certainement différent du nom du service. Ce nom est utilisé par l'hyperviseur pour communiquer avec la VM. Il est donc possible qu'il soit nécessaire de passer un nom complètement qualifié si le resolver de l'hyperviseur n'est pas paramétré pour chercher dans le domaine de la VM. Les communications avec les zones se font par zlogin, donc les noms complètement qualifiés ne sont jamais nécessaires dans ce contexte.

type

Choose among kvm, xen, docker, esx, hpvm, ldom, vbox, zone, vz and lxc.

nodes

La liste des hyperviseurs habilités à faire tourner la machine virtuelle en situation nominale.

autostart_node

Positionner au nom de l'hyperviseur où la machine virtuelle doit tourner en mode nominal.

drpnode

Positionner au nom de l'hyperviseur où la machine virtuelle doit tourner en cas de plan de reprise d'activité.

drpnodes

La liste des hyperviseurs habilités à faire tourner la machine virtuelle en situation de plan de reprise d'activité.

scsireserv

Positionner ce paramètre à true si :

  • les disques sont partagés entre les hyperviseurs

  • et les disques sont dédiés au service

  • et les disques supportent les commandes de réservation persistante scsi3

ressources ip

Tous les pilotes de VM de OpenSVC, excepté 'zone', délèguent le montage des adresses internet au système d'exploitation de la VM. Les configurations de ressources ip dans le fichier env des services ont pour but la vérification de la santé du service. Ces vérifications sont :

  • ping 'ipname'
  • et exécute dans le contexte du système d'exploitation invité une commande vérifiant la présence de l'adresse internet sur la carte 'ipdev'.

ressource vmdg

Ajoutez cette bribe de configuration de ressource si les disques sont donnés tels quels en gestion à la machine virtuelle. La ressource 'vmdg' est un cas particulier de ressource 'vg' dont la liste des disques est obtenue par inspection de la configuration de la machine virtuelle. Les commandes OpenSVC 'start' et 'stop' y sont réduites à la gestion des réservations scsi puisque le reste est pris en charge par le logiciel de virtualisation. Cet inventaire est également utilisé pour la complétude de l'inventaire des disques.

Autoriser les communications ssh en tant que root entre les hyperviseurs

OpenSVC utilise ssh en tant que root pour exécuter des commandes sur les autres hyperviseurs. Ces commandes se limitent à :

  • vérification du host_mode distant

  • vérification des montages des systèmes de fichiers cibles des réplications de données

Autoriser les communications ssh en tant que root entre les hyperviseurs et l'invité

Cette étape ne s'applique pas aux zones, puisque zlogin est toujours autorisé. Les autres pilotes utilisent ssh en tant que root pour exécuter des commandes dans le contexte de la machine virtuelle. Ces commandes se limitent à :

  • vérification de la santé des ressources ip

  • exécution des lanceurs applicatifs dans le contexte de l'invité

Populer le répertoire des lanceurs applicatifs

This step is recommended but not mandatory. OpenSVC command set allows to start the virtual machine but not the embedded applications through the 'startapp'/'stopapp' commands. For this feature to work as expected, startup scripts should not reside in the operating system's proposed infrastructure (/etc/rcX.d, /sbin/rcX.d, DMF, ...). OpenSVC expects to find app launchers in /svc/etc/init.d in the guest file hierarchy. This feature is useless in docker's context, where docker image maintainer should have dealt with applications startup when docker container is started.

Test

You should now be able to run succesfully:

sudo svcmgr -s yoursvc print status
sudo svcmgr -s yoursvc push
sudo svcmgr -s yoursvc diskupdate
sudo svcmgr -s yoursvc stop
sudo svcmgr -s yoursvc start