Questions fréquentes (FAQ) sur le réplica de stockage

Oui. Vous pouvez utiliser les scénarios suivants avec Azure :

• Réplication de serveur à serveur dans Azure (de manière synchrone ou asynchrone entre des machines virtuelles IaaS dans un ou deux domaines d’erreur de centre de données, ou de manière asynchrone entre deux régions distinctes)
• Réplication asynchrone de serveur à serveur entre Azure et localement (à l’aide d’un VPN ou d’Azure ExpressRoute)
• Réplication de cluster à cluster dans Azure (de manière synchrone ou asynchrone entre des machines virtuelles IaaS dans un ou deux domaines d’erreur de centre de données, ou de manière asynchrone entre deux régions distinctes)
• Réplication asynchrone de cluster à cluster entre Azure et localement (à l’aide d’un VPN ou d’Azure ExpressRoute)
• Clustering étendu à l’aide des disques partagés Azure (de manière synchrone ou asynchrone entre des machines virtuelles IaaS dans un ou deux domaines d’erreur de centre de données, ou de manière asynchrone entre deux régions distinctes)

Vous trouverez d’autres remarques sur le clustering invité dans Azure sur : Déploiement de clusters invités de machines virtuelles IaaS dans Microsoft Azure.

Remarques importantes :

• Il existe des modèles Azure Resource Manager pour le clustering de réplica de stockage basé sur des espaces de stockage direct dans Créer des clusters SOFS d’espaces de stockage direct avec réplica de stockage pour la récupération d’urgence dans les régions Azure.
• La communication RPC de cluster à cluster dans Azure (requise par les API de cluster pour accorder l’accès entre les clusters) nécessite la configuration de l’accès réseau pour l’objet nom de cluster (CNO). Vous devez autoriser le port TCP 135 et la plage dynamique au-dessus du port TCP 49152. Consultez Génération d’un cluster de basculement Windows Server sur une machine virtuelle Azure IAAS – Partie 2 Réseau et création.
• Il est possible d’utiliser des clusters invités à deux nœuds, dans lesquels chaque nœud utilise le bouclage iSCSI pour un cluster asymétrique répliqué par le réplica de stockage. Cela donnera néanmoins probablement de très mauvaises performances et ne doit être utilisé que pour des charges de travail ou des tests très limités.

Les messages de l’événement 1237 affichés dans le journal des événements de l’administrateur de réplica de stockage sur le serveur de destination indiquent le nombre d’octets copiés et restants toutes les 10 secondes. Vous pouvez également utiliser le compteur de performance du réplica de stockage sur la destination affichant \Statistiques du réplica du système de stockage\Total d’octets reçus pour un ou plusieurs volumes répliqués. Vous pouvez également interroger le groupe de réplication à l’aide de Windows PowerShell. Par exemple, cet exemple de commande obtient le nom des groupes sur la destination, puis interroge un groupe nommé Réplication 2 toutes les 10 secondes pour afficher la progression :

Get-SRGroup

do{
    $r=(Get-SRGroup -Name "Replication 2").replicas
    [System.Console]::Write("Number of remaining bytes {0}`n", $r.NumOfBytesRemaining)
    Start-Sleep 10
}until($r.ReplicationStatus -eq 'ContinuouslyReplicating')
Write-Output "Replica Status: "$r.replicationstatus

Oui, avec Set-SRNetworkConstraint. Cette applet de commande fonctionne au niveau de la couche d’interface et peut être utilisée dans des situations avec ou sans cluster. Par exemple, avec un serveur autonome (sur chaque nœud) :

Get-SRPartnership

Get-NetIPConfiguration

Notez les informations de passerelle et d’interface (sur les deux serveurs) et les instructions de partenariat. Ensuite, exécutez :

Set-SRNetworkConstraint -SourceComputerName sr-srv06 -SourceRGName rg02 -
SourceNWInterface 2 -DestinationComputerName sr-srv05 -DestinationNWInterface 3 -DestinationRGName rg01

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

