Architecture logique¶
Pour définir, déployer et configurer une solution OpenStack, les administrateurs doivent comprendre l’architecture logique.
Comme le montre Principe de l’architecture, OpenStack se compose de plusieurs parties indépendantes, appelés Services OpenStack. Tous les services peuvent être authentifiés par un service d’identité commun (Identity). Les services individuels interagissent entre eux par le biais des API publiques, sauf si des commandes d’administrateur privilégiés sont nécessaires.
En interne, les services OpenStack sont composés de plusieurs processus. Tous les services ont au moins un processus d’API qui écoute les requêtes API, les pré-traite, et les transmet aux autres parties du service. À l’exception du service Identity, le travail se fait par des processus distincts.
Pour la communication entre les processus d’un service, un gestionnaire d’allocation de messages AMQP est utilisé. L’état du service est stocké dans une base de données. Lors du déploiement et de la configuration de votre cloud OpenStack, vous pouvez choisir parmi plusieurs gestionnaires d’allocation de messages ou bases de données, comme RabbitMQ, MySQL, MariaDB et SQLite.
Users can access OpenStack via the web-based user interface implemented by the Horizon Dashboard, via command-line clients and by issuing API requests through tools like browser plug-ins or curl. For applications, several SDKs are available. Ultimately, all these access methods issue REST API calls to the various OpenStack services.
Le diagramme suivant montre l’architecture de cloud OpenStack la plus courante, bien que ce ne soit pas la seule possible: