Conman """""" Schéma de base '''''''''''''' .. graphviz:: digraph "arch" { nodesep=0.6; ranksep=1.7; subgraph cluster_admin { label="Admin"; "admin"[label="conman_wrapper"]; } subgraph cluster_client { label="Client"; "client"[label="BMC"]; } subgraph cluster_mgmtclient { label="Management node"; "client2"[label="BMC"]; } subgraph cluster_server1 { label="Islet Hypervisor 1"; "server1"[label="conman"]; } subgraph cluster_server2 { label="Worker Hypervisor"; "server2"[label="conman"]; } "gluster"[style=dotted]; server1 -> client [color=blue,label=read,dir=back]; server2 -> client2 [color=green,label=read,dir=back]; server1 -> gluster[color=red,label=write]; server2 -> gluster[color=red,label=write]; admin -> server1[color=yellow] admin -> server2[color=yellow] { rank = sink; Legend [shape=none, margin=0, label=<
Legend
Client BMC access
Mgmt BMC access
File writes
Interactive consoles
>]; } } Description ''''''''''' La solution proposée pour la gestion des consoles hardware utilise un `conman` par îlot et un conman pour les nœuds de management. Les `conman` feront des écritures dans gluster. Les logs des consoles seront accédés via `gluster` alors que l'accès interactif aux consoles nécessitera le développement d'un wrapper réalisant la détection et la connexion aux serveurs `conman` associés aux équipements monitorés. Les configurations des différentes instances conman, ainsi que le cas échéant celle du wrapper, devront être générées par `confiture`. Conman ne permet pas la haute disponibilité mis à part par la bascule des VMs hébergeant le service. Ces dernières pourront éventuellement basculer sur les hyperviseurs `worker` ou `top`. .. raw:: latex \clearpage