VMWare

De Justine's wiki
Aller à la navigation Aller à la recherche

Création d'une VM (TP1)

Récupération de l'OVA

La première étape de l'installation de la VM consiste à récupérer le fichier .ova, depuis le datastore de la machine 172.20.20.201. Pour cela :

  1. Je me connecte à la machine 172.20.20.201.
  2. Je clique sur l'onglet "stockage" dans le menu de gauche
  3. Je déroule l'arborescence : Datacenter > Dossier > Etudiants
  4. Dans le menu central, je choisis l'onglet "Fichiers" puis le dossier "ISO"
  5. Je fais un clic droit sur le fichier (TTYLinux.ova) puis "Télécharger de la banque de données"
  6. Dans la pop-up qui s'ouvre, je rentre mes identifiants. Le téléchargement se lance.

Mise en place de la VM

Je vais ensuite créer la VM à proprement parler :

  1. Depuis le menu de gauche je choisis "Machines virtuelles"
  2. Créer / Enregistrer une machine virtuelle
  3. Déployer une machine à partir d'un fichier ovf
  4. Je clic sur la zone de téléchargement, et je choisis mon fichier.
  5. Je sélectionne le datastore 1
  6. Je laisse le provisionnement mince.
  7. Je créée la machine virtuelle.
  8. Attendre que la VM soit finie (voir les tâches en cours, en bas de l'écran).
  9. Elle démarre.

A quoi correspond le datastore 1?

Ce datastore correspond ici simplement au disque dur de l'ESXi. C'est un espace de stockage, pour des fichiers ou des VMs.

Configuration réseau

Je vais prendre la main sur la VM pour la configurer. Pour cela, je vais passer pas une console de navigateur (la console VMRC nécessite d'avoir un compte chez VMWare pour être téléchargée...).

  1. Sélectionner la VM > Action > Ouvrir une console de navigation (on peut changer le clavier en cliquant sur le petit drapeau).
  2. Je me loggue en root sur celle-ci.
  3. vi /etc/sysconfig/network-scripts/ifcfg-eth0
  4. Je saisis les informations, puis :wq
  5. Enfin, je fais ifdown eth0 suivi de ifup eth0
  6. Je peux désormais pinguer l'IP de mon PC (celle de que je récupère depuis le vpn, même si je pourrais pinguer ma box...)

RTENOTITLE

Modification de la VM.

BIOS

Nous allons accéder au bios de la VM pour désactiver le lecteur de disquettes. Pour cela :

  1. Toujours avec ma console ouverte, je reboote la VM (Actions > Réinitialiser)
  2. Je tapote la touche F2 au démarrage, j'arrive dans le BIOS.
  3. Depuis le menu "main", je peux aller sur "Legacy Diskette A" et le désactiver.
  4. Exit > Exit saving changes.
  5. La VM démarre normalement.

Que se passe-t'il dans le datastore?

Lorsque la VM est éteinte, dans le datastore, je n'ai que les fichiers de disque dur (vmdk), de bios (nvram), et de configuration( vmx).

Une fois la VM démarrée, d'autre fichiers apparaissent : le fichier de swap, des fichiers de lock (qui permettent de faire en sorte qu'un seul ESX ne contrôle la VM à la fois), des fichiers d'index... Bref, la VM allumée dispose de plus de choses, et sa gestion en temps réel implique la création de certains fichiers.

Quel est le contenu du .vmx?

Le fichier .vmx contient divers réglages en lien avec la VM : en plus de l'encodage du fichier (et du nom de l'auteur, Mike Laverick, un employé de chez VMWare), il contient des informations sur le hardware virtuel de la VM.

VCenter (TP)

Je commence connectée au VCenter. De plus, je pingue en permanence ma VM (sur mon ESX) depuis mon PC.

