Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 07/02/2017, à 15:03

Christophe apprend Linux

KVM / plus de VM que de coeur ou thread dispo sur hôte?

Bonjour,

je souhaite utiliser KVM pour des projets personnels.

Quelqu'un peut il me dire si il est possible de faire tourner simultanément plus de machine virtuelle qu'il y de coeurs physiques ou de threads sur la machine physique hôte ?

Merci pour vos réponses.


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#2 Le 07/02/2017, à 15:47

opensrx

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Théoriquement si tu alloues 50% d'un cœur physique à une machine virtuelle tu dois pouvoir en faire tourner 2 sur le même cœur.
Quel est ton processeur et combien de machines virtuelles veux-tu faire tourner?
Penses que moins de ressources sont allouées et moins ta machine virtuelle est performante.

Hors ligne

#3 Le 07/02/2017, à 17:40

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Je suis effectivement du même avis que toi pour ce qui est de la théorie.

Mais est ce que KVM permet d'allouer des "moitiés"  de coeur physique ou de thread ? c'est toute la question.

Je ne connais pas KVM, c'est pour cette raison que je fais appel à vous.
Avec virtualbox c'est pas possible, sous vmware il me semble que c'est possible car il y a une quinzaine d'année je l'ai fait.


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#4 Le 09/02/2017, à 10:47

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Avec KVM, un vCPU c'est concrètement un thread sur l'hyperviseur.
Imagine que l'hyperviseur ait 4 cores.
Tu peux faire tourner simultanément 3 vms avec 2 vCPU chacune = 6 threads qui tournent sur 4 cores.
Les ralentissements apparaîtront quand tu pousseras simultanément à fond les 3 vms.
A part ce cas particulier, les 3 vms fonctionneront normalement.
En revanche, ce qu'il ne faut pas faire, c'est pour une seule vm, mettre plus de vCPU que de cores.

Hors ligne

#5 Le 09/02/2017, à 12:53

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

merci Outcast,

Mais si j'affecte plus de vCPU que de core disponible que ce passe t il ?
L'hyperviseur refuse ? le VM concernée ne démarre pas ? la machine hôte plante ? ou tout tourne mais avec de sévères ralentissement ?


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#6 Le 09/02/2017, à 13:32

opensrx

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Ca passera pas. Y a des limites au matériel.

Dernière modification par opensrx (Le 09/02/2017, à 13:33)

Hors ligne

#7 Le 09/02/2017, à 14:14

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Dans le cas d'une seule vm qui tourne avec nombre de vCPU > nombre de cores ce n'est pas du tout recommandé.
Mais ça tournera quand même avec parfois de faibles performances.
D'ailleurs, si tu configures ta vm avec virt-manager, il t'affichera le message 'L'utilisation d'un nombre trop important de vCPU peut affecter la performance".

Hors ligne

#8 Le 10/02/2017, à 11:53

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

C'est difficile pour moi de pouvoir me rendre compte de ce que signifie 'sévères ralentissements" ou "faible performance".

Mais ça l'est aussi pour vous, j'en suis bien conscient.

Le plus simple serait peut être de vous en dire un peu plus sur mon projet, qui est commandé par des besoins particuliers. Avant toute chose, il s'agit d'un projet personnel et privé même si les éléments sont de nature a faire penser au monde pro. J'ai la chance (ou la malchance ! ) de vivre dans une très grande famille recomposée.

Je souhaiterais pouvoir mettre en place un réseau avec les services suivants et utiliser le couple PROXMOX KVM pour la partie virtualisation :

1 machine physique hébergeant les serveurs en VM suivant : Mail, Squeezebox, Web (apache pour de petits sites dynamiques), BDD (mysql ou mariaDB), serveur de log, domotique (Jeedom), serveur MQTT (domotique)

1 machine physique hébergeant les serveurs en VM suivant : Routeur (PFsence), proxy, firewall, VPN, DNS,DHCP, annuaire

1 machine 100% physique pour le NAS/SAN (certainement sous freenas) avec service centralisé de MAJ des OS (95% sous sous Linux), serveur FTP, Bitorent, owncloud.

Si on part du principe qu'une VM = 1 vCPU et donc = 1 CPU, + 1 CPU pour l'hyperviseur, bien que certaine VM nécessiterait peut être plus que d'1 vCPU,  il faut 2 machines hôtes avec au moins 8 coeurs chacune ! Ce qui me parait énorme.

Ou alors je ne résonne peut être pas comme il faut, ou peut être faut il que j'organise le réseau différemment ?

A la lumière de ces compléments d'informations, qu'en pensez-vous ?
Merci à tous

Dernière modification par Christophe apprend Linux (Le 10/02/2017, à 12:00)


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#9 Le 10/02/2017, à 13:17

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Exercice très intéressant qui se résume ainsi :
J'ai 50 services à faire tourner, combien de machines physiques / virtuelles me faut-il ? et comment j'organise tout ça ?

Déjà, faut commencer par le pourquoi d'une vm.
Une vm ça sert à isoler un système entier du reste.
Une vm ça sert à être créée/détruite dans la seconde.
Une vm ça sert à être sauvegardée/restaurée dans la seconde.
Une vm ça sert à être redimensionnée (cpu, ram, disque, réseau, etc...) dans la seconde.
Une vm ça sert à être déplacée d'un hyperviseur à l'autre sans interruption de service.
Une vm ça sert à faire tourner un processeur arm sur x86.
Une vm ça sert à tester des configurations qu'on veut mettre sur des machines physiques.

