Mise en place de Storage Replica en Powershell

Bonjour,

Je vais attaquer la 2eme partie de l’article qui va consister à configurer Storage Replica entre deux serveurs.

Pour info voici la première partie de l’article qui traite de Storage Replica, son fonctionnement, les différentes architectures possibles pour Storage Replica ainsi que les prérequis nécessaires pour sa mise en œuvre sur Windows Server vNext.

•          Storage Replica Partie 1

Nous allons voir ici comme réaliser donc une réplication entre deux serveurs, voici tout d’abord l’architecture que je vais utiliser :

Pour commencer, il faut avoir suivi la partie 1 et remplir les prérequis demandés pour faire ce type de manipulation.

Donc je considère ici que vous êtes prêt et que vous avez rempli les prérequis demandés dans la première partie de l’article.

J’ai à ma disposition 3 serveurs : (infrastructure très basique)

-          vNextDC01 è mon contrôleur de domaine

-          vNextSAN01 è Mon serveur primaire (source)

-          vNextSAN02 è Mon serveur secondaire (destination)

Etape 1 : Création des volumes

Ici, je vais mettre des volumes directement en attachés au serveur en SCSI, vous pouvez bien entendu présenter des LUNs à vos serveurs (en attachement iSCSI par exemple).

Je vais créer deux volumes :

1. -          un volume pour les data
2. -          un volume pour la partie Log

Important :

Vous devez avoir les mêmes volumes (même taille) de chaque cotés (serveur source et destination) 

voici ma configuration:

J’ai ajouté sur mon serveur source un disque de 20 GB (disque qui sera répliqué) et un disque de 2 GB pour la partie Log :

Attention, il faut que les partitions soit en GPT : (vNextSAN01)

Voici le get-disk de mon serveur de destination avec la même chose que le serveur source, c’est-à-dire deux disques de 20 GB (pour la réplication des données) et un disque de 2GB pour la partie Log.

Récap :

Sur mes deux serveurs, j’ai ajouté deux disques :

1. -          un disque de 20 GB pour la data et réplication
2. -          un disque de 2 GB pour la partie Log

   Etape 2 : Installation de WVR

Une fois que vous avez fini la partie stockage, nous allons attaquer l’installation de la feature qui permet de faire du Storage Replica, vous avez deux manières de l’installer :

1. -          en PowerShell
2. -          en GUI

Voici installation en PowerShell:  è Install-WindowsFeature wvr 

Voici l’installation en GUI : il faut cocher « Windows Volume Replication »

Pensez aux pare-feu et à ouvrir les ports J  si vous avez des pare-feu entre vos deux serveurs (TCP 445 / 5445)

 Etape 3 : Création de la relation de réplication 

Nous allons créer une relation de partenariat de réplication entre les deux serveurs.

Lancer le script PowerShell suivant :

#Serveur source de replication

$SourceName ="vNextSAN01"

#Serveur de destination de replication

$DestName ="vNextSAN02"

# nom du groupe de replication source

$SrcRGName ="RG01"

# nom du groupe de replication destination

$DestRGName ="RG02"

#Volume source qui sera repliqué

$srcVol ="G:"

#Volume pour la partie Log source

$srclogvol ="H:"

#Volume de destination qui va recevoir la réplication

$desvol= "G:"

#Volume Log de destination

$deslogvol= "E"

#Création de la réplication entre les deux serveurs

New-SRPartnership -SourceComputerName $SourceName -SourceRGName $SrcRGName -SourceVolumeName $srcVol -SourceLogVolumeName $srclogvol -DestinationComputerName $DestName -DestinationRGName $DestRGName -DestinationVolumeName $desvol -DestinationLogVolumeName $deslogvol -LogSizeInBytes 1GB

Une fois exécutée vous aurez la fenêtre suivante :

Celle-ci vous montre l’état des deux serveurs qui font partie de la relation de réplication, on peut y trouver plusieurs informations :

1. -          nom des serveurs
2. -          les drives des logs (ici E: et H:)
3. -          l’état de la réplication (relation des deux serveurs)
4. -          les noms (source et destination) de la réplication

Nous allons vérifier également avec cette commande les membres de la relation de réplication :

On voit bien ici, que ça correspond à mon schéma d’architecture (j’ai bien le serveur vNextSAN02 en destination et vNextSAN01 en serveur source)

Une fois que vous avez créé votre relation de réplication, nous allons faire un test, c’est-à-dire je vais copier des fichiers sur le volume de mon serveur source et voir que la réplication se fait de manière automatique sur mon serveur de destination.

 Etape 4 : Vérification de la réplication

Nous allons pouvoir vérifier l'état de la réplication avec trois méthodes:

1. -          les Logs Windows Event
2. -          Via un compteur en PowerShell avec la commande Get-Counter
3. -          Et via perfmon.exe

Dans mon serveur source le volume qui sera répliqué vous l’avez bien compris sur le script PowerShell est le G:\, donc je vais copier dedans des fichiers afin de générer quelque IOPS pour qu’on puisse voir la réplication en temps réel.

Je lance une copie de plusieurs fichiers vers mon G:\, ensuite je me place sur le serveur de destination (celui sur lequel mon volume G:\ sera répliqué), et je lance dans un premier temps perfmon.exe

  

Et il faut créer un « Counter » sur « Storage Replication Statistics » comme ceci :

Ensuite activer le mode « Rapport » :

Voici ce que vous devez obtenir, ceci est avant la réplication :

Je vais maintenant dans mon serveur source et je lance une copie de fichier vers mon volume G:\, et voici le résultat dans perfmon.exe dans mon serveur de destination :

Remarquez la valeur « Number of Flushed Replication Transactions » qui à changée ... : preuve qu’il y’a des entrées sorties sur le disque et donc la réplication se fait bien de manière automatique.

Nous allons lancer le counter en PowerShell sur notre serveur de destination.

Faite un Get-Counter  (je stop la copie de fichier afin de stopper la réplication)

Remarquez ici, il y’a pas de réplication en cours :

Regardez maintenant quand je copie des fichiers vers mon volume G:\ qui sera donc répliqué sur le serveur de destination, regardez le champs « Physical disk ) on voit bien les entrées-sorties

Cela prouve bien le fonctionnement de la réplication de mon volume G:\ vers mon serveur de destination.

Allons maintenant voir la 3eme méthode de vérification dans l’évent Log de Windows.

Je suis dans le serveur de destination 

Tout d’abord, pour voir les Log de réplication il faut aller dans l’évent Log, ensuite aller dans :

« Applications and Services logs » è « Microsoft » è « Windows » è “WVR” et aller dans Admin:

Voici les Events ID qui correspondent à Storage Replica dans Windows Server vNext et qui vous montre l'état de votre réplication:

• 2200  
• 5001
• 5009
• 5005                
• 5015         
• 10002

Voici les logs qui montrent la réplication entre mes deux serveurs :

Dans un premier temps je vous montre l'Event 2200 qui montre le démarrage de la réplication:

On voit également par exemple sur cet event  (5015) l’établissement de la connexion pour faire la relation de réplication:

Voici également l’état du volumes Log :

On voit que des informations ont étaient écrits dessus. (c'est dû à la réplication, je vous invite à relire la première partie de mon article afin de comprendre l'utilité les deux volumes Log au sein de Storage Replica.

Voilà, c’est fini, vous avez pu faire de la réplication de stockage entre deux serveurs, la prochaine étape je vous monterai  la réplication de stockage (volume) entre cluster.

Restez connectez sur mon site et à bientôt.

@bientôt

Seyfallah Tagrerout

MSP 2014-2015

Storage Replica dans Windows Server vNext

Bonjour,

Nous allons voir dans ce nouvel article la réplication de volume  (Storage Replica) qui sera une nouvelle fonctionnalité dans la prochaine de Windows Server (vNext).

Cet article sera en deux parties :

-          Partie1 : Explication et introduction à Storage Réplica

-          Partie 2 : Miseen place d’une réplication entre deux serveurs

Storage Replica:

Storage Replica , est une nouvelle fonctionnalité qui permet de faire de la réplication de volume entre serveur ou cluster de manière (synchrone), c’est-à-dire qu’elle offre une réplication en temps réel entre deux sites distants, ce qui vous permet de mettre en place du PCA au sein de votre système d’information.

Elle offre également une réplication asynchrone entre serveurs ou clusters, cette configuration change de la réplication synchrone, car en fonction de votre RTO, vous allez avoir une perte de données, et elle ne nécessite pas les même moyens au niveau infrastructure qu’une architecture dite PCA (en réplication synchrone), par conséquent, un PRA sera moins coûteux qu’un PCA.

Nous sommes actuellement en version technical Preview sur le nouveau Windows Server vNext, donc ceci est pour faire du test et en aucun cas vous devez le mettre en production, la version de Windows Server vNext subira de nombreux changements jusqu’à sa version finale, je vous conseille de réaliser ces tests dans un cadre de Lab. (comme moi). =)

Nous allons commencer par les features disponibles dans Storage Replica

Features présentes dans Storage Replica:

Feature	Description
synchrone	OUI
asynchrone	OUI
Type de réplication	Volume (Partition)
Réseaux	TCP/IP / RDMA
RDMA	iWRAP / Infiniband
Kerberos	OUI
Data-dédpuplication	OUI
Bitlocker (sur un volume)	OUI
Administration	Powershell / console de clustering
Port de réplication	TCP 445 / 5445 )
Protocole de transport	SMB3

