5

任意に仮想化され、制御できないサーバー ホストを繰り返し、非ランダムに、一意に識別できる必要があります。

  • 一部の仮想化環境では、ネットワーク インターフェイスにハードウェア アドレスがないため、MAC アドレスは機能しません。
  • 状態ファイルを生成してディスクに保存しても、仮想マシンが複製されてファイルが複製される可能性があるため、機能しません。
  • サーバーの SSH ホスト キーが候補になる場合があります。それらは状態ファイルのように複製できますが、実際には、セキュリティ上の問題であり、めったに行われないミスであるため、通常は複製できません。
  • /var/lib/dbus/machine-id もありますが、これは dbus に依存しています。（ありがとうPreetam）。
  • cpuid がありますが、それは明らかに非推奨です。（TwitterのBruno Aguirreに感謝します）。
  • ホスト名は検討する価値があります。Chef などの多くのシステムでは、すでに固有のホスト名が必要です。（ありがとう、アルフィー・ジョン）

サーバーの再起動やソフトウェアの再起動後も、ソリューションが長期間持続することを願っています。最終的には、私のソフトウェアのユーザーがホストを廃止し、別のホストに置き換えたいと考えていることも知っていますが、それに関連付けられたデータの継続性は維持します。ホストが自分自身を不明であると見なし始め、理由もなく自分自身を再登録することを特に望んでいません。

ホストの代替の永続的で一意の識別子はありますか?

4

4 に答える 4

4

それは、「永続的」が何を意味するかによって異なります。たとえば、2 つの VM がそれぞれ同じネットワーク ソケットを開くことはできないため、それらが互いのビットレベルのクローンであっても、それらを区別することは可能です。

したがって、永続化の期間がどのようなものであれ、マシンを区別するのに十分な情報があれば十分です。

  • 持続期間がネットワーク接続の長さである場合、識別子はまったく必要ありません。ソケット自体は一意です。

  • 永続性を長くする必要がある場合 (たとえば、ブートの長さ)、システムが起動するたびに UUID を再生成できます。(複製された VM は、ホット コピーしない限り、再起動する必要があることに注意してください。)

  • それより長くする必要がある場合 (無期限など)、起動時に UUID 識別子を生成してディスクに保存できますが、これはマシンの識別情報の一部としてのみ使用します。その後、仮想マシンのクローンを作成すると、2 つのマシンが異なるソース (たとえば、2 つの異なるネットワーク ソケット、異なる起動時間など) から同じ ID を報告するため、これがわかります。つまり、各マシンに状態ファイルを再生成するように指示するなど、さらに差別化を強制する後続のアクションを実行できます。

最終的に、マシンが完全に複製された場合、定義上、そもそもどちらが「本物」であったかを知ることはできず、 2 つの区別可能なマシンが存在するだけです。

「本物」と「複製されたもの」の違いを見分けることができるということは、仮想マシン自体が作成されたときのタイムスタンプのように、2 つの違いを記録するために使用できる状態があることを意味します。その場合、それを州の記録に組み込むことができます。

于 2013-08-19T15:22:07.187 に答える
1

単純な解決策は除外されているようです。そのため、このプロトコルのような複雑なソリューションにつながる可能性があります: - クライアントはタプル [MAC アドレス、SSH 公開ホスト キー、シーケンス番号] を送信します - サーバーがこのタプルを期待どおりに受信した場合、サーバーとクライアントの両方がシーケンス番号をインクリメントします。- それ以外の場合、サーバーは何が起こったかを判断する必要があります (クライアントは複製されましたか? クライアントは移動しましたか?)。おそらく暫定的な結論に達し、それを確認するよう人間に警告します。

于 2013-08-19T20:38:54.260 に答える
0

利用可能な情報に基づいた単純な「X ソリューションを使用する」というものはないと思いますが、より良い場所にたどり着くための一般的な提案をいくつか示します。

  • 「ゴールド イメージ」からクローンを作成する場合は、「最初の起動」ロジックを使用して一意の ID を生成することを検討してください。Chef、Puppet、Cf-engine などの構成管理システムは、これを実現するための足場を提供します。
  • Zookeeperのようなグローバル状態マネージャーを考えてみましょう。具体的には、そのアトミック カウンター機能です。同じシステムが時間の経過とともに新しい ID を取得する可能性がありますが、それは一意になります。
  • また、このスタック オーバーフローによって、別の方向性が示される可能性があります。これは、同様の問題に対する Twitter のアプローチを参照しています。
于 2013-08-19T15:31:48.213 に答える
-1

私の理解が正しければ、次の条件下で永続的でグローバルに一意の識別子が必要になります。

  • 実行中にクローンを作成できる OS インストール。VM内の状態は機能しません。
  • 任意の仮想化環境で実行されている可能性があるため、VM の外部の状態は機能しません。

これがあなたの質問に直接答えるものではないことは承知していますが、ソリューションに対応するには、設計または制約のいずれかを大幅に調整する必要があるようです。

于 2013-08-19T15:25:57.187 に答える