記憶域レプリカについてよく寄せられる質問Frequently Asked Questions about Storage Replica

適用先:Windows Server 2019、Windows Server 2016、Windows Server (半期チャネル)Applies to: Windows Server 2019, Windows Server 2016, Windows Server (Semi-Annual Channel)

このトピックには、記憶域レプリカに関してよく寄せられる質問 (FAQ) に対する回答が含まれています。This topic contains answers to frequently asked questions (FAQs) about Storage Replica.

ストレージレプリカは Azure でサポートされていますか?Is Storage Replica supported on Azure?

はい。Yes. Azure では、次のシナリオを使用できます。You can use the following scenarios with Azure:

  1. Azure 内のサーバー間のレプリケーション (1 つまたは2つのデータセンターの障害ドメインにある IaaS Vm 間で同期的または非同期的に、または2つの異なるリージョン間で非同期的に)Server-to-server replication inside Azure (synchronously or asynchronously between IaaS VMs in one or two datacenter fault domains, or asynchronously between two separate regions)
  2. Azure とオンプレミス間のサーバー間の非同期レプリケーション (VPN または Azure ExpressRoute を使用)Server-to-server asynchronous replication between Azure and on-premises (using VPN or Azure ExpressRoute)
  3. Azure 内のクラスター間のレプリケーション (1 つまたは2つのデータセンターの障害ドメインにある IaaS Vm 間で同期的または非同期的に、または2つの異なるリージョン間で非同期的に)Cluster-to-cluster replication inside Azure (synchronously or asynchronously between IaaS VMs in one or two datacenter fault domains, or asynchronously between two separate regions)
  4. Azure とオンプレミス (VPN または Azure ExpressRoute を使用) 間のクラスター間非同期レプリケーションCluster-to-cluster asynchronous replication between Azure and on-premises (using VPN or Azure ExpressRoute)

Azure でのゲストクラスタリングに関するその他の注意事項については 、「Microsoft Azure での IAAS VM ゲストクラスターのデプロイ」を参照してください。Further notes on guest clustering in Azure can be found at: Deploying IaaS VM Guest Clusters in Microsoft Azure.

重要:Important notes:

  1. Azure では、共有 VHDX ゲストクラスタリングがサポートされていないため、Windows フェールオーバークラスターの仮想マシンでは、従来の共有記憶域の永続的なディスク予約クラスタリングまたは記憶域スペースダイレクトに iSCSI ターゲットを使用する必要があります。Azure doesn't support shared VHDX guest clustering, so Windows Failover Cluster virtual machines must use iSCSI targets for classic shared-storage persistent disk reservation clustering or Storage Spaces Direct.
  2. 記憶域スペースダイレクトベースの記憶域レプリカのクラスター化には Azure Resource Manager テンプレートがあります。「 Create a 記憶域スペースダイレクト SOFS クラスターと Azure リージョン間でのディザスターリカバリーのための記憶域レプリカを作成する」をご覧ください。There are Azure Resource Manager templates for Storage Spaces Direct-based Storage Replica clustering at Create a Storage Spaces Direct SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions.
  3. クラスターからクラスターへの RPC 通信 (クラスター間のアクセスを許可するためにクラスター Api によって必要) では、CNO に対してネットワークアクセスを構成する必要があります。Cluster to cluster RPC communication in Azure (required by the cluster APIs for granting access between cluster) requires configuring network access for the CNO. Tcp ポート135と TCP ポート49152を超える動的範囲を許可する必要があります。You must allow TCP port 135 and the dynamic range above TCP port 49152. AZURE IAAS VM での Windows Server フェールオーバークラスターの構築に関するリファレンス-第2部のネットワークと作成Reference Building Windows Server Failover Cluster on Azure IAAS VM – Part 2 Network and Creation.
  4. 2ノードのゲストクラスターを使用できます。各ノードでは、記憶域レプリカによってレプリケートされた非対称クラスターにループバック iSCSI を使用します。It's possible to use two-node guest clusters, where each node is using loopback iSCSI for an asymmetric cluster replicated by Storage Replica. しかし、この方法はパフォーマンスが非常に低く、ワークロードやテストが非常に限られている場合にのみ使用してください。But this will likely have very poor performance and should be used only for very limited workloads or testing.

初期同期中にレプリケーションの進行状況を操作方法確認するにはHow do I see the progress of replication during initial sync?