Architecture de Storage Replica:

Storage Replica (SR) propose deux types de réplication :

1. -          Réplication entre deux serveurs
2. -          Réplication entre deux cluster

Bien sur pour votre réplication, je vous conseil pour des soucis de haute disponibilité d’avoir la source et destination dans différents site (car aucun d’intérêt de faire de la réplication sur un seul site si vous souhaitez mettre en place un PCA/PRA)

Réplication entre deux serveurs :

Voici ici la première architecture simple, réplication de volume entre deux serveurs présents sur des sites différents. (à noter que la réplication se faire via le protocole SMB)

========================================================================

 Réplication entre deux clusters :

Voici une architecture plus solide, celle-ci consiste à répliquer le volume du cluster 1 vers le cluster 2 

On peut par exemple faire la réplication sur  le CSV « c:\clusterStorage\Volum1 ».

Voici les deux types de cluster supportés dans Windows Server Technical Preview vNext pour l’instant:

1. -          Cluster Hyper-V
2. -          Cluster de fichier (le SOFS n’est pas supporté pour l’instant)
3. 
   

   à noter que pour la réplication entre cluster, vous avez la possibilité de faire que de la réplication synchrone.

Il y’a plusieurs prérequis afin de réussir à faire une réplication de volume dans vNext, je vais les détailler ci-dessous.

Pré-requis:

 Afin de mettre en place Storage Replica, vous devez remplir les prérequis suivants :

