Archive | 日本語

ヴイエムウェア株式会社 ユーザ事例

VMwareによるサーバ統合でサーバ台数を80台から5台に削減。運用コストを50% 削減し、新規サービスにも迅速な対応を実現。

会社にとってまず最も重要なメリットとなるものとして、会社としても高く評価することになるのは、コストメリットです。運用コストの50% を削減したと言っても差し支えないでしょう。

— 株式会社GABA IT 部門 インフラストラクチャー課 シニア・マネージャー ニャナデバ クラカニカ 氏

事例ビデオ

詳細(PDF)

3,562 total views, no views today

0

vCenterとメモリ・メトリック

仮想マシンレベルで表示されるメモリーの詳細はvSphere クライントに数カ所配置されています。メモリ メトリックの解釈に戸惑う方も多くいるでしょう。というのも、用語的に似たような物が多く、それらが必ずしも同じことを指すとは限らないからです。サマリタブ内を見てみましょう。

ではまずはじめに全般(General)から。

de-2-1

原文: http://www.yellow-bricks.com

上記のスクリーンショットでは二つの項目がメモリーに関連します。

メモリ (2048MB)
メモリ オーバーヘッド (110.63MB)
最初の「メモリ」は、仮想マシンのために確保したメモリの量です。次の「メモリ オーバーヘッド」はVMカーネルが、該当する仮想マシンのために必要とするメモリのことです。ページテーブル、フレームバッファなどがそうです。

次にリソース(Resources)。

de-2-2

原文: http://www.yellow-bricks.com

同じく二つ、メモリに関連する項目があります。

消費されたホスト メモリ (1390.00MB)
アクティブなゲスト メモリ (61.00MB)
消費されたメモリとアクティブなメモリは一見すると理解しにくいかもしれませんが、頭を抱えるような物ではありません。「消費されたホスト メモリ」はゲストの為に割り当てられた、ホストの物理メモリです。メモリ オーバーヘッドも含まれるため、「消費された」メモリはゲストに与えられたメモリの容量を超えることもあります。余談ではありますが、パフォーマンス タブのパフォーマンス チャートの凡例内の消費カウンターには、実際のところメモリ オーバーヘッドは含まれません。

アクティブなゲスト メモリはVMカーネルが予想する、仮想マシンによって実際に使用されているメモリのことです。この「予想」は統計的なデータのサンプリングで計算された「予想値」です。

次のタブ、リソース割り当ては見る限りサマリより詳細です。

de-2-3

原文: http://www.yellow-bricks.com

メモリ セクションは三つのサブセクションから成り立ちます。

ホスト メモリ
消費 (1.36GB)
オーバーヘッドの消費 (42.00MB)

消費はゲストに割り当てられたメモリです。2GBの内、1.36GBがゲストによって消費されていることになります。オーバーヘッドの消費は仮想化オーバーヘッドによって消費されているメモリで、最初のスクリーンショットのVMカーネルが予想していた値よりも低いことが伺えます。簡単な方程式にするならば、こんな感じでしょう:
消費 = プライベート + オーバーヘッドの消費

ゲスト メモリ
プライベート (1.32GB)
共有 (700.00MB)
スワップ済み (0.00MB)
圧縮済み (0.00MB)
バルーン済み (0.00MB)
未アクセス (1.00MB)
有効 (102.00MB)

ゲスト メモリはいろいろあって、少々複雑に思えてくるでしょう。プライベートは物理的に確保されたメモリです。この場合1.32GBが物理的に確保されています。共有はTPS(Transparent Page Sharing*1)によって共有されるメモリです。スワップ済みはVMカーネルによって解放されたスワップ量。圧縮済みは仮想マシンの圧縮キャッシュに保存されたメモリの量。バルーン済みはバルーン ドライバによって開放されたメモリの量。後者三値はいずれも0が望ましいです。未アクセスは説明するのが厄介ですが、公式ドキュメントによると「ゲストによって決して参照されないメモリの量」です。

有効はアクティブに使用されているメモリです。コレも統計的なデータのサンプリングで計算された値です。(スクリーンショットを見て、61MBから102MBに変わったのがおわかりでしょう)最後のセクション、リソース設定ですが、ここにも二つ説明が必要な情報があります。
割り当ての最低限度 (2.14GB)
オーバーヘッド予約 (0.00MB)

割り当ての最低限度は全仮想マシンがフル稼働でメモリを消費するときに最低限に割り当てられるメモリのことです。仮想マシンに多大なメモリを割り当てる場合に要になるでしょう。オーバーヘッド予約はオーバーヘッド化メモリによって予約されているメモリの量。

元記事: http://www.yellow-bricks.com/2010/12/20/vcenter-and-memory-metrics/

