Search This Blog

vendredi 31 janvier 2014

Mise en place d'une replication de VMs avec Hyper-V Replica

Configuration d'Hyper-V Replica pour la réplication de VM.

Nous allons mettre en place la réplication d’une VM qui se trouve sur un cluster « CLUSTER-HYPERV » vers un serveur standalone qui se trouve hors site.(VH03) comme sur le schéma ci-dessous:

On voit sur le schéma, une VM en blanc entrain de se répliquer vers le serveur replica VH03.



Un schéma c'est beau, mais voyons maintenant comment ça se met en place, pour cela, il faut se rendre dans la console du cluster, je vois deux éléments ici :

-          - Une VM qui se nomme CL7 (client Windows 7)
-          - Un rôle « REPLICA-HYPERV » c’est ce rôle qui va permettre la réplication pour mon cluster      « CLUSTER-HYPERV »


Je clic droit sur la VM que je souhaite répliquer, et j’active la réplication comme ceci :





L’assistant s’ouvre :

Il vous indique les tâches à faire en amont, avant de faire de la réplication de VMs, c’est ce qu’on a fait lors des tutos précédents.

Cliquez sur suivant.




Ici, il faut choisir le serveur Replica, ça sera le serveur sur le quel nous allons répliquer notre VMs « CL7 » :
Attention, il faut spécifier le nom du serveur et non l’adresse IP, et pour cela, faut que vous ayez un DNS fonctionnel du cotés WAN.

Cliquez sur suivant.



Spécification du type d’authentification ainsi que l’encapsulation :

-          - Authentification Kerberos avec http (données non cryptée lors de la réplication) (mon choix ici pour ce LAB)
-          - Authentification sécurisée avec certificats (HTTPs) données cryptés durant la réplication des VMs

Je choisi la compression des données lors de la réplication afin de moins charger la bande passante.

Cliquez sur suivant.








Ici, choix des disques virtuel à répliquer, bon j’en ai qu’un sur la VM CL7, mais on aurait pu choisir plusieurs disques virtuels si ma VM avait plusieurs disque virtuels (.VHDx) 

Cliquez sur suivant pour passer à la prochaine étape.




Choisir ici la fréquence de réplication, je choisi 30 secondes, c’est-à-dire que le cluster va répliquer la VMs toute les 30 secondes au serveur réplica (VH03).

Au début, la réplication est assez longue, car tout le disque est répliqué vers le serveur réplica (VH03), ensuite les réplications toutes les 30 secondes dureront pas longtemps car seul les données modifiées seront répliquées vers le serveur de réplica, ce qui permet d’une optimisation de données répliquées.

Cliquez sur suivant.





Configuration des points de restauration supplémentaires:

Ici je choisi de conserver que le dernier point de récupération.

On peut configurer la fréquence VSS, faut savoir que plus vous avez de point de restauration, plus le réplica grossira et prendra de la place.

Cliquez sur suivant.




Choisi de la méthode de réplication initiale :

Je choisi d’envoyer la copie initiale sur le réseau.

On peut choisir quel moment faire la réplication :

-         -  Soit immédiatement
-         -  Ou la faire démarrer à une date et une heure précise.

Moi je choisi la réplication immédiate.






Voici le résumé qui fait un récap de vos actions :

Cliquez sur terminer afin de démarrer la réplication.




La réplication démarre :




A la fin une fenêtre s’ouvre pour vous prévenir que la réplication s’est bien déroulée , il nous informe que la réplication de la VM CL7 à bien fonctionné et se trouve sur le serveur réplica VH03.



Voici la réplication qui s’active sur le serveur VH03, on voit le pourcentage avancer:

On voit bien que je suis sur le serveur VH03.





Voici l’état de la réplication :


En PowerShell on voit la liste des VMs répliquées sur nos Hyper-V  (sur VH03):





et voila, l’article touche à sa fin, avec ça on peut avoir un vrai PRA afin de protéger son système d'information, on peut ainsi reprendre son activité après un crash complet d'u site avec une perte de données qui varie seulement entre 30 seconde et 15 minutes, ce qui est assez remarquable.


@bientôt

Seyfallah Tagrerout 








































lundi 27 janvier 2014

Mise en place d'un PRA

