Recherche Logiciels de Virtualisations spécifiques

[invite5420aad7]

Bonjour,
Je cherche un logiciel de virtualisation qui me permettra de mettre en commun les ressources de plusieurs machines physiques et de les répartir selon mon bon vouloir.
Par exemple le serveur des archive est utilisé à 90% et celui des messagerie à 15%, je souhaite récuperer les ressources du serveur de messagerie et les faire exploiter par le serveur d'archives. J'ai trouvé juste un seul logiciel qui me le permet le VMWare ESX, mais je voudrais faire une étude comparative et savoir si il en existait d'autres.
Merci par avance
-----

[invitee840409b]

Bonjour,

Tu peux t'inspirer de l'architecture d'Olympe Network, qui est beaucoup plus stable depuis qu'ils l'utilisent. En plus, c'est du 100% libre et open source.
https://www.olympe-network.com/infrastructure

ProgVal

[invite5420aad7]

Bonjour,

Tu peux t'inspirer de l'architecture d'Olympe Network, qui est beaucoup plus stable depuis qu'ils l'utilisent. En plus, c'est du 100% libre et open source.
https://www.olympe-network.com/infrastructure

ProgVal

Bonjour,
merci pour ton message.
En fait est ce que tu peux un peux plus m'expliquer cette architecture. Je ne suis pas dans l'informatique Réseaux en fait mais dans mon stage je dois un peu le manipuler donc je ne comprend pas tout. C'est une architecture ou pour chaque étape tu installe un logiciel open source ? ou bien je dois seulement me préoccuper du logiciel proxmox. qui a l'air de gérer ce que je veux

[invitee840409b]

Il me semble effectivement que Proxmox devrait suffire.

[A voir en vidéo sur Futura]

[invite5420aad7]

Il me semble effectivement que Proxmox devrait suffire.

Concrêtement ce que ej cherche à faire dans le langage de l'informatique reseaux ca s'appelle comment?
Ca m'aidera surement à faire de meilleure recherche internet pour trouver une plus large gamme de logiciel capable de répondre à ma demande.

[invitee840409b]

Je ne suis pas un expert dans la gestion de serveurs (finances obligent), mais ça doit avoir un lien avec la notion de cluster et de cloud computing.

[invite5420aad7]

Je ne suis pas un expert dans la gestion de serveurs (finances obligent), mais ça doit avoir un lien avec la notion de cluster et de cloud computing.

Ok merci, bon déjà tu t'y connais mieux que moi.
LOOL
c'est vrai que ej suis étonnée qu'il n'y ai pas de professionel dans la branche réseaux qui m'ai répondu.
Vous êtes où?

[wandazefish]

Bonjour,
Le problème général est celui de la "répartition de charge" (ou "load-balancing").
Le sujet est vaste, des architectures très différentes permettent de le traiter...

- Le cluster VMware met en commun les ressources de plusieurs serveurs physiques. En cas de surcharge sur une machine physique, une ou plusieurs machines virtuelles (VM) de ce serveur sont déplacées vers une autre machine physique. Cela suppose que les machines physiques sont largement dimensionnées, et que le nombre de machines virtuelles hébergées sur chaque serveur est significatif. Par exemple, si tu as uniquement 1 serveur d'archivage et 1 serveur de messagerie, cette solution n'a aucun sens. Ajoutons que la virtualisation de serveurs physiques existants ("P2V" pour "Physical to Virtual") n'est pas toujours possible ou souhaitable. En particulier les serveurs de sauvegarde et d'archivage sont de très mauvais candidats à la virtualisation.

- pour le "cloud computing" la granularité de la répartition est bien plus fine, puisqu'on agit au niveau de la transaction, et non du système complet - mais je laisse à des spécialistes du sujet le soin de répondre...

[invite5420aad7]

Bonjour,
Le problème général est celui de la "répartition de charge" (ou "load-balancing").
Le sujet est vaste, des architectures très différentes permettent de le traiter...

- Le cluster VMware met en commun les ressources de plusieurs serveurs physiques. En cas de surcharge sur une machine physique, une ou plusieurs machines virtuelles (VM) de ce serveur sont déplacées vers une autre machine physique. Cela suppose que les machines physiques sont largement dimensionnées, et que le nombre de machines virtuelles hébergées sur chaque serveur est significatif. Par exemple, si tu as uniquement 1 serveur d'archivage et 1 serveur de messagerie, cette solution n'a aucun sens. Ajoutons que la virtualisation de serveurs physiques existants ("P2V" pour "Physical to Virtual") n'est pas toujours possible ou souhaitable. En particulier les serveurs de sauvegarde et d'archivage sont de très mauvais candidats à la virtualisation.