Pour ce que tu veux faire, tu n'as pas besoin de tout ça.
Ce que je te recommande, c'est de prendre une machine relativement puissante et mettre les 50 services dessus.
Cette machine, c'est la machine "Compute".
Puis, tu prends une autre machine avec de gros disques durs, la machine "Storage".
Et surtout, un bon réseau 1Gbps pour relier le tout.
Dans ton architecture, t'as oublié un point très important, la sauvegarde/redondance des données.
Il se passe quoi si une des machines tombe en panne ?
Sur la machine "Compute", tous les services tournent dessus mais les données sont sur la machine "Storage".
Ainsi, si la machine "Compute" tombe en panne, tu ne perds aucune données.
Par conséquent, ta machine "Storage" doit être redondée.
Tu peux mettre en place un système de sauvegarde de "Storage" sur "Compute".
Autre point important, toujours dans le cas d'une panne, faut être capable de réinstaller "Compute" et "Storage" dans la seconde.
Sachant qu'il y a 50 services sur "Compute", t'as besoin d'un outil de provisionning (genre ansible) qui les installe et configure en 1 seconde.


Il y a une autre approche, celle des containers, genre docker.
C'est 100x plus léger qu'une vm.
Mais encore une fois, pourquoi isoler un service des autres ?

En fait, dans ce que tu veux faire, t'as plus une problématique de "Haute disponibilité" que d'isolation des services.
Pour cela, ton "Storage" doit être redondant et surtout avoir un outil de provisionning pour tout réinstaller / configurer dans la seconde.
ça empêche pas d'utiliser des vms pour modéliser tout ça avant de passer sur des machines physiques, c'est même très fortement recommandé car ça donne une idée de la puissance nécessaire de la machine "Compute" et de l'espace disque nécessaire pour "Storage" avant de passer à la caisse.

Hors ligne

#10 Le 12/02/2017, à 23:31

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

En fait dans ma réflexion, car cela fait plusieurs mois que j'ai commencé mon travail de recherche et de cogitation, me revoilà ...... au point de départ !!!

Effectivement, ce que tu dis, fût ma première interrogation. Faire tourner tous les services sur un même serveur ou mettre chaque service dans une VM ? Comme tu l'as dit et je suis d'accord avec toi, bien que je ne l'ai pas évoqué, mon plus gros soucis quand tout sera en place, c'est la disponibilité de l'ensemble. Tout particulièrement pour le serveur domotique car sinon je risque le black-out total ! J'avais prévu de doubler chaque machine physique pour faire de la HA

Après de multiple recherches et questions sur divers forum, j'ai fini par opter pour  la virtualisation. Ce qui me séduit par cette solution c’est de pouvoir bénéficier de certaines souplesses qui sont à peut prêt toutes celles que tu as énumérées : redimensionnement en fonction de l’évolution et de la charge dans le temps,  sauvegardes et restaurations, facilité de mise en place d’une HA avec un passage facile et transparent d’un hyperviseur à un autre en cas de défaillance et en plus toutes les VM ont leur disque en accès iSCSI sur le SAN/NAS avec un accès  gigabit ou 10 Gb sur un réseau dédier à cet effet, permettre une création simple et rapide de VM pour faire des essaies et autres expériences, avoir une bonne stabilité et en cas de plantage d’un service cela n’aura pas de conséquence sur les autres.

Jusqu’à ce que je pose ma question sur le forum, je pensais pouvoir faire des économies côté matériel. Mais je me rends compte qu’en fait il n’en est rien. En revanche je continue de penser que je ferai peut être des économies sur la conso électrique mais j’en suis même pas certain.

Que ce soit dans la solution de virtualisation ou d’un seul serveur, j’aurais besoin d’une machine avec au minimum 8 coeurs. En fait un microprocesseur à 10 coeurs serait recommandé. Ca chiffre à  900-1200€ en entré de gamme !!!  Une autre question se pose également pour ce qui est de la carte mère, 1 ou 2 processeurs ?  Car même à 2 processeurs, il faudra tabler sur 2 processeurs à 4 ou 6 coeurs chacun, sans parler de la mémoire à y mettre. Il y a aussi la solution de prendre une carte bi-processeur, d'y coller un processeur de 8 ou 10 coeurs et d'en ajouter un autre si cela devait être nécessaire.

Sachant, qu’il est impératif de mettre en place un environnement haute dispo, cela signifie que je suis obligé de doubler le serveur, que cela soit pour la virtualisation ou comme serveur unique.

Si j’ai compris tes propos pour la HA, dans le cas d’un serveur physique unique cela passe par du « provisionning ». Peux tu m’en dire un peux plus sur ce concept, car j’avoue que j’ai un peu de mal à comprendre le fonctionnement ?

Mon SAN/NAS sera lui aussi doublé pour assurer une bonne dispo et comme il est l’un des, voire même LE point central de l’installation avec des sollicitations en iSCSI et en accès normal, je pensais l’équipé de 2 connexions réseau 10 Gb l’un pour le flux montant et l’autre pour le flux descendant. Je n’écarte pas l’éventualité de l’équiper avec 4 connexions 10 Gb réparties sur 2 cartes réseaux. De manière à faire de load balancing avec 2x10Gb pour le flux montant et 2x10Gb pour le flux descendant. (J’ai refait le câblage de chez moi en cat6A 10Gb)

