Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Soichiro Anzai

作成者別アーカイブ: Soichiro Anzai

速報!VMware vSphere 6.0 新機能の概要

2015年3月12日に、vSphereの次バージョンとなる、VMware vSphere 6.0(以下vSphere 6.0)が公開されましたので、こちらのバージョンで追加された新機能・特徴の概要をご紹介します。

ただしこのBlogは、製品出荷前のバイナリ及びマニュアルを参照して記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

 

1.スケーラビリティ

以前のバージョンに比較して、ESXiホスト/仮想マシンのスケーラビリティが大きく拡張しております。

vCenterに関してもWindows版/アプライアンス版ともに下記の通り、管理可能なホスト数や仮想マシン数が拡張しております。

詳細な「構成の上限」に関する情報は、弊社ドキュメントを参照下さい。

 

2.プラットフォーム機能

  • ローカルの ESXi アカウントおよびパスワード管理の強化・・・ユーザーのアカウントのロックアウトや詳細設定による、複雑なルールが設定可能になり、ESXi の管理操作の監査性が向上しました。
  • Microsoft Cluster Service (MSCS) の機能拡張・・・MSCS 仮想マシンの vMotion をサポート。

 

3.vCenter Server

  • Platform Services Controller の導入・・・Platform Services Controller (以下 PSC)が導入され、単なるシングル サインオンの機能に加えてライセンス、証明機関の役割を持ちます。これにより柔軟な構成が可能になります。
  • 拡張リンク モードの使用・・・拡張リンク モードを使用することにより、すべてのリンクされた vCenter Server システムを表示し、まとめて検索することができます。

  • vCenter Server と ESXi の証明書ライフサイクル管理・・・vSphere 6.0 以降では、VVMware 認証局 (VMCA) が証明書を使用して環境のプロビジョニングを行います。これには、安全な接続用のマシン SSL 証明書、vCenter Single Sign-On への認証用のソリューション ユーザー証明書、vCenter Server に追加された ESXi ホスト用の証明書が含まれます

 

4.コア機能の強化

  • VMware vSphere vMotion(以下 vMotion)

vMotionについては、主に下記点で機能強化・改善が行われております。

 

・Cross vSwitch vMotion(別の仮想スイッチへの移行)・・・異なるタイプの仮想スイッチ間で仮想マシンを移行が可能です、但しDistributed Switch から標準スイッチへの vMotionは不可となります。(標準から標準または Distributed Switch に、および Distributed Switch から別の Distributed Switch に仮想マシンを移動することができます。)

・Cross vCenter vMotion(別のvCenter Server システムへの移行)・・・異なる vCenter Server インスタンス間で仮想マシンを移行。

・Long Distance vMotion(長距離 vMotion 移行)・・・ネットワークの最大往復待ち時間は 100 ミリ秒までの環境下で仮想マシンを移行。

・vMotion ネットワークの柔軟性の向上・・・vMotion TCP/IP スタックを使用して、vMotion のトラフィックを隔離し、このトラフィックの専用デフォルト ゲートウェイ、ルーティング テーブル、および DNS 構成を割り当て可能。

 

  • コンテンツライブラリの導入・・・仮想マシン テンプレートと vApp を簡単かつ効率的に管理が可能になります。

 

  • vSphere Fault Tolerance (FT)・・・vSphere Fault Tolerance は、最大で 4 つの vCPU を持つ対称型マルチプロセッサ (SMP) 仮想マシンに対応できます。以前のバージョンの vSphere(vSphere5.5以前) とは、Fault Tolerance に異なる技術が使用されております。

 

  • vSphere HA・・・仮想マシンのコンポーネント保護 (VMCP) の導入により、vSphere HA はデータストアのアクセス障害を検出して、影響を受ける仮想マシンの自動リカバリを実行できます。

 

5.仮想マシン

  • サポートゲストOSの拡張(詳細は互換性ガイドを参照ください)
  • ハードウェアバージョンのアップデート(ESXi 6.0以降:Virtual Hardware version 11)
  • 仮想マシンは、最大128個の仮想CPUと、4 TBの仮想メモリをサポート

 

6. Client

  • Web Clientの応答性が向上

 

7.ネットワーク

  • Network I/O Control バージョン 3・・・ホスト上の物理アダプタのキャパシティに基づいて、システム トラフィックのバンド幅を予約するメカニズムを導入しています。これにより、CPU およびメモリ リソースの割り当てに使用するモデルと同様に、仮想マシン ネットワーク アダプタ レベルでリソースを詳細に制御できます。

 

