En conséquence, avec le nombre de briques possibles, il s’avère important d’avoir une bonne maîtrise du sujet, car l’important est la mise en œuvre, l’intégration avec l’existant SI et la gestion opérationnelle de ce type de solution IaaS. J’ai découvert un document (ici) très intéressant de Dell qui évoque le déploiement et le maintien en condition opérationnelle de cet environnement IaaS, à l’aide de la solution Open Source (licence Apache2) Crowbar réalisée au cours du 1er semestre 2011 par Dell. La topologie et la configuration de la Haute Disponibilité du réseau ne sont pas décrites dans le document, mais le modèle existe et pour en bénéficier, il faut s’appuyer sur le consulting Dell. Quant aux serveurs HW, bien évidemment, Dell préconise le sien, mais peu importe, ce qui est intéressant c’est la démarche proposée, avec par exemple, un serveur d’administration Crowbar qui s’appuie sur Chef Opcode pour l’orchestration de déploiement initial. Le référentiel d’outils sur le serveur d’admin contient, entre autres ; Nagios, Ganglia, mais aussi tous les logiciels retenus pour le déploiement et la gestion de l’ensemble des nœuds de la ferme.
Crowbar fournit une
IHM et un panel de commandes CLI qui s’appuient sur une API Web Services
RESTful. Crowbar dispose d'une
fonction d'extension modulaire
qui permet aux différents composants
opérationnels d’être gérés indépendamment.
Chaque module, connu sous le nom de « barclamp », contient les données de configuration de déploiement
logique des composants par serveur. Les trois principaux aspects d’un « barclamp »
de Crowbar sont:
- Une API RESTful qui fournit le moyen de programmer le cycle de vie de modules « barclamps », ainsi que les nœuds exécutant les fonctions de « barclamps »,
- Une interface simple en ligne de commande pour chaque « barclamp ». La ligne de commande encapsule bien évidemment, les appels d'API Web Services
- Une interface UI pour chaque « barclamp ». Celle-ci fournit le moyen de gérer et manipuler le « barclamp » et sa configuration.
Crowbar fournit des fonctions de réinitialisation ou de réinstallation des
nœuds afin de permettre d’essayer
différentes configurations de
déploiement. Le nœud d'administration
gère l'ensemble des nœuds Nova &
Swift et Glance. Il attribue les adresses
IP autres nœuds;
il les démarre, les
configure et leur fournit les logiciels nécessaires à leur rôle. Pour fournir ces services, le nœud
d'administration s’appuie sur les logiciels suivants : Crowbar, Chef, DHCP, TFTP, NTP, et d'autres services. Il doit être le seul serveur
DHCP visible de l’ensemble :
- Crowbar Server : gère tous les nœuds, fournissant la configuration du matériel et des logiciels associés,
- Chef : gère de nombreux logiciels et permet de gérer les nœuds facilement,
- DHCP - attribue et gère les adresses IP pour les nœuds Nova & Swift,
- NTP - serveur de temps pour s'assurer que tous les nœuds sont alignés sur une horloge de référence,
- TFTP - PXE : démarre les nœuds Nova & Swift sous noyau Linux. Les services de TFTP permettent de passer des options au boot,
- DNS : gère la résolution de noms pour tous les nœuds.
Info : Baseboard Management Controller (BMC) hardware vLAN est utilisé sur chaque serveur
pour piloter les couches basses HW.
Le
petit centre de calcul (2 baies 48U proposées faiblement remplies) se base pour un
pilote sur 2 clusters constitués de 3 nœuds chacun avec des 2 liens (LAN)
réseau d’1Gb/s seulement (ceci est évidemment pas la topologie réseau :
débit, nombre de contrôleurs par serveur, redondance, etc.) et le serveur
d’administration. Ce qui donne environ avec les disques associés aux serveurs
une capacité aux alentours de 40To et 48 cœurs, soit environ 60 à 90 VMs. Côté
réseau, il est même préconisé d’utiliser des contrôleurs double ports à 10Gb/s.
Le
document est intéressant pour ceux qui n’ont pas l’habitude d’installer les
composants d’un centre de calcul avec les matériels suivants : baies,
switches, câbles, PDU, serveurs, etc. Plusieurs cas de figure d’extension de
composants matériels sont donnés par Dell pour remplir les 2 baies. Reste toutefois, à
bien maîtriser l’environnement IT, Nova, Swift, Glance et Crowbar, car dans l’hypothèse
d’un Data Centre d’un opérateur de services, voire d’un SI conséquent, ce n’est
pas 2 baies, mais 60 à 100 baies, d’où des problématiques de tout ordre :
alimentation, climatisation, débit réseau, redondance, etc. A ce stade, ce sont de vraies études d’infrastructure
de services qui sont à mettre en œuvre avec le choix ou l'intégration de composants traditionnels de gestion IT, le dimensionnement, la supervision de la
disponibilité et de la performance (sureté de fonctionnement) et de la sécurité (avec, si possible, la mise en place d'un SOC), sans oublier les autres
volets relatifs aux processus ITIL, ainsi que de facturation. Le schéma
ci-dessous montre bien cet écosystème pris en compte par des entreprises
partenaires au projet OpenStack.
Un autre point important vis-à-vis du développement, je pense qu'en dehors des contributions à la communauté, le développement propriétaire doit être au dessus de l'infrastructure et la piloter via les API Web Services proposés. Je pense particulièrement à l'IHM (client et opérateur) qui peut avoir une ergonomie et un look & feel propre à son identité, voire à ses services en plus de ceux d'OpenStack.
Aucun commentaire:
Enregistrer un commentaire