En tout cas maintenant je commence à mieux entrevoir les solutions et à mieux les comprendre aussi.
Aujourd'hui j'ai contacté une société qui m'a affirmé que la virtualisation ne ferait que déplacer mon problème à plus tard et ne l'arrangerait pas. Et qu'elle me proposait plutôt une solution de load balancing, mais ce que je ne comprend pas c'est que pour toi la virtualisation est une technique de load balancing.
Donc si je résume ce qu'elle m'a dit sur le sujet et sur ce que j'ai pu voir sur le net. Le principe s'applique sur deux serveurs ou plus qui effectue le même service (bien sur je dispose de bien plus de serveurs disons une dizaine), le load balancing répartit les charge à l'aide d'un boitier d'équilibrage des charges. Il faut pour ca fair un listing des applications et quels serveurs chacune d'elle utilise, pour déterminer quel serveurs sont à rassembler pour faire du load balancing avec telle application.
Jusque là ca passe je comprend, maintenant sur internet quand je regarde répartition de charge sur wiki je vois la phrase : " soit, comme certaines entreprises le proposent : acquérir le boîtier et faire appel au service de supervision qui l'accompagne", là pour moi la supervision fait intervenir la virtualisation et en plus je pensais que l'outil de virtualisation qui pouvait être une solution de rechange serait un hyperviseur et non un superviseur. Alors si quelqu'un peut m'aider sur ce point et m'expliquer un peu plus ce qu'elle signifie.

- pour le "cloud computing" la granularité de la répartition est bien plus fine, puisqu'on agit au niveau de la transaction, et non du système complet

Sinon pour le cloud computing, quand j'ai fait des recherches ce que j'ai vu c'est que c'est une méthode qui permet de travailler sur des serveurs à distance donc au final je en l'ai pas retenu comme solution applicable. Peux tu m'expliquer un peux plus le principe du cloud computing et comment le mettre en place?

Cordialement.

[invitee840409b]

Le terme de cloud computing est utilisé pour tout et n'importe quoi.
Moi, je l'utilise dans le sens où on est complètement déconnecté du matériel.

[wandazefish]

Bon, il faut en effet clarifier tout ça!

Le premier but de la virtualisation, c'est d'économiser des serveurs physiques: par exemple consolider la charge de 6 machines chargées à 10% sur une seule chargée à 60-70% . Donc, le contraire de la répartition de charge! La répartition de charge est apportée par l'association "virtualisation+cluster" proposée par VMware (et d'autres???) et qui permet:
- au moment de lancer une VM, de choisir le serveur physique le moins chargé.
- et - encore plus fort, quasi magique! - en cas de surcharge du serveur physique, de transférer automatiquement une VM vers un serveur moins chargé - sans arrêter le système actif ! avec une interruption de service imperceptible (1 ou 2 secondes).

Ceci dit, la virtualisation de 10 serveurs d'entreprise est un projet stratégique, et pour le justifier il faut trouver d'autres arguments qu'une économie - qui se révèle vite illusoire! - portant sur 2 ou 3 serveurs physiques! Autres bénéfices à attendre: la résistance aux pannes, les économies de surface au sol, de climatisation, d'électricité, la rapidité de déploiement de nouveaux systèmes...

Et à cette occasion d'autres enjeux apparaissent vite:
- la modernisation (lire: remplacement!) du parc de serveurs. Eh oui! Vouloir monter un cluster robuste et équilibré avec un assemblage hétéroclite de machines achetées lors des 10 dernières années, ce n'est pas très raisonnable...
- à cette occasion on en profite souvent pour délocaliser ce nouveau parc chez un hébergeur tiers...
- la normalisation des socles techniques et des procédures d'installation des systèmes
- les outils et procédures de supervision et de prévision d'équipement ("capacity planning")
- la remise à plat du Plan de Reprise d'Activité (PRA)...

Autant dire que ça ne dessine pas sur un coin de nappe entre la poire et le fromage!



Les boitiers dont tu parles sont des boîtes noires dédiées à la répartition de la charge du réseau. Ils sont donc efficaces quand la charge des machines est proportionnelle à la charge du réseau. C'est en général le cas pour des applications web (transactions courtes et homogènes). C'est moins efficace pour les infocentres et l'informatique décisionnelle. C'est inefficace pour les serveurs de sauvegarde et d'archivage...
Le boîtier se met typiquement en amont des serveurs HTTP. On peut aussi faire une répartition de charge entre les serveurs HTTP et les serveurs d'application. Pour ce faire d'autres dispositifs sont aussi envisageables - par exemple: plugin sur le serveur Apache, fourni par le serveur d'application.
La répartition de charge peut se faire par sous-réseau, par adresse IP, par session, par transaction... Le problème récurrent est celui de la persistance de session: ça passe pour les applications transactionnelles bien écrites, mais toutes ne le sont pas... et on peut tomber sur de vraies incompatibilités. Par ailleurs il faut "redonder" le boitier sinon ça devient un "SPOF"... et c'est dommage!

Bien entendu on peut mixer virtualisation et boitier de répartition.

En espérant avoir été plus clair...

[polo974]

Réponse très intéressante de wandazefish, mais on peut toujours sourire aux modes (variables par définition):

...
- à cette occasion on en profite souvent pour délocaliser ce nouveau parc chez un hébergeur tiers...

L'externalisation d'un intranet, c'est un concept assez étrange tout de même...
Une petite panne du modem, un câble télécom arraché (si, si, ça arrive souvent),un bug chez le fai, le prestataire, et c'est toute la boite qui est figée.
c'est plus du spof, c'est du scof ( chain à la place de point, voir plus bas)

...
La répartition de charge peut se faire par sous-réseau, par adresse IP, par session, par transaction... Le problème récurrent est celui de la persistance de session: ça passe pour les applications transactionnelles bien écrites, mais toutes ne le sont pas... et on peut tomber sur de vraies incompatibilités. Par ailleurs il faut "redonder" le boitier sinon ça devient un "SPOF"... et c'est dommage!

Bien entendu on peut mixer virtualisation et boitier de répartition.

En espérant avoir été plus clair...

Ben, heu... (si quand même, et merci!)
c'est beau "spof", surtout en gras, mais quezako (google et wiki à la rescousse (comme d'hab))
single point of failure
le point de passage obligatoire que s'il est en carafe, tout est dans les choux (ça c'est clair pour nous les gaulois )...

[invite5420aad7]

Normalement je pense que oui mais bon.
Je préfère résumer ce que j'ai compris pour être sur.
ALors il existe trois possibilités.

1) "virtualisation + cluster"

Avantage : -> lors d'une lancement d'un Vm nous administrateurs nous sommes libre de choisir sur quel serveur physique et donc à fortiori le moins chargé.
-> si le serveurs physique sur le quel se trouve la vm est surchargé celel ci migre automatiquement vers un serveur moins chargé
Avantage au niveau d'une entreprise possédant une dizaine de serveurs : -> résistance au panne (pouquoi?)-> economie de surface au sol (c a d?)
-> economie de climatisation
-> économie d'électricité
-> rapidité d'installation du nouveau système

Incovénient : -> les serveurs d'une dizaine d'année ne pourront pas s'adpater au nouveau systeme et seront donc à remplacer par de nouveaux serveurs.
-> délocaliser le parc chez un héberger (ce n'est pas vraiment un inconvenient puisque pa suen obligation, mais je doute que bcp d'entreprise accepte cela)
-> la normalisation des socles techniques et des procédures d'installation des systèmes
-> les outils et procédures de supervision et de prévision d'équipement ("capacity planning")
-> la remise à plat du Plan de Reprise d'Activité (PRA)

2) boitier de répartition de charge. Solution pas envisageable car inadapté à notre situation

3) boitier de répartition + virtualisation. Comment on met ca en place? Ou ou bien chez qui peut on trouver ce genre de solution est-ce adapté à notre situation malgré le boitier?

[wandazefish]

Une petite panne du modem, un câble télécom arraché (si, si, ça arrive souvent),un bug chez le fai, le prestataire, et c'est toute la boite qui est figée.

Allons, allons, "intranet", ça ne veut pas dire "dans mon bâtiment"! Les entreprises d'envergure nationale ont des serveurs intranet "nationaux" qui peuvent desservir des dizaines de sites géographiques. Quelle consolation, si le pépin touche justement le site national, que celui-ci soit "interne à l'entreprise" ?

Deux salles blanches distantes, avec alimentations secteur indépendantes, - secourues en plus par groupe électrogène -, avec 2 jonctions réseau différentes : c'est quand même plus sécurisant que des serveurs entassés dans le sous-sol d'un immeuble parisien (Rappel: inondable tous les 100 ans environ... )

Or quelle entreprise peut monter de A à Z, en interne, à un coût "raisonnable" , une telle architecture? la plupart, dont l'informatique n'est pas le métier, ne sauraient même pas par quel bout aborder le problème...

Pour l'hébergement externe, c'est une question de confiance avec le prestataire, de contrat, d'audit, d'assurances... sans parler des hébergeurs "externes" qui sont en fait une filiale de leur "client"... On peut très bien d'ailleurs externaliser l'hébergement et conserver en interne l'administration des systèmes!

L'externalisation de l'hébergement est aussi vertueuse parce qu'elle oblige à recenser le parc, normaliser la production, formaliser les contrats de service, limiter les accès physiques aux machines...

[wandazefish]

Avantage : -> lors d'une lancement d'un Vm nous administrateurs nous sommes libres de choisir sur quel serveur physique et donc à fortiori le moins chargé.

Oui. On peut aussi déléguer ce choix à l'hyperviseur.

-> résistance au panne (pourquoi?)

Cluster: les VM sont stockées sur un système de fichier partagé entre les machines physiques (datastore sur SAN) . Si une machine physique tombe en panne, on peut donc relancer les VM qu'il hébergeait sur d'autres machines physiques. On peut même automatiser cette relance en la déléguant à l'hyperviseur (attention aux reprises si des travaux batchs ont été interrompus) (attention de ne pas laisser le cluster se dégrader en ignorant les pannes )

-> economie de surface au sol (c a d?)

Tout simple: à une certaine échelle, moins de serveurs ça veut dire moins de m² en salle blanche et ces m² coûtent cher.

Inconvénients

Attention: plutôt que d'inconvénients, il s'agit d'investissements qui s'avéreront souhaitables ou nécessaires quand le projet de virtualisation avancera. Autant les envisager dès le départ, le Directeur Informatique (et le Directeur Financier) auront horreur de les découvrir au fil du temps! C'est pourquoi - j'insiste - la virtualisation de 10 serveurs de production est un choix stratégique, et non une solution technique.

-> les serveurs d'une dizaine d'années ne pourront pas s'adapter au nouveau systeme et seront donc à remplacer par de nouveaux serveurs.

Les serveurs récents aussi, s'ils sont hétéroclites!

-> délocaliser le parc chez un hébergeur (mais je doute que bcp d'entreprises acceptent cela)

Détrompe-toi! (voir post précédent). L'hébergement "maison" est à première vue économique mais c'est une activité ingrate... et risquée. Et c'est justement quand les applications sont vitales qu'il montre ses limites. Certes, je suppose que la NSA résiste à un hébergement externe, mais AMHA toutes les grandes banques, par exemple, y ont plus ou moins succombé...

2) boitier de répartition de charge. Solution pas envisageable car inadapté à notre situation

3) boitier de répartition + virtualisation. Comment on met ca en place? Ou ou bien chez qui peut on trouver ce genre de solution est-ce adapté à notre situation malgré le boitier?

Virtualisés ou non, les systèmes communiquent par TCP/IP donc les flux de VM à VM, ou de VM à système "physique", peuvent passer par les équipements réseau habituels (routeurs, répartiteurs de charge...). S'il y a une différence, c'est peut-être que la virtualisation fait un usage généralisé des VLAN.
Je ne connais pas suffisamment votre situation pour me prononcer davantage...

Dans tous les cas, il faut prendre en compte les coûts des étapes préalables de maquettage et de recette: on n'attaque jamais ces changements d'architecture par une mise en production directe!
D'ailleurs, on n'aborde jamais la virtualisation par une mise en production: on commence d'abord par virtualiser les environnements amont (développement, recette) pour se familiariser avec l'outil.
Enfin, s'agissant de répartition de charge, la recette devrait impliquer un injecteur de charge avec création d'un jeu d'essai non seulement significatif, mais si possible exhaustif (c'est toujours la "petite" transaction oubliée qui va poser problème: par exemple, l'authentification en début de session... )

Pour résumer: un projet intéressant, et ambitieux!

[invite5420aad7]

Bonjour,
quand je vais sur wikipedia et que je tape cluster il me dit que c'est le regroupement machines physique pour en faciliter la gestion globale et donc qu'entre autre ca permet de faire de la répartition de charge.
Est-ce qu'avec cluster simple sans combiner avec la virtualisation on pourrait pas répondre à mon prolème? Je dis ca parce que nos serveur travaille avec l'OS windows 2003 32 bits et que la plupart des logiciels comme proxmox en sont compatible qu'avec des architecture 64 bits.

[wandazefish]

Bonjour,

Est-ce qu'avec cluster simple sans combiner avec la virtualisation on pourrait pas répondre à mon prolème?

