Hébergement multiple sur machine physique ou virtualisation ?

Bonjour @ tous,

Je fais connaissance avec la virtualisation et j'ai beaucoup de mal à comprendre la philosophie, merci par avance pour vos lumières et milles excuses pour mes question de débutant.
Je vous précise que ma réflexion s'inscrit dans une démarche semi-professionnelle (une très grosse famille ayant des besoins de services pro). Pour faire simple il s'agit d'élaborer un réseau qui est aujourd'hui inexistant, donc partir de rien.

Voila ce qui me tracasse :

Qu'est ce qui est le plus judicieux, avoir un serveur physique faisant tourner un OS sur lequel est installé plusieurs services réseau ou un serveur physique hébergeant autant de machines virtuelles que de services réseau ?
Est ce que, dans les 2 cas la configuration de la machine physique serait la même ? bi processur ou mono processeur ? comment choisir les composants ?

J'entends par services réseau :
1 machine pour : serveur Email, serveur squeezebox, serveur FTP, web, BDD (mariaDB), bittorent.
1 machine pour : routeur, serveur VPN, DNS, proxy, DHCP

Merci @ tous.
Christophe

Avant de parler virtualisation, réfléchissons à l'infrastructure.

Il faut isoler les services d’une part par sécurité, et d'autre part en cas de panne.

Par rapport aux services souhaitées, je ferais cela :

1 machine : routeur, dhcp, proxy, dns, vpn
1 machine mails
1 machine bittorrent
1 machine web
1 squeezebox, ceci semblant être un appareil clé en main, ce sera une machine physique.

Solution modulable.

L’intérêt de la virtualisation est de pouvoir isoler les services semi-matériellement. Un autre intérêt est qu'une VM est déplaçable vers une autre machine physique, cela permet une évolution plus simple. (remplacement de serveur, répartition des serveurs virtualisés sur plusieurs hôtes).

Il est possible de cumuler plusieurs types de virtualisation, la virtualisation d'un OS sur un hôte équipé d'un hyperviseur (VMWare ou Hyper-V par exemple), cumulé à de la virtualisation d'application, les services/applications sont isolés les unes des autres dans le même OS, exemple serveur web et de bdd sur la même VM. On parle alors de conteneurs (ex : Docker, lxc, OpenVZ).

L'hôte doit être dimensionné selon le nombre de VM qu'il va héberger et selon la charge des services. En théorie, si tu as 2 OS demandant 4 go de RAM, il te faut au minimum 9 Go, 4 par VM et 1 pour l'hôte (1 Go est exagéré mais c’est pour montrer qu'il faut laisser de la RAM à l'hôte). Mais si tu sais qu'une des deux VM va être plus sollicitée que l'autre, tu peux très bien attribuer 2 Go à l'une et 6 Go à l'autre. Et surtout, ce n'est pas figé dans le temps, tu peux changer ses réglages quand tu le souhaites. Rajouter de l'espace disque est également plus simple matériellement, mais nécessite des étapes supplémentaires. Tu ajoutes un disque sur l'hôte, et tu agrandi les images disques des VM (ou tu les déplaces d'un disque à l'autre), puis enfin les Filesystem des VM.

La partie virtualisation pompe un peu de ressources et rajoute une couche de complexité. Pour 2 services par exemple, il peut être plus judicieux d'avoir 2 petites machines plutôt qu'un gros serveur. A cout équivalent, si une carte mère crame par exemple , sur un hôte, toutes les VM sont HS sans virtualisation : 1 machine HS=1 service HS, l'autre restant opérationnel, et la machine pouvant accueillir temporairement l'autre service.

Tu as 4-5 VM. L'idéal serait de les répartir sur 2 hôtes en ayant pour idée qu'en cas de panne, la machine accueillera provisoirement toutes les VM avec perfs dégradées. Mais 4-5 VM, peuvent tenir sur un seul hôte.

Pour dimensionner correctement tout cela, c'est une question de budget et de besoins

Bonjour chrstophe,

Je te remercie pour ton aide.

A la lecture de ta réponse, qui m'a déjà beaucoup appris, je vais commencé par reformuler de manière à m'assurer d'avoir bien compris tes propos.

Corrige moi si je me trompe, "Docker" est un procédé qui permet de faire tourner plusieurs applications sur une même machine mais chacune d'elle est parfaitement étanche aux autres. De cette manière si l'une d'elle devenait instable elle pourrait planter sans porter préjudice au fonctionnement de la machine et aux autres applications.

Q : Du coup, voila une première question qui pointe le bout de son nez : quels sont les critères permettant de choisir entre la virtualisation d'OS et la technique de containérisation ?


A la lumière de tes recommandations, concernant la répartition et l'organisation, j'ai revu ma copie et je l'ai complétée car je me suis aperçu que j'avais omis des points qui me paraissaient de prime abord négligeables.

voici donc à quoi ressemble mon besoin à présent :

1 machine "sécurité" : PfSence ; services déployés : routeur, proxy, firewall, serveur VPN, DNS, DHCP, procéder d'authentification d'ouverture de session, annuaire
1 machine NAS : FreeNas ; services déployés : NAS, serveur FTP, bittorent, owncloud, service de MAJ en local des OS et applications présents sur le réseau,service de sauvegarde des machines du réseau
1 machine "multi service" : services déployés: mail, squeezebox serveur (logiciel), web, BDD
1 machine "domotique" ; JeeDom : serveur domotique Jeedom et serveur MQTT

Il me parait plus logique de regrouper les services par catégorie, tout ce qui touche à la manipulation de fichier est sur le NAS, tout ce qui touche à la sécurité est sur la machine sécurité, la gestion domotique est ensemble et enfin reste la machine "multi services" qui hébergera les autres services, au service des utilisateur et des autres machines.

Q : J'ai lu que le serveur Mail devrait être mis dans une DMZ qu'en pense tu ? car sur le net les avis sont partagés.

Pour limiter le nombre de machines et la consommation électrique, j'hésite à intégrer la partie domotique sur la machine "multi service".

Q : Que pense tu de cette organisation ? Il me semble que chaque terme "machine" est en fait une machine physique qui hébergerait autant de VM que de services. Sauf pour ce qui est du NAS FreeNas et de la machine Pfsence qui disposent directement de pluggins et autres addon à installer. Mais pour les autres machines parlons nous de virtualisation d'OS ou de containérisation ?
Q : Dans cette configuration, comment choisir correctement la config de chaque machine ?

Q : Quelle technique de virtualisation conviendrait il le mieux ? j'utilise de temps en temps pour des essaies et pour le fun VirtualBox, mais j'imagine que pour ce projet il doit exister des solutions bien plus adaptées.
Q : certain NAS ont une mention du genre "pret pour la virtualisation" ou "vmware ready" ou "citrix ready". Cela signifie certainement que le NAS est optimisé pour l'utilisation de la virtualisation. Mais il fait quoi de plus ? ça apporte quoi de plus ?

Q : Tu me dis qu'il est possible de cumuler la virtualisation et la containérisation, dans quel cas on peut être amené a mettre en place ce genre de montage ?

D'autre part, comme tu peux le voir sur cette organisation, il est difficilement acceptable qu'une des machines tombe en panne car c'est alors tout le réseau local. En effet, la machine domotique a besoin de la BDD ainsi que du serveur web pour fonctionner. De plus sans serveur domotique, plus d’électricité ! sans la machine ""sécu" plus de réseau local et plus d’accès internet.
Donc comme tu l'a rapidement évoqué, il serait bon de prévoir un mode dégradé, au moins en attendant l'intervention curative !

Q : Quelles sont les techniques permettant de palier à la défaillance d'une machine ?

Merci par avance pour ton aide.
Christophe

Citation:

---

Q : Du coup, voila une première question qui pointe le bout de son nez : quels sont les critères permettant de choisir entre la virtualisation d'OS et la technique de containérisation ?

---

La virtualisation d'OS est plus lourde et demande en ressource de l'affectation de RAM, d'espace disque pouvant contenir l'OS plus logiciels/services, données. la contenairisation c'est plus léger mais offre un cloisonnement moindre.

Citation:

---

Q : J'ai lu que le serveur Mail devrait être mis dans une DMZ qu'en pense tu ?

---

Le principe d'une DMZ, c'est que les machines dedans sont isolés du LAN. Les règles du Firewall ne sont pas les même pour les dialogues entre la DMZ et le NET et la DMZ et le LAN.

Citation:

---

Q : Quelle technique de virtualisation conviendrait il le mieux ? j'utilise de temps en temps pour des essaies et pour le fun VirtualBox, mais j'imagine que pour ce projet il doit exister des solutions bien plus adaptées.

---

Un hyperviseur baremetal tel que ESX. Un NAS marqué virtualisation Ready signifie qu'il peut servir de volume de stockage comme une baie de disque pour un hyperviseur.

Citation:

---

Q : Que pense tu de cette organisation ?

---

PFSense n'utilise pas de containers pour isoler ses pluigns à ce que je saches.

Citation:

---

Q : Quelles sont les techniques permettant de palier à la défaillance d'une machine ?

---

- DRBD/Heartbeat : DRBD est en gros du RAID 1 over IP entre deux machines, heartbeat pouvant être traduit par prise de pouds est un système permettant de surveiller qu'une machine fonctionne et de transférer les services dessus en cas de défaillance
- en virtualisation : synchronisation de VM entre serveurs avec des produits tels que Double take Move platespin
- systèmes de répartition de charge à tolérance de panne : utilisation base de données/filesystem distribués avec DNS tournant
Il doit y en avoir d'autres.

Vu le cout de tout ça, ce n'est adapté qu'aux structures conséquentes.

Je te remercie pour ton aide grâce à toi j'ai pas mal bossé et encore beaucoup appris pour intégrer toutes ces nouvelles notions.


Ce qui me préoccupe pour mon projet c'est la consommation électrique de l'ensemble ainsi que la place à prévoir pour l'installation du matériel. Pour l'instant je ne parle pas de budget.....

Q : J'ai une première question pour ce qui est de DRBD : n'est-il pas possible d'utiliser tout simplement un disque local et un disque iSCSI en RAID 1 ? Cela ne reviendrait il pas au même ? les 2 disques seraient alors rigoureusement identique puisque c'est le propre du RAID 1 ?

Q : J'avais effectivement pensé à cela car que pense tu de l'organisation suivante ? peux tu me dire si c'est faisable ?

1 machine physique pour le NAS/SAN
1 machine physique pour la sécurité

1 machine physique musclée hébergeant un hyperviseur baremetal comme Proxmox VE (libre) sur lequel il y aurait 1 disque en local dédié pour héberger autant de VM que de serveurs/services souhaités. Chaque disque VM local serait en RAID 1 sur le SAN en iSCSI.

1 machine physique de "secours" "Promox VE dégradé" permettant la continuité des services, en mode performances dégradées, dans le cas d'une ou plusieurs défaillances des VM précédents voire l'arrêt complet de la machine Promox VE musclé. Cette continuité serait obtenue en "récupérant" l'accès des disques iSCSI sur le SAN par "Proxmox dégradé"

Le cas critique serait que le NAS/SAN tombe en même temps que la machine "Proxmox musclé", car le "Proxmox dégradé" ne serait alors plus en mesure d'assurer une continuité car dans l'impossibilité de se connecter aux disques iSCSI qui se trouvent sur le SAN/NAS

Q : Pour ce qui est du matériel, dis moi ce que tu pense de ma vision des config qui pourraient ressembler à quelque chose du genre :

Machine "Proxmox VE musclé" : une carte mère serveur bi processeur intel avec une 30aine de Go de mémoire, 1 carte réseau Gigabit dédiée pour iSCSI, 1 carte réseau Gigabit réseau, disque dur
Machine "Proxmox VE dégradé" : une carte mère serveur intel mono processeur, 1 carte réseau dédié iSCSI, 1 carte réseau, 1 petit disque dur.

