Quantcast
Channel: VMware Japan Blog
Viewing all 972 articles
Browse latest View live

VMware vRealize Operations Manager (vROps) をパワーアップしよう!

$
0
0

4回目:3rd Party Management Packs (F5/NetApp/UCS)

– Back Number –
#1…カスタムダッシュボードって難しいの?
#2…SDDC Management Packs (VSAN/NSX)
#3…3rd Party Management Packs (Deep Security)
#4…3rd Party Management Packs (F5/NetApp/UCS)

こんにちは、ソフトバンク コマース&サービスの中川明美です。

4回目は、3rd Partyの管理パックについてご紹介します。ここでは特にカスタムダッシュボード作成時のデザイン構成の参考にしていただけたらと思います。
カスタムダッシュボードを作成する段になると、どう構成するのが最適なのかを悩みませんか。少なくとも私は悩みます(笑)。
管理パックは、まさにカスタムダッシュボードです。カスタムダッシュボードの構成要素とレイアウトのヒントになればと考え、
3社「F5ネットワークス/NetApp/シスコシステムズ」の管理パックをピックアップしました。並べてみると、新たな発見があります!
またエンドユーザー様からよくご質問を受ける、「ダッシュボード活用法」の回答を共有します。ぜひ参考にしてください!

◆管理パックの入手方法◆

下図は、「VMware Solution Exchange」の画面です。
3社の管理パックである、「F5 BIG-IP」「NetApp Storage」「Cisco UCS」は、Blue Medora社から提供されています。
「Cisco UCS」はシスコシステムズ社からも提供されています。
Solution-Exchange

Blue Medora社はvROpsの3rd partyの開発会社です。こちらのURLから、各管理パックの評価版をダウンロードできます。管理パック名をクリックし、表示されたウィンドウで「Try」ボタンをクリックします。
https://solutionexchange.vmware.com/store/companies/blue-medora

順に3社の管理パックを見ていきましょう。

◆F5 BIG-IP◆

「F5 BIG-IP」は、VMware Horizon環境で、「セキュリティ」や「Connection Serverの負荷分散」を目的に提案される製品の一つですね。F5 BIG-IP製品の詳細については、F5ネットワークスジャパン合同会社のURLをご確認ください。

https://f5.com/jp/products/big-ip

7あるタブの中から、「F5 BIG-IP World Overview」タブを選択しました。このタブは、「スコアボード(赤枠)」「ヒートマップ(青枠)」「オブジェクトリスト(緑枠)」から構成されています。
スコアボードは、メトリックや測定単位、カラーメソッドを表示できるのが特長的です。
こちらのスコアボードからは、各コンポーネントを構成するオブジェクトの健全性と下位オブジェクト数を確認できます。また3列にすることで、より多くの情報を表示できます
F5-Overview

————————————————————————————————————————-

複数列を並べるには?
vROps 6.2.1では、列数を指定するのではなく、ウィジェットリストから必要なウィジェットをドラッグ&ドロップで並べます。4つまで並べてみましたが、見やすさを考えると、3つまでがお勧めです!
Widget

 

◆NetApp Storage◆

ネットアップ株式会社は、外資系ストレージベンダーです。ネットアップ社のストレージは、vSphere基盤で使用するNASストレージとして私は知りました。ネットアップ株式会社のストレージ製品の詳細については、こちらのURLをご確認ください。
http://www.netapp.com/jp/products/storage-systems/

11あるタブの中から、「NetApp SVM QoS」タブを選択しました。このタブは、「オブジェクトリスト(赤枠)」「表示(ビュー)(緑枠)」「スコアボード(青枠)」から構成されています。
オブジェクトリストは、複数の表示方法(フィルタリング)が提供されています。たとえば、「オブジェクト」というグループ単位、または「オブジェクト名」という個の単位があります。フィルタリングの設定によって、リスト内の表示内容を変えることができます。
こちらのタブの「オブジェクトリスト」は、「Virtual Machine」「Volume」「Datastore」のオブジェクト単位で表示されています。左側の「オブジェクトリスト」で任意の下位オブジェクトを選択すると、右側の「ビュー(リスト)」または「スコアボード」で、選択した下位オブジェクトと関連したデータが表示されるように設定されています
Netapp-SVM
————————————————————————————————————————-

スコアボードの内容を変更するには?
このカスタムダッシュボードは、クラスタ単位のリソースが表示されるように設定しています。リソースは、左側に「CPU」「メモリ」「ディスク」の総容量、右側にCPUとメモリの使用率およびディスクの使用量を表示します。
Object-List

次の手順で、ダッシュボードを新規作成します!
※詳細な手順は、「#1_カスタムダッシュボードって難しいの?」を参考にしてください。

  1. 「ウィジェットリスト」から、「オブジェクトリスト」と「スコアボード」をドラッグ&ドロップ
  2. 「ウィジェットの相互作用」で、選択したオブジェクトを「オブジェクトリスト→スコアボード」に設定

「スコアボード」をドラッグ&ドロップした直後は、意図した情報ではありませんね。

Object-List2

 

「オブジェクトリスト」にはクラスタ名が表示されるように編集し、「スコアボード」には意図した情報が表示されるようにメトリックの作成および指定をします。

オブジェクトリストの編集

「フィルタリングするタグの選択」から、「クラスタコンピューティングリソース」を選択します。「クラスタコンピューティングリソース」は、「オブジェクトタイプ」内にあります。

Edit-Object-List

 

メトリックの作成

今回は「sampleScoreboard.xml」をコピーし、新規作成しています。他に、「vRealize Operationsメトリック、プロパティ、およびアラートの定義」ドキュメントを参考にしました。

Metric-Management

 

スコアボードの編集

スコアボードの内容を意図した情報にするために、作成したメトリックを指定します。

Edit-Scoreboard

◆Cisco UCS◆

Cisco UCSは、シスコシステムズ合同会社が提供するサーバー製品です。先のNetAppストレージと、Cisco UCSサーバーおよびNexusスイッチの統合基盤である、FlexPodでも知られていますね。シスコシステムズ合同会社のユニファイド コンピューティング製品の詳細については、こちらのURLをご確認ください。
http://www.cisco.com/c/ja_jp/products/servers-unified-computing/product-listing.html

5あるタブの中から、「UCS Fabric Interconnect Overview 」タブを選択しました。このタブは、「オブジェクトリスト(赤枠)」「健全性チャート(紫枠)」「スコアボード(青枠)」「オブジェクトの関係(オレンジ枠)」「メトリックビュー(緑枠)」から構成されています。
こちらのタブでは、オブジェクトリストでオブジェクトを選択すると、複数の関連情報が表示されます。たとえば、左上の「Fabric Interconnects」オブジェクトリストで「UCS Adapter sys/switch-B」を選択すると、健全性、ステータス、スイッチを中心とした他のオブジェクトとの関係、アラート、ネットワークスループットが表示されます。そしてパワーサプライの情報がこのタブから得られます。任意のオブジェクトを複数の視点で分析したい場合、異なる複数のウィジェットで連携させると便利ですね。

UCS-Overview

 

————————————————————————————————————————-

ウィジェットには何があるの?
vROps 6.2.1では、44のウィジェットが提供されます。その中でも使用頻度が高いのではと思われる15のウィジェットをリストアップしました。たくさんありますね。

Widget1Widget2Widget3

◆一番多い質問は?◆

得られる情報が多すぎる、何を確認したらよいのかがわからない。これが私への一番多い質問です。先ほどまでは、「多くの情報を一画面で確認できるのは便利です」と様々な手法をご紹介しました。しかし、使用者のスキルレベルによっては、情報の多さに圧倒されてしまうようです。「多いなら少なくすればよいのでは?」と使用頻度の低いウィジェットを削除することをお勧めしています。
新規でカスタムダッシュボードを作成するのも1つの方法です。そして、デフォルトで提供されているダッシュボードをコピーして、ウィジェットを追加/削除するのもカスタマイズの1つの方法です。

ここでは、「診断」ダッシュボードを例に説明します。
診断に必要な情報が、1つに集約され、使い勝手がよさそうなダッシュボードです。こちらをvSphereの深い知識を持たない方を対象に、カスタマイズしてみました。
メトリックに関するウィジェット(赤枠)を削除し、パフォーマンスに関する「ワークロード」と「ストレス」のバッジ(青枠)はスクロールしない位置に変更しました。メトリックの詳細な値までを必要としない方は、このシンプルなカスタムダッシュボードを使用します。

<変更前>

Before

<変更後>
After

 

まとめ

vROpsの活用方法を知っていただきたく、今回執筆いたしました。導入したものの、活用できていない方々がいらっしゃると聞きます。ぜひこちらのBlogを参考に、vROpsをパワーアップしてみください。それから、活用できていない要因には、シンプルなツールを複雑に捉えているのかなぁという印象もあります。まだまだお伝えしたいことは尽きません。

パート2も企画しております!今後ともよろしくお願いします。

nakagawa

ソフトバンク C&Sのサイトで仮想化健康診断の事例を紹介しています。運用のヒントになるかもしれません。
詳細についは、以下↓↓アイコン↓↓をクリックして下さい!

Logo2

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう! appeared first on Japan Cloud Infrastructure Blog.


VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

$
0
0

1回目:最新のV4Hが使いやすくなっている!

こんにちは、ソフトバンク コマース&サービスの中川明美です。
7月から開始しましたvRealize Operations Manager (vROps)のBlogはおかげさまで好評を得ました。LikeやShareをいただいた読者のみなさま、誠にありがとうございます。
その結果を受け、パート2も執筆することになりました。「これは使える!」という実践的な内容を投稿していきたいと思います。今後ともよろしくお願いいたします。

パート2は次の5回構成です。

#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

仮想化健康診断やワークショップを実施するたびに、「vROpsの活用法」を多くの方に知っていただきたいとわくわくします!活用法を手に入れ、ぜひvSphere環境を安定稼働に導いてください。

このBlogの環境は、次のバージョンを使用しています。
Matrix

異なるサイトではありますが、V4Hの基本的な使い方をご紹介しています。参考までにご確認ください。このBlogの環境はV4H6.1を使用しています。
VMware vRealize Operations for Horizon (V4H)を使いこなしてみよう!

 

「VMware vRealize Operations for Horizon (V4H)」の説明を始めます。

◆V4Hは何を監視するの?◆
「vROpsはわかるのですが、V4Hはわかりません」と質問を受けることがあります。
V4Hで何が監視できるのかを知る前に構造を理解しましょう。V4Hは次の図のように2階層で構成されます。V4Hのアダプタを追加すると、ユーザー (仮想デスクトップ)を中心としたデータを監視することができます。
V4H

セッションやログオン時間などユーザーに関連することは、V4H(Horizonダッシュボード)で、仮想デスクトップの仮想基盤であるvSphere環境に関連することはvROps(vSphereダッシュボード)で監視すると考えれば、ハードルは低くなりませんか。
もちろんHorizonダッシュボードでも、仮想基盤の監視は可能です。慣れるまでは、V4H 6.3をお使いなら、「Horizon Help Desk」「Horizonの概要」ダッシュボードを監視するだけでも十分です!

◆Horizon ダッシュボード◆
V4H 6.3のダッシュボードです。この中から、「Horizon Help Desk」ダッシュボードについて詳細に説明します。
Dashboard

◆Horizon Help Desk◆
ユーザーから問い合わせがあった場合、その原因を調査する際に有効なダッシュボードです。
画面上部の中央(赤枠)の「フィルタ」で該当のユーザー名で検索すると、そのユーザー(仮想デスクトップ)に関わるデータが表示されます。
「Horizon Help Desk」ダッシュボードで取得できる情報をリストアップします。

  • セッション関連メトリック
  • セッションログオンの内訳
  • 選択したユーザー セッションアラート
  • 選択したセッション関連オブジェクト
  • 仮想マシンメトリック
  • セッションプロセス
  • 仮想デスクトップ
  • Horizon Client

Dashboard2

「Horizon Help Desk」ダッシュボードの中でも、特にお勧めの「仮想マシンメトリック」と「セッションプロセス」についてご紹介します。この2つがサブタイトルにある「使いやすくなった」と言える点です。

◆仮想マシンメトリック◆
以前のバージョンでは、セッション情報とメトリック情報を同時に見ることができませんでした。V4H 6.3では、仮想デスクトップのキャパシティやパフォーマンスを分析するために必要な主なメトリックが表示されます。
Dashboard3

上図の「VM Health」が赤色表示されているのは、アラート情報から、ディスク領域の不足が原因であるとわかります。パフォーマンスに関するメトリックは緑色表示のため、パフォーマンスの劣化は生じていないと判断できます。
「アラート」→「VM Health」→「VM Workload」→「メトリック」が一つのダッシュボードに表示されているため、この順で確認すれば、トラブル時の原因特定を早められますね。

次に、CPUとメモリのメトリックに言及します。

<CPU
に関するメトリック>
仮想デスクトップ基盤では、オーバーコミットによる、CPUの競合が発生する確率が高いように見受けられます。「CPU Ready」や「Co-Stop」の値から、仮想CPUに物理CPUがアサインされず、待ちが発生しているかいないかがわかります。これらの高い値はパフォーマンスの劣化を表わします。パフォーマンスに影響を与える値の目安としては、「CPU Ready」が10%以上、「Co-Stop」が15%以上と言われています。Co-Stopはクリティカルなレベルで影響を及ぼしますから、15%を超えないための対応が必要です。対応方法は、CPUリソースの空きがあるESXiホストへvMotionするか、CPUリソースの空きがなければESXiホストを追加します。

「vCPU Recommended」が表示されるのも嬉しいですね。仮想デスクトップに構成された値である「vCPU Count」よりも「vCPU Recommended」が多い場合は、キャパシティに問題がある(vCPUの割り当てが少ない)ことがわかります。

<メモリに関するメトリック>
メモリについては、「Memory Swap」が発生している時点で、物理メモリが枯渇していることがわかります。パフォーマンスに悪影響を及ぼしますから、早急に対応する必要があります。対応方法は、メモリリソースの空きがあるESXiホストへvMotionするか、メモリリソースの空きがなければESXiホストを追加します。

◆セッションプロセス
セッションプロセスでは、仮想デスクトップ(ゲストOS)の「サービス」「プロセス」「Traceroute」のデータを取得できます。
Dashboard4

<デスクトップ サービスを取得/デスクトップ プロセスを取得>
「サービス」または「プロセス」のデータから、どのApplicationがどの程度リソースを使用しているかを確認することができます。たとえば、仮想マシンのCPU使用率が高い場合、ゲストOS上のどのApplicationがCPUを多く使用しているのかを確認することができます。下図に表示されているCPU以外に、Page、Disk Read、Disk Write、Network Packetsのデータを取得できます。
Dashboard5
Dashboard6

<デスクトップを取得/クライアントのTraceroute>
仮想デスクトップから、Horizon Clientがインストールされている機器までのTracerouteを表示することができます。このTracerouteの結果から物理ネットワークの状態を確認することができます。セッションが切れる場合、1つの参考値になると思います。
Dashboard7

 

<セッションプロセスのデータ取得/表示>
データ取得は、「アクションの選択」でメニューを選択後、実行ボタン(赤枠)をクリックします。実行ボタンを押した時点のデータを取得することができます。
Dashboard8

過去のデータは、コンボボックスのリストから該当の日時を選択し、表示します。
Dashboard9

◆まとめ
V4H6.3では、「Horizon Help Desk」ダッシュボードのみで、仮想デスクトップの様々な情報を取得することができます。トラブル時などは、このダッシュボードだけで、必要な情報を取得できます。便利になりました!
これからは、「情報が多すぎてどのデータを確認したらよいかわからない」と質問されたら、「Horizon Help Deskダッシュボードを活用ください」と答えられます。
大きな単位(たとえばPodやPool単位)で仮想デスクトップの状態を分析したい場合は、その他のHorizonダッシュボードを活用します。仮想基盤を分析する場合は、V4Hでも標準vROps機能を当然活用することができます!
次回はvROpsに戻り、ビューの活用法をご紹介します。ビューを理解することがvROpsの活用度を高めます!

nakagawa

 

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。
ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!
voa

 

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2 appeared first on Japan Cloud Infrastructure Blog.

第3回 VMware Virtual SAN(VSAN)搭載アプライアンスVxRailとは? ~ VxRail の運用と管理:前編 VxRail Managerのご紹介 ~

$
0
0

こんにちは、ネットワールドの石塚智規です。前回のハイパーコンバージドインフラのアプライアンス「VxRail」のセットアップの続きで、今回は管理の方法についてご紹介したいと思います。

ishitsuka_mini

VxRail Managerによるシンプル管理

VxRailはvSphere環境を簡単に管理する手段として専用のGUI = VxRail Managerを搭載しています。このGUIにより、vSphereのリソース状況やハードウェアのステータス状況などを一括して管理することができます。

01

VxRail Manager の管理画面は以下の様な特徴があり、使いやすいと好評頂いています。

  • マウスクリックや画面スクロールなどの操作感が非常に軽快
  • ログインした時点でアプライアンスの状態(正常, 警告, エラーなど)が把握できる
  • 1クリックでリソース(CPU, メモリの利用率やディスクIO)の状況が把握できる
  • リソース状況画面と同じ画面上にハードウェアステータスを把握できる(壊れているパーツがあれば赤く警告される)
  • 故障個所がアプライアンスのどの位置で発生しているのかグラフィカルに表示される
  • 追加ノードを自動的に検出, ウィザードを利用して簡単(5分)で追加できる
  • ボタン1つでアプライアンス全体の電源断ができる

 

では、実際の管理の方法について具体的にご説明したいと思います。

 

 

管理GUI=VxRail Managerへのログイン

アプライアンスの管理GUIであるVxRail Managerへログインしてみます。ブラウザを起動して、URLにセットアップのときに指定したVxRail ManagerのIPアドレスもしくはホスト名を指定します。

02

ログインアカウントはvCenterと同じユーザ名/パスワードでログインします。VxRailアプライアンス内にvCenter/PSCを配置している場合はadministrator@vsphere.localユーザを利用して下さい。

 

ログインに成功すると以下のようなダッシュボードが表示されます。

03

VxRail Managerは左側にメニューがあり、「ダッシュボード」「サポート」「イベント」「稼働状態」「構成」の5つが利用できます。いくつかの機能はインターネット接続が必要になります。

 

ダッシュボード メニュー

ダッシュボードでは以下の4つの情報が得られます。

 

  • システム全体の稼働状態
    アプライアンス全体のステータスが表示されます。ステータスは「正常」「エラー」「警告」「重大」の4段階で表示されます。「エラー」は状態変化が発生した、もしくはしていることを示し、「警告」だとそのままの状態だと安定稼働に支障が出るため何がしかのアクションが必要な状態(例えばディスクスペースの不足など)、そして「重大」はダウンタイムに繋がる即時対応が必要な状態(ディスクの破損など)を示しています。

 

  • VxRailコミュニティ
    EMCサポートコミュニティサイトのVxRailセクションの最新情報がリストアップされます。最近話題になっているスレッドが表示されるので、安定運用のための情報が得られます。

 

  • サポート
    サポート情報としては「最新のハートビート」「サポートとチャットする」「サービスリクエストを作成する」の3つが利用できます。「最新のハートビート」ではEMCのSecure Remote Services(ESRS)実装済みの場合に最後にESRSと通信した時刻が表示されます。「サポートとチャットする」はそのままですがEMCサポート窓口に対してチャットで質問(例えば電源断の方法など)するためのチャットセッションが開始されます。「サービスリクエストを作成する」では事象を伴うトラブル(ディスク故障など)を問い合わせることができます。

 

  • イベント履歴
    イベント履歴もそのままですが、最近発生したイベントが表示されます。

 

 

サポート メニュー

04

サポートでは以下の7つの情報が得られます。

 

  • 最新のハートビート
  • サポートとチャットする
  • サービスリクエストを作成する
  • 送信した最新の構成情報を確認
    上記4つはダッシュボードと同じことが可能です。

 

  • ダウンロード
    EMCサポートのダウンロードサイトへのリンクです。

 

  • VxRailコミュニティ
    こちらもダッシュボードと同じことが可能です。

 

  • ナレッジベース
    EMCのナレッジベースを検索することが出来ます。

 

 

イベント メニュー

05

イベントでは以下の2つの情報が得られます。エラー以上のイベントを検知した場合、イベントメニューのアイコン上に発生したイベント数が赤く表示されます。

 

  • システムイベント
    発生した全てのイベントがリストアップされます。イベントIDや重大度、対象コンポ―ネットを指定してリストアップすることも可能です。

 

 

  • イベントの詳細
    システムイベントのリスト上で任意の情報を選択すると、その詳細が表示されます。

 

 

稼働状態 メニュー

稼働状態には「論理」と「物理」の2つのタブがあります。それぞれ以下の情報が得られます。論理タブではリソースステータス(ストレージ, CPU, メモリの各リソースの負荷状況)を正常(緑)、注意(黄色, 75%~85%)、警告(赤, 85%以上)で色分けして状態を表示してくれます。

 

<論理タブ>

06

管理しているアプライアンスのそれぞれのハードウェアIDが表示されます。標準状態では全てのアプライアンス全体の状態が表示されます。ハードウェアIDをクリックすると、それぞれのアプライアンスの状態が表示されます。

  • ストレージIOPS
    現在の負荷状況をパーセンテージで表示します。また、現時点のIOPS、最大のIOPSも表示されます。

 

  • CPU使用率
    現在の負荷状況をパーセンテージで表示します。また、アプライアンス全体で保有しているCPUリソース(クロック数, GHz)と、現時点での空きリソースも表示されます。

 

  • メモリ使用量
    現在の負荷状況をパーセンテージで表示します。また、アプライアンス全体で保有しているメモリリソース(GB)と、現時点での空きリソースも表示されます。
  • ストレージ情報
    Virtual SANとして構成されているストレージ容量が表示されます。全体容量が「容量」として表示されています。この容量は冗長性が考慮されていない所謂Raw容量です。各ゲストOSに割り当てられたストレージポリシーに従い消費します。
  • ESXiノード
    アプライアンスに搭載されいてるノードのハードウェアステータスが表示されます。容量ディスク(ハイブリッドの場合はHDD, オールフラッシュの場合はSSD)、キャッシュ用SSD、ESXiシステムブートディスク(SATADOM)、NICの各コンポーネントの状態が確認できます。各コンポーネントをクリックするとUUIDなどが表示されます。

 

 

<物理タブ>

07

管理しているアプライアンスのそれぞれのハードウェアIDが表示されます。標準状態では全てのアプライアンスの物理的な状態が一覧で表示されます。ハードウェアIDをクリックすると、それぞれのアプライアンスの前面図、背面図が表示されます。エラーなどのイベントが発生しているコンポーネントがある場合は、該当コンポーネントにステータスアイコンが表示されます。また、コンポーネントをクリックするとそれぞれのコンポーネントが持っている詳細情報が表示され、交換作業のためのウィザードが表示されます。また、ノードコンポーネントをクリックすると、物理的な位置を示すLED(UID LED)を点灯/消灯させることができます。

 

 

構成 メニュー

構成には「機能」と「市場」、「全般」の3つのタブがあります。それぞれ以下の情報が得られます。

 

<機能>

08

アプライアンスに既に実装済みの管理コンポ―ネント(バーチャルアプライアンス)が表示されます。標準状態ではVxRail Managerだけが表示されます。リモート保守用のESRSを追加すると追加で表示されます。

 

 

<市場>

09

EMCが提供しているバーチャルアプライアンスをダウンロードするためのリンクの一覧です。2016年9月1日時点ではCloud Array(VxRailアプライアンスには1TBキャッシュのライセンスがバンドルされています)と、Data Domain(0.5TBまでのコミュニティサポートエディション, 別途ライセンス購入可能です)、RecoverPoint for Virtual Machines(VxRailアプライアンスには15個のゲストOSの保護ライセンスがバンドルされています)、vSphere Data Protectionのダウンロードリンクが存在しています。

 

 

<全般>

10

  • サポートアカウントの設定
    インターネット経由で確認できるサポートの各種情報(ナレッジベースの検索やダウンロードなど)へのリンクに利用するEMCサポートサイトに登録しているユーザ自身のアカウント情報です。

 

  • ログコレクション
    VxRail Managerの最新のログ情報を取得します。トラブル対応時に必要になるログの1つです。

 

  • ESRS(EMCセキュア リモート サポート)の有効化
    EMCのリモートサポートシステムであるESRSの実装状態を示します。

 

  • ネットワーク環境設定の構成
    各種インターネット経由の機能を有効化(オンライン)もしくは無効化(オフライン)にします。

 

  • クラスター監視の抑制
    システム全体の状態監視を有効化/無効化します。メンテナンス等の作業時にステータス監視を無効化するときに利用します。

 

  • システム診断
    現在のシステム全体の状態をチェックすることができます。

 

  • クラスターのシャットダウン
    クラスター全体のシャットダウンを行うときに実行します。シャットダウンプロセスの前にシステム診断が行われ、正常状態でないとシャットダウンは実行できません。

 

  • 言語を選択
    VxRail Managerの表示を各種言語に切り替えられます。

 

 

以上がVxRail Managerの操作概要となります。ログインした時点でステータスが把握できますし、リソースとハードウェアのステータスも1クリックで確認できる究極的に簡単な管理ツールと思います。次回は管理の後半戦として、良くあるご質問にまとめてお答えしたいと思います。

#1…VxRail & VSAN Overview

#2…VxRail インストール

#3…VxRail の運用と管理:前編 VxRail Managerのご紹介

#4…VxRail の運用と管理:後編 運用についての良くあるご質問

#5…VxRail によるデータ管理の向上

#6…VxRail のサイジングと設定について

The post 第3回 VMware Virtual SAN(VSAN)搭載アプライアンスVxRailとは? ~ VxRail の運用と管理:前編 VxRail Managerのご紹介 ~ appeared first on Japan Cloud Infrastructure Blog.

VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

$
0
0

2回目:ビューの活用方法 ①

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース&サービスの中川明美です。
突然ですが、「ビューを制する者は、vROpsを制する」と私は思っています(笑)
vROpsは、「健全性」「リスク」「効率」スコアの色から、容易に状況を把握できるのがメリットの1つです。とは言うものの、詳細なデータを使用して分析したい場合は、ぜひ「ビュー」を活用してみてください。
今回のビュー①ではビューのノウハウを、次回のビュー②ではカスタムビューの活用方法をご紹介します

◆ビューの管理画面◆
ナビゲーションパネルの「コンテンツ」ボタンをクリックします。メニューから「ビュー」をクリックし、ビューの管理画面を表示します。この画面で、カスタムビューの作成/編集/削除を行います。
下図は、「CPU(赤点線枠)」で検索し、CPUに関連する標準のビューを表示しています。
タスクが終われば、フィルタに赤い×が付いているボタン(青点線枠)をクリックし、検索を解除してください。フィルタが反映された状態では、すべてのビューが表示されず、慌てることになります(笑)。お気をつけください。

View

◆任意のオブジェクトのビュー◆
次に、任意のオブジェクトのビューを表示します。ここでは対象をクラスタとします。
「環境」ボタン→「イベントツリー」→「vSphere ホストおよびクラスタ」→「vCenter 」→「クラスタ」とドリルダウンします。該当のクラスタを選択後、「詳細」タブ→「ビュー」をクリックし、クラスタに関連するビューを表示します。

<
リスト形式のビュー>
下図の「ホストのCPU診断リスト」は、私が仮想化健康診断で報告書を作成する際に、よく使用しているリスト形式のビューです。「タイプ」に「リスト」と明示しています。

View2

このビューでは、パフォーマンスとキャパシティに関するメトリックである、「競合(%)」「デマンド(GHz)」「使用量(GHz)」などの数値を並べて確認することができます。
上図は、使用量よりデマンドが多く、さらに競合率も15%を超えています。この値から、リソースの競合により、パフォーマンス劣化が生じていることがわかります。
このBlogの環境はクラスタに1台のESXiホストですが、複数のESXiホストを追加している場合は、各ESXiホストの状態を比較することもできます。
1回目のBlogで「空きリソースがあるESXiホストに仮想マシンを移行する」と対応方法を紹介しました。空きリソースがあるESXiホストを確認する場合に、この診断リストを使用すると調査が簡単です。

<グラフ形式のビュー>
グラフ形式のビューは、時系列で状況を確認することができます。
下図は、「クラスタのCPUデマンド予測トレンド」ビューを選択しています。過去から現在のデマンドと、未来(30日間)の予測デマンドを表示します。
中央の▲(赤点線枠)をドラッグすると、グラフを拡大表示することができます。

View3

◆ちょっとした表示のコツ◆
グラフ形式の表示に関する”コツ”をご紹介します。

<表示/非表示>
「クラスタのCPUデマンド予測トレンド」ビューは、7つの凡例(項目名)があります。
下図は、項目名の「クラスタのCPUデマンド予測トレンド – 構成済みキャパシティ」を選択しています。項目名をクリックすると、名前とグラフが強調表示されます。
さらにもう1回クリックすると、「非表示」になります。非表示の状態でクリックすると、再表示されます。

Trend

下図は、「構成済みキャパシティ」「使用可能なキャパシティ」「Rawデマンド」を非表示にし、「ストレスなしのデマンド」のみを表示しています。必要なデータだけを表示できますから、分析しやすいですね。このグラフから、7月はデマンドの値が増加していますが、8月から減少し、今後30日間はさらに低くなる傾向を読み取れます。

Trend2

<詳細表示>
下図は、任意の仮想マシンの「仮想マシンのCPU診断」ビューです。「ホストのCPU診断リスト」と同様の項目を、時系列で表示することができます。
ある時点をポイントすると、凡例(項目名)の具体的な数値を確認することができます。

CPU_Analytics

次に、ポイントしたままドラッグすると、表示の時間間隔を短くすることができます。
下図は、上図でドラッグした範囲が10分刻みで表示されています。元に戻したい場合は、右上の「ズームのリセット(赤点線枠)」をクリックします。
このグラフから、20分おきに、「デマンド」「使用量」「準備完了」の値が上昇していることがわかります。仮想マシンはCPUを要求しているけれども、リソース不足のため、同時にCPUの待ちが発生していると判断できます。この期間はパフォーマンス劣化が生じていますね。
たとえば、この仮想マシンを使用しているユーザーからクレームがあれば、診断ビューの日時と照らし合わせ、原因を調査することができます。

CPU_Analytics2

◆ビューの日付範囲◆
多くのビューは、過去7日間の範囲で表示されます。カレンダーのアイコン(赤枠)をクリックすると、表示データの日付範囲を変更することができます。
相対的な日付範囲は、「分」「時」「日」「週」「月」「年」の間隔で指定できます。また、開始と終了を指定して期間設定することもできます。

View4

◆CSVとしてエクスポート◆
「ビューのデータを保存すること、または印刷することはできますか」と質問を受けることが多々あります。印刷は、そのビューを元に作成された「レポート」機能を使うのが簡単です。ビューには、「CSVとしてエクスポート」という機能があります。この機能を使用すれば、エクスポートしたデータの保存、好みのレイアウトの印刷を行うことができます。

Export

下図は、エクスポートしたデータをメモ帳で開いたものです。

csv

1つ注意点があります。vROpsのCSVファイルは、UTF-8形式で保存されます。Excelを利用する場合は、「データ」メニューから「テキストファイル」を選択し、UTF-8形式でインポートしてください。下図のような文字化けを回避できます。

csv2

◆まとめ◆
今回は”ちょっとしたコツ”を含めた、ビューの活用方法をご紹介しました。
過去データから、トラブルの原因などを調査する際に威力を発揮します。データの表示間隔や日付も指定でき、データを柔軟に表示できるのは便利ですね。
ビューは、このBlogで紹介した「ビュー画面」で使用する場面もありますし、ダッシュボードやレポートの元データとして使用する場面もあります。後者はカスタムビューで対応することが多くなります。
次回は、そのカスタムビューの作成方法と活用方法をご紹介します。お楽しみに!

nakagawa

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!

voa

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2 appeared first on Japan Cloud Infrastructure Blog.

VMware NSX for vSphereへの移行

$
0
0

1回目:vCloud Networking and Security (vCNS)の販売終了

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース&サービスの中川明美です。
vCloud Networking and Security (vCNS)の販売が終了されていることをご存知ですか?
すでに一般サポートも2016 年 9 月 19 日に終了を迎えています。テクニカルガイダンスは2017年3月まで提供されます。
セキュリティベンダーが提供する仮想アプライアンスを使用して仮想基盤を保護されているユーザー様、または提案を予定しているパートナー様は、ご注意ください。
vCNSの販売および一般サポートの終了にともない、こちらのBlogでは3回にわたり、VMware NSX for vSphereへ移行のための情報を共有いたします。連携する仮想アプライアンスは、トレンドマイクロ社のDeep Securityを対象とします。

現在vCNS(旧vShield Manager) をご使用のユーザー様は、vShield Endpointを管理するために、今後はNSX Managerを使用することになります。
また、vShield  Managerを含むvShield Endpoint関連のコンポーネントは、すでにVMware社サイトからのダウンロードを終了しています。そのため、新規構築の際も、NSX for vSphereを使用することになります。
いずれも、NSX for vSphere 6.2.4 以降をダウンロードし、環境を構築する必要があります。
トレンドマイクロ社は、vCNS 5.5.x環境下のDeep Securityに関するサポートを継続します。ただしベストエフォート対応のサポートとなります。

終了については、次のKBをご確認ください。
<KB: 2145636 >
VMware vCloud Networking and Security 5.5.x の販売終了および一般サポートの終了

https://kb.vmware.com/kb/2145636

◆VMware NSX for vSphere 6.xのライセンスエディション◆

NSX for vSphereは、次の4つのエディションが提供されています。

  • NSX for vShield Endpoint
  • NSX Standard
  • NSX Advance
  • NSX Enterprise

「NSX for vShield Endpoint」は、VMware NSXバージョン6.2.4から追加された新しいライセンスです。

4つのエディションは、同じNSXモジュールを使用します。ライセンスキーを入力せずにインストールするとNSX for vShield Endpointとして機能します。残りの3つのエディションは各ライセンスをご購入されると利用できます。

◆vShield EndpointとNSXの構成の違い◆
vShield EndpointからNSXへ移行すると、どのようなコンポーネントが必要となるでしょうか。提案する際に何が必要かを知っておくことは大事なポイントとなりますね!

vshield-to-nsx

 

<変更のポイント>

  1. 管理マネージャーが、「vShield Manager」から「NSX Manager」に変わります。NSX Managerは、vShield Managerと同様に1システムに1つ準備します。
  2. 新たに、仮想アプライアンス「Guest Introspection」を、各ESXiホストに配置します。Guest Introspection がvShield Endpoint の全機能を提供します。

変更・追加対象の、「vShield Manager」と「Guest Introspection」は、「NSX for vShield Endpoint」を含む「VMware NSX for vSphere」すべてのエディションで提供されます。

◆各NSXエディションとDeep Securityの機能◆
ウイルス対策のみの場合は、NSX for vShield Endpoint (無償)で使用可能です。

matrix

◆まとめ◆

vCNSの販売の終了にともない、仮想基盤のセキュリティ強化に努めるユーザーや提案するパートナーに影響をもたらしていると思います。
仮想基盤の管理者にとっては悩ましいことですね。一般サポートも終了していますから、今後のことを考慮し、ぜひNSX for vSphereへのアップグレード準備を開始いただけたらと思います。
こちらのBlogの3回目では、無償版の「NSX for vShield Endpointへの移行」のサマリーをお伝えします。移行の詳細手順書を12月以降に提供する予定です。こちらは「VMware Japan」Facebookでお知らせします。
その前に新規インストール用の簡易手順書を共有します。こちらへアクセスください。

http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/NSX-NV-05-NSX_for_vShield_EndPoint_20161021a.pdf?elqTrackId=9bc23ac857cc422897d92420f93dc17b&elqaid=979&elqat=2

 

nakagawa

The post VMware NSX for vSphereへの移行 appeared first on Japan Cloud Infrastructure Blog.

VMware NSX for vSphereへの移行

$
0
0

2回目:Deep Securityを実装するためのNSX

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回、vCloud Networking and Security (vCNS)の販売が終了したことをお知らせしました。早急にVMware NSX for vSphereへの移行を検討しなければいけませんね。
今回は、トレンドマイクロ社のDeep Securityにフォーカスし、Deep Securityを実装するためのNSXエディションについてご紹介します。

NSXの各エディションとDeep Securityが提供する6機能の使用可否を整理します。
matrix

上の表から、主な使用目的は次の2つに分けられると思います。

①不正プログラム対策(ウイルス対策)
②侵入防御、ホスト型ホストファイアウォール

目的に合わせて、どのNSXエディションを選択するべきかを順に確認します。

①ウイルス対策のみの場合 (赤枠)ウイルス対策のみを使用したい場合は、無償ライセンスのNSX for vShield Endpointを含めた 4つのVMware NSXを選択することが可能です。

anti-virus

②侵入防御やファイアウォールの場合 (緑枠)侵入防御やファイアウォールを使用したい場合は、「AdvancedまたはEnterprise」を選択するか、「NSX for vShield EndpointまたはStandard」を選択するかの2パターンがあります。それぞれ準備するコンポーネントが異なります。

◆Advance / Enterprise◆
NSXのAdvancedまたはEnterpriseを選択する場合、Deep Security Virtual Appliance(DSVA)のみで、侵入防御やファイアウォールの機能を使用することができます。
adv-ent

◆NSX for vShield Endpoint / Standard◆
NSX for vShield EndpointまたはStandardを選択する場合、Deep Security Virtual Appliance(DSVA)で提供される機能はウイルス対策のみです。そのため、各仮想マシンにDeep Security Agent (DSA)をインストールし、侵入防御やファイアウォールを使用します。この方法がコンバインモードです。
combined-mode
コンバインモードの詳細はこちらをご確認ください。
http://esupport.trendmicro.com/solution/ja-JP/1112549.aspx?print=true

◆まとめ◆
侵入防御やファイアウォールを使用したい場合、どのNSXエディションを選択するかがポイントですね。Advanced / Enterpriseを選択するなら、導入が容易に思えます。一方でライセンスコストとの費用対効果を考えることも必要です。Advanced / Enterpriseで提供される機能が自社の運用管理の効率の向上が見込めるのであれば、この機会に検討されるのもよいですね。

無償の「NSX for vShield Endpoint」を選択するなら、DSAのライセンスを見積る必要があります。

現在、私個人が注目しているのは、運用面からの「ネットワークの仮想化」という選択です。

ここ数年、vRealize Operations Managerを介して、ユーザーの仮想基盤の運用管理のお悩みをうかがう機会が増えました。最近は、ストレージの運用の容易さから、Hyper-Converged Infrastructure (HCI)が台頭してきていますね。次はネットワークの仮想化の出番なのではないかと感じています。

今後のVMware Blogでは、運用面から見た「ネットワークの仮想化」の記事を投稿できたらと考えています。

次回は、VMware NSX for vShield Endpointへの移行検証サマリーを投稿します。

nakagawa

The post VMware NSX for vSphereへの移行 appeared first on Japan Cloud Infrastructure Blog.

VSAN Cormac Blog ~ VSAN6.1 新機能 – 問題のあるディスクの取り扱い ~

$
0
0

すでにお気づきの方もいらっしゃると思いますが、VMware Virtual SAN 6.1 リリースノートに下記の項目が追加されています。

Virtual SAN は、ソリッド ステート ドライブと磁気ディスク ドライブの健全性を監視し、健全でないデバイスをアンマウントしてそれらのデバイスを事前に分離します。また、Virtual SAN ディスクの段階的な障害を検出し、影響を受けるホストと Virtual SAN クラスタ全体で輻輳の状態になる前にそのデバイスを分離します。アラームは、健全でないデバイスが検出されたときと、健全でないデバイスが自動的にマウント解除された場合にイベントが生成されたときに、各ホストから生成されます。

この記事では、このすばらしい新機能に関するより多くの情報をご紹介する事が目的です。

 

歴史

まずdisk-failure-150x150はこの機能が必要となる背景をご紹介します。
我々はSSDや磁気ディスクドライブの不健全な動作が引き起こす問題に関していくつかの問合せを受けていました。
あるケースでは、ディスクから多くのエラーが報告されているにもかかわらず、故障には至っていませんでした。
最終的にこの1本のディスクにより、クラスタ全体のパフォーマンスの低下を引き起こしていました。

この新機能で実装された監視機構により、これらの不健全なディスクを未然に切り離し、クラスタ全体に影響を与えない事が可能となります。

この機能では、SSDもしくは磁気ディスクドライブで、長期間にわたり大幅な処理の遅延が発生していないかを探します。
VSANは特定のデバイスで長期間にわたる大幅な処理の遅延が確認されると、遅延デバイスがキャパシティデバイスの場合はディスクをアンマウントし、遅延デバイスがキャッシュデバイスの場合は、キャッシュデバイスが所属するディスクグループをアンマウントします。
対象のディスクもしくはディスクグループは”Absent”としてマークされ、CLOMD(Cluster Level Object Manager Daemon) タイマーの期限が切れると、クラスタの他の領域でコンポーネントのリビルドが行われます。

この動作により、一つの健全でないドライブによる影響を受けずに、仮想マシンのパフォーマンスが保たれます。

 

検出

VSANがこの処理をdisk-error-detect-150x150行った場合に、管理者/オペレーターはどのようにして知ることができるでしょうか?

さて、この問題が起こった場合、VOBs (VMware Observations)はさまざまなイベントをあげます。
例えば、VSAN Diskへの読込み時に、SSDもしくは磁気ディスクドライブのアンマウントにつながるような、閾値を超過する読込み遅延が発生した場合、下記のいずれかのメッセージが生成されます。

 


  • WARNING – READ Average latency on VSAN device %s is %d ms an higher than threshold value %d ms.
  • WARNING – READ Average Latency on VSAN device %s has exceeded threshold value %d ms %d times.

キャッシュデバイスもしくキャパシティデバイスのアンマウントにつながるような、閾値を超過する書込み遅延が発生した場合は、下記のいずれかのメッセージが生成されます。


  • WARNING – WRITE Average latency on VSAN device %s is %d ms an higher than threshold value %d ms.
  • WARNING – WRITE Average Latency on VSAN device %s has exceeded threshold value %d ms %d times.

繰り返しになりますが、対象のデバイスがキャッシュデバイスの場合はディスクグループへの影響があります。

読込み遅延の警告閾値を超過したため、下記のVOBメッセージが生成されます。


  • WARNING – Half-life READ Average Latency on VSAN device %s is %d and is higher than threshold value %d ms.

 

書込み遅延の警告閾値を超過したため、下記のVOBメッセージが生成されます。


  • WARNING – Half-life WRITE Average Latency on VSAN device %s is %d and is higher than threshold value %d ms.

 

トリガー / 閾値

トリガーとなる閾値は50msです。下記は、実際のホストのSSDで読み込み遅延を検知した場合のイベントの例です。


2015-09-15T02:21:27.270Z cpu8:89341)VSAN Device Monitor: WARNING – READ Average Latency on VSAN device naa.6842b2b006600b001a6b7e5a0582e09a has exceeded threshold value 50 ms 1 times.
2015-09-15T02:21:27.570Z cpu5:89352)VSAN Device Monitor: Unmounting VSAN diskgroup naa.6842b2b006600b001a6b7e5a0582e09a


 

ホーム・ラボユーザへの注意事項

VSANはエンタープライズクラスのHcautionCI(ハイパーコンバージド インフラストラクチャ)システムです。我々はミッションクリティカルなビジネス環境で必要とされるワークロードを、VSAN上で稼動させることをサポートします。

我々はデバイス、コントローラ、ドライバー、ファームウェアに関しての広範囲なHCL(ハードウェア互換性ガイド)をもっています。HCLから選択されたデバイスは、健全な場合にこのような大幅な遅延が発生する事はありません。HCLから選択されたデバイスでは、健全でないデバイスのみがこのような挙動を示すはずです。

しかしながら、我々は多くの顧客、パートナー、従業員がHCL以外のデバイスを使用してラボを運用していることを理解しています。この機能はVSAN6.1で有効となっているため、ラボの環境でコンシューマ向けのデバイスを使用している場合、大幅な遅延が発生し、この制限に該当した場合にデータストアをアンマウントする可能性があります。

この状況を回避するために、ディスクグループのアンマウントを防ぐ2個のパラメータが用意されています。


  • VSAN Device Monitoringの無効化:
    # esxcli system settings advanced set -o /LSOM/VSANDeviceMonitoring -i 0     ← デフォルトは “1” です

- もしくは -

  • VSAN Slow Device Unmounting 機能の無効化:
    # esxcli system settings advanced set -o /LSOM/lsomSlowDeviceUnmount -i 0     ← デフォルトは “1” です

ラボ環境では仮想マシンの稼動前や、データがホスト間で移動するメンテナンスモードタイプの操作を行う前に、すぐにこの機能を無効化したほうが良いかもしれません。これはラボの環境をVSAN 6.1 (vSphere 6.0u1)へアップデートする事を計画している場合も同様となります。

詳細は公式ドキュメントとしてKB2132079に記載されています。

 

最後に

この監視機構はVSANにとって素晴らしい機能拡張となりました。

これまで1本の不健全なデバイスが、VSANクラスタ全体への影響を引き起こしていた問題に対して、この機能により、デバイスの切り離し処理が適切におこなえる様になったため、この種類の問題による影響を軽減する事ができるようになっています。

 


原文: VSAN 6.1 New Feature – Handling of Problematic Disks

VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事は VSAN 6.1ベースに記載しております。予めご了承ください

The post VSAN Cormac Blog ~ VSAN6.1 新機能 – 問題のあるディスクの取り扱い ~ appeared first on Japan Cloud Infrastructure Blog.

vSAN に特化した vRealize Loginsight コンテンツパック

$
0
0

loginsight-logo vSAN ユーザの皆様へ重要なお知らせがあります。vSAN に特化した、Log Insight のコンテンツパックが新しくリリースされました。vSAN ユーザの皆さまの中は、 Log Insight をご存知ではない方もおられると思いますが、 Log Insight は様々なログの集約と、ログの分析を通じて、ログ管理の効率化・自動化を行います。この製品により、管理者は大容量のログを分析することや、非構造化データ(各種のログ)をすばやく解析し、GUI ベースの扱いやすいインターフェースを通じてインタラクティブでリアルタイムな検索や分析を行えます。

vSAN 用の新しいコンテンツパックは、vSAN の為のダッシュボードを用意しており、vSAN コンテンツパックを利用することで、vSAN の様々なログへの深い知識と洞察力を提供します。コンテンツパックは、様々なダッシュボード、クエリとアラートが含まれており、vSAN 管理者に優れた診断機能とトラブルシューティングを提供します。

Log Insight 用の他のコンテンツパックをインストールした方法・手順と同じようにインストールできます。

その前に、以下のように vSAN Cluster を管理している vCenter を管理下にします。

li-vc-1

コンテンツパックのインストールが完了すると、”VMware – vSAN” ダッシュボードが利用可能となります。

li-vsan-dash-2

vSAN 管理に特化した新しい項目を確認する為に、”VMware – vSAN” をクリックします。

li-vsan-dash3

ご覧通り、 vSAN に関して様々な観点で調べることができます。 Log Insight には、 vSAN 環境で発生している各種エラーや、問題が上がってきます。そのため、特に問題が発生していない場合、多くのレポートは空になります。

ここで、 vSAN 環境で収集された Log Insight の例を示します。

li-vsan-obj-config-create-4-new

上記のスクリーンショットは、vSAN オブジェクトの作成に関連するイベント群を表示しています。

下記のスクリーンショットでは、各対象の負荷 (congestion) と特定のデバイスの待ち時間 (device latency) が確認できます。

この環境では、過去24時間の内、一部の時間帯で平均デバイス待ち時間が上昇していることがわかります。ここでも、拡大するにはスクリーンショットをクリックしてください。

li-congestion-latency-5-new

いくつかのデバイスに遅延の問題が発生している、という事実がわかりましたが、それは何を示しているのでしょうか。 “i” のアイコンをクリックすると、そのイベントの詳細情報を確認できます。

また、より多くの情報を持つ VMware KB へのリンクを提供する場合もあります。

li-vsan-latency-kb-link-6-new

簡単ではございますが、vSAN 環境のログ管理を効率化する方法をご説明しました。
ご確認いただいたように、Log Insight は vSAN 環境を管理しているユーザ様にとって問題発生時の切り分け、問題発生箇所の分析などで有益な機能を提供します。

もし、すでに Log Insight を使用されており、 vSAN 環境をお持ちでしたら、このコンテンツパックの導入・テストを強く推奨いたします。また、Log Insight は vRealize Operations Manager にも連携され、vSphere 全体の管理性が向上されます。 Log Insight の使用を是非ご検討ください。

vSAN 用のコンテンツパックは VMware Solutions Exchange から見つけることができます。

原文:A new vRealize Log Insight Content Pack for VSAN
http://cormachogan.com/2015/12/03/a-new-vrealize-pack-for-vsan/
VSAN Cormac Blog 日本語版 Index
http://blogs.vmware.com/jp-cim/2016/03/vsan-index.html

VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの機能に関しては弊社マニュアル 、KBをご確認ください。また本記事は vSAN 6.2 ベースに記載しております。予めご了承ください。

The post vSAN に特化した vRealize Loginsight コンテンツパック appeared first on Japan Cloud Infrastructure Blog.


VSAN Cormac Blog ~ vSAN 6.2 キャパシティ ビュー

$
0
0

vSAN Cormac Blog ~ vSAN 6.2 キャパシティ ビュー ~ 

 

vSAN 6.2 の新機能の中でも、特に重複排除や圧縮のような容量効率化の機能に注目している方も多いかと思います。
この機能の他にも、新しく バージョン3になった オン ディスクフォーマット と新しいソフトウェアチェックサム機能があります。
これらの機能はキャパシティのオーバーヘッドをもたらしますが、vSAN 6.2 で導入された新しいストレージビューにより、管理者によるストレージ消費の追跡を容易にしています。

%e7%94%bb%e5%83%8f1

まず最初にキャパシティ オーバービューに焦点をあてた場合、vSAN データストアの全体サイズを見ることができます。 (上記の画面では 59.43 TB あります。)

併せて、重複排除と圧縮のオーバーヘッドも確認することができますが、更にファイルシステムのオーバーヘッドやチェックサムのオーバーヘッドを確認したい場合は、画面下部の使用量の内訳で詳細を表示することができます。

使用済み合計 – vSAN データストア上で、物理的にどれくらいのデータが書き込まれているのか (論理サイズとは対照的)を表しています。

これは、データストア上に存在することができる仮想ディスク、 仮想マシンのホームオブジェクト、スワップオブジェクト、パフォーマンス管理オブジェクトおよびその他の項目の組み合わせです。

 

その他の項目とは、例えば ISOイメージ、未登録の仮想マシン、またはテンプレートなどがあります。 画面下部の使用容量内訳の仮想マシンオブジェクトに表示されている値は、オブジェクトの種類ごとにグループ化されたときに、関連する使用量、重複排除と圧縮前の値かが計算されています。

重複排除と圧縮を行った後に、オブジェクトがどのくらいのスペースを消費しているかを確認するための情報は、この時点ではありません。

しかし、これらのスペース効率の機能によって保存されている領域の量が確認できないということではありません。

 

画面右上のデデュープと圧縮の概要は、スペースの節約とデデュープ (重複排除) 率がどれくらい達成しているのかを確認できるのと同様に、管理者が vSAN 上のスペース効率化の機能を無効にして重複排除と圧縮されたオブジェクトを再膨張させたい場合に有効な情報となる場合があります。

展開されている仮想マシンがより類似のものであれば、容量の節約率は高くなります。ここでは、数百の仮想マシンを展開している例です。いかがでしょうか?

%e7%94%bb%e5%83%8f2

これは、重複排除と圧縮を使用しないで現在のワークロードを展開した場合、11TBほどが必要になることを意味しています。 重複排除と圧縮機能を使用することで、400GB程度まで削減されました。

留意点は、「使用前 (Used Before)」の値は、レプリカ(RAID-1)とパリティ(RAID-5/6)の値も含まれることです。これは、データタイプのグループを反転させることで、すぐに確認することができます。

これで、重複排除と圧縮を無効にして、仮想マシンをもとのサイズに再膨張させた場合に必要とされる容量を確認することができます。

上記のような操作を計画している場合、この画面を参照し、利用可能な十分な容量があることを確認してください。

 

続いて、キャパシティビューの中で表示されているオブジェクトの説明です。

%e7%94%bb%e5%83%8f3

・オブジェクトタイプのグループ

 

パフォーマンス管理オブジェクト

パフォーマンスサービスが有効になっている場合、パフォーマンス・メトリックを格納するために作られたオブジェクトによって消費される容量

 

ファイルシステムのオーバーヘッド

重複排除、圧縮やチェックサムのオーバーヘッドに起因しない、容量のドライブ上のファイルシステム(VirstoFS)に取り込まれた任意のオーバーヘッド 。

重複排除と圧縮が有効になっている場合、ファイルシステムのオーバーヘッドは、 vSANデータストアの論理サイズの増加を反映して10倍に増加されます。

 

デデュープおよび圧縮のオーバーヘッド

重複排除と圧縮の効果を得るため、オーバーヘッドが発生します。これは、重複排除や圧縮のために必要なマッピングテーブル、ハッシュテーブル、そして他のメカニズムに関連付けられたものが含まれます。

チェックサムのオーバーヘッド

すべてのチェックサムを格納するオーバーヘッドです。重複排除と圧縮が有効になっている場合、チェックサムのオーバーヘッドは、 vSANデータストアの論理サイズの増加を反映して10倍に増加されます。

 

vSANデータストア上に仮想マシンやテンプレートを展開している場合は、より多くのオブジェクトが表示されます。

 

仮想ディスク

vSAN上に存在する仮想マシンディスク (VMDK)のオブジェクトによって消費される容量

 

仮想マシン ホーム オブジェクト

vSANデータストア上に存在する、VMホームの名前空間オブジェクト(仮想マシンファイルを含む)によって消費される容量

 

スワップ オブジェクト

vSANデータストア上に存在する仮想マシンのスワップ領域によって消費される容量。

 

Vmem オブジェクト

仮想マシンのスナップショット取得時に作成されるメモリオブジェクトによって消費される容量。これは仮想マシンバ ージョン10以上をつかっているときのみ表示されます。

 

 

その他

仮想マシンテンプレート、登録されていない仮想マシン、仮想マシンに関連付けられていないスタンドアローンのVMDK、手動で作成 されたvSANオブジェクト、手動で作成されたISOを保存しているディレクトリによって消費される容量。

次は、別のビューであるデータタイプを掘り下げてみてみましょう。

%e7%94%bb%e5%83%8f4

データタイプのグループ

プライマリ 仮想マシン データ

VMホームの名前空間、VMスワップとVMDKオブジェクトを含む、仮想マシンによって消費される容量

 

Virtual SAN オーバーヘッド[レプリカ・監視・RAID 5 コンポーネントなど]

レプリカや 監視 (Witness )、Raid 5 / 6 のパリティやその他のデータによって消費される容量。

 

一時的なオーバーヘッド

オブジェクトの移動や再構成によって、一時的に消費される容量。

 

使用済み予約超過仮想マシン

重複排除と圧縮が有効にされていない場合は、画面上のキャパシティの概要部分に表示されます。このフィールドは 「使用済み – 予約超過仮想マシン」と呼ばれます。

 

オブジェクト・スペース・リザベーション (OSR) を使用することを決めたら、このフィールドによりどのくらいのスペースが予約されるのかを確認することができます。この値が高い場合、オブジェクトスペースリザベーションの値を減らし、このスペースの一部を他の用途に再利用する価値があるか、再検討する必要があります

 

重複排除と圧縮を有効にしている場合、オブジェクト領域の予約は0%または100%に設定する必要がありま す。(これら以外の中間値を設定することはできません。)

容量の消費のされ方や重複排除/圧縮がどのように動作しているかを確認するフィールドです。

容量の観点から他の情報も項目として必要である・有用であるというご要望がある場合は、私までお知らせくださいませ。プロダクトマネージャーやエンジニアにフィードバック致します

原文  VSAN 6.2 Part 7 – Capacity Views 

(http://cormachogan.com/2016/02/25/vsan-6-2-part-7-capacity-views/)

VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。vSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事はvSAN 6.2ベースに記載しております。予めご了承ください

 

The post VSAN Cormac Blog ~ vSAN 6.2 キャパシティ ビュー appeared first on Japan Cloud Infrastructure Blog.

VMware NSX for vSphereへの移行

$
0
0

3回目:VMware NSX for vShield Endpointへの移行検証サマリー

-Back Number-
#1_ vCloud Networking and Security (vCNS) の販売終了
#2_Deep Securityを実装するためのNSX
#3_ VMware NSX for vShield Endpointへの移行検証サマリー

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、「vShield Endpoint(vCNS)からNSX for vShield Endpointへのアップグレード手順をご紹介します。このBlogでは簡単な手順を共有します。詳細な手順をお知りになりたい方は、この後ご紹介するURLから入手ください。

◆構成図◆
今回の手順は、下図の構成で環境を構築しています。赤点線枠のコンポーネントをアップグレードします。vSphere 6.0環境下で、NSX for vShield Endpointへ移行します。
今後、vSphere 5.5 U1 + View 5.3 + Deep Security 9.5環境下からのアップグレード手順もご紹介する予定です。
env

◆アップグレード手順◆
次の11ステップを進めます。
1
2
3
4
5
6
7
8
9
10
11

◆詳細手順◆
<アップグレード手順>
詳細手順を入手されたい方は、こちらにアクセスください。
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/techresources/20161206_NSXforvShield_Upgrade_Guide.pdf?elqTrackId=0d6a8486773f458c87c7f923b4e16016&elqaid=979&elqat=2

<新規手順>
「NSX for vShield EndpointおよびDeep Securityの新規構築」手順も準備しました。
こちらから入手ください。
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/techresources/Tips_NSX6.2.4_DS9.6SP1_PoC_20161121.pdf?elqTrackId=0d6a8486773f458c87c7f923b4e16016&elqaid=979&elqat=2

◆まとめ◆

今回のBlogでは、vSphere 6.0環境でのアップグレード手順を共有いたしました。vSphere 6.0環境をご使用のエンドユーザー様は、こちらの手順を参考にアップグレードの計画を進めていただけましたらと思います。
最後に、仮想スイッチについて補足します。NSX for vShield Endpointは、標準スイッチ(vSS)での動作をサポートしています。今回の環境は標準スイッチを構成しています。他の3つの有償エディション(Standard/Advanced/Enterprise)では、分散スイッチ(vDS)のみのサポートになります。標準スイッチはサポートされません。仮想デスクトップ環境は、より多くのESXiホストで構築されています。複数のESXiホストで構成されたクラスタ環境において、分散スイッチのメリットを享受できます。こちらのBlogで、あらためて分散スイッチの活用方法についてご紹介したいと考えています。現在標準スイッチで仮想デスクトップ環境を構築されていらっしゃる場合は、分散スイッチのメリットをご認識いただけましたら幸いです。

nakagawa

The post VMware NSX for vSphereへの移行 appeared first on Japan Cloud Infrastructure Blog.

PowerCLI 6.5 Release 1 and vSAN

$
0
0

powercli

今朝、私が最初に見たメールは、私の仲間の Alan Renouf からのも のでした。
Alan は、API、SDK、CLI、および Automation Frameworks (Alan 昇進おめでとう)の製品ラインマネージャーです。
このリリースでは多くの改良点があり、多くの賛辞は PowerCLI チームに送られなければなりません。
vSAN の観点からも、この PowerCLI の改良は素晴らしいものです。
補足
PowerCLI  のこれらの新機能を活用するために vSAN 6.5 にアップグレードする必要はありません。
このバージョンの PowerCLI は、vSAN 6.2 および 6.0 でも動作します。

Alan 曰く、
「今回のリリースでは、PowerCLI ストレージモジュールに大きな焦点が当てられています。 vSAN、仮想ボリューム(VVols)、および仮想ディスクの処理に関して多くの機能が追加されています。 vSAN コマンドレットは、vSAN クラスタのライフサイクル全体に焦点を当てた12個以上のコマンドレットに強化されています。 新しい PowerCLI を用いて、テストの実行や vSAN HCL データベースの更新だけではなく、vSAN クラスタ作成プロセス全体を自動化することができます」

vSAN コマンドレットの一覧を次に示します。

  • Get-VsanClusterConfiguration
  • Get-VsanDisk
  • Get-VsanDiskGroup
  • Get-VsanFaultDomain
  • Get-VsanResyncingComponent
  • Get-VsanSpaceUsage
  • New-VsanDisk
  • New-VsanDiskGroup
  • New-VsanFaultDomain
  • Remove-VsanDisk
  • Remove-VsanDiskGroup
  • Remove-VsanFaultDomain
  • Set-VsanClusterConfiguration
  • Set-VsanFaultDomain
  • Test-VsanClusterHealth
  • Test-VsanNetworkPerformance
  • Test-VsanStoragePerformance
  • Test-VsanVMCreation
  • Update-VsanHclDatabase

この記事中で私は vSAN 固有の項目だけを強調していますが、Alan が言及するように、VMDK の管理や、Storage Policy Based Management(SPBM) や VVols の新しいコマンドレットなど、他のストレージ領域でも機能が強化されています。

VMware PowerCLI 6.5 Release 1 での変更点の詳細については、(新機能、改善点、bug fix、セキュリティ強化点、廃止予定の機能など) VMware PowerCLI Change Log を参照してください。
特定の機能の詳細内容については、「VMware PowerCLI 6.5 Release 1 User’s Guide」 を参照してください。
特定のコマンドレットの詳細内容については、「VMware PowerCLI 6.5 Release 1 Cmdlet Reference」を参照してください。
ここから PowerCLI 6.5 Release 1 を見つけることが出来ます。 すぐに入手ください!

原文:PowerCLI 6.5 Release 1 and vSAN
http://cormachogan.com/2016/11/18/powercli-6-5-release-1-vsan/
vSAN Cormac Blog 日本語版 Index
http://blogs.vmware.com/jp-cim/2016/03/vsan-index.html

VMware Storage and Availability Business Unit の シニアスタッフエンジニア Cormac Horgan の個人ブログを翻訳したものになります。vSAN の機能に関しては弊社マニュアル 、KB をご確認ください。また本記事は vSAN 6.2 ベースに記載しております。予めご了承ください。

The post PowerCLI 6.5 Release 1 and vSAN appeared first on Japan Cloud Infrastructure Blog.

vSANのデザインとサイジング - メモリオーバーヘッドに関する考慮点

$
0
0

今週はEMEAで開催されるテックサミットに参加するためベルリンに来ています。このイベントはEMEAのフィールドの皆さんのためのイベントです。私は、vSANのデザインとサイジングを含むいくつかのセッションを担当しました。そのセッションの一部では、トピックとしてvSAN環境でのメモリ消費について取り上げました。過去には、こちらのブログでも触れました通り、ディスクグループ構成によるホストのメモリ要件についてのみお話しをしてきました。例えば、vSANの最大構成時(ホスト毎に最大5つのディスクグループ、各ディスクグループには最大7台のディスクを割り当て可能)には、ホストのメモリを最低でも32GB消費します。しかし、これはvSANのみが消費するのではなく、ワークロードを実行するために消費されるのかもしれません。その値は構成の上限としてお考えください。上の過去のブログで触れたように、もしホストが32GB以下のメモリしか搭載していない場合は、ホスト上で作成されるディスクグループの数を減らす必要があります。
私の知っている限り、何がvSANクラスタ上のメモリ消費の一因となるのかについて、情報として共有されていませんでした。このブログで、その部分について説明をしていきたいと思います。

[Update] KB2113954でも、vSAN環境でのメモリ消費について触れられています。

vSAN環境のメモリ消費を理解するために、以下の方程式が使われます。

equation

BaseConsumption:ESXiホスト毎で、vSANによって消費される固定のメモリ量。この値は現在は3GBです。このメモリは、vSANのディレクトリ情報、ホスト毎のメタデータ、メモリキャッシュを格納するために使われます。vSANクラスタが16ノードを超える場合は、BaseConsumptionの値は300MB増えて、3.3GBとなります。

NumDiskGroups:ホスト毎のディスクグループ数。1から5の範囲で設定可能です。

・DiskGroupBaseConsumption:ホストの個々のディスクグループによって消費される固定のメモリ量。この値は現在500MBです。このメモリは、主にディスクグループ毎の操作の際に使われます。

・SSDMemOverheadPerGB:SSDの各GB毎に割り当てられた固定のメモリ量。この値は現在はハイブリッド環境では2MB、オールフラッシュ環境では7MBとなっています。このメモリの大部分は、ライトバッファやリードキャッシュ用途として使われるSSD内のブロックのトラックを保持するために使われます。

・SSDSize:SSDのサイズ(GB)

注意:これらの値はvSAN 6.0,6.1,6.2を前提としています(KB2113954参照)。将来バージョンで変更される可能性があります。

それではいくつかのシナリオに沿ってメモリ消費について理解を深めていきましょう。

シナリオ1
各ホストで32GB以上のメモリを搭載、vSANクラスタを構成するホスト数は16台以下、SSDのサイズが400GB。

例1
ホスト毎に1つのディスクグループ、ハイブリッド構成

example1

例2
ホスト毎に3つのディスクグループ、ハイブリッド構成

example2

例3
ホスト毎に1つのディスクグループ、オールフラッシュ構成

example3

例4
ホスト毎に3つのディスクグループ、オールフラッシュ構成

example4

シナリオ2
各ホストで32GB以上のメモリを搭載、vSANクラスタを構成するホスト数は16台以上、SSDのサイズは600GB。
vSANクラスタが16台を超える場合は、BaseConsumptionは300MB増えてトータル3.3GB。

例5
ホスト毎に1つのディスクグループ、ハイブリッド構成

example5

例6
ホスト毎に3つのディスクグループ、ハイブリッド構成

example6

例7
ホスト毎に1つのディスクグループ、オールフラッシュ構成

example7

例8
ホスト毎に3つのディスクグループ、オールフラッシュ構成

example8

シナリオ3
各ホストで32GB以下のメモリを搭載。32GBよりも少ないため、メモリの消費量は公式(SystemMemory/32)に従って直線的に減少します。SystemMemory(GB)とは、システムに搭載されるメモリの搭載量です。よって、システム搭載メモリが16GBの場合、メモリ消費量は公式から”1/2”となります。システム搭載メモリが8GBの場合、”1/4”まで減少します。

各ホストの搭載メモリが16GB、vSANクラスタを構成するホスト数は16台以下、SSDのサイズが400GBという前提で考えましょう。

例9
ホスト毎に1つのディスクグループ、ハイブリッド構成

example9

例10
ホスト毎に3つのディスクグループ、ハイブリッド構成

example10

例11
ホスト毎に1つのディスクグループ、オールフラッシュ構成

example11

例12
ホスト毎に3つのディスクグループ、オールフラッシュ構成

example12

vSAN構成におけるメモリ消費量について、いくつかの例をもとにまとめてきました。このようにして、vSANのメモリオーバーヘッドを算出することができます。特に考慮すべき点は、以下の通りです。

・ホストのメモリ搭載量が32GB以下の場合には、vSANはメモリ消費を抑制します
・16ノードを超えるvSANクラスタ環境では、追加でメモリを消費します
・オールフラッシュ構成では、ハイブリッド構成と比べて追加でメモリを消費します

The post vSANのデザインとサイジング - メモリオーバーヘッドに関する考慮点 appeared first on Japan Cloud Infrastructure Blog.

What’s new in VSAN 6.5?

$
0
0

このトピックについて、さまざまな情報源から多くの情報が確認できると思います。
当然ですが、VMware のテクニカルマーケティングチームから発信される、最新の有益なドキュメントをチェックし、より詳細な情報や公開されているマニュアル等を参照することを強くお勧めします。
しかし、私からも vSphere 6.5 で使用できる新しい vSAN 機能の概要を説明したいと思います。
このバージョンの vSAN は6.5 と呼ばれます。

1. ライセンスに関する変更
まず最初に強調したいのは、vSAN のライセンスに関する大幅な変更です。
ライセンス条件は緩和されており、vSAN Standard ライセンスで All-Flash vSAN クラスタを展開できるようになりました。ですが、この vSAN Standard では重複排除や圧縮などのデータサービスは利用できません。これらのデータサービスを使用するには、より上位のライセンスのエディションが必要になります。

補足:vSAN 6.5 での各エディションと利用できる機能は以下の PDF P4 で確認できます
VMware vSAN 6.5 Licensing Guide

2.  iSCSI サポート
vSAN 6.5 には、vSAN クラスタ上に iSCSI ターゲットと LUN を作成するための新しい機能が追加され、これらの LUN は vSAN の外部で他の用途に使用できます。これは、vSAN クラスタに必要以上のストレージ容量があり、その容量をクラスタ外で利用する場合に便利な機能です。

この新しい機能をどのように利用できるかについては、多数の制限とサポートに関する考慮事項があることに留意ください。たとえば、これらの iSCSI LUN を ESXi ホストに提供することはできません。
本番環境で iSCSI LUN を実稼動させる前に、公式ドキュメントを参照し、出来ること・出来ないことを確認する事を強く推奨します。

3. 2 ホストでの展開における直接接続と 監視トラフィック(witness traffic)の分離
これは、リモートオフィス/ブランチオフィス(ROBO)での利用、もしくは小規模ビジネス(SMB)のユースケースで利用する場合、2台のホストで vSAN を展開することを検討している方にとって非常に興味深い改善です。
VMware は、この構成での 2つの ESXi ホストをネットワークケーブルで直接接続することをサポートし、ESXi ホスト間の物理スイッチが必要ではなくなります。
この拡張機能には、vSAN 監視トラフィックをデータトラフィックから切り離すためのメカニズムが含まれています。つまり、vSAN データトラフィックを直接接続ネットワークに残すことができ、監視トラフィックを別の VMkernel インターフェイス経由で監視ホスト/アプライアンスに送信することができます。繰り返しになりますが、 公開されている情報が豊富に存在し、この新しい構成を展開する方法の詳細がテクニカルマーケティングチームからリリースされます。これにより、2ノードの vSAN 構成を展開するコストが大幅に削減されます。

4. 512eデバイスのサポート
これは多くのお客様が求めていることです。 4K ネイティブデバイスはまだサポートされていませんが、これらの512e (エミュレーション)デバイスのサポートにより、今後はより大容量のデバイスを vSAN で使用できます。

5.  vSAN 用の PowerCLI コマンドレット
多くのお客様が求めているのは、PowerCLI コマンドレットを利用し、さまざまな vSAN タスクをスクリプト化 / 自動化することです。既に公開されたPowerCLIの新バージョン6.5には、vSAN で使用できる新しい PowerCLI コマンドレットもいくつか用意されています。
これらのコマンドレットも以前のバージョンの vSAN と下位互換性があり、以下の VMware Product Interoperability Matrixes  から、PowerCLI 6.5 と、vSAN 6.5, 6.2, 6.0 との互換性を確認できます。
VMware Product Interoperability Matrixes

また、PowerCLI 6.5 は以下より入手できます。
Download VMware PowerCLI 6.5 Release 1
VMware PowerCLI Documentation

vSAN 6.5 の便利な新機能について、皆さまに賛同いただけると確信しています。

原文:What’s new in Virtual SAN 6.5

What’s new in Virtual SAN 6.5

VSAN Cormac Blog 日本語版 Index
http://blogs.vmware.com/jp-cim/2016/03/vsan-index.html

VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。vSANの機能に関しては弊社マニュアル 、KBをご確認ください。また本記事は vSAN 6.2 ベースに記載しております。予めご了承ください。

 

The post What’s new in VSAN 6.5? appeared first on Japan Cloud Infrastructure Blog.

VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

$
0
0

3回目:ビューの活用方法②

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回お伝えしましたとおり、今回はカスタムビューの活用方法をご紹介します。

最初に、エディションごとの機能を確認します。

◆エディション◆
カスタム機能を使用するには、「Advanced」エディション以降が必要です。前回ご紹介した標準ビューの機能は、「Standard」エディションから使用できます。

lic

◆カスタムビュー◆

下図のビューは、「CPU」「メモリ」「データストア」「ネットワーク」の4つのメインリソースのワークロードを調査するために新規作成しました。グラフが少々ひしめき合っていますが、複数リソースの相関関係の確認を前提に構成しました。

main-resource-workload

たとえば、ネットワークI/Oの遅延の原因を調べていたら、CPUの処理性能が原因だったということがあります。複数のリソースを並べたカスタムビューを活用すれば、このような相関関係を確認する場合に最適です!
先のカスタムビューを例に、「CPU」と「ネットワークI/O」の相関関係を調べたい場合は、「メモリ」と「データストアI/O」の凡例(ラベル名)を2回クリックします。そうすることで、調査対象のグラフのみ表示されます。もう一度ラベル名をクリックすれば、グラフは再表示されます。1つのカスタムビューで、表示を切り替えることにより、活用度がぐ~んと上がりますね。

ここからは、カスタムビューの作成手順を確認します。

◆カスタムビューの作成①◆

ナビゲーションパネルの「コンテンツ」ボタンをクリックします。左メニューから「ビュー」をクリックし、ビューの管理画面を表示します。「ビューの作成」ボタンをクリックします。

create-view

先のカスタムビューを例に、新規作成します。5つのステップで完成です!


1
2
3
4-1
4-2
4-3
4-4
4-55

◆標準ビューを利用したカスタムビューの作成◆

次は、標準ビューをコピーし、ビューを作成する方法を確認します。この方法は、表示されるデータのみを変更したい場合に適しています。
先にコピー元となるビューを確認します。下図は、「仮想マシンのワークロードデマンドサマリリスト」ビューです。仮想マシンが過去1週間に使用したリソース状況を確認することができます。仮想マシンでワークロードが高い場合、どのリソースが高いワークロードを引き起こしているかを特定することができます。
各リソースは、「5分」間隔でロールアップされ、過去「1週間(7日間)」の「平均値」が表示されます。これらはデフォルトの値です。「ロールアップ間隔」と「日付範囲(期間)」は、この画面のアイコン(赤枠)から都度変更できます。

rollup

◆カスタムビューの作成②◆

デフォルトの平均値を「最新値」に変更するカスタムビューを作成します。最新値を表示したいというご要望はよくあります。
ビューの管理画面で、変更したいビューを選択し、「ビューのクローン作成」アイコンをクリックします。

view-clone

ここでは、「名前」とデータの「変換」の値を変更するだけです!

custom-view-1

他に、何が変更できるのかを確認します。
「ロールアップ間隔」と「日付範囲」は、ビュー画面以外にウィザード内でも変更できます。


custom-view-2
custom-view-3custom-view-4

◆まとめ◆

すべてのビューをながめてみました。ビューでは、さまざまな視点からデータを得られます。そのデータをぜひ活用いただきたいです。
加えてビューは、ダッシュボードやレポートを構成するウィジェットとしても使用できます。ダッシュボードのビュー活用法はこちらのBlogで紹介しています。レポートのビュー活用法は次回のBlogでご紹介します。
実は、「vROpsをパワーアップしよう!」Blogを投稿する前は、カスタムが苦手でした。しかし、Blogを執筆する機会を得たり、ワークショップでエンドユーザー様からのご要望にお応えしたりするうちにすっかりはまってしまいました(笑)。

このBlogから、みなさんの仮想基盤がパワーアップされましたら、うれしい限りです!!

nakagawa

ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!

voa

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2 appeared first on Japan Cloud Infrastructure Blog.

VSAN で DR / BCP を実現する VSAN Stretched Cluster !! ~ vSAN stretched clusterとは? ~

$
0
0

第1回 vSAN stretched clusterとは?

img_0284

皆さん、こんにちは。JBCC株式会社の美谷島と申します。

突然ですが、VSAN Stretched Cluster をご存知でしょうか?

先日のvForum 2016 の VSAN Deep Dive セッションでも紹介されていました vSAN stretched Clusterの概要、構築方法などを 今回から4回にわたってご紹介していきたいと思います。

第1回ではvSAN stretched clusterとは?と題してvSAN stretched clusterの概要・メリット、サイジング方法をご紹介します。

弊社では、VMware社のvSphereやHorizonのような仮想化製品のインテグレーションに力を入れています。

その中でも、特に注目したのが ” Software Defined Storage(以下SDS)”です。SDS は一言でいうとソフトウェアでストレージ機能を実装するという技術です。仮想化基盤では可用性を持たせるために共有ストレージ装置が必要となりますが、SDS を導入すれば汎用的なx86サーバだけで共有ストレージ機能を実現できるのが強みです。また、x86サーバを追加するだけで簡単に容量とパフォーマンスを増強することができますので、オンプレミス環境であってもクラウド環境のような柔軟な拡張性が実現できるようなりました。ちなみに SDS は近ごろ大変脚光を浴びている Hyper-Converged Infrastructure のコアテクノロジーでもあります。

現在各社からたくさんの SDS 製品がリリースされておりますが、その中でも VMware 社の vSAN stretched cluster 機能 は BCP 対策も可能な高度な機能を有したストレージです。

私共はこの vSAN stretched cluster に着目して、お客様に新たな選択肢となり得るであろう BCP ソリューションをお届けするためにこれを検証することにしました。

 

vSAN概要

1

まず、stretched clusterを語る前に簡単に vSAN のおさらいをしておきますが、 vSAN は SDS 製品の中でも代表格となる製品です。 従って、 vSAN によって SDS のメリットがもれなく享受でき、その上、各ノードに SSD を配置することで、これをディスクの Read Write の IO のキャッシュとして利用することができパフォーマンス向上も期待できます。さらには、仮想マシン毎に可用性のレベルや QoS をセットすることが可能で、ポリシーベースで柔軟性があるところも他の SDS にはない、非常に大きな強みとなっています。

 

 

vSAN Stretched Cluster概要

ここからが本題となりますが、 Stretched Cluster は通常の vSAN 構成と何が違うのでしょうか。

端的にご説明しますと地理的に離れたサイト間で vSAN が組めるということです。普通に考えれば2サイトにロケーションが分かれればストレージは2つ独立して存在することになるのですが、 Stretched Cluster は2つのサイト間(地理的に離れたサーバ同士)でも1つの共有ストレージとして扱うことができます。

 

2

 

また、災害対策と言うと一般的には Active – Standby 構成となり、災害対策サイト側の機器は普段は稼働することなく、遊んでしまっている状態になってしまい、ちょっと勿体ない構成となってしまいますが vSAN Stretched Cluster は本番サイト、災対サイト 共に Active – Activeで構成できる ことがポイントです。

Active – Active構成にすることで以下のメリットが挙げられます。

 

・災害対策サイト側も Active なのでリソースを有効活用

・ゼロRTO * 1(サイト間でデータは完全同期レプリケーション)

*1 RTO ・・・ Recovery Time Objective

・各サイトにvCenterを配置する必要がなく、本番サイト1つで良い

・本番サイトから災害対策サイトへの切り替え作業が不要

(基本的にL2延伸でサイト間は利用しますので、DNSによるレコード切替、IPアドレス変更といったサイトを切り替える手順を実施する手間が省けます。)

 

シンプルな構成で DR 構成を組みたいといったユーザ様にとってはメリットが大きい構成だと思います。

また、通常の vSANは 同じデータを別ホストにも書き込むことで冗長性を担保していることが特徴ですが、 vSAN Stretched Cluster構成であれば別サイトのホストに可用性のためのデータを書込むことが可能になりますので、サイト障害にも、もちろん データロスなしで対応できます。

 

その他に必要となるコンポーネントとして witness サーバがあります。 Witness サーバとは監視サーバのことであり、サイトの死活監視をしていますので Witness サーバは両サイトとは別のセグメントで立てる必要があります。

vSAN Stretched Cluster 環境では2フォルトドメインまで立てられ、各フォルトドメインに15ホストまで構築可能です。フォルトドメインとは Disk グループで構成される障害の単位になります。

 

vSAN Stretched cluster の要件は以下の通りです。(一般的な vSAN の必要条件はここでは割愛します。)

 

・vSphere 6.0 update1以上

・最適な仮想マシンの挙動を行うためにDRSのアフィニティルールが必要となりますので、エディションはEnterprise Plus以上

・10 Gbps以上のネットワーク帯域(サイト間)

・100 Mbps以上のネットワーク帯域(サイト ー witness間)

・5 msec以下のlatency(サイト間)

・100 msec以下のlatency(サイト ー witness間)

・サイト間はL2接続

・サイト – witness間は L3 接続

 

3

 

既にお気づきかと思いますが、ここで肝となるのがネットワーク(vSANネットワーク)です。

そこで、vSAN ネットワークのサイジング方法をご紹介します。

 

 

サイジング

ここからはサイジングの話となります。まず、CPUやメモリ、 Diskといったサイジングについては通常のvSAN 構成と同様なので以下の VMware 社 川崎様記載のブログを参照ください。

http://blogs.vmware.com/jp-cim/2016/04/vSAN_04.html

 

通常のvSAN構成と違う点としては、片方のサイトが被災した場合も考慮しなければいけないのでCPU、メモリは片方のサイトで賄えるようにサイジングする必要があります。

ネットワークのサイジングについては write のスループットがポイントとなってきます。データを書き込む際の処理の動きは図4の通りとなり、サイト間の vSAN ネットワークが 5msec以内であることが必須要件となります。

データの読み込みは仮想マシンが稼働しているプライマリホスト群から直接読み込みますので別サイトにあるホストにアクセスすることはなく、WAN経由してまでvSANネットワークを使うことはありません。(図5)

 

4

 

5

 

そこで各ホストの write のスループットを算出することで必要となる vSAN ネットワーク帯域が判明できますのでネットワークをサイジングするときは write スループットの算出がお勧めです。

 

※ JBCC社における構成時の参考値

・既存に vSAN を導入している場合

…ESXTOPで算出

・vSphere 環境のみであり、新規に vSAN Stretched Cluster を導入する場合

…既存ストレージの管理画面から取得

 

(例) writeスループット:1 Gbpsの場合

vSAN ネットワーク=1 Gbps ( writeスループット)×1.4(オーバーヘッド)×1.25(障害時に走るtraffic 25 % 込)=1.75 Gbps

 

この場合であれば10 Gbpsの帯域で余裕ですね。

 

以上が vSAN Stretched Clusterの概要、サイジング方法でした。

 

尚、弊社ではストレージのワークロードを分析しお客様環境のIO分析をするストレージクリニックと呼ばれる無償サービスを実施していますのでwriteスループットの算出のみでなく仮想環境のサイジングを実施する際は是非ともご活用ください。

http://www.jbcc.co.jp/products/plan/storage_clinic/index.html

 

ただ、障害時にどのような挙動になるか気になりますよね?

JBCC は日本で最初にvSAN Stretched Clusterをお客様に提案し、ご採用頂きました。

ご採用頂くにあたり私共は、様々な検証をしました。そのときの内容を元に、次回は障害時の挙動に関してご紹介しますので是非ともご確認ください。

 

vSAN Stretched Clusterブログ

第1回 vSAN Stretched Clusterとは?

第2回 障害時の挙動

第3回 構築、運用ポイント

第4回 JBCC推奨構成

 

 

 

The post VSAN で DR / BCP を実現する VSAN Stretched Cluster !! ~ vSAN stretched clusterとは? ~ appeared first on Japan Cloud Infrastructure Blog.


VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

$
0
0

4回目:レポートの活用方法

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回はレポートの活用方法をご紹介します。レポートを活用するためには、カスタマイズが必要です!!

◆よくあるご質問◆

「レポートの出力期間を変更したい」と質問を受けることがあります。その場合はレポートの元となる「ビュー」の日付範囲を変更します。
レポートは、1つ以上の「ビュー」または「ダッシュボード」、もしくは両方から構成されます。データの表示は「ビュー」または「ダッシュボード」を使用し、レイアウト(配置)や出力形式(PDF/CSV)をレポートの作成ウィザードで指定します。

◆カスタムレポートの作成①◆

既存レポートの出力期間(過去の期間)をデフォルトの30日から特定の2ヶ月間に変更します。
<データタイプの確認>
ここでは、「ホストのCPUデマンドおよび使用量(%)トレンドビューレポート」をカスタムの対象にします。どのビューを元にレポートが構成されているかを確認します。レポートを選択し、「テンプレートの編集」アイコンをクリックします。

edit-report-template

「2.ビューとダッシュボード」の「データタイプ」が表示されます。このレポートは、「ホストのCPUデマンドおよび使用量(%)トレンドビュー」というビューで構成されていることがわかります。

edit-report-template2

<ビュー/レポートの編集>
レポートのデータ表示期間を変更するには、レポートのデータタイプで指定されたビューの日付範囲を変更します。その後、変更したビューに差し替えます。この場合、ビューもレポートもコピーを作成し、変更することをお勧めします。

■ビューの編集
edit-view

■レポートの編集
edit-report
edit-report2

◆レポートの出力◆
レポートのテンプレートを実行し、レポートを出力(ダウンロード)します。
download-report

下図は、日付範囲を変更したレポートをPDFで出力した結果です。「特定の日付範囲」で指定した8月~9月の過去データが表示されています。

display-report

◆カスタムレポートの作成②◆
新規レポートを作成します。前回のBlogで作成したカスタムビューを元にレポートを作成します。
下図は、前回のBlogで作成したカスタムビューです。
custom-view

<レポートの新規作成>
create-report
create-report2

◆まとめ
2つのカスタムレポートの作成方法をご紹介しました。ぜひ活用してみてください!
全体を通したお話となりますが、vROpsに慣れるまでは標準の機能(ダッシュボード/ビュー/レポート)を使用してみてください。vROpsを知る段階で、カスタム機能までを習得しようとすると、「やることがいっぱい」「カスタム機能は難しい」と思ってしまうようです。
まずは、「vROpsで何ができるの?」を知ることから始めてください。その後、カスタム機能を習得するのが理想的です。カスタム機能については、ぜひこちらのBlogをご活用いただけたらと思います。

次回は、vRealize Log Insightとの連携をご紹介します。

nakagawaソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方 が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。
インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!
voa

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2 appeared first on Japan Cloud Infrastructure Blog.

VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2

$
0
0

5回目:vRealize Log Insightとの連携

– Back Number –
#1…最新のV4Hが使いやすくなっている!
#2…ビューの活用方法①
#3…ビューの活用方法②
#4…レポートの活用方法
#5…vRealize Log Insightとの連携

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回はvRealize Operations ManagerとvRealize Log Insightを連携した活用法をご紹介します。

仮想化健康診断では、「ワークロード」と「ストレス」の値を参考に、分析してくださいとお話しています。「ワークロード」は現在の状態を、「ストレス」は過去6週間の平均値を表わしています。
下図の「ストレス」の結果から、木曜の16時から18時、19時から20時の間で負荷が高いことがわかります。たとえば、バックアップなど定時に高負荷な状態が起きる場合は、この画面から原因を推察することができます。しかし突発的な負荷が起きた場合は、原因を調査する必要があります。その際、Log Insightで収集されたイベントから何が起きたかを調査すれば、より早く原因を特定することができます。vROpsとLog Insightを連携することで、よりパワーアップできますね。
stress

このBlogでは、ネットワークの負荷を高めた状態を準備し、原因を特定するまでのプロセスを、連携の活用法としてご紹介します。
ネットワークの負荷を高める方法は、仮想マシン「Win7-01(192.168.250.202)」から、仮想マシン「Win7-02(192.168.250.200)」へPingコマンドを実行します。
Pingコマンドは、「-t:パケットの送受信を無限に繰り返す」と「-l:パケットのデータサイズ(バイト単位)を指定する」の2つのオプションを追加しています。今回は負荷を高めるため「-l 1000」を指定しました。-lのデフォルト値は32バイトです。
実行してしばらく経つと、「推奨」タブに、Win7-01でCPU使用量が高いためストレスが発生しているとアラートが表示されました。
alert

◆vROpsでの分析◆
ここから順に原因を特定していきます!
「Win7-01」の「分析」タブで詳細な状況を確認します。通常とは異なる状態であることを表わす「アノマリ」が高い値を示しています。
anomaly
どのリソースが高い値を引き起こしているかを、画面下部の詳細情報から確認します。
これらの情報から、「ネットワークリソース」に原因があることがわかります。
Detail
「詳細」タブの「仮想マシンのネットワークI/O診断」からは、14:40以降に受信/送信パケット数が上がっていることもわかります。
Detail2
ここで、あらためてネットワークのパフォーマンスについて確認します。

◆仮想ネットワークのパフォーマンス◆
仮想ネットワークは、「スループット」や「パケットドロップ」のメトリックを使用してパフォーマンスを監視します。特に「パケットドロップ」が発生しているかを確認することはパフォーマンス劣化の原因を特定する有効な方法です。
パケットドロップは、受信と送信でパフォーマンス劣化の原因が異なります。そのため対応方法もそれぞれ異なります。

<ドロップ送信パケット>
送信パケットは、ネットワークキャパシティが足りない場合に、仮想NICから仮想スイッチポートの順でキューイングされ、いずれもキューがあふれるとドロップされます。

<ドロップ受信パケット>
受信パケットは、準備できていない場合に、仮想NICから仮想スイッチポートの順でキューイングされ、いずれもキューがあふれるとドロップされます。

「準備できる」というのは、受信する仮想マシンで、仮想CPUに物理CPUが割り当てられた状態です。物理CPUが割り当てられなければ、受信処理を行うことができません。
仮想マシンのCPU使用率は、受信パケットのドロップ数にも影響を与えます。

◆Log Insightでイベントの検索◆
下図は、「IPアドレス」と「dropped」をキーワードに、仮想マシン「Win7-01」のLogを検索した結果です。木曜(12/8)の17時前後にドロップされているイベントがあります。vROpsの「ストレス」で確認した曜日と時間が一致しています。ドロップによるパフォーマンスが劣化していることは確定しました。
LI
参考までに、受信側の仮想マシン「Win7-02」の状況も確認してみます。
こちらの仮想マシンも、「アノマリ」で高い値を示しています。送信側の仮想マシン「Win7-01」と異なるのは、「CPU|準備完了」の値も上がっています。仮想CPUに物理CPUに割り当てられず、受信処理が行われていないことがわかります。
ネットワークのパフォーマンスが劣化している場合は、原因特定にCPUの状況も確認する必要がありますね。
Detail3

◆まとめ◆
Log Insightと連携することで、詳細な日時で何が起きたのかを確認することができます。
vROpsの「詳細」タブでは日時までは確認できますが、具体的に何が起きているかまでは調査するのは厳しいですね。
仮想化健康診断で、具体的な日時で何が起きているのでしょうかと聞かれます。連携すると、このご質問にも対応できますね。ぜひご活用いただきたいと思います。
計9回(パート1 x4回パート2 x5回)にわたり、vROpsの活用法をご紹介してきました。「このBlogで勉強しています」と声をかけていただくこともあり、嬉しいフィードバックでした。
今後も、様々な製品の活用法をご紹介していけたらと思います!

nakagawa
ソフトバンクC&SのサイトでvROpsを使用した仮想化健康診断の事例を紹介しています。ここでは、「vSphere環境を運用管理している方が何に困っているのか」「その困ったことにパートナーのみなさまがどのようにアプローチされているのか」を載せています。インタビュー形式で構成しています。ぜひお仕事に役立つ情報を手に入れてください!
voa

The post VMware vRealize Operations Manager (vROps) をパワーアップしよう! パート2 appeared first on Japan Cloud Infrastructure Blog.

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

$
0
0

1回目:仮想スイッチのお作法#1 (仮想スイッチの歴史とポートIDベースロードバランス)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2

こんにちは、ソフトバンク コマース&サービスの中川明美です。
今回は、あらためて「仮想スイッチ」について取りあげます!!
私は、2009年から2015年までVMware認定インストラクターとして、「VMware vSphere : Install, Configure, Manage (5日間)」等の公認コースを実施してきました。
インストラクターとして得た、「ここがポイントですよ!」を共有しながら、標準スイッチと分散スイッチの同じところ/異なるところをご紹介していきます。
第1回目は、仮想スイッチの歴史とロードバランスのポートIDベースについてご紹介します。

◆仮想スイッチの歴史
Version3.5の知識のままvSphereを管理運用されているエンドユーザー様にお会いすることがあります。たとえば、vSphere HAや仮想スイッチです。仮想スイッチの1つである標準スイッチは3.5から変更点はありませんから支障がないのかもしれません。
しかし「ESXiホストの管理台数が増える」「ハードウェアの進化を活用する」となると、新しい知識(機能)が必要になります。そしてベストプラクティスも変更されていきます。
私は、エンドユーザー様にアップデートされた機能に興味をもっていただきたい場合、歴史(機能の変遷)の話をします。ご存知の時点から順に歴史の話をすると、興味をもっていただける傾向があります。では、歴史のお話を!
仮想スイッチの歴史は、公認コースのテキストを使用します。
Versionが上がれば機能が増えます。機能が増えればコースのスライド内容が変わるのは当然と思うかもしれません。しかし比較してみると、機能だけではなく、「思い(ベストプラクティス)」も伝わってくる気がします。順次見ていきましょう。

◆Version 3.5
古くからVMware製品に携わっている方には、懐かしい「サービスコンソールポート」です。3.xまでは管理ネットワークの接続タイプが必要でした。この図では、1つの「標準スイッチ」に複数の接続タイプが構成されています。1Gbps物理NIC3つの構成では、パフォーマンスに支障が出そうですね。
接続タイプ:3種類のネットワーク接続

1

◆Version 4.0
4.0になって、用途によって仮想スイッチを分ける例が紹介されています。この時は、用途別に仮想スイッチを分けるのは一般的でしたね。課題はESXホストの物理NICの数でした。冗長化を考慮するなら、最低2倍の物理NICが必要です。

2

◆Version 4.1
4.1になると、冗長化を意識した、複数の物理NICが搭載された図になっています。1Gbps物理NICが主流の時のベストプラクティスが見えてきますね。上の構成図は、10Gbps物理NICを使用した分散スイッチに適していますね!

3

◆Version 5.5
スライドの構成は、4.1以降変更はありません。しかし、各役割のVMkernelポートが1つという構成は最近ありませんね。vMotionであれば帯域確保や、iSCSIであればパスを増やす必要があります。その場合、複数のVMkernelポートを構成します。

4

◆なぜVMkernelポートは複数必要?
なぜVMkernleポートが複数必要なのかを知る前に、NICチーミングの「ロードバランス」を復習します。ロードバランスは物理NICの選択方法です。デフォルト値はポートIDベースです。ここでは仮想マシンポートグループを使用して、ポートIDベース確認します。物理NICは、仮想NICが割り当てられた仮想スイッチのポートによって選択されます。たとえば、下図は、VM①の仮想NICはポート0に割り当てられています。ポート0に接続されたVM①の通信は物理NICのvmnic0を使用します。同様にVM②はvmnic1を、VM③はvmnic2を使用します。すべての物理NICが選択されたため、残りのVM④は再びvmnic0を使用して通信をします。この説明はあくまでもイメージです。ポートIDベースは名前の通り、仮想NICが割り当てられたポートをベースに物理NICを選択し、ロードバランスをします。シンプルな物理NICの選択方法ですね。デフォルト値であることは納得です!

5

次に、VMkernelポートはどうでしょうか?
下図は、vMotionの構成例です。この仮想スイッチには、vMotion用のVMkernelポート(vmk0)が1つ構成され、物理NICが2つ(vmnic0/vmnic1)割り当てられています。VMkernelポートはESXiホストが通信をするために必要なポートですから、IPを付与するだけなら、1つでも支障はなさそうです。ただし、デフォルトのロードバランス設定はポートIDベースですから、フェイルオーバーが起きなければvmnic1は使用されません。ポートIDベースは、仮想NICが割り当てられた仮想スイッチのポートによって物理NICが選ばれるから。。。でしたね。この構成で冗長性は満たしていますが、2つの物理NICを十分に活用しているとは言えません。

6

ではどのように構成するのがベストでしょうか。参考までに次のKBをご確認ください。

-vSphere における複数 NIC の vMotion-
https://kb.vmware.com/kb/2014840

VMkernelはデフォルトのポートIDベースを使用します。複数の物理NICを活用するには、活用できるように構成をする必要があります。下図のように物理NICが2つあれば、VMkernelも2つ作成し、それぞれにActive-Standbyの設定をします。この構成をすることによって、2つの物理NICを活用し、帯域を拡張することができます。パフォーマンスを上げられますね。

7

VMkernelポートは、vMotion以外の用途として、「管理ネットワーク」「iSCSI/NFS」「FT」がありますね。管理ネットワークは、vSphere HAハートビートに影響がありますから、私は念には念を入れてロードバランスの値として、「明示的なフェイルオーバー」の設定を行っています。iSCSIでは、ポートバインドの設定が必要な場合もあります。参考までに次のポートバインドのBlogをご確認ください。

http://ja.community.dell.com/techcenter/b/weblog/archive/2012/04/05/equallogic-vsphere-portbind

◆まとめ
ポートIDベースの物理NICの選択方法を知ると、特にVMkernelポートではNICチーミングが必要な構成であることをご理解いただけたと思います。ESXiホストが少ない場合は、複数の標準スイッチにポリシーを構成するのも煩雑ではないかもしれません。しかし、VDI環境など多くのESXiホストがある環境では、ポリシーを一元管理できる分散スイッチが注目されてきますね。
次回は、分散スイッチを活用するシチュエーションについてご紹介します。

8

nakagawa

The post 仮想スイッチのお作法~標準スイッチから分散スイッチへの道~ appeared first on Japan Cloud Infrastructure Blog.

仮想スイッチのお作法~標準スイッチから分散スイッチへの道~

$
0
0

2回目:仮想スイッチのお作法#2 (分散スイッチはいつ使用する?)

– Back Number –
#1…仮想スイッチのお作法#1
#2…仮想スイッチのお作法#2

こんにちは、ソフトバンク コマース&サービスの中川明美です。
前回、仮想スイッチの歴史とロードバランスの1つであるポートIDベースについてとりあげました。なぜポートIDベースについてとりあげたのか?
それは、なぜその設定が必要なのか、なぜその機能が追加されたのかを理解するためには、ポートIDベースを理解することが早道だからです。
現在、NICチーミングをデフォルト設定のまま構成することは少なくなりましたね。それらの設定を変更する際、状況に応じては、分散スイッチを選択する方が運用管理の煩雑さを避けることができます。今回は、あらためて分散スイッチのよさと、いつ使うのがよいのかをご紹介します。

◆標準スイッチと分散スイッチの違い
最初に、標準スイッチと分散スイッチの異なるところ/同じところを復習します。

<異なるところ>
異なるところは、ネットワークポリシーを管理する場所です。ネットワークポリシーには、「セキュリティ」「トラフィックシェーピング」「NICチーミング」があります。
「標準スイッチ」は各ESXiホストで作成しますが、ネットワークポリシーも各ESXiホストで管理します。

1

「分散スイッチ」は複数のESXiホストにまたがって作成され、ネットワークポリシーはvCenterサーバーで一元管理します。仮想マシンを複数のホスト間で移行する場合でも、仮想マシンに対して一貫したネットワーク構成を提供することができます。
ポリシーは各ESXiホストにプッシュインストールされます。vCenterサーバーとの通信が遮断されたとしても、ポリシーで設定した動作に支障がない仕組みを持っています。


2

<同じところ>
構成するコンポーネントの概念は同じです。先に、標準スイッチからコンポーネントの名前を確認します。


3

Port/Port Group
仮想NICが接続する仮想スイッチのポート(出入口)です。ポートには、「仮想マシンポートグループ」と「VMkernelポート」があります。仮想マシンポートグループは、名前の通り複数の仮想マシン用のポートです。

vmk#(0
から連番)
VMkernelポートに接続されている仮想NICには、「vmk#」という特別な名前が付けられます。ESXiホストが通信するために、vmk#にIPアドレスを付与します。

Uplink Port

物理NIC(Uplink)が接続する仮想スイッチのポート(出入口)です。

vmnic#(0から連番)
物理NICのことです。

Port/Port Group
の識別名:
左図では、MGMT/Production/vMotionが該当します。ネットワークポリシーの識別名でもあります。

次に分散スイッチです。


4

分散スイッチが標準スイッチと異なるのは次の2つです。

dvPort Group
分散スイッチのポートグループをdvPort Groupと呼びます。ポートは複数のESXiホストに分散配置されます。

dvUplink Ports
論理的な物理NICのポートです。論理的と表現したのは、複数のESXiホストの物理NICをグループ化し、1つのdvUplink Portに割り当てるからです。
分散スイッチでは、いくつの物理NICを割り当てるかを、「dvUplink Ports」の数として指定します。そして各dvUplink PortsにESXiホストの該当物理NICをアサインします。左図では、dvUplink Port 1に3台のESXiホストのvmnic2が割り当てられています。

※dvは「Distributed Virtual」の略

図3と図4の仮想マシンポートグループ「Production」に注目してください。
標準スイッチと分散スイッチを構成するPortとUplink Port(dvUplink Ports)は、同じ構成(図形)で描かれています。標準スイッチと分散スイッチは、単体のESXiホストで構成されるのか、複数のESXiホストにまたがって構成されるかだけの違いです!

本題に入ります!

◆vMotionを例にしたネットワークポリシー設定
前回のBlogで、下図のようにvMotion用にNICチーミングを構成することで、冗長化だけではなく、パフォーマンスの向上も期待できることをご紹介しました。それは2つの物理NICを活用できるからでしたね。

5

vMotionで必要な設定は次の通りです。

6

ESXiホストの台数が多くなると、なかなか煩雑な作業です。
たとえば、2つの物理NICを割り当てた標準スイッチで、vMotion用の設定を10台のESXiホストで構成するとなると・・・標準スイッチで、vMotion用のVMkernelポートを2つ作成し、各々でNICチーミングの設定をします。これを10回繰り返すことになります。
入力ミスや設定ミスが生じるかもしれません。分散スイッチであれば、ESXiホストが何台であろうと、ネットワークポリシーの設定は1回の作業で完了します。
管理するESXiホストの台数が多くなれば、分散スイッチに分がありますね。

◆分散スイッチはいつ使うの?
分散スイッチはいつ使うのがよいのでしょう。分散スイッチで提供される、「物理NIC負荷に基づいたルート」と「ネットワーク I/O コントロール」を例に説明します。

<物理NIC負荷に基づいたルート>
分散スイッチのみで提供しているロードバランスの方法(物理NICの選択方法)が、「物理NIC負荷に基づいたルート」です。
物理NIC負荷に基づいたルートは、ポートID と複数物理NICのアップリンク(物理NIC)数を取得し、仮想マシンのアップリンクの負荷を計算します。30 秒ごとにアップリンクを監視し、その負荷が使用量の75 パーセントを超えると、I/O の使用率が最も高い仮想マシンのポート ID を別のアップリンクへ移動します。名前の通り、負荷状況に応じて最適な物理NICを選択する方法です。
デフォルトのポートIDベースはポートによって物理NICが選択されるシンプルな方法ですから、アップリンクの負荷までは見ていません。
仮想マシンの台数が多い仮想デスクトップ環境の場合は、「物理NIC負荷に基づいたルート」を選択することをお勧めします。Horizon Bundleのライセンスでは、vSphere Desktop(vSphere Enterprise Plusと同等の機能) が含まれます。このライセンスであれば、分散スイッチを使用できますね!

<ネットワーク I/O コントロール>
CPUやメモリーのリソースコントロールと同様に、ネットワークリソースのコントロールができる機能です。設定値には、「シェア」「予約」「制限」があります。

7

最近注目されているHCI基盤を例に説明します。10Gbpsの物理NIC2枚構成の場合、図3のようなトラフィックごとの仮想スイッチを準備することができません。物理NICは仮想スイッチ間で共有できませんから、1つの仮想スイッチに複数のトラフィック(役割)を構成することになります。
ここで、パフォーマンスが気になりますね。分散スイッチであれば、トラフィックごとにネットワークリソースのコントロールが可能です。
デフォルトのネットワークリソースの割り当ては、すべて無制限です。帯域幅が飽和した場合に、ネットワーク I/O コントロールの「シェア値」を使用することで、帯域幅の割り当てをコントロールできます。管理者としては、より多くの仮想マシントラフィックに、より多くのiSCSIトラフィックに十分な帯域を割り当てたい、優先順位を付けたいと考えますよね。そのような場合に備え、ネットワークリソースのコントロールをご検討いただければと思います。

下図は、vSphere Web Clientのネットワークリソース割り当ての画面ショットです。


8

実際の設計/導入の場面では、下図のように1Gbps物理NICを接続した標準スイッチに管理ネットワークを、10Gbps物理NICを接続した分散スイッチにそれ以外のトラフィックを構成されることが多いと思います。下図は設計例の1つです。
この場合も複数のトラフィックを構成している分散スイッチは、ネットワーク I/O コントロールでのリソースコントロールをお勧めします!
1Gbpsと10Gbpsの混在環境では、「構成の上限(※)」にご注意ください。vSphere 6.5では、1Gbpsは4、10Gbpsは16です。

(※)vSphereの各バージョン毎に準備されているConfiguration maximum ガイドを参照下さい。
vSphere6.5のConfiguration maximum ガイドはこちら

9

◆まとめ
今回はあらためて仮想スイッチをとりあげました。分散スイッチは、Version 4.0から「vSphere Enterprise Plus」ライセンスで提供されています。上位ライセンスのため、標準スイッチと比べて、頻繁に導入する機会はなかったのではないかと思います。
しかし、この数年注目されつつある「VMware NSX」では、分散スイッチが前提となります。また、物理NICも10Gbpsが一般的になってきましたから、ネットワーク I/O コントロールの提案もしやすくなっている状況ではないでしょうか。
提案時のエンドユーザー様はコスト重視の傾向がありますが、導入後のトレーニングでは、「先に話してくれれば。。。」とよく言われました(笑)
費用がかかるからこそ、その効果を知っていただくために、事前の勉強会も必要なのでは?と特に感じています。その際にはこちらのBlogをテキストに勉強会を企画いただけたら嬉しく思います。

8

nakagawa

The post 仮想スイッチのお作法~標準スイッチから分散スイッチへの道~ appeared first on Japan Cloud Infrastructure Blog.

ちょっとした技術的な TIPs のご紹介

$
0
0

みなさん、こんにちは。VMwareでパートナー様を担当させて頂いてますSEの北村です。

今後、月に1回の頻度で VMware Blog (Cloud Infrastructure Blog と End-User Computing Blog) で、ちょっとした技術的なTIPs を投稿していこうと思っておりますので、お付き合いください。

今回は次の 2点をお伝えします。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
2. CPU の EVC 互換の確認方法

では、それぞれについて記載していきます。

1. vSphere (vCenter Server と ESXi) がサポート対象としている Active Directory の Domain Function Level について
みなさん、VMware の Knowledge Base サイト (kb.vmware.com) はご存知でしょうか? 弊社製品におけるトラブルシューティングやサポート関連の情報などを公開しているサイトになるので、是非、ご活用頂けると幸いです。

さて、以下の Knowledge Base (略して KB という言い方をします) は、vCenter Server と ESXi がサポート対象としている Active Directory の Domain Function Level について記載しているのですが、最近、この KB が更新され、昨年末にリリースされた、vSphere 6.5 の情報が追記されました。

Versions of Active Directory supported in vCenter Server (2071592)
Versions of Active Directory supported in VMware ESXi (2113023)

ここで、大事な事をお伝えしますが、vSphere 6.5 から Windows 2003 Domain Function Level がサポートから外れました (Windows Server 2003 の延長サポートが既に終了となっていますので、その結果が繁栄されていると思われます)。

Versions of Active Directory supported in vCenter Server (2071592) より抜粋 (詳細は KBをご参照ください):
KB2071592

Versions of Active Directory supported in VMware ESXi (2113023) より抜粋 (詳細は KBをご参照ください):
KB2113023

それに伴い、「以前のバージョンの vSphere」 と 「Windows 2003 Domain Function Level」 で利用している環境を、vSphere 6.5 へバージョンアップすると、動作の可否に関わらず、vSphere 6.5としてはサポート外の構成となってしまいますので、バージョンアップをご検討されている場合はこの点ご注意ください。

vSphere 6.5 へのアップグレードには以下のドキュメントを参考にして下さい。

1. ブラウザで、http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubs.html へ。
2. 「vSphere アップグレード ガイド」の PDF をクリック頂き、PDF版を参照するか、「vSphere 6.5 ドキュメント センター」リンクをクリック頂き、ブラウザの左側の「目次」で、「ESXi および vCenter Server 6.5 のドキュメント」→ 「vSphere のアップグレード」 の順で、クリック頂く事で、ブラウザ上で PDF 版と同じ内容を参照頂けます。

2. CPU の EVC 互換の確認方法
みなさんは、弊社の Compatibility Guide のサイトはご存知でしょうか? このサイトでは、弊社製品がサポートするハードウェア関連 (一部ソフトウェア) の情報を掲載しており、どのサーバ、どのCPU 、どのIOカード (NICやHBAなど) が弊社製品でサポートされているのかを確認頂く事ができます。

ちなみに、このページに掲載されている情報は、弊社が認定作業を実施していると思われがちですが、基本的には各ハードウェア・ベンダー様に認定作業を実施頂き、認定をパスしたハードウェアの情報を頂戴して弊社が掲載しています。

話を元に戻しますが、このサイトの1つとして、CPU Series というページがあります。ここでは、ESXi の各バージョンがサポート対象としている CPU や、Fault Tolerant 機能がサポート対象としている CPU、また、世代の異なる CPU 間での vMotion をサポートする為の機能、Enhanced vMotion Compatibility (EVC) を確認する事ができます。

特に、EVC は既存環境に新たに ESXi を追加する際に、既存サーバに搭載されている CPU と新たに追加するサーバに搭載されている CPU 間で vMotion、もしくは、DRS (DRSは仮想マシンの再配置を行う際に vMotion を利用しています) の互換性があるか、また、互換性を持たせる為に設定すべき EVC モードは何かを確認する事ができます。

例えば、既存環境では、① Intel Xeon E5-2690 を搭載しているサーバを使用していて、②その環境に新たに Intel Xeon E5-2690 v4 を搭載しているサーバを追加したいとします。かつ、①と②の間で vMotion または DRS を利用したいとします。

①の Intel Xeon E5-2690 は、Intel Xeon E5-2600 Series、②の Intel Xeon E5-2690 v4 は、Intel Xeon E5-2600-v4 Series になりますので、CPU Series のページで、それらを選択します。
HCL_EVC1

次に、”CPU / EVC Matrix” ボタンをクリックします。
HCL_EVC2

その結果 (上記) から、Intel Xeon E5-2690 (Intel Xeon E5-2600 Series) と Intel Xeon E5-2690 v4 (Intel Xeon E5-2600-v4 Series) の EVC モードが、Intel® Sandy-Bridge Generation である事がわかります。ちなみに、赤枠で囲まれた “Intel Xeon E5-2600 Series” や “Intel Xeon E5-2600-v4 Series” をクリックすると、それぞれの CPU のコードネーム (Code Name) を確認する事もできます。

どうでしょう、一見難しい様に思える異なる世代の CPU 間の EVC モードの確認が簡単に行える事をご理解頂けたと思います。

最後まで読んで頂きありがとうございます。今回は以上となります。またの機会をお楽しみに。

The post ちょっとした技術的な TIPs のご紹介 appeared first on Japan Cloud Infrastructure Blog.

Viewing all 972 articles
Browse latest View live