Inside vCloud Director : base de données, limitations et bidouilles de haut vol

J’en ai déjà parlé il y a quelques billets de vCloud Director, le logiciel de gestion de cloud privé/hybride de VMWare, un outil très structurant lorsqu’on décide de l’intégrer à une activité de production quelconque et en particulier lorsque la fonction d’hébergement contractuel face à des “clients extenes” à l’entreprise se développe.

VCD a des atouts indéniables, notamment en matière de gestion du SDN (isolation, filtrage, services de base etc. …), ceci étant, après quelques semaines d’utilisation et de découverte, j’avoue que certains aspects me laissent encore assez perplexe, même si le support VMWare est souvent de bon conseil.

Une des choses les plus frustrante de VCD, c’est son incapacité chronique à vous fournir des outils pour “forcer des suppressions” ou rapidement éradiquer toute une branche hiérarchique d’objets au sein de son interface (pas ailleurs claire et relativement réactive, comparée à vSphere Web Client ;) ). En effet, si vous souhaitez supprimer toute une organisation et les VM, Templates, réseaux qui y sont associés, vous devez passer par toutes les étapes de suppressions avant de terminer par l’organisation ! Imaginez un environnement complet constitué de plusieurs dizaines de VM, une dizaines de réseaux internes, de gateways diverses et variées : chaque objet doit donc faire l’objet d’une suppression unitaire ET DANS LE BON ORDRE. Impossible de supprimer un réseau tant qu’une VM y est rattaché, par exemple.

Plus ennuyeux encore : en cas de problème quelconque avec un élément que vous souhaitez faire disparaître de l’interface de gestion : même combat, vous allez vous battre contre de nombreux refus de suppression, pour, quelques fois, par dépit, appeler la hotline VMWare. Mais, au fait, comment la hotline s’y prend-t-elle pour vous sortir d’affaire dans ces situations critiques ? En fait, tout simple, s’y j’ose dire : quand on ne peut pas passer par devant, on passe par derrière via la base de données ;)

Certes, c’est risqué si vous ne savez pas ce que vous faites, mais c’est ENFIN efficace et définitif. Parmis les nombreuses manips que j’ai pu observé, l’une d’elle a retenue mon attention et est susceptible de résoudre certains problèmes “triviaux” qu’on peu rencontrer sur VCD : des problèmes de synchronisation des inventaires respectifs de VCD et vCenter. Pour pouvoir repartir du bon pied, il faut donc purger un certain nombre de tables SQL, puis redémarrer tranquillement votre vCD. C’est assez magique et relativement simple pour qui maîtrise un tant soit peu les environnements BDD.

Premièrement, stopper les cellules de votre vCloud Director (/etc/init.d/vmware-vcd stop sur vos appliances Linux)
Deuxièmement, exécuter les ordres SQL suivants sur votre instance VCLOUD :
delete from compute_resource_inv;
delete from custom_field_manager_inv;
delete from cluster_compute_resource_inv;
delete from datacenter_inv;
delete from datacenter_network_inv;
delete from datastore_inv;
delete from datastore_profile_inv;
delete from dv_portgroup_inv;
delete from dv_switch_inv;
delete from folder_inv;
delete from managed_server_inv;
delete from managed_server_datastore_inv;
delete from managed_server_network_inv;
delete from network_inv;
delete from resource_pool_inv;
delete from storage_pod_inv;
delete from storage_profile_inv;
delete from task_inv;
delete from vm_inv;
delete from property_map;

delete from QRTZ_SCHEDULER_STATE;
delete from QRTZ_FIRED_TRIGGERS;
delete from QRTZ_PAUSED_TRIGGER_GRPS;
delete from QRTZ_CALENDARS;
delete from QRTZ_TRIGGER_LISTENERS;
delete from QRTZ_BLOB_TRIGGERS;
delete from QRTZ_CRON_TRIGGERS;
delete from QRTZ_SIMPLE_TRIGGERS;
delete from QRTZ_TRIGGERS;
delete from QRTZ_JOB_LISTENERS;
delete from QRTZ_JOB_DETAILS;

Une fois ces ordres passés, pour les Oracliens, n’oubliez pas le mot magique : commit ;)

Enfin, redémarrez vos cellule VCD. Normalement, vos inventaires devraient se resynchroniser entièrement.

D’une manière plus générale, la base de données vCloud Director est finalement assez lisible et relativement bien verrouillées par des liens relationnels entre tables. Même si je ne vous conseille pas du tout de faire ce genre de choses sur un environnement de production, je vous suggère malgré tout d’aller jeter un oeil sur cette base sur un environnement de test ou bac à sable.

Enfin, et comme déjà évoqué dans un précédent billet, faites très attention aux Storage Policies, surtout pendant vos phase d’upgrade, les nombreux virages opérés par VMWare sur ces sujet depuis quelques années donnent rapidement des sueurs froides, notamment lorsque votre/vos vCenter sont intriqués à un vCloud Director.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *