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

作成者別アーカイブ: Kenji Uchino

Microsoft SQL や Exchange サーバーを VMware vSAN で稼働させるリファレンスアーキテクチャのご紹介・vSphere / vSAN オンラインセミナー実施のお知らせ(2019年04月)

VMware パートナーチームの内野です。

皆さまは、システムを構築する時に、例えば、Microsoft SQL サーバー専用の環境・Exchange サーバー専用の環境の様に各システムを個別に構築しておりませんでしょうか。

もちろん、SQL サーバーの負荷が高くなってしまった時に Exchange サーバー側への影響が発生してしまうのではないか。等のご心配も多くあるのではないかと思っております。

VMware vSAN は、Oracle、SAP、MS SQL サーバー、Exchange 等の様々なビジネスクリティカルなアプリケーションを混在させて稼働させることにより、クラスタの統合が行えることができるスケーラビリティを備えています。

クラスタの統合を行う事により、運用管理負荷の減少・柔軟性の向上・ハードウェアリソースの有効活用により、結果としてトータルコストの削減に役立ちます。

今回、ご紹介する “Mixed Workloads on VMware vSAN All-Flash” では、混在するワークロードがある様な環境において、インフラ管理者が VMware vSAN をどの様に構成するべきかの助けになる構成ガイドとベストプラクティスが記載されております。

 

 

また、こちらのデザインガイドの中には、よくお問い合わせを頂くパフォーマンスに関するテスト結果や Disk Group やキャッシュディスクが破損 (Fail) した場合のパフォーマンス結果の記載もございますので、ご興味がある方はぜひ、ご一読下さい。

■ 例 : 単一の vSAN データストアグループ上で SQL Server Always On Availability Groups と Exchagne Server Database availability groups を同時に稼働させた際のパフォーマンスデータ

■ 例 : Disk Group 障害時 (18:40 前後) の SQL サーバーの動作に関するテスト結果

 

本ガイドの中には、バックアップに関する影響等に関しても記載がされております。詳しくは、是非、”Mixed Workloads on VMware vSAN All-Flash” からご興味のある内容をご確認頂ければと思います。なお、本ブログは、下記 URL ブログの内容を翻訳・抜粋・補足を追記させて頂いたものとなります。不明点に関しては、下記ブログも合わせてご確認下さい。

Mixed Workloads on VMware vSAN for Microsoft SQL Server and Exchange

 

なお、上記でもご紹介している VMware vSAN に関して、2019 年 4 月にオンラインセミナーを実施させて頂くこととなりました。

(注意 : 上記、Microsoft SQL や Exchange サーバーを稼働させる際のリファレンスアーキテクチャーの話はオンラインセミナーでは含まれておりませんのでご注意下さい)

今回は、下記の 2 つのオンラインセミナーを実施させて頂きます。

4/19 日の “vFORUM 2019 プレイバック!基礎からわかる HCI 入門” では、HCI 導入の背景や VMware vSAN の概要・特徴等を解りやすくご紹介させて頂きます。vFORUM 2019 のブレイクアウトセッションでも非常にご好評を頂いたセッションンになっております。

4/24 の “【リアルタイム実況!!】 1 時間で vSAN 初期構築はどこまできる!?” では、オンラインセミナー中に VMware のインターネット上のハンズオン環境を使って、実際に VMware vSAN の構築作業を行い、その様子をオンラインセミナー経由で中継させて頂きますので、実際の構築作業を行いたい方向けの内容となっております。

 

vFORUM 2018 プレイバック! 基礎からわかる HCI 入門

vSphere / vSAN オンラインセミナー 2019#2

 

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 04 月 19 日(金) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社 奥村 奈緒美

■ セミナー目次 :
=============

12:00-12:50

1. HCI が定番になりつつある背景
2. vSAN 技術概要
3. やっぱり vSAN がベストな理由
4. HCI 導入にあたる不安要素を取り除こう!
5. まとめ

12:50-13:00

QA

 

【リアルタイム実況!!】1 時間で vSAN 初期構築はどこまでできる!?

vSphere / vSAN オンラインセミナー 2019#3

 

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 04 月 24 日(水) 12:00-13:00 (11:50 から受付開始)

費用: 無償

申し込み : こちらよりお申込みください。

講演者 : ヴイエムウェア株式会社 内野 賢二

■ セミナー目次 :
=============

12:00-12:50

1. 検証環境への接続/vCenter への接続
2. 検証環境の確認 / VMware vSAN の有効化
3. ノードの追加・ディスクの追加作業
4. 仮想マシンストレージポリシーの設定作業
5. 仮想マシンの作成およびディスクレイアウトの確認

12:50-13:00

QA

 

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的にオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容等がございましたら、是非、オンラインセミナーご参加時に直接、コメントを頂ければ幸いです。

VMware 内野

vSphere 6.7 / vSAN 紹介ウェビナー開催のお知らせ

VMware パートナーチームの内野です。

3/13 (水) のお昼の時間に、下記のオンラインセミナーを開催させて頂きます。インターネットに接続出来ていれば、日本全国はもちろん、海外からでも参加できる非常にお手軽なオンラインセミナーです。

去年の vFORUM でも非常に人気のセッションだった vSphere 6.7 の最新機能紹介とやはり、お客様やパートナー様からのお問い合わせが非常に多い VMware の HCI : vSAN に関するご紹介をさせて頂きますので、是非、多くの皆様にご参加頂ければと思っております。

 

vSphere & vSAN オンラインセミナー

~ 仮想化システムの運用負荷軽減に効く!! vSphere & vSAN 最新機能と活用法をご紹介


 

本オンラインセミナーでは、vSphere や vSphere に一番最適な HCI である vSAN に関して製品のご紹介から利用用途・導入事例等様々な情報をお届けさせて頂きます。

対象 : パートナー企業様、エンドユーザー様
※競合企業、もしくは対象外と判断させていただいた方は、ご遠慮いただく場合がございます。

主催 : ヴイエムウェア株式会社

日時: 2019年 03 月 13 日(水) 12:00-13:00

費用: 無償

申し込み : こちらよりお申込み下さい

■ セミナー目次 :
=============

12:00-12:25
—————–
vSphere 6.7 What’s New – 進化した vSphere 6.7 の最新機能をご紹介

講演者 : ヴイエムウェア株式会社

(セッション概要)
今回のリリースの特徴には、管理の大幅な簡素化と効率化、組み込み型の包括的なセキュリティ、より多くのワークロードへの対応強化、ハイブリッド クラウド関連機能の強化があります。本セッションでは、それらを実現する為に実装された VMware vSphere 6.7 の新機能と拡張された機能について解説します。

12:25-12:50
—————–
vSAN 概要紹介

講演者 : ヴイエムウェア株式会社

(セッション概要)
サーバにコンピューティング機能とストレージ機能を統合したシンプルな構成の仮想化基盤として、ハイパーコンバージドインフラ(HCI)の普及が急速に進みつつあります。仮想化システムの運用管理の負荷にお困りのお客様や、仮想化システムの更新を検討中のお客様に最適な VMware の HCI : vSAN に関して、概要および利用方法をご紹介させて頂きます。

12:50-13:00
—————–
Q&A


 

では、当日のオンラインセミナーでお会いできることを楽しみにしております。

また、今後、定期的に vSphere や vSAN 等のオンラインセミナーを行う事を計画しております。

今後、取り扱って欲しい内容や VMware のオンラインセミナーで発表してみたい等のご意見がございましたら、お気軽にご意見を頂ければ幸いです。

 

VMware 内野

VIB アクセプタンスレベルに関して

VMware 内野です。

VMware では仮想基盤をより安定して運用して頂くために VIB に関してアクセプタンスプログラムという認証プログラムを持っております。今回は VIB に関するご説明とアクセプタンスプログラムに関してご紹介させていただきます。

 

非常に地味ですが、システム選定の際に非常に大切なことですので、ご一読頂ければ幸いです。

 

VIB (VMware Infrastructure Bundle) とは…..

ESXiの構成上するために以下の様なパーツをまとめたファイルを VIB (VMware Infrastructure Bundle) と呼んでおります。

よくある VIB ファイルの構成例:

・ESXiベースイメージ(ESXi Kernel)
・デバイスドライバ
・CIMプロバイダ

特定のハードウェアを認識させる場合、該当のハードウェア専用の VIB ファイルをインストールさせてから動作させる必要が多いため、デバイスドライバの様なイメージで捉えて頂いている方も多いのではないでしょうか。

その為、特定のハードウェアを利用する為に、該当のハードウェアメーカー様が提供されている VIB ファイルを ESXi にインストールするという形なります。Windows のデバイスドライバと同じ考え方だと思って頂ければわかりやすいかと思います。

アクセプタンスレベルの分類

VIB にはデバイスドライバ等、システムを安定的に稼動させるために必要な多くのプログラムが含まれております。デバイスドライバ等、システムにロードされるプログラムの品質が悪いと仮想基盤自体を不安定になってしまう要因となることがございます。

そのような仮想基盤が不安定になってしまう要因を取り除くために品質テスト・動作テストというのが非常に大切になってまいりますが、VMware では下記の 4 つのレベルに分類して品質テスト・動作テストを実施しております。

  1. VMwareCertified
  2. VMwareAccepted
  3. PartnerSupported
  4. CommunitySupported

以下、4 つの項目に関して 1 つずつ説明させていただきます。

“VMware Certified” に関して

VMware Certified レベルは最も厳しい要件です。VMwareCertified レベルの VIB はVMware 社内品質保証テストと完全に同等な詳細なテストが行われます。

この VIB に関する障害調査は VMware 内部で全ての調査等が行われます。

 

“VMware Accepted” に関して

VMware Accepted レベルは、すべての機能を完全に VMware 内部でテストをしている訳ではありません。検証テストは各パートナー様内で実行されており、VMware は各パートナー様内で行われたテスト結果を確認した上で認証しております。

この VIB に関する障害調査は VMware は、各種パートナー企業様のサポート組織と連携して調査を行います。

 

“PartnerSupported” に関して

Partner Supported レベルは、VMware パートナー プログラムに参加している信頼のおける各パートナー様内ですべてのテストが実行されており、VMware はテスト結果を確認しておりません。

この VIB に関する障害調査は VMware は、各種パートナー企業様のサポート組織と連携して調査を行います。

 

“CommunitySupported” に関して

Community Supported レベルは、VMware パートナー プログラムに参加していない個人または企業が作成した VIB になります。

このレベルは VMware が承認したテスト プログラムは行われておりません。

VMware のテクニカル サポートや VMware パートナーによるサポートは受け付けることができません。

 

まとめ

アクセプタンスプログラムは皆様の仮想化基盤の安定稼動を目的としたプログラムです。仮想基盤の新規構築・更新の際には、アクセプタンスレベルも含めてご確認頂きますようお願いいたします。

特に Community Supported レベルの VIB をインストールする必要がある場合は、テクニカルサポートに関しては、ユーザー企業様・販売会社様の自己責任となる可能性があることをご認識の上、ご検討頂ければと思います。

VMware としては、より上位のアクセプタンスレベルの製品 (VIB) を選定して頂きますよう推奨させて頂いております。

[参考ドキュメント]

VIB およびホストの許容レベルについて

内野

P2V!! VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行

皆様、こんにちは。VMware の内野です。

本エントリでは、ブログ [仮想化への移行] シリーズの第二弾として、VMware vCenter Converter Standalone (以下Converter) を利用した物理環境上にインストールされている Linux 環境を vSphere 環境へ P2V (Physical to Virtual) するための実際の手順をお伝えします。

[仮想化への移行]シリーズ
・はじめに
-移行計画、準備段階でのポイント
• V2V (Virtual to Virtual)
VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
• P2V (Physical to Virtual)
– VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から vSphere 環境への移行 ←本エントリ
• I2V (3rd Party Image/Backup Tool to Virtual)
– 3rd Party Image/Backup Tool から VMware vSphere 環境への移行←Coming soon!!
• V2C (Virtual to Cloud)
– VMware Sphere 環境から VMware vCloud Air への移行 ←Coming soon!!

 

 

-事前準備-

前回のブログに Converter の入手方法等に関しては記載されております。入手方法等はそちらを確認してください。
また、インストール手順はこちらのブログが非常に参考になると思います。

Linux 環境特有の注意点としては、

移行元の Linux は起動しておく必要があります。

・SSH を有効にしておく必要があります。

・データベースや Web アプリケーション、ウィルスソフト等のサービスはできるだけ停止してから P2V を実施してください。特にファイルをロックするようなアプリケーションは注意が必要です。

・GRUB のみサポートしています(LILO はサポートしておりません)。

・HelperVM (移行作業用のテンポラリVMです) 用に IP アドレスが別途、必要です。1 VM を P2V するために 1 つの作業用 IP アドレスが必要になります。

その他の注意点はこちらの資料の  P29 ページをご確認ください。

 

 

それでは、実際の移行作業をご説明します。なお、今回は RedHat Enterprise Linux 6.0 にて動作確認を行っております。

まずは、

1.VMware vCenter Converter Standalone を起動して、[Convert machine] ボタンをクリックします。

 

Converter1

 

2. ウィザードが表示されましたら

Select source type : “Powered-on machine” を選択

IP Address or name : 物理Linux の IP アドレス

User name : Linux のユーザー名

Password : Linux のパスワード

OS Family : “Linux” を選択

と順番に選択して、[Next] ボタンをクリックします。

Converter2

3. 証明書の画面が表示されるので、[Yes] ボタンをクリックします。

Converter3

4. 指定した物理 Linux の名前やバージョン、設定情報が表示されるので、[Close] ボタンをクリックします。

Converter4

5. ウィザードの次の画面で移行する vCenter の

IP アドレス : vCenter の IP アドレス

user name : vCenter の管理者ユーザー名

password : vCenter の管理者ユーザーのパスワード

情報を入力して、[Next] ボタンをクリックします。

Converter7

6. 移行先の ESX を選択して、[Next] ボタンをクリックします。なお、こちらの画面で移行先の仮想マシンバージョンや保存先のデータストアの指定を行うことが可能です。

Converter8

7. 仮想マシン名を指定して、仮想マシンフォルダを選択して、[Next] ボタンをクリックします。

Converter9

 

8.今回、検証した環境では、仮想環境のディスク容量が足りずにエラーが発見されました。そのため、ディスク設定を変更するため、”Edit” をクリックします。

Converter11

9. “Advanced” をクリックします。

Converter23

10. “Destination layout” タブをクリックして、容量が超えてしまっているディスクを “Thin” ディスクをへ修正します。

Converter13

11. “Devices”  の各設定画面は下記の通りです。メモリの容量変更などを行うことができます。

Converter14

12.  “Network” の各設定画面は下記の通りです。ネットワークタイプ等を選択することができます。

Converter15

13.  “Advanced Option” の各設定画面は下記の通りです。”Power on destination machine” と “Power off source machine” 両方のチェックボックスをオンにすると、P2V 終了後、自動的に物理環境の Linux がシャットダウンして、仮想環境の Linux が起動してきます。

Converter16

 

15. 最後に [Helper VM network configuration] をクリックして、[Network] タブのネットワーク設定を行います。この設定を行わないと P2V に失敗しますので、ご注意ください。

Converter24

## 補足 ##

Helper VM の設定を行わない場合、下記の様なエラーメッセージが表示されます。下記のエラーメッセージが表示された場合は Helper VM のネットワーク設定を確認してください。

Converter22

16.  最後に設定内容を確認して、[Finish] ボタンをクリックします。Converter18

17. P2V のジョブが実行 (Running) されたことを確認して、ジョブが終了するまで待機します。

Converter19

18. ジョブが成功すると、ステータスが “Completed” になります。

Converter28

19. 仮想マシンを起動して、Linux が起動してくることを確認します。その後、設定情報や VMtools 等のインストール等を実施してください。

Converter30

 

いかがでしたでしょうか? 私たちが今回、検証した環境では検証環境の物理環境を準備する部分の方が非常に手間がかかり改めて仮想化環境の便利さを再確認することができました。

VMware vCenter Converter Standalone を使えば、簡単に物理環境の Linux を vSphere 環境に移行することができますので、物理環境の保守切れやシステム更新の際などには P2V 作業を入り口に vSphere 環境で効率適な運用を目指してみてはいかがでしょうか。

来週はサードパーティー製品を利用したイメージツールからの P2V の実施方法をご紹介させて頂きます。

[仮想化への移行]シリーズ
・はじめに
-移行計画、準備段階でのポイント
• V2V (Virtual to Virtual)
– VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
• P2V (Physical to Virtual)
– VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行 ←本エントリ
• I2V (3rd Party Image/Backup Tool to Virtual)
– 3rd Party Image/Backup Tool から VMware vSphere 環境への移行←Coming soon!!
• V2C (Virtual to Cloud)
– VMware Sphere 環境から VMware vCloud Air への移行 ←Coming soon!!

Interop Tokyo 2014 マネージメントコーナー紹介

こんにちは。VMware の内野です。

本日は 6 月 11 日 ~ 13 日に幕張メッセで開催された Interop Tokyo 2014 の VMware ブース内の マネージメントコーナーの内容をご紹介します。

マネージメントコーナーでは、サーバーはもちろん、ストレージやネットワークまでも含めていかに一括で効率的に運用管理が行えるか。に関してお客様からよく頂くご質問に対する解決策を多くご紹介させていただきました。

Interop Tokyo 2014 の VMware ブースマネージメントコーナーでは、以下の様な環境を準備しました。

interop-mgmt-env

今回は上記の環境を使って、VMware vCenter Operations (以下、Operations Manager) や VMware vCenter Log Insight (以下、Log Insight) が多くのお客様で共通される課題をいかに解決できるかに関して実際の画面 (動画) も含めて、ご紹介させて頂きます。

課題 1. 現状の仮想環境にあと何台仮想マシンを追加できますか。

仮想化環境のメリットをより多く受けるためには 1 台のサーバーにより多くの仮想マシンを起動させたいと皆さんが思っております。

しかし、同時に仮想化環境に多すぎる仮想マシンを起動してしまうと、

  • “性能が劣化してしまうのではないか心配”
  • “ピーク時に十分な性能が出ることを保証したい”

等の理由で統合率を上げることに躊躇しているのではないでしょうか。

その様な時には Operations Manager を使って、最適な統合率を確認することが可能です。Operations Manager を利用することにより今まで今までの経験則でのキャパシティ管理から脱却して、利用状況に即したキャパシティ管理を行えるようになります。

interop-mgmt-case1

 

 実際の画面に関しては下記のリンクをクリックして実際の Operations Manager の画面を動画で確認してください。なお、動画を再生する為には Quick Time が必要です。

動画:あと何台VMを載せられるか確認する

ご覧頂いた様に対象のクラスタを選択しただけで、残り何台の仮想マシンを乗せることができるかがすぐに確認することが可能です。今までは熟練の管理者が vCenter からパフォーマンスデータを取得して、Excel と格闘しながら、経験則で判断していたかと思いますが、これであれば、誰でも簡単に正確にキャパシティプランニングを行えます。

現在の利用状況のまま使い続けた場合、翌週・翌月・翌3ヵ月後の予測を行うことも可能ですので、いつの間にかリソースが足りなくなってしまったということは発生しません。また、ハードウェアを購入するためには上司や購買部門等に “なぜ、サーバー (ストレージ) が必要なのか” を説明する必要があると思いますが、この画面を使えば、上司や購買部門の方への説明もスムーズに行くのではないでしょうか。

仮想マシンを実際に追加した場合のシュミレーションも行うことができますので、実際に仮想マシンを追加する前にシュミレーションを行うことで “性能が劣化してしまうのではないか” という心配もしなくても大丈夫です。

それでは次の課題に進みます。

課題 2. いつ頃ハードウェアを追加すればいいですか?

仮想化環境を上手く使いこなせるようになるとハードウェアリソースの利用率がだんだん高くなってきます。統合率が高くなることによりハードウェアリソースが不足する場合も出てきます。

ハードウェアリソースの不足が発覚したタイミングでハードウェアを購入しようとしても上司や購買部門と調整した後、ハードウェアを注文して、到着まで待って、ラックマウントしてセットアップをして・・・・・と多くの作業を実施した後にハードウェアを利用することができます。

しかし、購買の手続きをしている最中もハードウェアリソースが不足している状況では、パフォーマンス低下が発生してしまう可能性がありますので、事前に “いつ頃ハードウェアが不足するのか” を事前に知らなくてはいけません。

今まではいつリソースが枯渇するかが明確ではなかったので、経験則や勘でハードウェアを追加していたのではないでしょうか。Operations Manager を利用することにより実際の運用で行われてきた実データの利用状況トレンドを基づいて、リソースの残り時間を推測することができます。

interop-mgmt-case2

実際の画面に関しては下記のリンクをクリックして実際の Operations Manager の画面を動画で確認してください。なお、動画を再生する為には Quick Time が必要です。

動画:いつリソースが枯渇するか確認する

このように Operations Manager を利用することにより簡単に現在の利用状況のトレンドを考慮した上で現在のハードウェアリソースがあと何日 (何ヶ月/何年) 持つのかを CPU やメモリ、ディスクなどのコンポーネント単位で確認することが出来ます。

また、ハードウェアを追加した際にどの程度の利用期間が延びるのかなども簡単にシュミレーションすることができますので、仮想環境の正常性の確認以外にも、たとえば、ハードウェアを購入する際に サーバーを追加した時には  20 仮想マシンを追加できるけど、メモリだけ追加しても 20 仮想マシンの追加が可能になる。サーバーを購入するのではなく、メモリだけ増設して方が価格が安いからメモリだけ増設しよう。等の判断を明確に行えるようになります。

Operations Manager を使ってシュミレーションできる実例:

  • サーバーやストレージを追加した際に何台の仮想マシンを起動できるかのシュミレーション
  • CPU やメモリ等の増設をした時に何台の仮想マシンを起動できるかのシュミレーション
  • 特定のサーバーやストレージを撤去した時に何台の仮想マシンを起動できるかのシュミレーション
  • システムをリプレースする際のサイジングのシュミレーション
  • 仮想マシンを追加・削除した際のシュミレーション

それでは次の課題に進みます。

課題 3.無駄にハイスペックな仮想マシンがたくさんいるんだけど・・・

仮想環境の管理をしているとリクエストされている仮想マシンのリソースが適切にリクエストされているか疑問に思うことはありませんか。

本当は 1CPU / 4 GB メモリあれば、十分なのに、4 CPU / 16GB メモリの申請をされるようなことは無いでしょうか。リクエストをしている人はパフォーマンスを担保する意味で、多めにリソースの申請をしてしまいやすい傾向があると思います。

そのようなリクエストが多数あると、せっかく仮想環境を構築して、リソースを効率的に使おうとしても非効率な状況が発生してしまいます。

今までは過剰に申請された仮想マシンを見つけ出す方法がありませんでした。Operations Manager を利用することにより簡単に過剰申請された仮想マシンを探し出すことができるようになります。

interop-mgmt-case3

実際の画面に関しては下記のリンクをクリックして実際の Operations Manager の画面を動画で確認してください。なお、動画を再生する為には Quick Time が必要です。

動画:過剰割り当てVMを探す

このように簡単なオペレーションで過剰にリソースが割り当てられた仮想マシンを適正化して削減できた分で新規の仮想マシンを作成することができ、より効率的に仮想環境を利用することが可能です。

なお、私がお客様先に Operations Manager を評価してもらう為に導入したお客様の実績ベースでも 95% 以上の仮想マシンがオーバースペックなリソースが割り当てられていました。皆様の仮想環境でも少なくとも 90% 以上の仮想マシンがオーバースペックになっているのではないかと確信しています。オーバースペックの仮想マシンを最適化することにより新しい仮想マシンのリソースとして再利用することが出来るようになります。

それでは次の課題に進みます。

課題 4.仮想環境で使っているストレージのパフォーマンスが上がらないんだけど・・・

仮想環境でも物理環境でもパフォーマンスの問題が発生した時の調査というのは非常に難しいですよね。CPU・メモリ・ディスク・ネットワーク等、各コンポーネントの利用状況等を調べて、既存の環境を依存関係を把握した上で、原因を追究する必要があります。

そのため、どこにボトルネックがあるのか正確を特定できれば、パフォーマンス問題の半分は解決できたと考えてもいいでしょう。

中でも特にストレージのボトルネックを探し出して原因を究明することは非常に難しく、共有ストレージのボトルネックはシステム全体のパフォーマンス低下に直結します。

Operations Manager を利用すれば、vCenter から ESXi ホスト、仮想マシン、データストアーはもちろん、外部ストレージの中のコントローラーやディスク、キャッシュ等も含めて一元的に視覚化することができます。

interop-mgmt-case4

 

実際の画面に関しては下記のリンクをクリックして実際の Operations Manager の画面を動画で確認してください。なお、動画を再生する為には Quick Time が必要です。

動画:VMが起動している外部ディスクの情報を確認する

仮想マシンが起動しているハードディスクがどれかを特定しようとすると色々なツールを駆使して、一つずつ確認をしていかないとどのハードディスク上で起動しているかを確認できないと思います。Operations Manager を使うと仮想マシンを選択するだけで、その仮想マシンが外部ストレージの中のコントローラやキャッシュ、ディスクのどれを使っているかを瞬時に判断することが出来るようになります。

なお、Interop Tokyo 2014 では EMC 様にご協力頂き、EMC VNX を設定させて頂きましたが、Operations Manager に対応しているストレージは下記の Solution Exchange というページから検索することができますので、現在ご利用のストレージで同じことができるか確認してみてください。

https://solutionexchange.vmware.com/store

それでは次の課題に進みます。

課題 5.管理する仮想マシンや物理的な機器が増えすぎてログを確認できないんだけど・・・

仮想環境でも物理環境でも同様だと思いますが、皆様は Windows や Linux / ストレージ機器やネットワーク機器のログを確認しておりますでしょうか。

多くの方のログの確認する場合はトラブルが発生したやセキュリティを担保するためにログを確認することが多いのではないでしょうか。

ですが、ログの確認は当たり前ですが、各機器によって確認方法が違います。

  • Windows : イベントログから確認
  • Linux : /var/log/messages のログファイルを確認
  • ストレージ機器 : ストレージ管理ソフトから確認 (各スベンダーにより確認方法が異なる)
  • ネットワーク機器 : show logging コマンド等でログを確認

Linux であれば、/var/log/messages の中を grep 等のコマンドを駆使して、目的のログを探すのは経験が必要な作業なのではないでしょうか。

また、例えば、100 台の Windows と 100 台の Linux を管理しているのであれば、合計 200 台に対して、リモートデスクトップや ssh でログインして、1 台ずつ確認していたら、それだけで 1 日が終わってしまいますよね。

そのような場合には Log Insight を利用すれば、一箇所で集中して管理することができるようになります。

interop-mgmt-case5

実際の画面に関しては下記のリンクをクリックして実際の Log Insight を動画で確認してください。なお、動画を再生する為には Quick Time が必要です。

動画:LogInsightでログを検索する

このように Log Insight は多くの機器のログを一括集中で管理することができます。

“syslog サーバーと何が違うの?” という疑問もあるかと思いますが、syslog サーバー上で大量のログメッセージを grep 等のコマンドで検索すると非常に時間がかかると思います。Log Insight を使えば、大量のログメッセージを高速に検索することが出来ます。

また、Log Insight 2.0 から Windows エージェントが Log Insight に追加されておりますので、Windows サーバーや端末のログを集中管理を行うことが出来ます。

ログのフィルタリングや集計機能を使えば、トラブル時に原因のログを探したり、日々のログデータのトレンドを把握することも簡単に行えるようになると思います。また、アラーと設定を行い、例えば、”ログイン失敗のエラーメッセージが発生したら、メールを送る” 等の設定も可能ですので、セキュリティを担保するという意味でも非常に効果があると思います。

それでは次の課題に進みます。

課題 6.NSX も一緒に Operations Manager で管理したい。

Interop Tokyo は皆さんもご存知の通り、ネットワークのイベントです。VMware の中ではネットワーク仮想化ということで NSX を出展させて頂きました。その NSX も今までご紹介してきた Operations Manager を使って参照することが可能です。

管理ツールが複数存在すると、その分、運用のオペレーションが増えたり複雑になったりします。全ての管理を OPerations Manager に統一することにより運用をよりスリムに行うことが可能です。

interop-mgmt-case6

実際の画面に関しては下記のリンクをクリックして実際の Operations Manager の画面を動画で確認してください。なお、動画を再生する為には Quick Time が必要です。

動画:NSXをOperations Managerで視覚化する

なお、NSX アダプタは 2014 年 6 月現在、テクニカルプレビューというステータスになっておりますので、正式なリリースまでもう少しお待ちください。

 

いかがでしたでしょうか。

 

Operations Manager / Log Insight が既存の運用をどの様に効率的になるかをご理解頂ければ幸いです。本ブログを興味を持って頂いたら、皆様の環境でもぜひ、Operations Manager / Log Insight をまずはお気軽にお試し頂ければと思います。

 

まとめ:

Operations Manager / Log Insight は導入コストを削減する製品ではなく、運用コストを削減することを目的とした製品です。現在、多くのお客様環境ではより少人数で多くのシステムをより高い品質で運用することが求められています。

導入コストは製品を購入するというはっきりした支出がありますので、導入コストばかりが注目されてしまいますが、導入コストだけでは全体的な IT コスト削減は望めません。むしろ、システム全体の費用で考えた時には導入コストよりも運用コストの方が大きく、本当に改善しなくてはいけないのは、導入コストではなくて運用コストなのです。

Operations Manager / Log Insight という運用管理ツールを使い、運用コストを圧縮して、全体的なコストを最適化していく必要があります。

interop-mgmt-overall

執筆者:内野 賢二

Interop 2014 関連リンク

Interop Tokyo 2014 VMware SDDC におけるネットワーク&ストレージ仮想化、マネージメント 〜Best of Show Award への挑戦〜
Interop Tokyo 2014 自宅でNSX VMware Hands On LABS のご紹介
Interop Tokyo 2014 ブースの舞台裏
Interop Tokyo 2014 Software Defined Storage コーナー デモ環境構 築TIPS
Interop Tokyo 2014 Automation 01 – ネットワークサービスの展開及び設定の自動化
Interop Tokyo 2014 Automation 02 – 負荷に応じたWeb サーバの自動展開(オートスケール)
Interop Tokyo 2014 マネージメントコーナー紹介

vCenter Orchestratorを使ってみる(2)

プライベートクラウド実現に向けた自動化のニーズ

みなさん、こんにちは。

Orchestrator に関する 4 回目になります。過去の記事を確認したい方は下記のリンクよりご確認ください。

=================================

1 回目はこちら

2 回目はこちら

3 回目はこちら

=================================

今回は、Orchestrator の統合化ということで Orchestrator を使って Active Directory 上のユーザーやグループを操作する場合を例をご紹介します。