Si, bien sûr, enfin, si on admet que le mot "simple" peut s'appliquer à un cluster! Au lieu d'un cluster de virtualisation, on peut en effet opter pour une mise en cluster application par application. Par exemple, pour équilibrer la charge d'un serveur SGBD Oracle ou SQL Server surchargé, on peut la répartir entre 2 instances travaillant en cluster, situées sur 2 serveurs physiques différents. Ca peut être une solution opportuniste, - spécifique à une application, parce que son SGBD le permet - alors que le cluster de virtualisation propose une architecture générique: résistance aux pannes + répartition de charge, même si l'application n'a pas été conçue avec ces objectifs.

Je dis ca parce que nos serveur travaille avec l'OS windows 2003 32 bits et que la plupart des logiciels comme proxmox en sont compatible qu'avec des architecture 64 bits.

Connais rien de proxmox - mais si c'est un hyperviseur 64 bits de la même classe que ESX, il doit pouvoir héberger sans problème des VM 32 bits...

[invite5420aad7]

Bonjour,

Bonjour,
Si, bien sûr, enfin, si on admet que le mot "simple" peut s'appliquer à un cluster! Au lieu d'un cluster de virtualisation, on peut en effet opter pour une mise en cluster application par application. Par exemple, pour équilibrer la charge d'un serveur SGBD Oracle ou SQL Server surchargé, on peut la répartir entre 2 instances travaillant en cluster, situées sur 2 serveurs physiques différents. Ca peut être une solution opportuniste, - spécifique à une application, parce que son SGBD le permet - alors que le cluster de virtualisation propose une architecture générique: résistance aux pannes + répartition de charge, même si l'application n'a pas été conçue avec ces objectifs.

APplication par application? non je crois que la virtualisation c'est mieux lol.

Connais rien de proxmox - mais si c'est un hyperviseur 64 bits de la même classe que ESX, il doit pouvoir héberger sans problème des VM 32 bits...

Oui mais finalement l'hyperviseur 64 bits je doute qu'il s'installe sur notre OS 32 bit c'est là tout le problème de la virtualisation pour mon problème. Maintenant à cela s'ajoute le problème d l'architecture. Il faut docn que ej toruve des Hyperviseurs 32bits, mais je ne sais pas si ca existe en tout cas pour l'instant j'en ai pas vu.

[wandazefish]

Oui mais finalement l'hyperviseur 64 bits je doute qu'il s'installe sur notre OS 32 bit c'est là tout le problème de la virtualisation pour mon problème. Maintenant à cela s'ajoute le problème d l'architecture. Il faut docn que ej toruve des Hyperviseurs 32bits, mais je ne sais pas si ca existe en tout cas pour l'instant j'en ai pas vu

Ah, c'était donc ça! En fait, les hyperviseurs bare-metal (ESX, et proxmox!) s'installent directement sur la machine, à la place du système d'exploitation. Voilà comment ça se passe:
- sur une machine vide, on installe l'hyperviseur
- une conversion plus ou moins magique (P2V - voir plus haut) va construire une image virtuelle (VM) du serveur physique. Cette VM est stockée sur un système de fichier (datastore) accessible par l'hyperviseur (en général, espace de stockage SAN).
- on lance la VM, "par-dessus" l'hyperviseur et sous son contrôle, et si tout marche bien, on peut recycler le serveur physique initial - en installant dessus un 2ème hyperviseur, et en l'intégrant au cluster de virtualisation.

Au passage, la qualité du logiciel de conversion P2V est aussi à prendre en compte: s'il est défaillant, il faudra ré-installer un système neuf sur une VM vide, ré-installer dessus les applications et transférer les données...

Donc un hyperviseur 64 bits bare-metal peut héberger des systèmes 32 bits (CQFD)

non je crois que la virtualisation c'est mieux

Certes, certes. Mais c'est aussi plus cher et beaucoup plus ambitieux. En fait, comme tu le découvres, c'est simple sur le papier, mais les "à côté" sont nombreux, et dans la vraie vie on ne peut pas les négliger...

[invite5420aad7]

bonjour,

Encore désolée d'être lente à la détente.

En fait, les hyperviseurs bare-metal (ESX, et proxmox!) s'installent directement sur la machine, à la place du système d'exploitation. Voilà comment ça se passe:
- sur une machine vide, on installe l'hyperviseur

