私の自宅のラボでは、VMwareの無料の仮想化を使用しています。これは安価で信頼性が高いものです。 最初は1台のサーバーがあり、次にローカルデータストアを追加し始め、2台目のサーバーを組み立てました...これの標準的な問題は仮想マシンの移動でした。 これらの操作を手動で行うと、作業中の仮想マシンをまったく別の場所にあるフラットファイルのコピーに切り替えることができる1つの方法が見つかりました。 この方法は非常に簡単です。仮想マシンのスナップショットを作成し、フラットを新しい場所に複製してから、デルタで親ディスクへのリンクを強制終了します。 ハイパーバイザーはディスクメタデータファイルを開いたままにしないため、スナップショットを削除すると、新しいディスクとマージされ、古いディスクは安全に削除できます。 この方法は、無料のハイパーバイザーでは利用できないVDDKがなくても機能し、たとえば同様の状況でVeeamによって使用されます。
この手順をpythonで簡単に自動化して、さらにいくつかのトリックを適用しました。リクエストがあれば、以下の記事で拡張できます。 少し後に、前の同僚から男を書くことに同意したいい人が見つかりましたが、後者はUnityに実装されましたが、結果として出た無料のソリューションではExtrasphereと呼ばれ、まったく悪くはありませんでした。 管理者向けのおもちゃではないものは何ですか？
自宅の研究室用に仮想マシンを移行したので、障害からの保護について考えました。 最小要件は稼働中の仮想マシンのバックアップであり、最大値は元のバックアップのバックログが存在しないことです。 15秒の損失が重要であるようなデータを持っていたわけではありません。実際、数日を失うことは重要ではありませんが、将来の基盤を備えたこのような理想に到達したかったのです。
使用可能なソリューションの分析と比較は行いません。それはかなり前のことであり、それ以降はメモがありません。サイクリングに対する思いも寄らない渇望を覚えているだけです。
無料のハイパーバイザーでは、接続されている仮想マシンのフラットをフックできるLinuxマシンから最も単純なバックアップエージェントを作成できます。 このソリューションは完全バックアップの作成に適していますが、増分バックアップには絶対に適していません。 ネイティブCBTは、無料のハイパーバイザーでは使用できません。
自分でCBTをカットするのはいいと思いましたが、どうですか？ ZertoとSRMについてvSCSIFilterから聞いたことがありますが、ESXiのオープンソースパッケージをダウンロードした後、そこに似たものは見つかりませんでした-キャラクターデバイスを作成できることを除いて。 驚いたことに、すべてがそれほど複雑ではなかったので、hbr_filterデバイスを見てみることにしました。 3週間の実験-そして今、仮想ディスクにフィルタードライバーを掛けて、変更を追跡できます。
しかし、変更を追跡するだけでなく、それらを複製する場合はどうでしょうか？ ここで最大の危険性は、伝送チャネルを提供する大量のコードの作成を開始することです：ここで、変更をプルし、ネットワークにパッケージングして送信し、そこで受け入れ、アンパックし、書き込みます。また、すべてのステップとエラー処理で整合性を確保する必要があります 一対のエージェントなしではできないようです。 Zertoアーキテクチャを見て、このようなソリューションの作成と安定化だけでは非現実的であることを理解してください。
図 1.コマーシャルのZerto Virtual Replicationアーキテクチャ。
次に、ESXi自体が、たとえばiSCSIやNFSを介してネットワーク経由で書き込みできることを思い出しました。 必要なのは、ターゲットデータストアをローカルにマウントすることだけです。 また、レプリカも有効にすると、フィルタードライバーから直接レプリカに書き込むことができます！ 私は実験を開始しました。最初は、含まれているレプリカをどうするかわからず、Ubuntu Live CDからロードしたばかりでした。数週間後、作業コピーを作成し始め、その場で変更を転送することを学びました。 さらに、ソースマシンは、両方の受信者にレコードを渡すまで、レコードの確認を受け取りません。 だから私はゼロラグで複製を得ました。
この技術は、少なくともコードを除いてエージェントレスであることが判明し、すぐにPythonにレプリカを作成しました。 このような古典的な複製と単純性の相違のため、私はそれをミラーリングと呼ぶことにしました。
簡単なブートローダーを書くことで、含まれているミラーの問題を解決しました。そして、それがどんな用途にもなるように、ブートのミラーの最後のステータスを表示してからフリーズします。 その結果、実際のメモリ消費量はゼロになる傾向があり、データ転送中にCPUが少し無駄になりますが、インストールされたエージェントはそれよりも少なくなります。 その結果、ミラーと元のマシンに記録するディスクアクティビティのグラフは同一になります。
図 2.負荷がかかった元のマシンのCPU消費。
図 3.同じ期間のミラーでのCPU消費。
図 4.負荷のある元のマシンのメモリ消費量。
図 5.同じ期間のミラー上のメモリ消費。
図 6.負荷がかかっている元のマシンのディスクパフォーマンス。
図 7.同じ期間のディスクミラーパフォーマンス。
ミラーの状態を確認するために、ミラーのスナップショットからリンククローンとして実行するテストマシンを作成しました。 必要に応じて、スナップショットを保存してからテストを再度実行できます。テストが本当に気に入った場合は、組み込みの移行を備えた永続的な仮想マシンに変えることができます。これについては、冒頭で説明しました。
ローカルターゲットは良いのですが、別のオフィス/都市にミラーリングする必要がある場合はどうでしょうか？ 通信チャネルが十分に広い場合でも、応答の期間はソースマシンのパフォーマンスを著しく低下させます。ソースマシンは両方の受信者で終了するまで記録の確認を受信しないことを覚えています。 ここでの解決策は非常に簡単です。記録の不確実性の間隔をゼロから適切な値に拡張する必要があります。 たとえば、3〜5秒の許容可能な遅延は、良好なデータ整合性と適切なパフォーマンスの両方を提供します。 私は今このソリューションに取り組んでいます。 次に続くのは、sshとアプリケーションレベルの一貫性のない作業です。これもトリックなしでは行えません。喜んで共有します。