レプリケーション先のサーバーの記憶域レプリカの管理者イベント ログに表示される Event 1237 メッセージに、コピーされたバイト数および残りのバイト数が 10 秒間隔で表示されます。The Event 1237 messages shown in the Storage Replica Admin even log on the destination server show number of bytes copied and bytes remaining every 10 seconds. 1 つまたは複数のレプリケートされたボリュームに対して \Storage Replica Statistics\Total Bytes Received が表示されるレプリケーション先で、記憶域レプリカのパフォーマンス カウンターを使用することもできます。You can also use the Storage Replica performance counter on the destination showing \Storage Replica Statistics\Total Bytes Received for one or more replicated volumes. Windows PowerShell を使用して、レプリケーション グループをクエリすることもできます。You can also query the replication group using Windows PowerShell. たとえば、このサンプル コマンドはレプリケーション先にあるグループの名前を取得し、Replication 2 という名前の 1 つのグループをクエリして、10 秒間隔で進行状況を表示します。For instance, this sample command gets the name of the groups on the destination then queries one group named Replication 2 every 10 seconds to show progress:

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

レプリケーションに特定のネットワーク インターフェイスが使用されるように指定できますか。Can I specify specific network interfaces to be used for replication?

はい、Set-SRNetworkConstraint を使用して指定できます。Yes, using Set-SRNetworkConstraint. このコマンドレットはインターフェイス層で動作し、クラスター シナリオおよび非クラスター シナリオの両方で使用されます。This cmdlet operates at the interface layer and be used on both cluster and non-cluster scenarios. たとえば、(各ノード上の) スタンドアロン サーバーでは次のコマンドを実行します。For example, with a standalone server (on each node):

Get-SRPartnership

Get-NetIPConfiguration

(両方のサーバーの) ゲートウェイとインターフェイスの情報およびパートナーシップの方向に注意してください。Note the gateway and interface information (on both servers) and the partnership directions. 次に、次のコマンドを実行します。Then run:

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

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

ストレッチ クラスター上でネットワークの制約を構成するには、次のコマンドを実行します。For configuring network constraints on a stretch cluster:

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"

1対多のレプリケーションまたは推移的 (A から B から C) へのレプリケーションを構成できますか。Can I configure one-to-many replication or transitive (A to B to C) replication?

いいえ。記憶域レプリカは、サーバー、クラスター、またはストレッチクラスターノードの1対1のレプリケーションのみをサポートします。No, Storage Replica supports only one to one replication of a server, cluster, or stretch cluster node. これは、今後のリリースで変更される可能性があります。This may change in a later release. 当然ながら、各種サーバーの特定のボリューム ペアを、方向を指定してレプリケーションするよう構成することはできます。You can of course configure replication between various servers of a specific volume pair, in either direction. たとえば、サーバー 1 の D ボリュームをサーバー 2 に、E ボリュームをサーバー 3 からレプリケートできます。For instance, Server 1 can replicate its D volume to server 2, and its E volume from Server 3.

記憶域レプリカによってレプリケートされたボリュームを拡大または圧縮することはできますか?Can I grow or shrink replicated volumes replicated by Storage Replica?

ボリュームは、拡大 (拡張) できますが、圧縮できません。You can grow (extend) volumes, but not shrink them. 既定では、記憶域レプリカを使うと管理者はレプリケートされたボリュームを拡張できません。サイズ変更前に、ソース グループで Set-SRGroup -AllowVolumeResize $TRUE オプションを使ってください。By default, Storage Replica prevents administrators from extending replicated volumes; use the Set-SRGroup -AllowVolumeResize $TRUE option on the source group, prior to resizing. 次に例を示します。For example:

  1. ソースコンピューターに対して使用する: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUEUse against the source computer: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
  2. 希望する方法を使ってボリュームを拡大するGrow the volume using whatever technique you prefer
  3. ソースコンピューターに対して使用する: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSEUse against the source computer: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

読み取り専用アクセスでレプリケーション先のボリュームをオンラインで取り込むことはできますか。Can I bring a destination volume online for read-only access?

Windows Server 2016 では構成できません。Not in Windows Server 2016. 記憶域レプリカは、レプリケーションが開始されると宛先ボリュームをマウント解除します。Storage Replica dismounts the destination volume when replication begins.

ただし、バージョン1709以降の Windows Server 2019 および Windows Server Semi-Annual チャネルでは、移行先ストレージをマウントするオプションが使用できるようになりました。この機能は "テストフェールオーバー" と呼ばれます。However, in Windows Server 2019 and Windows Server Semi-Annual Channel starting with version, 1709, the option to mount the destination storage is now possible - this feature is called "Test Failover". これを実行するには、現在、宛先でレプリケートされていない、未使用の、NTFS または ReFS でフォーマットされたボリュームが必要です。To do this, you must have an unused, NTFS or ReFS formatted volume that is not currently replicating on the destination. 次に、レプリケートされた記憶域のスナップショットを、テストやバックアップの目的で、一時的にマウントすることができます。Then you can mount a snapshot of the replicated storage temporarily for testing or backup purposes.

