物理サーバーのクラスタリングを開始し、3ノードのハイパーコンバージドoVirtセットアップを計画しています。
現在、すべてのアプリとサイトをVPSとAPIでプロビジョニングされたクラウドインスタンスにデプロイしています。私はHAの経験がありますが、プロジェクトごとに、最終的には単一のロードバランサーまたはWebサーバーがあり、ドメイン名がポイントされます。
OVirtクラスターは、VPNまたはパブリック名を介して各ノードがFQDNアクセス可能になるように構成されていることを理解しています。
しかし、任意のVMを実質的に任意のホストに移動できる場合、クラスターから複数のパブリックvhostを実行するにはどうすればよいですか?すべてのホストIPアドレスを個別のDNSAレコードとしてリストし、ブラウザーのフェイルオーバーに依存する必要がありますか?奇妙に思えます。または、すべてのTLDのエントリポイントとして機能する個別のファイアウォール/ルーターを使用してクラスター全体を拡張する必要がありますか?ここでも、単一障害点になり、コロに追加のボックスになります。または、ゾーンの更新をスクリプト化することが必須でしょうか?
私はおそらく完全に明白な何かを見逃しています。すべてのアドバイスは大歓迎です。ありがとう!
oVirtはハードウェアを仮想化し、VMインスタンスを提供します。これらのVMは、別の物理ホストで起動できます。
論理仮想ネットワークは通常、物理ネットワークとは異なります。また、VM web3
は、ovirt1
からovirt2
に移行するときにIPアドレスを保持します。これらの物理ノードは、エンドユーザー向けではありません。
ただし、oVirt VMは、高可用性を完全に考慮しているわけではありません。
回復時間の目標は何ですか?数時間の場合は、大幅な修理を行う時間があります。少ないものは次第に複雑で高価になります。
アプリケーションの設計を検討してください。着信リクエストはどのようにどのインスタンスに流れますか?複数のインスタンスに負荷分散できますか?ロードバランサー自体にHAが必要ですか?そのデータベースにはレプリケーションソリューションがありますか?
クラスターを安全かつ迅速に実行することは困難であることを理解してください。 oVirtHAの基準VM再起動するのは簡単ではありません。 ディザスタリカバリは常に考慮事項です。これには、クラスターがブレインとデータが破損しています。アプリケーションが利用可能な状態を維持するために単一のVMを必要としない場合、VM HAの重要性は低くなります。
DRと言えば、複数のサイトが範囲内にあるかどうかを検討してください。クラスターの典型的な例として、 oVirtにはいくつかのDRパターンがあります 。アクティブ/アクティブをストレッチし、クラスターをアクティブ/パッシブに分離します。ここでの設計上の決定は、問題のドメインと回復までの時間に影響します。たとえば、パッシブセットアップは、ストレージとレイヤー2ネットワークの観点からほぼ完全に分離できます。プライマリサイトの問題がそこに拡大するのは非常に困難です。パブリッククラウドの地域を考えてみてください。ただし、カットオーバーは手動プロセスであり、DNSの更新が含まれる場合があります。