コンテナはクラウドの未来です

オラ、Habrasociety！

はじめに

このレポートはもともと、2013年8月24〜25日にエストニアのタリンで開催されたFastVPS ROCK IT 2013の会議での講演のために準備されました。



誰かが個人的にそれを聞いたことがあるかもしれません（ありがとう！）、しかし、この出版物はより詳細であり、レポートから省略された多くの詳細を考慮しているので、とにかく読むことをお勧めします



この出版物は、Linuxを搭載した物理サーバーをベースにした複数の仮想環境を展開するためのオープンソース市場で利用可能なツールの概要を提供するとともに、コンテナを使用してクラウドを作成する利点について説明します:)

仮想環境を作成するためのLinuxオープンソースソリューション

今日の物語のヒーローに会おう！











名前で：

• Kvm
• Xen
• Linux VServer
• Openvz
• LXC（Linuxコンテナー）

表：Linuxで仮想環境を実装するための既存のテクノロジーの比較







Oracle VirtualBoxは完全にオープンではないため、意図的にテーブルに含まれていなかったことに注意してください。また、記事ではオープンテクノロジーのみを検討しています。



この表から、今日の産業で使用できる技術はKVM、Xen、およびOpenVZの3つのみであると簡単に結論付けることができます。 また、LXCテクノロジーは非常に活発なペースで開発されているため、この理由から単に検討する必要があります。 次に、4つのテクノロジーすべてが2つの分離アプローチを実装します。これについては、完全仮想化とコンテナー化について説明します。

完全仮想化

純粋に理論的な説明から離れて、KVMの例の視覚的な図を見てみましょう。







ご覧のとおり、3つのレベルがあります。

• ハードウェア（ディスク、NIC、CPU、イメージ内のメモリ-ストレージシステム、ネットワークデバイス、プロセッサ、およびメモリ）
• Linuxカーネル（多かれ少なかれ最新のディストリビューションからの絶対的なものですが、2.6.32以降が推奨されます。明確にするために、HWN、HardWare Nodeと呼びましょう）
• 通常のLinuxデーモンの隣のLinuxシステムで通常のプロセスのように実行される仮想マシン（クライアントOS）

ここでのすべての相互作用は非常に透過的です-ベースLinuxカーネル（HWN）はハードウェア（プロセッサ、メモリ、I / O）と相互作用し、さらに、本格的なLinux、FreeBSD、または窓 これらは非常に一般的なプロセスではないことに注意してください;仮想マシンの動作は、クライアントオペレーティングシステムからHWNにシステムコールを変換するカーネルモジュール（KVM）によって保証されます。 この作業の説明は完全に正しいとはいえませんが、このアプローチの意味を完全に伝えています。最も重要なことは、クライアントOS呼び出しからHWN呼び出しへの変換が特別なプロセッサーテクノロジー（AMD-V、Intel VT）を使用して実行されることです。



このタイプの分離の欠点は、実際のハードウェアと仮想環境の間に抽象化の追加のハードウェアソフトウェア層を使用するため、ディスクサブシステム、ネットワークサブシステム、メモリ、プロセッサの動作の遅延が減少することです。 さまざまなテクノロジーとアプローチ（たとえば、ソフトウェアvirtio、ハードウェアVT-d）の力により、これらの遅延は最小限に抑えられますが、これは追加の抽象化レイヤーであるため、完全に排除することはできません（ハードウェアに仮想化が組み込まれていない場合）支払います。

完全仮想化の実装コスト

最近のIBMの調査によると、オーバーヘッド（仮想環境内のアプリケーションのパフォーマンスと、仮想化をまったく使用せずに実行されている同じアプリケーションのパフォーマンスの差）によると、KVM I / Oテクノロジーは、SUSE Linux Enterprise Server 11 Service Pack 3でテストした場合、約15％です。