8.ストレージ

  • vSphere Virtual Volumes・・・外部ストレージアレイを仮想マシン単位で管理することができます。
  • 仮想マシン ストレージ ポリシー・・・ストレージ情報およびデータストアの特性を、特定のデータストアタイプ共通の管理機能を提供します。これにより、仮想マシンの配置について適切に決定し、ストレージ環境を監視することができます。
  • VMware Virtual SAN 6.0
・All Flash のサポートによるパフォーマンス・スケーラビリティの向上。
・ユーザビリティの向上(vSphere Web Client UIでサポート)。
・信頼性向上。

 

9.その他

  • VMware vSphere Replication

・End-to-End でのネットワークの圧縮・・・帯域幅の要件をさらに削減

・ネットワーク トラフィックを管理ネットワークから分離・・・帯域幅を制御し、パフォーマンスとセキュリティを向上

・Linux ファイル システムの静止機能 (quiescing)・・・Linux 仮想マシンをリカバリする際の信頼性を向上

 

次回から、各機能の詳細な情報をご紹介していきます。

VMworld 2014からの注目セッション第6回 – vC Ops の物理環境への拡張 & Hypericによる基幹系

みなさん、こんにちは。

今回の記事では、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、vCenter Operationsマネージャーを利用して、仮想環境上でアプリケーションの運用をより効率的に行う方法をご紹介します。

