Linuxコンテナ化の詳細-LXCおよびOpenVZパート2

この記事は、 Containers- Linuxでの クラウドとContainerizationの詳細-LXCとOpenVZの出版物で始まったシリーズの続きです。 パート1



未来についての出版物をスキップできる場合、記事「パート1」は、私たちが話していることを理解するために読む必要があります。

コンテナハードウェアリソース制限サブシステムの技術的な実装

説明を完全にするために、システムリソースと権利だけでなく、ハードウェアリソースも区切るという側面に必ず触れなければなりません。



ユーザー間で共有する必要があるリソース：

• CPU
• ハードディスク（ロード）
• メモリ（ボリューム）

このようなすべての制限には、cgroupsサブシステムが使用されます。 入力/出力負荷はcgroups blkioサブシステムを使用して修正できます。バイト/秒およびオペレーション/秒（IOPS）でハード制限を設定する可能性、および重み係数（つまり、10サーバー全体の％）。 メモリはメモリcgroupによって制限されます。ここではすべてが非常に単純です-コンテナがそれを超える場合、RAMの量を示します-プロセスはOOMメッセージを受け取ります。 プロセッサーの場合、負荷をパーセントで指定する機能のみが許可されます。これは、Linuxでのスケジューラー実装の特性によって説明されます。



合計、リソース使用の差別化を実装するために、次のcgroupを使用しました。

• CPU
• 記憶
• ブルキオ

コンテナ使用時の一般的な問題

コンテナのすべての利点を説明したとき、コンテナの欠点に対処しないことを意図的に決めました。これは非常に膨大なトピックであり、多くの説明が必要だからです。



それでは、行きましょう：

1. Linuxアップストリームコンテナには、コンテナ間で/ procファイルシステムを分離する際の問題があります。 OpenVZはこの問題を解決しました。
2. Linuxアップストリームコンテナでは、完全に独立したファイルシステムを使用せずに、コンテナで使用可能なディスクの量を制限することはできません（これは、不便でサポートに非常に不便です）。 将来この問題に対する有望な解決策として、サブボリュームファイルシステムBtrfsの機能に注目する価値があります。これにより、同じファイルシステム内に完全に隔離された領域（固定ボリューム）を作成できます。
3. コンテナ化を使用する場合、物理サーバーで実行されているのと同じOSのみがクライアントOSとして使用できます。 これは技術的なコンテキストの欠陥ではなく、実装の機能です。 つまり、物理Linuxマシンで実行できるのはLinuxのみです。 別のOSを実行する必要がある場合、KVMは非常に優れたサービスを提供します。これは、OpenVZカーネルとLinuxアップストリームの両方で十分にサポートされています（正直なところ、こちらの方が優れています）。
4. 完全仮想化よりもセキュリティが低い。 コンテナからハードウェアノード自体の障害につながるエクスプロイトを作成する可能性があります。 Linuxカーネルのコンテナーを使用する場合、OpenVZでの分離がはるかに改善されているため、ハードウェアサーバーを無効にする方法の数が決定的に多くなっています（UBCの細かな制限、およびアップストリームカーネルでは利用できない追加のチェックのため）。
5. 安定した使用のために（しかし、本番環境については話をしていません！）Linuxアップストリームコンテナーは、約3.8（理想的には3.10）のカーネルから開始できますが、カーネルの多くの安定したディストリビューションでは、カーネルはより若く、すべての機能を使用する方法はありません。 Linuxのアップストリームコンテナを操作するための非常に良いオプションは、 Oracleのカーネルです 。これはバージョン3.8であり、コンテナが産業で使用できる状態にあると主張しています。
6. ディストリビューターの製造元からのサポートはありません。たとえば、標準的な方法では、Fedora 20をコンテナー内に配置することはできませんが、仮想マシンでは可能です。 インストールの質問にはDebianの質問がより簡単であり、debootstrapパッケージは必要なディストリビューションを簡単にインストールできます。 OpenVZの場合、開発者がOSの事前に組み立てられたイメージを使用して問題を解決します。
7. 管理ユーティリティの問題。 これは非常に重要なポイントであるため、私の意見では、これについてさらに詳しく検討し、記事の最後に個別にペイントすることにしました。
8. ネットワーク接続速度を制限するための組み込みソリューションの欠如-この問題は、LinuxアップストリームコンテナーとOpenVZの両方に影響します。 もちろん、tcに基づいて独自のソリューションを作成することは可能ですが、そのような便利な機能は単純にそうでなければなりません。