Pour configurer des contraintes de réseau sur un cluster étendu :

Set-SRNetworkConstraint -SourceComputerName sr-cluster01 -SourceRGName group1 -SourceNWInterface "Cluster Network 1","Cluster Network 2" -DestinationComputerName sr-cluster02 -DestinationRGName group2 -DestinationNWInterface "Cluster Network 1","Cluster Network 2"

Non, le réplica de stockage prend uniquement en charge la réplication un-à-un d’un serveur, cluster ou nœud de cluster étendu. Cela peut changer dans une version ultérieure. Vous pouvez bien sûr configurer la réplication entre différents serveurs d’une paire de volumes spécifique, dans les deux sens. Par exemple, le serveur 1 peut répliquer son volume D sur le serveur 2 et son volume E à partir du serveur 3.

Vous pouvez augmenter (étendre) des volumes, mais pas les réduire. Par défaut, le réplica de stockage empêche les administrateurs d’étendre les volumes répliqués ; utilisez l’option Set-SRGroup -AllowVolumeResize $TRUE sur le groupe source, avant le redimensionnement. Par exemple :

1. Utilisez sur l’ordinateur source : Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
2. Augmentez le volume à l’aide de la technique de votre choix
3. Utilisez sur l’ordinateur source : Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

Pas dans Windows Server 2016. Le réplica de stockage démonte le volume de destination au début de la réplication.

Toutefois, dans Windows Server 2019 et le canal semi-annuel Windows Server à compter de la version 1709, l’option de montage du stockage de destination est désormais possible. Cette fonctionnalité s’appelle « Test de basculement ». Pour ce faire, vous devez disposer d’un volume inutilisé au format NTFS ou ReFS qui n’est pas en cours de réplication sur la destination. Vous pouvez monter un cliché instantané du stockage répliqué de manière temporaire à des fins de test ou de sauvegarde.

Par exemple, pour créer un test de basculement dans lequel vous répliquez un volume « D: » dans le groupe de réplication « RG2 » sur le serveur de destination « SRV2 » et disposez d’un lecteur « T: » sur SRV2 qui n’est pas répliqué :

Mount-SRDestination -Name RG2 -Computername SRV2 -TemporaryPath T:\

Le volume répliqué D: est désormais accessible sur SRV2. Vous pouvez le lire et y écrire normalement, copier des fichiers ou exécuter une sauvegarde en ligne que vous enregistrez ailleurs à des fins de conservation, sous le chemin D:. Le volume T: contient uniquement des données de journal.

Pour supprimer le cliché instantané du test de basculement et ignorer ses modifications :

Dismount-SRDestination -Name RG2 -Computername SRV2

Vous devez uniquement utiliser la fonctionnalité de test de basculement pour les opérations temporaires à court terme. Cette fonctionnalité n’est pas destinée à une utilisation à long terme. En cas d’utilisation, la réplication continue vers le volume de destination réel.

Bien que techniquement possible, cette configuration n’est pas recommandée en raison du manque de reconnaissance des sites dans les nœuds de calcul qui contactent le SOFS. Si vous utilisez une mise en réseau à l’échelle du campus, où les temps de latence sont généralement inférieurs à la milliseconde, cette configuration fonctionne généralement sans problème.

Si vous configurez une réplication de cluster à cluster, le réplica de stockage prend entièrement en charge les serveurs de fichiers avec montée en puissance parallèle, notamment l’utilisation des espaces de stockage direct, lors de la réplication entre deux clusters.

Non. Vous pouvez répliquer avec CSV ou une réservation persistante de disque (PDR) appartenant à une ressource de cluster, comme un rôle de serveur de fichiers.

Si vous configurez une réplication de cluster à cluster, le réplica de stockage prend entièrement en charge les serveurs de fichiers avec montée en puissance parallèle, notamment l’utilisation des espaces de stockage direct, lors de la réplication entre deux clusters.

