QUESTIONS Cours 3 Flashcards
QUAND CHANGER DE NOEUD : La compagnie Netflix ne poss`ede pas d’infrastructure informatique et effectue toutes ses operations informatiques avec les services
Amazon EC2. Une strategie qu’elle utilise est de demarrer une instance, de mesurer sa performance et de la conserver si elle est au-dessus d’un certain seuil, ou au contraire de la terminer si la performance n’est pas acceptable. Combien d’instances un fournisseur de services infonuagiques devrait-il ordonnancer sur un
meme nœud physique : 4, 8, 10…? Est-ce que ce nombre doit plutot dependre de la memoire ou du nombre de coeurs du nœud, du comportement des l’instances? Quelle est la consequence de mettre trop ou trop peu d’instances sur un meme nœud?
Avec trop d’instances, une ou des ressources (e.g., CPU, disque, reseau) seront saturees et deviendront un goulot d’etranglement. En consequence, tout s’en
trouvera considerablement ralenti inutilement, et les clients seront mecontents.
Avec trop peu d’instances, aucune des ressources ne sera pleinement utilisee et il y aura de la capacite excedentaire inutilisee et donc gaspillee. L’ideal est de
grouper sur un meme nœud des instances complementaires qui n’utilisent pas toutes les memes ressources en meme temps. Ce peut etre plusieurs instances avec un taux d’utilisation faible et des periodes de pointes differentes, une instance gourmande en CPU avec une autre limitee par les entrees-sorties… Il est possible en premiere approximation de prendre un chiffre comme 6 ou 8
pour le nombre d’instances, en fonction de la charge moyenne d’une instance, et de la memoire et du nombre de coeurs disponibles sur un nœud. Sur un
service comme Amazon, les clients choisissent un type d’instance, ce qui donne une bonne idee quant a la charge attendue par l’instance.
EMPILER KUBERNETES ET OPENSTACK : Peut-on rouler Kubernetes par-dessus OpenStack? OpenStack
par-dessus OpenStack? Qu’en est-il de OpenStack par-dessus Kubernetes et Kubernetes par-dessus Kubernetes? Expliquez pour chaque cas comment cela peut ou non se faire, et commentez sur l’opportunite et l’efficacite d’une telle configuration.
Kubernetes par-dessus OpenStack est possiblement la configuration la plus courante. Le fournisseur infonuagique offre des machines virtuelles via
OpenStack et le client utilise cela pour un deploiement Kubernetes. Il n’y a qu’un seul niveau de virtualisation, ce qui est supporte par materiel et la performance est adequKubernetes par-dessus OpenStack est possiblement la configuration la plus courante. Le fournisseur infonuagique offre des machines virtuelles via OpenStack et le client utilise cela pour un deploiement Kubernetes. Il n’y a qu’un seul niveau de virtualisation, ce qui est supporte par materiel et la
performance est adequate. L’inverse est aussi frequent. OpenStack est assez complique a deployer et une configuration au-dessus de Kubernetes permet de
simplifier grandement son deploiement. Un fournisseur infonuagique pourrait facilement d´eployer OpenStack par-dessus Kubernetes pour offrir des machines
virtuelles a ses clients. Encore la, il n’y a qu’un seul niveau de virtualisation et la performance est bonne. Le client peut encore ici rouler Kubernetes par-dessus OpenStack (qui est par-dessus Kubernetes) sans probleme et avec une bonne performance.ate. L’inverse est aussi frequent. OpenStack est assez complique a deployer et une configuration au-dessus de Kubernetes permet de simplifier grandement son deploiement. Un fournisseur infonuagique pourrait facilement d´eployer OpenStack par-dessus Kubernetes pour offrir des machines virtuelles a ses clients. Encore la, il n’y a qu’un seul niveau de virtualisation et la performance est bonne. Le client peut encore ici rouler Kubernetes
par-dessus OpenStack (qui est par-dessus Kubernetes) sans probleme et avec une bonne performance.
Rouler Kubernetes par-dessus Kubernetes est moins frequent mais est possible avec une bonne performance. La difficulte est que certaines operations pour
configurer les conteneurs de Kubernetes requierent les privileges d’administrateur. Les conteneurs au premier niveau devront donc etre des conteneurs avec des privileges speciaux. OpenStack par-dessus OpenStack,
avec la virtualisation a chaque niveau, serait possible mais peu performant. Par contre, il est possible d’utiliser OpenStack en mode bare metal pour orchestrer
le deploiement de OpenStack par-dessus des noeuds physiques commandes par des modules de gestion de noeud (e.g., IPMI ou AMT). Tout comme OpenStack par-dessus Kubernetes, ceci est un moyen d’automatiser le
d´eploiement de OpenStack.
MIGRATION DES MACHINES VIRTUELLES : Une machine virtuelle dans KVM contient 4GiO de memoire
organisee en pages de 4KiO. On desire migrer cette machine virtuelle vers une autre machine physique localisee sur le meme reseau local et connectee avec un reseau de 100Mb/s soit 2000 pages/seconde. Par contre, on veut minimiser le temps ou la machine virtuelle est interrompue pour la migration et il faut donc
copier toutes les pages sans suspendre la machine virtuelle en notant les pages qui sont modifiees apres avoir ete copiees. L’execution de la machine virtuelle modifie ses pages en memoire au rythme de 100 pages differentes par seconde. On veut que le temps de suspension, pour copier les dernieres pages modifiees, soit inferieur a 1 seconde. Combien de temps durera la migration au total? Combien d’iterations de copies seront requises? Quel sera le temps d’interruption?
La machine virtuelle contient 1Mi pages = 1048576, ce qui demande 1048576 pages / 2000 pages/s = 524.288s. Pendant ce temps, 52428 pages pourraient etre modifiees, ce qui demande 26.21s secondes au
deuxieme tour. Pendant ce temps, 2621 pages seraient modifiees, demandant 1.31 secondes pour le transfert du troisieme tour. Rendu la, on suspend la machine virtuelle et il y aura 131 pages a transferer en .06 secondes pour finaliser le transfert avant de reprendre l’execution de la
machine virtuelle sur la nouvelle machine physique. Il faudra donc 4 tours de copies, un temps total de 551.86s mais une interruption de seulement .06s.
