SAN同期レプリケーションとSQLServer-0のRPOは可能ですか？
SQL Server 2012 SP2を使用しているが、AlwaysOn可用性グループを使用していないソリューションに取り組んでいます。これは、データベース間のトランザクションが原因であり、このシナリオでは機能しません。
注：これは私たちが話しているときに対処されていますが、私の問題の背景情報として追加されています。
HP 3PAR StoreServソリューションを使用して、SANを介したサイト間同期レプリケーションを取得しています。これにより、DRシナリオをクロスサイトで機能させることができるため、セカンダリにフェイルオーバーできます。
データが失われ、破損が発生する可能性があるシナリオがあるため、私の懸念はRPOが0であることにあります。たとえば、サイト間でリンクが切断された後、プライマリがダウンします。
私の質問は次のとおりです。
- SANは、同期が完了するまでI/Oへのデータ書き込みを拒否しますか？
OR
リンクが切断された場合、接続が復元されるまでSANバッファはブロックの変更を変更しますか？
TLログの書き込み中にリンクが切断され、DRが発生した場合、これは、潜在的に破損したTLがセカンダリサイトに書き込まれ、データが失われることを意味しませんか？データの損失は、プライマリがコミットできたが、セカンダリが同期できなかったためです。
ゼロのRPOは、スタック全体で保証されますか（SQL Server /メモリ/ネットワーク/ SAN/IO）？
HP 3PAR StorageServホワイトペーパーから： 要求の厳しい耐災害環境向けのレプリケーションソリューション 、6ページ：
同期レプリケーションソリューションの場合、ソリューションのRPOは常にゼロです。ただし、非同期レプリケーションソリューションの場合、RPOは常にゼロより大きくなります。非同期定期モードは非同期レプリケーションです。その結果、非同期定期レプリケーションを使用するソリューションを設計する場合、RPOが問題になります。
SANは、許容誤差が0のRPOを保証するため、ネットワークが停止したときに、SANは、変更がI/O？
更新：
上記のリファレンスの12ページにこの情報があります。
同期長距離トポロジ
リモートコピー同期長距離（SLD）トポロジは、リモートコピーボリュームグループ内のボリュームを1つのソースStoreServアレイから2つの異なるターゲットStoreServアレイに複製できるようにする現在サポートされている唯一のトポロジです。これは、2つのStoreServアレイ（「ソース」アレイと「同期ターゲット」アレイ）間でデータを同期的に複製すると同時に、定期非同期モードを介して同じデータを3番目のStoreServアレイ、ディザスタリカバリまたは「非同期ターゲット」アレイに複製することによって行われます。ユーザーは、2つの同期アレイをアクティブ-アクティブな方法で処理し、データセンターでの障害によりフェイルオーバーが必要な場合にそれらの間でフェイルオーバーし、「同期ターゲット」アレイでの操作を再開するオプションがあります。これにより、同期アレイ間で発生するレプリケーションの同期性により、ゼロに等しいRPOを提供するフェイルオーバーソリューションが提供されます。
同期ターゲットアレイへのフェイルオーバー時に、そのアレイと非同期ターゲットアレイの間のパッシブ非同期定期リンクがアクティブになり、同期ターゲットに複製されたがまだ非同期ターゲットアレイに到達していないデータはすべて同期から送信されます。非同期ターゲットへのターゲットアレイは、同期ターゲットに対して発生した最後の書き込みで非同期ターゲットアレイを最新の状態にします。その後、同期ターゲットデータセンターで操作が続行され、非同期ターゲットアレイにデータが複製され続けます。
この情報から、非同期レプリケーションに参加するための3番目のエンドポイントが必要です。これにより、ネットワークリンクが切断されたときに、セカンダリサイトに変更を通知できます。
3PARについて具体的にコメントすることはできませんが、EMCSymmetrixアレイについては多くの経験があります。
私のアドバイスは次のとおりです。別の方法を見つけます。同期レプリケーションは、紙の上で最適な状況で見栄えがするこれらのテクノロジーの1つですが、現実の世界では膨大な量の苦痛を引き起こします。
それが機能する方法は次のとおりです。
- 着信書き込みはアレイのキャッシュに入ります。
- 書き込みは、同期リンクを介してリモートサイトにコピーされます。
- 書き込みは、リモートアレイのキャッシュにコミットされます。
- 確認応答がプライマリに返送されます。
- write IO成功はホストに確認されます。
IF IT IS ON DISKはリモートサイトにあるという意味で「RPO0」です。ほとんどのアプリケーションはメモリキャッシュを使用しますが、これはDRで失われます。ただし、かなりの価格：
リモートサイトには、レプリケーション要件に対応するのに十分な総帯域幅が常に必要です。そうしないと、ディスクの待ち時間が大幅に増加するため、プライマリシステムに深刻な影響が及びます。 everこのリンクを飽和させると、問題が発生し、プライマリサービスがクラッシュする可能性があります。
常にレイテンシーの負担があり、その結果、パフォーマンスが低下します。
さて、これらの両方が「問題ない」のかもしれません。しかし、私の経験では、RPO0と「同期レプリケーション」は通常、本当に重要なものがある場合にのみ説明されます。
ただし、質問に直接回答するには：
_Does the SAN deny data writes to the I/O until synchronisation has completed?_
いいえ-同期モードに入る前に、非同期で「追いつく」でしょう。帯域幅によっては時間がかかる場合があり、同期されるまで「0RPO」はありません。
_If a link is severed, does the SAN buffer the block changes until the connection is restored?_
設定によって少し異なります。通常、リンクの一時停止/再開は、非同期再同期が必要なイベントとして扱われます。リンクが「アウト」である間、RPOはゼロではなくなります。リンク障害で 'ブロック' IOできますが、これはおそらくアプリをクラッシュさせるだけです。
_If a link is severed during a TL log write, and a DR occurs, doesn't this mean that we will have a potentially corrupt TL written to the secondary site, and therefore incur data loss? The data loss is only because the primary was able to commit, but the secondary was not able to synchronise._
いいえ-同期は同期を意味します。同期している場合、ディスク上のIOはリモートにもあります。ディスク上の任意のIO notはただし、失われたため、最後のトランスログが失われる可能性があります。
Is RPO of zero ever a guarantee across the stack (SQL Server / Memory / Network / SAN / IO)?
RPOは回復ポイントの目標です。あなたの目的が（本当に）ゼロであるなら、...あなたはあなたのアーキテクチャについて非常に真剣に考える必要があります。それは達成可能ですが、信じられないほど高価です。
個人的には、同期の代わりに次のことをお勧めします。
プライマリデータストアを非同期で実行し、ログに依存して「同期」ビットを提供します。とにかく、あなたの「RPO0」（実際には）は「あなたのコミットされたトランスログ」にすぎません。したがって、NFS（CIFS？）はリモートドライブをマウントし、ネットワークを介して「ローカル」ストレージにトランスログを書き込み、それらをデータベースに再生します。
とにかく、ほぼ同じ回復ポイントが得られます-ジャーナリングされていないデータを使用したいと思うのではないかと疑っています-そして、高価な同期操作を必要とせずにそうすることができます。