Image : 07 (08/2011: images extraites de la documentation (Diablo) du site OpenStack et des slides de la société Nicira)
VLAN Manager
Quantum Single Service
Type :
|
Network Management
| |
Détail :
|
La release Diablo apporte une refonte importante de la
couche réseau avec la fonctionnalité « multi-nic » (diablo-3, ici),
mais aussi les prémices de Quantum avec son API WS RESTful (détails : uses
cases : ici,
API extension : ici,
…, voir plus amples détails sur le wiki Openstack, c.à.d : ici)
sur L2 de la couche réseau qui permet de créer des réseaux virtuels
par coupleur physique de chaque host et d’y associer par attachement des
ports logiques (par exemple avec le pilotage d’un switch virtuel ).
Dans l’exemple, ci-dessus, on voit bien que l’API (endpoint)
de la partie compute « Nova » et de la partie network « Quantum »
est différente. Toutefois, cela pourrait être le même "endpoint" (services : network et server portés par le même host, ex: openstack.com). Tout ceci concourt, à ce que le client maîtrise totalement sa
configuration réseau, comme il le fait pour la partie "compute (VM)" (flavor, image, etc.). On voit donc qu’il devient possible à ce que les clients
puissent implémenter des architectures applicatives multi-tiers avec un
découpage réseau et instance. Avant d’imaginer les évolutions apportées sur la
couche L3, on peut penser à la qualité de services (QoS, ACL, etc.) sur
la couche réseau, ce qui permettra aux clients d’avoir une visibilité totale
sur la sécurité, la sureté et les performances, en dehors d’Internet, bien évidemment, dans
le cas d’un IaaS public. Pour
les curieux, il y a même une démonstration de la mise en œuvre fortement automatisée d’une
application multi-tiers (ici).Pour les aficionados du réseau et plus particulièrement des éléments virtuels, il y a 2 posts très intéressants sur OpenvSwitch et Quantum d'OpenStack (ici et ici).
| |
Référence(s) :
|
OpenStack et slides de Dan Wendlandt : dan@nicira.com
|
Image : 06 (08/2011: images extraites d’un article du blog « Unchain Your Brain » (ici), with 3 contributors)
FlatDHCP
Type :
|
Network Configuration
|
Détail :
|
Ces 2 images sont intéressantes, car elles montrent la complexité de la configuration réseau. En
effet, on y trouve la configuration FlatDHCP et une variante de Haute
Disponibilité avec HA FlatDHCP et les 3 options possibles: Fail Over,
Multi-NIC et HW Gateway, ainsi qu’une 4ième relative à une variante
pour la Haute Disponibilité partant du principe que le réseau privé d’accès aux VM, voire plutôt le host
portant ce service pour l’ensemble des autres hosts peut tomber.
Logiquement, à la lecture des schémas, on devrait comprendre la topologie réseau adressant les switches (public & privé), les hyperviseurs avec 2 coupleurs réseau (eth0 & eth1) et leurs VM. On trouve 3 plages d’adresses réseau : eth0 avec 99.99.99.[1-128], eth1 avec 192.168.0.[1.128] et un plage du bridge associé à ce coupleur sur chaque serveur au bénéfice des VM, avec 10.[1-255].[1-255].[1-255]. Tous les flux entrants et sortants passent par le seul service « nova-network » qui assure les fonctions de DHCP, gateway, de filtres, etc Le schéma avec la variante HA fournit un service network par host de compute. Le code a été repris pour pouvoir intégrer cette fonctionnalité. |
Référence(s) :
|
Unchain Your Brain (blog, ici)
|
Image : 05 (06/2011: image extraite de l'article du blog de Rob Hirschfeld)
Type :
|
Hypervisor Management
|
Détail :
|
Ce schéma est intéressant, car je me suis posé la question de la prise en charge de différents hyperviseurs, dont certains gérés avec la couche d'abstraction libvirt (qemu, kvm, openVZ, LXC, ...) et d'autres directement avec des API. Ceci est vrai pour XCP, XenServer via XenAPI et ESX(i) 4.1 avec VMWareAPI. Pour exemple, la prise en compte d'un host "XenServer" sous Nova se fait par la mise en oeuvre d'une VM de service portant "nova-compute" sur ce host. Pour ce qui est du composant, module ou service "Nova Agent Proxy", il est intéressant de connaître son périmètre fonctionnel et son dialogue avec "nova-scheduler" et vCenter.
|
Référence(s) :
|
Rob Hirschfeld's Blog
|
Type :
|
Architecture
|
Détail :
|
Ce schéma est intéressant, car il montre la couverture fonctionnelle de la release Cactus pour les domaines suivants (Ressources IT de bas niveau, Intégration, Logique de Contrôle, API et/ou IHM de Management et API ou IHM de Self-Service). Il appartient à un article de Ken Peeple sur l’architecture fonctionnelle et technique d’OpenStack. Reste toutefois à préciser que la couverture affichée pour un domaine fonctionnel quelconque (partie en rouge), ex : « nova-network » ne peut être complète sur l’aspect opérationnelle, mais perfectible en richesse de périmètre fonctionnel et probablement technique. Lorsqu’un domaine est couvert que partiellement (ex : Monitoring / Instances), on imagine que le sujet est en chantier et qu’il sera couvert dans un release ultérieure. Il reste à réaliser une intelligence de placement sur plusieurs critères avec l’hétérogénéité des hyperviseurs pris en compte. Pour ce qui est du monitoring management, on trouve dans le code (partie « compute »), la production de fichiers RDD pour chaque instance. Il n’y a pas pour le moment, les moyens de les exploiter depuis des API (OpenStack ou EC2), voire l’IHM Openstack-dashboard.
|
Référence(s) :
|
Ken Peeple (Technical Director, Principal Engineer and Chief Technologist)
|
Type :
|
Network as a Service
|
Détail :
|
Ce schéma est intéressant, car il montre pour les versions supérieures à Cactus que la gestion réseau est totalement différente, tout en gardant les 3 modes précédents (Flat, Flat DHCP & VLAN pour des questions de compatibilité), mais ajoutant un 4èmeVirtual Network Service ». Dans ce schéma, on utilise la notion de port aussi bien pour les bridges que les switches virtuels. Les architectures réseau précédentes montraient leur restriction en termes de fonctionnalité, de performance et d’évolutivité. Les préconisations émises par un groupe Japonais ont dû inspirer partiellement ou en totalité les spécifications pour NaaS. Tout ceci n’est encore qu’à l’état de Draft en spécification (ici) et pour comprendre, il faut être plus imprégner des spécifications et de l’architecture réseau des anciennes releases. nommé «
|
Référence(s) :
|
Spécification OpenSource sur NaaS
|
Image : 02 (05/2011: image extraite d’une publication de Ken Pepple)
Type :
|
Architecture
|
Détail :
|
Effectivement, la plaque tournante de l’architecture Nova est RabbitMQ (MoM) avec au minimum, un « topic » par service. Ceci permet de décliner différentes topologies de services pour une architecture fortement scalable. Pour exemple, l’Image Store de Glance sera exportée via NFS pour être visible des services « nova-compute » relatifs aux hosts (hyperviseurs). Dans cette architecture, la base de données centralisée ne sera pas fortement sollicitée, car chaque environnement Nova déployé (notion de région, zones, sous-zones, etc.) embarque une DataBase avec le même DataModel, sans pour autant qu’elle soit totalement utilisée.
|
Référence(s) :
|
Ken Peeple (Technical Director, Principal Engineer and Chief Technologist)
|
Image : 01 (11/2010: image extraite du site d'OpenStack)
Type :
|
Architecture
|
Détail :
|
Ce fut l'un des 1er schémas de l'architecture générale de Nova (release Austin, voire Bexar) qui a permis de mieux comprendre les liens entre les différentes briques et services, ainsi que le rôle central de RabbitMQ.
|
Référence(s) :
| OpenStack |
