コンテナが必要な場合は、すでに理解しています。 しかし、どのタイプのサーバーが最適なのか知っていましたか？ Dockerや他の同様のコンテナー管理環境などのホスティングプラットフォームには、仮想マシンよりも専用サーバーを使用する方が良いでしょうか？
もちろん、答えは多くのパラメーターに依存します。 この記事では、このようなパラメーターと、専用サーバーまたは仮想マシンでのコンテナーの使用に関する賛否両論について説明します。 Dockerに焦点を当てますが、結論は一般的にどのコンテナー管理プラットフォームにも当てはまります。
専用サーバーまたは仮想マシン？
ソフトウェア環境をホストするための専用サーバーと仮想マシンの長所と短所を比較することは、新しいタスクではありません。 テクニカルリーダーは、Dockerが登場するずっと前の2000年代にデータセンターで仮想化が広く使用されたときに、このことについて考え始めました。
要するに、専用サーバーの主な利点は次のとおりです。
- 比較的高速 。 システムリソースはハードウェアエミュレーションに費やされません。
- 機器のリソースは、需要の高い時期にアイドル状態にならないため、完全に使用されます。
- 簡素化された管理。 インフラストラクチャに含まれるホスト、ネットワーク、およびドライブが少なくなります。
仮想マシンでは、次の利点があります。
- あるサーバーから別のサーバーに仮想マシンイメージを移動する間で、アプリケーションを簡単に移動できます。
- 異なる仮想サーバーで実行されているアプリケーションの分離。 これにより、セキュリティの問題が解決され、管理の複雑さが軽減されます。
- 物理サーバーが異なっていても、すべてのアプリケーションを同じタイプの仮想マシンにデプロイすることにより、インフラストラクチャ全体のソフトウェア環境の均一性を維持する機能。
しかし、仮想マシンを使用すると、 いくつかの欠点もあります。 これらには次のものが含まれます。
- サーバーリソースが完全に使用されていない可能性があります。 たとえば、仮想マシンイメージを保存するためにサーバーにスペースを割り当てると、ディスクに関連付けられた仮想マシンが割り当てられた量全体を使用しなくても、このメモリ量は他の目的に使用できなくなります。
- 仮想マシンを使用して、物理機器を直接操作することはできません。 たとえば、GPUで仮想マシンの代わりに計算操作を実行する場合、仮想マシンは対応するサーバー環境とは非接触で動作するため、少なくとも単純な方法では何も起こりません。
- 原則として、仮想マシンのリソースは仮想サーバーのハードウェアのエミュレートに費やされるため、仮想マシンは物理サーバーほど速く動作しません。
これらの制限を克服するために、システム管理者は最新の仮想化プラットフォームに基づいたいくつかのトリックに頼ることができます。 たとえば、仮想マシンで使用されるにつれてボリュームが拡大するダイナミックディスクイメージを作成できます。 つまり、ユーザーが実際に必要とするまで、メモリの量はロックされません。 特定の場合に、仮想マシンが物理機器に直接アクセスできるように、バックホールを使用できます。
ただし、これらのトリックは必ずしも効果的ではありません。 このアプローチは、すべてのタイプのホストおよびゲストオペレーティングシステムに適用できるわけではありません。一般に、これはすべて管理者の追加の負担になります。 使用するアプリケーションが物理的な機器に直接アクセスする必要がある場合は、そのような機器ですぐに実行することをお勧めします。
または、物理サーバー上のコンテナでアプリケーションを実行し、1つの石で2羽の鳥を殺すことができます。
四角い円：専用サーバーでのコンテナーの動作
物理サーバーでコンテナを使用すると、仮想マシンの多くの利点が得られますが、仮想化の欠点は回避されます。
専用サーバー上のコンテナを使用すると、次のことができます。
- 交通手段に頼らずにハードウェアにアクセスできます。 アプリケーションは、サーバーと同じオペレーティングシステムで実行されます。
- システムリソースを効率的に使用します。 原則として、データの計算、保存、および送信のためにコンテナに割り当てられるリソースを制限することは可能ですが、特定のコンテナの操作専用にこれらのリソースを割り当てる必要はありません。 つまり、サーバーは必要に応じてシステムリソースを配布できます。
- ホストサーバーからアプリケーションを分離するハードウェアエミュレーションがないため、アプリケーション専用のサーバーのパフォーマンスを取得します。
さらに、専用サーバーでコンテナーを使用する場合、原則として仮想マシンのみに関連付けられている利点にアクセスできます。
- あるホストサーバーから別のホストサーバーにすばやく移行できるローミング環境でアプリケーションを実行する機能。
- アプリケーションの分離。 おそらくコンテナの助けを借りて仮想マシンと同じ分離を達成することはできませんが、その機能により、管理者はアプリケーションの相互作用を防ぎ、各コンテナのリソースの権利と使用を制限できます。
一般に、専用サーバー上のコンテナを使用すると
コンテナを常に専用サーバーに配置するべきではない理由。 おそらく、専用のサーバーでコンテナを直接起動しないのはなぜでしょうか？ このアプローチがすべての利点を提供する場合、なぜ他に必要なのですか？
仮想マシンではなく専用サーバーでコンテナをホストすることの次の欠点を考慮してください。
- 物理サーバーのアップグレードは困難です。 サーバーを新しいサーバーに交換する場合は、新しいサーバーでコンテナーソフトウェア環境を最初から再作成する必要があります。 コンテナソフトウェア環境が仮想マシンイメージの一部である場合、新しいサーバーに移動するだけで済みます。
- ほとんどのクラウドサービスは、仮想マシンの使用を主張しています。 RackspaceのOnMetalやOracleのBare Metal Cloud Serviceなどの専用サーバーを使用したクラウドホスティングもあります。 しかし、概してクラウドでの作業には仮想マシンの使用が含まれます。 コンテナにクラウドプラットフォームを使用する場合は、仮想マシンを使用する必要があります。
- コンテナは、すべてのハードウェアおよびソフトウェア設定をサポートしているわけではありません。 現在、VMwareなどの仮想化プラットフォームや、ほぼすべてのオペレーティングシステムとサーバーで動作するKVMに、ほぼすべての種類のオペレーティングシステムを配置できます。 しかし、Dockerの可能性は限られています。 物理サーバーでホストされている場合、Linuxおよび一部のWindowsサーバーでのみ機能します。 つまり、専用サーバーがWindows Server 2012などを使用していて、Dockerが現在それをサポートしておらず、Dockerをその上でホストする場合は、Dockerの要件に準拠するために、Windowsサーバーに加えて仮想マシンをインストールする必要があります。
- LinuxサーバーをWindowsサーバーで実行したり、その逆を実行することはできません。 この欠陥は、 LinuxコンテナがLinuxサーバーでのみ機能することを意味します。 Windowsを備えた専用サーバーがあり、そのサーバー上でDockerコンテナーを実行して、Linux用に開発されたアプリケーションをホストするとします。 Linux仮想マシンをWindowsサーバーにインストールし、Dockerをホストするための環境として使用する必要があります。
- 専用サーバーでは、以前の状態に戻ることはできません。 ほとんどの最新の仮想化プラットフォームでは、非常に便利な機能が実装されています。必要に応じて、仮想マシンのスナップショットを作成し、後でその状態に戻すことができます。 これは専用サーバーでは機能しません（技術的には、オペレーティングシステムまたはファイルシステム自体のバックアップ機能を使用できる場合がありますが、このプロセスは仮想マシンほどスムーズではありません）。 そして、一般的に、スナップショット、およびコンテナの以前の状態への復帰、概念は無意味です。 コンテナ自体は一時的なものであり、以前の状態はありません。 最後に、以前の状態への最も簡単な復帰は、仮想マシンでのみ実装できます。
おわりに
コンテナを専用サーバーに配置するか、仮想マシンに配置するかを決めるのは簡単ではありません。 組織に最適なオプションを決定するには、すべての長所と短所を比較する必要があります。
コンテナをどこに配置しても、アプリケーションの移植性、スケーラビリティ、ダイナミズムなど、コンテナ化の基本的な特性を活用できることは喜ばしいことです。
プロジェクトに仮想サーバーまたは専用サーバーを選択する場合は、 VDS.menuおよびDEDICATED.menuディレクトリを使用してみてください。