outcast
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.
Christophe apprend Linux
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 ?
outcast
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.
Christophe apprend Linux
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.
outcast
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.
Christophe apprend Linux
j'ai bien compris maintenant qu'une architecture réseau est en constante évolution. Pour se faire, il existe des outils de toutes sortes.
Aussi, je vais commencer petit à petit. Mais je tiens à 2 machines distinctes, physique !
Je vais commencer par ce qui est le plus urgent pour moi et qui m'est le moins difficile : la construction de stockage. Mon espace de stockage actuelle est dans le rouge.....
Mais cette machine NAS/SAN hébergera non seulement toutes les données mais aura aussi tous les services ayant un rapport avec la manipulation (manutention !!) des données comme par exemple serveur ftp, bittorent, owncloud, sauvegardes des machines du réseaux, gestion des maj des OS.... Objectif : mise en service et 100% opérationnel pour septembre au plus tard. Je suis en mode 100% DIY donc cela prends un peu de temps. Conception du boîtier rackable de 24 baies pouvant être facilement doublé par extension en cas de besoin, cogitation sur la fixation des disques, gestion des ventillos.....
Puis ça sera le tour du serveur et de toute ses technologies embarquées. Objectif : mise en service progressive pour être 100% opérationnelle pour la fin de l'année. Ce qui me laisse le temps de me former à tout ce que je ne connais pas !!
Je ne sais pas quelle est ta profession mais compte tenu de ta pédagogie je suis volontaire pour un stage à tes côtés sans rémunération.
mazarini
Si ca peut aider, pour xen (ca doit être semblable pour kvm) :
- on associe des cores à une VM (la VM ne pourra utiliser que ces cores, mais plusieurs VM pourront utiliser le même core)
- on fixe un nombre de cores virtuels pour chaque VM (une VM utilisera par exemple 2 cores virtuels qui pourront utiliser les cores physiques qui lui sont associés, donc au moins 2)
Ensuite le système répartie le temps de calcul entre les VM. Sur un même core, plusieurs VM peuvent se succéder et un système de priorité peut faire qu'une VM ait plus de temps que les autres. On peut également définir le temps d'un cycle.
On peut associer les VM à tous les cores et laisser le système gérer la répartition. Il n'est pas bon pour les performances qu'un core virtuel soit basculer d'un core physique à un autre.
Perso avec 8 cores, j'ai choisi d'attribué au moins 2 à 4 cores virtuels à chaque machine en fonction de leur importance et de leur autoriser 6 cores physiques pour facilité la répartition de charges en limitant les éventuels transferts entre cores physiques. Pas sur que ce soit le mieux.
Seule la mémoire physique limite la mémoire répartie entre les VM.
Christophe apprend Linux
Merci Mazarini pour cette précision.
Mais pour l'instant je vais laisser de coter les containers et la virtualisation pour ne faire que du 100% physique comme j'en ai parlé avec Outcast.
Quoiqu'il en soit, je mets ton information dans un coin de ma tête car c'est bon à savoir....
Merci
