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

作成者別アーカイブ: Isao Kodama

vSAN の新しいカタチ ~ 2 Node vSAN を複数拠点にバラ撒いて集中管理をしましょう ~

みなさま、こんにちは!!アステック株式会社の中平(左)と坂本(右)です。

アステック株式会社は大阪に本社をかまえ、制御系システムソフトウェア開発を中心とした「ソフトウェア開発」部門と、IT インフラのネットワーク設計、セキュリティシステムの設定からハードウェア・ソフトウェアの販売・導入・保守メンテナンス等まで対応している「IT ソリューションビジネス」部門の二本柱を中心とした事業を行っております。

https://www.astec-corp.co.jp/

 

今回は世間で仮想化基盤のデファクトスタンダードとなっている HCI Powered by vSAN の新しい使い方 「複数拠点向け 2 ノード vSAN のバラ撒き構成」をご紹介します。

こちらの記事は日本製薬様というお客様へ実際に導入した実体験を基に、具体的な構成や構築のポイントなどをお伝えします。

※事例化の記事は以下のリンクを参照ください。

https://vmware-juku.jp/casestudy/nihon-pharm/

 

◆案件の概要

  • 各拠点で点在していた NAS および 物理サーバー を 2Node vSAN にリプレース
  • 拠点ごとに個別管理していたインフラを、中央の vCenter Server から集中管理
  • 各拠点の NAS ストレージは、2 Node vSAN 上に構築した Netapp Ontap Select へリプレース
  • バラ撒かれた2 Node vSAN 上の Netapp Ontap Select は 中央の Netapp ストレージとレプリケーションすることで データの DR も実現

 

1.   複数拠点向け 2 Node vSAN  構成とは?

2 Node vSAN といえば小規模の環境でサーバーとストレージを統合するためのソリューションと思われがちかもしれませんが、実は複数拠点を展開している企業での利用も最適です。

 

複数拠点をお持ちのお客様で拠点ごとにストレージや NAS を配置しているパターンは結構ありませんか?

その使い方だと拠点ごとの個別管理で運用負荷が増えていく原因にもなります。

そこで 2 Node vSAN を各拠点にバラ撒いて運用をすると、中央から集中管理が可能になり、運用の効率化と負荷軽減を実現することが可能です。

 

2.    導入構成の Before / After の紹介

2 Node vSAN を各拠点にバラ撒いて、本社やデータセンターに配置した vCenter Server から集中管理するときのネットワーク構成の詳細が書かれた資料は少ないと思いますのでここでは実際の構成をもとに紹介したいと思います。

 

導入前の構成

以前の構成は各拠点に物理サーバー1台とファイルサーバー用の NAS を配置して、本社に配置した NAS ストレージとデータミラーリングを行っていました。

各拠点は単体の物理サーバーで運用していますので冗長化はされていませんでした。

 

導入後の構成

以下が 2 Node vSAN を各拠点に展開したときのネットワーク構成になります。

2 Node vSAN を採用することで、以下のメリットを各拠点に提供できるようになっています。

・拠点のサーバーとストレージ管理をデータセンター側から集中管理できる

・仮想化により vSphere HA による冗長化ができる

・拠点で H/W を新規購入することなくサーバーを構築できる

また、拠点の vSAN ノードの管理インターフェースから Witness 通信をさせるように設定をするという点と、必要に応じてデータセンター側の vSAN Witness アプライアンス と通信ができるようにStatic Route を設定することを忘れないでください。

[ESXi ホストの Witness 通信設定変更コマンド]

例) esxcli vsan network ip add -i vmk1 -T=witness
https://storagehub.vmware.com/t/vmware-vsan/vsan-2-node-guide/vmkernel-interfaces-witness-traffic/

[ESXi ホストの Static Route 設定コマンド]

例) esxcfg-route -a 192.168.100.0/24 192.168.0.1
https://kb.vmware.com/s/article/2001426?lang=ja

 

3.    vSAN バラマキ構成でメリットの出し方

今回の導入でどのようにしてメリットを出したのかをポイントをわけてご紹介します。

3-1.  各拠点の個別管理から集中管理へ移行したいなら vSAN バラマキ構成がベスト

vSAN のばら撒き構成のメリットにはサーバーとストレージの集中管理ができる点にあります。

以下の図は vCenter Serverのログイン画面です。

1つの画面上で全拠点の仮想サーバーの管理はもちろんのこと、ストレージの状況や管理まで行えるため、各拠点に IT 要員を配備しなくても運用ができるようになります。

 

3-2.  拠点で物理サーバーを運用しているなら 2 Node vSAN への移行がベスト

今回のケースではもともと拠点側では NAS と物理サーバーで運用している環境でした。

「2章 導入構成の Before / After の紹介」にあるように、リプレース前の構成では拠点内のサーバーは冗長構成が取られていません。

この環境で仮想環境へ移行するために、サーバーとストレージの新規購入をすると大幅な費用追加を求められます。

こういった環境では 2 Node vSAN にすることで、実際にかかるハードウェアコストを70%まで削減することができました。

以下の画像の赤枠で囲った部分のコストを下げることができます。

もし拠点で物理サーバーを運用している方で、今後仮想環境に変えたいと考えている場合は、3 Tier ストレージ構成ではなく 2 Node vSAN での構成を検討ください。

コスト面 + 運用負荷 + 利便性 などの様々な面でメリットを感じられるはずです。

 

 

3-3.  コストメリットを出すなら vSAN ノードを手組みで構成するのがベスト

vSAN は アプライアンス型、Ready Node 構成 、DIY (手組み構成)がありますが、様々な要望に応えつつ コストメリットを出すなら Ready Node 構成と手組み構成の組み合わせベストです。

具体的な構成方法は VMware が提供している vSAN ハンズオンの中で紹介していますので興味ある方はご参加ください。

※以下のリンクから vSAN ハンズオン資料を取得できます。資料中でもやり方を記載しています。

https://vmware.my.salesforce.com/sfc/p/400000009hQR/a/34000000U33i/VXl.gqTrh8UplMS_8h8le96cN61WQgpj9.Ox10UiW0w

 

今回の案件で採用した構成は最適なコストパフォーマンスを出すために、Ready Node 構成と DIY 構成を組み合わせています。

これは各ハードウェアメーカーが検証することで動作確認が取れている Ready Node 構成を、要件に応じて一部のパーツだけを認定の取れているパーツへ変更するという部分的な手組み構成を組み合わせています。

 

この組み合わせによるメリットはハードウェアの大半が検証済みの構成を採用できるので安定的な稼働を受けられると共に、CPU / Memory / ディスクサイズ(キャッシュ、キャパシティ)などを要件に合わせて柔軟に変えられることで、パフォーマンスとコストメリットの両立を実現できることです。

 

今回の構成では、2 Node vSAN 上に Netapp Ontap Select を実装して、ファイルサーバーとして利用しています。

課題はファイルサーバーを動かすためのディスク容量が必要になるという点はもちろんのこと、快適に利用するためにキャッシュも大容量であることが求められます。

そこで今回の案件では Ready Node 構成に対して以下のような変更をすることで仮想基盤 & ファイルサーバー基盤の両方の要件を満たせる構成を実現しました。

今回のポイントは廉価で高速かつ大容量の SSD をキャッシュに採用して、高速な仮想ストレージを実現するところにあります。

Hybrid 構成の vSAN を採用したため Read Cache が70% 、Write Cache が 30% となります。

今回は1ノードあたり 1.92TB SSD を使用しますので以下の容量になります。

Read Cache のサイズ  ⇨  1.92TB * 0.7 (Read Cache 割合) = 1.34TB

Write Cache のサイズ ⇨  1.92TB – 1.34TB (Read Cache サイズ) = 580GB

これだけの容量があれば仮想基盤とファイルサーバーを共存しても安心ですね!!

※キャッシュ構成の情報は以下の VMware ブログを参照ください。

https://blogs.vmware.com/jp-cim/2016/04/vsan_04.html

 