Sur une machine vide? Si mes machines ne sont pas vide par vide moi j'entend rien d'installer dessus. Comment je fais j'installe le tout par dessus? Ou il faut acheter expres une machine (bon là j'avoue que ca m'étonnerait la question est un peu bête).
En fait je ne vois pas trop trop trop le truc supposons que j'achete mon logiciel de virtualisation. Supposons aussi que je règle le problème de machien vide, j'en trouve donc une. Moi par machien j'entend serveur. Docn j'instalel mon logiciel sur mon serveur vide après comment je fais pour relier les serveurs entre eux? Le logiciel va les détecter tout seul?
Désolée si mes question sont limites c'est la première fois que je travail l'informatique dans le secteur réseau, j'ai plutot l'habitude moi de la programmation, cela dit j'apprend beaucoup de chose donc ca m'interesse bcp.

[wandazefish]

Sur une machine vide?

OUI. C'est incontournable, pour amorcer le processus il faut une 1ère machine libre, sur laquelle on installe le 1er hyperviseur. A ce stade du projet, ce n'est pas grave: tu en es encore à élaborer des scénarios grossiers, pas trop irréalistes quand-même dans le cadre de l'entreprise. Ensuite un comité de validation - ou plus simplement: le Chef!) te dira les directions à explorer ou à exclure. De toute façon: pas de ressources, pas de projet - tes interlocuteurs en sont normalement bien conscients! Les modalités de mise en production sont encore loin...

après comment je fais pour relier les serveurs entre eux? Le logiciel va les détecter tout seul?

Excellente question, donc tu n'es pas si lente! Il faut prévoir 2 types de flux réseau: les flux applicatifs classiques, et les nouveaux flux nécessaires au fonctionnement du cluster. La virtualisation permet de mutualiser les interfaces réseau, sans que les flux soient pour autant "mélangés" (isolation logique par VLAN) . Les flux passent par l'infrastructure réseau classique de l'entreprise (switch, routeurs, boîtiers répartiteurs...) mais, ne nous leurrons pas, il va falloir remettre à plat cette infrastructure...

c'est la première fois que je travail l'informatique dans le secteur réseau

Là, tu es au delà du réseau: tu définis une infra-structure de production complète, et pour un stagiaire c'est pour le moins ambitieux! Normal que tu patauges un peu...

Mais il ne faut pas se perdre dans les détails pratiques: tu agis au stade de l'avant-projet, et je ne sais pas si tu iras beaucoup plus loin dans le cadre de ton stage! A ce stade tu t'occupes des schémas d'architecture, pas des modalités de mise en oeuvre. C'est déjà beaucoup!

[wandazefish]

Question bête: as-tu déjà fait l'étude de l'existant?

- pour chaque serveur:
. domaine d'utilisation (développement, recette, production...)
. clients desservis (internet, intranet, extranet...)
. contrats de service (plages de fonctionnement, objectif de disponibilité, délai de redémarrage...)
. type de serveur (LAMP,décisionnel, messagerie, sauvegarde, bureautique...)
. OS, progiciels, logiciels (Apache, Oracle, MySQL, SQL Server, WAS, Tomcat...)
. configuration physique (processeurs, mémoire, stockage, interfaces réseau...)
. courbe de charge heure par heure (pour le serveur complet, pour chaque logiciel...)

- schéma d'ensemble du réseau, des infrastructures de stockage...

Du concret bien solide, pour appréhender le contexte dans son ensemble, avant de chercher à le modifier!

[invite5420aad7]

Question bête: as-tu déjà fait l'étude de l'existant?

- pour chaque serveur:
. domaine d'utilisation (développement, recette, production...)
. clients desservis (internet, intranet, extranet...)
. contrats de service (plages de fonctionnement, objectif de disponibilité, délai de redémarrage...)
. type de serveur (LAMP,décisionnel, messagerie, sauvegarde, bureautique...)
. OS, progiciels, logiciels (Apache, Oracle, MySQL, SQL Server, WAS, Tomcat...)
. configuration physique (processeurs, mémoire, stockage, interfaces réseau...)
. courbe de charge heure par heure (pour le serveur complet, pour chaque logiciel...)

- schéma d'ensemble du réseau, des infrastructures de stockage...

Du concret bien solide, pour appréhender le contexte dans son ensemble, avant de chercher à le modifier!

