前の部分で用語を定義しました。 次に、「仕組み」の詳細な説明に移ります。 （「テイクアンドラン」にせっかちな人は、xenサイトのマニュアルを使用して実行できます）。

このパートでは、プールとホストデバイスの概要について、Xenについて少し説明します。

プール

すべてのXCPは1つのプールを表します（複数のプールのサポートは非​​常に遠い計画です）。 基本的に、会社は複数のプールを持つことができます。 ホストに異なるハードウェアを使用する場合、同じハードウェア内でプールを形成する必要があります。 縮退した場合、これは「1つのホスト-1つのプール」を意味します。 この構成では、ライブマイグレーションの可能性はなく、唯一のオプションは仮想マシンのエクスポート/インポートです（ゆっくりと手動で）。 したがって、ライブマイグレーション機能を使用するには、少なくとも2〜3台の同一のマシンが必要です（同じことは、プロセッサのステップまでは「まったく同じ」という意味です）。 プールにさまざまな種類の鉄を集めることができるかどうか、少し前に疑問が生じました。 公式の答えはノーです。 本当にしたい場合は可能ですが、同時に発生した可能性のあるグリッチはすべて自分のレーキになります。

各プールホスト（デバイスについては以下で説明します）には、プール内のすべてのマシンの状態に関する完全な情報があります（プールデータベース全体を格納します）。 「プールマスター」と呼ばれる1つのホストのみが操作を実行できます。 マスターは外出先で簡単に変更でき（仮想マシンを再起動および停止することなく）、マスターが「死んだ」場合、その役割を強制的に別のホストに移すことができます。 元のマスターが起動すると、「プールの分割」が発生します。元のマスターが自分がマスターであると信じ、他の全員が新しいマスターにサブミットすると、プールは2つの不均等な部分に分割されます。 この問題は、「以前のマスター」の設定を強制的に変更することで簡単に解決できます。

マスターは慎重にプレイする必要があります。まさにマスターとのゲームのために、Xenの状況（クラウドマシンのリストにない仮想マシンが起動されたとき）を取得しました 。 ただし、XCP 0.1.1以降、状況は少し変わり、生きているマスターがいない場合のホストの動作はより合理的になりました。


マスターはコマンドを受け入れて、それらをスレーブに送信します（マスターではないプール内のホストはスレーブと呼ばれます）。 ただし、任意のホストのコンソールからプールを管理できます。この場合、入力されたコマンドは単にウィザードに送信され、ユーザーに結果が表示されます。 管理についての詳細はもう少し低くなります。

プールには、（いくつかの例外を除いて）すべてのホストで完全に同一の構成が保存されます。 これにより、仮想マシンはどのホストでも実行でき、ホストは仮想マシンの観点から区別できません（これが「XCP」という名前にクラウドが含まれる理由です。プラットフォームでは、特定のマシンを忘れて、多くの同等のブリックを使用できます）。

ホストにはまだ下位レベルの機能がありますが、上位レベルでは慎重にマスクされます。 これは主にネットワークとストレージの接続に関連しています-一部のホストのPBDとPIFは接続されていない、つまり接続されていない場合があります。 これは、管理上の決定または外部の理由（スイッチのポートが壊れた、iSCSIターゲットがホストの1つへの接続を拒否したなど）のいずれかです。 この場合、次の状況が発生します。

「where / where」（ xe vm-start 、 xe host-evacuate ）を指定せずにマシンを起動/移行するコマンドが発行された場合、「不適切な」ホストは無視され、利用可能なホストを使用してコマンドが実行されます。 管理者が仮想マシンの起動場所を明示的に指定した場合、ホストリソースの一部が準備されていないため、このホストでマシンを起動できないと通知される場合があります。 典型的な管理アプリケーションでは、「マシンを起動する場所」を正確に指定する必要はありません（すべてのマシンは同等です）ので、「準稼働」ホストは問題を引き起こしません。

もう1つの興味深い機能は、負荷分散です。 XCPネイティブと外部の2つのタイプがあります。 ネイティブの負荷分散は、マシンがオンになっている場合にのみ実行されます（欲張りと控えめの2つの動作戦略があります：欲張りは、ほとんどのリソースがあるマシンを起動し、十分なリソースを持っている控えめなマシン、つまり、タスクに可能な限り少ないホストを占有しようとします）。 外部バランス（通常は移行時）はユーザーに任されています。

さらに、XCPは、動的メモリ制御（DMC）メカニズム（各仮想マシンにRAMの境界を設定するメカニズム）を提供します。必要に応じて、XCPは他のマシンを「プッシュ」して、新しいネイバーにメモリを提供できます。 ただし、メモリ管理については後ほど説明します。