たとえば、宛先サーバー "SRV2" のレプリケーション グループ "RG2" 内にボリューム "D:" をレプリケートしており、SRV2 にレプリケートされていない "T:" ドライブがある場合に、テスト フェールオーバーを作成するには、次の操作を実行します。For example, to create a test failover where you are replicating a volume "D:" in the Replication Group "RG2" on the destination server "SRV2" and have a "T:" drive on SRV2 that is not being replicated:

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

レプリケートされたボリューム D: は SRV2 でアクセスできるようになります。The replicated volume D: is now accessible on SRV2. このファイルに対して読み取りと書き込みを行ったり、ファイルをコピーしたり、安全のために別の場所に保存されているオンラインバックアップを実行したりできます。You can read and write to it normally, copy files off it, or run an online backup that you save elsewhere for safekeeping, under the D: path. T: ボリュームにはログデータのみが含まれます。The T: volume will only contain log data.

テスト フェールオーバーのスナップショットを削除してその変更を破棄するには:To remove the test failover snapshot and discard its changes:

Dismount-SRDestination -Name RG2 -Computername SRV2

テスト フェールオーバー機能は、短期的な一時的な操作としてのみ使用する必要があります。You should only use the test failover feature for short-term temporary operations. 長期的に使用するための機能ではありません。It is not intended for long term usage. 使用中の場合、レプリケーションは実際の宛先ボリュームまで継続されます。When in use, replication continues to the real destination volume.

ストレッチクラスターでスケールアウトファイルサーバー (SOFS) を構成できますか。Can I configure Scale-out File Server (SOFS) in a stretch cluster?

技術的には可能ですが、SOFS に接続するコンピューティングノードにサイト認識がないため、これは推奨される構成ではありません。While technically possible, this is not a recommended configuration due to the lack of site awareness in the compute nodes contacting the SOFS. 通常、待機時間がサブミリ秒になるキャンパス距離ネットワークを使用している場合、この構成は問題なく動作します。If using campus-distance networking, where latencies are typically sub-millisecond, this configuration typically works without issues.

クラスター間のレプリケーションを構成している場合、記憶域レプリカは、2 つの記憶域クラスター間でのレプリケート中の記憶域スペース ダイレクトの使用も含め、スケールアウト ファイル サーバーを完全にサポートします。If configuring cluster-to-cluster replication, Storage Replica fully supports Scale-out File Servers, including the use of Storage Spaces Direct, when replicating between two clusters.

CSV は、ストレッチクラスター内またはクラスター間でレプリケートする必要がありますか。Is CSV required to replicate in a stretch cluster or between clusters?

いいえ。No. ファイルサーバーの役割など、クラスターリソースによって所有されている CSV または永続的なディスク予約 (民主共和国) を使用してレプリケートできます。You can replicate with CSV or persistent disk reservation (PDR) owned by a cluster resource, such as a File Server role.

クラスター間のレプリケーションを構成している場合、記憶域レプリカは、2 つの記憶域クラスター間でのレプリケート中の記憶域スペース ダイレクトの使用も含め、スケールアウト ファイル サーバーを完全にサポートします。If configuring cluster-to-cluster replication, Storage Replica fully supports Scale-out File Servers, including the use of Storage Spaces Direct, when replicating between two clusters.

記憶域レプリカを使用したストレッチ クラスターで記憶域スペース ダイレクトを構成することはできますか。Can I configure Storage Spaces Direct in a stretch cluster with Storage Replica?

これは、Windows Server でサポートされている構成ではありません。This is not a supported configuration in Windows Server. これは、今後のリリースで変更される可能性があります。This may change in a later release. クラスター間のレプリケーションを構成している場合、記憶域レプリカは、記憶域スペース ダイレクトの使用も含め、スケールアウト ファイル サーバーと Hyper-V Server を完全にサポートします。If configuring cluster-to-cluster replication, Storage Replica fully supports Scale Out File Servers and Hyper-V Servers, including the use of Storage Spaces Direct.

非同期レプリケーションを構成するにはどうすればよいですか。How do I configure asynchronous replication?

New-SRPartnership -ReplicationMode を指定して引数 Asynchronous を入力します。Specify New-SRPartnership -ReplicationMode and provide argument Asynchronous. 既定では、記憶域レプリカのすべてのレプリケーションは同期です。By default, all replication in Storage Replica is synchronous. Set-SRPartnership -ReplicationMode でモードを変更することもできます。You can also change the mode with Set-SRPartnership -ReplicationMode.

ストレッチ クラスターの自動フェールオーバーを回避するにはどうすればよいですか。How do I prevent automatic failover of a stretch cluster?

