• DATE:
  • 2015.05.22
  • 気づいた事、発見した事

  • TITLE:
  • 第181回「新技術への移行が、更に加速されて」F.W

業務関連のネタで恐縮ですが、RHEL7の新技術検証を行う機会を得たので、昔のUNIXや最近までのLINUXとは大きく様変わりしてきた事を痛感します。

つい最近までは、仮想化と言えば、VMWareやXEN、KVM、Hyper-V等によるサーバ集約や、仮想リソースバランスの管理が中心、完全仮想化や準仮想化を実現する、ハイパーバイザーが主役でした。

ところが、昨年度辺りから特に躍進している仮想技術が、Dockerなどに代表される、LXC系のコンテナ仮想化技術です。
元々は、FreeBSDやNetBSDなどで利用されていたJailをベースに、カーネルだけを共通化して、ユーザランド部分を仮想化する技術となります。

何故、Dockerなどのコンテナ仮想化が持て囃されるかは、観点によって諸論がありますが、一番大きな点はハイパーバイザー層が存在しない為に仮想化実行負荷が軽減されて、リソースが軽減できる点と、処理速度の改善や、仮想化の集約度が向上する点も見逃せません。

また、AmazonAWSやGoogleAPPS、WindowsAzureなどのクラウドサービスには、コンテナ型仮想化でリソースを節約し、CPUやネットワークなどの帯域制御で、顧客へSLAベースのサービスを簡単に提供できる点も歓迎されています。

一方のVMWareでは、DRSなどによる自動負荷分散機能が合るので対抗可能なようにも思えますが、VMWareやHyper-Vなどの仮想ゲストをライブマイグレーションで負荷分散する場合、最低でも数十GB単位のOSイメージを、ノード間で遷移させるため、非常に負荷の大きな処理となります。

しかし、コンテナ型仮想化ではカーネル部分を除くユーザランドのみが対象となるため、同様のライブマイグレーションでは数十MB〜数百MBのデータをノード間で遷移させるだけで処理が完了します。

昨今のHW性能におけるノード間遷移では、VMの場合で数分〜十数分、コンテナの場合は数秒〜数十秒となり、クラウドのような大規模サービスではVM型仮想化が淘汰されて、コンテナ型仮想化へ移行せざるを得ないのでした。

また、コンテナ型仮想化機能が改善され、従来は不可能だったある程度のマルチOSに対応した点も強みです。

例えば、CentOS7.1環境で、CentOS6.xや5.x、UbuntuやDebianなどの異なるディストリビューションが、コンテナとして稼働します。

むしろ、CoreOSなどのクラスタ対応のコンテナ仮想化専用ディストリビューション上で、データセンターなどの大規模クラウドが稼働しており、古き良き時代のディストリビューション制約などは無くなってしまいました。

更に、ベアメタル推奨のDBサーバなども、コンテナ仮想化で実行効率が改善されて、(起動コンテナ)数の論理がまかり通る時代となりました。
そう、Hadoopの大規模DBは上記のコンテナ運用推奨で、従来のベアメタル運用では全く性能が出ません。

一昔前には、ビルの1フロアを占拠して隆盛を極めたメインフレームは、今や仮想化ゲストとして動作したり、SystemZのような高機能サーバへの転身を果たしています。

旧来の技術的な概念は次々と書き換えられ、何処まで進歩するのか楽しみな今日この頃です。

この記事はワタシが書きました。

システム部

匿名希望

同じ人が書いた記事

第200回「油断」F.W


2016.03.01

正月〜社員旅行と、自分の年齢的には負荷の多いイベントを過ごし、気づ...

第192回「落葉」F.W


2015.11.21

猛暑のさ中で発見した大阪城公園経由の通勤ルートですが、季節の 移...

第187回「大阪城公園」...


2015.08.21

暑くて溶けてしまいそうな毎日が続いて大変ですね。 暑さ対策の...

カテゴリー一覧