Mise en place d’un PRA « plan de reprise d’activité »  avec Windows Server 2012 R2. (PART 1)

Bonsoir, nous allons voir dans cet article, la mise en place d'un PRA, une stratégie très très importante pour les DSI et les systèmes d'informations de nos jours.

Tout d'abord, Un PRA permet d’assurer la remise sur pied d’un système d’information et les activtés d’une entreprise après un gros incident tel quel que des catastrophes naturelles, (tremblement de terre), ou incendie dans les locaux.

C’est un choix stratégique qui coûte cher certes, mais qui permet à l’entreprise de garder ses données, son activité, sa clientèle après de graves incidents.

Pour faire du PRA avec Windows server 2012, il faudra utiliser Hyper-V réplica, c'est une fonction native d'hyper-v qui permet la réplication de VMs entre un hyperviseur A vers un hyperviseur B qui peut se trouver sur un autre site pour plus de sécurité.

Nous allons ici mettre en place la réplication de VM vers un serveur extérieur, ça nous permettra d’avoir une sauvegarde de VM hors site en cas d’incendie etc. .

Faut savoir que la configuration de la réplication entre deux Hyperviseurs autonome n’est pas la même qu’avec des hyperviseurs clusterisé.

Je m’explique, si vous avez deux serveurs automnes (non cluster), la réplication est plus au moins facile, car il suffit de l’activez dans chaque hyperviseur via les paramètres Hyper-V.

Dans un environnement clusterisé, il faut configurer un rôle cluster « HyperV Replica broker » qui va se charger d’ordonner la réplication des VMs pour les hyperviseurs qui sont sur le cluster, peu importe ou la VM se trouve, la réplication se fera tout de même et de manière transparente pour le serveur qui va recevoir la réplication.

Voici l’architecture que nous allons utiliser pour Hyper-V replica :




À partir d’un cluster Hyper-V, nous allons répliquer une VM vers un serveur autonome VH03 dans un site distant pour protéger les VMs.

Etape de configuration :

  • -          Installation et configuration de l’Hyperviseur VH03
  • -          Paramétrage d’hyper-V replica sur VH03
  • -          Création et configuration du rôle cluster « Hyper-V Replica Broker »
  • -          Paramétrage d’Hyper-V replica sur le cluster via le broker
  • -          Réplication d’une VM vers VH03


Une fois que le serveur VH03 est installé, configuré, il faut aller dans les paramètre d’hyper-V, comme ceci :
(capture d’hyper-v avec l’accès au paramètre Hyper-V)


Et allez dans « Configuration de la réplication » :


Cocher les cases suivantes :
  • -          Activez ce ordinateur en tant que serveur de réplication
  • -          Utiliser la méthode d’authentification Kerberos (via http), on à pas de certificat SSL ici, donc on reste sur le protocole http.
  • -          Autorisez la réplication à partir… (c’est dans ce dossier ou seront placées les VMs répliquées), bon ici, c’est sur le C:\ mais en général c’est sur un stockage soit de type SAN ou NAS pour plus de sécurité.

Voici le résultat :


Une fois qu’on a configuré VH03, nous allons maintenant passer au cluster, et configurer le rôle « Hyper-v Replica Broker ».

Allez dans votre cluster et ajoutez un rôle (ici mon cluster c’est HYPERV-CLUSTER.seyf.lan) :



Ensuite choisissiez le rôle suivant  Service Broker de réplication HyperV :

Cliquez sur suivant.



Choisir ici le nom d’accès client , « REPLICA-HYPERV » avec une adresse IP : 192.168.2.51 /24.
Et cliquez sur suivant.


L’assistant vous montre la création de l’objet dans active directory,

Cliquez sur suivant pour poursuivre.



Résumé de la création du rôle  Service Broker de réplication Hyper-V , cliquez sur terminer.


Activation de la réplication dans le cluster via le Broker :

Comme on a installé le rôle cluster « Service Broker de réplication Hyper-V », le paramétrage de la réplication se fait uniquement sur ce dernier, et non directement sur les hôtes, c’’est le broker qui va faire office d’ordonnanceur entre tous les hôtes du cluster.

Allez dans le rôle du cluster « Service broker de réplication Hyper-V » et cliquez droit et allez dans Paramètres de réplication, comme ceci :