Du coup, j’avoue ne plus savoir très bien quelle solution retenir pour ce projet. Histoire d’avoir un bon compromis entre performance – coût – consommation – disponibilité. En d’autres termes, concilier…. l’inconciliable !!!

Au début, j’avais même envisagé d’installer un service par Raspberry. Le Raspberry est quand même équipé d’un quad coeur ARM…..Sauf bien entendu pour le SAN/NAS. J’avais trouvé ça idiot mais pas tant que ça finalement. Malheureusement, 2 choses ne me conviennent absolument pas sur le Raspberry pour la réalisation de mon projet : connexion limité à 100Mb et impossibilité ou trop compliqué de faire booter en PXE (pour éviter tous les problèmes liés à la carte mémoire). A moins que si une nouvelle version plus musclée sorte fin février….

Une autre info de mes cogitations, dans le cas de la virtualisation,  je voulais utiliser PROXMOX/KVM car c’est un couple issu de la communauté du libre et parce que c’est une virtualisation de type un barre métal et donc générant moins de ralentissement ou pour le moins nécessitant moins de ressources.

Je pourrais aussi, m’appuyer sur mes connaissances des logiciels pour prendre une décision. Mais je ne suis qu’un petit passionné bidouilleur qui est intéressée par tout ce qu’il ne connaît pas et qui même s’il n’a peur de rien souhaite bénéficier du côté pédagogique de son projet, et n’en connais pour l’instant pas suffisamment pour retrouver un semblant de direction.

Voilà, ou j’en suis. C’est à dire bien perdu !!!

Votre aide est la bienvenue, et vous aussi si vous passez dans le sud ouest……


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#11 Le 13/02/2017, à 18:07

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Ton projet est suffisamment complexe pour qu'il n'y ait pas de solution unique.
Il y a un concept important, le scale up et le scale out.
scale up : tu prends une seule machine de plus en plus grande / puissante pour que tout entre dedans
scale out : tu prends plusieurs petites machines et tu en ajoutes en fonction des besoins, c'est ce que tu voulais faire avec les Raspberry
Le scale out pose des problèmes d'orchestration, c'est à dire comment faire travailler les machines ensembles, c'est un sujet complexe, quand on peut l'éviter, faut l'éviter.

Dans ton cas particulier, tu peux t'en sortir avec 2 machines, la "Compute" et la "Storage".
Le point important, c'est le provisionning.
ça consiste à écrire un script qui installe et configure tous tes services automatiquement.
Ainsi, si tu pars d'un OS vierge, tu lances le script, il installe et configure apache, bdd, mail, firewall, dns, vpn, ftp, etc...

Concrètement, on part du cas ou t'as 2 serveurs, "Compute" et "Storage".
Tous les services sont sur "Compute" et toutes les données sont sur "Storage".
"Storage" sauvegarde une fois par jour les données sur "Compute".
Imagine que le disque dur de "Compute" est mort.
Tu le changes, tu installes le OS, tu lances le script de provisionning, il installe et configure tes services, "Compute" est de nouveau dispo et tout refonctionne.
Pareil avec "Storage".
Certes pendant la panne rien ne fonctionne, mais une fois le matériel de rechange installé, le serveur est quasi immédiatement dispo.
Si tu veux de la haute disponibilité, il est possible de prendre un 3ème serveur qui surveille les 2 autres, si l'un d'eux est en panne, il lance le provisionning et prend sa place, c'est automatique, l'interruption est courte, mais il faut 3 serveurs au lieu de 2.

En ce qui concerne Proxmox, je viens de comprendre pourquoi t'en parles.
Ce que tu veux faire, c'est un cloud.
D'un coté il y a "amazon web services" qui propose ses services, de l'autre il y a le client qui crée les vms.
C'est "amazon web services" qui s'occupe de tout le matériel, si un serveur est en panne, c'est "amazon web services" qui live migre la vm et répare le matériel.
Ainsi le client n'a plus du tout à s'occuper du matériel, ce qui est très pratique pour lui.
Sauf que dans ton cas particulier à toi, t'es tout seul pour gérer le matériel et le service.
Créer une telle séparation est artificiel et demande trop de travail.

En fait, tant que t'as pas une équipe dédiée pour le matériel, faut pas partir dans les solutions cloud.
Si les boites utilisent "amazon web services" c'est pour qu'elles n'aient plus à s'occuper du matériel et se concentrer sur les applications développées sur les vms. Dans ce cas la séparation des rôles est un réel apport de productivité.
Mais si t'es tout seul, que tu veux gérer toi même ton propre matériel et héberger tes propres services, c'est trop de travail de créer un cloud.
Mais ça peut être très formateur.
Faut voir quel est le but en fait.

Hors ligne

#12 Le 16/02/2017, à 00:25

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Grâce à cet échange je continue d’apprendre et je poursuis mes cogitations en repartant de zéro.

Tu dis « Le scale out pose des problèmes d'orchestration, c'est à dire comment faire travailler les machines ensembles, c'est un sujet complexe, quand on peut l'éviter, faut l'éviter. »

Je ne comprends pas en quoi cela est complexe d’interconnecter plusieurs serveurs/ordinateurs entres eux. En effet, chacun ayant sa tâche et son propre matériel, et en cas d’échange de données, le réseau Gb avec son switch est là !

