プロセッサの違いに関するIntelの意見は次のとおりです。http ： //ark.intel.com/compare/64593,40201
キーポジション：
新しいプロセッサのプロセッサ時間の価格は変わりません。 各コアのパフォーマンスが高いため、新しいプールで同じ負荷がかかっている場合、タスクはより速く、より少ないマシン時間で、つまりより安価に実行されます。
これらの変更に加えて、クラウドのツールスタックで大きな変更が発生します。
- ハイパーバイザーの新しいバージョンへの切り替え（3.4-> 4.1）（4.1、4.0の変更ログ）
- ストレージモーションサポート（プール間のライブマイグレーションをサポートする主要なステップ）
- xapiメジャーアップデート（ changelog ）
...そして、さらに多くのローカルな改善。 そして、ノイズによって、彼らはまだこのプールubuntu 10.04で利用可能なテンプレートのリストから削除しました... m ... uh ...市場関連性の損失。
正直に言うと、これらの変更の90％は将来の課題です。 それらのいくつか：
- Storage Motionを使用すると、外出先でストレージとプール間でディスクを中断なく転送できます
- 新しいハイパーバイザー（Xen 4.1）では、pv_opsカーネル（Linuxバニラカーネル）をパッチなしで製品に取り込むことができます（さよなら、-xenカーネル）
- xapiはついにXenSeverの小児疾患を取り除き、ホスト間で仮想マシンのバランスをとるプロセスを大幅に簡素化しました
なぜそんなに長く展開するのですか？
新しいプールのベースとなるXCP 1.6は2012年12月にリリースされました。3番目のプールのベータ版は2013年4月末に収縮されました。
遅延にはいくつかの理由があります。 最初のテスト。 テストでは、xapiの動作に誤りのあるシナリオがいくつか見つかりました（XenServerの観点からは誤りではありませんが、クラウドツールスタックとして動作することにはまったく興味がありません）。 この場合、さまざまなパラメーターを使用してプールの完成したコピーに対して多くの操作を実行する自動テストシステムが作成されました。 最長のテストには5時間以上かかり、それぞれ2つのホストの2つのプールで実行されます。
第二に、xapiの変更に対するツールスタックの部分の適応。 表面的には見えますが、それぞれに数工数の労力がかかります（最初に見つけてから適応します）。 コンソールは、PTS経由ではなくTCP経由で提供され、xapiからxenopsdへのドメイン操作の移行中に多くの属性が失われたため、回避方法を探す必要がありました。 Xenは、ABIに変更をもたらしました（すべてのSLAアカウンティングバインディングを再構築/書き換えするのに時間がかかりました）。 仮想マシンがプール間を移動できるようにするには、理論的にはデータベース構造に重大な変更が必要でした（以前は単純で明確な関係がありました-「すべての仮想マシンにプールuuidがあります」 。 別の問題は、IPアドレスの再配布でした（無料のIPv4アドレスはどんどん少なくなりました）。
出所