Diskless¶
Schéma de base¶
![digraph "arch" {
nodesep=0.6;
ranksep=1.7;
subgraph cluster_gluster {
label="GlusterFS cluster";
glusterd
}
subgraph cluster_islet1 {
label="Islet hypervisor #1"
glusterfs1[label="glusterfs"]
iscsi1[label="iSCSI"]
glusterfs1 -> glusterd[label="mounts",dir=back]
iscsi1 -> glusterfs1[label="exports",dir=back]
}
subgraph cluster_iscsi2 {
label="Islet hypervisor #2"
glusterfs2[label="glusterfs"]
iscsi2[label="iSCSI"]
glusterfs2 -> glusterd[label="mounts",dir=back]
iscsi2 -> glusterfs2[label="exports",dir=back]
}
subgraph cluster_compute1 {
label="Compute"
iscsid1[label="iSCSId"];
}
subgraph cluster_compute2 {
label="Compute"
iscsid2[label="iSCSId"];
}
iscsid1 -> iscsi1[label="mount",color=green,dir=back]
iscsid2 -> iscsi2[label="mount",color=blue,dir=back]
}](../../_images/graphviz-4860c9c55c158f64167702ab03133c5d980cc968.png)
Description¶
La solution proposée consiste en grande partie à réutiliser les systèmes dejà en place.
Concernant la méthode d’export des images, iSCSI reste la technologie pour exporter les images. 2 serveurs seront utilisés par ilots, ces serveurs seront partagés entre les noeuds de calcul de façon statique via la méthode de boot utilisée (Script milkcheck). A noter que cette méthode donne l’opportunité d’améliorer le système de HA et loadbalancing grâce à multipath (supprimant le partage statique des serveurs), néammoins cette méthode ne sera en place par défaut.
Les images diskless seront exposées aux serveurs iSCSI via un montage GlusterFS local, ces dernières seront accédées directement dans Gluster par les clients (au travers d’iSCSI). En cas de problèmes de performances et/ou de résilience aux pannes liés à GlusterFS, une copie locale des image est envisageable.
Concernant le build des images diskless, il est proposé de mutualiser les efforts sur un process de build utilisant pcocc et cloud-init. En effet, en réutilisant les hyperviseurs d’administration et la méthode utilisée pour installer et configurer les VM d’administration, il est possible de générer des images diskless comme une VM classique : a partir d’une image cloud de base, l’application d’un cloud-init permettrait d’obtenir le même résultat que le process actuel. Neammoins, en cas de problèmes avec ces nouveaux process, une bascule dans l’ancien processus reste possible.
Les images seront exportées et chiffrées au format RAW. A terme (Ocean 3.0), ces images doivent permettre un boot automatique des noeuds.
Il est également envisageable de mettre en place un système permettant l’execution de cloud-init lors du boot d’un noeud de calcul, les solutions proposées sont:
Un export iSCSI supplémentaire d’une ISO meta-data/user-data
L’utilisation de BMGR comme
DataSourcepour cloud-init.
Les mises à jour des images diskless se feront au travers de pcocc également, en suivant le même processus d’export que pour le build des images.