今回は単純に Orchestrator から Active Directory 上にコンピュータを登録・削除するという非常に単純な方法をご紹介しますが、他のシステムと連携することでたとえば、[バーチャルマシンを複製] -> [Active Directory へ登録] や [バーチャルマシンを削除] -> [Active Directory 上のコンピュータオブジェクトの削除] 等といった運用上の作業を自動化することが可能になります。

なお、本画面はインターネット上で公開されているハンズオンラボ環境で実施しております。皆様ご自身で検証環境を作ることなく同様の操作を実施することが可能です。是非、本ブログの操作および Orchestrator のその他の機能を触ってみてください。

ハンズオンラボへのログイン操作方法は下記 URL をご確認ください。

登録方法 : http://blogs.vmware.com/jp-cim/2013/12/hol.html

今回、ご紹介する環境は ハンズオン ID : “HOL-SDC-1307 – vCloud Automation Solutions” 上で実施しておりますので、皆様も同様の動作を環境を構築することなくご確認いただくことが可能です。

1. Active Directory 上のコンピュータアカウントの作成

=======================================

1-1. ハンズオン環境にログインして、デスクチップ上の Orchestrator 管理画面を開きます。

vCO-blog-4st-001

1-2. ログイン画面が表示されたら、[password] 欄に “vcoadmin” と入力して、[Login] ボタンをクリックします。

vCO-blog-4st-002

1-3. Orchestrator 管理画面にログインできたら、左ペインの “Workflow” タブをクリックします。その後、[admin@vcac-w8-01a] – [Library] – [Microsoft] – [Active Directory] – [Computer] と順番にクリックします。

vCO-blog-4st-003

1-4. “Create a computer in a group” を右クリックして、”Start workflow” をクリックします。

vCO-blog-4st-004

1-5. [Parent group for the new computer] 欄の “Not set” をクリックします。

vCO-blog-4st-005

1-6. [Filter:] 欄に “Computers” と入力し、”Computers” を選択し、[Select] ボタンをクリックします。

vCO-blog-4st-006

1-7. [Name for the new computer] 欄に “VCOocks” と入力し、[Submit] ボタンをクリックします。(“VCOrocks” はコンピュータ名です。適宜、変更して入力していただくことも可能です)

vCO-blog-4st-007

1-8. ワークフローが完了したら、右上の最小化ボタンで Orchestrator 画面を最小化します。

vCO-blog-4st-008

1-9. デスクトップ上の “Active Directory” 管理画面をクリックして、開きます。

vCO-blog-4st-009

1-10. “Active Directory” 管理画面が表示されたら、左ペインより [corp.local] – [Computers] と順番にクリックします。手順3 – 7 で追加した “VCOocks” コンピュータが作成されていることが確認できます(もし、違う名前でコンピュータを登録されている場合、異なる名前のコンピュータ名が表示されます)。

vCO-blog-4st-010

1-11. コンピュータオブジェクトが追加できたことを確認できたら、右上のバツボタンで “Active Directory” の管理画面を終了します。

vCO-blog-4st-011

 

2. Active Directory 上のコンピュータアカウントの削除

=======================================

2-1. 最小化している Orchestrator の画面を開きます。(Orchestrator 管理画面を閉じている場合は再度、起動・ログインします)

vCO-blog-4st-012

2-2. 左ペインの “Workflow” タブをクリックします。その後、[admin@vcac-w8-01a] – [Library] – [Microsoft] – [Active Directory] – [Computer] と順番にクリックします。

vCO-blog-4st-013

2-3. “Destroy a computer” を右クリックして、”Start workflow” をクリックします。

vCO-blog-4st-014

2-4. [Computer to destroy] 欄の “Not Set” をクリックします。

vCO-blog-4st-015

2-5. [Filter:] 欄に “VCO” と入力し、”VCOocks” を検索できたら選択し、[Select] ボタンをクリックします。(異なるコンピュータを登録した場合は異なる名前のコンピュータを検索して選択します)

vCO-blog-4st-016

2-6. [Computer to destroy] 欄に “VCOrocks” が選択できたら、[Submit] ボタンをクリックします。

vCO-blog-4st-017

2-7. ワークフローが終了したことを確認し、画面右上の最小化ボタンをクリックします。

vCO-blog-4st-019

2-8. デスクトップ上の “Active Directory” 管理画面をダブルクリックして、管理画面を開きます。

vCO-blog-4st-009

2-9. 左ペインの [corp.local] – [Computer] をクリックして、登録されていた “VCOocks” コンピュータオブジェクトが削除されていることを確認します。

vCO-blog-4st-020

 

いかがでしたでしょうか。無事、コンピュータアカウントの追加と削除が行えましたでしょうか。

今回は単純な Active Directory のコンピュータオブジェクトの追加・削除ですが、vCenter や他のシステム (PowerShell や ssh はもちろん、REST や SOAP 等) と連携してワークフローを作成することにより多くのメリットを受け取ることが出来ます。

是非、身の回りの毎日・毎週・毎月行っている業務を思い出して、日々の繰り返し業務を自動化できるかを考えてみてください。

次回は最終回で、以下の内容を予定しています。

5回目:vCloud Automation Centerとのインテグレーション

vCenter Orchestratorのアーキテクチャ