また、Journal of Physics：Conference 219（2010）には非常に興味深いテストがあります。このテストでは、プロセッサのオーバーヘッドが3〜4％、ディスクI / Oの20〜30％が発表されています。



同時に、2013年のRedHat プレゼンテーションでは、12％の数値（つまり、仮想化なしで実行されている構成のパフォーマンスの88％）が発表されました。



もちろん、これらのテストはさまざまなソフトウェア構成、さまざまな負荷パターン、さまざまな機器で実行され、それらの一部は正しく実行されなかったことも認めていますが、その本質はKVMとXenの両方を使用する場合のオーバーヘッド（オーバーヘッド）に要約されます使用するソフトウェアの種類とシステムの構成に応じて5〜15％に達します。 同意しますか？

コンテナ化

同じことを行い、図を使用します。







OpenVZとLXCの両方について、下記のすべてが当てはまることを一度に予約したいと思います。 これらの技術は非常によく似ており、非常に近い親類です（次の出版物でこのトピックを公開するつもりです）。



イメージはわずかに異なるスタイルで描画されますが、重要な違いはすぐに明らかになります-コアは1つだけ使用され、仮想マシン（VM）の言及はありません！ しかし、それはどのように機能しますか？ 低レベルでは、すべてが同じように行われます。LinuxHWNカーネルはハードウェアと対話し、仮想環境からハードウェアへのアクセスに関連するすべての要求を満たします。 しかし、仮想環境はどのように互いに分離されていますか？ これらは、組み込みのLinuxカーネルメカニズムを使用して分離されます！



まず第一に、これはchrootの修正された類似物です（修正は主に保護に関係するため、chrootの環境からルートファイルシステムにエスケープすることはできません）。これは私たち全員によく知られているもので、同じファイルシステム内で互いに分離された階層を作成できます。 ただし、chrootは、たとえば、独自のinitプロセス（PIDデータを持つinitプロセスが既にHWNに存在するため、pid 1）を開始することはできません。これは、コンテナー内に完全に分離されたクライアントOSが必要な場合の必須要件です。 このため、PID名前空間メカニズムが使用されます。これは、各chroot環境内でHWNから完全に独立したプロセス識別子システムを作成します。initプロセスが既にサーバー自体で実行されている場合でも、PID 1を持つ独自のプロセスを作成できます。 一般的なケースでは、互いに接続されていない数百または数千の個別のコンテナを作成できます。



それでは、メモリ、CPU、ハードドライブはどのように制限されていますか？ また、これらはcgroupメカニズムによって制限されます。このメカニズムは、ちなみに、KVMテクノロジーでもまったく同じ目的で使用されます。

コンテナ化費用

前に説明したように、分離技術には、必要かどうかにかかわらずオーバーヘッドがあります。 しかし、コンテナ化の場合、非常に単純な変換が使用されるため、このオーバーヘッドは無視できます（0.1〜1％）。これは多くの場合、文字通り指で説明できます。 たとえば、PIDプロセスとソケットスペースの分離は、プロセスが属するコンテナを示す4バイトの識別子を追加することで行われます。 メモリを使用すると、すべてが少し複雑になり、その特定の損失が発生します（メモリ割り当ての特性により）が、これはメモリ割り当てとメモリ操作の速度にほとんど影響しません。 ディスクシステムと入出力サブシステムでは、状況は似ています。 OpenVZのオーバーヘッドの見積もりの​​数値は、ブラジル大学のHPC エンジニアおよびHPCの研究者 による 研究で示されており、負荷の種類およびテスト方法に応じて0.1〜1％の範囲にあります。

コンテナ化と仮想化

それで、私たちは最初に述べたトピックに来ます！ 完全な仮想化テクノロジーとコンテナー化テクノロジーのオーバーヘッドについて説明しましたが、今度はそれらを互いに直接比較するときです。 OpenVZの代わりにPCSの商用バージョンが使用されるいくつかのテストでは、オープンOSと商用OSの両方で使用されるカーネルが完全に同一であるため、テストへの影響は最小限です。



