Le Software defined Data Center ne peut-il compter que sur la virtualisation ?
2 min read
A de nombreuses occasions j’ai expliqué que désormais l’élément essentiel d’un DataCenter était devenu la machine virtuelle. Le commutateur logiciel Nexus1000v a d’ailleurs joué un rôle crucial pour amener le réseau au niveau de la VM tout en offrant une gestion cohérente du réseau virtuel et physique.
Dans ce billet je ne considère que l’infrastructure serveurs, j’aurais l’occasion de revenir sur les autres composants d’infrastructure d’un DataCenter.
Il faut faire plusieurs constats :
- Un monde purement virtuel n’existe pas, il faut donc toujours disposer d’une infrastructure de serveurs physiques.
- De nouvelles applications ne s’accommodent pas encore de la virtualisation en production. Je pense en particulier à SAP HANA et à Hadoop
- Il reste toujours à un moment ou à un autre des ressources matérielles à administrer, des microcodes à mettre à jour, des nouveaux processeurs à prendre en compte …
En tenant compte de ces constats il est donc nécessaire :
- de disposer de solutions de serveurs qui s’attachent à baisser les coûts opérationnels qui constituent la grande partie des coûts de possession d’un serveur
- de prolonger les bénéfices de la virtualisation jusque dans l’infrastructure matérielle
- d’apporter de la souplesse aux environnements qui ne sont pas virtualisés.
C’est ce qui a été fait avec le serveur UCS qui a rencontré un rapide succès avec près de 30.000 clients. Depuis plusieurs trimestres IDC classe les serveurs UCS à la deuxième place des serveurs en lame X86 au niveau mondial.
Ce succès je l’explique par la rencontre de l’innovation apportée dans ces serveurs (un point unique d’administration, les services profiles, câblage unifié ..) avec l’attente des clients en matière de réduction des coûts opérationnels et d’agilité.
Fondement de l’agilité de l’UCS : le service profile.
Un forme de virtualisation au niveau du matériel puisque l’on crée une couche d’abstraction pour pouvoir définir toutes les caractéristiques d’un serveur physique indépendamment du serveur lui-même.
On parle ainsi d’un serveur « stateless », c’est-à-dire sans état …Les serveurs de la solution UCS n’ont en effet aucun état jusqu’à ce que on leur applique un service profile. C’est ce service profile (un fichier XML) qui va donner au serveur sa personnalité, ses caractéristiques.
Toutes les propriétés et configurations de l’infrastructure serveur sont ainsi programmables au travers de l’UCS manager.
Automatiser toutes les tâches du provisionnement d’un serveur physique.
L’UCS manager va pouvoir automatiser la gestion des éléments de bout en bout. Ces éléments sont tous ceux qui sont requis pour provisionner un serveur physique. Cela inclut par exemple :
- firmware BMC firmware
- firmware du contrôleur RAID et paramétrages
- firmware BIOS et paramétrages, incluant serveur UUID et boot order
- firmware du Network adapter et paramétage, incluant adresses MAC et WWN ainsi que les parameter de boot sur SAN
- Les Virtual port groups utilisés par les machines virtuelles travaillant avec la technologie VN-Link
- Configurations d’interconnexion, incluant les definitions uplink et downlink , les adresses MAC et WWN ,VLANs, VSANs, QoS, etc…….
Une fois le serveur UCS câblé, les ressources systèmes font partie d’un pool flexible qui peut être rapidement utilisé pour n’importe quelle demande nécessitant l’affectation d’un serveur.
Une industrialisation avec les services profile templates :
Les administrateurs peuvent aussi créer des templates qui pourront être utilisés pour provisionner une quantité de serveurs aussi simplement que pour en provisionner un seul.
La programmation du serveur UCS ouverte aux développeurs :
Les services profile et leurs paramètres associés peuvent être créés, modifiés et monitorés par des systèmes d’administration externes par l’intermédiaires d’API XML. Cette API facilite également l’intégration avec des CMDBs (Configuration Management Databases)
La structure des API XML de l’UCS en fait un outil puissant qui est simple à apprendre et à mettre en œuvre
Authors