ホストデバイス

Xenバーチャライザーの動作の完全な説明は、記事で計画されているものをやや超えています（この分野で十分な教祖だと思うなら、これを書きます）。 ここでは、XCPの中心であるXenハイパーバイザーの仕組みを非常に表面的に説明します。 OSが起動する前にXenが起動し、プロセッサ、メモリ、およびI / Oを制御します。 この言葉遣いにあります。 VMWareとは異なり、Xenはディスク操作やネットワークについて何も知りません。 制御するのは、割り込み、DMA、メモリ、およびプロセッサのみです。 デバイスを確実に動作させるために、最初のオペレーティングシステムがロードされます（XCPではCentOSです）。これはすべての物理デバイスにアクセスし、ハイパーバイザーをコマンドする権利（つまり、コマンド、他のドメインまたはハイパーバイザーのメモリに直接アクセスしません）および仮想デバイスをサービスする義務を取得します仮想マシン。 実際、ハイパーバイザーの観点から見ると、コマンドOSはもう1つの仮想マシンにすぎません。

Xenの用語では、実行中のマシンは「ドメイン」と呼ばれます。 重要：ドメインを破棄することは、仮想マシンを「シャットダウン」することです。 マシンの電源を切らなくてもドメインが破壊される場合があります（たとえば、マシンがホストからホストに移行する場合、受信ホストでドメインが作成され、送信ホストで破壊されます）。

OSの司令官はdom0と呼ばれます（これは一般的な用語であり、今後はそれのみを使用します）。 ゲストドメインはdomUと呼ばれます。 Xenにはスタブドメイン（特定の鉄片と連携し、それらに基づいて仮想の鉄片を提供するよう委任されるドメイン）の概念がありますが、XCPでは使用されません。 鉄片をゲストドメインに「転送」する機能が使用されないように。 すべてのハードウェアはdom0にあります。 ポイント。

Dom0は、特別に適合したカーネルに加えて、さらにいくつかのコンポーネントを含んでいます。 これは：

• xapiはXCPの頭脳です。 ハイパーバイザーにコマンドを送信し、API呼び出しを移行および処理するメインサービス。 xapiは、ある意味で「通常の」xenのxendの類似物です（これはxenとXCPの主なアーキテクチャの違いです）。
• xenデバイスメンテナンスバンドル：blktap、xenstore、コンソール（それらについては後で説明します）
• vswitchを開きます（同様に、少し後の短い-これは仮想ネットワークの仮想スイッチです）。
• squeezedは、動的なメモリ調整を提供するデーモンです。
• プール内のホスト間の通信を提供するstunnel（ホストとネットワーク間のすべての対話が暗号化されていることを忘れていましたか？それは一種の暗示です）。
• xsconsoleは、メニューを使用してホストを管理するためのシンプルなncursesメニューです。 ホストをロードした後に開始するのは彼です
• xeは強力なオートコンプリート機能を備えた非常にクールなコンソールユーティリティです（強力と言うと、本当に強力という意味です）。これにより、プールでできることをすべてプールで実行できます。 実際、利便性のために少し構文上の砂糖を使用して、XenAPIのすべてを完全にカバーしています。

もちろん、これに加えて、ネットワーク、iscsi、nfs、FCなどで動作するLinuxコンポーネントのyumからopenofficeまで、多くのサポートがあります 。 もちろん、それらの中にはsshサーバーとntpサーバーがあります。

ところで、NTPについては...これはXCPの最も重要なコンポーネントです。ホストの時刻同期は通常のマシンの移行に不可欠です。 私の知る限り、構成されたntpなしでXCPを実行することは非常に困難です。 この場合、時間のソースは「グローバル」である必要はありません-一般的な時間のソースと同期するのに十分です。

ホストが起動すると、Xenがロードされ、dom0コアが起動します。 ダウンロードの詳細については、RHEL / CentOSのマニュアルを参照してください。 他のすべてのアプリケーションは、通常のデーモンのように実行されます。 インフラストラクチャ全体は4つの部分に分かれています（これは私の個人的な区分であり、一般的に受け入れられていません）：

1. コンピューターとしてのホスト（OSおよびアプリケーションソフトウェア）
2. Xenと彼のハーネス
3. XCPのクラウドパーツ
4. 管理部分（コンソールユーティリティ、xsconsole、vncterm）

今、各部分について（最初の部分を除いて、セントスが混乱を引き起こさないことを願っています）more ...