Cette configuration n’est pas prise en charge dans Windows Server. Cela peut changer dans une version ultérieure. Si vous configurez une réplication de cluster à cluster, le réplica de stockage prend entièrement en charge les serveurs de fichiers avec montée en puissance parallèle et les serveurs Hyper-V, notamment l’utilisation des espaces de stockage direct.

Spécifiez New-SRPartnership -ReplicationMode et indiquez l’argument Asynchronous. Par défaut, toute la réplication dans le réplica de stockage est synchrone. Vous pouvez également modifier le mode avec Set-SRPartnership -ReplicationMode.

Pour empêcher le basculement automatique, vous pouvez utiliser PowerShell pour configurer Get-ClusterNode -Name "NodeName").NodeWeight=0. Cette action supprime le vote sur chaque nœud dans le site de récupération d’urgence. Vous pouvez ensuite utiliser Start-ClusterNode -PreventQuorum sur les nœuds dans le site principal et Start-ClusterNode -ForceQuorum sur les nœuds dans le site de récupération d’urgence pour forcer le basculement. Il n’existe aucune option graphique pour empêcher le basculement automatique et cette action n’est en outre pas recommandée.

Pour empêcher l’exécution de la nouvelle fonctionnalité de résilience de la machine virtuelle Hyper-V et pour mettre par conséquent en pause les machines virtuelles au lieu de les basculer vers le site de récupération d’urgence, exécutez (Get-Cluster).ResiliencyDefaultPeriod=0

Vous pouvez utiliser un stockage alloué dynamiquement comme moyen d’accélérer les durées de synchronisation initiale. Le réplica de stockage recherche et utilise automatiquement le stockage alloué dynamiquement, notamment les espaces de stockage non cluster, les disques dynamiques Hyper-V et les LUN SAN. Une fois la réplication initiale lancée, le volume ne peut pas être réduit ni tronqué.

Vous pouvez également utiliser des volumes de données amorcés pour réduire l’utilisation de la bande passante et parfois le temps, en veillant à ce que le volume de destination possède un sous-ensemble des données du volume principal, puis en utilisant l’option Amorcé du Gestionnaire du cluster de basculement ou New-SRPartnership. Si le volume est pratiquement vide, l’utilisation de la synchronisation amorcée peut réduire le temps et l’utilisation de la bande passante. Il existe plusieurs façons d’amorcer des données, avec différents degrés d’efficacité :

• Réplication précédente : réplication avec une synchronisation initiale normale locale entre les nœuds contenant les disques et les volumes, suppression de la réplication, expédition des disques de destination ailleurs, puis ajout de la réplication avec l’option Amorcé. Il s’agit de la méthode la plus efficace, car le réplica de stockage garantit un miroir de copie de blocs et les blocs delta sont la seule chose à répliquer.
• Cliché instantané restauré ou sauvegarde basée sur un cliché instantané restauré : en restaurant un cliché instantané basé sur un volume sur le volume de destination, il doit y avoir des différences minimales dans la disposition en bloc. Il s’agit de la seconde méthode la plus efficace, car les blocs sont susceptibles de correspondre grâce aux clichés instantanés de volume étant des images miroirs.
• Fichiers copiés : en créant un volume sur la destination qui n’a jamais été utilisé auparavant et en effectuant une copie complète de l’arborescence robocopy/MIR des données, il est probable qu’il y ait des correspondances de blocs. L’utilisation de l’Explorateur de fichiers Windows ou la copie d’une partie de l’arborescence ne crée pas beaucoup de correspondances de blocs. La copie manuelle de fichiers est la méthode d’amorçage la moins efficace.

Vous pouvez utiliser l’applet de commande Grant-SRDelegation. Cela vous permet de définir des utilisateurs spécifiques dans des scénarios de réplication de serveur à serveur, de cluster à cluster et de cluster étendu comme ayant les autorisations de créer, modifier ou supprimer la réplication, sans être membres du groupe Administrateurs local. Par exemple :