そして、性能指標でも Read IOPSが57,000 で Write IOPS が27,000 ということで、十分に収容可能であることが確認できます。

https://www.hpe.com/au/en/product-catalog/servers/server-solid-state-drives/pip.specifications.hpe-1dot92tb-sata-6g-read-intensive-sff-2dot5in-sc-3yr-wty-digitally-signed-firmware-ssd.1010129362.html

もし vSAN 導入時のコストでお悩みの際は、手組みの vSAN でコストの最適化を検討してみてください。

 

4.    構築時のポイント

最後に 2 Node vSAN ばら撒き構成を構築する際のポイントをいくつかご紹介します。

 

・2 Node vSAN クラスタ 1つに対して、vSAN Witness アプライアンスが1つ必要です。今回の構成は 3拠点に vSAN ノードをバラ撒いていますので、データセンターに Witness アプライアンスを3台展開しています。

 

・拠点内の vSAN ノード を10G NIC 直結で構成する場合は、Witness アプライアンスに疎通可能なインターフェースに、vSAN Witness 通信のタグをつけるようにしてください。

※詳細な構成は世界で70名ほどしかいない vExpert-vSAN の一人である「Captain 大塚」ことSBC&S 大塚正之さんのブログも参照してみてください。

https://vm-fun.blogspot.com/2019/04/2-node-vsan.html

 

・2 Node vSAN の障害時の挙動を知りたいという方向けに良いブログを見つけました。

vExpert-vSAN の一人である SBC&S 稲葉直之さんのブログで障害時の挙動がサマリにされており、とても見やすいのでそちらを抜粋しつつ紹介します。

https://www.dell.com/support/article/jp/ja/jpdhs1/sln313110/

今回のブログでは 2 Node vSAN の構成や導入に関する情報を書かせていただきました。

お役に立つ情報がまたありましたらこちらでご紹介させていただきますのでご期待ください。

第3回 シュナイダー (APC) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~2 Node vSAN 対応とよくある QA編~

第3回 シュナイダー (APC) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~2 Node vSAN 対応とよくある QA編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

 

◆はじめに

 

いつもシュナイダーUPS & vSAN 連携ブログを閲覧いただきありがとうございます。

シュナイダー エレクトリック 出口と冨田です。

前回のブログでは 広島の田中電機工業社 村上さんと中野さんに自社導入実績をもとに、機器構成と消費電力量の計算方法をご紹介いただきました。

今回のブログでは多くの方からご相談を頂いていた 「2 Node vSAN での対応状況」と「サポートされる構成」、「2 Node vSAN でよくあるQA」を紹介していきます。

 

 

1.そもそも 2 Node vSAN とは?

通常の vSAN は 3台以上の vSAN ノードを用意して vSAN クラスタを構成しますが、2 Node vSANは 2台の vSAN ノードと1台の管理用ノードで実現できる最小構成の HCI です。

管理用ノードには  Witness Appliance という vSAN ノードのマスターを判定する機能を持った仮想アプライアンスと vCenter Server をデプロイします。

構成イメージは下記の図を参照ください。

 

2.2 Node vSAN でサポートされる構成

2019年6月5日 現在、 PowerChute Network Shutdown (以下略 PCNS)は バージョン4.3になり、2 Node vSAN にも対応しています。

今回紹介する構成はよくある2パターンの構成で、1つ目は2 Node vSAN システム外部の 物理Windows サーバーにPCNSをインストールするパターン。

2つ目は2 Node vSAN システム内部の Witness アプライアンスを実装した管理ノードに仮想アプライアンスとして提供されている PCNS 仮想アプライアンスをデプロイするパターンをご紹介します。

 

◆2 Node vSAN の構成におけるポイント

PCNSを外部の物理Windowsサーバーにインストールして管理する方法とESXiホストに仮想アプライアンスとしてデプロイして管理する方法がありますが、仮想アプライアンスの場合はvSANクラスタ外の管理ノードにデプロイします。
いずれの構成もUPSが電源障害を検知すると、PCNSはvSANクラスタと管理ノードのすべてのESXiホストを安全にシャットダウンします。

※こちらで紹介する構成は UPS がシングル構成、冗長構成どちらでもサポート対象となります。

 

パターン1. 外部 の物理 Windows サーバーに PCNS をインストールする構成

 

パターン2. vSAN 管理用ノードに 仮想アプライアンス版 PCNS をデプロイ

※パターン2の構成で、電源復旧後にvSANシステムを自動起動する場合には、管理ノード上にデプロイした PCNS と Witness Appliance を ESXi の機能を用いて自動起動するように設定してください。(設定方法については下記リンクを参照)

https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-5FE08AC7-4486-438E-AF88-80D6C7928810.html

 