自動フェールオーバーを回避するには、PowerShell を使用して Get-ClusterNode -Name "NodeName").NodeWeight=0 を構成します。To prevent automatic failover, you can use PowerShell to configure Get-ClusterNode -Name "NodeName").NodeWeight=0. これにより、障害復旧サイト内の各ノードの票が削除されます。This removes the vote on each node in the disaster recovery site. その後、プライマリ サイト内のノードの Start-ClusterNode -PreventQuorum および障害サイト内のノードの Start-ClusterNode -ForceQuorum を使用して、フェールオーバーを強制することができます。Then you can use Start-ClusterNode -PreventQuorum on nodes in the primary site and Start-ClusterNode -ForceQuorum on nodes in the disaster site to force failover. 自動フェールオーバーを防止するためのグラフィカルなオプションはなく、自動フェールオーバーの防止は推奨されません。There is no graphical option for preventing automatic failover, and preventing automatic failover is not recommended.

仮想マシンの回復性を無効にするにはどうすればよいですか。How do I disable virtual machine resiliency?

新しい Hyper-v 仮想マシンの回復性機能が実行されないようにして、障害復旧サイトにフェールオーバーするのではなく、仮想マシンを一時停止するには、を実行します。 (Get-Cluster).ResiliencyDefaultPeriod=0To prevent the new Hyper-V virtual machine resiliency feature from running and therefore pausing virtual machines instead of failing them over to the disaster recovery site, run (Get-Cluster).ResiliencyDefaultPeriod=0

初期同期にかかる時間を短縮するにはどうすればよいですか。How can I reduce time for initial synchronization?

初期同期の間を短縮する 1 つの方法として、仮想プロビジョニングされた記憶域を使用できます。You can use thin-provisioned storage as one way to speed up initial sync times. 記憶域レプリカは、クエリを実行し、非クラスター化記憶域スペース、Hyper-V の動的ディスク、SAN LUN を含む、仮想プロビジョニングされたストレージを自動的に使用します。Storage Replica queries for and automatically uses thin-provisioned storage, including non-clustered Storage Spaces, Hyper-V dynamic disks, and SAN LUNs.

シードされたデータボリュームを使用して、帯域幅の使用量を減らし、場合によっては、宛先ボリュームがプライマリからのデータの一部を保持し、フェールオーバークラスターマネージャーまたはのシードオプションを使用するようにすることもできます New-SRPartnershipYou can also use seeded data volumes to reduce bandwidth usage and sometimes time, by ensuring that the destination volume has some subset of data from the primary then using the Seeded option in Failover Cluster Manager or New-SRPartnership. ボリュームがほぼ空の場合は、シード同期を使用すると、時間と使用帯域幅を低減できます。If the volume is mostly empty, using seeded sync may reduce time and bandwidth usage. さまざまな程度の意味でデータをシード処理する方法は複数あります。There are multiple ways to seed data, with varying degrees of efficacy:

  1. 以前のレプリケーション-ディスクとボリュームを含むノード間で通常の初期同期をローカルにレプリケートすることにより、レプリケーションを削除し、別の場所に宛先ディスクを配布してから、シードオプションを使用してレプリケーションを追加します。Previous replication - by replicating with normal initial sync locally between nodes containing the disks and volumes, removing replication, shipping the destination disks elsewhere, then adding replication with the seeded option. これは、記憶域レプリカがブロックコピーミラーを保証し、レプリケートするのがデルタブロックだけである場合に最も効果的な方法です。This is the most effective method as Storage Replica guaranteed a block-copy mirror and the only thing to replicate is delta blocks.
  2. スナップショットの復元またはスナップショットベースのバックアップの復元-ボリュームベースのスナップショットをターゲットボリュームに復元することにより、ブロックレイアウトの違いが最小限に抑えられます。Restored snapshot or restored snapshot-based backup - by restoring a volume-based snapshot onto the destination volume, there should be minimal differences in the block layout. これは、ボリュームスナップショットがミラー化されているためにブロックが一致する可能性が高いため、次の最も効果的な方法です。This is the next most effective method as blocks are likely to match thanks to volume snapshots being mirror images.
  3. コピーされたファイル-転送先に使用されていない新しいボリュームを作成し、データの完全な robocopy/MIR ツリーコピーを実行することで、ブロック一致が発生する可能性があります。Copied files - by creating a new volume on the destination that has never been used before and performing a full robocopy /MIR tree copy of the data, there are likely to be block matches. Windows エクスプローラーを使用したり、ツリーの一部をコピーしたりしても、多くのブロック一致は作成されません。Using Windows File Explorer or copying some portion of the tree will not create many block matches. ファイルの手動コピーは、シード処理の最も効果的な方法です。Copying files manually is the least effective method of seeding.

レプリケーションを管理するユーザーを委任できますか。Can I delegate users to administer replication?