17,513 total views, 23 views today

0

リソースプールと一斉移行

多くの組織がリソース・プールを使いホストにフォルダー構成を作り、vCenterのビューをクラスタ化します。仮想マシンはそのリソースプール内に置かれ、関連付け若しくはOS、アプリケーションの名前別にソートされるのが現状です。VMwareはこのためにリソースプールを開発したわけではありません。リソースプールは仮想マシンの負担を軽減し、仮想マシン群へのリソースを優先若しくは制限します。

ワークショップの際、リソースプールはフォルダー構成の為に用いられるものではないと参加者に教えております。 メインソリューションとしてリソースプールと仮想マシンのシブリング(兄弟)共有レベルを挙げます。

fd-1-1

原文: http://frankdenneman.nl/

シェア(共有)は仮想マシンへの優先度や他のリソースプールと同じ親リソースを持つ仮想マシンを指定します。要点はシブリング内でしか共有を直接比較することはできません。VM6とVM7の比率はどちらの優先度が高いのを示すのに対し、VM4とVM6の共有はどちらの優先度が高いのを示しません。

リソースプールについて以下の方々によって書かれました: “The resource pool priority-pie paradox”, (Craig Risinger)“Resource pools and shares” (Duncan Epping), “Don’t add resource pools for fun” (Eric Sloof) and “Resource pools caveats” (Bouke Groenescheij).

リソースプールをフォルダー構成として使わない他の理由として、vMotionのプロセスに影響を及ぼすおそれがあることが挙げられます。ネットワークの通信速度によりますが、vSphere4.1では同時に8つのvMotionプロセスを実行することができます。しかしこれらはリソースプールを変更しない場合、同じクラスタ内でしか実行することができません。以下のナレッジベースにてこの事が確認されました。(Knowledge Base article 1026102)幸いにもvMotionでは異なるリソースプールに一斉移行を実行する事は可能ですが、ターゲットが同じリソースプールの場合はこの限りではありません。 クラスタは最上位のリソースプールであるため、クラスタ間の移行は同時に一つのvMotionのオペレーションに限定されます。

fd-1-2

原文: http://frankdenneman.nl/

 

リソースプールをフォルダー構成の用に使用することがリソースの可用性に障害を及ぼす恐れがあるだけではなく、仮想マシンが他のリソースプールに移行される際に日常的なメンテナンスにも影響する恐れがある。

元記事: http://frankdenneman.nl/2010/09/resource-pools-and-simultaneous-vmotions/

7,733 total views, 8 views today

0

クラウド・コンピューティングを利用したオペレーティング・システムの未来

オペレーティング・システム(OS)はソフトウェアの一部で、コンピュータのハードウェアを管理し、様々なアプリケーション用の一般サービスを提供します。クラウド・コンピューティングの台頭にともなって、OSがまだ関連するのか、また、将来のクラウドにおいてOSがどんな役割を果たすのか疑問に思う人もいるでしょう。

OSの主な構成要素

オペレーティング・システムには、リアルタイムOSから、デスクトップOS、メインフレームOSまで様々な種類があり、最先端のOSがクラウドOSです。

一般的に、どのOSにも以下の共通する構成要素があります。

  • メモリやプロセスなどを管理するカーネル。
  • 異なるベンダーによる様々なハードウェアをサポートするデバイスドライバ。
  • コマンド・ライン・シェルやウィンドウ・システムを含むユーザー・インターフェース。
  • データを保持するための階層構造を提供するファイル・システム。
  • ユーザーを認証し、情報を守るセキュリティ。

OSのタイプにより、上記のどれかが欠けていたり、また、他の要素があることもあります。例えば、内蔵のOSにはユーザー・インターフェースがなく、全てが遠隔管理されていることもありますし、デスクトップOSには、計算機、カレンダー、ブラウザなど、頻繁に利用される追加アプリケーションがあるかもしれません。

押し出されたサンドイッチ

仮想化により、オペレーティング・システムはソフトウェア・スタック中に押し上げられました。ハードウェアを管理、抽象化する役割は仮想マシン下のハイパーバイザに譲られ、OSは仮想化によって、底から押し出された形になります。

仮想化のずっと以前から、データベースやメッセージングなどを含むソフトウェアのミドルウェアという概念がありました。これらは、より高いアプリケーションの階層プラットフォームを提供することにより、結果的に製品の質と開発者の生産性を高めます。 また、JVMや.NETのようなソフトウェア仮想マシンの台頭でOSサービスはプログラムAPIの上階層に抽象化されたので、アプリケーション開発の視点から見ると、OSはそれほど重要ではありません。OSは最上階からも押し出されたのです。