Xenパーツは、ユーザーからは見えませんが、まだ存在しています。 xenstoredがあり、XenStoreを操作するためのユーティリティセット（xenstore-ls、-read、-write、-rm）、gibletsに隠されたxc pythonモジュール、xentopおよびxentraceがあります。 特に、通常の使用でそれについて考える必要はありません。自分の何かを見ている場合、または理解できない何かが起こった場合、それについて考える必要があります。

XCP'shnyパート-実際、会話のトピック。

xapiはAPIを提供し、http（s）サーバーの動作を保証し、仮想マシンの動作を制御し（特にxapiは移行を実行します）、マスターに情報を送信し、マスターからコマンドを受信します。 マスターは、それに応じて、情報を収集し、コマンドを受信して​​提供し、すべてのホストに変更を送信します。 XCPベースは完全にメモリに保存され、そのダンプはディスクに保存されます。 （この場合、DBMSは使用されません）。 xapiはOCamlで記述されており、ソースコードをいじくり回すファンは、大きな混乱と混乱に陥ることがあります。

さらに、ホスト上の各xapiはマスターからコマンドを受け取り、実行します。 これらは、仮想マシンに関するコマンドだけでなく、ホスト自体の構成に関するコマンドでもあります-ネットワーク設定、再起動/シャットダウンコマンド、ブロックデバイスとNFSボールのマウントの制御（非常に間接的な）、ユーザー管理。 Xapiは、「eth0 to host-123」という用語からxe pif-param-list uuid=(someuuid)に切り替えることができる抽象化レイヤーを提供し、最も重要なことは、eth0が配置されている特定のホストからではなく、任意のホストから使用することです。

xapiは、stunnelを使用して、マスターとスレーブ、およびスレーブ間の相互接続を保護します。大量のデータを転送する場合、暗号化は無料の操作ではないため（マシンを移行するときにこれを見たことがありますが、そこに転送されるデータの量はボリュームより少ないゲストシステムのRAM）、プロセッサの比較的適切な割合を食い尽くす可能性があります。 原則として、プールがそのように約10〜15である場合、マスターのxapi + stunnelがほぼ1つのコアを完全に外食すると予想できます。 （ところで、XCPのすべてのdom0は厳密にシングルコアです）。 スレーブのロードははるかに低く、xapiのダウンロードを25％以上作成できませんでした。

管理部分は、コンソールサーバー（新しくインストールされた仮想マシンのコンソールについて説明しています）、ホスト自体のコンソールの基本メニュー（sshから呼び出すこともできます）、および最も強力な制御システムがxeコマンドラインによって表されます。 xeに加えて、XCPには数十個のユーティリティも含まれており、それぞれが非常にまれなケースで使用されます。 すべてのフルタイム管理は「xe」を経由します。

xeの特性は、プールホストでは動作しない可能性があることです（特に、xeのWindowsバージョンがあります）。 Xeは別のパッケージとして提供され、適切なマシンにインストールできます（少なくとも管理ワークステーション用）。 XeはAPIを使用してプールマスターに接続し、認証後、ローカルとほぼ同じ方法でプールを管理できます。

コンソールユーティリティに加えて、多くの代替オプションがあります。 これは、XenCenter（Citrix for Windowsの有料グラフィカルユーティリティ）、OpenXenManager（PythonのXenCenterのクロスプラットフォームクローン）、およびさまざまな利便性の数十のグラフィカルシェルです。 XCPの共著者の1人は、マシン移行との自動バランスをサポートするXen Cloud Control Systemのバージョンを積極的に宣伝しています（私の手が届かない）。 ただし、グラフィックシステムはオブジェクト間の関係をわずかに単純化することを余儀なくされるため、本格的な作業（WTFシンドロームを引き起こさない）はコマンドラインまたはAPIからのみ可能です。

管理とAPIについては、後ほど詳しく説明します。

最後に、プールとホストの関係についてさらに詳しく説明します。

ホストは1つのプールにのみ属することができます。 ホストが1つしかない場合は、ホスト自体がプールされます。 ホストが「外部」プールに受け入れられると、ホストはそのプールを「忘れ」、外部プールを受け入れます。 したがって、マスターは誰も忘れませんが、外部ホストを受け入れ、自分のプールのデータに追加するだけです。 ホストがプールを離れると、「その」プールの古いデータをバックアップから取得します（注：このようなバックアップには仮想マシンは保存されないため、プールへの参加と離脱の操作は破壊的であると考えてください）。

プールからマシンを削除した場合、プールを破棄することはできません。その結果、プールには1つのホストのみが残り、それが独自のマスターになります。 彼は、「プールを殺す」ように言われることはできません。別のプールに受け入れられるか、システムを破壊する必要があります。

次の部分：VBD VDI PBD SR VIF PIF Open vSwitch