コマンドレットを使用でき Grant-SRDelegation ます。You can use the Grant-SRDelegation cmdlet. これにより、サーバー間、クラスター間で特定のユーザーを設定して、クラスターのレプリケーション シナリオを、ローカルの管理者グループのメンバーにならずにレプリケーションを作成、変更、削除する権限が付与されているとして拡張することができます。This allows you to set specific users in server to server, cluster to cluster, and stretch cluster replication scenarios as having the permissions to create, modify, or remove replication, without being a member of the local administrators group. 次に例を示します。For example:

Grant-SRDelegation -UserName contso\tonywang

このコマンドレットは、変更が有効になるように、管理しようと計画しているサーバーからユーザーがログオフおよびログオンする必要があることを通知します。The cmdlet will remind you that the user needs to log off and on of the server they are planning to administer in order for the change to take effect. Get-SRDelegationRevoke-SRDelegation を使用して、さらにこれを制御できます。You can use Get-SRDelegation and Revoke-SRDelegation to further control this.

レプリケートされたボリュームのバックアップと復元のオプションは何ですか。What are my backup and restore options for replicated volumes?

記憶域レプリカは、ソース ボリュームのバックアップと復元をサポートします。Storage Replica supports backing up and restoring the source volume. さらに、ソース ボリュームのスナップショットの作成と復元もサポートします。It also supports creating and restoring snapshots of the source volume. 記憶域レプリカによって保護されている間はマウントもアクセスもできないため、レプリケーション先のボリュームをバックアップまたは復元することはできません。You cannot backup or restore the destination volume while protected by Storage Replica, as it is not mounted nor accessible. ソース ボリュームが失われる障害が発生した場合、Set-SRPartnership を使用して以前のレプリケーション先ボリュームを昇格します。読み取りと書き込みが可能になったソースによって、失われたソース ボリュームをバックアップまたは復元できるようになります。If you experience a disaster where the source volume is lost, using Set-SRPartnership to promote the previous destination volume to now be a read/writable source will allow you to backup or restore that volume. Remove-SRPartnershipRemove-SRGroup を使用して、このボリュームを読み取りと書き込みが可能なボリュームとして再マウントすることもできます。You can also remove replication with Remove-SRPartnership and Remove-SRGroup to remount that volume as read/writable.

アプリケーション整合性のスナップショットを定期的に作成するために、ソース サーバーで VSSADMIN.EXE を使用して、レプリケートされたデータ ボリュームのスナップショットを作成できます。To create periodic application consistent snapshots, you can use VSSADMIN.EXE on the source server to snapshot replicated data volumes. たとえば、F: ボリュームを記憶域レプリカでレプリケートしている場合は次のようになります。For example, where you are replicating the F: volume with Storage Replica:

vssadmin create shadow /for=F:

その後、レプリケーションの方向を切り替えた後、レプリケーションを削除した後、または同じソース ボリューム上にいる場合、任意のスナップショットをその時点に復元できます。Then, after you switch replication direction, remove replication, or are simply still on the same source volume, you can restore any snapshot to its point in time. たとえば、依然として F: を使用している場合は次のようになります。For example, still using F:

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

スケジュールされたタスクを使用して、このツールが定期的に実行されるようにスケジュールすることもできます。You can also schedule this tool to run periodically using a scheduled task. VSS の使用方法の詳細については、Vssadmin を確認してください。For more information on using VSS, review Vssadmin. ログ ボリュームのバックアップは不要であり、行う価値もありません。There is no need or value in backing up the log volumes. バックアップしようとすると、VSS によって無視されます。Attempting to do so will be ignored by VSS.

Windows Server バックアップ、Microsoft Azure Backup、Microsoft DPM、またはその他のスナップショット、VSS、仮想マシン、またはファイルベースのテクノロジの使用は、ボリューム層内で動作する限り、記憶域レプリカでサポートされます。Use of Windows Server Backup, Microsoft Azure Backup, Microsoft DPM, or other snapshot, VSS, virtual machine, or file-based technologies are supported by Storage Replica as long as they operate within the volume layer. 記憶域レプリカは、ブロックベースのバックアップと復元はサポートしません。Storage Replica does not support block-based backup and restore.

記憶域レプリカに必要なネットワーク ポートを教えてください。What network ports does Storage Replica require?

記憶域レプリカは、レプリケーションと管理において SMB と WSMAN を利用します。Storage Replica relies on SMB and WSMAN for its replication and management. つまり、次のポートが必要です。This means the following ports are required:

  • 445 (SMB レプリケーショントランスポートプロトコル、クラスター RPC 管理プロトコル)445 (SMB - replication transport protocol, cluster RPC management protocol)
  • 5445 (iWARP SMB-iWARP RDMA ネットワークを使用する場合にのみ必要)5445 (iWARP SMB - only needed when using iWARP RDMA networking)
  • 5985 (WMI/CIM/PowerShell の WSManHTTP 管理プロトコル)5985 (WSManHTTP - Management protocol for WMI/CIM/PowerShell)