また、押し出そうとしても、現代のサンドイッチに「肉」はそんなにありません。VMware(ヴイエムウェア株式会社)の代表取締役、Paul Maritz(ポール・マリッツ)氏もVMworld(ヴイエムワールド)2010で「ハードウェアをどう構成するかという改革とサービスをどのようにアプリケーションに提供するかという改革は、今はもう、OS内では起こってはいない。」と指摘しています。言い換えれば、改革は現在、もっと下(仮想化)と上(ミドルウェア)で起こっているのです。

それでもOSがクラウド・コンピューティングの中で重要なのは何故か。

前にも言ったように、クラウド・コンピューティングは革命というよりは進歩です。 従来の方法を守るということは導入する上でとても大切で、その従来の方法の一つがオペレーティング・システムなのです。

技術的な面で、OSはとても重要な財産、IPアドレスを持っています。IPアドレスは、ネットワークにおいて2つの機能を持っています。1)出入りの際の交通整理を助けることと、 2) 個々の操作システムを特定することです。

ESXのようなハイパーバイザはIPアドレスを持ってはいますが、管理目的で持っているだけで、作業負荷の計算目的ではありません。ミドルウェアとアプリケーションはIPアドレスを持っていませんが、必要に応じて個々のサービスポートと自身を結び付けます。

2つ目の、IPがIDであるという役割はとても重要で、これは公共のインターフェースのようなものです。私達がIPをミドルウェアやアプリケーション層に移動させることができない限り、OSは重要な構成要素であり続けるのです。

IPv4を利用する場合、利用可能なIPv4アドレスが限られているため、IPをアプリケーションに割り当てることは実用的ではありません。IPv6を利用すると、IPアドレスが豊富にあるので、全て可能になりますが、そうなると、それが本当に必要か、また、その変更によって何が手に入るのかという疑問が生まれます。1例を挙げると、IP属性をミドルウェアやアプリケーションに移動することで人々の感じ方がガラリと変わり、それが導入を阻害する可能性があります。

JEOSは十分か。

仮想化にともなって、Just Enough Operating System(必要最小限のOS:JEOS)とVirtual Appliance(仮想アプライアンス:VA)の概念が生まれました。考え方としては、アプリケーションをサポートするための必要最低限まで、OSをそぎ落とすことができるということです。この比較では、仮想マシンを1つのアプリケーションとして考えてください。

1つには、操作システムのサイズを大幅に減らすことができます。ここでの挑戦は、どうやって以前と同じくらい便利に保つかということですが、私個人としては、その挑戦に対する完璧なソリューションはまだ見たことがありません。一般的に、多くの人は仮想アプライアンスを1つのアプリケーションと考えることにまだ戸惑いを感じます。そのような人は、それをまだOSとして見ており、同じ機能を期待してしまうのです(一連の新しいツールが、アプリケーションと同様にそれを管理することに役立つ場合を除く)。これは「次の大物」として、新しい改革の波を牽引するかもしれません。

OSの分散

OSは様々な環境において、異なる目的で利用されるため、一様に進化するとは考えられず、クラウド・コンピューティングを背景に、OSの未来はその目的別に分散していくと思います。

まず、企業用のOSです。Paul Maritz(ポール・マリッツ)氏が言ったように、OSはスタック中の構成要素であり続けます。クラウド・インフラをサポートする上で、まだ重要であり、安定した構成要素なのです。クラウドのタイプによっては、OSについて特に知らなくて良いかもしれませんが、オペレーションのためにはまだ重要です。緊急を要する課題は、新しいフィーチャーを改革することではなく、OSを信頼性があって、便利で、安全で、さらに新しいCPU構造についていけるようにすることです。

2つ目は、エンドユーザーのためのOSです。ブラウザがあればいいと思う人もいますが、私は仕事でもプライベートでも本格的なデスクトップOSの便利さを好みます。グーグル・クロムOSのようなブラウザ上でも似たようなユーザー満足度を築くことはできますが、それも私が既によく知っているフィーチャーをもったデスクトップです。こういったOSはクラウド中でも生きることができ、離れたところからエンドユーザーのために役立ちます。エンドユーザーはクラウドの外にもOSを必要とすることになるでしょう。これらのOSは、独立したソフトウェアとしてではなく、コンピューター・ハードウェアと強く結びつくことができるかもしれません。様々なデスクトップ、ネットブック、スマートフォン、セットトップボックスにまたがって、携行性を高め、個人データを簡単に管理するためには、より良い同期方法が必要になってくるでしょう。

元記事: http://www.doublecloud.org/2010/10/the-future-of-the-operating-system-in-cloud-computing/

3,625 total views, no views today

0

Powered by WordPress. Designed by WooThemes