Grant-SRDelegation -UserName contso\tonywang

L’applet de commande vous rappelle que l’utilisateur doit se déconnecter du serveur qu’il envisage de gérer, puis se reconnecter pour que la modification prenne effet. Vous pouvez utiliser Get-SRDelegation et Revoke-SRDelegation pour mieux contrôler cette opération.

Le réplica de stockage prend en charge la sauvegarde et la restauration du volume source. Il prend également en charge la création et la restauration d’instantanés du volume source. Vous ne pouvez pas sauvegarder ni restaurer le volume de destination tant qu’il est protégé par le réplica de stockage, car il n’est pas monté ni accessible. Si un incident survient et que le volume source est perdu, l’utilisation de Set-SRPartnership pour promouvoir le volume de destination précédent afin qu’il devienne une source accessible en lecture/écriture vous permet de sauvegarder ou restaurer ce volume. Vous pouvez également supprimer la réplication avec Remove-SRPartnership et Remove-SRGroup pour remonter ce volume comme accessible en lecture/écriture.

Pour créer des instantanés cohérents au niveau application réguliers, vous pouvez utiliser VSSADMIN. EXE sur le serveur source pour capturer les volumes de données répliqués. Par exemple, vous répliquez le volume F: avec le réplica de stockage :

vssadmin create shadow /for=F:

Ensuite, après avoir basculé le sens de la réplication ou supprimé la réplication, ou si vous restez toujours sur le même volume source, vous pouvez restaurer tout instantané à son point dans le temps. Par exemple, en utilisant toujours F: :

vssadmin list shadows
vssadmin revert shadow /shadow={shadown copy ID GUID listed previously}

Vous pouvez également prévoir une exécution régulière de cet outil à l’aide d’une tâche planifiée. Pour plus d’informations sur l’utilisation de VSS, voir Vssadmin. Il est inutile et sans intérêt de sauvegarder les volumes de journaux. Une telle tentative sera ignorée par VSS.

L’utilisation de la sauvegarde Windows Server, de la sauvegarde Microsoft Azure, de Microsoft DPM, d’un autre instantané, de VSS, de la machine virtuelle ou des technologies basées sur des fichiers est prise en charge par le réplica de stockage tant que ces outils fonctionnent au niveau de la couche du volume. Le réplica de stockage ne prend pas en charge la sauvegarde et la restauration basées sur des blocs.

Le réplica de stockage s’appuie sur SMB et WSMAN pour sa réplication et sa gestion. Cela signifie que les ports suivants sont requis :

• 445 (SMB : protocole de transport de réplication, protocole de gestion RPC de cluster)
• 5445 (iWARP SMB : nécessaire uniquement lors de l’utilisation de la mise en réseau iWARP RDMA)
• 5985 (WSManHTTP : protocole de gestion pour WMI/CIM/PowerShell)

La taille optimale du journal varie considérablement selon l’environnement et la charge de travail, et est déterminée par la quantité d’E/S d’écriture effectuées par votre charge de travail.

• Un journal plus grand ou plus petit ne vous rend pas plus rapide ou plus lent
• Un journal plus grand ou plus petit n’a aucune incidence sur un volume de données de 10 Go par rapport à un volume de données de 10 To, par exemple

Un journal plus volumineux collecte et conserve simplement plus d’E/S d’écriture avant qu’elles ne soient encapsulées. Cela permet à une interruption de service entre l’ordinateur source et l’ordinateur de destination (par exemple, une panne réseau ou une destination hors connexion) de s’allonger. Si le journal peut contenir 10 heures d’écritures et que le réseau tombe en panne pendant 2 heures, lorsque le réseau est rétabli, la source peut simplement lire très rapidement le delta des modifications non synchronisées vers la destination et vous êtes à nouveau protégé très rapidement. Si le journal contient 10 heures et que la panne est de 2 jours, la source doit alors lire à partir d’un autre journal appelé bitmap et sera probablement plus lente pour se synchroniser. Une fois la synchronisation rétablie, la source utilise à nouveau le journal.