みなさん、こんにちは。

前回に引き続き Orchestrator に関する 2 回目になります。

今まで仮想化環境の自動化はどう行っていますか。 Power CLI 等個別でスクリプトを作り込んでいたのではないでしょうか。個別でスクリプトを作り込む場合、例えば、データベースへの接続や Active Directory への接続等全てを作り込む必要があるので、非常に工数が必要な作業だと思います。

Orchestrator を使うことにより、個別カスタマイズを極力減らして、自動化の恩恵を受けることできます。

Orchestrator の注目度の高さは弊社のブログの PowerCLI のスレッド数と Orchestrator のスレッド数が比べてみると最近、非常に注目度が高いことがわかると思います。

VMware コミュニティへの新規スレッド数 [PowerCLI VS Orchestrator]

vCO-graph

[出所 URL]
http://technodrone.blogspot.com/2014/01/vcenter-orchestrator-finally-gaining.html

 

上記グラフからもわかる通り Orchestrator は利用者数が伸びており、コミュニティでのやり取りも活発になっています。もし、Orchestrator で探している情報があれば、是非、Orchestrator ブログもチェックしてみてください。

 

VMware Orchestrator Blog (英語)
http://blogs.vmware.com/orchestrator/

また、Orchestrator は既存の PowerCLI を実行することもできるので既存のPowerCLI も無駄にすることなく利用できます。

では、Orchestrator のアーキテクチャに関して以下の項目に沿ってご紹介させていただきます。

 

  1. 利用環境の種類に関して
  2. アーキテクチャ(概要)
  3. プラグイン
  4. ライセンス
  5. 保守

 

利用環境の種類に関して

まずは、Orchestrator の環境をどのように準備するかに関して説明します。

Orchestrator ですが、以下のとおり、Windows 版とアプライアンス版の 2 つが用意されています。

 

  1. Windows 版
  2. アプライアンス版

 

[Windows 版]
Windows 上に vCenter を Simple  Install することにより Orchestrator も自動的にインストールされます。

Windows 版の vCenter をインストールを行った人は既に多くいるかと思いますが、その方々は既に Orchestrator のインストールも完了していることになります。

但し、Orchestrator のサービスは標準では自動的に起動しませんので、利用する際にはサービス (VMware vCenter Orchestrator Configuration / VMware vCenter Orchestrator Server) を手動で起動 (もしくは、自動的に起動するように設定変更) する必要があります。

vCO-service-status

[アプライアンス版]
アプライアンス版に関しては、下記の VMware のダウンロードサイトから ova ファイルをダウンロード・展開することにより利用することができます。

 

https://my.vmware.com/jp/web/vmware/details?productId=352&downloadGroup=VCL-VCOVA_550

vCO-Download

OVA ファイルは Windows 環境を用意することなく非常に簡単に展開することが可能です。

 

アーキテクチャ(概要)

 

vCenter Orchestrator のアーキテクチャの概要に関して示します。

vCO-Architecture

Orchestrator 自身はワークフローの制御を行い、他のシステムとの連携はプラグインで行う形になっています。

その為、Orchestrator 側でのワークフローの作成は連携するシステムが異なっても同一の手順でワークフローを作成することが出来ます。異なるシステムと連携する際には利用するプラグインを変えるだけで利用することができます。

専用の管理画面からシンプルな操作性を実現しておりますので、ワークフローを作成する際には多くの操作をドラッグアンドドロップでワークフローの作成や INPUT や OUTPUT 等の引数の受け渡しを行うことが可能です。

new-workflow

 

プラグイン

Orchestrator がワークフローを管理して、プラグインを経由して外部システム等と連携を取り、様々なシステムに連携したワークフロー簡単に作成することが可能です。

vCO-PlugIn

自動化・統合化の恩恵を最大限に享受するためには他のシステムと連携できるかが非常に重要になってきますが、Orchestrator は非常に多くのプラグインを備えております。

vCenter Server やConfiguration Manger 等の VMware 製品はもちろん、REST や SNMP、SQL、SSH 等の標準プロトコルにも対応しているので様々なシステムと連携することが可能です。

さらに Active Directory や Windows PowerShell 等にも連携しているので、社内システムのワークフローを作成する上でも必要な機能が揃っています。

 

ライセンス

Orchestrator のライセンスは vCenter Server のライセンスに含まれているので Orchestrator 用に追加のライセンスコストは発生しません。

その為、vCenter のライセンスをお持ちの方はすぐに Orchestrator を試すことができます。

 

保守

Orchestrator の製品自体の保守サポートは vCenter Server の保守に含まれております。

但し、SDK/API等の開発に関するお問い合わせは通常の保守窓口ではお受けしておりません。その為、SDK/API 関連のお問い合わせが必要な場合や商用環境や本番環境に関しては、別途、SDK Support Program のご加入をお勧めいたします。

 

VMware SDK Support Program
https://www.vmware.com/support/services/sdk.html

次回以降は、vCenter Orchestrator の実際の画面をいくつかご紹介していきます。

 

次回以降は以下の内容を予定しています。

3回目:vCenter Orchestratorを使ってみる(1)- 自動化を想定した使い方

4回目:vCenter Orchestratorを使ってみる(2)- 統合化を想定した使い方

5回目:vCloud Automation Centerとのインテグレーション