!付箋Test-SRTopology コマンドレットでは、ICMPv4/ICMPv6 が必要ですが、レプリケーションまたは管理には必要ありません。![NOTE] The Test-SRTopology cmdlet requires ICMPv4/ICMPv6, but not for replication or management.

ログ ボリュームのベスト プラクティスについて教えてください。What are the log volume best practices?

ログの最適なサイズは環境やワークロードごとに大きく異なり、ワークロードが実行する書き込み IO の量によって決まります。The optimal size of the log varies widely per environment and workload, and is determined by how much write IO your workload performs.

  1. ログのサイズを大きくしたり小さくしたりしても、高速または低速になることはありません。A larger or smaller log doesn't make you any faster or slower
  2. たとえば、サイズの大きいログまたは小さいログには、10 GB のデータボリュームと 10 TB データボリュームに対する影響はありません。A larger or smaller log doesn't have any bearing on a 10GB data volume versus a 10TB data volume, for instance

サイズの大きいログは、単純に、一杯になるまでに多くの書き込み IO を収集して保持できます。これにより、ログのソースと保存先コンピューターの間での、長時間にわたるサービス中断に対処できます (ネットワークの切断や保存先コンピューターのオフラインなど)。A larger log simply collects and retains more write IOs before they are wrapped out. This allows an interruption in service between the source and destination computer – such as a network outage or the destination being offline - to go longer. ログが 10 時間分の書き込みを保持できる場合、ネットワークが 2 時間ダウンしても、ネットワークの復旧時にソース側から保存先に対して同期されていない変更の差分を素早く同期すれば、短時間で保護された状態に回復します。If the log can hold 10 hours of writes, and the network goes down for 2 hours, when the network returns the source can simply play the delta of unsynced changes back to the destination very fast and you are protected again very quickly. しかし保持されるログが 10 時間分である場合に、ネットワークが 2 日間ダウンすると、ソース側はビットマップと呼ばれる別のログから再生する必要があるため、同期状態への回復に時間がかかります。同期された後は、元どおりログを使用できます。If the log holds 10 hours and the outage is 2 days, the source now has to play back from a different log called the bitmap – and will likely be slower to get back into sync. Once in sync it returns to using the log.

記憶域レプリカのすべての書き込みパフォーマンスはログに依存します。Storage Replica relies on the log for all write performance. ログのパフォーマンスは、レプリケーションのパフォーマンスにとって重要です。Log performance critical to replication performance. ログ ボリュームには、ログではすべての書き込み IO がシリアル化、シーケンス化されるため、ログ ボリュームはデータ ボリュームよりも高速に動作するデバイスを使用する必要があります。You must ensure that the log volume performs better than the data volume, as the log will serialize and sequentialize all write IO. ログ ボリュームでは、常に SSD などのフラッシュ メディアを使う必要があります。You should always use flash media like SSD on log volumes. ログ ボリューム上では、他のワークロードの実行を絶対に許可しないでください。同様に、SQL データベースのログ ボリューム上で他のワークロードの実行を許可しないでください。You must never allow any other workloads to run on the log volume, the same way you would never allow other workloads to run on SQL database log volumes.

繰り返しますが、ログ ストレージには、データ ストレージよりも高速に動作するデバイスを使用することをお勧めします。またログ ボリュームは、絶対に他のワークロードに使用しないでくださいAgain: Microsoft strongly recommends that the log storage be faster than the data storage and that log volumes must never be used for other workloads.

Test-SRTopology ツールを実行することで、ログのサイズ変更に関する推奨事項を取得できます。You can get log sizing recommendations by running the Test-SRTopology tool. または、既存のサーバーでパフォーマンスカウンターを使用して、ログサイズを略しすることもできます。Alternatively, you can use performance counters on existing servers to make a log size judgement. この数式は単純です。ワークロードの下にあるデータディスクのスループット (1 秒あたりの平均書き込みバイト数) を監視し、それを使用して、さまざまなサイズのログがいっぱいになるまでの時間を計算します。The formula is simple: monitor the data disk throughput (Avg Write Bytes/Sec) under the workload and use it to calculate the amount of time it will take to fill up the log of different sizes. たとえば、50 MB/秒のデータディスクスループットによって、120GB のログが 120GB/50 MB 秒または2400秒または40分でラップされます。For example, data disk throughput of 50 MB/s will cause the log of 120GB to wrap in 120GB/50MB seconds or 2400 seconds or 40 minutes. そのため、転送されるログが40分になるまで、宛先サーバーに到達できない時間があります。So the amount of time that the destination server could be unreachable before the log wrapped is 40 minutes. ログがラップされているにもかかわらず、宛先が再び到達可能になると、ソースはメインログではなくビットマップログを使用してブロックを再生します。If the log wraps but the destination becomes reachable again, the source would replay blocks via the bit map log instead of the main log. ログのサイズがパフォーマンスに影響を与えることはありません。The size of the log does not have an effect on performance.