これで2 Node でも 3 Node以上でも、安心して vSAN を導入できますね (^^♪

 

3.2 Node vSAN 構成の Tips 集

◆vSAN 用ネットワークの構成について

vSAN ネットワーク用の NIC は 10G ネットワークで構成してください。

2 Node vSAN に限り、10G NIC 直結でも、スイッチ経由でも構成可能です。

 

◆ネットワークの組み方について

vSAN のよくある質問でネットワークの組み方について聞かれることが多いと思います。

このネットワーク部分で、世界で70名ほどしかいない vExpert-vSAN の一人である「Captain大塚」こと SB C&S 大塚正之さんのBlogに良い記事がありましたので引用させていただきました。

https://vm-fun.blogspot.com/2019/04/2-node-vsan.html

大塚さん ありがとうございます m(_ _)m
https://twitter.com/masotsuka

 

・LAN内で Witness アプライアンスに2つのIPアドレスを設定しないで構成する場合

 

・ROBO構成などのように、Witness アプライアンスに2つのIPアドレスを設定して構成する場合

 

4.参考リンク

PCNS v4.2 の2 Node vSAN 対応について

https://www.se.com/jp/ja/faqs/FA350086

 

以上で3回続けてきたシュナイダーUPS & VMware vSAN ブログも今回で最後となります。

 

これからも皆様の HCI 環境を快適に動かすための情報があれば情報展開していきますのでこれからも シュナイダー社とVMware社に乞うご期待ください!!

 

第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!

第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~電力消費量計算編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

◆はじめに

はじめまして! 田中電機工業株式会社 中野 (左) と 村上 (右) です。

田中電機工業は広島でシステム・ネットワーク構築、アプリケーション開発をはじめ、コンサルティングから設計、構築、運用、保守まで、システム全般のサポートを行っております。

http://www.tanaka-elec.co.jp

 

前回のシュナイダーエレクトリック 出口さんの続きとして、VMware vSANとシュナイダー UPSを自社の本番環境に導入した実績を基に、「構成と製品選定のコツ」、「バッテリー稼働時の耐久時間」「シャットダウン時の動き」をご紹介していきます。

 

1.構成と製品選定のコツ

2018年10月現在で、我々の会社では3ノードの vSAN 上で約50台のVMが稼働しています。

 

👉 vSAN を構成しているハードウェアはこちら

👉 vSAN と UPS の構成図

vSAN と UPS の物理接続構成はこの様になっています。

もし導入構成で迷われている方がいましたら、ぜひ参考にしてください!!

 

では具体的にUPS製品の選び方を見ていきましょう!

 

シュナイダー社が提供している UPS 製品のラインナップは以下の様に豊富に提供されていますが、HCI 環境で使う場合には赤字でマークしてある製品を検討いただくことが多くなるかと思います。 (2018年1月現在のラインナップ)

 

お気づきの方もいるかも知れませんが、製品名に書かれている「2200」「3000」という数字は UPS の保持電力量になります。

vSAN 環境で UPS を使う場合は複数のノードの扱うことになりますので、上の表でマークしたような、ある程度の電源容量がある型番が選ばれることが多くなりそうですね。

 

 

2.電源容量とUPS稼働時間の計算方法

では、いよいよ UPS を選んでいくにあたって 皆様が気にされていると思われる電源容量と稼働時間の算出方法を見ていきたいと思います。

稼働時間を算出するには、以下のポイントを確認いただければ簡単に算出していくことが可能です。

  • UPS の電源容量

    👉こちらは先程お見せしたリストのように、UPS型番をみれば電源容量は一目瞭然ですね (^^♪

  • 接続するサーバーの合計消費電力

    👉 弊社で導入したvSAN基盤は Lenovo 社のサーバーを使っていますので、こちらのサイトから詳細に電力を算出しました。
    http://dcsc.lenovo.com/


最大電力消費量は3ノードで1983.6 W。

運用中の負荷が70%  程度の使用率と考えた場合の消費量は以下になります。

「皮相電力」 ・・・ 2009.7 VA × 70% = 1406.79 VA
「消費電力」 ・・・ 1983.6 W × 70% = 1388.52 W

 

2台冗長構成で実装しており、3台の電源消費量を2台で分散して処理しますので、UPS 1台あたりの消費量は以下のとおりです。

「皮相電力」 ・・・  1406.79 VA ÷ 2 = 703.395 VA
「消費電力」 ・・・  1388.52 W ÷ 2 = 694.26 W

使っている UPS 型番と機器の消費電力が算出できたら、シュナイダー社の以下ドキュメントに記載されている各 UPS 毎のバックアップ時間表を確認することで、簡単に計算をすることができます。
http://catalog.clubapc.jp/pdf/ups/small-ups_1510.pdf

※P23 を参照。以下に抜粋

今回の使用している UPS は一番右の SMT3000RMJ2 です。

先程算出した皮相電力と消費電力が当てはまる部分を赤枠で囲ってみました。

ということで、今回の構成ではバッテリー稼働時に20分間は問題なく稼働できるということが確認できました。

 

 

3.UPS稼働時のシャットダウン動作と電源復旧時の起動方法

最後に望まないことではありますが、もし実際に電源障害が発生してしまい、UPSで vSAN を安全にシャットダウンしなければならない状況が発生した場合に、「どのような流れでシャットダウンが行われているか?」と「電源復旧時のシステム起動方法」を実際に運用した際の勘所を交えてお伝えします。

 

[シャットダウンフローはこちら]

 

[電源を復旧させる場合のフロー]

・vSAN ノードと vCenter Server が異なるホスト上にある場合

今回はこちらの流れになります。

1.UPSの通電を開始
2.vCenter Server の起動
3.ESXiホストの起動
4.ESXi ホストのメンテナンスモードを終了
5.各仮想マシンを起動

※2番でESXiホストよりも先にvCenter Server を起動していますが、Virtual Appliance 版のvCenter ServerをvSANノード上に配置している場合は、次にご紹介するフローで起動可能です。

 

・vSANノード上にvCenter Serverが配置してある場合

1.UPSの通電を開始
2.ESXi ホストの起動
3.ESXi ホストのメンテナンスモードを終了
4.vCenter Server の起動
5.各仮想マシンを起動

vSANの機能はESXiホストが実装している機能なので、vCenter Serverが起動していなくても
vSANデータストアは使用できるのです  ε-(´∀`*)ホッ

 

最後に実装と運用する際の勘所をサマリにまとめました。

・vSAN をメンテナンスモードに移行していく際に、一度に全てのホストがメンテナンスモードには移行するのではなく、1台ずつ順番にメンテナンスモードに移行します。

・PowerChute Network Shutdownでコマンド実行を行う場合、サービスを起動するユーザで実行します。うまくいかない場合は、管理者権限のあるユーザに変更する必要があります。

・ホストをメンテナンスモードに移行させるためにSSH接続を使用しますが、初回にセキュリティ警告が表示されますので、unknown_hostsリストに該当のESXiホストサーバを追加する必要があります。

実装するスクリプトや、詳細な情報については以下のURLが参考になりましたのでご覧ください。

 

https://www.schneider-electric.co.jp/ja/faqs/FA329212/

 

 

4.さいごに

 

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

HCI を導入する際に vSAN を採用すれば、今まで vSphere で蓄えた知識を基に、簡単にUPSを導入できることがイメージしていただけたのではないかと思います。

弊社では検証環境用に 2 ノード vSAN も導入しています。
社内で身につけた 2 ノード vSAN 構築、運用、3rd パーティ製品連携の勘所なども、いずれご紹介したいと思いますのでご期待ください!!

PS : 広島へお越しの際は、お土産に平安堂梅坪にも寄ってみてください。
特にバターケーキが村上のオススメです。

 

平安堂梅坪

※株式会社平安堂梅坪は、田中電機工業の子会社になりました。

第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!

第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!! ~導入構成編~

 

#第1回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~導入構成編~

 

#第2回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~電力消費量計算編~

 

#第3回 シュナイダー ( APC ) UPS と VMware vSAN はシャットダウン連携ができるんです!!
~2 Node vSAN 対応とよくある QA編~

 

◆はじめに

 

はじめして! シュナイダー エレクトリック APC UPS 管理製品担当 出口 (右) & 冨田 (左) です。

最近 IT業界全体で注目度の高い ハイパーコンバージドインフラ ( 略して HCI ) の代表的な製品 VMware vSAN と弊社 UPS 管理製品 PowerChute がシャットダウン連携できるようになりました。

 

vSAN を導入することで運用負荷やコストを下げられるというメリットを感じて導入を検討される方も多いとは思いますが、やはり 電源障害や停電対応にも対応した UPS がないと不安で導入できないという方もいらっしゃると思います。

 

ご安心ください!!既に連携ができます!! 

 

今回のブログでは、どのような構成がサポートされて、どのような仕組みで VMware vSAN & シュナイダー ( APC ) UPS 連携ができるのかをご紹介いたします!!

 

1.UPS と vSAN のシャットダウン連携のサポート構成

APC UPS では 以下に挙げる構成パターンで vSAN との連携が可能です。

 

[パターン1]

物理 Windows サーバー にPowerChute Network Shutdown ( 略 PCNS )と、Windows 版 vCenter Server をインストールするパターン

この構成は、Windows 版 vCenter Server に PCNS や他の管理系ソフトウェア(バックアップ、監視など)を同居させる場合にピッタリの構成パターンとなっています。

 

[パターン2]

vSAN クラスタ上に vCenter Server Virtual Appliance ( 略 VCSA ) をデプロイして、PCNS は物理 Windows サーバー にインストールするパターン

 

この構成では VCSA を vSAN クラスタ上に構成するシンプルなパターンで、Dell EMC 社 の VxRail に代表される vSAN を基盤とした HCI アプライアンスを導入される方にピッタリの構成パターンとなっています。

 

[パターン3]

vSAN クラスタとは異なる ESXi サーバー上に VCSA をデプロイして、PCNS は物理 Windows サーバー にインストールするパターン

 

この構成では VCSA を vSAN クラスタ上に配置しないで構成します。vCenter Server のような管理系のサーバーを vSAN クラスタとは異なる環境で構成したい方や、複数のシステムをやクラスタを vCenter Serverで統合管理されている方にピッタリの構成パターンとなっています。

 

これだけのパターンが網羅されていればどんな環境でも安心して vSAN を導入できますね (^^♪

2.vSAN 連携させるために必要なもの

各パターンごとにおける 必要なコンポーネントと機器サンプルは以下の通りです。
詳細な電源容量の計算などは次回のブログでご紹介します!!

[構成パターン1および2で必要なコンポーネント]

Smart-UPS 1500 RM 2U LCD (SMT1500RMJ2U)   ・・・・・・・・・・・・ 1

Network Management Card (AP9630J)    ・・・・・・・・・・・・・・・・ 1

Powerchute Network Shutdown for Virtualization (SSPCNSV1J)   ・・・・・  4

 

[構成パターン3で必要なコンポーネント]

Smart-UPS X 3000 Rack/Tower LCD (SMX3000RMJ2U) ・・・・・・・・・  1

Network Management Card (AP9630J) ・・・・・・・・・・・・・・・・  1

Powerchute Network Shutdown for Virtualization (SSPCNSV1J) ・・・・・  5

 

3.vSAN 連携時のシャットダウンシーケンス

シャットダウン時の流れは以下の様になります。

 

4.参考リンク

すでに vSAN を導入されている方も、これから導入を考えている方もぜひ、電源管理は シュナイダー UPS にお任せください!!

次回のブログでは「電源容量と耐久時間」や「製品の選び方のポイント」についてご紹介いたします。

では次回を乞うご期待ください!!

 

[vSAN & シュナイダー UPS 連携のKB (シュナイダー社リンクへ飛びます)]

PowerChute Network Shutdown の vSAN対応について

アプリケーションノート:PowerChute Network Shutdown for VMware

ここが変わった! VMware vSphere 6.5 Part4

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vSphere 6.5で使用可能な3つの管理ツールについてご紹介します。

vSphere 6.5から、「VMware Host Client (HTML5 バージョン)」と「vSphere Client (HTML5 バージョン)」が新たに提供され、「vSphere Web Client (Flex/Flash バージョン)」はパフォーマンスと操作性が改良されています。

WindowsアプリケーションのvSphere Clientは、vSphere 6.5から使用不可となりました。

https://blogs.vmware.com/vsphere/2016/05/goodbye-vsphere-client-for-windows-c-hello-html5.html

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆3つの管理ツール◆

vSphere 6.5で使用可能な3つの管理ツールの違いを確認します。

vSphere 6.5からは、ESXiホストを管理するために「VMware Host Client (HTML5バージョン)」を、vSphere基盤を管理するために「vSphere Web Client (Flex/Flash バージョン)」および「vSphere Client (HTML5 バージョン)」を使用します。

 

◆VMware Host Client (HTML5バージョン)◆

VMware Host ClientはvSphere Web Clientと類似したユーザーインターフェイスです。慣れた画面構成で、初めて使う方でも操作に迷うことはほとんどないと思われます。

また、1台のESXiホストを管理するツールのため、vCenter Serverで提供される機能は表示されません。特別な設定も必要とせず、サポートされるWebブラウザを準備するのみです。

次のアドレスを使用して、Host Clientへ接続します。

https://ESXiホストのFQDNまたはIPアドレス/ui

 

Host Clientは、vSphere 6.0 Update 2 以降から使用可能です。vSphere 6.0を運用管理されているユーザーの方もぜひ試用してみてください。

私個人としては、HTMLベースのHost Clientは、ダウンロード等の事前準備が必要ないこと、vSphereバージョンごとの導入が必要ないことをメリットと感じます。

 

 

◆vSphere Client (HTML5バージョン)◆

vSphere Clientは、HTMLベースのため、Adobe Flash Playerのインストール(Adobe Flexの有効)は必要ありません。Host Client同様、対応のWebブラウザがあれば使用可能です。

次のアドレスを使用して、vSphere Client (HTML5)へ接続します。

https://vCenter ServerのFQDNまたはIPアドレス/ui

 

vSphere Client (HTML5)は未サポートの機能もあります。vSphere 6.5 Update 1から標準的な機能が追加されています。

<vSphere 6.5 Update 1の未サポート/サポート機能>

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-client-65-html5-functionality-support.html

 

先日vRealize Operations Managerのトレーニングテキストを作成するために、テスト環境を構築しました。その環境では、Adobe Flash Playerのインストールができなかったため、vSphere Client (HTML5) の使用を試みました。標準的な機能を使用するのであれば十分ですね。全機能の移行が待たれます。

 

 

◆vSphere Web Client (Flex/Flash バージョン)◆

vSphere 6.5から、vSphere Web Clientがすべての機能やプラグインを提供する管理ツールとなります。

Web Clientは、Adobe Flash Player 16以降のインストール、およびサポートされるWebブラウザを準備する必要があります。

次のアドレスを使用して、vSphere Clientへ接続します。

https://vCenter ServerのFQDNまたはIPアドレス/ vsphere–client

 

vSphere 6.5のWeb Clientの改善点をいくつか挙げます。

 

1.ユーザーインターフェイス

vSphere 6.5では、「はじめに」「監視」「構成」のタブで構成されています。以前の「管理」から「構成」へタブが変更されています。vCenter Serverのwebclient.propertiesを編集し、「管理」タブへ戻すことも可能です。

Web Client 6.5では、WindowsアプリケーションのvSphere Clientに近いメニュー構成に変更されています。以前と比べ階層が1つ減り、操作性が改良されています。

 

<Web Client 6.0>

<Web Client 6.5> ※下図は、vSphere 6.5 Update 1の画面ショットです

2.クライアント統合プラグイン

vSphere 6.0以前のバージョンでは、次の機能を実行するために、クライアント統合プラグインが必要でした。6.5では不要です。小さな改良ですが、嬉しい改良点ですね。

  • OVFファイルのインポート/エクスポート
  • データストア内のファイルのアプロード/ダウンロード

 

3.拡張認証プラグイン

拡張認証プラグインは、vSphere 6.0以前のクライアント統合プラグインの後継機能です。

拡張認証プラグインは、統合 Windows 認証と Windows ベースのスマート カード機能を提供します。この2つの機能のみが、以前のクライアント統合プラグインから引き継がれます。

以前のクライアント統合プラグインとvSphere 6.5の拡張プラグインの間で競合は発生しません。

 

4.その他のプラグイン

VMware Site Recovery Manager (SRM) プラグインはバージョン 5.8からWeb Clientへ完全に移行します。

参考までに、VMware Update Manager (VUM) プラグインは、vSphere 6.0 Update 1からWeb Clientで使用可能です。

 

 

◆vSphere Client (HTML5)の情報◆

vSphere Client (HTML5) と vSphere Web Client 6.5 の FAQ

<英語版>

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147929

<日本語版>

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2148759

 

vSphere Client (HTML5)で使用可能な機能の最新情報はこちらでご確認ください。

https://labs.vmware.com/flings/vsphere-html5-web-client#changelog

 

 

◆まとめ◆

VMware Infrastructure 3.5からのユーザーである私には、使い慣れたツールであるWindows アプリケーションのvSphere Clientが廃止されるのは少々寂しい気持ちになります。しかし快適な使用環境へ移行しているのですから、喜ばしいことです。

vSphere 5.1からの新機能はWeb Clientから提供され、vSphere 6.5でvSphere ClientからWeb Clientへ完全に移行されました。また先に述べたように、Web Client 6.5ではメニュー構成も改良されています。覚えたメニューの配置が変わるのは、慣れるまで時間を要しますが、よりよい変更のためですからね!

次回はvSphere HAです。vSphere HAはvSphere 5.0で大きくアーキテクチャーを変更し、その後も小さな改良が見られます。私個人はバージョンが上がるたびにVMware社がvSphere HAの改善を追求していると感じます。vSphere HAは運用において重要な機能ですからね。次回も参考にしていただければ幸いです。

 

ここが変わった! VMware vSphere 6.5 Part3

日本ヒューレット・パッカード株式会社の中川明美です。

今回は、vCenter ServerやESXiホストをアップグレードする際に、アップグレードの可否が検討される「仮想ハードウェア」と「VMware Tools」についてご紹介します。

現在設定されているバージョンが仮想マシンの継続稼働に問題があるのか、最新バージョンにアップグレードしたらどんなメリットがあるのかを知っておくことは、大事なポイントであると思います。

また、仮想ハードウェアのアップグレード時には仮想マシンを再起動するダウンタイムが発生します。「いつ」「誰が」実施するのかも考慮する必要がありますね。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

◆仮想ハードウェアバージョン13◆

vSphere 6.5で提供される最新の仮想ハードウェアバージョンは、「13」です。

下表は、「13」から提供される機能です。これらの機能は、「仮想マシンに ESXi 6.5 以降との互換性(仮想ハードウェアバージョン13)が設定されている」こと、「サポートするゲスト OS が仮想マシンにインストールされている」ことが前提です。

※仮想ハードウェアはESXiホストで使用できる物理ハードウェアに対応します。仮想ハードウェアバージョン13では最大6TBのメモリをサポートします。しかしESXiホストに6TBの物理メモリが搭載されていなければ、仮想マシンに割り当てることはできません。

仮想ハードウェアもアップグレードしなければならないの?

たとえば下図のように、vCenter Server 5.5をvCenter Server 6.5へ、vSphere ESXi 5.5の一部をvSphere ESXi 6.5へアップグレードした例を使い、仮想ハードウェアバージョンのアップグレード可否について確認します。ここではあえてこの構成にしています。

 

 

アップグレードしない場合 (仮想マシンの互換性を変更しない)

構成例ではESXiホストのバージョンが5.5と6.5の混在環境のため、仮想マシンの互換性は古いESXiホストとの互換性を維持するために、「ESXi 5.5以降以降 (ハードウェアバージョン 10)」を選択します。言い換えると、仮想マシンの互換性は変更せず、仮想マシンの稼働を継続します。

仮想マシンの互換性を「ESXi 6.5以降」に変更すると、その仮想マシンをESXi 5.5または6.0  ホスト上で実行することができません。たとえば、仮想マシンの互換性が「ESXi 6.5以降」である仮想マシンを、ESXi 5.5ホストへ移行することができません。

また、すべてのESXiホストが6.5であったとしても、最新の仮想ハードウェア機能を使用しないのであれば、必ずしも最新の仮想ハードウェアバージョンを選択する必要はありません。

私はESX 4.0 ホスト上で作成した仮想マシンをovfファイルにエクスポートし、新しいバージョンのESXi ホスト上で継続的に使用したことがあります。これは互換性により可能となります。

vSphere ESXi 6.5では、仮想マシンの互換性に、「ESX/ESXi 4.0 以降 (ハードウェアバージョン 7) 」を選択できます。これは仮想ハードウェアバージョン 7以降の仮想マシンを、ESXi 6.5ホスト上に配置できることも意味します。

VMware製品、ストレージやネットワークベンダーから提供されるovfファイル (仮想アプライアンス) は、互換性を考慮し「ESXi 5.0以降 (ハードウェアバージョン 8) 」で提供されているのを見かけますね。

 

アップグレードする場合 (仮想マシンの互換性を最新の「ESXi 6.5以降」に変更する)

6.5で提供される最新の仮想ハードウェア機能を使用したい場合は、すべてのESXiホストを6.5で構成し、仮想マシンの互換性に「ESXi 6.5以降」を選択します。

 

仮想マシンの互換性のデフォルト値

ESXi 6.5ホスト上で新規に作成する仮想マシンの互換性は「ESXi 6.5以降」が選択されます。

互換性のデフォルト値は仮想マシンを作成する ESXi ホストのバージョンによって決まります。デフォルトの互換性の設定値をESXiホストのバージョンとは異なる値にしたい場合には、こちらを参照ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.vm_admin.doc/GUID-FD9DC4FF-4420-4FCA-AEF4-6E19AFF869F5.html

 

 

◆VMware Tools バージョン10.1.x◆

vSphere 6.5 に付属している VMware Tools のバージョンは 10.1です。10.1はメジャーリリースで、2017年5月18日に10.1.7がリリースされています。

最新のゲスト OS はVMware Tools 10.1.xに対応し、レガシー ゲスト OS はVMware Tools 10.0.12 に対応します。

 

VMware Tools 10.1.xでサポートされるゲスト OSです。

VMware Tools 10.1で提供されている機能です。

VMware Toolsもアップグレードしなければならないの?

仮想ハードウェアと同様にVMware Tools も最新バージョンへのアップグレードは必ずしも必要ではありません。VMware Tools の新しいバージョンは、複数のホ ストのバージョンと互換性があります。追加された機能や性能が環境にとって必要かどうかを検討後、実行ください。

下図は互換性リストの一部です。

◆仮想マシンのアップグレードのダウンタイム◆

仮想マシンをアップグレードする時、必要なダウンタイムはゲスト OS と実行するアップグレードの種類によって異なります。VMware Tools のアップグレードから開始します。

Linux ゲスト OS の多くは、VMware Tools の現在のバージョンではアップグレード後の再起動が不要です。以前のバージョンでは、「PVSCI」「VMXNET」「VMXNET3」ドライバのアップグレード後にゲスト OS を再起動する必要があります。

 

◆参考◆

  1. ESX/ESXiホストでサポートされる仮想ハードウェアはこちらのKBを参照ください。
    Hardware features available with virtual machine compatibility settings (2051652)

 

  1. ESXi 6.5ホストでバンドされないVMware Tools ISOイメージは、My VMwareからダウンロードできます。バンドルされていない、特定のオペレーティング システム用の VMware Tools をダウンロードする場合は、VMware Tools 10.1.0 リリース ノートなどに記載されている手順を参照ください。

 

  1. ESXiホストのバージョンに関係なく、最新のVMware Tools をインストールまたはアップグレードする方法についてはこちらのKBを参照ください。
    Installing and upgrading the latest version of VMware Tools on existing hosts (2129825)
    こちらのVMware vSphere Blogはコメントも含め参考になります。
    https://blogs.vmware.com/vsphere/2015/09/vmware-tools-lifecycle-why-tools-can-drive-you-crazy-and-how-to-avoid-it.html
    ※ESXi 6.5ホストにバンドルされる3つのISOイメージです。

  1. 仮想マシンのアップグレードについては、こちらのドキュメントを参照ください。
    https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-EE77B0A9-F8FF-4785-BEAD-B6F04EE04492.html

 

 

◆まとめ◆

今回は、最新の「仮想ハードウェア」と「VMware Tools」をご紹介しました。

本文内では、仮想マシンのアップグレードは必ずしも必要ではないと述べていますが、アップグレードすればパフォーマンスや運用の利便性を向上する機能を使用できます。ダウンタイムを考慮し、仮想マシンのアップグレードを検討いただけたらと思います。

ダウンタイムは仮想ハードウェアのアップグレード時には必ず発生しますから、「仮想マシンの互換性アップグレードのスケジュール設定」やUpdate Managerを利用して計画的に進めることをお勧めします。

今回のBlogを書くにあたり、あらためて「仮想ハードウェア」と「VMware Tools」について調べてみました。KBやドキュメントを読むと、新たな発見があり、とても楽しかったです。

お時間が許せば、参考にあげているKBやドキュメントもぜひ参照いただければと思います。

次回は、vSphere 6.5で使用する管理ツールについてご紹介します。

 

 

ここが変わった! VMware vSphere 6.5 Part2

 

日本ヒューレット・パッカード株式会社の中川明美です。

今回はvSphere 6.5から提供される、「vCenter Server Appliance の高可用性」と「vCenter Server ApplianceとPlatform Services Controllerアプライアンスのファイルベースのバックアップとリストア」についてご紹介します。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

vCenter Server停止時の影響範囲は?

VMware製品に初めて関わる方からは、vCenter Server停止時の影響範囲についてよく質問されました。プリセールス時には可用性も含めて提案しますから気になりますね。

最近はvCenter Server停止時の質問は減りましたが、復習をかねて影響範囲について確認しましょう。

vCenter Serverが停止して困るのは、vCenter Serverが提供している機能を使用できない時です。たとえば、仮想マシンのクローン作成やvMotion(仮想マシンの移行)を行う時です。

vSphere HAや分散スイッチは、新規作成や設定変更時にはvCenter Severが稼働している必要があります。しかし機能の継続には支障ありません。vSphere HAや分散スイッチは、ESXiホスト側で管理する仕組みを持っているからです。

最近の質問は、「vCenter Single Sign-Onサービスが停止したら、vSphere Web ClientからvCenter Serverにログオンできなくなるの?」です。次から次へと疑問は尽きませんね。

 

Platform Services Controller (PSC) の可用性

こちらのBlogでは、vCenter Serverの可用性を中心に進めます。vCenter Single Sign-Onサービスを含むPSCの可用性については、組み込みのPSCか外部のPSCを選択するかで方法が異なります。組み込みのPSCはvCenter Serverを保護すれば同時にPSCも保護されます。

外部のPSCの可用性については、こちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.psc.doc/GUID-62CC201A-01ED-4116-8604-FF123481DAFC.html

 

vCenter Server の可用性

vCenter Serverを長く停止させるわけにはいけませんから、少しでもダウンタイム (サービスの停止時間) を短くする方法を検討する必要があります。

vCenter Serverの可用性については、いくつかの方法が提供されてきました。シンプルな方法として選択されてきたのはvSphere HAですね。

vSphere 6.5では、vCenter Server Applianceを対象に、「vCenter High Availability」が追加されました。ハードウェア障害からの保護だけではなく、 パッチ適用などサービスを停止しなければならない際にダウンタイムの短縮に役立ちます。

<補足情報>

vSphere 6.0のドキュメントになりますが、vSphere HAとMicrosoft Cluster Serviceで構成するvCenter Serverの可用性についてまとめられています。参考にしてください。

http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.vcenterhost.doc/GUID-4A626993-A829-495C-9659-F64BA8B560BD.html

以下はvCenter Server の高可用性に関する VMware の KBです。こちらも参考にしてください。

-英語版-
Supported vCenter Server High Availability Options
https://kb.vmware.com/kb/1024051

-日本語版-
サポート対象の vCenter Server 高可用性オプション
https://kb.vmware.com/kb/2089839

vCenter High Availability

vCenter HAは3つのvCenter Server Applianceインスタンスから構成します。

1つ目のインスタンスは、Activeノードとして使用されます。Activeノードのクローンが2回作成され、Passiveノードと監視ノード用に構成されます。

Activeノードに障害が発生すると、自動的にPassiveノードに役割を引き継ぎます。監視ノードはクォーラムを提供し、スプリットブレインの状態から保護します。

vSphere 6.5から提供される機能ですから、ESXiホストも6.5で構成できればよいですね。

vCenter HAのハードウェア要件とソフトウェア要件はこちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.avail.doc/GUID-8FD87389-8CC9-4298-8B08-A1526FB44524.html

設定方法はシンプルです。下図のウィザードにあるように、vCenter HAネットワーク用のIPアドレスを設定します。環境に応じて、「Passive」と「監視」の仮想マシンをどのESXiホスト、どのデータストアに配置するかを指定します。事前にESXiホスト上にvCenter HAネットワーク用のポートグループを作成しておく必要があります。

vCenter Server ApplianceおよびPlatform Services Controllerアプライアンスのバックアップ

vSphere 6.0から、vSphere Data Protectionを使用して、vCenter Server、vCenter Server Applianceまたは Platform Services Controller を含む仮想マシンのイメージベースのバックアップができるようになりましたね。vCenter Serverを、vSphere Data Protection アプライアンスが実行されているESXi ホストに直接緊急リストアできることは特徴の一つです。

 

<補足情報>

vSphere Data ProtectionはvSphere 6.5が最後の提供となります。

https://blogs.vmware.com/partnernews/2017/04/vsphere-dp-eol.html

 

vSphere 6.5 では、vCenter Server Appliance 管理インターフェイスを使用して、vCenter Server Appliance と Platform Services Controller アプライアンスのファイルベースのバックアップを提供します。バックアップはvCenter Server Appliance 管理インターフェイスを、リストアはvCenter Server Applianceの GUI インストーラを使用します。

 

< vCenter Server Appliance 6.5のバックアップ>

vCenter Server Appliance 管理インターフェイス (https://vCetner Server ApplianceのFQDN or IPアドレス: 5480) を使用してバックアップします。

バックアップデータは、指定したリモート システム(たとえばFTPサーバー)に、HTTPS/ HTTP/ SCP / FTPS/ FTPのいずれかを使用してストリーミングされます。

< vCenter Server Appliance 6.5のリストア>

リストアは、次の2つの手順で実施されます。

  1. vCenter Server Appliance 6.5 Installerでovaファイルのデプロイ
  2. vCenter Server Appliance 管理インターフェイスでバックアップデータの転送

1の手順でovaファイルのデプロイ完了後、 vCenter Server Appliance 管理インターフェイスへリダイレクトされ、2の手順のリモートシステムにあるデータを、新しくデプロイされた vCenter Server Appliance にコピーします。

リストア後、vCenter Server Applianceと Platform Services Controller アプライアンスのデプロイタイプにより、スクリプト /usr/bin/vcenter-restore を実行します。

詳しくは、こちらをご確認ください。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-67C7D3ED-2A52-4960-95EC-03C4EE3F5E34.html

 

◆まとめ◆

今回は、vSphere 6.5で提供された、vCenter HAとvCenter Server Appliance と Platform Services Controller アプライアンスのファイルベースのバックアップをとりあげました。

可用性については、vSphere HAを選択するべきか、vCenter HAを選択するべきか。

vSphere HAはDRSの非アフィニティルールと構成することを推奨しています。vCenter HAはESXiホストが3台以上およびDRSを構成することを推奨しています。vSphere HAもvCenter HAも1つのvCenter ServerライセンスとvSphere Standardのライセンスで構成可能です。DRSを使用するならvSphere Enterprise Plusのライセンスが必要です。

どちらの機能を選択し、どのように設計(構成)するかは、運用コストの費用対効果を考慮する必要がありますね。

Windows版のvCenter Serverの場合は、vSphere HAまたはMicrosoft Clustering Serviceのどちらかを検討することになります。

次にバックアップですが、サードパーティ製品を使用して仮想マシンのバックアップを取られていることが多いと思います。コスト面からvSphere Data Protection を検討されていた方もいらっしゃるかと思いますが、先に述べたようにvSphere 6.5が最後のリリースとなりますからご注意ください。

vCenter Server Applianceをご使用であれば、正常に動作するアプライアンスを復元できるようにバックアップデータを取りますから、こちらもお勧めかもしれません。

次回は仮想ハードウェア Version 13  VMware Tools Version 10.1ついてご紹介します。

HPE Synergy – 最初のコンポーザブル インフラストラクチャー (HCI) – vSAN on Synergy の構成が認証されました

□はじめに

以下のURLは、HPE小川様のブログです。(外部リンク)
HPE Synergy にご興味をお持ちの方は、以下のリンク先も併せてお読みください。

https://community.hpe.com/t5/%E6%97%A5%E6%9C%AC%E3%81%AE%E3%81%8A%E5%AE%A2%E6%A7%98%E5%90%91%E3%81%91-%E3%82%A8%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%97%E3%83%A9%E3%82%A4%E3%82%BA-%E3%83%88%E3%83%94%E3%83%83%E3%82%AF%E3%82%B9/VMware-vSAN-%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E3%82%AB%E3%82%BF%E3%83%81-%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%82%B6%E3%83%96%E3%83%AB-HCI/ba-p/6964180#.WUdElWjyg2w

□ご紹介

vSANは、最も重要なワークロードを稼働させる信頼性の高いインフラとして、7000社を超えるお客様に使われ、現在も成長を続けています。この流れをさらに促進させるべく、VMwareはパートナー様と連携し、次世代ハードウェアにいち早く対応させることを明言しています。
コンポーザブルインフラストラクチャはお客様が採用を検討する次世代プラットフォームであり、vSANとして初めて認証を受けた最初のコンポーザブルインフラストラクチャであるHPE Synergyを発表できることは非常に光栄です。これは、我々の成熟したお客様が稼働させる従来のアーキテクチャのワークロード、および次世代のワークロードにとって非常に画期的な位置づけの製品です。
HPE Synergyの構成詳細については、以下vSAN VCG(VMware Compatibility Guide)を参照下さい。
AF-6:http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vsan&productid=41543&deviceCategory=vsan&details=1&vsan_type=vsanreadynode&page=1&display_interval=10&sortColum
n=Partner&sortOrder=Asc
AF-4
http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vsan&productid=41542&deviceCategory=vsan&details=1&vsan_type=vsanreadynode&page=1&display_interval=10&sortColum
n=Partner&sortOrder=Asc

□従来のHCIとコンポーザブルHCI

コンポーザブルインフラストラクチャの定義については、次のセクションにて記載をします。しかしその前に、基本的なご質問として良く聞かれるのが、“コンポーザブルインフラストラクチャはHCIとして使用することができるのか?”です。答えは“Yes”です。


基本的な違いは、コンポーザブルインフラストラクチャでは“コンピューティング”と“ストレージ“が構成要素として分かれていることです。従来のHCIは、インフラの成長に合わせて”コンピューティング“と”ストレージ“を一緒に拡張させていました。しかし、ワークロードに対してより柔軟に対応していかなければいけません。HCIの恩恵を維持するためには、”コンピューティング“および”ストレージ“からの要求に対して個別にスケールアウトさせていく必要があります。コンポーザブルインフラストラクチャはHCIの世界でそのような考えを実現するための構成要素です。

□コンポーザブルインフラストラクチャとは?

コンポーザブルインフラストラクチャは、3つの要素(ソフトウェアで定義する仕組み、流動的なリソースプール、統合されたAPI)から構成されています。流動的なリソースプールとは、変化する各アプリケーションの要求に対して、構成要素として分かれている“コンピューティング”、“ストレージ”を柔軟に組み合わせるために必要な要素です。そしてソフトウェアで定義する仕組みとは、自動化(サーバやストレージの仮想化)をより促進することによってIT管理者の運用管理をシンプルにしていきます。最後に、統合されたAPIにより、サイロ化された運用を統合し複雑さを排除する単一の管理インターフェースを提供します。このインフラによって年に1-2回程度のインフラストラクチャのアップデート等が発生した際にも、継続的なサービス提供と、アプリケーションの展開を手助けすることができるようになります。

□HPE Synergy

HPE Synergyとは、フレームと呼ばれる10Uのボックスで、12個のハーフサイズのモジュラーを搭載、もしくは6個のフルサイズのモジュラーを構成するベイが存在しています。これらのベイは、最大12台のサーバを搭載可能であり、最大4台のストレージモジュールを搭載することも可能となっています。さらに、ストレージモジュール毎に最大40のSFF(スモールフォームファクタ)ドライブベイを持っています。
以後のセクションで、vSAN視点におけるHPE Synergyの構成について見ていきたいと思います。

□なぜvSANとSynergyを組み合わせるのか?

HPE Synergyは、今までの HPE BladeSystemからの進化と、柔軟に構成を組めるコンポーザブルインフラストラクチャーの第1弾であり、ここで詳細を学ぶことができます。
https://h20195.www2.hpe.com/V2/GetDocument.aspx?docname=A00006129ENW
それ以外にも、HPE Synergyがもたらす主要な利点がありますが、それらはvSANと組み合わせることによって実現可能となっています。

□分離されたストレージとコンピューティング

ビジネスはより動的になってきており、事前に計画し、必要なワークロードを予測することは困難です。企業は、動的に拡張できるプラットフォーム(コンピューティングとストレージの両方)を求めています。このプラットフォームの最大の利点はストレージとコンピューティングが独立して拡張できることです。

選択された構成シナリオ(以下のHPE SynergyのおけるvSAN展開の選択肢のセクションで説明します)では、単一のHPE Synergyフレームは、最大80 SFF(2.5インチ)ドライブまたは最大10台のコンピューティングサーバーを保持できます。

小規模(3台のコンピューティングサーバと1台のストレージモジュールを部分的に搭載)から始めて、ワークロードに応じて、コンピューティングまたはストレージを追加することができます。

これは今日のビジネス環境において大きな利点です。オーバープロビジョニングを避けることによって先行的な投資を最小化するだけでなく、必要に応じた拡張を可能にする柔軟性を提供します。例えば新しいワークロードがコンピューティングのみを要求する場合は、フレーム内でコンピューティングモジュールを拡張することができます。
実際には、単一のフレーム(筐体)内に最大40台のドライブを搭載した10ノードのvSANクラスタを構築し、ビジネス需要の増加に応じてフレームを追加することで拡張できます。

任意のワークロードに対する単一のインフラストラクチャ:

エンタープライズ企業では、従来のインフラストラクチャで従来のアプリケーションを稼働させ、新しいクラウドネイティブアプリケーションやモバイルアプリケーション等の次世代アプリケーション用途として異なるインフラストラクチャとツールで作り上げる戦略を採用することが期待されています。
しかし、vSANは、従来および次世代のアプリケーション用途として稼働しています。我々はお客様との話し合い、vSANの導入状況を把握することで、日々学んでいます。次の図は、お客様がvSAN環境で実行しているユースケースを表しています。

ここから、vSANは「バイモダルコンピューティング」(従来および新世代のワークロード)に対応すべきである、という事が明確に分かります。
HPE Synergyのアーキテクチャと管理ソリューションは、従来のビジネスアプリケーションと新しいビジネスアプリケーションの両方に対応し、企業が単一のインフラストラクチャでvSANユースケースを実行できるよう支援します。

フレーム間の高速インターコネクト:

HPE Synergyは同じ論理エンクロージャー・サーバー内のフレーム間のイーサネット接続にマスター・サテライト・トポロジーを使用しているため、サーバーのデータ・トラフィックは、トップ・オブ・ラックで導入された環境下でも – 異なるサーバーのフレーム間でも – レイテンシを発生させずに最大20Gbpsの高速イーサネット接続を提供できます。

□なぜ Synergy は vSAN に適しているのか?

HPE Synergyとは:フレームが コンピューティング、ストレージ、ファブリック、冷却、電力、およびスケーラビリティのリソースをプールするインフラストラクチャです。
フレーム内の重要な要素の1つは、ローカルディスクストレージが単一フレーム内でのみアクセス可能であることです。これは、フレーム内のサーバに対して全てのディスクを割り当てる必要があることを意味します。vSANの基本は、ホスト(ESXi)で使用可能な全てのローカルストレージディスクを、全てのサーバが共有する単一のデータストアに集約することです。
従来のラックサーバの場合、コンピューティングとストレージは独立して拡張されません。
しかし、HPE Synergyでは、ストレージを拡張して別々に計算することで、集約を実現できます。これにより、vSANなどのHCIソリューションに最適といえます。

HPE SynergyのおけるvSAN展開の選択肢:

単一フレーム内のHPE SynergyプラットフォームでvSANを構成、および複数のフレームを跨いでvSANを構成し、かつコンピューティングとストレージを構成するなど、方法は数多くあります。実際に選択肢はほぼ無限大です。

しかし、vSANの配備の観点から、1つのフレーム内に3つの基本的な構成(完全集約化)でのみ展開頂くをご提案しています。
※以下に記載のあるSATAとは、HDDを指しているのではなく、SATA インターフェースで接続されたSSD を指しています。
※vSANで認定された ディスクは 「SAS SSD」「SATA SSD」「SAS HDD」「Nearline SAS」 の4種類です。

1xストレージモジュール{D3940(12ドライブ)}と3x Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム:

これらのコンピューティングサーバーのそれぞれは、1つのディスクグループ内に4つのドライブ(1つのキャッシュ+ 3つのキャパシティ)をサーバーごとに構成しています。最適な選択は、SASドライブをキャッシュ層として、SATAドライブをキャパシティ層として使用することです。

2つのストレージモジュール{D3940(80ドライブ)}と8×Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム:

これらのコンピューティングサーバーは、グループ毎に2つのディスクグループ(1つのキャッシュ+ 4つのキャパシティ)の計8つのドライブが構成されています。最適な選択は、SASドライブをキャッシュ層として使用し、SATAドライブをキャパシティ層として使用することです。

1xストレージモジュール{D3940(40ドライブ)}および10x Compute Servers {SY 480}ハーフハイトサーバーを備えた1つのフレーム:

これらのコンピューティングサーバーは、1台のサーバーにつき1つのディスクグループとして4つのドライブ(1つのキャッシュ+ 3つのキャパシティ)で構成されています。最適な選択は、SASドライブをキャッシュ層として、SATAドライブをキャパシティ層として使用することです。
SynergyでのオールフラッシュvSAN構成での3つの展開例として、以下の表を参考にしてみましょう。

単一フレーム内でのvSAN構成例
もう一度繰り返しますが、vSANを構成するには初めに3台のコンピューティングサーバーが必要です。上記は、単一フレーム内での構成例です。この新世代のハードウェアがさらに普及するにあたり、ユーザーが望むその他構成について更に考えていきます。

HPE SynergyとHPE BladeSystemとの比較:

HPEサイトには素晴らしい文書があり、ここで読むことができます。しかし、私はここでの比較で紹介したいと思います:

□HPE Synergy を適用しにくいケース

HPE Synergyは単一のインフラストラクチャとして多くのユースケースをカバーしていますが、現時点でHPE Synergyに向かない用途もあります。

1. ストレージモジュールでNVMeドライブが必要なアプリケーション:

ストレージモジュールにNVMeデバイス並みのパフォーマンスを必要とするニッチなワークロードが存在する可能性があります。
今日のHPE Synergyプラットフォームは、ネイティブPCIeの代わりにSASインターフェイスを使用しているため、ストレージモジュール上でNVMeをサポートしていません。
ただし、HPE Synergyは、vSANのキャッシュ層デバイスとして使用される可能性のあるサーバーモジュールでNVMeサポートを提供しています。

2.大容量のDASストレージ:

ご存知のように、3.5 “ドライブは2.5″ドライブより容量が大きいです。現在のHPE Synergyストレージモジュールは3.5 “ドライブをサポートしていません。
ワークロードとして大容量ストレージを必要とし、パフォーマンスを必要としないDAS指向アプリケーションがいくつかあります。

このような場合、Synergyは最もコスト効率の高いストレージソリューションを提供しない可能性があります。パフォーマンスと高密度ストレージの両方を必要とするアプリケーションであれば、Synergyは依然としてそのようなワークロードに最適なプラットフォームです。

まとめ:

組織がこの新世代のプラットフォームを採用して従来のアプリケーションや次世代のアプリケーションを稼働させるにあたり、VMwareは、HPEさんのようなパートナー様と密接に連携して、vSANの有効性を証明していきます。

HPE Synergyは、ストレージとコンピューティングを分割して管理する最適なHCIを提供することで、お客様は要求に基づいて環境を成長させることができます。

vSANハードウェアに関するご質問は、vsan-hcl@vmware.comまでお問い合わせください。

ここが変わった! VMware vSphere 6.5 Part1

日本ヒューレット・パッカード株式会社の中川明美です。

vSphere 6.0とvSphere 6.5の違いを尋ねられることが多くなりました。そのご質問に、こちらのBlogで回答します!

また、バージョンアップ時にプリセールスのみなさまからよくご質問をいただく内容をふまえ、vSphere 6.5の変更点をお伝えします。次の6回構成です。

 

#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)

#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)

#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1

#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)

#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)

#6: vSphere DRS (Predictive DRS / その他のオプション)

 

 

1回目と2回目は、vCenter Server Applianceのアップデートについてです。併せてWindows版との違いも説明します。

 

■ vCenter Server Applianceに含まれるソフトウェア ■

vCenter Server Appliance 6.5は、下表のソフトウェアで構成されます。

6.5からPlatform Services ControllerとvCenter ServerはPhoton OS上で動作します。Project PhotonはVMwareがコンテナ向けにリリースした軽量Linux OSです。

Update ManagerはvCenter Server Appliance 6.5ではサービスとして提供されます。そのためインストール不要です。Windows版のUpdate Managerはコンポーネントとして提供されるため、従来通りインストールが必要です。

1

vCenter Server Appliance 6.5は仮想ハードウェアバージョン10 (ESXi 5.5以降でサポートされるバージョン) で提供されます。仮想ハードウェアバージョン10ですから、vCenter Server 6.5は、ESXi 5.5以降のホストまたはvCenter Server 5.5 以降のインスタンスのインベントリに含まれる ESXi ホストまたは DRS クラスタにデプロイできます。

 

~ハードウェアリプレース時~

ハードウェアリプレース時には、vSphereの移行方法(導入手順)に関わるため、最新のvCenter Serverの配下に既存のESXiホストが動作可能なのかをよく尋ねられます。

下図は、「VMware Product Interoperability Matrices」の画面ショットです。vCenter Server 6.5ではESXi5.5以降のホストを配置可能です。

2

■ vCenter Serverのコンポーネントとサービス ■

6.0と6.5で、「Platform Services Controller」と「vCenter Server」のコンポーネントがインストールされるのは変わりません。「Platform Services Controller」は6.0から提供されているコンポーネントです。

6.5で追加されたサービスは、Webブラウザを使用するvSphere ClientとUpdate Managerです。先に述べたとおり、Update ManagerはAppliance版に追加されます。

Syslog CollectorはWindowsと明記しているとおり、Windows OS上にインストールするサービスです。vCenter Server ApplianceでのLog収集はLinux OS に組み込みの Rsyslogサービスを使用します。

ESXiホストにLocalディスクを搭載しない場合は、トラブルシューティングのためにDump CollectorやSyslog Serverを別途準備しておく方がよいですね。

3

■ vCenter Serverのスケーラビリティ ■

vCenter Serverのキャパシティについてです。6.0と6.5では約2倍の差があります。

Appliance版とWindow版のデータベースにかかるコストで比較すると、ESXiホストを20台以上管理する場合、vCenter Server Appliance  6.5に分がありますね。

4

最大構成数は、パブリックのドキュメントを参照しています。

vCenter Server Appliance 6.5は上表から判断できるように、外部データベースをサポートしません。Window版でサポートしている外部データベースの詳細はこちらでご確認ください。

http://www.vmware.com/resources/compatibility/sim/interop_matrix.php#db

 

◆参考情報◆

ハードウェア要件とポート情報を付記します。

 

■ Platform Services Controllerのハードウェア要件 ■

規模に関わらず、2 個の vCPU と 4 GB メモリです。

 

■ vCenter Serverのハードウェア要件 ■

規模に合わせて、ハードウェア要件は異なります。Window版は最小推奨ハードウェア要件となりますから、vCenter Serverに同居するサービスによってメモリサイズを考慮した方がよいと思います。

5

■ Platform Services Controller アプライアンスのストレージ要件 ■

Platform Services Controller アプライアンスのストレージ要件は 60 GB です。

 

■ vCenter Server Applianceのストレージ要件 ■

このストレージ要件には、vCenter Server Appliance でサービスとして実行される vSphere Update Manager の要件も含まれています。インストール中に3つのストレージサイズを選択することが可能です。

■ Windows での vCenter Server および Platform Services Controller の最小ストレージ要件 ■

各フォルダの最小ストレージ要件は、インストール時のデプロイ モデルによって異なります。

7

■ vCenter ServerおよびPlatform Services Controllerに必要なポート ■

必要なポートはこちらで確認できます。

http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-925370DD-E3D1-455B-81C7-CB28AAF20617.html

 

◆まとめ◆

1回目は、Platform Services ControllerとvCenter Serverの概要についてでした。

プリセールスの方には必要なコンポーネントやハードウェア要件を、導入エンジニアの方には設定値レベルで必要な情報と思われるものをリストアップしました。

今後は、vSphere 5.5からvSphere 6.xにアップグレードされるお客様が増えてくるのではないかと思います。今回のテーマの5.5と6.xの違いは、vCenter Single Sign-OnがvCenter Serverコンポーネントに存在するか否かです。

6.5のアップデートでは、Enterprise Plusを前提とする機能も散見しますが、それらはパフォーマンスを改善する機能として提供されます。

2回目はvCenter Server Applianceの高可用性とバックアップです。お楽しみに!

 

 

 

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

第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推奨構成