Le réplica de stockage s’appuie sur le journal pour toutes les performances d’écriture. Les performances des journaux sont essentielles aux performances de réplication. Vous devez vous assurer que le volume de journal fonctionne mieux que le volume de données, car le journal sérialise et séquentialise toutes les E/S d’écriture. Vous devez toujours utiliser des supports flash comme SSD sur les volumes de journaux. Vous ne devez jamais autoriser d’autres charges de travail à s’exécuter sur le volume de journal, de la même façon que vous n’autoriseriez jamais d’autres charges de travail à s’exécuter sur des volumes de journaux de base de données SQL.

Là encore, Microsoft recommande vivement que le stockage des journaux soit plus rapide que le stockage de données et que les volumes de journaux ne soient jamais utilisés pour d’autres charges de travail.

Vous pouvez obtenir des recommandations de dimensionnement des journaux en exécutant l’outil Test-SRTopology. Vous pouvez également utiliser des compteurs de performances sur des serveurs existants pour juger de la taille du journal. La formule est simple : surveillez le débit du disque de données (octets d’écriture moyenne/s) sous la charge de travail et utilisez-le pour calculer le temps nécessaire pour remplir le journal de différentes tailles. Par exemple, le débit du disque de données de 50 Mo/s entraîne l’encapsulation du journal de 120 Go/50 Mo en secondes, soit 2 400 secondes ou 40 minutes. Par conséquent, la durée pendant laquelle le serveur de destination peut être inaccessible avant que le journal soit encapsulé est de 40 minutes. Si le journal est encapsulé, mais que la destination redevient accessible, la source relit les blocs via le journal de mappage de bits au lieu du journal principal. La taille du journal n’a pas d’effet sur les performances.

SEUL le disque de données du cluster source doit être sauvegardé. Les disques journaux du réplica de stockage ne doivent PAS être sauvegardés, car une sauvegarde peut entrer en conflit avec les opérations du réplica de stockage.

Le réplica de stockage est disponible en trois configurations principales : cluster étendu, cluster à cluster et serveur à serveur. Chacune présente différents avantages.

La topologie de cluster étendu est idéale pour les charges de travail nécessitant un basculement automatique avec orchestration, comme les clusters de cloud privé Hyper-V et ICF SQL Server. Elle dispose également d’une interface graphique intégrée à l’aide du Gestionnaire du cluster de basculement. Elle utilise l’architecture classique de stockage partagé de cluster asymétrique des espaces de stockage, SAN, iSCSI et RAID via une réservation persistante. Vous pouvez l’exécuter avec seulement 2 nœuds.

La topologie de cluster à cluster utilise deux clusters distincts et est idéale pour les administrateurs qui souhaitent un basculement manuel, en particulier lorsque le deuxième site est approvisionné pour la récupération d’urgence et non pour une utilisation quotidienne. L’orchestration est manuelle. Contrairement au cluster étendu, les espaces de stockage direct peuvent être utilisés dans cette configuration (avec des mises en garde ; consultez les FAQ sur le réplica de stockage et la documentation de cluster à cluster). Vous pouvez l’exécuter avec seulement 4 nœuds.

La topologie de serveur à serveur est idéale pour les clients qui exécutent du matériel qui ne peut pas être en cluster. Elle nécessite un basculement et une orchestration manuels. Elle est idéale pour les déploiements peu coûteux entre des filiales et des centres de données centraux, en particulier lors de l’utilisation de la réplication asynchrone. Cette configuration peut souvent remplacer des instances de serveurs de fichiers protégés par DFSR utilisées pour les scénarios de récupération d’urgence monomaître.