Activez ensuite la réplication comme sur VH03, avec l’authentification Kerberos via (http), ensuite il faut spécifiez le chemin ou seront placés les réplicas des VMs).

PS : le chemin dans le cadre d’un cluster Hyper-V avec le rôle « Service Broker de réplication Hyper-V » doit être un stockage CSV, sinon ça ne marche pas.

Cliquez sur OK.


L’hyperviseur vous prévient qu’il y’a des ports spécifique à ouvrir sur le pare-feu Windows afin que la réplication puisse se faire, ces port doivent être ouverts sur tous les serveurs qui participent à la réplication des VMs.

C'est fini pour cette première partie, nous verrons en deuxième parte comme activer la réplication dent VM sur une VM clusterisé.

@ bientôt

Seyfallah 


















Configuration cluster Hyper-V sous Windows Server 2012

Configuration cluster Hyper-V sous Windows Server 2012 R2

Bonsoir, nous allons continuer sur notre lab de virtualisation , nous allons cette fois-ci installer et configurer un cluster d'hyperviseur sous Hyper-V R2.


Afin  de configurer le rôle cluster qui permettra d’avoir un cluster Hyper-V pour répartir les VM sur des nœuds, il faut au préalable avoir configuré le cluster Windows de base.

Voici un ancien article que j’avais fait, celui-ci montre la configuration d’un cluster de base ainsi qu’un rôle cluster de fichier.

Une fois que votre cluster de base est opérationnel, nous pouvons créer le rôle virtual machine qui permettra d’avoir des VM clusterisée.

Pour ceux, qui ne savent pas monté un cluster sous Windows Server, voici un article ou je montre la mise en place d'un cluster de fichier de façon trés détaillé. ==> cluster de fichier

Création du rôle Hyper-V « virtual machine cluster » :


Allez dans votre Cluster, moi ici c’est « CLUSTER-HYPERV.seyf.lan » , et cliquer doit, et sélectionnez « Créer un rôle vide » :


Voici un petit avant-propos qui vous explique brièvement la haute disponibilité des rôles au sein d’un cluster Windows Server.

Cliquez sur suivant.


Choisissiez le rôle à configurer pour la haute disponibilité, ici, il faut choisir «  Ordinateur virtuel », et cliquez sur suivant.


Sélectionnez les VM que vous souhaitez mettre en haute disponibilité, ici j’ai qu’une seule VM « CL7 », vous pouvez ajouter plusieurs VM bien entendu.

Cliquez sur suivant pour poursuivre.


Un récap qui vous montre les VMs que vous avez sélectionnés pour la haute disponibilité.

Cliquez sur suivant.


On voit ici la configuration du rôle « ordinateur virtuel » ainsi que la configuration des VMs pour un environnement clusterisé.


Le résumé de votre installation ; on voit que le rôle est parfaitement configuré, mais j’ai un warning sur résultat, analysons ensemble ce que c’est.

Cliquez sur « Rapport ».





-     Le chemin de l’iso ne se trouve pas dans le stockage partagé pour qu’il puisse être accessible par les deux nœuds de cluster (donc il faut faire la copie de l’iso dans la LUN qui fait office de storage partagé pour le cluster).


Voici le résultat, on voit ici le rôle configurée avec la VM clusterisé au sein de mon cluster :



Une fois que le rôle de cluster est configuré, nous allons pouvoir effectuer les opérations suivantes sur notre cluster :


  • -          Migration à chaud des VMs
  • -          Migration à chaud du stockage (Quorum)
  • -          Création d’un stockage CSV
  • -          Activez la réplication par le rôle clusterisé « Hyper-V Replica Broker »
  • -          Répliquer et faire une migration à chaud en même temps

@ bientôt 

Seyfallah 



















vendredi 24 janvier 2014

Nic Teaming

Bonjour,

Voici mon premier article en 2014 qui va traiter cette fois ci sur la partie réseau de Windows Server 2012 R2.

cet article est basé sur mon expérience personnel dans le cadre de mon lab chez moi.

Nous allons voir le Nic Teaming "l'agrération de cartes réseau". je vous montre ici les  bonnes pratiques lorsqu'on monte une plateforme de virtualisation sous Hyper-V.