Le HA dans ta solution, est basé sur le provisionning. Cette technique s’appuie sur un script qui a pour but d’installer et de paramétrer automatiquement les applications et les services dont j’ai besoin. Sachant que cela ne peut se faire que sur une machine dont l’ OS est déjà préalablement installé. Le problème pour moi, c’est que je n’ai jamais écrit de script. Il va donc me falloir apprendre le langage et sa programmation. Naturellement, cela ne me fait pas peur mais cela va me demander du temps.

En revanche, tu m’as soumis une idée à laquelle je n’avais pas pensée pour la HA. Au lieu de doubler systématiquement chaque serveur, prévoir 1 seul serveur de « secours » qui prendra la place du premier serveur défaillant. Ce qui permet d’économiser un peu sur le matériel. Le point faible étant que si plus d’un serveur tombe en panne, la HA est foutue !

Tu dit « En ce qui concerne Proxmox, je viens de comprendre pourquoi t'en parles.
Ce que tu veux faire, c'est un cloud. »

En fait j’avoue que je ne sais plus très bien ce que signifie précisément « un cloud ». Nous trouvons ce terme tellement utilisé à bonne et mauvais escient qu’aujourd’hui il est difficile de savoir ce qu’a voulu réellement dire celui qui l’a employé. C’est pour cette raison que je ne l’ai jamais utilisé.

Pour moi, un cloud, c’est faire travailler ensemble N machines équipées d’un ou plusieurs processeurs chacune, dans le but de leur faire tourner un ou plusieurs services de type différents.
En fait c’est créer un super ordinateur avec plusieurs plus petits afin d’additionner leur puissance de calcul et/ou de traitement.

Je ne pense que cela soit ce que je souhaite réaliser pour mon projet. Je recherchais, dans la solution de virtualisation, une économie de coût,de machine physique et donc de place occupée par la machine et de consommation électrique.

A mon sens, ce n’est pas un cloud, car dans mon cas je ne cherche pas à construire un super ordinateur en additionnant les processeurs, mais plutôt d’affecter un nombre limité de coeur d’une machine à une tâche précise. En d’autre termes, 1 tâche = 1 coeur.

Mais c’est vrai, que j’ai également rechercher une solution pour construire 1 super ordinateur auquel il serait possible, en fonction de la charge, d’ajouter de la puissance par l’adjonction de nouvelles machines. Ce super ordinateur à la puissance variable, constituerait donc un seul serveur physique sur lequel je pensais faire tourner autant de services et d’applications dont j’ai besoin. Lorsque je me retrouve un peu à l’étroit, hop, je rajoute de nouveau coeurs !!

Mais à priori, ce n’est pas faisable. C’est cela pour moi ce que je nomme « un cloud » qui se rapproche aussi de ce qu’on appelle « le calcul distribué ».

Pour en revenir à ce que tu disais : « En ce qui concerne Proxmox, je viens de comprendre pourquoi t'en parles.
Ce que tu veux faire, c'est un cloud. »

Ce choix du couple PROXMOX/KVM est surtout du au fait que c’est du libre, qu’il s’agit d’un type de virtualisation « barre métal », dont très proche du matériel ce qui induit moins de perte de puissance et plus de répondant pour les VM.
Mais c’est aussi, la simplicité de prise en charge de manière automatique et quasi instantanée de la HA. Dès qu’une ou plusieurs VM tombent, d’autres prennent le relais. Grâce au protocole iSCSI et/ou au partage NFS.

D’autre part, allant bénéficier un SAN/NAS avec FreeNas (BSD), j’en exploiterai donc toutes les fonctionnalités puisque le iSCSI initiateur et target, la virtualisation (les disques) tout comme différents partages comme le NFS  sont des fonctionnalités nativement prisent en charge.

Pour l’instant ta façon de faire me séduit par le nombres de matériel nécessaire.


Comme tu l’as dit le problème, si toutefois s’en est un, c’est qu’il n y a pas qu’une solution unique.

Je n’ai encore pris aucune décision et suis toujours autant dans le brouillard !
Ca me promet encore de nombreuse heures de cogitation et de nuits blanches….


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#13 Le 16/02/2017, à 10:04

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

La discussion dépasse ton cadre particulier, autant en profiter pour aborder ces concepts.
Quels moyens disposons-nous ?
Machines réelles
Machines virtuelles
Containers
Lequel est le plus adapté pour ce que je veux faire ?

Machines réelles, tout le monde sait ce que c'est.
Machines virtuelles, c'est faire tourner un système entier (noyau, réseau, applications, etc...) sur une machine réelle.
Container, c'est faire tourner une application / service indépendamment de la machine (réelle ou virtuelle).

Je vais prendre des exemples concrets.
Le 1er : Faire tourner 3 wordpress, l'un avec php 5.6 l'autre avec php 7 et le 3ème avec php 7.1
Comment faire ?
Machine réelle.
OS debian 8 qui a php 5.6 dans les dépôts.
On veut aussi php 7 et 7.1, mais si on ajoute un backport, on peut avoir qu'une seule version de php et pas 3.
Il y a 2 possibilités :
- on télécharge php 7 et 7.1, on les compile
A chaque mise à jour de php 7 et 7.1, faut répéter l'opération de compilation
- on lance des containers php 7 et 7.1
Avec docker, suffit de mettre à jour les containers
Plusieurs conclusions :
1 container = 1 service
Les containers c'est facile à installer / mettre à jour
Si on veut la dernière version d'une application, entre utiliser un backport, télécharger / compiler les sources, container, la solution la plus simple qui perturbe le moins le système c'est d'utiliser un container.