標準のLinuxコンテナ化に対するOpenVZの利点

OpenVZとLinuxのアップストリームコンテナーは、アーキテクチャと実装が類似した非常に類似したテクノロジーですが、多くの違いがあります。 違いの一部は、現在のバージョンのOpenVZが2.6.32 RHELカーネルでサポートされているという事実によるものです。 やめて！ 私と同じように見えますか？ 2.6.32コアですか？ ただし、このカーネルが古いことを恐れないでください。RedHatは新しいブランチからコードをバックポートするために多大な作業を行っており、このカーネルは機能的に3.xに非常に近く、同時に標準「バニラ」2.6から非常に遠いためです。 32。



したがって、RHEL6 OpenVZコアと現在のバージョンのアップストリームカーネル（3.12）を比較すると。 プロセッサとディスクリソースの分離レベルは同じレベルですが、以下に注意する価値のある微妙な点がいくつかあります。



上流のLinuxカーネルにはないOpenVZには正確に何がありますか：

1. vSwapシステムが使用されます。これにより、コンテナーのオーバーコミットを構成でき、仮想（仮想的に（約100メガバイト/秒の速度で）スローダウンするため）SWAPを発行することもできます。
2. より細かいUBCカウンターにより、コンテナが消費するRAMをより正確に計算し、使用中のカーネルメモリ、ソケットメモリ、割り当て済みおよび実際に使用中のメモリ、ページ数shmメモリなどを計算できます。
3. 各コンテナによるページキャッシュの消費を考慮する機能
4. LVMに類似した機能を備えたploopに基づいて構築された、使用可能なコンテナスペースを制限する機能、スナップショットを作成する機能、オンラインモードで増減する機能を備えたストレージシステム。 このファイルシステムは、完全な仮想化システムのレベルで分離レベルを提供します。
5. ダウンタイムがゼロ（1 pingの損失）でサーバーからサーバーへのライブマイグレーションのサポートと、非常に効率的なアルゴリズムの使用

ご覧のとおり、OpenVZのほぼすべての利点は、ソリューションの実際の運用に焦点を当てており、Linuxのアップストリームコンテナーのように、この機会またはその機会を実装するメカニズムを提供することに焦点を当てていません。

ユーザー空間からの問題

残念ながら、コンテナを管理する統一された方法はありません。 OpenVZはこれにvzctlを使用します。これは、バージョン3.x以降の通常のアップストリームカーネルでもコンテナーを管理できます。また、Fedora-20パッケージに含まれており、外部の依存関係なしでインストールおよび使用できます。 LXCおよびdocker（LXCにも基づいています）もありますが、コンテナーユーザーが必要とする可能性のあるすべての機能を完全にはカバーしていません。 さらに、Linux Upstream Containersは非常に非標準的な場所で使用されています 。多くのディストリビューションで使用されているsystemd初期化システムであるsystemd-nspaw機能です。



したがって、Linuxでコンテナーを管理するための便利で、有能で、柔軟性があり、適切に設計されたフレームワークを実装する問題は開かれており、それを書くことで世界を変えることができます（笑） 2013年。

結論

これまで見てきたように、Linuxでのコンテナー化は非常に活発に開発されており、今後数年間で、アップストリームカーネルでの本格的なコンテナー化の準備が整います。 ただし、産業用の場合（ここでは、クライアントを使用して相互に分離し、独自のサービスではありません）、コンテナはOpenVZを使用する場合にのみ準備できます。 ただし、独自の目的でコンテナ化が必要な場合は、Linuxアップストリームコンテナが最適な選択肢です。カーネルの現在のバージョンを心配するだけです。



また、特に複雑な技術的問題の編集に協力してくれたAndrey Wagin avaginにも感謝します。



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

CTO FastVPS LLC