Voici l'architecture de base:

Vous avez ici 3 serveurs sous Hyper-V 2012 R2.

Architecture:

  • Un cluster Hyper-V avec deux nœuds (VH01 et VH02)
  • Un serveur qui fait office de SAN qui distribue deux targets ISCSI pour le stockage mutualisé entre les deux nœuds, il sert pour le stockage commun des VMs et pour le Quorum pour la parte clustering
  • Un serveur VH03 qui fera office de serveur replica (il va hébergé les réplicas des VMs ) pour faire du PRA (plan de reprise d'activité)




Nous allons voir la partie réseau, c'est à dire les cartes réseaux de chaque serveurs, on va essayer de faire de la redondance au niveau des cartes réseaux des hyperviseurs afin d'avoir une plateforme de virtualisation optimale et surtout hautement disponible.

1- Présentation du Nic Teaming 

Le NIC Teaming est une agréation de cartes réseau qui va permettre de regrouper plusieurs cartes réseau en une seul carte virtuelle, par conséquent le débit sera additionné sur la carte agrégée.

Exemple :

Si vous avez deux cartes réseau de 10 GB/s, avec une agrégation de cartes réseau, vous aurez un débit de 20 GB/s.

Cette fonctionnalité à vue le jour avec la nouvelle version de Windows Server, Windows Server 2012.

L’avantage du NIC Teaming :
  • L’amélioration des performances de la bande passant
  • La tolérance aux pannes des cartes réseau
  • Réparation de charge entre les différentes cartes réseau qui font partie de la même équipe Teaming
  • Facilité d’implémentation et de gestion avec Windows Server 2012 / R2

Fonctionnalité supportées : (Windows Server 2012)
  • Administration PowerShell
  • Administration via l’interface graphique
  • Support des VLANs
  • Cartes réseaux de différents types (constructeurs différents)


Dans Windows Server 2012, le NIC teaming intègre 3 modes de fonctionnement :





-  Association statique : C’est le mode le plus supporté par tous les Switchs du marché, il faut que le commutateur supporte le protocole 802.1d qui est un avenant au protocole 802.1q qui permet de faire l’agrégation de plusieurs Vlan sur un seul lien Ethernet.


-   Indépendant du commutateur : Comme son nom l’indique, le Switch n’est pas en interaction avec la Team , il ne sait pas que le port de la carte réseau est enfaîte une agrégation (association) de cartes réseau.

-   LACP : (link aggreation control protocol) Ce mode permet la négociation automatique, il est utilisé sur les Switch qui supportent le protocole 802.1aX qui permet d’identifier dynamiquement les liens entre les ports des carte réseaux et les ports des différents Switch.

  Dans Windows server 2012 R2, il y’a l’équilibrage de charge dynamique qui a été implémenté qui permettra de facilité l’implémentation des Teams.


2- Configuration de l’agréation de carte réseaux sous Windows Server 2012 :

Je me rend sur le serveur VH01:

Lancer la commande : LbfoAdmin.exe afin d’aller à l’interface de gestion des agrégations de cartes réseaux :

Une fois que vous êtes sur cette interface, vous allez pouvoir créer votre association de cartes réseau en créant une équipe qui va englober deux ou plusieurs cartes réseaux.

Dans le cadre de mon projet de virtualisation, je souhaite créer plusieurs Team afin d’avoir de la redondance et  surtout des performances élevées pour un environnement virtualisé sous Hyper-V.

Nous allons créer les Team suivantes :

  •      Team-ISCSI è pour le stockage
  •      Team-HA è pour le réseau du cluster (Herbeat)
  •      Team-PROD è pour le réseau de production


Création de la Team ISCSI  avec l’interface graphique :

Je sélectionne les deux cartes réseau pour le stockage, et je clique sur « Ajouter à une nouvelle équipe » :



Ici, je choisi le nom de l’équipe (TEAM-ISCSI), et je sélectionne bien les deux carte que je veux agréger.

Au niveau des propriétés supplémentaires, je choisi les modes suivant :
  •  Mode d’équipe : Indépendant du commutateur
  •  Mode d’équilibrage de charge : Dynamique (nouveautés Windows Server 2012 R2).
  •  Carte réseau en attente: (aucun) c’est pour faire de l’actif / passif, donc ici je fais de l’actif/actif, c’est-à-dire que les deux cartes réseaux  sont activés au même temps.
  •  Interface d’équipe principale : (pas de VLAN, donc rien à faire la dessus)


J’appuie sur OK et l’équipe se crée simplement.

Une fois crée, nous allons vérifier la création de l’équipe « TEAM-ISCSI » 

Sélectionnez « Interface d’équipe » : ci-dessous, on voit sur la capture d’écran l’équipe « TEAM-ISCSI » qui fonctionnement correctement.


Nous allons vérifier maintenant dans le centre réseau et partage la création d’une nouvelle carte virtuelle qui va englober les deux carte réseau, et ça sera sur cette carte qu’on va définir les paramètres TCP/IP.
On voit ici les Team suivantes :

-          TEAM-ISCSI
-          TEAM-HA
-          TEAM-PROD

Voici le résultat ci-dessous :


Voici les propriétés de la carte virtuelle "TEAM-ISCSI" qui regroupe les deux cartes réseau (ISCSI-01 & ISCSI-02)  pour le réseau ISCSI:

On peut voir que la vitesse du débit réseau est de 2Gbits/s, c’est normal, car avec l’association de carte réseaux, la vitesse est additionnée ==>  1 Gbits + 1Gbits = 2Gbits/s.



Nous allons voir la creation d'une agréartion via Powershell, ce qui est beacoup plus facile et plus rapide.


3- Création d'une Team en Powershell:

Avec la comdlet NetLbfo on peut créer, gérer et effacer les associations de cartes réseau sous Windows Server 2012.

Afin d’avoir toutes les commandes disponibles pour cette comdlet, nous allons tapez la commande suivante dans une invite PowerShell :

Get-command –Module 

Voici le résultat:



Elle montre toutes les comdlets qui sont liés à l'association de cartes réseau.

Je me rend sur le serveur VH02:

Nous allons créer une team ISCSI sur le serveur de virtualisation numéro 2 « VH02 » :


On voit ici que la Team est bien crée avec la commande PowerShell :




Vérification de la carte virtuelle qui englobe les deux cartes réseau, elle est présente dans le centre réseau et partage.

Liste en des Team créer sur mon serveur VH02: (Get-NetLbfoTeam)


Avec cela, vous allez avoir un serveur redondant sur la partie réseau, car si l’une des cartes réseaux tombe en panne l’autre carte sera toujours en service donc vous aurez une haute disponibilité sur la partie réseau. 
Surtout au niveau du stockage et du réseau HA ça me semble essentiel d’avoir de la redondance de cartes réseau.

4- Test de la haute disponibilité des association de cartes (Team): 

Nous allons simuler une panne sur l’une des carte réseau de la team « TEAM-ISCSI » afin de vérifier le bon fonctionnement de l’agrégation de carte au niveau de la redondance.


Paramètre TCP/IP de l’équipe « TEAM-ISCSI » : sur le serveur VH01

IP : 172.16.1.2
MASK : 255.255.255.0



Paramètre TCP/IP de l’équipe « TEAM-ISCSI » : sur le serveur VH02

IP : 172.16.1.3
MASK : 255.255.255.0





Je vais lancer un ping –t depuis le serveur VH02 afin de pinger le serveur VH01 comme ceci :




On voit que le Ping passe bien, je vais donc désactiver une des cartes réseau de l’équipe « TEAM-ISCSI »sur le serveur VH01 comme ceci : « je clique sur désactiver » :


La carte étant désactivée, le Ping fonctionne toujours, on voit bien qu’il y’a une redondance de carte réseau.


Vérification que la carte réseau est bien désactivée dans l’équipe via le gestionnaire d’agréation de cartes réseau.

On voit bien qu’il y’a un Waring qui nous dit que l’une des cartes réseau est en échec et introuvable, voici la capture ci-dessous :


En conclusion l’agréation de cartes réseau est très utile dans un environnement  de production, elle permet d’avoir de la redondance au niveau des cartes réseau et surtout aussi un gain en termes de performance sur le débit réseau.

@ Bientôt.

Seyfallah Tagrerout 


















< >