raphael.semeteys@atosorigin.com Raphaël Semeteys fr openQRM 4.4 31 GNU GPL http://www.openqrm.com Plate-forme de gestion de data center visant à gérer des machines physiques, comme des images virtuelles, ainsi que de mettre en place du cloud computing. https://demo.openqrm.com 1.6 Gestion infrastructure virtuelle 1.0

Les critères génériques de l'évaluation Presto de QSOS Pérennité Logiciel provenant d'un fork ou avec une forte probabilité de fork dans un futur proche. Projet jeune (moins de 3 ans) ou connaissant des difficultés à stabiliser les versions de développement. Projet stable ou ayant un bon historique de gestion de crise. Les nouvelles versions apportent de façon prépondérante de nouvelles fonctionnalités. 2 Le projet existe depuis 2005 et provient de développements initiaux propriétaires. La branche 4.X est un portage global de Java vers PHP. OpenQRM a été élu projet du mois en 2006 sur sourceforge. Usage détectable sur Internet sans véritable activité communautaire Utilisation communautaire prépondérante Nombreuse références industrielles 0 Faible activité détectable via les listes de discussion et les forums. Deux ou moins de deux développeurs clairement identifiés. Équipe de développement réduite avec un turn-over important ou sans équipe de direction identifiée. Équipe de développement structurée comportant plus de 5 développeurs actifs. 0 La grande majorité des développements sont réalisés par une seule personne (Matt Rechenburg). Très faible activité, que ce soit sur les résolutions de bugs, les releases, l'ajout de nouvelles fonctions ou sur les espaces communautaires (wiki, forum, mailing list...) Activité détectable mais anarchique (pas feuille de route accessible facilement, pas de prévisions de nouvelles fonctionnalités ou de prévisions de nouvelles versions visible) Activité importante et visible via la mise en place de feuilles de routes traçant les requêtes de nouvelles fonctionnalités et/ou les prévisions de sortie des nouvelles version 1 Pas de stratégie détectable ou stratégie dictée par une société commerciale, un sponsor ou un individu unique. Stratégie décidée par l'équipe de developpement. Indépendance forte de l'équipe de développement, fort engagement du projet dans un processus de standardisation. 0 La stratégie semble décidée par le développeur principal du projet. Les droits sont détenus par quelques individus ou entités commerciales, facilitant le changement de licence Les droits sont détenus par de nombreux individus de façon homogène, rendant le changement de licence très difficile Les droits sont détenus par une entité légale, une fondation dans laquelle la communauté a confiance (ex: FSF, Apache, ObjectWeb) 0 Chaque contributeur semble détenir les droits sur son code, cependant il n'est pas fait mention de copyright dans le code et le nombre de contributeurs est très restreint. Licence, à pondérer uniquement si le client désire un jour devenir propriétaire du code Licence très stricte, comme la GPL Licence modérée entre les deux extrêmes (GPL et BSD), licence duale dépendante du type d'utilisateur (personne, société…) ou de leur activité Licence très permissive comme BSD et Apache 0 GPL. Licence très permissive comme BSD et Apache Licence modérée entre les deux extrêmes (GPL et BSD), licence duale dépendante du type d'utilisateur (personne, société…) ou de leur activité Licence très stricte, comme la GPL 2 GPL. Niveau d'industrialisation du projet Développements réalisés à plus de 60% par des employés d'une seule société Développements réalisés à 60% maximum par des employés d'une seule société Développements réalisés à 20% maximum par des employés d'une seule société 0 Pas d'offres de services identifiée Offre existante mais restreinte géographiquement ou en une seule langue ou fournie par un seul fournisseur Offre riche : plusieurs fournisseurs ou plusieurs langages 1 Le développeur principal du projet travaille en indépendant et offre des services de support et d'expertise sur openQRM (cf. http://www.rechenburg.com). Pas de documentation utilisateur La documentation existe mais est en partie obsolète ou restreinte à une seule langue ou peu détaillée Documentation à jour, traduite et éventuellement adaptée à différentes cibles de lecteurs (end-user, sysadmin, manager…) 1 Documentation en anglais dans un wiki : http://www.openqrm.com/?q=node/33. Pas de processus de qualité identifié ni d'outils de gestions de bugs Processus qualité non formalisé ou non outillé ou comportant des outils qui sont très peu utilisés Utilisation très active d'outils standards (tests unitaires, outils de gestion de build, outils de mesure de qualité du code) 1 L'outillage standard proposé par sourceforge est disponible. Packaging pour les différents systèmes d'exploitation Pas de packaging officiel pour la famille BSD Packaging existant pour quelques distributions de la famille BSD Packaging complet pour les distributions de la famille BSD suivantes : FreeBSD, OpenBSD, NetBSD et Mac OS X 0 Pas de packaging officiel pour les systèmes d'exploitations GNU/Linux Packaging existant pour quelques distributions GNU/Linux Packaging complet les systèmes de packaging .deb et .rpm 2 Paquets disponibles pour Debian, Ubuntu, Fedora, CentOS, SuSE. Pas de packaging officiel pour les systèmes de la famille Unix Packaging existant sur quelques systèmes de la famille Unix Packaging existant sur au moins ces 3 systèmes : AIX, HP-UX, Solaris 0 Le logiciel n'est pas disponible sur un système Windows. Le logiciel existe sous forme d'archive tout en un. Le logiciel dispose d'un installeur. 0 L'installation depuis les sources est hasardeuse et risquée L'installation depuis les sources est difficile ou limité (seulement à un OS, une architecture, la résolution de l'écran...) L'installation depuis les sources est outillée (vérification des dépencances, verification de l'installation, gestion de build) 1 Pas d'archive disponible Archive globale Archive séparée pour chaque module installable 1 Niveau d'exploitabilité Difficulté d'utilisation, demande une connaissance approfondie des fonctionnalités du logiciel Ergonomie austère et très technique Ergonomie élaborée et IHM comprenant des fonctions d'aide 1 Complexe à mettre en oeuvre. Pas de fonctionnalités de contrôle, ni d'administration Fonctionnalités présentes mais incomplètes ou à améliorer Fonctionnalités complètes et faciles de contrôle et d'administration. Intégration possible avec des outils tiers (ex : SNMP, syslog…) 2 Intégration de Nagios via un greffon. Adaptabilité technique Logiciel monolithique Présence de modules haut niveau permettant un premier niveau d'adaptation Conception modulaire, permettant des adaptations faciles par sélection et/ou création de modules 2 L'architecture d'openQRM est conçue dès le départ comme modulaire. Tout à la main Recompilation possible mais complexe, sans outils, ni documentation Recompilation facile, outillée (ex : make, ANT, Maven…) et documentée 2 Depuis la branche 4.X openQRM est développé en PHP et dispose d'un système de construction facile d'utilisation (http://www.openqrm.com/?q=node/78). Toute modification demande une recompilation du code Architecture conçue pour des extensions statiques mais exige une recompilation Architecture de plugins, conçue pour des extensions dynamiques et sans recompilation 2 L'architecture d'openQRM intègre un système de greffons, amélioré lors du portage de Java à PHP.

Elements d'infrastructure gérés par la solution Gestion standard des images virtuelles Portabilité de la solution de gestion Solutions de virtualisation supportées. Une seule et unique solution est supportée. Seules des solutions libres sont supportées (comme Xen, KVM ou OpenVZ par exemple). Les solutions libres sont supportées ainsi que des solutions propriétaires (telles que celles VMWare ou Microsoft par exemple). 2 VMware, Xen, Citrix XenServer, KVM et Linux-VServer. Libvirt est utilisé pour assurer une couche d'abstraction vis-à-vis de certaines solutions de virtualisation. Pas de compatibilité libvirt. Utilisation restreinte de libvirt. Utilisation complète de libvirt comme couche d'abstraction vis-à-vis de certaines solutions de virtualisation. 0 Outre les solutions de virtualisation, la solution peut ne supporter que certains systèmes d'exploitation (en hôtes comme ne invités). Seule une version spécifique d'un système d'exploitation est supportée. Plusieurs systèmes d'exploitation sont supportés comme hôtes et comme invités mais ce nombre est limité par rapport à ce que les solutions de virtualisation sous-jacentes permettent. La solution n'impose pas de contraintes autres que celles des solutions de virtualisation avec lesquelles elle est compatible. 1 La philosophie d'openQRM est construite autour de l'abstraction de Linux comme un ensemble de fichiers et d'un hyperviseur comme un fournisseur de ressources. Ceci limite l'usage à des serveurs Linux pour les hôtes. Installation et déploiement centralisés d'images virtuelles (provisioning). Aucune fonctionnalité de provisioning disponible. La solution offre la possibilité de déployer les images virtuelles sur le parc de machines physiques. La solution offre la possibilité de déployer les images virtuelles sur le parc de machines physiques ainsi que des fichiers de configuration dans les machines virtuelles. 2 La notion de déploiement de serveur Linux est complètement générique et réduite à du stockage et de la copie de fichiers. Cela offre une grande souplesse dans les possibilités de provisioning. Le greffon puppet-plugin permet en outre de gérer les configurations. Fonctionnalité de gestion manuelle du cycle de vie des images virtuelles : démarrage, arrêt, gel, clonage. Pas de gestion du cycle de vie des images. Gestion manuelle limitée au démarrage et à l'arrêt des images. Gestion du démarrage, de l'arrêt, du gel et du clonage d'images virtuelles. 2 Possibilité de démarrer, arrêter, redémarrer et désinstaller une image. Le clonage est également possible. Disponibilité d'un référentiel centralisé des images gérées par la solution. Aucun référentiel centralisé des images gérées par la solution n'est disponible. Référentiel centralisé des images basique. Référentiel centralisé des images avancé avec notamment des fonctionnalités de recherche avancées. 1 Le greffon Image-shelf permet de se connecter à des référentiels d'images dont celui d'openQRM qui est publique. Il est également possible d'en créer de nouveaux. Modèles configurables et réutilisables pour générer de nouvelles images. Aucune fonctionnalité de gestion de templates. Possibilité de gérer des modèles mais restant peu configurables et difficiles à gérer de manière simple et centralisée. Gestion de modèles centralisée dans un référentiel avec possibilité de configurer simplement les templates. 1 Certaines images peuvent faire office de templates (appelés golden-images). Possibilité de gérer des réseaux virtuels au sein de l'infrastructure. Possibilité de configurer des ponts (bridges) virtuels (couche réseau 2 Liaison de données). Pas de possibilité de configurer des ponts virtuels. Gestion des ponts virtuels disponible mais limitée et complexe à mettre en oeuvre. Gestion des ponts virtuels disponible, simple d'utilisation. Possibilité de gérer des ponts entre images virtuelles et machines physiques. 1 Possibilité de configurer des routeur virtuels (couche réseau 3 Transport). Pas de possibilité de configurer des routeurs ou switches virtuels. Gestion des routeurs ou switches virtuels disponible mais limitée et complexe à mettre en oeuvre. Gestion des routeurs ou switches virtuels disponible et simple d'utilisation. Possibilité de gérer des routeurs entre images virtuelles et machines physiques. 0 Fonctionnalités de gestion de réseaux virtuels. Aucune fonctionnalité de gestion de VLAN. Possibilité de rattacher les images à des réseaux virtuels de manière statique (attribution statique d'adresses MAC et IP). Possibilité de rattacher les images à des réseaux virtuels de manière dynamique (attribution dynamique d'adresses MAC et IP, via des mécanismes tels que DHCP par exemple). 2 Le greffon Cloud-Ipgroup permet de gérer des réseaux statiques (plage IP, sous-réseau, passerelle et DNS). Le greffon dhcpd-plugin fournit un serveur DHCP qui peut être couplé avec le mode de déploiement PXE d'openQRM. Fonctionnalités de virtualisation du stockage dans l'infrastructure. Types de stockages physiques supportés pour l'abstraction via virtualisation (réseau, SAN, iSCSI). Uniquement disques locaux des machines hôtes. Possibilité de virtualiser des espaces de stockage distants mais limitée à un seul type d'attachement (réseau, SAN ou iSCSI). Virtualisation et abstraction d'espaces de stockages distants indépendamment des types d'attachement (réseau, SAN ou iSCSI). 2 Disques locaux, filers NetApp. NFS, iSCCI, Aoe/Coraid : directeement ou au-dessus de LVM. Association d'espaces de stockage à des images, des pools de serveurs Pas de possibilité d'associer les espaces de stockage à des images ou à des pools d'images. Possibilité d'associer les espaces de stockage à des images mais pas à des pools d'images. Possibilité d'associer les espaces de stockage à des images et à des pools d'images. 0 openQRM permet de stocker les images mais pas d'y attacher du stockage virtuel. Fonctionnalités de gestion des images disques (snapshots). Aucune gestion des snapshots. Gestion des snapshots existante mais limitée et complexe d'utilisation. Fonctionnalités avancées de gestion des snapshots (référentiel, planification, etc.). 1 openQRM supporte LVM et NetApp et donc indirectement les snapshots. Gestion des utilisateurs accédant à l'outil Possibilité de configurer les droits des utilisateurs sur la gestion de l'infrastructure virtuelle. Pas de notion d'utilisateur, de rôle ou de gestion de droits. Il existe un gestion des utilisateurs et des droits requérant une authentification mais la base des utilisateurs est propre à la solution. Authentification et gestion des droits des utilisateurs externalisable via LDAP ou dans Active Directory. 1 Gestion interne des utilisateurs et des rôles Possibilité de déléguer l'administration d'une partie de l'infrastructure. Délégation d'administration impossible. Délégation de l'administration possible mais pas sur tous les types d'objets gérés dans l'infrastructure. Délégation de l'administration sur tous les types d'objets gérés dans l'infrastructure, permet de définir des zones d'administrations séparées. 1 L'utilisation du portail Cloud-portal permet de déléguer l'installation d'images virtuelles (ou physiques) par les utilisateurs mais il s'agit en fait d'un usage de type Cloud computing et non d'une réelle délégation d'administration. Existence d'un portail d'accès dédié aux utilisateurs non administrateurs. Pas de portail utilisateur. Possibilité de configurer les droits des utilisateurs sur la console d'administration de manière à leur donner une visibilité restreinte sur l'infrastructure. Existence d'un portail dédié aux utilisateurs non administrateurs leur donnant une vue sur l'infrastructure et éventuellement la possibilité de provisionner leurs images. 2 Portail de self-provisioning disponible via les plugins Cloud-plugin et Cloud-Portal, offrant une IHM ergonomique pour créer ses demandes de provisioning (Visual Cloud Designer).

Fonctionnalités de gestion dynamique de l'infrastructure virtuelle Possibilités de migrer manuellement des images Conversion de machines physiques en machines virtuelles Pas de conversion possible de machines physiques en machines virtuelles. Possibilité de conversion de machines physiques en machines virtuelles mais limitée par des contraintes techniques (OS, solution de virtualisation...) et complexe à utiliser. Conversion de machines physiques en machines virtuelles existente et simple d'utilisation. 0 openQRM permet de déployer des systèmes Linux sur des machines physiques ou sous forme d'images virtuelles. Cela permet d'envisager des migrations dans les deux sens. Il ne s'agit cependant pas de conversion. Possibilité de déplacer manuellement des images virtuelles entre machines physiques. Pas de possibilité de déplacer manuellement des images virtuelles entre machines physiques. Seul le déplacement manuel à froid d'images virtuelles entre machines physiques est possible, cela implique d'arrêter les images avant la migration. Le déplacement manuel à chaud d'images virtuelles entre machines physiques est possible, cela n'implique pas d'arrêter les images avant la migration. 1 Déplacement à chaud uniquement disponible pour des images Xen. Possibilité de déplacer manuellement des pools d'images virtuelles entre machines physiques. Pas de possibilité de déplacer manuellement des ppols d'images virtuelles entre machines physiques. Seul le déplacement manuel à froid de pools d'images virtuelles entre machines physiques est possible, cela implique d'arrêter les images avant la migration. Le déplacement manuel à chaud de pools d'images virtuelles entre machines physiques est possible, cela n'implique pas d'arrêter les images avant la migration. 1 Possibilité de reconfigurer des zones de stockage virtuelles en migrant les disques. Aucune possibilité de migrer des disques virtuels. Possibilité de reconfigurer des zones de stockage virtuelles en migrant à froid les disques. Possibilité de reconfigurer des zones de stockage virtuelles en migrant les disques à chaud 0 Mécanismes disponibles pour dynamiquement répartir la charge entre images Possibilité de répartir la charge entre différentes images virtuelles. Aucun mécanisme de répartition de charge entre images virtuelles n'est disponible. Possibilité de répartir la charge entre différentes images virtuelles mais avec un nombre restreint d'algorithmes de répartition. Possibilité de répartir la charge entre différentes images virtuelles avec la possibilité d'utiliser et combiner plusieurs algorithmes de répartition. 0 Déplacement dynamique d'images entre machines physiques en fonction de la charge Pas de déplacement dynamique d'images possible. Déplacement dynamique d'images possible avec utilisations de règles de gestion. Optimisation de la charge des machines via des scénarios couplés à la supervision des ressources. 0 Possibilité de configurer une solution de failover en cas de panne Aucune mécanisme de haute disponibilité n'est disponible. Failover disponible sur une panne du serveur physique hébergeant l'image virtuelle, avec un impact pour l'utilisateur (indisponibilité, perte possible de données...). Failover disponible sur une panne du serveur physique hébergeant l'image virtuelle, sans impact pour l'utilisateur. 2 Fonctionnalités de haute disponibilité disponibles via le greffon highavailability-plugin entre machines virtuelles (avec des technologies de virtualisation différentes) mais aussi entre serveurs physiques et machines virtuelles. Possibilité de réserver des ressources auprès du gestionnaire de l'infrastrcture virtuelle. Aucun mécanisme de réservation de ressources n'est disponible. Mécanisme de réservation de ressources disponible mais limité et complexe à mettre en oeuvre. Mécanisme de réservation de ressources complet et adaptable, éventuellement, possibilité de s'intégrer avec un gestionnaire de réservation externe. 0

Fonctionnalités mises à la disposition des administrateurs et des exploitants. Fonctionnalités disponibles pour exploiter l'infrastructure virtuelle. Possibilités offertes pour se connecter directement aux systèmes invités. Aucune connexion aux systèmes invités possible via l'outil d'administration. Connexion possible aux systèmes invités en mode console uniquement. Connexion possible aux systèmes invités en mode graphique uniquement (de type VNC), voire en mode sécurisé. 1 Connexion possible via SSH avec le greffon sshterm-plugin. Il est également possible de se connecter à la console d'administration VMWare d'un hôte via la console. La branche 3.X comportait un greffon bacula mais il n'a pas été porté. Possibilité de gérer les sauvegardes et les restaurations d'images virtuelles. Pas de sauvegarde possible. Sauvegarde et restauration à froid des images est possible via l'outil mais pas à chaud. Sauvegarde et restauration à chaud des images est possible via l'outil. 0 Possibilité de sauvegarder/restaurer un ensemble des machines virtuelles à un moment donné pour éviter tout problème de désynchronisation. Aucune fonctionnalité de sauvegardes/restaurations synchronisées de plusieurs machines virtuelles. Possibilité de sauvegardes/restaurations synchronisées à froid de plusieurs machines virtuelles, mais pas à chaud. Possibilité de sauvegardes/restaurations synchronisées à chaud de plusieurs machines virtuelles. 0 Fonctionnalités de mise à jour des systèmes gérés par la solution. Aucune possibilité de mise à jour des systèmes via l'outil. Fonctionnalités de mise à jour des images virtuelles gérées par la solution. Fonctionnalités de mise à jour des images virtuelles et des machines physiques gérées par la solution. 0 Fonctionnalités permettant d'automatiser des opérations d'exploitation complexes, telles que le scripting ou des workflows. Pas de possibilité d'automatiser des opérations d'exploitation complexes : pas de scripting ni de workflow. Possibilité d'automatiser des opérations d'exploitation complexes via du scripting et de l'ordonnancement simple. Possibilité d'automatiser des opérations d'exploitation complexes via du scripting et de le gestion de workflows. 0 Possibilité d'effectuer des recherches dans l'infrastructure via mots-clefs sur les noms des objets gérés par la solution. Aucune fonctionnalité de recherche n'est disponible. Il est possible de lancer des recherches sur l'infrastructure mais elles sont limitées à certains types d'objets. Il est possible de lancer des recherches sur l'infrastructure sur tous les types d'objets. 0 Fonctionnalités de surveillance et de supervision de l'infrastructure virtuelle. Nagios est intégré avec openQRM vi a un greffon qui permet de gérer les machines physiques comme les images virtuelles. Fonctionnalités de supervision des systèmes physiques gérés par la solution. Pas de supervision des systèmes physiques. Supervision des ressources des systèmes physiques (CPU, RAM, disques locaux, ...). Supervision des ressources des systèmes physiques (CPU, RAM, disques locaux, ...), d'éléments matériels (ventilateur et température par exemple) ou de la consommation électrique. 2 Disponible via le greffon Nagios. Fonctionnalités de supervision des objets virtuels gérés par la solution. Pas de supervision des systèmes objets virtuels (images, réseaux, stockage). Supervision des systèmes de certains des objets virtuels gérés par la solution (images, réseaux ou stockage). Supervision des systèmes de tous des objets virtuels gérés par la solution (images, réseaux ou stockage). 2 Disponible via le greffon Nagios. Mécanismes de déclenchement de notifications sur certains évènements au sein de l'infrastructure. Aucune mécanisme de notification n'est disponible. Possibilité de configurer le déclenchement de notification sur un nombre limité d'évènement et via le canal email uniquement. Possibilité de configurer le déclenchement de notification sur un grand nombre d'évènements, avec conditions et via plusieurs canaux de communication (email, SMS...). 2 Disponible via le greffon Nagios. Journalisation des évènements et des opérations au sein de l'infrastructure. Aucune fonctionnalité de journalisation, d'historisation ou de reporting n'est disponible. Existence de fonctionnalité de journalisation mais limitée à un niveau technique et ne pouvant pas être utilisée à des fins de resporting. L'outil propose des fonctionnalités de journalisation et de reporting avancées (statistiques, graphes, historiques...). 1 Possibilités d'intégration de la solution au niveau de la supervision. La solution ne propose aucune ouverture vers des systèmes de supervision externes. La solution peut être intégrée avec un système de supervision externe mais ne respecte pas les standard du domaine (SNMP, CIM...). La solution supporte un ou plusieurs standards de supervision (comme par exemple SNMP ou CIM) et peut facilement être intégrée avec un outil externe. 1 L'intégration avec SNMP est possible via l'utilisation de Nagios. Encryptage des flux d'administration Pas d'encryptage des échanges entre la console et les objets gérés. Possibilité de crypter les flux mais limitée à quelques types d'encryptage. Présence d'une infrastructure de gestion de la sécurité des flux, supportant plusieurs types d'encryptage. 1 La version 4.4 ajoute la sécurisation des flux via SSL et la possibilité d'implémenter d'autres mécanismes de sécurisation.