ソースクラスターのデータディスクのみをバックアップする必要があります。ONLY the Data disk from the Source cluster should be backed-up. バックアップが記憶域レプリカの操作と競合する可能性があるため、記憶域レプリカのログディスクをバックアップしないでください。The Storage Replica Log disks should NOT be backed-up since a backup can conflict with Storage Replica operations.

ストレッチ クラスター トポロジ、クラスター間トポロジ、クラスター サーバー トポロジを使い分ける方法について教えてください。Why would you choose a stretch cluster versus cluster-to-cluster versus server-to-server topology?

記憶域レプリカには、ストレッチクラスター、クラスターからクラスター、サーバー間の3つの主な構成があります。Storage Replica comes in three main configurations: stretch cluster, cluster-to-cluster, and server-to-server. それぞれの構成には、異なる利点があります。There are different advantages to each.

ストレッチ クラスター トポロジは、Hyper-V プライベート クラウド クラスターや SQL Server FCI など、オーケストレーションを使用した自動フェールオーバーを必要とするワークロードに最適です。The stretch cluster topology is ideal for workloads requiring automatic failover with orchestration, such as Hyper-V private cloud clusters and SQL Server FCI. また、フェールオーバー クラスター マネージャーを使用したグラフィカル インターフェイスが組み込まれています。It also has a built-in graphical interface using Failover Cluster Manager. このトポロジでは、永続的予約を介して、従来の非対称クラスター共有記憶域アーキテクチャである記憶域スペース、SAN、iSCSI、および RAID が使用されます。It utilizes the classic asymmetric cluster shared storage architecture of Storage Spaces, SAN, iSCSI, and RAID via persistent reservation. これは、2 ノード以上の構成で実行できます。You can run this with as few as 2 nodes.

クラスター間トポロジでは、2 つの独立したクラスターが使用されます。特に 2 番目のサイトが障害回復用にプロビジョニングされていて、日常的な用途に使用されず、手動のフェールオーバーを必要とする場合に最適です。The cluster-to-cluster topology uses two separate clusters and is ideal for administrators who want manual failover, especially when the second site is provisioned for disaster recovery and not everyday usage. オーケストレーションは手動で実行します。Orchestration is manual. ストレッチクラスターとは異なり、記憶域スペースダイレクトはこの構成で使用できます (注意点があります。記憶域レプリカに関する FAQ とクラスター間のドキュメントを参照してください)。Unlike stretch cluster, Storage Spaces Direct can be used in this configuration (with caveats - see the Storage Replica FAQ and cluster-to-cluster documentation). これは、4 ノード以上の構成で実行できます。You can run this with as few as four nodes.

サーバー間トポロジは、クラスター化できないハードウェアを実行しているユーザーに最適です。The server-to-server topology is ideal for customers running hardware that cannot be clustered. この構成では、手動によるフェールオーバーとオーケストレーションが必要です。It requires manual failover and orchestration. ブランチオフィスと中央データセンター (特に非同期レプリケーションを使用する場合) との間の安価なデプロイに最適です。It is ideal for inexpensive deployments between branch offices and central data centers, especially when using asynchronous replication. この構成では、多くの場合、単一マスター障害回復シナリオに使用される DFSR で保護されたファイル サーバーのインスタンスを置き換えることができます。This configuration can often replace instances of DFSR-protected File Servers used for single-master disaster recovery scenarios.

このトポロジは、すべての場合において、物理ハードウェアでの実行と仮想マシンでの実行の両方をサポートします。In all cases, the topologies support both running on physical hardware as well as virtual machines. 仮想マシンで使用する場合、基盤のハイパーバイザーは Hyper-V である必要はなく、VMware、KVM、Xen なども使用できます。When in virtual machines, the underlying hypervisor doesn't require Hyper-V; it can be VMware, KVM, Xen, etc.

記憶域レプリカには、同じコンピューター上の 2 つの異なるボリュームへのレプリケーションを指定するサーバー内モードも使用できます。Storage Replica also has a server-to-self mode, where you point replication to two different volumes on the same computer.

データ重複除去は記憶域レプリカでサポートされていますか?Is Data Deduplication supported with Storage Replica?

はい。データ Deduplcation、記憶域レプリカでサポートされています。Yes, Data Deduplcation is supported with Storage Replica. 移行元サーバーのボリュームでデータ重複除去を有効にすると、レプリケーション中に、移行先サーバーはボリュームの重複除去コピーを受け取ります。Enable Data Deduplication on a volume on the source server, and during replication the destination server receives a deduplicated copy of the volume.