Dans tous les cas, les topologies prennent en charge à la fois l’exécution sur du matériel physique et sur des machines virtuelles. Dans les machines virtuelles, l’hyperviseur sous-jacent ne nécessite pas Hyper-V ; il peut s’agir de VMware, KVM, Xen, etc.

Le réplica de stockage dispose également d’un mode serveur à auto, dans lequel vous pointez la réplication vers deux volumes différents sur le même ordinateur.

Oui, la Déduplication des données est prise en charge avec le réplica de stockage. Activez la Déduplication des données sur un volume sur le serveur source pour que, pendant la réplication, le serveur de destination reçoive une copie dédupliquée du volume.

Bien que vous deviez installer la Déduplication des données sur les serveurs source et de destination (voir Installation et activation de la Déduplication des données), il est important de ne pas activer la Déduplication des données sur le serveur de destination. Le réplica de stockage autorise uniquement les écritures sur le serveur source. Étant donné que la Déduplication des données effectue des écritures dans le volume, elle doit s’exécuter uniquement sur le serveur source.

Malheureusement, nous ne prenons pas en charge la création d’un nouveau partenariat entre Windows Server 2019 et Windows Server 2016. Vous pouvez mettre à niveau en toute sécurité un serveur ou un cluster exécutant Windows Server 2016 vers Windows Server 2019 et tous les partenariats existants continueront de fonctionner.

Toutefois, pour obtenir des performances de réplication améliorées de Windows Server 2019, tous les membres du partenariat doivent exécuter Windows Server 2019 et vous devez supprimer les partenariats existants et les groupes de réplication associés, puis les recréer avec des données amorcées (lors de la création du partenariat dans Windows Admin Center ou avec l’applet de commande New-SRPartnership).

Pour obtenir une assistance technique sur le réplica de stockage, publiez un message sur les forums Microsoft. Vous pouvez également envoyer un e-mail à srfeed@microsoft.com si vous avez des questions sur le réplica de stockage. Pour les problèmes liés à cette documentation, consultez la section Commentaires en bas de cette page, puis sélectionnez Cette page.

Le réplica de stockage est une technologie de réplication unidirectionnelle. Cette technologie ne réplique que de la source vers la destination pour chaque volume. Ce sens peut être inversé à tout moment, mais cette technologie reste unidirectionnelle. Toutefois, cela ne signifie pas que vous ne pouvez pas avoir un ensemble de volumes (source et destination) répliqué dans un sens et un autre ensemble de lecteurs (source et destination) répliqué dans le sens inverse. Par exemple, vous souhaitez que la réplication de serveur à serveur soit configurée. Serveur1 et Serveur2 ont chacun des lettres de lecteur L:, M:, N:, et O: et vous souhaitez répliquer le lecteur M: du Serveur1 vers le Serveur2, mais le lecteur O: du Serveur2 au Serveur1. Cela peut être effectué tant qu’il existe des lecteurs de journaux distincts pour chacun des groupes. c’est-à-dire,

• Lecteur source M: du Serveur1 avec lecteur de journal source L: répliqué sur le lecteur de destination M: du Serveur2 avec le lecteur de journal de destination L:
• Lecteur source O: du Serveur2 avec lecteur de journal source N: répliqué sur le lecteur de destination O: du Serveur1 avec le lecteur de journal de destination N:

Le réplica de stockage empêche les disques de cluster de passer en mode maintenance. Pour les tâches telles que l’activation ou la désactivation de Bitlocker, les disques doivent être en mode maintenance. Pour effectuer des tâches qui nécessitent que les disques soient en mode maintenance, le partenariat doit d’abord être rompu et créé à nouveau une fois terminé.

• Vue d’ensemble du réplica de stockage
• Réplication de cluster étendu à l’aide d’un stockage partagé
• Réplication de stockage de serveur à serveur
• Réplication de stockage de cluster à cluster
• Réplica de stockage : problèmes connus

• Vue d’ensemble du stockage
• Espaces de stockage direct