2020年-DRBDの実行可能なLinuxブロックレベルレプリケーションの代替案はありますか？
プライマリデータセンターから障害復旧サイトへのほぼリアルタイムのレプリケーションをどのように実装できるかを調査しています。複製されるデータは次のとおりです。
- KVM VMの画像
- MySQLおよびPostgreSQLデータベース
簡単にするために、平均書き込み速度が100MB/s未満で合計10TB未満のデータであり、ピークが1500MB/sであり、プライマリとバックアップのデータセンター間のリンクのスループットが10gbit/sであると仮定します。
非同期レプリケーションは許容され、望ましい-書き込みがバーストしたり、両方のデータセンター間の接続が短時間停止したりした場合-ローカルの書き込み速度を遅くしたくないので、ケースで失われる可能性があるデータの最新の部分を犠牲にしてもかまいませんプライマリデータセンターに影響を与える致命的な障害の数。
私の理解では、次の中から選択できます。
- プロプライエタリSAN複製機能を備え、iSCSI LUNを提供できるハードウェア
- DRBDプロキシと組み合わせる必要がある可能性が高いDRBD [利用可能な帯域幅の一時的な低下または両方のデータセンター間のレイテンシスパイクがソースでの書き込みパフォーマンスに影響しないことを確認するため]
- http://schoebel.github.io/mars/ のようなソフトウェアベースのソリューション-悲しいことに-最良のシナリオでメインラインカーネルにマージするにはかなり時間がかかります
- DBの場合-データベースレベルのレプリケーションもオプションですが、すべてのワークロードをデータセンター間で切り替えたいDRテストを時々実行したいと考えています。 DRサイトからメインサイトにフェールバックするのは非常に面倒です。
検討する価値のある他の解決策はありますか？
ありがとうございました！
多くの理由により、DBとDB対応および依存型アプリケーションの場合、独自のレプリケーションは常に「一般的な」ブロックレベルのレプリケーションよりも優先され、DBの一貫性はその1つです。したがって、2014年または2015年以降のSQL Serverの標準バージョンでもいくつかの制限付きで利用可能なSQL Server可用性グループ（AG）を使用し、MS Exchange DAG、SAP HANA、AeroSpikeレプリカなどを使用します。2020年にDRBDを実行するのは、そのためです。特にオールフラッシュ構成でのI/Oパフォーマンスが低い場合、DRBDは、2000年代初頭の回転ディスクと高レイテンシの非RDMAネットワーク用に作られ、スプリットブレインの問題に対する保護が非常に不十分です。仮想SAN主要なハイパーバイザーの一部として見つけることができるテクノロジーは、DBの組み込みレプリケーションテクノロジーに対するもう1つの優れたオプションです。