Lol,
alors j'explique bon quand je suis arrivée en stage mon tuteur m'a dit voilà le problème on a des serveurs qui sont utilisé à seulement 30% de leurs ressources en moyenen on voudrait exploiter les 70% restant, on a par exemple le serveur des archives qui a utilisé 90% de ses ressources et celui des mails 15%. On voudrait pouvoir exploiter les ressources du serveurs mail pour les serveurs qui en ont besoin quand ils en on besoin. Trouve moi un outil qui pourrait répondre à ce problème.
Voilà, lol et entre temps j'ai appris comment on peut simuler ça à l'aide de la virtualisation et aussi des cluster d'application quoique moi je cherche actuellement un logiciel qui me fait automatiquement les cluster d'application.
Sinon je ne comprend pas pourquoi si je trouve un logiciel de virtualisation compatible avec une configuration Windows server 2003 32biits pourquoi je ne pourrait pas juste l'installer? Ou directement utiliser le logiciel de clustering?
Aussi un tuc est-ce que tout le long de mon stage vous pourrez être disponible pour répondre à mes questions?
Au mieux moi je peux faire un rapport en disant qu'avant d'utiliser un logiciel de virtualisation il faut fair eune etude de l'existant qui se fait comme ceci, comme celà. Non? Après sans doute mon tuteur me montrera comment on procède ou j'inonderai sle forum de mes questions LOL

[wandazefish]

mon tuteur m'a dit voilà le problème on a des serveurs qui sont utilisé à seulement 30% de leurs ressources en moyenen on voudrait exploiter les 70% restant, on a par exemple le serveur des archives qui a utilisé 90% de ses ressources et celui des mails 15%. On voudrait pouvoir exploiter les ressources du serveurs mail pour les serveurs qui en ont besoin quand ils en on besoin. Trouve moi un outil qui pourrait répondre à ce problème.

C'est un peu succinct mais au départ il ne sait pas trop ce qu'il peut te demander, et il a sûrement un tas de trucs à faire... Et ça te laisse quand-même une certaine latitude pour mener ton stage.

AMHA, en gros:
- il n'y aura pas d'outil miracle - enfin, je n'en connais pas. La solution la plus généraliste est bien la virtualisation, - avec, dans un environnement de production, la lourdeur, les coûts, les "à côté" et les risques qui en découlent.
- 30% de charge en moyenne, c'est déjà beaucoup sur du x86: c'est plus probablement 30% de charge en moyenne en heure de pointe. Même là, c'est déjà un parc qui n'est pas si surdimensionné - on a vu bien pire - ce qui va encore limiter l'intérêt de la solution. D'où l'intérêt de demander les statistiques pour voir dans quelle mesure les courbes de charge se complètent (cas favorable) ou se superposent (cas défavorable).
- il est bien trop tôt pour proposer des scenarios - tant pis, je me lance, à titre d'exemple.

Scenario 1 - le plus raisonnable, le moins coûteux:
- s'il y a dans le lot des machines dédiées aux développements/recette, on les consolide sur un seul serveur de virtualisation ESXi ou proxmox (que je ne connais pas). Gratuit et simple (pas de cluster).
- les machines libérées sont réutilisées: pour de nouvelles applications, pour monter un prototype de cluster ESX, pour le backup...
- on ne touche pas à l'architecture de production: si le serveur d'archivage sature, on le booste.

Scénario 2 - variante du scénario 1 - on cherche à soulager le serveur d'archivage
- on regarde si le logiciel d'archivage propose lui-même une solution de répartition de charge
- est-il possible de séparer le SGBD qui supporte le référentiel d'archivage? si oui, on le transfére vers une machine moins chargée (architecture n-tier)

Scenario 3 - plusieurs mois plus tard: on commence à bien maîtriser la virtualisation.
- le prototype du cluster ESX a permis de faire la recette d'une application en environnement virtualisé, et tout se passe bien: on passe en production cette 1ère application...

Scenario 4 - plusieurs mois plus tard
- toutes les applications sont virtualisées - y compris le SGBD du référentiel d'archivage...
- ...à l'exception du moteur d'archivage proprement dit, qui est un mauvais client (trop d'entrées/sorties, périphériques spécifiques...)

Ca, c'était juste pour montrer un exemple d'évolution à peu près réaliste - dans un environnement très "virtuel" , puisqu'il n'y a pas d'étude de l'existant...
- pas d'outil/solution miracle: un ensemble de techniques, que les professionnels (architecte technique, chef de projet production, administrateurs) mettent en oeuvre à bon escient
- grande prudence avec l'environnement de production: en particulier, pas de virtualisation immédiate (pour ne pas dire "intempestive" )

Bon, là, je t'ai un peu saoûlé, et on s'est peut-être éloigné de ce qui doit rester ta préoccupation: dans le cadre de la demande initiale, mener au mieux ton stage, dans ton intérêt et celui de ton "client"... j'y reviendrai dans un prochain post - au risque de te saouler à nouveau ...

Sinon je ne comprend pas pourquoi si je trouve un logiciel de virtualisation compatible avec une configuration Windows server 2003 32biits pourquoi je ne pourrait pas juste l'installer?

Je suppose que tu fais référence à des logiciels comme VMware Server ou VMware Workstation par exemple. En effet, ça s'installe sur un serveur Windows ou Linux existant (tiens? pourquoi pas sur ton micro personnel? VMware Server est gratuit, - il y en a d'autres - que je ne pratique pas, et qui sont pas mal non plus). On peut les utiliser pour le développement ou le maquettage applicatif, mais jamais en production (fiabilité, surconsommation) - ni même pour le maquettage d'architecture technique (trop limité, trop loin du matériel).
Si je me réfère à http://fr.wikipedia.org/wiki/Virtualisation : pour la production - et la répartition de charge! - , c'est forcémént "hyperviseur de type I" , jamais "hyperviseur de type II".