Bon naturellement, si mon "idée" de faire du RAID 1 en local - iSCSI SAN n'est pas possible, je mettrai alors en place la solution de DRBD, dans cette même organisation.
A moins que la solution de faire de la virtualisation de serveurs sur des disques local et iSCSI soit "problématique" ou technologiquement juste impossible ("partage" d'un disque iSCSI entre "Proxmox musclé" et "Proxmox dégradé" impossible). Du coup j'ai plus qu'a me remettre à cogiter !

Citation:

---

: J'ai une première question pour ce qui est de DRBD : n'est-il pas possible d'utiliser tout simplement un disque local et un disque iSCSI en RAID 1 ?

---

DRBD doit être instalél et paramétré entre 2 OS. Il travaille au niveau bloc mais se fout du type de disque. Un NAS peut éventuellement embarquer DRBD mais c'est plutôt adapté entre 2 machines physiques.

Citation:

---

1 machine physique musclée hébergeant un hyperviseur baremetal comme Proxmox VE (libre) sur lequel il y aurait 1 disque en local dédié pour héberger autant de VM que de serveurs/services souhaités. Chaque disque VM local serait en RAID 1 sur le SAN en iSCSI.

---

Avoir des images disques sur un SAN peut provoquer un goulot d'étranglement, je préfererais des disques locaux.

Citation:

---

Le cas critique serait que le NAS/SAN tombe en même temps que la machine "Proxmox musclé", car le "Proxmox dégradé" ne serait alors plus en mesure d'assurer une continuité car dans l'impossibilité de se connecter aux disques iSCSI qui se trouvent sur le SAN/NAS

---

d’où aussi ma préférence pour des disques locaux.

Code:

---

Bon naturellement, si mon "idée" de faire du RAID 1 en local - iSCSI SAN n'est pas possible, je mettrai alors en place la solution de DRBD, dans cette même organisation.

---

grosso-modo soit tu fais du DRBD entre 2 machines, soit tu gères le RAID au niveau SAN.

Le RAID (géré par DBRD ou autre chose) ne te protégeras pas d'un effacement de données. Il faut gérer les sauvegardes, d’où l'utilité d'envisager des réplications de VM entre serveur avec sauvegardes par snapshot.

Q : Peux tu me confirmer qu'il est possible d'utiliser le iSCSI comme je le pense ?

A savoir, obtenir une image strictement identique de chacun des disques virtuels utilisé par chacune des machines virtuelles en leur attachant un disque en RAID 1 sur le SAN avec le protocole iSCSI. Chaque machine virtuelle possède donc un disque virtuel sur le disque physique du serveur ou se trouve trouve l hyperviseur et un autre disque en RAID 1 sur le SAN. De cette manière, il n y a pas de risque de goulot d'étranglement car les disques en iSCSI en RAID 1 ne sont là que pour le serveur de secours dans le cas ou il devrait assurer la continuité d'une ou plusieurs VM.

Pour la redondance des disques, je préférerais utilisé le RAID 1 plutôt que DRBD puisque la finalité est la même, créer une copie conforme d'un disque. Les 2 font la même chose et cela éviterait une une "couche" supplémentaire, pourquoi faire compliqué...

J'ai donc besoin de savoir précisément si le protocole iSCSI permet effectivement à une machine de secours d’accéder un disque monté en RAID 1 d'une autre machine en cas de défaillance de celle ci. Je n'arrive pas à trouver sur internet une réponse claire et précise à cette préoccupation.

Désolé, je ne sais pas si je suis bien clair dans mes explications !

Si malgré tout il y avait un risque d'étranglement, je peux toujours doubler ou quadrupler les cartes réseau 1Gb ce qui me permettrait en plus de faire tout à la fois du load balancing, de l'agrégation et du bonding. Après j'ai aussi la possibilité d'utiliser des cartes réseau 10Gb Ethernet (naturellement avec un switch adéquat).

Q : Peux tu me donner également ton avis sur le genre de config auquel je pense et dont j'ai fais une description très succincte dans mon message précédent ?
Q : Comme je te l'ai indiqué dans mon précédent message, que pense tu de tout regrouper sur un serveur "musclé" pour toutes les VM et un monté un serveur "dégradé" pour le secours ?

Je prévois également de faire une simple copie de sauvegarde du SAN sur une machine NAS distant. Sait on jamais, si le SAN brûle, je ne perds pas mes données personnelles, copies des sauvegardes des ordinateurs du réseaux et les éléments de fonctionnement du réseau (disques iSCSI...) Du coup on peut aussi se poser la question : quitte à monter une machine pour faire un backup du SAN pourquoi ne pas prévoir directement un SAN de secours redondant avec le premier ? Mais dans ce cas faudrait il quand même prévoir une machine pour faire un backup des informations dupliqués sur les 2 SAN ? si oui, ça fait encore une machine de plus !...

Bien que tu m’aies beaucoup appris en quelques échanges je suis de plus en plus intéressé par la virtualisation, les possibilités, les procédés, les différentes techniques, la virtualisation de session - de poste de travail - d'applications, ce que cela apporte.....

Q : Peux tu me conseiller des ouvrages ou des "PDF" en français pour me permettre de progresser ?
Q : Quels logiciels me recommanderais tu pour me permettre de faire des "plans" de l'architecture de mon réseau, avec des icones ou symboles des éléments qui constituent habituellement un réseau informatique ?


merci

Le protocole ISCSI n'est que le protocole de communication. Pour l'utiliser, il faut que toutes les machines susceptibles de l'utiliser le gèrent. Ce n'est pas lui qui va s'occuper du RAID sur le volume de destination (du moins je pense, mais je peux me tromper).

Je ne l'est jamais utilisé, donc je peux pas trop te guider avec.

Par contre je ne pense pas que se soit fait pour faire du mirroring entre 1 disque physique local et un disque distant. C'est plutôt fait pour gérer l'accès concurrentiel de plusieurs machines vers un SAN.

Je pense que le mieux pour éliminer les goulots d'étranglement réseau est de stocker les données sur la machine, pas sur un SAN. Ca te coutera aussi moins cher. Un avis d'un utilisateur spécialiste de ce type d'infra serait un plus,mais Je pense que le SAN, c'est pour les grosses infra structures.

Citation:

---

Comme je te l'ai indiqué dans mon précédent message, que pense tu de tout regrouper sur un serveur "musclé" pour toutes les VM et un monté un serveur "dégradé" pour le secours ?

---

Moi j'aurais tendance à répartir les VM sur 2 serveurs moyens, en pouvant fonctionner sur un seul en mode dégradé (panne matérielle). On peut aussi les répartir en services sensibles, non sensibles.

Peut-être celui-là :
http://www.editions-eni.fr/livre/vir...-9782746050068
Mais je ne l'ai pas lu.
Lire les tutoriels ici me parait pas ml aussi :
http://virtualisation.developpez.com/cours/

Citation:

---

On peut aussi les répartir en services sensibles, non sensibles

---

C'est une nouvelle notion pour moi !

Peux tu m'en dire un peu plus la dessus ?

Si tu as un serveur de fichiers, c'est bien de l'isoler aux max d'un serveur exposé au net tel qu'un serveur mail. C'est plus un principe de précaution.

Tu ne m'as pas dit ce que tu pensais du genre de config que je t'ai donné pour mon serveur "Proxmox musclé" et le "Proxmox dégradé".

Est ce cohérent ? pas assez ? beaucoup trop ?

si j'ai répondu,

Plutôt que d'avoir un "gros" serveur et un "petit", je mettrais 2 moyens sur lesquels je répartirais les VM.

désolé je suis allé un peu vite.

Peux tu me m'aiguiller sur la config de ces 2 moyens serveurs ? qu'entends tu par moyen ? mono ou bi processeur ? mémoire ? combien de ports réseau ?

merci

Cela dépend de ton budget.

En fait pour l'instant le budget ne rentre pas en considération !!

Naturellement, il est tout de même inutile de partir sur quelque chose de très disproportionné.