2ème exemple :
plusieurs postes de travail "haute disponibilité".
Comment faire ?
Un serveur puissant qui fait tourner des machines virtuelles.
Les postes de travail sont des clients légers (ils démarrent sur le réseau ou sur une carte SD) qui se connectent aux machines virtuelles.
Plusieurs conclusions :
1 machine virtuelle = 1 système entier
Nécessité d'un serveur puissant avec un hyperviseur / machines virtuelles
Nécessité d'un bon réseau
Redondance du serveur
Il y a beaucoup de machines réelles / virtuelles, il faut donc des outils de provisionning pour les installer / configurer

Remarques :
1 container = 1 service
1 machine virtuelle = 1 système entier
Par conséquent, il ne faut pas faire :
1 container = 1 système entier
1 machine virtuelle = 1 service

Pour ce qui est du cloud, ma définition, c'est la séparation des rôles entre ceux qui s'occupent du matériel et ceux qui s'occupent des machines forcément virtuelles.
Exemple, avec un cloud chez aws, si un serveur réel tombe en panne, ce n'est pas mon problème, je ne m'en apercevrai même pas en fait, la machine virtuelle est déjà migrée ailleurs sans interruption de service. Alors que sans le cloud, si j'avais un serveur réel qui tombe en panne, c'est à moi d'appeler l'hébergeur (par exemple ovh) pour qu'il change de disque dur, etc ... puis c'est à moi de tout réinstaller, etc... et bien évidemment pendant ce temps les services sont inaccessibles.

Hors ligne

#14 Le 16/02/2017, à 22:11

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Effectivement, je suis en plein hors sujet sur mon propre post ! Souhaite tu que nous continuons nos échanges en privé ?

Je commence un peu mieux a comprendre ta façon de voir les choses.

Pour synthétiser, les containers constituent une technique qui, en quelque sorte, prend ce qu’il y a de mieux dans les deux autres techniques (physique et virtualisation).

Si je comprend bien les notions que tu cherche à me faire passer, c’ est que pour déployer un « simple service » utiliser la virtualisation est disproportionnée.

Là ou la virtualisation doit tout re-créer (OS et applications ou services) la containérisation se met en place sur une machine avec son OS. Ce sont les fondations du fonctionnement, les éléments commun à tous les containers qui y seront par la suite installés. C’est un peu de la mini virtualisation ! C’est beaucoup moins « étanche » que la virtualisation. Du coup, si le système physique devient instable, c’est tous les containers qui sont susceptibles de s’arrêter. Ce qui n’est pas le cas dans la virtualisation.

Ca me fait beaucoup penser au principe de fonctionnement des « jails » sous BSD.

De plus, si je te suis toujours dans tes explications, la containérisation nécessite infiniment moins de ressources que la virtualisation.

Du coup, j’avoue que je suis assez séduit par la containérisation pour mon projet.

Mais, viennent alors plusieurs questions sur cette technique :

Quelle est la relation entre nombre de coeurs et nombre de containers susceptibles d’être déployer ? Est ce toujours 1 coeur = 1 container (1 service) ?
Comment proportionner le matériel ?
Est ce que chaque service à sa propre adresse IP ?
Bref, compte tenue de ce que je souhaite faire, comment choisir le matériel pour avoir la bonne puissance de traitement ?
Ou sont stocker les données de chaque container ?
Ces données peuvent elles être stockées directement sur mon  SAN/NAS via iSCSI ou NFS ?
Pour faire de la haute disponibilité, à quel niveau le test se fait il ? Au niveau du « poul » de la machine physique ou de celui de chaque container ?
Si un container plante, est il possible de faire du HA uniquement sur le ou les containers défaillants ou faut il remplacer toute la machine physique ?
Est ce que n’importe quels services et applications peuvent être mis dans un container ? 
Existe t il des restrictions à ce sujet quant à l’utilisation de containers ?
Existe t il des services ou des applications qui ne doivent ou ne peuvent pas être mis dans un container?
Comment s’installe un service ou une application dans un container ?
Les services ou les applications doivent ils être déjà dans une version container pour être containérisé ou est ce une installation « normale » ?
Docker est le plus connu pour faire de la containérisation, est ce le seul ? Si non, comment choisir ?
Docker ou autre équivalent sont ils libres ?

En revanche, la containérisation ne me permettra pas de créer des machines virtuelles pour des tests et autres expériences plus ou moins risquées. Du coup, il va quand même falloir que je prévois une machine physique pour cela.


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#15 Le 18/02/2017, à 10:45

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Avant de répondre aux questions, je balaie quelques idées reçues.
- Il y a pas si longtemps, pour isoler un service, il n'y avait pas d'autre choix que de le mettre dans une vm.
Mais aujourd'hui, avec les containers et surtout la simplification de leur usage (merci à docker) il y a une alternative crédible, opérationnelle, sécurisée et en pleine évolution pour répondre à ce besoin. Donc à part des cas très particuliers, les vms n'ont plus rien à faire la dedans. ça n'empêche pas certains (je parle aux vieux), par habitude, de continuer à faire 1 vm = 1 service.
- Les containers, ce n'est pas de la virtualisation, pourtant beaucoup considèrent docker comme de la virtualisation, pourquoi ?
Parce qu'il y a des images debian, ubuntu, centos, etc..., qu'ils ont une ip, qu'on peut se connecter dessus avec ssh, qu'on peut installer plein de services, etc... Ces containers ont l'odeur d'une vm, le touché d'une vm, le goût d'une vm, la forme d'une vm, le son d'une vm mais ce ne sont pas des vms car il n'y a tout simplement pas de matériel virtualisé.
Les jeunes ne font aucune différence entre une vm et un OS container pourtant, il faut la faire car à un moment il verront des comportements étranges qui s'expliquent uniquement par le fait qu'un OS container n'est pas une vm.