Ou directement utiliser le logiciel de clustering?

Le cluster de virtualisation repose tout entier sur le partage entre plusieurs ESX (ou équivalent) d'un FS spécifique, et la sérialisation SCSI. Ca suppose un sérieux remaniement de l'architecture technique. Les autres solutions de clustering sont spécifiques...

[invite5420aad7]

Non, non tu ne me saoule pas du tout, mais je vais prendre le temps d'ingurgiter tout tes conseils.
Lol.

[polo974]

Finalement, il faut bien avouer une chose:
la virtualisation permet de regrouper des applis (avec leurs systèmes sous-jacents) sur une machine, ce qui est le contraire du clustering qui permet de répartir une appli sur plusieurs machines (ce qui est plus compliqué...) ...

C'est donc un mix savant des 2 qui va permettre d'optimiser l'existant.
(je regroupe 3 applis sur une virtualisation, et du coup je dispose de matériel pour "étaler" l'appli sur plusieurs machines récupérées (avec éventuellement mise en place de virtualisation pour simplifier le déplacement sur d'autres lors d'un renouvellement du matériel).

Pour le serveur d'archivage qui semble être le gros problème, il serait peut-être juste possible de scinder les données en 2 groupes bien distincts, et de monter un second serveur d'archivage pour soulager le premier. C'est pas top, c'est même un peu bricolo, mais c'est une solution court terme s'il y a un danger imminent de saturation.

Revenons à la virtualisation: si le matériel n'est pas appelé à être remplacé, il est tout de même important de vérifier si le(s) processeur(s) des machines choisies disposent du support de virtualisation...

[invite5420aad7]

Bonjour,

donc, si j'ai bien compris même la virtualisation en permet pas de résoudre le problème du serveur d'archivage.
Mais je ne comprend pas pourquoi? Pourquoi our lui on ne toruve aps de solution?

[invite5420aad7]

VMware Server est gratuit, - il y en a d'autres - que je ne pratique pas, et qui sont pas mal non plus). On peut les utiliser pour le développement ou le maquettage applicatif, mais jamais en production (fiabilité, surconsommation) - ni même pour le maquettage d'architecture technique (trop limité, trop loin du matériel)....

Quelle est la difference ?

Si je me réfère à http://fr.wikipedia.org/wiki/Virtualisation : pour la production - et la répartition de charge! - , c'est forcémént "hyperviseur de type I" , jamais "hyperviseur de type II".

J'avais vu au début de mes recherches qu'il y avait deux types d'hyperviseurs. Mais moi quand j'ai fait des recheches je n'ai plus trop regarder ca, si on me dit qu'un hyperviseur de type 2 résoud mon problème de répartition des charges comment je peux dire que ce n'est pas le bon outil?

[polo974]

Bonjour,

donc, si j'ai bien compris même la virtualisation en permet pas de résoudre le problème du serveur d'archivage.
Mais je ne comprend pas pourquoi? Pourquoi pour lui on ne trouve pas de solution?

La virtualisation te permet de mettre plusieurs systèmes sur une machine, mais toi tu veux répartir une appli sur plusieurs machines.

Il faut donc découper fonctionnellement l'appli, ou la dupliquer pour différentes "familles" de données, ou enfin (tadahhh le mot magique...) clusteriser (ouille le porte monnaie)...

Il faudra peut-être changer d'appli d'archivage (façon polie de ne pas dire sûrement...).

[invite5420aad7]

La virtualisation te permet de mettre plusieurs systèmes sur une machine, mais toi tu veux répartir une appli sur plusieurs machines.

Il faut donc découper fonctionnellement l'appli, ou la dupliquer pour différentes "familles" de données, ou enfin (tadahhh le mot magique...) clusteriser (ouille le porte monnaie)...

Il faudra peut-être changer d'appli d'archivage (façon polie de ne pas dire sûrement...).

Lol ok merci de m'avoir bien résumer le truc.