グラフ上には、cloudspectator.comのIaaS-「クラウド」市場にある5社の仮想マシンのパフォーマンステストがあり、同じ方法を使用してCROC「クラウド」の速度を測定しました。 06/20/13から06/29/13までの日別内訳。
満足のいく高い結果にもかかわらず、このテストの結論は一方的なものに思えました。 そして、タスク自体が同僚の間で多くの論争を引き起こしました。結局のところ、 「クラウド」のパフォーマンスを評価することは重要な問題です。 そして、私たちはもっと深く見ることにしました。
「クラウド」は、大まかに言って、この「クラウド」を機能させる機器と、顧客の仮想マシンが稼働する機器で構成されています。 仮想マシン自体のパフォーマンスは、それらが実行されている物理サーバーのパフォーマンスに依存します。 単一の標準はありません。市場の誰もが、これらの仮想回路の完全に異なる構成の完全に抽象的な仮想プロセッサを提供しています。
「クラウド」を構築するために使用されるテクノロジーを公開している人はいません。 独自の「クラウド」用に独自のデータセンターアーキテクチャを開発する人もいますが、Amazonなどの非常に大規模なプレーヤーだけがそれを行っています。 データセンターを見た場合、それらが飛行場のサイズであることを知っています。
まず、同僚とクライアントに「クラウド」を選択する方法と対象について尋ねました 。 そのような「1つの数字」はありませんでしたが、大多数は同様のシナリオでした。 まず、顧客は、単一の仮想マシンが十分に高速であることを確認することを望んでいます（つまり、提供されるもの、たとえば、全体ではなくカーネルの1/4ではありません。ここでは、プロセッサ、メモリ、ディスクサブシステムが重要です）。 次に、ネットワークの質問が発生します（「クラウド」へのping、インターネットとの通信チャネルの帯域幅、クラウド物理インターフェイスの帯域幅、およびデータセンター間のチャネルの帯域幅）。
大企業の場合、主なことは、仮想ネットワーク間の相互作用の速度とデータセンターの相互接続の速度です。 さらに、SLA、サービスとしてのバックアップ、セキュリティ、監視、データセンターの信頼性などについて疑問が生じます。 私たちはこれで完全な注文をしているので、パフォーマンスが主な選択のポイントのままです。 そこで、他の「クラウド」と十分に比較するために、スタートアップが提案した方法とテスト条件から逸脱しないことを決定し、独自の仮想マシンの速度を測定し始めました。 そして、ここにもニュアンスがあります。
顧客の目で状況を見ると、個々の仮想マシンのこのようなテストの結果は、現在の物理サーバーを移行できる仮想サーバーの必要なサイズを推定するのに役立ちます。
最初のテストの本質は簡単です。すべての「クラウド」では、通常最も一般的なタイプの仮想マシン（1 vCPU、4 GB RAM）が同じサイズで取得され、同じユーティリティがしばらく実行され、パフォーマンスが測定されます。 この特定のケースでは、これはオープンなUnixBenchユーティリティであり、物理プロセッサから仮想マシンに割り当てられたカーネルのパフォーマンスを数値的に評価できます。 わかりました、同じことをします。
同じレポートのvirtualka構成の例：
「チート」テスト
「クラウド」で実際の結果を取得したいという事実を考慮して、条件を可能な限り戦闘条件に近づけるようにしました。 実負荷でのテストと合成テストの違いは何ですか、説明する必要はないと思います。
まず、テストのためにインフラストラクチャを調整するという問題が発生します。 もちろん、設定により、結果を数十パーセント「微調整」できます。 可能な限り、特定の顧客の特定のタスクのために、クラウドの物理インフラストラクチャのチューニングを実行します。 たとえば、大規模な顧客のアプリケーションのCPUの負荷と読み取り/書き込み操作の比率を正確に把握している場合、設定を変更してパフォーマンスを向上させることができます。 ただし、サーバーを追加購入するか、特定のタスクの「調整」を選択するたびに、サーバーの追加を選択します。 これは、「クラウド」が大きいほど、サポートする必要がある物理的機器が多くなるためです。 また、同じインフラストラクチャを維持する方がはるかに簡単です。 チューニングに夢中になると、柔軟性が失われ、不具合が発生する可能性があります。 したがって、テストのために、物理サーバーと仮想マシンの最適化は実行しませんでした。
第二に、明らかに、たとえば午前3時に仮想マシンのパフォーマンスを測定しても意味がありません 。 「クラウド」では、物理サーバーのパフォーマンスは、仮想マシンが配置されているすべての顧客間で分割されるためです。 夜には、すべての仮想マシンは確かに動作しますが、ロードされません。 つまり、テストでは、「クラウド」が多少高い負荷で動作しているときよりもはるかに大きな値が表示されます。 主な負荷は午後5時頃に低下します。 この状況は非常に一定であるため、この時点で測定を開始しました。 1週間半テスト済み。 各テストには約10〜15分かかります。
ネットワークテスト
そこで、仮想マシンの速度に関する実用的なデータを取得し、他の「クラウド」と比較しました。 次のステップはネットワークテストです。仮想マシン間のネットワークの速度、仮想インフラストラクチャの安定性、「クラウド」と別のサイト（または物理ストレージシステムなど）にあるお客様の物理機器の接合部におけるネットワークの速度と安定性を決定します仮想インフラストラクチャにドッキングされた顧客データ）、およびデータセンター間の相互接続を提供する通信チャネルの速度。
なぜこれが必要ですか？ たとえば、2つの異なるデータセンターに2つのアクティブ/アクティブシステムがある場合、または最初のシステムに障害が発生した場合にメインシステムと高可用性コピーがある場合、これらのポイント間のチャネルは非常に重要です。 大企業向けのこのようなソリューションを専門としています。 そしてすぐに、別のトピックの私の同僚が、データセンター間のトランザクションの遅延を7ミリ秒から5ミリ秒に大幅に削減するために、あるクライアントのためにどのように戦ったかを話します。
まとめ
テストは、データセンター「Compressor」にある「クラウド」で行われました。 構成1 vCPU、4Gb RAM上のUnixBench。 テスト自体の結果は非常に驚きました。CROC「クラウド」での仮想マシンのパフォーマンスは、MicrosoftのインフラストラクチャクラウドプラットフォームであるWindows Azureで受け取った結果リストのリーダーのパフォーマンスより悪くないことを示しました。
結果は次のとおりです。
テスト概要表：
|
日付 |
CROCクラウド |
アマゾン |
HPクラウド |
ラックスペース |
ソフトレイヤー |
Windows Azure |
|
06/20/2013 |
1468.9 |
337.9 |
1350.4 |
561.6 |
1137.2 |
1437.6 |
|
06/21/2013 |
1454.4 |
375 |
1338.6 |
569.5 |
1139.4 |
1446.1 |
|
06/22/2013 |
1459.8 |
421.2 |
1352.7 |
568.7 |
1140.7 |
1444.5 |
|
06/23/2013 |
1446.7 |
378.6 |
1333.5 |
469.1 |
1137.1 |
1451 |
|
06/24/2013 |
1470.1 |
378.5 |
1344.9 |
568 |
1137.5 |
1433.2 |
|
06/25/2013 |
1467.8 |
381.5 |
1326.4 |
565.2 |
1142.3 |
1447.1 |
|
06/26/2013 |
1465.8 |
380.2 |
1338.2 |
563.6 |
1134.1 |
1449.3 |
|
06/27/2013 |
1439.9 |
375.8 |
1328.8 |
574.1 |
1140 |
1442.6 |
|
06/28/2013 |
1430.2 |
376.5 |
1327.7 |
537.3 |
1139 |
1434 |
|
06/29/2013 |
1419.1 |
373.2 |
1341.6 |
575.2 |
1135 |
1442.2 |