Pour venir à nos moutons.
Je veux installer le service mysql, comment faire ?
Il y a 4 possibilités :
Je compile le code source
J'utilise les dépôts officiels de la distribution
J'utilise les dépôts non officiels
J'utilise un container

Comment choisir ?
La réponse est simple, ça dépend de la version de mysql qu'on veut avoir.
Si on veut la dernière version => compilation du code source
Si on veut une version très récente => container / dépôts non officiels
Si on veut une version stable et maintenue plusieurs années => dépôts officiels

Pour la quasi totalité des utilisateurs, le plus simple est de choisir le dépôt officiel.
L'exemple de mysql est simple car il n'évolue pas beaucoup.

Prenons le cas de node.js ou une version sort tous les jours.
Le dépôt officiel est inutilisable.
Compiler tous les jours, c'est compliqué.
Les dépôts non officiels, faut avoir confiance dans la personne.
Reste le container docker officiel, simple à mettre à jour.

Maintenant, prenons le cas d'une application entière, de type wordpress.
On a besoin d'un serveur web, d'une base de données, de php.
Pour corser les choses, rajoutons du cache http et php.
Pour le serveur web, on prend du nginx
Pour la base de données, on prend du mariadb
Pour php, on prend php 7.1
Pour le cache http, on prend varnish
Pour le cache php, on prend redis
Si l'OS est une debian 8, dans les dépôts officiels, il n'y a pas php 7.1, les versions de nginx, varnish et redis sont obsolètes.
Bref, passer par des containers docker est le plus simple / rapide / évolutif à mettre en place.
On peut aussi se dire qu'on a pas besoin de tout ça et on se contente d'un simple apache 2.4, php 5.6 et mysql 5.5 et du coup, les dépôts officiels de debian 8 font l'affaire.
Mais rien n’empêche de faire des combinaisons, dépôts officiels et containers officiels.

Pour revenir au cas particulier de ton projet.
Je ne pense pas que t'as des besoins extrêmes et les dépôts officiels feront l'affaire.
Pour l'usage des vms, je n'en vois pas l'utilité à part créer toute ton infrastructure dans des machines virtuelles pour tester le bon fonctionnement avant d'acheter le matériel et le construire.

Comment j'aurai procédé ?
Créer les vms "Compute" et "Storage".
Créer les scripts de provisionning qui installent et configurent tous les services.
Utiliser les services qui tournent sur les vms.
Faire des tests de montée de charge.
ça donne une idée de la puissance nécessaire.
Acheter le matériel, le construire.
Lancer les scripts de provisionning sur les machines réelles.
Lancer les tests de montée de charge sur les machines réelles.
Plus tard, si il faut apporter des modifications, les tester sur les machines virtuelles, faire des tests, si ça fonctionne, modifier les scripts de provisionning, les lancer sur les machines virtuelles, si ça passe, le faire sur les machines réelles.
Ainsi, aucune bidouille n'est faite sur les machines réelles qui sont en production, mais tous les tests sont faits sur des machines virtuelles.
C'est ainsi que je vois l'agencement entre machines réelles, machines virtuelles et containers dans ton cas particulier.
ça t’empêche pas de créer ces machines virtuelles sur "Compute" pour ne pas avoir une machine en plus.
Ainsi sur "Compute" t'as tous les services + des machines virtuelles qui représentent "Compute" et "Storage" pour les tests.
Certes ça demande pas mal de travail d'abstraction mais à force, on s'y habitue.

Personnellement, j'ai un simple pc portable avec 16Go de ram, je crée une vm avec 12Go de ram, vm qui est un hyperviseur virtuel, et dans cette vm, je crée des vms. Oui, des vms dans une vm. Ainsi, je simule toute une infrastructure dans une vm, quand c'est validé, elle passe sur un serveur réel, l'hyperviseur virtuel devient réel. Cette façon de procéder me permet de ne pas bidouiller sur ma machine réelle qui est toujours propre.
De plus, j'ai une copie virtuelle de tous les serveurs réels, ça permet de tester des modifications avant de les passer en réel.

Hors ligne

#16 Le 18/02/2017, à 21:15

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

A la lumière de tes explications, je pense qu’en choisissant la solution VM ce n’était pas la plus judicieuse.

Tu m’as définitivement convaincu, j’opte  donc pour Docker. Je vais revoir complètement l’architecture de mon réseau mais il sera impératif de mettre œuvre de la haute disponibilité.

Le plus gros problème pour moi c’est que tu m’ouvre la porte d’un monde que je ne connais absolument pas.

J’ai donc besoin d’apprendre, de me former sur les points techniques dont je vais avoir besoin pour la réalisation de mon projet.

En l’occurrence, tout sur Docker, mise en oeuvre de Docker avec de la haute disponibilité, la programmation de script et le langage utiliser et enfin les techniques ainsi que la mise en place du provisionning.

Aurais tu des livres / sites / cours ou autres pdf à me conseiller pour me permettre d’ingurgiter toutes les connaissances qui me manquent ?


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#17 Le 19/02/2017, à 14:59

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