移行元サーバーと移行先サーバーの両方にデータ重複除去を インストール する必要があります (「 データ重複除去のインストールと有効化」を参照してください)。移行先サーバーでデータ重複除去を 有効 にしないことが重要です。While you should install Data Deduplication on both the source and destination servers (see Installing and enabling Data Deduplication), it's important not to enable Data Deduplication on the destination server. 記憶域レプリカは、移行元サーバーでのみ書き込みを許可します。Storage Replica allows writes only on the source server. データ重複除去はボリュームへの書き込みを行うため、ソースサーバー上でのみ実行する必要があります。Because Data Deduplication makes writes to the volume, it should run only on the source server.

Windows Server 2019 と Windows Server 2016 の間でレプリケートできますか。Can I replicate between Windows Server 2019 and Windows Server 2016?

残念ながら、Windows Server 2019 と Windows Server 2016 の 新しい パートナーシップの作成はサポートされていません。Unfortunately, we don't support creating a new partnership between Windows Server 2019 and Windows Server 2016. Windows Server 2016 を実行しているサーバーまたはクラスターを Windows Server 2019 に安全にアップグレードすることができ、 既存 のパートナーシップは引き続き機能します。You can safely upgrade a server or cluster running Windows Server 2016 to Windows Server 2019 and any existing partnerships will continue to work.

ただし、Windows Server 2019 のレプリケーションパフォーマンスを向上させるには、パートナーシップのすべてのメンバーが Windows Server 2019 を実行している必要があります。また、既存のパートナーシップと関連するレプリケーショングループを削除し、シードされたデータを使用してそれらを再作成する必要があります (Windows 管理センターまたは New-SRPartnership コマンドレットでパートナーシップを作成するHowever, to get the improved replication performance of Windows Server 2019, all members of the partnership must run Windows Server 2019 and you must delete existing partnerships and associated replication groups and then recreate them with seeded data (either when creating the partnership in Windows Admin Center or with the New-SRPartnership cmdlet).

記憶域レプリカまたはこのガイドに関する問題を操作方法報告しますか?How do I report an issue with Storage Replica or this guide?

記憶域レプリカの技術的なサポートについては、 Microsoft フォーラムで投稿できます。For technical assistance with Storage Replica, you can post at the Microsoft forums. 記憶域レプリカに関する質問や、このドキュメントに関する問題は、srfeed@microsoft.com に電子メールを送信することもできます。You can also email srfeed@microsoft.com for questions on Storage Replica or issues with this documentation. Windows Server の一般フィードバックサイトは、お客様がアイデアに関するサポートとフィードバックを提供できるようにするため、設計変更要求に適しています。The Windows Server general feedback site is preferred for design change requests, as it allows your fellow customers to provide support and feedback for your ideas.

記憶域レプリカを双方向にレプリケートするように構成できますか。Can Storage Replica be configured to replicate in both directions?

記憶域レプリカは、一方向のレプリケーションテクノロジです。Storage Replica is a one-way replication technology. ソースから宛先へのレプリケートはボリュームごとに行われます。It will only replicate from the source to the destination on a per volume basis. この方向はいつでも元に戻すことができますが、常に一方向になります。This direction can be reversed at any time, but is still only in one direction. ただし、これは、一連のボリューム (コピー元と宛先) を一方向にレプリケートすることができず、別のドライブセット (ソースと宛先) が逆方向にレプリケートすることを意味するわけではありません。However, that does not mean you cannot have a set of volumes (source and destination) replicate in one direction and a different set of drives (source and destination) replicate in the opposite direction. たとえば、サーバー間のレプリケーションを構成する必要があるとします。For example, you have want to have server to server replication configured. Server1 と Server2 は、それぞれドライブ文字 L:、M:、N:、および O を持ち、ドライブ M: を Server1 から Server2 にレプリケートしますが、ドライブ O: Server2 から Server1 にレプリケートします。Server1 and Server2 each have drive letters L:, M:, N:, and O: and you wish to replicate drive M: from Server1 to Server2 but drive O: replicate from Server2 to Server1. これは、グループごとに個別のログドライブがある限り実行できます。This can be done as long as there separate log drives for each of the groups. つまり、I.E.

  • Server1 ソースドライブ M: コピー元のログドライブ L: Server2 宛先ドライブ M: 宛先ログドライブ L: を使用してレプリケートしています。Server1 source drive M: with source log drive L: replicating to Server2 destination drive M: with destination log drive L:
  • Server2 ソースドライブ O: ソースログドライブ N: 接続先のドライブ O: 宛先ログドライブ N: を使用してレプリケートしています。Server2 source drive O: with source log drive N: replicating to Server1 destination drive O: with destination log drive N:

参照See Also