Pour des raisons de cloisonnement, de performance, l’architecture de déploiement des services Nova est modulaire et permet de gérer des groupes logiques avec une notion d’arborescence (père / fils). Ceci est comparable à la notion de région, de zones et de Data Centres d’Amazon. Le découpage en zone géographique est la plus naturelle, mais celle-ci peut se faire par autre nature (ex : affaire), voire une combinaison des deux.
Un déploiement de Nova est une Zone. Le partitionnement des zones à base de groupes logiques permet en plus d’effectuer du Load Balancing entre zone, ainsi que la distribution d’instances d’un type d’hyperviseur. Chaque zone peut communiquer qu’avec ses fils et pas avec ses parents. Il n’y a pas de restriction dans la dépendance « parent / enfant ». Si une zone n’est pas capable de répondre à une requête, celle-ci est routée à un de ses fils. C’est le service « nova-scheduler » parent qui choisit le fils, le plus apte à répondre à la requête. Chaque zone a, à minima, les services Nova suivants : « nova-api » et « nova-scheduler ». Une zone qui ne partage rien ne peut être accédée que via ses API exposées. Il n’y a pas de partage d’objet de gestion entre zone (base de données, file de communication, utilisateurs et projets).
Les échanges d’information entre zones sont basés sur des capacités, c.à.d des expressions régulières de ce type: key/{value} ;[0,n]. Ces capacités sont envoyées, à fréquence régulière (flags = --zone-capabilities & --periodic_interval) à « nova- scheduler » afin qu’il puisse prendre les bonnes décisions d’allocation, mais aussi de répartition de charges, voire des alertes vis-à-vis du statut des fils (ex : nova-compute) qui est, à priori, effectué en mode pooling par le service « nova-scheduler ». Tous les échanges entre services sont effectués via des files AMQP. A titre d’info, toutes ces informations relatives aux capacités d’une zone sont disponibles via des API REST (ex : GET « /v1.0/zones/info ») qui donne les informations pour toutes les zones enfants, bien sûr. La même commande en mode CLI est (contexte initialisé) « # nova zone-info <CR> ».
server1@novadev:~$ nova zone-info <CR> +-----------------+---------------+ | Property | Value | +-----------------+---------------+ | compute_cpu | 0.7,0.7 | | compute_disk | 123000,123000 | | compute_network | 800,800 | | hypervisor | xenserver | | name | nova | | network_cpu | 0.7,0.7 | | network_disk | 123000,123000 | | network_network | 800,800 | | os | linux | +-----------------+---------------+ |
Pour obtenir ces infos sur les capacités (KPI pour l'opérateur) avec « val min », « val max », il faut positionner le flag « service »_ « capability » = « min », « max » dans le fichier de configuration lié au service "nova-compute", voire aussi le code "nova/scheduler/manager.py" et "nova/scheduler/zone_manager.py". Ci-dessous quelques exemples d'options associées au service "nova-compute", voire "nova-scheduler":
- --compute_cpu=0,100
- --compute_disk=0,25000
- --compute_network=0, 2800
Plusieurs autres flags semblent nécessaires, mais pour cela exhaustif, avec quelques exemples :
- --zone-name=zone1 # identification de la zone par son nom, vis-à-vis des parents,
- --allow_admin_api=true|false # permettre ou interdire, les opérations entre zones via les API,
- --enable_zone_routing=true|false # service « nova-scheduler » distribué ou pas.
NB: Il est important de mentionner que le code contient les KPI par instance (orienté client) avec un formatage pour graphe avec des données RDD (cpu: jauge, moyenne et max; disk: compteur, moyenne et max; network: compteur, moyenne et max). Ces fichiers RDD (Round-Robin Database) sont stockés sur File System, Swift ou S3, d'où l'importance de l'architecture générale de l'implémentation et de la configuration des composants OpenStack.Le détail du code est dans "nova/compute/monitor.py" (voir extrait de code ci-dessous).
def get_zone_capabilities(self, context, service=None):
"""Roll up all the individual host info to generic 'service'
capabilities. Each capability is aggregated into
<cap>_min and <cap>_max values."""
service_dict = self.service_states
if service:
service_dict = {service: self.service_states.get(service, {})}
# TODO(sandy) - be smarter about fabricating this structure.
# But it's likely to change once we understand what the Best-Match
# code will need better.
combined = {} # { <service>_<cap> : (min, max), ... }
for service_name, host_dict in service_dict.iteritems():
for host, caps_dict in host_dict.iteritems():
for cap, value in caps_dict.iteritems():
key = "%s_%s" % (service_name, cap)
min_value, max_value = combined.get(key, (value, value))
min_value = min(min_value, value)
max_value = max(max_value, value)
combined[key] = (min_value, max_value)
return combined
Un dossier spécifique au KPI (opérateur et client) devra voir le jour afin de mieux appréhender les implémentations réalisées.
Pour finir cette 1ère approche, après avoir lu le document (ici) disponible sur le site nova, voici 3 actions principales sur les zones :
- Ajout d’une zone (enfant) : # nova add zone « API URL » « username » « api key » <CR>
NB : La zone enfant aura été créé préalablement et les infos de « novarc » récupérées pour fournir qqs éléments à la commande ci-dessus.
- Liste des zones (enfant) : # nova zone-list <CR>
- Suppression d’une zone (enfant) : # nova zone-delete N <CR> # (N = ID de la zone).
Un autre document est à lire pour mieux appréhender le concept, il s’agit de « MultiClusterZones » (ici). D’ailleurs, dans ce document, on apprend une extrapolation de dimensionnement d’un environnement IaaS, sur la base de :
- 50 à 60 VM par host (pour le calcul, retenons 50),
- 200 hosts par zone (enfants),
- 200 zones parents (comprenant par zone parent de 2 baies avec 10 blades de 10 lames).
Soit au total, une capacité en terme de machines virtuelles = 200.000 VM sur du réseau à 10 ou plutôt 100 Gb/s.
Aucun commentaire:
Enregistrer un commentaire