「消費による支払い」の概念が形になりつつあり、「数える方法」を必死に探していたとき、プロセッサとメモリが最も単純な2つのリソースであるように思えました。
実際、xencontrol（Xenハイパーバイザー管理ライブラリ）があり、各ドメイン（実行中の仮想マシン）、メモリの量、消費されたナノ秒数を正確に知ることができます。 このライブラリーは、ハイパーバイザーに（xenbusを介して）直接情報を要求し、最小限の処理を行います。
この情報は次のようになります（Pythonのxencontrolバインディング出力）：
{
「一時停止」：0、
「cpu_time」：1038829778010L、
'ssidref'：0、
'hvm'：0、
'shutdown_reason'：0、
「死にかけている」：0、
'mem_kb'：262144L、
'domid'：3、
'max_vcpu_id'：7
「クラッシュ」：0、
「実行中」：0、
'maxmem_kb'：943684L、
'shutdown'：0、
'online_vcpus'：8、
「ハンドル」：[148、37、12、110、141、24、149、226、8、104、198、5、239、16、20、25]、
「ブロック」：1
}
ご覧のとおり、仮想マシンに割り当てられたメモリに対応するmem_kbフィールドがあり、ある種の驚異的な数値を含むcpu_timeフィールドがあります（実際には17分です）。 cpu_timeはナノ秒単位まで正確にカウントします（より正確には、ここに格納される値はナノ秒単位でカウントされ、実際の精度は約マイクロ秒です）。 理解できるように、メモリはキロバイトです（ただし、アカウンティングの内部単位は、Linuxカーネルがページであるハイパーバイザーです-デフォルトサイズは4キロバイトです）。
「取り込んで」と思われるかもしれませんが、悪魔は細部に宿っています...
下の黄色い見出しでごめんなさい、しかしそれは問題の1つの議論の間に論争の質問がどのように聞こえたかです：
ハイパースレッディング+ Xen =顧客からのお金の盗難
質問：Xenを使用するホストでハイパースレッディングを有効にするかどうか これを含めると、クライアントにより多くのコアを提供できます。 それぞれに4つのコアを持つ2つのゼオンの場合、これは16のコアを提供します。自分のニーズに合わせてカップルを予約すると、14のコアになります。 14は8よりも冷たいですか？ クーラー。 したがって、14になります。
さらに、マルチスレッドアプリケーションを実行すると、実際の7つのカーネルよりも14の「偽の」カーネルで1.5倍高速にカウントされます。 これは事実です。テストサーバーの1つで裸のLinuxのテストをチェックしました。
...停止します。 1年半？ つまり、14のコアは2倍のコアで1.5倍動作しますか？
はい、それはまさに起こったことです。 最大の負荷と数時間にわたって明らかに解決できないタスクがある仮想マシンでナンバークラッシャーを実行しようとした瞬間に状況は特に劇的になり、別の仮想マシンでは固定ボリュームの計算タスクを考慮するアプリケーションを起動しました。 そして、計算にどれだけの時間を費やしたかを、ハイパートレッドのオンとオフを比較しました。
| 負荷レベル | HTなしでカウントされたプロセッサー時間 | HTを使用 |
| アイドル状態のネイバー、1コア | 313.758 | 313.149 |
| アイドル状態のネイバー、4コア | 79.992 * 4 | 80.286 * 4 |
| ネイバーはアイドル状態、8コア | 40.330 * 8 | 40.240 * 8 |
| ネイバーはアイドル状態、16コア | - | 29.165 * 16 |
| 完全にロードされたネイバー、1コア | 313.958 | 469.510 |
| 完全にロードされたネイバー、4コア | 79.812 * 4 | 119.33 * 4 |
| 完全にロードされたネイバー、8コア | 40.119 * 8 | 59.376 * 8 |
| 完全にロードされたネイバー、16コア | - | 29.634 * 16 |
見やすいです。29.6* 16は473.6で、59.376 * 8（475）と同じです。 そして、これは40.119 * 8（320）の1.5倍です。
言い換えると、ハイパースレッディングは、プロセッサの数を2倍にすると、プロセッサを1.5倍遅くします。
プロセッサが完全に自分のものである場合に役立ちます。 そして、プロセッサ時間が支払われ、近くに「同僚」さえいなくても、単に「見知らぬ人」がいる場合はどうでしょうか？
その後、大きな議論がありました（断続的に約3日かかりました）-クライアントのホストのクラウドでHTを実行する必要がありますか？ 明白な「誠実な不正直」と「誰も知らない」に加えて、もっと深刻な議論がありました。
- 1つのサーバーがより多くのプロセッサリソースを生成します（Intelがこのテクノロジを実行したため）
- マシンタイムの価格を下げる際に、この「パフォーマンスの低下」を考慮することができます
- ホストの負荷を監視し、50％を超える過負荷を防ぐことができますが、より多くのコアをクライアントに提供できます
議論の後、次の一連の議論に至りました。コンピューター時間の消費を制御できず、実際に（統計的にも）予測することはできません。 移行は、抜け道ではありますが部分的です。移行反応は最低でも30〜40秒である必要があり、ロード時のショットは瞬時（1秒未満）になる可能性があるためです。 この点に関して、クライアントにどのようなマシンタイム（フルまたはノー）を提供したかはわかりません。いずれにしても、クライアントは、隣人が重いものを計算したかったという事実のために、明白な理由もなく不当なパフォーマンスの損失に直面します。
ハイパースレッディングを使用して仮想マシンのパフォーマンスを一定に保つことができないため、コンピューター時間の支払いを伴うクラウド内のHTをオフにする必要があるという観点で勝ちました（仮想マシンあたり8コアの制限）。
移行：コピーと削除
2番目の面白い瞬間は、移行中のリソースのアカウンティングの問題でした。 デフォルトでは、ハンドル（別名uuid）はオブジェクトの一意性の証明であり、1つのuuidで2つの仮想マシンが存在することはできません。 確かにそうです。 ただし、これはドメインではなく仮想マシンに適用されます。 移行中に、ドメイン（RAM）の内容がコピーされ、新しいノードで起動され、古いノードでのみ削除されます。 これにはすべて、ドメインフラグメントの多数の再コピーが伴います（仮想マシンは引き続き動作するため）。 いずれにしても、1つの仮想マシンから2つのドメインを取得します。 数字を大まかに数値的に数える（要約する）と、最後のカウンターで完全に間違った数字が得られます。 （ちなみに、この問題はかなり遅れて発見され、打ち上げが遅れた理由の1つでした）。
この問題の解決策はエレガントで、建築的に美しいものでした。 一度に動作できるドメインのコピーは1つだけです。他のコピーはすべて一時停止モードです。 これは非常に重要です。2つのドメインが機能する場合、まれなfireを壊す可能性があるからです。 したがって、ソリューションは次のようになります。一時停止したドメインは計算されません。 これには、いくつかの小さな悪影響があります。
- クライアントに見事な「一時停止」ボタンを提供することはできませんでした（このモードではドメインは存在しますが、実行されません）。 このようなドメインはメモリを消費するため、クライアントが仮想マシンを一時停止して休暇をとる場合、それを考慮に入れる余裕はありません。 また、「移行中の一時停止」と「一時停止」を区別することはできません（少なくとも、州やデータベースとの非常に大規模で重要なダンスはありません）。
- クライアントがマシンをリブートすると、ドメインがすでに存在するが、まだ一時停止している瞬間があります-それを考慮しません（したがって、マシンを絶えずリブートするクライアントは少量のメモリを過小評価することができます）。 これは私たちの問題であるため、これはさらに正直である可能性があります-すべてがそこに構築されており、マシンが動作し始めるまで、クライアントがそれを支払う理由はありません。
ただし、それ以外の場合、このソリューションには副作用はありません。 そして、いくつかが議論されました：アカウンティングデータベースのロックの存在、ドメインのライフタイムのアカウンティングなど。 停止したドメインを無視して、ソリューションの優雅さを背景にしたそれらのすべては、かさばり、andいように見えます（あなた自身を賞賛することはありません。
dom0の費用は誰が負担しますか？
もう1つの大きな問題は、dom0ブートの問題でした。 ユーザーがネットワーク経由で要求を行うか、ディスク操作を実行すると、要求はdomU（実行中の仮想マシンであるドメイン）からドライバーの後半のdom0に転送されます。 ドライバーは要求をこめつめ、これらの鉄片の実際のドライバーに渡します。 そして、私は、集中的なディスク操作で、彼がどうやってくめちゃくちゃ言わなければならない。 50〜80％でお問い合わせください-nefigの仕組み。 そして、この数の大部分はOVS、blktap、xenstoreなどです。 （残りはクラウド管理システムの一部であるxapi、squeezed、stunnelです）。 このマシンタイムの請求対象者は誰ですか？ そして最も重要なことは、あるユーザーを別のユーザーから分離する方法ですか？ ドライバーレベルでは、これは可能かもしれませんが、もっと...
同じOVS（Open vSwitch、仮想ネットワークを提供するプログラム）がフレームを交換し、彼はそれらがどのドメインに属しているかを気にしません。
Zenovites（ハイパーバイザーとそのバインディングの開発者）は、この問題について頭を痛めました。 私も考え始めましたが、やがて私の感覚になりました。 ディスク操作が支払われる場合、実際には、その価格にはリクエストの処理コストが含まれます。 これらは、IOPSディスク、RAIDコントローラーの負荷、SAN、10Gカードの償却などだけではありません。 これと（上記に対して非常に重要でない）マシンタイムdom0。 すべてが論理的であり、それ自体で決定されました。