1. -          Un domaine active directory (vous pouvez utiliser une version Windows Server 2012 R2 , pas obligé que ça soit un vNext)
2. -          Tous les serveurs qui participent à la réplication de volume devraient être par contre sur Windows Server vNext
3. -          Des volumes sur chaque serveur (présenté via un SAN (iSCSI) / SAS / JBOD / Fibre Channel SAN  (un disque pour les data et un autre pour les Logs de réplication)
4. -          Une latence réseau <ou égal à 5 minutes
5. -          Ouverture des ports suivants (445) (5985) dans les deux sens
6. -          L’activation de la règle suivante sur le pare-feu des serveurs qui participent à la réplication :

 Enable-NetFirewallRule -CimSession SR-SRV05,SR-SRV06 -DisplayGroup "Remote Desktop","File and Printer Sharing"

Pour la partie stockage des serveurs qui participent à la réplication:

Vous êtes d’accord que nous allons répliquer les volumes d’un serveur ou d’un cluster vers un autre serveur ou cluster, mais pour cela, il faut que le volume qui sera répliqué respecte les prérequis suivants :

Vous devez avoir deux Volumes (qu’il soient en local ou via une baie SAN )

o   Un volume ou sont placés vos données (files / VMs etc …)

o   Un volume pour la partie Logs (on verra plus tard à quoi ça sert ) avec une taille minimum 1GB

1. -          Les volumes doivent êtres en GPT et non MBR
2. -          Les volumes data et Logs  du serveur source doivent être de la même taille que ceux du serveur de destination pour la réplication

Attention :

Afin de pas ralentir l’écriture de l’application sur les disque data, les disque pour les logs doivent être en SSD.

Fonctionnement Storage Replica synchrone:

Voici en image le fonctionnement de la réplication synchrone de Storage Replica :

Fonctionnement Storage Replica Asynchrone :

Voila, cette première partie touche à sa fin, dans la 2eme partie,on verra la mise en place de Storage Replica (Server-Server) en Powershell, avec des tests, etc afin de bien comprendre son fonctionnement.

@bientôt

Seyfallah Tagrerout

MSP 2014-2015

Nouveautés hyper-v vNext

Bonjour,

Nous allons voir dans cet article, les nouveautés de la prochaine version d’hyper-V Vnext.

Nouveau format de fichier :

Nous allons commencer par le nouveau format de fichier des VMs qui sera en (.VMCX), ce format est plus fiable et plus robuste que l’ancien format des VMs sur les versions précédentes d’Hyper-v.

Regardez ici, dans mon Hyper-V (simple en standalone) j’ai deux machines virtuelles :

•         TEST01
•          TEST02

     

      Allons dans les dossiers ou sont stockés les fichiers de la VM « TEST01 » afin de vérifier le nouveau format de fichier de la VM en question sous Hyper-V vNext.

(Bon, ici mes VMs sont stockées sur C:\VMs , ce n’est pas bon pour de la production, c’est juste pour faire un test le temps de vous écrir ce petit article)

Donc, je me rends dans le dossier de ma VM « TEST01 » et voici le nouveau format de fichier de configuration en (.VMCX).

Et si on revenait en arrière afin de regarder les fichiers de configuration d’une VM sous l’ancienne version d’Hyper-v (Version 3 sous 2012 R2) ?

Voici le résultat :

On voit bien le format xml, tant dit que sur la nouvelle version vNext, on a du VMCX.

Et si on allait au-delà ?

Allons maintenant vérifier la version des VMs dans Hyper-V sous Windows Server 2012 R2 (V3) , avec la commande PowerShell suivante :

Get-VM * | Format-Table Name, Version

Vous constatez que nous sommes en version 5.0 :

Allons sur mon nouveau serveur Hyper-V vNext, et faisons la même chose afin de vérifier la nouvelle version de VM.

On constate ci-dessous que nous sommes en version 6.0 avec la nouvelle version d’Hyper-V vNext J 

Que se passe-t-il si je migre ma VM sous Windows Server 2012 R2 (Hyper-V 3) vers mon nouveau Windows Server vNext (Hyper-V vNext ) ? 

La VM en question fonctionnera toujours, mais par contre elle sera toujours en version 5.0 et donc vous ne profiterez pas des nouvelles fonctionnalités de la nouvelle version (6.0).

Il faut lui faire une montée de version afin qu’elle puisse passer à la version (6.0), avec la commande suivant :

Update-VmConfigurationVersion vmname

FAQ :

Si je monte de version (6.0) je peux revenir à la version précédente (5.0) ?

Non, une fois upgradé, ça sera pas possible de faire machine arrière.

Pouvons-nous faire l’upgrade de la VM vers une version (6.0) à chaud ?

Non, pour l’instant, vous devez arrêter la VM, faire votre montée de version, ensuite allumer la VM.

Une fois migrée vers la nouvelle version (6.0), je pourrais migrer cette VM vers un Hyper-V sous 2012 R2 ?

Non, vous pourrez utiliser cette VM uniquement sur Hyper-V vNext (nouvelle version)

Je peux exporter une VM de 2012 R2 vers Hyper-V vNext ?

Oui, cette opération est possible, par contre la version de la VM ne sera pas modifiée, elle restera en version (5.0) et vous devrez faire l’upgrade vers la version (6.0) vous-même.

Connexion avec Hyper-V Manager :

Une autre nouveauté également, est la possibilité d’utiliser des différents crédentials pour se connecter à un autre serveur Hyper-V depuis la console Hyper-V Manager.

Ce qui permet de faciliter la vie au quotidien J

Bien entendu vous aurez la possibilité depuis Hyper-V manager de Hyper-V vNext de manager des Hyper-V sous 2012 ou 2012 R2.

Regardez sur la version Hyper-V (2012 R), vous n'aviez pas la possibilité de choisir d'autres credentials:

Linux Secure Boot :

Dans cette nouvelle version, vous allez pourvoir bénéficier également du secure boot sous Linux, avec une VM de génération 2.

Pour pouvoir bénéficier de cela, il faut spécifier la commande Powershell à votre VM et la relancer :

Set-VMFirmware nomVM -SecureBootTemplate MicrosoftUEFICertificateAuthority

Les services d’intégration:

Les services d’intégration sont désormais directement gérer par Windows update.

Snapshot :

Cette nouvelle version d’Hyper-V prend en compte également les Snapshots dans un contexte production avec VSS. (Volume Snapshot Service)

Pleins d’autres nouveautés devraient arrivées encore, nous n’avons pas toutes les informations, donc restez connecter afin d’être à jours sur toutes les nouvelles fonctionnalités qui vont arriver avec vNext Server.

@bientôt

Seyfallah Tagrerout

MSP 2014-2015 

Techdays 2015 journée 2

Bonsoir,

Après une longue et très belle première journée, demain on attaque la deuxième journée des Techdays, retrouvez moi dans le stand (ATE) demain matin après la plénière IT.

Pour ceux et celles qui n'ont pas la chance de s'y rendre , vous pouvez bien entendu suivre les Techdays sur Twitter avec #mstechdays et également le fameux live qui se trouve sur le lien ci-dessous:

Live Techdays 2015

Ma première en tant qu'ATE s'est très bien passé, avec plusieurs question / réponses / problématiques autour des thèmes suivants :

• Windows Server 
• Hyper-V  (Virtualisation / Design )
• Windows 8.1 / Windows 10 (Poste de travail / Migration Design )

Je vous fais partager quelques photos de ma première journée aux Techdays 2015.

@Demain pour d'autres info 

Demain, je ferais un article sur les nouveauté de Windows Server Vnext / Hyper-V Vnext 

Seyfallah Tagrerout

MSP 2015-2015