En utilisant docker, faut veiller à 2 choses :
- la nécessité d'avoir une version très récente d'un service
- l'obligation d'avoir une image officielle et non pas communautaire à cause des problèmes de sécurité

Je réitère mon estimation que tu n'as pas besoin de docker car les services que tu veux installer bougent très peu et en choisissant un OS récent, comme ubuntu 16.04, t'es tranquille. Quitte à utiliser exceptionnellement docker pour 1 ou 2 services mais c'est l'exception, pas la règle.

Concernant la haute disponibilité c'est un sujet très très vaste, il y a pas mal de documentation pour un SAN hautement disponible, d’où ma proposition de séparer l'architecture en un serveur "Compute" et l'autre en "Storage".

Pour ce qui est de ton apprentissage, je vais dire que tu es à l'étape une sur dix.
Pour progresser un peu, il y a 2 tutoriels qui brassent pas mal de concepts et d'outils, ils ont l'air simple mais je pense qu'il faut ~4 mois pour bien comprendre ce qui se passe.

Le 1er : http://www.pidramble.com/
C'est un cluster Raspberry Pi 2 hautement disponible pour héberger un site drupal.
C'est l'exemple type d'une architecture scale out abordée précédemment.
Il y a 5 Raspberry Pi 2 :
1 pour le load balancing http / monitoring du cluster avec munin
2 pour serveur http / php
2 pour serveur mysql
Les Raspberry sont provisionnés grâce à ansible.
- Tu vas ma dire que tu n'as pas de Raspberry pour tester tout ça.
C'est justement la ou ça devient magique, t'en as pas besoin, tu as les machines virtuelles pour ça.
Tu as un script qui crée 5 machines virtuelles sur ton pc qui sont ensuite provisionnées avec ansible.
Tu te retrouves avec un cluster hautement disponible avec des machines virtuelles.
Il y a également un script pour créer ces machines virtuelles dans le cloud chez digitalocean.
C'est ce que je dis depuis le début, pour chaque machine réelle, créer son clone virtuel pour faire des tests en local ou bien dans le cloud.
Enregistrer toutes les modifications dans la conf ansible et déployer en prod.
- Tu vas également me dire "mais il y a qu'un seul service par machine !!".
Oui mais on est dans le cas particulier d'un service hautement sollicité à forte charge, donc non seulement il y a un seul service par machine mais les machines sont redondées. D'ailleurs, le load balancer n'est pas redondé mais créer un cluster Raspberry Pi avec 6 machines ça commence à faire beaucoup.
Sur le site, il y a des vidéos pour monter son cluster de 5 Raspberry, il y a le wiki qui explique comment ça marche, puis le dépôt github avec les scripts ansible. Pour tout bien comprendre et reproduire chez soi, il y en a pour ~2 mois de boulot.

Le 2nd : https://ejosh.co/de/2015/05/ansible-for … visioning/
Comment créer un hébergement wordpress avec une vm, 5 containers docker et ansible.
ça parait simple mais il y a pas mal de concepts derrière.
Il y a 3 parties :
Provisionning de la vm avec ansible.
Provisionning des 5 containers avec ansible.
Provisionning de comment faire travailler les 5 containers ensemble.
C'est une architecture type microservices.
Il y a un dépôt github avec tous les provisionning ansible.
La encore, il a créé les 5 containers dans une vm, mais rien n’empêche de créer ces containers sur une machine réelle.
Pour tout bien comprendre, je pense qu'il y a ~2 mois de boulot.

Le concept clé dans tout ça c'est qu'il n'y a plus de frontière entre le réel et le virtuel et qu'on peut installer tout un cluster de 100 machines réelles et/ou virtuelles avec un simple fichier texte de quelques kilo octets.
Une machine réelle/virtuelle devient une simple application.

Dernière modification par outcast (Le 19/02/2017, à 18:19)

Hors ligne

#18 Le 20/02/2017, à 01:11

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Je réitère mon estimation que tu n'as pas besoin de docker car les services que tu veux installer bougent très peu et en choisissant un OS récent, comme ubuntu 16.04, t'es tranquille. Quitte à utiliser exceptionnellement docker pour 1 ou 2 services mais c'est l'exception, pas la règle.

Oups, emporté dans mon élan, j'en ai complètement oublié cette autre solution. Qui représente en fait la plus simple de toute !

Je vais donc y réfléchir. Pour cette solution, comment je dois procéder pour choisir le matériel afin d'avoir la puissance nécessaire pour tout faire tourner ?


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#19 Le 20/02/2017, à 09:42

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Commence par choisir ton OS.
Crée les vms et installe ton OS et les services.
Configure le tout.
Crée le provisionning avec ansible.
Fais des tests de bon fonctionnement et de charge.
ça te donne une idée de la puissance cpu, de la ram, des capacités disques.
Quand tout est au point, tu choisis le matériel qui convient le mieux.
Tu lances le provisionning sur les machines réelles cette fois.
Ainsi t'auras le provisionning et des clones virtuels des machines réelles.
Clones virtuels qui te permettront de tester les évolutions avant de les appliquer sur les machines réelles.

Hors ligne

#20 Le 21/02/2017, à 19:44

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Grand merci pour ton aide.

Tu m'a permis d'éviter un choix qui se serait très certainement révélé laborieux sans compter tous les conseilles et concepts que tu m'as appris a travers cet échange.

Je suis maintenant près pour passer à l'action.... enfin après m'être formé un minimum sur les points qui me sont inconnus.