仮想環境上で稼働するアプリケーションを監視する方としては「Hyperic」(http://www.vmware.com/jp/products/vfabric-hyperic)を利用する方法があります。
Hypericを利用してゲストOS上にHypericエージェントをインストールすることにより、プロセスやWindows Serviceをはじめ、様々なアプリケーションのメトリックを収集することが可能となります。

さらにHypericで収集された情報をvCenter Operationsと連携することによりアプリケーションの稼働監視や分析を行うことが可能となります。
P12-Slide

VMworld 2014では下記のアプリケーションとの連携について将来バージョンにおける
連携が発表されております。

1.MSSQL

P22-Slide
ソリューションの特徴は以下です。
・自動検知による、MSSQLサービスとインスタンスの登録
・クラスタ構成の可視化
・デフォルトKPIによる静的および動的な監視
・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

2.Microsoft Exchange

P27-Slide

ソリューションの特徴は以下です。
・メールボックスとCASロールの自動検知
・DAGの検知
・関連する全サイトの情報伝搬
・デフォルトKPIによる静的および動的な監視
・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

3.vCAC

P32-Slide

4.SAP HANA
P34-Slide
ソリューションの特徴は以下です。
・エージェント不要でデータ収集
・SAP HANAシステムへは負荷は軽微
・Out-of-the-box ダッシュボードの提供(トラブルシューティング、診断法と分析)
・300以上は、SAP HANA Studioの中で入手不可能300以上の判断基準
・SAP HANAとvSphereの間の関係マッピング

 

まとめ
仮想環境上で稼働する様々なアプリケーションの管理・監視のソリューションについてご紹介いたしましたが、如何でしたでしょうか。

11/5(水)~6(木)にプリンスタワー東京でvForum2014が開催されます。

こちらでも、今回のVMworldと同様のセッションが数多く講演されますので、ぜひご来場ください。

vSphere App HA 1.1について

vSphere App HA (以下App HA)を使用すると、環境内の仮想マシンで実行中のアプリケーションの高可用性を定義できます。

先日、App HA 1.1がリリースされましたので、今バージョンで強化されたポイントについてご紹介します。

  • vSphere App HA には vSphere Web Client 5.1 U2 との下位互換性があります。
  • デフォルト以外のプラグインを管理するカスタムのサービスを作成することができます。
  • ポリシーを編集することができます。サービスに割り当て済みのポリシーでも編集可能です。
  • 監視対象として、OracleとPostgreSQLが追加されました(監視可能なバージョンはドキュメトを参照下さい)
  • App HA 1.1で利用するVMware® vFabric™ Hyperic®(以下 Hyperic  Server)のバージョンは5.8.1となります。(App HA 1.0ではVMware® vFabric™ Hyperic®の対応バージョンは5.7.xとなっております。) その他のソフトウェア要件につきましては、インストールマニュアルを参照下さい。

1.カスタムのサービスの作成と、登録について

・・・App HAで標準としてサポートされていないプラグインを使用するための、カスタムサービスを定義することができます。

カスタムサービスの設定手順について、ご紹介します。

1-1. App HA仮想マシンにログインします、認証情報はインストール中に設定した「root」認証情報を使用します。
AppHA-1
※vSphere App HA へのリモート アクセス
SSH プロトコルを使用して vSphere App HA VM へリモートでアクセスすることができます。SSH を有効にするには、VM 上でコンソールを開き、 sshdサービスを開始します。
デフォルトでは、 root認証情報を使用してリモートでログインすることはできません。 root認証情報によるログインを有効にするには、VM 上でコンソールを開き、 sshd_configファイルの permitRootLoginエントリを yes に変更した後、 sshdサービスを再開します。
AppHA-2
1-2. /opt/vadm-engine/bin/custom_service.sh addを実行します。
プロンプトが表示されたら、追加するサービスの名前を指定します。
サービス名は、 2~128 文字の ASCII 文字である必要があります。
# /opt/vadm-engine/bin/custom_service.sh add
Enter service name: JBoss7.1

サービス名(Enter service name:)は、Hyperic Server側の「Server Type」で定義されている名前と同じ名前を指定する必要があります。

1-3. サービスが追加されたら、App HA サービスが自動的に再起動します。

サービスの再起動には 1~2 分かかります。


Adding custom service 'JBoss7.1'

2014-04-16 15:51:03,260 [main] INFO  c.v.v.d.service.ConfigurationService - Configuration:
        DB Host:        127.0.0.1
        DB Port:        5432
        DB Name:        apphadb
        DB Username:    appha
        Config schema:  dbconfig
        Postgres bin:   /var/lib/pgsql/bin

2014-04-16 15:51:03,264 [main] INFO  c.v.v.dbconfig.service.FacadeService - Validating configuration

Operation succeeded.
Restarting vSphere App HA ...

1-4. App HAの再起動後、vSphere Web Clientから[管理]-[vSphere App HA]-[ポリシー]より「構成詳細>サービスの選択」で追加したサービスが表示されます。

AppHA-5

1-5. vCentre Hyperic Serverにログイン後、カスタム定義されたサービスと関連付ける「サーバ」を登録します(監視対象のプラットフォームに既にサーバが登録されている場合は、こちらの手順は必要ありません)

  • vSphere App HA で使用される用語の “仮想マシン” は、vCenter Hyperic ではプラットフォームと呼ばれます。
  • vSphere App HA で使用される用語の “サービス” は、vCenter Hyperic ではサーバと呼ばれます

1-6. 「プラットフォーム」に対して、[Tools Menu]-[New Server]を選択して、「サーバ」を追加します。

設定の詳細についてはマニュアル(About vCenter Hyperic 5.8 Configuration and Metrics Guide)を参照ください。

AppHA-6

1-7. 「プラットフォーム」に「サーバ」を追加後、Hypericエージェントからのメトリックの収集が実行されるとvCenter側でクラスタ-[監視]-[アプリケーション可用性]にカスタム定義された「サーバ」が表示されます。

AppHA-9

1-9. vCenter側でポリシーの割り当てすると、監視している「サーバ」が停止した場合、ポリシーで定義したアクショに従い、処理が実行されます。下図の例ではvCenter側にアラートが表示されています。

2. Oracleの監視について
2-1.   vCentre HypericServerにログイン後、監視対象となる「プラットフォーム」に対して、[Tools Menu]-[New Server]を選択して、「サーバ」を追加します。(監視対象のプラットフォームに既にサーバが登録されている場合は、こちらの手順は必要ありません)
AppHA-6
2-2. 「プラットフォーム」に「サーバ」を追加後、Hypericエージェントからのメトリックの収集が成功するとvCenter側でクラスタ-[監視]-[アプリケーション可用性]にカスタム定義された「サーバ」が表示されます。
AppHA-12   AppHA-11
2-3. 登録が完了後、Hypericエージェントからメトリックが収集されると、vCenterの[アプリケーション可用性]画面のサービス一覧に表示されます。
2-4.  vCenter側でポリシーの割り当てすると、「サーバ」が停止した場合、ポリシーで定義したアクショに従い、処理が実行されます。下図の例ではvCenter側にアラートが表示されています。
App HAを利用するには、Hyperic Server側でも設定が必要になりますが、是非活用して仮想環境の効率的な運用にお役に立ててください。
以前、本Blogで紹介したハンズオンラボを利用すると、App HAを体感することが出来ますのでご利用下さい。
(ラボ名:HOL-SDC-1317 – vCloud Suite Use Cases – Business Critical Applications)

vCenterで確認できるメモリ情報の見方について

仮想環境を運用する上で、メモリの利用状況の確認は非常に重要な情報の1つとります。
今回は、VMware® vCenter Server™(以下vCenter)から確認できるメモリ情報の見方をご紹介したいと思います。

vCenterでは、以下の3つの画面でメモリの状況を確認することができます。

  1. 仮想マシンのハードウェア
  2. ホストメモリ
  3. ゲストメモリ

最初に、仮想マシンのハードウェアで確認できる値を紹介します。

スクリーンショット 2014-04-09 14.47.17
図1.仮想マシンハードウェア

図1で確認できる通り、「仮想マシンハードウェア」の画面で表示される、メモリに関する情報は以下のように表示されています。

  • メモリ使用率:2048MB、266MB使用
  • ホストオーバヘッド:41MB

メモリ使用率で表示される、最初の値(2048MB)は、仮想マシンを作成した際にメモリとして設定をした値となります。

次に、XXXMB使用(266MB)の部分は、以前のC#クライアントでは「アクティブなゲストメモリ」と表示されていた項目となっており、仮想マシンが活発に利用しているメモリを、一定期間の内部統計値より計算しています。

ホストのオーバーヘッド(41MB)は、仮想マシンをパワーオンするために必要なオーバーヘッド メモリの量となっており、内部的にはページ・テーブルなどの情報を含んでいます。
見積に関してはマニュアルを参照ください。(仮想マシン上のオーバーヘッド メモリ

 

次に、「監視」タブの「リソース割り当て」で確認できる情報を紹介します。
ここではメモリ情報として「ホストメモリ」と「ゲストメモリ」の2つのポートレットで情報の確認が可能です。
スクリーンショット 2014-04-10 10.36.58

まずは、ホストメモリからご紹介します。
ホストメモリで確認できる情報は、ESXi で消費していると認識しているメモリ量を表します。

スクリーンショット 2014-04-09 13.20.56
図2 ホストメモリ

図2にある通り、メモリに関する情報は以下のように表示されています。
消費:1.83GB、オーバーヘッド:41.00MB、予約、制限、構成済み:2GB、シェア、割り当て最低限度:854.00MB、オーバーヘッド予約:37.87MBの項目があります。

消費(1.83GB)とはホストの物理メモリを仮想マシンが消費しているメモリ量となります。

つまり、今回の例では2GBの割り当てたメモリの内、1.83GBメモリが消費されているということになります。

この項目の注意点として、パフォーマンスタブのメモリ項目の「消費」とは違う点です。

こちらの消費は、オーバーヘッドを含みますが、パフォーマンスタブのメモリ項目の「消費」はオーバーヘッドを含みません。

オーバーヘッド(41.00MB)は、前項で紹介したとおり、仮想マシンをパワーオンするために必要なメモリオーバーヘッドとなっております。「ホストのオーバーヘッド」と同じ値となります。

構成済み(2.00GB)は、前項で紹介したとおり、仮想マシンを作成した際のメモリとして設定をした値となります。
メモリ「使用率」の最初の値と同じ値となります。

割り当て最低限度(854.00MB)は、すべての仮想マシンが割り当てられたリソースを全て消費した場合、該当の仮想マシンに割り当てることができるメモリ量となります。
重度なオーバーコミットが発生した場合、この値に基づいてメモリの確保を行います。
オーバーコミットをしている環境では、注意して確認すべき値の1つとなります。

オーバーヘッド予約(37.87MB)は仮想化オーバーヘッド用に予約されているメモリの量となります。

 

最後に、ゲストメモリについて紹介します
ゲストメモリとはゲスト OS で消費していると認識しているメモリ量を表します。

スクリーンショット 2014-04-09 14.46.46
図3 ゲストメモリ

図3にある通り、メモリに関する情報は以下のように表示されています。
有効なゲストメモリ:266.00MB、プライベート:1.73GB、共有:251.00MB、バルーン済み:0.00B、圧縮済み:440.32KB、スワップ済み:23.00MB、未アクセス:583.68KBの項目があります。

有効なゲストメモリ(266.00MB)は、前項で紹介したとおり、実際に読み書きを行っている(物理メモリにタッチしている)メモリの値を、一定期間の内部統計値より計算しています。
メモリ「使用率」の2つ目の値の「XXXMB使」と同じ値になります。

プライベート(1.73GB)とは、仮想マシンが物理メモリとしてバッキングされている容量を表します。
今回の例では1.73GBは物理的にメモリが確保されています。

共有、バルーン済み、圧縮済み、スワップ済みに関しては、マニュアルを参照ください。今回は説明を省略させていただきます。

未アクセス(583.68KB)とは、ゲストにより参照されないメモリの量となります。

 

今まで紹介した各値は、下図のようにあらわされます。

Image1

vCneter上で確認できるメモリ情報は仮想環境を運用するうえで、有用な情報が多く含まれています。
まずは、こちらの内容を確認後、さらに詳細な調査が必要な場合はメトリック情報を、各種ツールでの取得をして下さい。

例えばvCenter Operations Managerなどを利用すると、仮想基盤の様々な情報を判りやすく取得することが可能となります。

押さえておきたいvSphereの基本-可用性編 vSphere DRS

押さえておきたいvSphere の基本」の可用性編として、2回に分けてvSphereのリソースコントロールの機能と可用性を高める機能のご紹介をしたいと思います。

1回目の今回は、vSphere上でゲストOSを運用する際、特定のESXiホストの負荷が高くなった場合、柔軟なリソースコントロールと稼働ホストの分散により、ゲストOSへの稼働に影響を最小限に抑える機能をご紹介します。

利用ケースとして、複数のESXiホストが稼働している状況で、各ホストのリソースを効率よく活用することにより、ゲストOS間のパフォーマンス劣化を防止することやより高い統合率での仮想環境の運用が可能になります。

その他、サーバリソースを追加した場合、新たに追加されたサーバのリソースの効率的な利用などもあります。

仮想マシンが増えてきた場合、それらの仮想マシンの負荷を想定して、どのサーバー上で稼働させればパフォーマンス最適化が図れるかを設計することは困難ですし、仮に設計が出来たとしても、時間の経過と共に負荷状態は変化していきますので常に最適な状態で運用し続けることは困難です。

そこで、非常に強力な機能としてvSphereにはDRS(vSphere Distributed Resource Scheduler)があります。

DRS5

どのエディションで利用可能かについては「vSphere のエディションの比較」サイトを参照ください。注意点としてDRS機能を有効にするにDRS利用可能なエディションでクラスタを作成する必要があります。

DRSには以下の役割を持っています。

  • ユーザーによる、VMパフォーマンス要件の最適化。
  • VMのリソースの分離と共有を提供。
  • 効率的なインフラストラクチャ活用とリソース管理。
  • 包括的なクラスタ管理。

上記役割を満たすためのメカニズムとして以下の機能があります。

  • 初期配置/ロードバランシング
  • QoSの施行:共有、予約、制限、リソースプール
  • ポリシーの施行:アフィニティルール、アンチアフィニティルール
  • ホストメンテナンス時の退避

1.初期配置/ロードバランシング

DRSの「初期配置/ロードバランシング」を利用する際に、一番重要な考え方となるのが「VM の要求を満たす」つまり「VMやアプリケーションが問題なく稼働する」と言うことです。

1つ例を示します。

図1のようにクラスタ内の特定ホストのリソース(CPU・メモリ)が不足した結果、そのホスト上で稼働するVMが十分な要求リソースを確保出来なくなった場合、DRSにより不均衡解消に働きます。一方、図2のようにクラスタ内のホストが十分にリソースが確保されている場合、ホスト上で稼働しているVM数に少々のバラつきがあっても、DRSは発動されません。

図1.クラスタ内の特定ホストのリソースが不足した場合

図2.クラスタ内のホストは十分にリソースが確保されている場合

では、どのような方法でホストの「負荷」と「ばらつき」を評価するかというと、構成するホストの負荷(ホストの負荷 = (VMの負荷の合計) / (ホストのキャパシティ))のばらつきを標準偏差として管理し、この標準偏差の値が、設定されたしきい値(保守的~積極的の5段階で設定)を超えた場合、vMotionを利用して仮想マシンをほかのサーバーに移行させます。

また、vMotionの実行も自動でVMがホスト間を移動するのではなく、管理者側に判断を仰ぐということも可能となっています(可用性ガイド参照)。

2.QoSの施行:共有、予約、制限、リソースプール

各VMの要求リソースリソースのコントロールをうまく行うことにより、VMの稼働を安定させることが可能となります。その方法としてリソースプールという機能がDRSでは設定可能となっています。

リソースプールの主な特徴は以下となっています。

  • リソースの分離のための、強力なリソース抽象化機能
  • ビジネス要件に応じて、リソースプールを作成可能
  • プール内でのリソース共有と、プール間でのリソース隔離

リソースプールをうまく活用することにより、ホスト毎のリソース管理ではなく、クラスタ単位でリソースの管理が行えます。

このリソースプールは「予約」「制限」「シェア値」の設定により柔軟なリソース管理が可能です。

また、それぞれの設定項目に関しては、次のガイドライン(リソース割り当て設定の推奨事項)に従うことにより、仮想マシンのパフォーマンスを向上させるのに役立ちます。
合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません (同じシェア数のままです)。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください (10% 以上を未予約にしてください)。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。次のガイドラインは、仮想マシンのパフォーマンスを向上させるのに役立ちます。

合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません (同じシェア数のままです)。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください (10% 以上を未予約にしてください)。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。

3.ポリシーの施行

DRSでは仮想マシン間の依存性を、ルール設定により制御が可能となっています。

それぞれの動きの特徴と利用シーンを下表でまとめます。

まとめ

以上のように、DRSをうまく活用していただき、効率よい仮想環境の構築・運用をしていただければと思います。

 

 

互換性ガイドの参照方法について

VMware製品を導入する上で、どのソリューションが、「どのプラットフォーム上で稼働サポートをするのか」や「ゲストOSとして何をサポートするのか」を調べるためには、互換性ガイドの参照が欠かせません。

今回は、互換性ガイドの調査方法について紹介いたします。

1.互換性ガイドには大きく3つのカテゴリがあります。

ⅰ.システムの互換性ガイド・・・稼働システム/サーバ、サポートゲストOS、サポートホストOS 等の互換性が確認出来ます。

ⅱ.プロダクト互換性ガイド・・・VMware製品のバージョンの組み合わせ、サポートデータベース、アップグレードパスが確認出来ます。

ⅲ.パートナー製品との互換性ガイド・・・パートナー製品との互換性やサポート状況を確認できます。

 

1つの例として、ESXi5.5でサポートされるMicrosoftのゲストOSについて調べ方をご紹介します。

1.システムの互換性ガイドから「ゲストOS」を選択します。

2.Productとして「ESX/ESXi」、Release Versionとして「5.5」、OS Vendorとして「Microsoft」を選択します。

ここで、必要であれば「OS Family」等の細かな属性を指定することも可能です。

3.最後に「Update and View Results」で一覧が表示されます。

仮想化を導入する上で、稼働プラットフォームやサポートゲストOS等の情報は必須となりますので、是非活用ください。

VMware vSphere 5.5 AppHAについて

このBlogは、製品出荷前のバイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は、VMware vSphere 5.5のAppHAの機能を紹介します。

VMware vSphere 5.5より、ゲストOS内で稼働するアプリケーションの状態監視を行えるようになりした。

監視対象アプリケーションのサービスが停止した際、「サービスの再起動」または「仮想マシンのリセット」が実行されます。また、同時にvCenterへのアラート通知と管理者へのメール通知を行うことも可能です。

従来、VMware vSphere HAではアプリケーションの監視を有効にするには、適切な SDK を入手し、これを使用して監視対象となるアプリケーションのハートビートの開発/設定する必要がありました。AppHAでは、特別な開発を必要とせず、仮想マシン内で稼働するサービスに対しての保護が可能となります。

AppHAは従来のvSphere HA機能と連携して、ホスト障害から仮想マシン内で稼働するアプリケーションの保護まで可能となりました。



 

 

 

現行バージョンで監視対象と出来る、アプリケーションは下記となります。
※ 2013/9/25追記:アプリーショーンの最新のサポート状況に関しては弊社マニュアルを参照ください。

  • Microsoft SQL Server2005
  • Microsoft SQL Server2008
  • Microsoft SQL Server2008R2
  • Microsoft SQL Server2012
  • Microsoft Internet Information Services6
  • Microsoft Internet Information Services7
  • Microsoft Internet Information Services8
  • VMware vFabric tc Server6
  • VMware vFabric tc Server7
  • Apache Tomcat6
  • Apache Tomcat7
  • Apache HTTP Server1.3
  • Apache HTTP Server2.0
  • Apache HTTP Server2.2

 1.稼働コンポーネントについて

AppHAを設定するには、下記のコンポーネントの導入が必要となります。

各コンポーネントの稼働要件については、弊社ドキュメントでご確認ください。

1.vCenterサーバ

2.AppHAサーバ(仮想アプライアンス)

3.vFabric Hyperic Server(仮想アプライアンス)

4.vFabric Hyperic Agent(監視対象となる仮想マシン内で稼働)

2.AppHAの設定について

仮想マシン内で稼働する、アプリケーションの監視方法はすべて、ユーザーが事前に定義するポリシーにより決定されます。

AppHAを利用して、監視対象アプリケーションの登録方法とポリシー設定について紹介します。

AppHAは、vFablic Hyperic Serverと連携して稼働するため、AppHAのデプロイ後、vFabric HQ Serverと監視対象となる仮想マシンにvFabric Hyperic Agentの登録が必要となります。vFablic Hyperic ServerとvFabric Hyperic Agentの導入方法については、マニュアルを参照ください。

1.AppHAの初期設定として、AppHA Plug-InよりvFablic Hyperic Serverの接続情報を指定します。

2.監視ポリシーを追加します。

3.ポリシー名とコメントを設定します。

4.監視対象となるサービスの種類を選択します。

5.監視対象のサービスが停止した場合の対処方法について設定をします。

6.vCenter Serverに対してアラートの設定とメール通知の設定をします。

7.すべての設定が完了後、仮想マシン内で稼働するサービスに対して作成したポリシーを割り当てます。

また事前に、vFabric Hyperic ServerにvCenterの登録をしておく必要がありますので、登録をしていない場合、名前を「VC」としてNew Server登録を行ってください。

設定の詳細に関してはマニュアル「Fabric Hyperic Resource Configuration and Metrics」の「vSphere」の章を参照ください。

8.設定が完了して、ステータスが「Available」となると監視が開始されます。

なお、VMware vSphere HAの設定は「仮想マシンとアプリケーションの監視」で設定する必要があります。

まとめ

仮想環境において仮想マシン内で稼働するアプリケーションの監視が容易に行えるようになりましたので、是非 ご利用ください。

vSphere 5.5 新機能紹介 Web Clientについて

このBlogは、製品出荷前のバイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は、VMware vSphere 5.5のWeb Clientの機能を紹介します。

VMware vSphere 5.5(以下 vSphere5.5)では、前バージョンに引き続き、Web Clientでいくつかの機能強化が行われております。

従来利用していたvSphere Clientには、vSphere 5.5の新機能追加は行われておりませんので、vSphere 5.5で追加された機能を利用する場合は、Web Clientの使用が必須となります。

なお、vSphere 5.5から、vSphere Clientを起動した場合、ログイン画面に下図のような注意文が表示されるようになっております。

1.Web Clientでのオブジェクトのドラッグ&ドロップが可能

これまで、Web Clientではオブジェクトのドラッグ&ドロップは提供されておりませんでしたが、現バージョンより可能となりました。

この機能により、Web ClientにおいてもvSphere Clientと近い操作性で、各機能を実行することが可能となります。

 

2.クイックフィルター機能

同機能により、オブジェクトが大量にあった場合、目的に応じた絞り込みが可能となります。

クイックフィルターは、データストア、クラスタ、ホスト、VMにおいて利用可能です。

例えば、仮想マシンの状態が「パワーON状態」のVMのみや、「Toolsが未インストール」のVMといった絞り込みが可能となります。

3.最近アクセスしたオブジェクト/新規オブジェクトの表示

頻繁に利用するオブジェクトへ、1クリックでたどり着くことが可能となり、煩雑な画面遷移を軽減する工夫が行われております。

4.プラットフォームのサポートの向上

Web Clientのプラットフォームサポートに、OS Xからの使用が追加され「仮想マシン コンソールのアクセス」、「OVF テンプレートの展開」、「クライアント デバイスの接続」が可能となります。

 

VMware vSphere 5.5 新機能の概要について

2013年8月26日に「VMworld 2013 San Francisco」で、vSphereの次バージョンとなる、VMware vSphere 5.5(以下vSphere 5.5)が発表されましたので、こちらのバージョンで追加された新機能・特徴の概要をご紹介します。

ただしこのBlogは、製品出荷前のバイナリ及びマニュアルを参照して記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

1. Client
クライアントにつきましては、vSphere 5.1よりWeb Clientが大幅に機能強化されており、新機能に関してはWeb Clientにしか実装されておりませんでした。
この考え方は、vSphere 5.5に関しても同様となっております。
新機能部分としては、以下となります。

  • Web Clientでのオブジェクトのドラッグ&ドロップが可能
  • Web Client SDKによるカスタマイズ
  • vSphere Web Client でのOS Xサポート
  • クイックフィルター機能
  • ナビゲーションの利便性向上
  • 最近アクセスしたオブジェクト/新規オブジェクトの表示

2. ストレージ
ストレージとしては、下記の機能追加/強化があります。
注目すべき新機能としては、「Virtual SAN(以下VSAN)」と「vSphere Flash Read Cache (以下vFlash)」の2点大きな機能が追加されました。

i. VSAN

内蔵のHDD及び、SDDを共有ストレージとして利用することが可能となります。

この機能により共有ストレージが無い場合でも、vMotion、DRSおよびHAのような既存のVMwareのソリューションと連携が可能です。
ただし、VSANはvSphere5.5では「パブリックベータプログラムとして提供」となりますので、利用の際は注意が必要となります。

代表的な特徴として、以下があります。

  •  vSphereに完全に統合されたストレージソリューション
  • 「サーバー内蔵HDDとSSD」を利用した、低価格の階層型ストレージで、サーバー間でのデータリプリケーションにより冗長性を提供
  • ポリシーベースの採用により、VMの配置決定を簡素化
  • ESXiによりデータのレプリケーションを提供することにより、冗長構成可能
  • サーバ増設により、スケールアウトするストレージシステム

ii. vSphere Flash Read Cache
vSphere 5.1 まで、ESXiのVMkernelのスワップ領域として利用可能であった、サーバ内蔵のSSDが仮想マシン毎に対しても、キャッシュ領域として利用可能となりました。
この機能を利用した場合でも、vMotion、DRSおよびHAのような既存のVMwareのソリューションと連携が可能です。

iii. VMFS、NFS、仮想互換RDMで62TBまでのVMDKに対応
iv. VAAIでのUNMAPサポート

3. ネットワーク
ネットワークの機能拡張は下記となります。

ⅰ.LACP の拡張
・・・vSphere 5.1 での構成上の制約が緩和され柔軟なネットワーク構成が可能になります。
ⅱ.トラフィックのフィルタリングと、QoS マーキング
・・・入出力トラフィックのフィルタリングと、QoS マーキングが可能になります。
ⅲ.パケットキャプチャ
・・・様々なレベル(vNIC, vSwitch, アップリンク)でのパケットキャプチャが可能になります。
ⅳ.SR-IOV
・・・SR-IOV の設定が、ポートグループのプロパティとしてパススルーNIC に適用されます。
ⅴ.40 Gb NIC
・・・Mellanox の40 GB NIC をサポートしホストが使用できる帯域幅を拡張します。

4. ESXi/vCenter
i. ホスト1台あたりの構成上限が拡張されます。

vSphere5.1 vSphere5.5
160個の物理CPU 320個の物理CPU
2TBのメモリ 4TBのメモリ
8個のNUMAノード 16個のNUMAノード
2048個の仮想CPU 4096個の仮想CPU

ii. Reliable Memoryのサポート※
・・・ハードウェアによりマップアウトされたメモリをESXiが認識し、その領域にアクセスしないようにするため、「メモリ障害」が原因となるPSODを軽減します。

※2013/9/26追記:こちらの機能は、ハードウェア側でのサポートが必要となります。
詳細は互換性ガイドを参照ください。

iii. AMD、IntelのGPUサポート追加
・・・GPUの利用で仮想マシンのハードウェレンダリングとGP-GPUをサポートします。

iv. PCIe SSDのHot-Pluggleサポート
・・・ダウンタイムなしで SSD デバイスをホット アド / ホット リムーブを提供します。

ⅴ-ⅰ.vSphere AppHA

・・・アプリケーションダウンタイムを最小化します。

v-ⅱ. vSphereHAの改善

    • アドミッションコントロール(改善)・・・アンチアフィニティルールを反映し、同一ホストに再起動させないようにします。

vi. vSphere Replication

  • レプリケーション先は、vCenter Server 1 台あたり最大 10 か所まで、可能となります。
  • 複数の復帰ポイントの保持可能となります。
  • Storage DRSとの互換性が提供されます。

vii. MSCS Clustering利用時の機能強化

  • FCoE と iSCSI の各プロトコルをサポートします。
  • FCoE Hardware Adapters・・・ラウンドロビンマルチパスポリシーに対応します。

viii. vCenterServer組み込みデータベースのスケーラビリティ (vPostgres)
・・・最大 100 台の vSphere ホスト / 3,000 台の仮想マシンをサポートします。※

※2013/10/6修正

ⅸ. リアルタイムアプリケーションへの対応機能 ・・・ 仮想マシン毎にLatency Sensitivity(待ち時間感度)を設定することにより、物理環境に近いパフォーマンスにすることが可能です。

5. 仮想マシン

  • ハードウェアバージョンのアップデート(ESXi 5.5以降:Virtual Hardware version 10)
  • ゲストOSサポートの変更・・・いくつかの、ゲストOSのサポート終了します(詳細はvSphere5.1 リリースノートを参照ください)

6.VDP(VMware vSphere Data Protection)

  • vCenter Serverに依存せず、ESXiホストを利用して仮想マシンのリストアが可能となります。
  • VMDKファイル単位での、バックアップとリストアが可能となります。
  • バックアップスケジュールの設定が可能になります。
  • クラウド環境へのバックアップが可能となります。

次回から、各機能の詳細な情報をご紹介したいと思います。