このネットワークには、3人のプレーヤー全員が参加して実施した高品質のテストがかなりあり、それらのほとんどすべてがOpenVZ開発者であるParallelsによって実施されました。 そのようなテストがチェックおよび繰り返しの可能性なしに行われた場合、バイアスについて疑問が生じる可能性があります。



私はかなり長い間これを達成する方法を考えましたが、Intel-vConsolidateによって開発されたテスト方法論に基づいてKVM、XEN、およびOpenVZ / PCSがテストされ、自宅ですべての結果を確認できる標準化されたLAMPテストと彼らの真実を確かめてください。







このテストは純粋にオウムで行われるため、中間グラフは提供せず、最終結果を導き出しました。 おわかりのように、OpenVZの顔の利点。 もちろん、Intelはテストで多くのことを考慮しましたが、これらの数値を解釈することは依然として非常に困難です。



したがって、Parallelsの同じドキュメントから、より理解しやすいLAMPテストを提案します。これは、実行中の仮想環境の数に応じてLAMPアプリケーションのパフォーマンスをテストします。







LAMPアプリケーションによって実行されるトランザクションの総数がほぼ2倍に増加していることが、すべて明らかになり、はっきりと見えます。 さらに何を求めることができますか？ :)



もちろん、さらに多くのテストをカバーすることもできましたが、残念ながら、これまでのところ、典型的なHabrの記事のフレームワークを超えているので、 ここでお願いします 。



コンテナ化に基づいたソリューションにより、鉄から可能な容量のほとんどすべてを絞り出すことができると納得できたことを願っています。

コンテナ化はクラウドの未来です！

この記事では、完全仮想化の代わりにコンテナ化を使用する場合のハードウェアリソースの使用効率により、すべてのサーバーコンピューティングリソースの最大10％（平均評価）を節約できることを証明しようとしました。 百分率で判断するのは非常に難しく、100台のサーバーがあり、完全な仮想化を使用して特定の問題を解決したことを想像するのははるかに簡単です。その後、コンテナー化を実装することで、多くの電力を消費するほぼ10台の本格的なサーバーを解放し、スペースを取ります（これは非常に高価です）現代のデータセンター）、彼ら自身は多額の費用がかかり、またそれらにサービスを提供するスタッフを必要とします。



抽象的な「高価な」から実数に逃げる方法は？ 私たちにとって最も重要な節約は、電気の節約です。 Intelによると 、電力コストは、データセンターを運用するための全運用コストのほぼ10％を占めています。 また、環境保護庁によると 、米国環境保護庁は、米国で生成されたすべての電力のほぼ1.5％を消費しています。 したがって、私たちは企業のお金を節約するだけでなく、電力消費量の削減と効率的な使用により、環境の保全に大きく貢献しています！



また、世界最大のコンピューティングシステムであるGoogle 、 Yandex 、 Heroku、および他の多くの独自のクラウドがLXCテクノロジーを使用して構築されていることも注目に値します。これは、クラウドコンピューティングにおけるコンテナー化の利点を実証し、実際の企業の例を示しています。



さらに、有声コンテナ化テクノロジーの両方-OpenVZとLXCは無料のライセンスを持ち、非常に活発に開発されており、LXCは（一部ではありますが）昨年1年半にインストールされたほぼすべてのLinuxサーバーにあります オープンライセンスとアクティブな開発者コミュニティは、近い将来の技術の成功の鍵です。



今後の出版物では、OpenVZおよびLXCテクノロジーに焦点を当て、それらの比較分析も行います:)



更新、一連の出版物の継続：

• Linuxでのコンテナー化の詳細-LXCおよびOpenVZ。 パート1

また、LXCテクノロジーの特に複雑な側面を説明してくれたVasily Averin（Parallels）にも感謝します。



敬具パベル・オディンツォフ

CTO FastVPS LLC