@u plaisir de se re-croiser.
Christophe.


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#21 Le 21/02/2017, à 20:43

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Le sujet est passionnant.
Puis ton projet est complexe, on dirait mes clients qui veulent construire la tour Eiffel en 1 jour.
Ce qu'il faut comprendre c'est que tous ces outils permettent de faire évoluer l'infrastructure alors qu'on sait pas vraiment ou on va.
Tu commences par prendre une machine relativement puissante.
Dessus, tu crées 2 vms, une "Compute" et une "Storage".
Tu installes, configures, bidouilles, provisionnes etc... dessus.
Quand c'est satisfaisant, ces 2 vms sont la prod, tu les clones pour en faire le dév sur lesquels tu feras tes prochains bidouillages.
Ensuite, tu regardes au jour le jour si le serveur tient la charge.
Si c'est le cas, rien à faire, à part avoir un disque externe pour la sauvegarde.
Si ce n'est pas le cas, prendre une 2nd machine, et mettre la vm "Storage" dessus, mais cette fois ci en réel, grâce au provisionning, ça se fait en 5 min.
Puis en fonction de la charge, si besoin, sortir "Compute" sur une machine réelle.
Et ainsi de suite.
Rien n'est figé, tout évolue.

Hors ligne

#22 Le 23/02/2017, à 13:54

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

oui je vais procéder comme cela, petit à petit.

Une dernier concept encore à préciser.

A partir de quel moment, on peut dire qu'un serveur ou machine ne tient pas la charge ? Est ce en fonction du taux d'occupation du processeur  et à quel taux ? est ce en fonction des lenteurs constatés ? Est ce lorsque qu'elle ce met à planter régulièrement ?


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#23 Le 23/02/2017, à 15:32

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Excellente question.

Je surveille 5 points :
Charge CPU
Consommation de RAM
Trafic réseau entrant/sortant
Lecture/écriture sur le disque dur
Remplissage du disque dur

En général, t'as rarement les 5 points simultanément en goulot d'étranglement.
Pour le réseau, prends directement du Gigabit.
Pour le disque, vu ce que tu veux en faire, prends directement du 2To en SATA.
Pour la RAM, prends 16Go, comme ça tu pourras créer tes 2 VMs de prod et 2 VMs de dèv.
Pour le CPU, prends un i3 avec l'accélération matérielle vt-x et vt-d pour la virtualisation.

Ensuite, tu remarqueras que le CPU est rarement sollicité et que la RAM est utilisée majoritairement pour le cache.
Mais c'est pas grave, ils serviront quand tu utiliseras les VMs pour les tests.
Pour ta seconde machine réelle, t'en sauras plus après quelques temps avec les 2 VMs de prod.
ça se trouve t'auras pas besoin d'une 2nd machine réelle, et que les 2 VMs font l'affaire, tu pourras rajouter de la RAM et des disques pour les redimensionner.

Hors ligne

#24 Le 23/02/2017, à 22:38

Christophe apprend Linux

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Quels sont les niveaux d'occupation du CPU, de la RAM et traffic réseau permettant de dire que l'on est en surcharge ?

Pour moi je dirais que si le processeur est occupé  100% du temps à au moins 80 % de son max, c'est qu'il faut commencer à envisager une évolution. Pour la RAM c'est lorsque son taux d'occupation  est de 80% de moyenne. Pour le réseau je n'en ai aucune idée !

Je pense que pour mon projet, je vais opter pour 2 serveurs physiques dédiés, l'un au SAN/NAS (stockage) et l'autre qui hébergera tous les services et les applications (compute). Le 3ème est celui de secours qui prendra la main si l'un des 2 tombe, en utilisant le provisionning.


Ancien Windowsien 7 repentis !!
J'ai choisi de faire mes premiers pas dans le monde de Tux avec Ubuntu 10.04 64bits. J'ai un ordinateur portable Toshiba QOSMIO G40 64bits double coeurs.
Merci d'avance pour vos réponses et votre aide.

Hors ligne

#25 Le 24/02/2017, à 14:03

outcast

Re : KVM / plus de VM que de coeur ou thread dispo sur hôte?

Je reviens un peu sur un concept général mais fondamental.
En informatique, rien n'est figé, tout évolue et faut accompagner le changement.
Toute architecture rigide est vouée à disparaître.
Pour cela, il y a des idées très importantes comme l'isolation et l'indépendance.
Si je parle des 2 entités "Compute" et "Storage" c'est justement pour bien séparer ces 2 concepts indépendants.
Si on part sur un scénario "Compute" et "Storage" sont des VMs, après, en fonction de la charge, rien n’empêche d'avoir "Storage" sur une machine réelle. Machine réelle que tu peux toi même construire en sélectionnant les composants ou bien prendre un synology qui fera largement l'affaire.
De même pour "Compute", rien ne t’empêche de sortir certains éléments et les mettre dans le cloud si tu as besoin momentanément d'une puissance de calcul dont tu ne disposes pas. Tu peux même envisager que la machine de secours soit dans le cloud, ainsi tu paieras uniquement à l'usage.
Si tu ne fais pas la distinction entre "Compute" et "Storage", tu te retrouves avec un mélange ingérable et très difficilement évolutif.

C'est pour cela que la meilleure des démarches consiste à commencer petit en gardant à l'esprit que ça évoluera.
Mais il faut impérativement connaître les outils à disposition pour faire évoluer l'architecture dans le sens qu'on veut.

Hors ligne