Insertion des licences

  1. Après avoir récupéré mon numéro de licence sur le datastore du VCenter professeurs (de la même façon que j'ai récupéré mon .ova plus tôt) Je vais insérer mes licences.
  2. Je vais dans le menu de gauche , clic droit sur le VCenter > Insérer une licence > rentrer un nom et valider.
  3. Je refais la même chose avec la licence de l'ESXi, mais je l'ajoute à l'inventaire.
    1. Attention : L'insertion d'un ESXi dans un cluster nécessite une licence "Enterprise plus". Ne pas choisir une licence hypervisor !

Datacenter et Cluster

Je vais créer le datacenter et le cluster. Le Cluster est contenu dans le datacenter, ce qui nous donne une arborescence du type :

VCenter -> Datacenter -> Cluster -> ESXi -> VMs

Ici, je crée le DATACENTER60 et le CLUSTER60.

Datacenter :

  1. Dans le navigateur, choisir le VCenter
  2. Menu central > Onglets "Centres..."
  3. Nouveau centre de données > Nommer > OK

Cluster :

  1. Dans le navigateur, choisir le datacenter
  2. Menu "Hôtes et clusters" > Onglet clusters > Nouveau cluster
  3. Nommer, le mettre dans le datacenter
  4. Je laisse par défaut pour l'instant (on pourra activer des fonctions plus tard) et je clique sur OK

Insertion de l'ESXi

L'ESXi va aller dans le cluster.

  1. Aller dans le cluster sur le menu de gauche
  2. Onglet Hôtes > Ajouter un hôte
  3. Rentrer IP, logins, cliquer sur suivant...
  4. On a un avertissement dû au clefs autogénérées, on dit oui
  5. On choisit la licence insérée précédemment
  6. On active pas le verrouillage (pas dans le cadre d'un simple TP en tout cas)
  7. On vérifie le résumé, puis on valide.

La VM a-t'elle été indisponible?

Le ping semble s'être déroulé normalement tout le long de l'opération.

L'ESXi inséré dans le cluster

RTENOTITLE

 

Changement de cluster et de datacenter

Nous allons changer notre ESX de cluster et de datacenter.

Créer les nouvelles ressources

Je vais créer un nouveau datacenter et un nouveau cluster, qui s'appelleront simplement DATACENTER et CLUSTER.

  1. On commence par créer un nouveau datacenter suivi d'un cluster...
  2. ...de la même façon que précédemment (Se placer dans le VCenter depuis le navigateur)
    1. Attention, ne pas confondre "Banque de données" et "Centre de données" (le mieux serait de tout mettre en anglais)

Migrer l'ESX

Méthode 1 (Qui marche pas...)

  1. Je me rend sur le cluster d'origine, et je fais un clic droit sur mon ESX > Passer en mode maintenance. Cela prend un peu de temps, surveiller la progression dans la fenêtre inférieure !
    1. Il faudra sans doute couper la VM... Le mode maintenance permet de la HA si l'on dispose vMotion, mais ce n'est pas le cas ici.
    2. L'ESXi est désormais indiqué "en mode maintenance".
  2. En théorie, il suffit de faire un clic droit sur l'ESXi > Déplacer vers. Cependant, j'ai un problème d'autorisation. Je vais donc changer de méthode.
  3. Ne pas oublie d'enlever le mode maintenance après !

Méthode 2

  1. Faire un clic droit sur l'ESX > Déconnecter
  2. Clic droit > Supprimer de l'inventaire
  3. Ensuite, il suffit de rajouter l'ESX dans le nouveau cluster.

Je peux ensuite supprimer les anciens datacenter et clusters :

  1. Clic droit sur le datacenter > Supprimer.
  2. Cela supprime aussi le cluster associé.

La migration provoque-t'elle une interruption de service ?

Dans mon cas oui, puisque je suis passée par la première méthode (avant de me heurter à des soucis d'autorisations). Le mode maintenance provoque une coupure, si l'on ne dispose pas de vMotion. Avec vMotion, on pourrait normalement migrer la VM sur un autre ESX avant de faire le déplacement.

Cependant, la seconde méthode ne doit pas provoquer de coupure : a aucun moment, on a besoin de stopper la VM.

Mon ESX a bien été migré

RTENOTITLE

Connexion à un disque NFS (TP)

Connexion

Je commence par me connecter au FreeNas, via l'IP et avec les identifiants fournis.

Source

https://www.virtualizationhowto.com/2017/05/configure-freenas-9-10-nfs-vmware-esxi-6-datastore/

Configuration de FreeNAS

Créer le volume

  1. Je me rends dans Storage > Volumes > Volume Manager
  2. Une fenêtre s'ouvre :
    1. Je donne un nom au volume
    2. J'ajoute un disque avec le +
    3. Je choisis Stripe (on a qu'un seul volume, de toute façon...), et je tire sur la petite poignée pour m'assurer que le disque est sélectionné
    4. Je clique sur "Add Volume".
    5. Le volume finit par être créé après un certain temps.

Dans la foulée, je vais créer un Dataset :

  1. Storage > Volumes > /mnt/vol01 > Creat Dataset
  2. Je le nomme comme je veux (Ici NFS61)
  3. Je laisse ici la compression et la déduplication sur off
  4. Je clique sur Advanced et je précise la taille : "Reserved space for this dataset and all children : 1 GiB" et la même chose dans "Reserved Space"
  5. Add Dataset

Activer le service NFS pour l'IP privée et créer le partage:

  1. Je me rends dans l'onglet Sharing
  2. Je clique sur "UNIX/ NFS" :
    1. Je crée le montage NFS. Pour cela, je choisis le dossier /mnt/VOL01/NFS61 créé juste avant.
    2. Je peux activer l'option "All directories".
    3. Je laisse le reste en configuration par défaut.
    4. Normalement, le dossier partagé est "/mnt/VOL01/NFS61". Le noter
    5. Une fois fait, je clique sur "OK".
    6. Dans advanced:
      1. J'ajoute le réseau autorisé
      2. Je choisis le "Maproot User" (Root), qui est l'utilisateur dont les login seront utilisés pour accéder au partage
  3. Je vais dans "Services > NFS":
    1. Je coche la case : "Bind for <IPdeFreeNAS>"
    2. Activer NFS4
    3. OK

RTENOTITLE

Monter le NFS sur l'ESX

Je commence par me rendre sur le VCenter. Ensuite :

  1. Clic droit sur DATACENTER > Stockage > Nouvelle Banque de données
  2. Type : NFS
  3. NFS 3.1
  4. Pour Nom et configuration :
    1. Nom : VOL01
    2. Dossier : /mnt/VOL01/NFS61 (Correspond au dossier sur le serveur, par sur le client !)
    3. Serveur : IP du FreeNAS (puis cliquer sur le + vert)
  5. Pas d'auth Kerberos
  6. Cocher la case de l'ESXi (pour qu'il ait accès au NFS)
  7. Terminer.

Attention : L'interface peut donner l'impression que le cluster a disparu.. Si c'est le cas, il faut aller dans Datacenter puis : "Hôtes et clusters", cliquer sur le cluster. De la même façon le partage NFS peut donner l'impression d'avoir disparu...

 

RTENOTITLE

Ici, le montage NFS est bien visible dans le menu de droite


Pouvez-vous connecter le partage NFS de votre binôme?

C'est en effet possible. Pour cela, il suffit de recréer les datastores, en sélectionnant à chaque fois les deux ESXi au lieu d'un seul.

Cela permet d'avoir de la haute disponibilité sur le stockage, par exemple.

Modifier le contenu du partage

Je vais créer un nouveau répertoire dans le partage. Pour cela, je vais dans NFS61 > Fichiers :

  1. Je peux créer un nouveau dossier, et lui donner le nom que je veux

RTENOTITLE

Connexion de disques iSCSI

On repart ici de la même architecture, avec le FreeNAS comme target.

 

Configuration de l'ESXi

Je commence par rajouter un adaptateur VMKernel :

  • Choisir l'ESX > Configurer > Adaptateur VMKernel > Nouveau
    • adptateur réseau VMKernel
    • vswitch0
    • Le reste est standard, penser à cocher la case "vSAN"

Ensuite un adaptateur de stockage :

  1. Choisir l'ESX > Configurer > Stockage > adaptateurs de stockage > Nouveau (+)
  2. Un nouvel adaptateur apparaît sous la rubrique "iSCSI Software Adapter"
  3. Je peux voir son IQN dans la rubrique "Général".
  4. Dans l'onglet "Liaison", ajouter l'adaptateur VMKernel précédemment créé

Je vais ajouter une cible dynamique, toujours dans les même rubriques, onglet "Cibles" :

  1. Découverte Dynamique > Ajouter
  2. Rentrer l'IP du FreeNAS (port par défaut)
  3. OK

Avez-vous des périphériques et des chemins disponibles?

Pour l'instant, non. Rien n'as été configuré sur le FreeNAS pour le moment.

Mon IQN

Ici, mon IQN est :

iqn.1998-01.com.vmware:esx61-709dbd84

A quoi correspond "vmhba0" dans adaptateur de stockage? A quoi correspond le chemin?

Cela semble correspondre à un lecteur de CDROM? Le chemin est : vmhba32:C0:T0:L0

Côté FreeNAS...

!!!FreeNAS a parfois des problèmes avec le menu central, mais tout est faisable par le menu de gauche

Une fois connectée au FreeNAS, je vais configurer le service.

  1. Services > iSCSI > ON
  2. Storage > Volumes > /mnt/VOL01 > Create zVol:
    1. Donner un nom et une taille
    2. Add zvol
  3. Sharing > Block > Portals > Add Portal
    1. Choisir l'IP du FreeNAS (la seule, normalement)
  4. Sharing > Block > Initiators > Add Initiator
    1. Ajouter l'IQN dans initiators (et effacer le ALL)
    2. OK
  5. Sharing > Block > Targets > Add target
    1. Donner un nom
    2. Portal group ID : Choisir le portal créé
    3. Initiator group ID : choisir l'initiator créé
    4. OK
  6. Sharing > Block > Extents > Add Extent :
    1. Donner un nom
    2. Choisir le zvol créé
    3. OK
    4. Un extent, ce n'est rien d'autre qu'un LUN !
  7. Sharing > Block > Add Target / Extent:
    1. Choisir le target et l'extent créés
    2. On a associé les deux !

RTENOTITLE

...de retour sur VCenter

Avant tout : Vérifier qu'à côté de l'ESXi, dans la fenêtre de navigation, je n'ai pas un "Reboot Required". Si c'est le cas, reboot de l'ESXi !

Je reviens sur l'ESXi > Configurer > Adaptateurs de stockage :

  1. Je dois avoir de nouvelles choses disponibles, un chemin et un périphérique :

RTENOTITLE

RTENOTITLE

  1. Je n'ai rien de plus dans les datastores, je vais en rajouter un à mon ESXi:
  2. Il se créée de la même façon que les autres, avec:
    1. Type : VMFS
    2. Choisir le LUN (dérouler le menu "Sélectionner un hôte" si besoin)
    3. Ne pas oublier de donner un nom...
    4. OK

Datastores

J'ai trois datastores : Le datastore de "base", le NFS, et le LUN. J'en aurais 5 si j'avais un binôme, mais ce n'est pas le cas.

RTENOTITLE


Concernant le LUN du binôme

Connecter un LUN à deux ESXi ne semble à priori pas possible. En effet, chaque ESXi dispose d'un LUN pour lui tout seul. Il est probablement possible d'effectuer une configuration du côté de FreeNAS qui permet de faire cela, mais ce n'est pas vraiment le but du iSCSI.

Utilisation de VMotion et Storage VMotion

Je pars d'une configuration dans laquelle j'ai un VCenter avec deux ESXi : mon 172.20.20.161, et un 172.20.20.162 que j'ai créé pour l'occasion et qui est identique. C'est sensé être celui de mon binôme, mais je n'ai pas de nouvelles de lui...

Je rappelle que chaque ESXi a son propre LUN. Le NFS61 est connecté aux deux ESX.

Ajout de l'adaptateur

Je vais commencer par ajouter un adaptateur VMKernel à mon ESX, de la même façon que lors de la configuration de l'iSCSI. Dans le doute, je lui active tous les services. Il a une IP fixe. Je fais cela sur les deux ESXi.

Test du vMotion

Migrer la ressource de calcul

Je vais essayer de migrer une VM depuis un ESXi vers un autre. Je fais un clic droit sur celle-ci, puis migrer :

  1. Je choisis "uniquement la ressource de calcul"
  2. Ensuite, je ne vois que mon ESX; je le sélectionne...

Ca ne fonctionne pas, puisque je ne vois qu'un seul ESXi de disponible pour la migration (je ne peux pas migrer uniquement le calcul chez le voisin en gardant le stockage sur mon ESX !), celui sur lequel je me trouve déjà. Cela dit, je ne perds pas de ping dans l'opération.

Réponse aux questions :

  • La migration ne peut se réaliser que sur le même ESXi (donc elle ne s'effectue pas vraiment...), puisque je ne peux pas migrer uniquement la ressource de calcul. Cela serait possible si les deux ESXi avaient une ressource de stockage commune et que la VM s'y trouvait déjà.
  • Pas de perte de paquets sur le ping
  • La VM n'as pas bougé

Migrer le stockage

Je vais essayer de migrer la VM vers un datastore NFS61. Pour cela, je choisis "uniquement le stockage". Mais le résultat est le même : je ne vois que les datastores propres à mon ESXi. La VM ne peut être migrée que vers une ressource de stockage auquel mon ESX à accès. C'est logique, puisque même une fois la migration effectuée, il devra assumer la charge de calcul pour celle-ci.

Je peux tout même choisir de migrer la VM sur mon NFS61. Cela fonctionne, et (presque) sans perte de connectivité. Je n'ai perdu qu'un seul paquet sur le ping.

Si je réessaye ensuite de migrer à nouveau "uniquement la ressource de calcul", cela fonctionne.

Réponse aux questions :

  • La migration peut se réaliser, si je migre la VM vers une ressource de stockage connectée à cet ESXi (NFS61, en l'occurence)
  • Un unique paquet perdu sur le ping (une perte de connectivité négligeable)
  • La VM est toujours sur le même ESXi après la migration de stockage.

Stockage + ressource de calcul

Je vais essayer de migrer les deux en même temps. Je choisit donc migrer > "Ressource de calcul et Stockage"

  1. Je commence par la ressource de calcul
  2. Je choisis l'autre ESXi (le contrôle de compatibilité doit être OK)
  3. Pour le stockage, je choisis le LUN de l'autre ESXi
  4. Je laisse le reste par défaut.

La migration se lance.

Cela fonctionne, que l'on ai une ressource de stockage commune ou pas. Dans tous les cas, ce sera à l'autre ESX d'assumer entièrement la VM, donc, pas de problèmes.

Réponse aux questions :

  • La migration fonctionne, puisque j'ai déplacé le stockage ET le calcul.
  • Un unique paquet perdu sur le ping (une perte de connectivité négligeable)
  • La VM est à présent exécutée sur l'autre ESXi (elle est passée de 172.20.20.161 à 172.20.20.162)

Retour à la normale

Une fois ces opérations effectuées, je rappatrie les VMs sur leur ESX d'origine.

Snapshots

J'utilise ma VM "Tiny61", que j'ai ramenée sur mon ESXi.

Création d'un snapshot

Je commence par prendre un premier snapshot avant toute modification. Rien de plus simple :

  1. Clic droit sur la VM  Snapshots > Prendre un Snapshot
  2. Je lui donne un nom (Ici "Snap_Sans") et une description, si besoin
  3. OK, puis attendre que le snapshot soit pris.

Ensuite, je me rends dans ma VM, et je crée un répertoire "test" à la racine du disque. Ensuite, selon le même principe, je refais un snapshot (Snap_Avec).

Restauration des snapshots

Je restaure "Snap_Sans" :

  1. Clic droit sur la VM > Snapshots > Gérer les snapshots.
  2. Je vois l'arborescence des snapshots. Je peux choisir celui que je veux (ici, je choisis snap_sans) puis actions > restaurer.

Sur ma VM, le dossier "test" n'existe pas, c'est normal : je suis revenue "dans le temps", avant la création du dossier.

Je restaure "Snap_Avec":

De la même façon, je peux restaurer "Snap_Avec".

Sur ma VM, le dossier "test" est bien là. Je suis après sa création, c'est normal.

Supprimer les Snapshots

Toujours depuis l'écran de gestion des snapshots, je peux supprimer les snapshots en les sélectionnant et en cliquant sur la croix rouge.

Sur ma VM, le dossier "test" est toujours là. C'est normal. J'avais restauré Snap_Avec, qui incluait le dossier test; bien que j'ai supprimé les snapshots (qui ne sont que des images de la VM, des photos, en quelque sorte), la VM, elle, n'a pas eu de raison de changer !

HA : High Availability

La HA permet de basculer automatiquement les VMs d'un ESX à l'autre. Pour cela, les ESX doivent avoir des banques de données communes.

Activation de la HA

  1. Dans le menu de navigation, sélectionner le cluster.
  2. Dans le menu central, choisir l'onglet Config
  3. Disponibilité vSphere > Modifier > Activer vSphere HA.
  4. OK

Par défaut, seule l'option "Echec de l'hôte" est activée. On peut ensuite se rendre dans les onglets pour une configuration plus fine : ici, je me contente de choisir la Réponse en cas de panne de l'hôte, qui consiste à redémarrer les VMs. Cela veut dire que les VMs seront redémarrées une fois leur hôte revenu, ce n'est pas encore du basculement...

Tests

Avant toute chose, je lance un ping continu vers ma VM Tiny61, qui est sur mon ESX61.

Je me rend sur le VCenter prof (qui contient les ESX...) et j'arrête mon ESX61. A ce moment-là :

  1. L'ESX devient indisponible sur le VCenter.
  2. La VM s'arrête. Elle est toujours marquée "Sous tension" mais n'est plus disponible.
  3. Un message arrive : "Le basculement de la VM a échoué". C'est normal : je n'ai pas configuré de basculement, puisque je ne peux pas encore (PoActive HA est désactivé...). J'aurais besoin de DRS pour faire des basculements automatiques de VM, mais il n'est pas encore en place.

 

Une fois que je relance l'ESX, la VM est relancée, elle aussi. Ce processus est automatique.

DRS

Distributed Resource Scheduler.

Le but de cette fonctionnalité est de répartir les VMs automatiquement entre les ESX afin de répartir la charge. Le déplacement de VMs se fait par VMotion.

DRS permet de créer des groupes (de VMs et / ou d'ESX) grâce à des règles d'affinité pour les faire fonctionner ensemble. Cela permet de mettre en place de la HA.

Activation

J'active DRS sur le cluster.

  1. Je me rend au même endroit que pour la HA, mais je choisir DRS et je l'active.
  2. Je laisse les options par défaut.


Création d'une règle de non-affinité

On va créer une règle de non-affinité, qui empêche d'avoir les deux VM sur le même groupe DRS. Ici, le résultat final sera d'avoir les deux VMs dans un même groupe, sachant qu'elle ne pourront pas être démarrées en même temps (non-affinité).

  • La règle définit tout simplement un comportement à adopter au sein du groupe.
  • Le groupe définit les machines (au sens large) qui fonctionneront de concert.

Dans la configuration, je choisis "Règle de VM/Hôte" :

  • Je clique sur ajouter.
  • Ensuite, je fais comme ci-dessous :

RTENOTITLE

Je dois aussi créer un groupe, dans "Groupes de VM/Hôtes" :

RTENOTITLE

Tests

Quand j'essaye de mettre les deux VMs sur le même ESXI, je ne peux en avoir qu'une seule de démarrée. C'est le but de ma configuration...

Si j'éteins l'ESXI, ma VM est automatiquement migrée sur l'autre ESXi. La HA fonctionne à présent. C'est normal, c'est le but de DRS.

Étude de cas

Les documents suivants présentent une étude de cas. Les choix ont été contraints par un budget.

Matériel et Licences

Serveurs

Nous avons 3 serveurs, qui acceuillent les ESX + Vcenter. Leur caractéristiques : 

   • 16 coeurs à 2.1 GHz
   • 32 Go de RAM
   • 4 Interfaces
   • 1 disque système
   • 2U
   • 3 * 8000 €

NAS

Nous avons un NAS autonome: 

   • 24 baies
   • Processeur 8 coeurs
   • Extensible via PCIe
   • 3U (baie + contrôleur)
   • 4500 €

Il contient : 

   • 24 disques de 1 To
   • 7200 RPM
   • 10 TO en RAID1
   • 4 spares
   • 7200 €

Commutateurs

Nous avons 2 piles de 2 commutateurs afin de répartir les liaisons et d’avoir du failover. 

   • 24 ports
   • Manageables
   • 1U
   • 4 * 2000 €

Routeur

Nous avons un routeur entre pour l’arrivée fibre. 

   • 1U
   • 1000 €

Licences

   • Windows : 2 * 871€
   • VMWare : 2 * VMware vsphere enterprise Plus à 3 305€ + Vcenter Server Standard à 6005 €

Total : 

   • 59057 €
   • 11U

Ressources allouées aux Vms

Serveur Web : 

   • 2 cores
   • 4 Go de RAM
   • 500 Go

Base de données : 

   • 4 cores
   • 8Go de RAM
   • 2To

AD + Zimbra : 

   • 4 cores
   • 8 Go de RAM
   • 500 Go

Windows Comptabilité : 

   • 2 cores
   • 4 Go de RAM
   • 500 Go

PfSense 

   • 2 cores
   • 4 Go de RAM
   • 50 Go

Réseau

Physique Le réseau est en 1 Gigabit sur l’ensemble des liaisons. Toutes les liaisons sont doublées via du NIC teaming, ce qui permet d’assurer une redondance en plus de doubler les performances. Les commutateurs fonctionnent en stacks de 2 ; ainsi, chaque interface de chaque ESXi peut être connectée à un commutateur différent, ce qui induit une meilleure redondance.

Virtuel Le réseau virtuel est basé sur trois vSwitches. Les vSwitches 1 et 3 sont reliés à des interfaces physiques. Le vSwitch1 dessert le LAN, est relié à une interface physique. Le vSwitch2 dessert la DMZ. Le vSwitch3 dessert l’accès Internet. Il est relié à une interface physique. Cette configuration se répète sur chaque ESXi. Ainsi, chaque ESXi peut acceuillir n’importe quelle VM, ce qui permet la redondance. La VM PFSense assure le rôle de routeur / pare-feu pour toutes les Vms ; de par son efficacité et sa fiabilité, c’est une bonne solution gratuite et libre. PfSense permet de créer des règles de filtrage poussées. Configuration interne à VMWare Le Vcenter contrôle les deux ESXi. Sur celui-ci, la configuration est la suivante : 

   • 1 cluster, qui contient : 
       ◦ Les ESXi
       ◦ Un Datastore en NFS, relié aux deux ESX.
   • Les deux Vswitches sont présents, reliés aux interfaces virtuelles correspondantes.
   • Les Vms sont reliées aux Vswitches correspondants.

Pour la HA : 

   • Vsphere HA est activé.
   • DRS est activé au niveau du cluster : les 4 VM sont dans le même groupe de VM/Hôtes.
   • En cas de perte d’un ESXi, vMotion accomplira le transfert des Vms.
   • Pas de règles d’affinité à définir.


Choix techniques

Réseau Le choix de PfSense permet de sécuriser l’infrastructure à moindres coûts. Le CARP failover, disponible sous PfSense, n’est pas utilisé ici pour ne pas complexifier davantage l’infrastructure ; la haute disponibilité est déjà assurée au niveau de VMWare. Redondance et Failover La redondance est configurée de la façon suivante : 

   • Chaque ESX acceuille 2 Vms. Au total, ces deux Vms utilisent 14 Go de RAM et 8 cores pour l’ESXi 1, et 12 Go de RAM ainsi que 6 cores pour l’ESXi 2. 
   • Ainsi, chaque ESXi peut acceuillir l’ensemble des Vms, si son voisin venait à tomber. Il a les ressources suffisantes, au niveau du matériel comme au niveau du réseau.

Évolutivité 

   • Les ressources matérielles permettent d’avoir une bonne évolutivité. En effet, il est possible d’allouer encore des ressources aux Vms , sans pour autant perdre la possibilité de faire tourner toutes les Vms en même temps sur un seul ESXI. 
   • La volumétrie permet également de l’évolutivité, que ce soit pour acceuillir de nouvelles Vms ou pour accueillir un système de sauvegarde plus poussé. Seuls 4 To sont utilisés sur les 10, 8 si l’on compte de façon grossière les sauvegardes (il est possible de gagner de la place en introduisant un vrai système de sauvegarde contenant de la déduplication). 
   • L’idée derrière cette allocation de ressources est de commencer petit et d’allouer des ressources aux Vms en cas de besoin (notamment les ressources processeur). On garde de la marge dans le but de faire évoluer les Vms au gré de la demande. Compte tenu de la petite taille de l’entreprise, cette démarche devrait permettre de parer à une augmentation d’activité, au moins pendant un certain temps.
   •  Cette marge de manœuvre pourrait permettre d’accueillir de nouvelles machines : sauvegarde, supervision...

Stockage Toutes les Vms sont sur le Datastore NFS, qui est commun aux ESX. Ainsi, toutes les données sont centralisées sur le NAS, et le failover est possible. On profite aussi de la redondance du RAID5, qui amène un bon compromis entre l’espace de stockage et la sécurité. Il amène cependant une certaine quantité de calculs à la reconstruction. Le choix d’un autre type de RAID est possible, en fonction des demandes du client. Le stockage est configuré comme suit : 

   • RAID5 : 20 disques utilisés+ 4 disques de spare
   • Pertes acceptables : 5 disques maximum
   • Volumétrie utile : 20 To
Récupérée de « https://wiki.squi.fr/index.php?title=VMWare&oldid=2149 »