Find Communities by: Category | Product

【全6回シリーズ6/6 最終回! 新時代のデータ保護】

 

「クラウドネイティブ」という言葉は、クラウド中心のITインフラを利用していく場合に使われる。ただしその場合のクラウドとはこれまで、オンプレミスで構築したプライベートクラウドを指すことが多かった。しかし「マルチクラウド」という考え方が浸透してきているのも事実で、パブリッククラウドを含めたクラウド活用をどう確立していくかが話題となっている。今回は、バックアップも含めたデータ保護の観点から、新しいパブリッククラウドの利用法をDell EMCのPeter Marelas氏に聞いてみた。

 

 

Peter Marelas

Dell EMC

Principal Systems Engineer

最近、お客様のクラウドに関する懸念事項に変化を感じることが増えました。

Bain cloud computing surveyの調査でも、それがはっきり裏打ちされていますので、少し紹介しましょう。この調査では、2012年と2015年での、懸念事項に関する回答を比較しています。

cloud.jpg

 

2012年の段階では、懸念事項の中心はデータセキュリティやコスト、そしてSLAが守られるかといったことでした。もちろん、こうした懸念は2015年においても消えてしまうことはないのですが、2015年時点での懸念事項の中心は、データの可搬性、サービス事業者からのロックイン、コンプライアンスや規制対応などになっています。

 

Dell EMCでも、パブリッククラウドを利用するお客様から、さまざまなご相談を受けています。プライベートクラウド、オンプレミスを含めたマルチクラウド、ハイブリッド環境を構築しているお客様も多く、安全かつ低コストでパブリッククラウドをどう利用していくかに腐心されているお客様がほとんどです。

 

簡単に言ってしまえば、こうしたお客様は、パブリッククラウドの中にある自社のデータおよびワークロードを、オンプレミスの環境と同様にコントロールしていきたいと考えています。

 

これが実現すれば、1つのパブリッククラウドから状況に応じて別のクラウドにデータを移行することができますし、セキュリティも保たれます。また、ある事業者のサービスにロックインされることもありませんし、常にコストを最適化することが可能です。

 

Dell EMCでは、こうしたご要望に対応するため、「LTR To Cloud(クラウドへのデータ長期保存)」「DR To Cloud(クラウドへのDR)」「In Cloud Protection(クラウド内での保護)」「SaaS Protection(SaaSデータの保護)」という4つの用途に分けてパブリッククラウド向けのソリューションを開発、提供しています。

 

●4つの用途に分けたDell EMCのパブリッククラウド向けソリューション

 

「LTR To Cloud」のLTRとは「Long Term Retention(長期保存)」という意味です。長期保存が必要なデータ保管場所を、安価なパブリッククラウドストレージに変えることで従来のデータ保護コストを大幅に節約することができます。

 

しかし、重要データをパブリッククラウドに保管するということに、セキュリティ上の懸念を抱いているユーザーも少なからずいるでしょう。

 

Dell EMCでは、長期保存するパブリッククラウドのストレージも、他のオンプレミスの環境と同様の1つの階層としてとらえ、管理、保護するという考え方を持っています。

 

当社が開発したData Domain Cloud Tierという機能では、AWS、Azure、Virtustreamといったクラウドサービスのストレージをオンプレミスから直接階層化して利用することが可能になります。一定のポリシーに従って、自動的に保存すべきデータが暗号化されたうえで転送され、しかもソース側で事前に重複排除するので、クラウド側に保存するデータ量を大幅に圧縮することが可能です。

 

これによって、従来テープで重要データをバックアップしていたお客様は、大幅なコスト削減ができるようになります。

 

「DR To Cloud」は、災害対策でのパブリッククラウドの活用です。

 

DRサイトでは、データだけでなく仮想マシンをコピーして、万が一の場合は、これらを保存したパブリッククラウド側でシステムを稼働させることになります。また、さらに重要になるのは、しばらくDRサイトでシステムを稼働させていて、のちに本番環境が復旧した場合は、従来のシステム環境に戻る、つまりフェールバックが正確にできるかどうかということです。

 

Dell EMCでは、こうしたフェールオーバー、フェールバックを1つの管理コンソールから簡単に実行できるData Domain Cloud Disaster Recovery機能を提供しています。

 

「In Cloud Protection」は、IaaSとして利用しているパブリッククラウド内のシステムデータを、オンプレミスと同様のレベルで保護するというものです。

 

AWS、Azure、Virtustreamなど代表的なパブリッククラウドは、機能も充実しており、安全性も向上していますが、それでも、ユーザーによる作業ミスやシステムデータの部分的な棄損、破壊の可能性はゼロではありません。

 

Dell EMCでは、こうした可能性に対応するために、「Cloud Snapshot Manager」というサービスを提供しています。現在、AWSに対応していますが、まもなくAzureにも対応することなります。

 

「Cloud Snapshot Manager」は、製品機能ではなくサービスとして提供するものです。パブリッククラウド内のスナップショットを外部からコントロールすることで、実装・管理の簡素化だけでなく、適切なデータ保護状況のモニタリングや、コストに直結するストレージ容量消費の適正化を可能にします。

 

また、このサービスを利用することで、IaaSとしてクラウドを活用している場合は、他のIaaSにシステムを移行させることも理論上可能です。昨今は、パブリッククラウドで稼働していたシステムを、マルチリージョン、マルチクラウドで戻すというニーズも出てきています。いずれにしても、こうしたスナップショットの管理をサービスとして利用できれば、新たな大がかりなソリューションを導入する必要もなくなり、リーズナブルだといえるでしょう。

 

「SaaS Protection」は、SaaS利用におけるバックアップです。Office 365、Salesforce、G Suiteなどのバックアップサービスを提供している、Spanning社と協力してお客様に提供しています。このSaaS向けバックアップサービス自体もSaaSなので、ソフトウェアやアプライアンスを導入する必要はありません。

 

●これからのクラウド活用における留意点とは?

 

今後は、多くの企業でパブリッククラウドの活用がもっと活発化すると、わたしは考えています。それは、データ保護の観点からもいえることで、低コストのパブリッククラウドをうまく利用することで、従来のストレージ関連コストが低減され、また、運用負荷も低くなるからです。

 

この方向性に抗う企業は、ほとんど存在しえないでしょう。実際、「Cloud Snapshot Manager」は、ある金融機関の「パブリッククラウドでも、オンプレミス並みのデータ保護をしたい」という要望に当社が応えることで完成したサービスなのです。

 

オンプレミスのプライベートクラウドよりも、パブリッククラウドをIT環境の中心にすえて考える企業は、次第に増えていっています。だからこそ、Dell EMCでは、4つの用途にわけたクラウドソリューションを提供しているわけです。

 

ただし、クラウドサービス事業者は、ユーザーデータの完全性を担保してくれるわけではありません。データ保護は、利用者自身が手を打つしかないのです。そして、どんなに優れたクラウドサービスも時には障害が起きることがあり、ユーザーはその事態に備え、データを含めたシステム全体を守り、事業の継続性を担保していかなくてはなりません。

 

こうした備えをしっかりとることで、パブリッククラウドの活用がさらに効率化、安全化され、それが、ユーザーの競争力の源泉ともなります。

 

日本のお客様にも、そうした本当の意味での「クラウドネイティブ」な企業が増えてきているのも事実です。Dell EMCは、こうしたお客様のニーズに応えるためにも、素早くニーズをキャッチして、先進的で利用しやすい、製品、サービスを提供していきます。

 

 

《まとめ》

パブリッククラウドは、一部のサービスのみか、長期保存する必要のあるデータの保管場所、ととらえるユーザー企業はまだ少なくない。しかし、グローバルのさまざまな有力ユーザーの動向を知るMarelas氏によると、パブリッククラウドの利用メリットを最大限に生かし、重要なシステムをそこに移行する動きが活発化しているようだ。おそらく、システム関連経費を大幅に絞ることで、新たな投資や事業拡大の余地を増大させるというのがその目的だろう。こうした動きは早晩国内にも波及してくるはずで、それに備える意味でも、Dell EMCのクラウド関連ソリューションは注目に値する。

 

聞き手・構成

ITジャーナリスト 大西高弘

 

【シリーズ:新時代のデータ保護】

1回:DellEMCDNAを融合させたData Domainシリーズの最新版「Data Domain DD3300」の魅力とは?

2回:最新のデータ保護アーキテクチャを適正なコストで構築するための秘訣

3回:今後、データ保護ルールの新デファクトスタンダードになる可能性もあるEU一般データ保護規則(GDPR)

4回:サイバー対策の最新トレンド「サイバー復旧」とは何か?

5回:Dell EMC、データ保護コンバージドアプライアンス「IDPA」のエントリーモデル「DP4400」を提供開始 シンプルでパワフルなデータ保護機能をより身近に

6回:今後拡大が見込まれる「パブリッククラウドを活用したデータ保護」ユーザーが留意すべきポイントとDell EMCデータ保護の戦略


【全6回シリーズ5/6 新時代のデータ保護】

 

Dell EMCは、2018年7月、統合データ保護アプライアンス「IDPA(Integrated Data Protection Appliance)」シリーズの最新モデル「DP4400」の提供を発表した。この製品は既存のIDPAシリーズの各製品の中では価格を抑えた「エントリーモデル」として位置づけられる。このことで、データ保護関連の全体コスト、特に運用コストに悩むユーザーも、より身近にハイレベルな重複排除機能やマルチクラウド環境でのシンプルな運用プロセスを利用できるようになる。そこで、今回はこの製品に深くかかわったDell EMCのTan Jit Chuan氏に話を聞いた。

Tan Jit Chuan

Dell EMC

Field CTO

APJ DPSチーフアーキテクト

 

今回市場投入した統合データ保護アプライアンス「IDPA(Integrated Data Protection Appliance)」シリーズの最新モデル「DP4400」は、「IDPA」シリーズの中で初のエントリーモデルとして位置づけられます。そのため、IDPAが提供するシンプルでパワフルなデータ保護機能を、より身近に利用できる製品といえるでしょう。

 

まず、DP4400のお話しを始める前に、なぜDell EMCがIDPAの提供を始めたかについて、お話しさせてください。

 

みなさんもご存じの通り、世界中で発生しているデジタルデータは、IDCの調査によると、2013年の4.4ゼタバイトから2020年には44ゼタバイトに増加するといわれています。

 

この爆発的な増加は、おそらくみなさん自身も実感していることではないでしょうか。組織で蓄積運用するデータ量は、毎年予想を上回る勢いで増え続け、それに対応するためのストレージコストはどんどん膨らんでいきます。それだけでなく、IT環境の変化から、データ保護の運用も複雑化し、思うようにデータ活用が進まないといった状況も出ているのではないでしょうか。

 

IT環境の変化、というものをもう少し具体的に考えてみましょう。

 

最大の変化はクラウドです。Dell EMCの調査でも、85%のエンタープライズ企業がマルチクラウド環境を目指しており、70%のCIOが、クラウドファーストの方針を掲げています。

 

これは、何を意味しているのか。データ保護の観点からいえば、従来の各部門、縦割りで行っていたデータ保護体制を切り替え、クラウドを活用しながら、あらゆる部門、部署、事業所などで発生するデータを統合的に管理するということになります。

 

このことで、ストレージなどのハードウェアから、管理ソフトウェア、そして運用担当者などの人的コストまで、可能な限り適正化することができます。また同時に、データ管理の壁を取り払うことで、より活発なデータ活用が実現するのです。

 

しかし、ここで新たな問題が発生するようになりました。

 

それは、クラウドも含めたITインフラの複雑化です。縦割りのデータ保護体制を低コストで変更するには、クラウドの利用が欠かせません。しかし、クラウドにはプライベートクラウド、パブリッククラウドの2種類があり、マルチクラウド体制ではこの両方をうまく活用していくことになります。そして、ITインフラには既存のオンプレミス環境もあり、これらを上手に組み合わせて、新しいデータ保護体制を構築していかなければなりません。

 

●マルチクラウド時代に求められるデータ保護体制のありかたとは?

 

たとえば、使わなくなったが廃棄することはできないデータを、利用料金がリーズナブルなパブリッククラウドのストレージサービスに移行する、ということが多くの企業で行われるようになりました。

 

しかし、一定のルールに基づいて自動的に古いデータをクラウドに移行できなければ運用プロセスが属人化してしまいます。さらにデータをパブリッククラウドに送信するコストや時間も考えなければなりません。そしてパブリッククラウドが安いといっても、データをそのまま保存しているのでは、やはり利用コストは次第に負荷となってきます。また、その古いデータを利用する必要が発生したときに、どれくらいの時間で社内システムに戻すことができるのか、ということも考える必要があります。

 

それからもう1つ、パブリッククラウドを災害対策(DR)用に利用するということも、昨今のトレンドになっています。この場合、データも含め、仮想マシンをコピーしてクラウド側に保存するわけですが、フェールオーバー、フェールバックを適正に実行できるか、ということも確認しておく必要があります。また、DRサイトの運用は別の管理製品で実行するしかない、というのでは、非常時の運用という意味で不安視されることになるでしょう。

 

「IDPA」がなぜ生まれたか、という背景には、こうした多様な環境でのデータ保護をできるだけシンプルに行いたいというニーズがあります。

 

将来のデータの増加量を予測したうえで、相当の期間対応でき、しかも予測外のIT環境の変化があっても追加のコスト負担は最小限。これこそ、当社のお客様が求めるデータ保護コンバージドアプライアンスなのです。

 

●2Uというコンパクトなアプライアンスが複雑な環境下でのデータ保護を実現

 

「DP4400」は、そのプラットフォームにDell EMC PowerEdgeサーバを採用し、さらに最新のNVMeフラッシュテクノロジーを活用しています。これにより、バックアップ、リストアのスピードも大幅に上がりました。ストレージ容量はオンプレミスで24テラバイト~96テラバイト、クラウドに追加で192テラバイトまで拡大できます。この容量は、2Uというサイズで提供可能な容量として、同クラスの他社製品よりも20%大きなものです。

 

最小構成の24テラバイトだけでなく、どの容量でスタートしても、それ以上の利用が必要なときは、追加のライセンスをお支払いいただくだけで、最大96テラバイトまで拡張でき、ハードウェアを買い足す必要はありません。

 

「DP4400」は、ほかの「IDPA」シリーズと同じくVMwareの仮想環境で55:1、それ以外でも高い重複排除率を誇ります。この能力は、他社製品を大きく上回るものです。この重複排除機能があるおかげで、ユニークなデータのみバックアップされるので、クラウドへの転送においても、暗号化された状態の重複排除後データを送ることができます。そのため、生のデータをそのまま転送するのに比べて98%帯域を少なくできます。

 

そして、「DP4400」は、こうした高い機能をわずか2Uの筐体で提供します。データの保存容量が増えても2Uのままなので、データセンターのコスト低減にも貢献できます。

dp4400.png

dp4400-2.png

また「IDPA」ではシンプルな運用を可能にすることを目指しており、お客様からも高い評価をいただいています。「DP4400」でも、シンプルで直感的に理解できる管理コンソールを用意し、データの検索も素早く実行することが可能です。

 

dp4400-3.png

 

●企業規模にかかわらず適正なデータ保護環境を実現できる「DP4400」

 

クラウドへの対応についても、もちろん、「DP4400」は他社製品にはない機能があります。

 

パブリッククラウドをDRサイトに活用している場合、復旧後のフェールバック、つまり一度DRサイトで運用していた体制を従来の本番環境に戻すことが必要になりますが、「DP4400」が搭載するData Domain Cloud Disaster Recovery機能が、いつでも本番環境に戻すことを可能にします。

 

現在はオンプレミスのVMware仮想OSをAWSへフェールオーバー、およびフェールバックが可能で、近々にはAzureなど他のパブリッククラウドプラットフォームもサポートする予定です。

 

dp4400-4.png

また、この製品はご購入後、数時間で利用開始することが可能なように設計されており、何カ月もかけて改めてユーザー側で設定しなおすという必要はありません。

 

さらに、運用における自動化機能も充実させて、クラウド、オンプレミス間のデータ送信も簡単に設定できるようになっています。

 

また「DP4400」は、Dell EMCのストレージをご購入いただいたお客様に対するさまざまなお約束をさせていただく、「FUTURE-PROOF STORAGE LOYALTY PROGRAM注1」の対象製品にもなっています。重複排除率はもちろん、お客様満足度などもお約束させていただき、保守コストも明確にした上で保証し、この製品にまつわるすべてのコストを透明にしています。したがって、予測していなかったコストがご購入後に発生することはありません。

 

こうしたことができるのも、当社が「DP4400」の性能について高い自負をもっているからとご理解いただければと思います。マルチクラウドの時代はすでに到来しており、会社の規模にかかわらず、多くの企業にとって当たり前の環境となりつつあります。そうした環境で、適正にデジタルトランスフォーメーションを実現するためにも、「DP4400」の活用を検討していただければと思います。

 

《まとめ》

Jit Chuan氏は、「DP4400」は、EU一般データ保護規則(GDPR)などの厳しい規制なども念頭にいれて開発したと話す。エントリーモデルといっても、データ保護機能は従来の「IDPA」シリーズとほぼ同等の能力をもつこの製品は、データ保護にまつわる追加コストも含めた関連予算を圧縮したいユーザーから、大いに注目されるものとなるはずだ。

 

聞き手・構成

ITジャーナリスト 大西高弘

※注1:Dell EMC FUTURE-PROOF STORAGE LOYALTY PROGRAM

 

参考文献:Efficiently Protect Virtual Environments with Integrated Data Protection Appliances from Dell EMC(ESG Lab, February 2018)

 

 

【シリーズ:新時代のデータ保護】

1回:DellEMCDNAを融合させたData Domainシリーズの最新版「Data Domain DD3300」の魅力とは?

2回:最新のデータ保護アーキテクチャを適正なコストで構築するための秘訣

3回:今後、データ保護ルールの新デファクトスタンダードになる可能性もあるEU一般データ保護規則(GDPR)

4回:サイバー対策の最新トレンド「サイバー復旧」とは何か?

5回:Dell EMC、データ保護コンバージドアプライアンス「IDPA」のエントリーモデル「DP4400」を提供開始 シンプルでパワフルなデータ保護機能をより身近に

6回:近日公開予定

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.5.210が先日リリースされ、GW中にリリースされたばかりのvSphere6.5 Update 2が早速実装されました。

パッチリリースではないマイナーバージョンアップも即座に適用してくるところは、Vmware側と密に連携して開発している事の現れですね。

 

■VxRail 4.5.210 へのアップグレードに関して

早速弊社でもアップグレードと、ファクトリーリセットからの初期セットアップを試しました。


※アップグレードに関しては、過去の本ブログにもその手順を記していますが、適用手順は従来通りでSupport EMCサイトからアップグレード用のパッケージをDLして適用するか、VxRail Managerがインターネットに接続されている環境であればオンラインでのパッケージDLと適用が可能です。


アップグレードをDELLモデル(E460F)への適用を試したところ、4Node構成の内部vCenter構成の場合で約6時間と、今までより長いメンテナンス時間が必要でした。

これはBIOSやSAS HBAのファームウェア、iDRACなど、ハードウェア関連のソフトウェア更新時のESXiホスト再起動と、ESXi への6.5u2適用時の再起動で複数回再起動が走るため、従来より長めの時間を要しています。

 

■ vSphere 6.5 u2での不具合改善とその影響について


VxRailに限らず、vSphereでは長いこと「冗長電源の片系断をアラームで検知できない」不具合がありました。

これが6.5u2でようやく修正されました。

 

お客様先でシステム導入時の障害検証で正しく検知されない、といったこともなくなります。

 

-- リリースノートからの抜粋 --

vSphere Web Client で、一部のハードウェア健全性ステータス アラームが失われ、センサーが誤ったグループに表示される可能性がある

ハードウェア センサーからの問題、または接続されていない電源などのハードウェアの問題によって、vSphere Web Client の [ハードウェア ステータス] タブでアラームがトリガされない可能性があります。ハードウェア センサーが、誤ったカテゴリに表示される可能性があります。たとえば、ストレージからのセンサーが電圧グループに表示される可能性があります。

本リリースで、この問題は修正されました。

----

 

ただ、検証環境やデモ環境などで設備の制限で片系しか給電できなかった環境では、

6.5u2適用と同時に一斉にホストにレッドアラームが表示されてしまい、非常に見た目が悪くなってしまいます。

 

実際に弊社環境でも、アップグレード前は正常だった(正常に見えていた)クラスタが、一気にレッドアラームが点きっぱなしになりました。

VxRail_4.5.210_20180512_016.png

 

この状態はVxRail Managerの健全性チェック(診断)でも引っかかります。※前のバージョンは引っかからなかった…

VxRail_4.5.210_20180512_014.png

 

VxRail 4.5.210 での初期セットアップやノード拡張時に片系電源だけでの構築、拡張は問題ありませんでしたが、

今後バージョンアップの時などクラスタの正常性確認が走る際に、このエラーがあると何か影響しそうな予感です。

 

もし、Web Clinet上の見栄えが気になるけれども、検証環境やデモ環境のファシリティの制限で片系電源しか用意できない場合は、

「ホストのハードウェアの電源状態」という、vCenterのトップ階層に設定されたデフォルトのシステムアラーム定義を無効化することでアラームは表示されなくなりますが、本来のアラームの目的とは真逆の設定なのでご注意ください。

※個別のホスト、クラスタでアラームを無効化したい場合は逆のカスタムアラームを作成すれば打ち消せるかもしれませんが、少し面倒そうなので時間ができたら試します。

VxRail_4.5.210_20180512_021.png

 

※アラームを無効化してもVxRail Managerでの診断には引っかかりました。アラームの無効化の分、若干エラーの検知個所は減っています。

VxRail_4.5.210_20180512_023.png

 

■ 気になる改善点


VxRail 4.5.210でのアップグレード周りの機能改善点として、VxRail 4.5.200以前では、最小3Nodeで構成された場合はアップグレード時の事前チェックを無効化する必要ありましたが、4.5.210からは3Node構成でも通常と同じようにアップグレードができるようになったようです。

※ 4.5.210から次のバージョンへの更新で確認できるはずなので、次期パッチリリース時に試してみます。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



今月、VxRailチャンピオンクラブの勉強会にLTで参加した際に、皆さんいろいろとvSANやHCIの負荷試験についてその方法を検討されている様でしたので、私がよく使うVmware社のLabsツール、HCIBenchの使い方を紹介いたします。

あまり日本語で取り上げられていないので、これから試してみようという方、ぜひとも参考にして頂ければと思います。

 

※本投稿はvExperts Advent Calendar 2017 の12月17日の分の参加blogになります。

https://adventar.org/calendars/2248

 

※ 2019年に HCIBench 2.0 がリリースされましたので、その後のネタとして以下のブログにも記事をまとめていますので参照ください。

調べたこと 試したこと: HCIBench 2.0 のリリースと機能強化のご紹介

調べたこと 試したこと: HCIBench を利用したベンチマークテストのポイントと効率化(1)

調べたこと 試したこと: HCIBench を利用したベンチマークテストのポイントと効率化(2)


■ HCIBenchとは?

 

HCIBenchとはVmware Labs Filngsで公開されている負荷試験の自動化を目的とした無償のベンチマークツールです。

ツールの公開サイトはこちら → HCIBench

HCIBench-20171218_030.png

 

HCIBenchはベンチマークツールとしてもメジャーなVDBenchを利用したvSANデータストア・vSANクラスタへの負荷試験を自動化して、ベンチマークレポートの収集が簡単にできるようになります。

 

また、vSphere環境であればvSAN以外のHCI、NFSやiSCSI、FCのデータストアに対してもVDBenchの負荷試験利用が可能です。

VDBenchを利用して複数ホストに負荷試験を実施するのは割とテクニックがいるテストなので、これを自動化できるHCIBenchは非常に便利なツールです。

 

HCIBenchはOVA形式の仮想マシンで提供され、vSANの性能検証に欠かせないコントローラVM(PhotonOS)と、負荷用のテストVMテンプレート(PhotonOS)で構成されます。

テスト用のコントローラVMには以下のツールが組み込まれて配布されていますので、準備が非常に楽です。

  • Ruby vSphere Console (RVC)
  • vSAN Observer
  • Automation bundle
  • Configuration files

 

負荷用のPhotonOS VMテンプレートは、別途ダウンロードしたVDBenchが組み込まれ、クラスタに自動でクローン展開されて負荷を実行します。


■ HCIBench実行環境の注意事項


HCIBenchのコントローラVMをデプロイするvSphereクラスタと、負荷をかける対象のvSphereクラスタは同一L2のネットワークが適用されている環境が推奨です。

ユーザーガイドにはどのvSphere環境への展開でも問題ない、と記載されていますが負荷対象のクラスタとコントローラVMの配置されるクラスタは別環境である方が正しいレポートが取得できるので推奨です。

また、HCIでやりがちな構成として、コントローラVMと負荷をかける対象のテストVM、そしてvCenterが同じクラスタ、同じデータストア上に存在すると過負荷を掛けすぎてログが正常に取得できないなど残念な結果になることもあるので、

できれば負荷試験対象のクラスタとは別の場所にvCenterとコントローラVMを配置することが強く推奨されます。今回のVxRail環境は外部vCenterを利用しております。


一度パラメータ指定を間違えて、VxRailクラスタ全体の容量を食い潰し、管理VMのリソースを枯渇させて死亡したことがあります...

間違っても本番環境では実施しないでください。

 

※テストVMとの通信で従来コントローラVMのDHCPサービスを利用していましたが、HCIBench 1.6.5 以降のバージョンではStaticIPでテストVMに自動的にIPを割り当てて検証が可能になりました。StaticIP オプションを利用する場合は、Public NetworkとPrivate Networkを同一ネットワーク(同一VLAN)で設定します。詳細はユーザーガイドを参照願います。

 

■ HCIBenchの準備

 

事前にDLが必要となるものは HCIBench の公式サイトからダウンロードするOVAファイルと、VDBenchのバイナリです。

VDBenchはOracle社が公開しているオープンソースのベンチマークテストツールですので、以下のOracle社のDLサイトから入手します。

Vdbench Downloads

 

■ HCIBench コントローラVMの展開

 

HCIBench でダウンロードしたOVAをvSphereクラスタ上にデプロイします。

vSphereへOVAのデプロイ手順は通常のvSphereの操作手順に準拠しますが、注意点として必ずシンプロビジョニング形式でデプロイしてください。詳細はユーザーガイド(英文)にも記載があります。

 

HCIBench-20171217_005.png

負荷試験の実行結果を蓄積するとコントローラVMの容量が増加しがちなので、不要なデータは試験後に回収後、SSHでログインして削除してしまうことを推奨します。

 

HCIBench-20171217_011.png

デフォルトの仮想ディスクフォーマットがシックプロビジョニングになっている場合がありますので、特にVMFSにデプロイする場合は必ずシンプロに変更してください(NFS・vSAN上にデプロイする場合は結果的にシンプロビジョニングでデプロイされます)

 

HCIBench-20171217_013.png

HCIBenchのネットワークは、WebUIへのアクセス用のパブリックネットワークと、テストVMとの通信用のプライベートネットワークの二つを指定します。

プライベートネットワークはDHCPがすでに利用できる環境であればDHCPをそのまま利用し、DHCPがない場合はプライベートとパブリックを両方とも同じネットワークに指定しておきます。HCIBench 1.6.5以降は自動でStaticIPをこのネットワーク上に設定して負荷試験が実行できます。

 

HCIBench-20171217_015.png

HCIBenchのWebUIアクセス用のネットワーク情報とrootのパスワードを設定します。

ここで指定したrootパスワードはWebUIへのアクセスと、コントローラVMへのSSHアクセスなどでも利用可能です。

 

HCIBench-20171217_016.png

準備が完了したらデプロイを続行します。

シンプロビジョニングなので初期のストレージ消費量は2GB弱と非常にエコです。

 

HCIBench-20171217_020.png

デプロイ完了後、パワーオンしてIPへの疎通を確認してください。



■HCIBenchの初期設定


HCIBenchのWebUIは http://<HCIBench IP>:8080 でアクセスできます。

rootパスワードを入力してください。

HCIBench-20171217_022.png

 

また、ポート8080をつけない場合は、負荷試験結果などが保存されているディレクトリツリーを確認できます。

HCIBench-20171217_029a.png


WebUIにログインできたら負荷対象のvSphereクラスタ情報の入力と、VDBenchのバイナリをアップロードします。

少し画面が長くなりますが、以下のような設定項目を埋めます。

HCIBench-20171217_023.png


ポイントとなる個所を簡単に説明します。


▼ 負荷対象vSphere環境の指定

HCIBench-20171217_031a.png


vCenter、ログイン情報、データセンター、クラスタの情報欄はvSphere Web Clientなどで表示されているインベントリ名を正確に入力します。


▼プライベートネットワークの指定

HCIBench-20171217_029.png

ネットワーク欄はコントローラVMのデプロイ時に指定したプライベートネットワークと同じL2ネットワークのポートグループ名を入力します。(vSS、vDSのどちらでも可能です)

「Set Static IP ~~」のチェック欄は、ネットワークでDHCPが有効でない場合にチェックを入れてください。

その場合、指定するネットワークはHCIBench コントローラVMのパブリックネットワークを同じL2ネットワークを指定します。


▼負荷対象データストアの指定

HCIBench-20171217_032a.png

データストア欄はvSANの様に1クラスタ1データストアであれば、上の様に1行でデータストアのインベントリ名を入力します。


HCIBench-20171217_033a.png

通常のVMFS(FC・iSCSI)やNFSのデータストアを利用する場合で、複数データストアに均等な負荷をかけたい場合は1行毎に入力します。

ここに入力されたデータストアに対して均等に仮想ディスクが作成され、負荷試験が実施されます。


「Clear Read/Write Cache Before Each Testing」のチェックボックスは、この後の設定メニューの負荷対象ホストを個別にアクセス指定する時のみ有効にできます。

ただ、vDSのポートグループを利用する場合には負荷対象ホストを個別指定はできないので、今回はこのチェックは利用しません。


▼負荷対象ホストの指定

HCIBench-20171217_034a.png

HCIBenchは指定しなければクラスタ内の全ホストに対して負荷試験を実施します。

特定ホストのみに負荷試験を実施したい場合などは上記のメニューで指定します。ただし、先にも述べたようにvDSのポートグループを指定している場合はこのオプションは利用できません。


▼テストVMの構成指定

HCIBench-20171217_035a.png

 

テストVMの台数、テストVM1台毎の仮想ディスクの数、および仮想ディスクのサイズを指定します。

「EASY RUN」を選ぶとvSANデータストアの負荷試験用に自動でクラスタの情報を読み取り、テストVMの台数、仮想ディスクの数などが指定され簡易テストが実行できます。

初回の動作確認を兼ねて、「EASY RUN」は一度実施してください。


複数のテストを続けて実行する際などは「Re-Use The Existing VMs If Possible」にチェックを入れてテストVMの再利用が可能です。


▼VDBenchバイナリのアップロード


Vdbench Downloads からDLしたバイナリをアップロードします。

HCIBench-20171217_036.png

「ファイルを選択」ボタンからDLしたバイナリを指定します。


HCIBench-20171217_038.png

 

▼設定バリデーションの実施

HCIBench-20171217_036a.png


設定入力が完了したら「Save Configuration」をクリックし、「Validate」を実行します。

HCIBench-20171217_037a.png

バリデーションがすべてパスしたことを必ず確認してください。

HCIBench-20171217_038a.png


■ HCIbenchを利用した負荷試験の実行


準備が完了したら「Test」をクリックして負荷試験を実行します。

負荷試験の内容にもよりますが、「EASY RUN」であればテストVMのデプロイから負荷試験実行で1時間半ほどかかります。


HCIBench-20171217_059.png

HCIBench-20171217_051.png

負荷試験の一連の動作はすべて自動化されており、必要台数分のテストVMのデプロイ、仮想ディスクの作成、負荷の実行が行われます。

環境のセットアップさえ完了すれば、負荷試験の間は別の仕事に時間を割り当てられるし、業務の終了際に試験を実行して翌朝確認なども可能です。


HCIBench-20171217_018a.png


■ HCIBench 実行結果の確認

HCIBench-20171217_036a.png

テストの完了後、「Result」をクリックするとWebUIで結果の確認ができます。

「Save result」をクリックするか、以下の画面でZIPファイルをダウンロードすることで負荷試験の結果をローカルに保存できます。

HCIBench-20171217_039a.png

負荷試験のテスト名フォルダをクリックすると、詳細データをWebUI上で確認できます。

HCIBench-20171217_026a.png

※EASY RUN はvSANデータストアへの標準的な負荷を想定して、ブロックサイズ4K / R:W=7:3 / 100%RandomIO / 4スレッド で実行されます。


テキストファイルにはベンチマーク結果のサマリが含まれているので、ここを確認すれば試験結果がすぐにわかります。


HCIBench-20171217_027a.png

サマリレポートですが、IOPSやスループット、IO遅延など必要な情報は一通り確認できます。

また、クラスタでのCPU利用率や、vSANのKernel側でのCPU負荷も確認ができます。



それぞれのテストVM毎のVDBenchの結果を確認したい場合はフォルダの中の個別ファイルでチェックできます。


HCIBench-20171217_040a.png

個別のテストVM毎のレポートも全て閲覧可能です。

また、「iotest-vdbench-XXvm」フォルダの配下には、vSANObserverの情報が格納されており、

「stats.html」を開くとvSANObserverのViewで詳細なvSANコンポーネントのレポートを確認することができます。

HCIBench-20171217_041a.png

HCIBench-20171217_042a.png


■HCIBenchの活用・応用編


ここまで、HCIBenchの「EASY RUN」を利用した標準的なテストをご紹介しましたが、

HCIBenchはVDBenchの負荷パターンのパラメータファイルを作成したり、作成済みのパラメータファイルをインポートすることで多様な負荷試験の実行が可能です。

VDbenchのパラメータファイルを初見で1から作れと言われても非常に面倒なのですが、自動で多数のファイルを簡単に作成できるのも大きなメリットです。

HCIBench-20171217_043a.png


負荷パターンは以下の様な項目で指定します。

HCIBench-20171217_044a.png

ここで注意しなければいけない点としては、仮想ディスクの数(Number of Disks to Test)は、必ずテストVMの指定項目で設定した数と同一にすること、負荷試験実施時間(Test Time)は、Reporting Intervalの倍数にすること、Warmup TimeはTest Time以下に指定することくらいです。

Warmup Timeの指定は負荷試験の開始から指定時間は記録されない(暖機運転)となります(オプション)。

Reporting Intervalの指定は長時間の負荷試験中にログが大量になることを防ぐために記録のインターバルを指定します(オプション)。


私の場合は、Read/Write比とRandom/Sequential比、IO ブロックサイズを少しずつ変更し、データストアに対して一括で負荷を掛けられるようにパターンを作り、前パターンの試験を一気に実行できるようにしています。

HCIBench 1.6.5.1ではブロックサイズは以下のパターンで指定できます。

HCIBench-20171217_007a.png


より細かい、VDBenchのパラメータを作成したい場合は、手動で作成したファイルを読み込ませる事ができるので、VDBenchを熟知した方はそちらのほうがやりやすいかもしれません。

 

作成したパラメータはそれぞれのパターンで名前がついていますので、個別のパターンを指定して負荷試験の実行もできますし、「Use All」を選択することで、登録した全パターンの一括負荷試験も可能です。

HCIBench-20171217_009a.png

※作成したパターンファイルはコントローラVMの [ /opt/automation/vdbench-param-files ] ディレクトリに格納されていますので、SCPなどでバックアップもできますし、SSH接続してviなどで直接パラメータファイルの編集も可能です。

HCIBench-20171217_022a.png

自動生成されたパラメータファイルを編集して、VDBenchの追加パラメータを含めることも可能です。


HCIBench-20171217_046a.png

最後に、負荷試験前の仮想ディスクの初期化(ZERO埋め or Randomデータ埋め)の指定や、

パラメータファイルで指定した試験実施時間の上書き変更、

試験実施後のテストVMの削除の有無を指定できます。


※試験が失敗したときに再度デプロイ、仮想ディスクの初期化が時間がかかるので、あえてチェックする必要はないかと思います。

 

 

■ まとめ

 

HCIBenchは今まで面倒だったストレージ負荷試験を均質なパラメータで、どんなクラスタにも一括で実施できることができます。

ベンチマーク毎に実行環境やパラメータを変えるのではなく、複数の環境を同じパラメータで試験する事で性能比較が容易になることがHCIBenchの大きなメリットとなります。

 

無償で使え、面倒だったVDBenchを自動化してストレージ負荷試験を実行できる強力なツールですので、ぜひ活用してみてください。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.5の追加機能、リリースノートなどを確認すると

VxRail Manager自体のプロキシ設定のサポートや、ノード拡張時に一度に同時6台を追加拡張できるバッチ拡張モードなどが加わっています。

バッチ拡張モードについては後日、そのレポートを投稿しようと思いますが、

地味にESXi側にも新しい機能が加わりましたのでご紹介します。

 

■ 追加されたサービス


VxRail 4.5のvCenterで各ESXiホストのサービスを見ると、以前とは異なるVxRail関連のエージェントにマニアックな人は気づくかもしれません。

VxRail4.5-UI-20171207_001.png

 

VxRailで以前から

  • loudmouth (EVO:RAILの頃からあるVxRail Manager エージェント)
  • vxrail-election (VxRail 4.0で追加された初期導入時の1st Node選定用プロセス)

の二つが存在していましたが、VxRail 4.5において追加の

  • vxrail-platform-service
  • vxrail-platform-service-util

が加わりました。

 

アップグレードの時にバイナリに含まれていたパッケージがこれら4つのサービスを構成しています。

VxRail4.5-Agent.png

 

■ VxRail Platform Service の役割


新しい二つのサービスが何をしているか、ですがサービス名が示す通り、ESXiの基盤の管理を行うものの様です。

  • vxrail-platform-service
  • vxrail-platform-service-util

このうち、-utilの方はバージョンアップなどの際に利用される様で、詳細が確認できていないのでこちらはいずれ確認次第に紹介します。

 

vxrail-platform-service の実態は、実はesxcliコマンドのオプションとして「esxcli vxrail ~~」が加わっています。

下にESXiにSSHで接続した際のコマンドの画面を貼りますが、ESXiの核となる管理CLI、esxcli にvxrail というオプションが追加されているのが確認できます。

VxRail4.5-UI-20171207_003.png

 

今のところ、ハードウェアの構成(マザーボード・ドライブ情報など)やファームウェアの状態確認などの機能が利用できます。

VxRailが単なるvSAN Ready Nodeの亜種ではなく、Vmwareの核となるESXiとも密に連動したアプライアンスであるという方向性がこの辺りのアップデートからも感じることができます。

 

※個々のオプションの紹介は省きますが、VxRailを利用していて興味ある方はesxcliのオプション詳細が記載されたxmlが以下のファイルなので、こちらを確認してください。

/usr/lib/vmware/esxcli/ext/esxcli-vxrail.xml

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.5.0が9月末にリリース、10月に入ってVxRail 4.0.070がリリースされSupport EMCにもアップグレード用バイナリがいくつか上がっているので、検証した際の手順と注意点を簡単にまとめたいと思います。


VxRail アプライアンスの魅力でもある簡単バージョンアップ機能、vSphere 6.0u3 から vSphere 6.5u1へのメージャーアップグレードが8クリックくらい(ワンクリックではない)で完了してしまいます。

 

※ 年末年始のシステムメンテナンス時にアップグレードを計画されている方もいらっしゃると思いますが、4.0.xから4.5.xへのメジャーアップグレードに対応したバージョン次のVxRail 4.5.1xxとなるようです。まずはVxRail 4.0.400に更新して次のリリースを待ちましょう。

 

※ 作業の公式手順はSolveDesktopの手順書、リリースノートを必ず正としてください。

※ VxRail 4.0.070へのメジャーアップグレードは、2017年12月6日現在、VxRail 4.0.310からのアップグレードが正式サポートとなります。


★DECNでVxRailのアップグレードに関しての情報、注意点などがまとまった以下のスレッドが有用ですのでアップグレードの計画時にチェックをお勧めします。

VxRail Upgradeに関する注意点

 

■ アップグレード用バイナリのダウンロード


まずはバイナリを落とします。Support EMCにログインして、VxRailのダウンロードページの【Full Release】欄のXX Composite for XXがアップグレード用パッケージです。

https://support.emc.com/downloads/39970_VxRail-Appliance-Series

for4.0.310_002.png

今回は 4.0.310からのアップグレードなので

VxRail 4.5.070 Composite Upgrade Package for 4.0.310

こちらを選びます。

ダウンロードしたZIPファイルの中身に何が含まれているかは、先日の投稿を参照ください。

VxRailを構成するコンポーネントのバージョンについて

 

■ 作業前の事前注意・準備情報

 

  • DNSサーバにVxRailの関連コンポーネント(VxRail Manager、vCenter、PSC、各ESXiホスト)のFQDNを登録
    VxRail 4.5.xから、従来vCenter Server Applianceにインストールされ機能していた内部DNS(DNSMASQ)が利用できなくなります。
    そのため、必ずDNSサーバにコンポーネントのFQDNを登録しておく必要があります。
  • vCenter 6.0 -> vCenter 6.5への移行用 一時IPアドレスの用意
    vCenter 6.5は従来のSUSE LinuxベースからPhoton OSベースに大きく変わっているため、仮想アプライアンスが再デプロイされ、既存のデータが移行されます。その時に必要となる一時IPアドレス(既存のvCenterなどと同じセグメント)が一つ必要となります。
  • 当然ながら、アップグレード前はvCenter Web Client側でも各ホストが正常であることを確認しておきます。

 

■ VxRail ManagerへダウンロードしたZIPファイルをそのままアップロード

 

VxRail Managerにログインして、構成メニューから「ローカルアップグレード」をクリックしてZIPファイルをアップロードします。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_043.png

 

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_052.png

Quantaモデルの場合は適用されるものが、VxRail Manager、vCenter Server Appliance、vSphere ESXiの三つとシンプルです。

※実際はESXiの中にVxRail Manager用のVIBや、VxRail Platform Service用のVIBも含まれています。

 

参考に、DELLモデルの場合(以下のキャプチャは 4.5.0 -> 4.5.070へのものですが)は、DELL PowerEdge用の各モジュール一式が更新されます。

VxRail4.5-4.5.070_Upgrade-20171030_021.png

 

■ アップグレードの実行

 

「続行」ボタンをおしてアップグレードを開始すると、早速何か「additional information」を入れろを青帯が表示されます。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_056.png

 

ここで必要になるのが、事前準備の項で記載した、vCenterのデータ移行用の一時IPアドレスと、FQDNを登録したDNSサーバのアドレスです。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_058.png

 

アップグレードが進行すると、自動的に新しいPhoton OSベースのvCSA、PSCがデプロイされ、既存の設定・データが移行されます。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_065.png

vCenterのアップグレードが完了して、サービスが起動すると新しいvCenter 6.5のWeb Clientにアクセスできるようになります。

画面を見ると、Photon OSベースのvCSA以外に、以前のvCSAなどに(legacy)と書かれ、シャットダウンされています。

※正常移行が確認できた後、これらは削除可能です。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_099.png

 

ESXiホストなどのアップグレードも終わり、4Node構成のVxrail アプライアンスであれば2時間ほどでアップグレードは完了です。

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_100.png

 

■ アップグレード後のVxRail 4.5のチェック

 

VxRail Managerの画面を見てると、殆ど何も変わってません(笑)

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_102.png

パフォーマンスViewも同じですね

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_104.png

 

構成設定のあたりをみると「プロキシの有効化」が追加されています。一応VxRail 4.5の追加項目の一つです。ちょっと地味ですが...

BKUP01_VxRail4.0.310-4.5.070-Upgrade_20171030_106.png

 

VxRail 4.5の注目アップデート内容はやはりvSphere 6.5u1に大幅アップグレードなので、やはりメインはWebClientのHTML5対応、でしょうか。当然VxRail環境でも利用可能です。

※vSphere 6.5u1でのHTML5 vSphere Client自体が一部の機能制限がありますが、通常の仮想マシン運用では不自由する事はないと思います。

 

vCenterをブラウザで開くと従来のFlashとHTML5が選べるようになりました。

VxRail4.5-HTML (2).png

HTML5 vSphere Clientを選択すると新しいUIのvCenter環境が利用可能です。

VxRail4.5-HTML (1).png

 

 

今回のアップグレードに関しての記事は以上となります。

vSpehre vSANクラスタのアップグレードもほぼ自動で、運用負担なく実施できてしまうのがVxRail アプライアンスの大きな魅力かと思います。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。




年末年始の計画メンテナンスでVxRailのバージョンアップを計画されているお客様からの質問がちらほら来ているので、2017年12月6日時点でのそれぞれのアップグレードパスをまとめました。

2017年12月5日にVxRail 4.0.400もリリースされましたので、どのバージョンから直接更新が可能か確認する際に参照ください。

 

※ DELL EMCの公式情報ではなく、あくまでもリリースノート、KBやSolveDesktopでの情報を整理した覚え書きです。作業計画時には必ずSolveDesktopの手順書を生成してそちらを正として確認ください。

各バージョンに含まれるコンポーネント情報は以下KB参照

https://support.emc.com/kb/495337

 

アップグレードパスは2018年2月現在、VxRail 4.5 リリースノートの巻末に記載がありますので最新情報はそちらを確認してください。

https://support.emc.com/docu86659_VxRail_Appliance_Software_4.5.x_Release_Notes.pdf

https://support.emc.com/docu80740_VxRail_Appliance_Software_4.0.x_Release_Notes.pdf

※ 表が見切れている時は右にスクロールしてください。

ターゲットバージョン
3.03.54.0.04.0.1004.0.1324.0.2004.0.1314.0.3004.0.3014.0.3024.0.3104.0.4004.5.04.5.0704.5.1xx
3.0-要SR-------------
3.5--○ ※1-----------
4.0.0---○ ※3○ ※3○ ※3-○ ※3○ ※3------
4.0.100----○ ※3○ ※3-○ ※3○ ※3-----
4.0.131----○ ※3○ ※3-○ ※3○ ※3-----
4.0.132-----○ ※3-○ ※3○ ※3----
4.0.200-------○ ※3○ ※3----
4.0.300--------○ ※3---?
4.0.301------------?
4.0.302-------------?
4.0.310-----------○ ※3○ ※2?
4.0.400--------------?
4.5.0-------------○ ※2?
4.5.070--------------?
4.5.1xx---------------

 

注意事項

  • ※1:VxRail 3.5 から VxRail 4.0.x へのアップグレードは、VxRail Manager 4.0.100 の個別パッケージでVxRail Managerを更新し、その後にVxRail 4.0.302のアップグレードパッケージを適用可能。
  • ※2:2017年12月現在、VxRail 4.0.310 から VxRail 4.5.070へのメジャーアップグレードはDELL EMCへSRでサポート依頼を上げる必要がある。また、VxRail 4.0.30x から 4.5.xへのメジャーアップグレードは次期バージョンのVxRail 4.5.1xxでのサポート予定となりますので注意して下さい。
  • ※3:2017年12月現在、ターゲットコードとしてVxRail 4.0.302、4.0.400、4.5.070がSupport EMCサイト上でバイナリが公開されているため、ターゲットコードへの更新が推奨。
  • アップグレード手順は必ず公式のSolveDesktop資料を確認する事。
  • 3Node構成のアップグレード時には事前のクラスタ正常性チェックプロセスをスキップさせる必要があるので注意。
  • VxRail 4.0.310 は 2017年12月時点の出荷時のみの適用バージョンのため、以前のバージョンからVxRail 4.0.310にはアップグレードパスは無し。
  • VxRail 4.0.400 は VxRail 4.0.132 以降のバージョンから直接アップグレードが可能。
  • VxRail 4.0.x から VxRail 4.5.xへのメジャーアップグレードはVxRail 4.0.300 以降で適用可能。ただし、2017年12月6日時点ではVxRail 4.0.310からのみサポートとなり、
  • VxRail 4.5.070のアップグレードパッケージは、4.0.xからのアップグレードパッケージと、4.5.0からのアップグレードパッケージでバイナリが異なるので注意。
  • VxRail Managerを利用したインターネットアップグレードは、最新の同一メジャーバージョンがターゲットとなるので、直接アップグレードがされない世代差の更新がある場合はローカルアップグレードが必要です。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


最近VxRailのバージョンアップについてよく聞かれるので、自分用に各情報のリンクをまとめました。

 

■ VxRailの公式ドキュメント、KB、ダウンロードパッケージなどのURL

Support EMCのアカウントで要ログイン

https://support.emc.com/products/39970_VxRail-Appliance-Series

 

■ VxRailのバージョンアップ用のパッケージの入手方法

Support EMCのダウンロードページから入手可能

https://support.emc.com/downloads/39970_VxRail-Appliance-Series

 

Full Release の + 印を開き、「VxRail <Version> Composite Upgrade Package」というZIPファイルがバージョンアップ用パッケージです。

VxRail_001.png

例えば、VxRail 4.0.3xⅹ から 4.5.070へのアップグレードパッケージ「VXRAIL_COMPOSITE-4.5.070-6881819_for_4.0.zip」の中には、

以下のようなVxRailを構成するコンポーネント(ESXi、vCenter、VxRail Manager、BIOS、Firmwear、VxRail agent、Device driver、etc)など、必要なものすべてが含まれています。

 

VxRail Manager 4.5.070-6881818

  • VMware vCenter Server Appliance 6.5.0-6671409
  • ESXi 6.5.0-6765664 (Dell)
  • Dell ptAgent 1.4-1.10264 (Dell)
  • VxRail Platform Service 1.0.0-60 (All platforms)
  • BIOS 2.5.5 (Dell)
  • Disk Controller 13.17.03.05 (Dell)
  • DELL iSM 2.5.1.ESXi600-0000 (Dell)
  • HBA driver 14.15.00.00-1OEM.650.0.0.4598673 (Dell)
  • VxRail VIB 4.5.070-6881818 (All platforms)

 

BIOSやファームウェアも一括でアップグレードできるHCI製品は珍しいです。

 

ちなみにZIPファイルは解凍せずに、そのままVxRail Managerにアップロードして利用しますが、中身は以下のようになっています。

VxRail_002.png

 

上記のZIPファイルを手動でアップロードしてアップグレードする方法はローカルアップグレードと呼ばれています。

手順などは過去いくつか投稿しているので参照ください。

 

インターネットアップグレードが可能な時は、VxRail Manager上から適用が可能です。

詳細はこちらの以前の投稿を参照

 

■ VxRailの各コンポーネントに含まれるソフトウェアのバージョン一覧、サポートマトリクス。

各バージョンのリリースノート、または以下のKBに集約されています。

 

※ 2018/5/18 追記 : KBの構成が変更となりました。詳細は以下のサポートマトリクスと、外部vCenter利用時のサポマトを参照ください。

VxRail versions and each component code levels (通常のサポマト)

https://support.emc.com/kb/495337

 

VxRail and external vCenter interoperability matrix(外部vCenter利用時のサポマト)

https://support.emc.com/kb/520355

 

 

vSphereのパッチ公開に合わせて順次VxRailもバージョンアップしているので、なるべく最新で安定したバージョンで運用する事が推奨です。

2017年11月30日時点では以下のようなバージョンの組み合わせとなっています。

※最新は常に上記のKBやリリースノートで確認してください。

 

VxRail ReleaseSystem VersionEsxi (Version - Build #)VxRail managervSANInternal vCSAExternal vCSA
MinRecommendedMax
3.03.0.0.34822486.0 U1b - 33801243.0.0.3482248 (VRMe)6.16.0 U1bN/AN/AN/A
3.53.5.0.39368716.0 U2 - 36207593.5.0.39368716.26.0 U26.0 U26.0 U2 or later6.0 U3b
4.04.0.0-46311856.0 U2 P03 - 41922384.0.0-46311846.26.0 U26.0 U26.0 U2 or later6.0 U3b
4.0.000014.0.00001-46311856.0 U2 P04 - 46009444.0.0-46311846.26.0 U26.0 U26.0 U2a or later6.0 U3b
4.0.1004.0.100-49076976.0 U2 P04 - 46009444.0.100-49076966.26.0 U2a6.0 U26.0 U2a or later6.0 U3b
4.0.1324.0.132.00000-51281786.0 U3 - 50505934.0.132-51281776.26.0 U36.0 U26.0 U3 or later6.0 U3b
4.0.2004.0.200-52341436.0 EP07a - 52249344.0.200-52341426.26.0 U3a6.0 U26.0 U3 or later6.0 U3b
4.0.3004.0.300-56294296.0 P5 - 55726564.0.300-56294286.26.0 U3b6.0 U36.0 U3b or later6.0 U3b
4.0.3014.0.301-60265196.0 P5 - 55726564.0.301-60265186.26.0 U3b6.0 U36.0 U3b or later6.0 U3b
4.0.3024.0.302-68297786.0 EP11 - 67650624.0.302-68297776.26.0 U3b6.0 U36.0 U3b or later6.0 U3b
4.0.3104.0.310-61371156.0 P5 - 55726564.0.310-61371146.26.0 U3b6.0 U36.0 U3b or laterN/A
4.54.5-66077446.5 U1 - 59693034.5-66077436.6.16.5 U16.5 U16.5 U1N/A
4.5.0704.5.070-68818196.5 EP02 - 67656644.5.070-68818186.6.16.5 U1a6.5 U16.5 U1aN/A

 

次の投稿ではVxRail 4.0.x -> 4.5.x へのメジャーバージョンアップグレードについて紹介します。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRail 4.5 の検証している中で、いつもDNSサーバの設定は入れて実施しているのですが、

隔離環境用にDNSサーバのアドレスを未指定でセットアップしようとしたところ、

VxRail 4.5 ではこの項目を空欄にすることが出来なくなっていました。


また、VxRail 4.0以前で、外部DNSを利用せずにセットアップした環境(vCSAのDNSMASQサービスを流用していた場合)も、VxRail 4.5へのアップグレード時に外部DNSサーバの準備が必要となります。

※詳細は次のコミュニティのスレッドにコメントしました(こちら

Re: Vxrail構築_DNSサーバを使用しない方法(運用含め)

 

現状、作業PCに簡易的にDNSサーバを立てるなどの準備が必要になりそうです。

VxRail4.5.0_20171113_001.png

 

英語UIだと以下のメッセージ。

VxRail4.5.0_20171113_002.png

 

VxRail 4.5のPoCを隔離環境で実施する場合や、隔離環境での事前セットアップには注意が必要そうです。

ご注意ください。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※2017/10/27 修正版リリース済み


今週週明け、検証環境でChromeでWeb Clientが使えなくなってしまい、普段利用していないFirefoxだと大丈夫だったのでしばらくすれば直るだろうと思ってましたが、WilliamさんのBlogでも取り上げられていました。

http://www.virtuallyghetto.com/2017/10/shockwave-flash-has-crashed-workaround-for-vsphere-web-flash-client.html

 

20171016_017.png

同じ事象でアクセスできない方はFlashが最新になっているとクラッシュするので、しばらくはブラウザのアップデートを控えるか、リスクがありますがKBを参照して古いバージョンのFlashに切り替えるなどワークアラウンドが必要となります。


※2017/10/18 追記 : 公式にKBも出たようです

https://kb.vmware.com/kb/2151945

 

※2017/10/23追記 : Flash Player 27 Betaを入れて回避する方法がKBに追記されました。


※2017/10/27追記 : 面倒を強いられていたWeb Clientのクラッシュ問題。

 

Flashの最新版(27.0.0.183 or later)がリリースされ、解決されました。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※ 前編の「VxRail 管理系VMのバックアップ・リストア方法【バックアップ取得編】」の続きです。

 

前編で取得したバックアップデータを利用して、VxRailの各コンポーネントの復旧を試してみます。


※2018/04 Update:

2018/04現在のVxRailバージョンでは、VxRail Managerなどのバックアップ手順が公式にリリースされました。SolveDesktopなどの手順を必ず確認してデータ保護対策を実施してください。

 

■ VxRail Manager のリストア

 

VxRail Manager VMが起動しなくなってしまった、壊れてしまったという場合は直近のイメージバックアップを戻すことで元通りになります。

※構成ファイルだけを戻したい場合などはFLRで抜き出すか、別途SCPなどで取得しておくことが推奨です。

 

まず、障害状態を作るためVxRail Managerを停止します。

FILESV01_Vxrail4.0.301_20170829_139.png

 

次にvDPのリストア画面からインベントリ名を別名で指定して直近のVxRail Managerを復元します。

FILESV01_Vxrail4.0.301_20170829_140.png

 

リストアオプションは以下の様に別名を指定します。

FILESV01_Vxrail4.0.301_20170829_146.png

 

リストア処理が開始されるとWeb ClientのインベントリにVMが追加され、ステータスが確認できます。

また、DataDomainからはリストアのトラフィックが流れているのが確認できます(リストア時は重複排除データが"復元されて"から流れるので実際のサイズのトラフィック負荷がかかります)

FILESV01_Vxrail4.0.301_20170829_158.png

FILESV01_Vxrail4.0.301_20170829_156.png

 

リストアが完了したら起動します。MACアドレスの競合は、元のVxRail Managerが残っているので表示されています。

今回は無視で構いません。

FILESV01_Vxrail4.0.301_20170829_160.png

 

起動後、しばらくしてVxRail Managerのサービスが立ち上がれば、リストアしたVxRail Managerでも問題なくシステム状態が確認できます。(今回1ホスト停止いていますが、その状態も反映されているのが確認できます。)

FILESV01_Vxrail4.0.301_20170829_161.png

 

VxRail Managerのイメージバックアップからのリストアは以上です。

それほど難しくなく戻すことが可能です。

 

 

■ vCSAのリストア

 

vSAN上にvCSA自身が稼働していると、vCSAが起動できなくなるなど重大障害が発生した際のリストアにコツが要ります。

ポイントは以下となります。

 

  • vDPはvCenter自身がダウンしているとWeb ClientのvDPコンソールが利用できないため緊急リストアモードでESXiホストに直接VM(vCSA)を戻す必要がある。
  • しかし、vDPの緊急リストアモードでリストアする際にはESXiをvCenterから明示的に「切断」しなければならない。(C#のvSphere Clientではなく、HTML5のHost Clientでの実施を推奨)
  • さらにvDPの緊急リストアでvCSAをリストアしても、10G 2portでvDSが構成されるVxRailの場合、デフォルトの設定のままでは「vCenterがダウンしているとvDSの新規ポートアサインが出来ない」ので、リストア後のvCSAがネットワークに接続できない...orz
    • そのため、バックアップ編にも書きましたが、VxRailの運用時にはvDSに「短期バインド(Ephemeral Binding)」のvCSAリストア時用ポートグループを作成しておくことを推奨します。
  • 短期バインドのポートグループがない場合、vCSAをネットワークに接続するためにはvDSではなく、新規にvSSを作成し10G 2portのうちの片方をvDSから外しvSSに付け替えなければならない(DELL PowerEdgeモデルはNDCの1Gポートがあるので、上位スイッチ次第ですがそれを利用する事が出来るので復旧が楽です)。
  • vSSにvCSAを接続し、通信が可能になると再びvSANクラスタ、vDSがvCenter管理下になりますので、緊急リストア様にvCenter管理下から外したESXiをvCenterに際せず属し、vMotionで正常な他のホストに戻すことができます。
  • vCSAの移行後、vSSを削除し、vDSにポートを戻すことが出来ます(変に設定をいじったのが気になる場合はFRU用のイメージでホストを初期化してVxRail Managerでノード交換の手順で再追加という荒業も出来ますが、たぶん公式は非サポート)

 

テキストで書く複雑ですが、vCSA on 時分自身のvSAN with vDS の構成だと復旧時にこのような搦め手が必要です。

※PSCのみの障害の時は、緊急リストアこそ必要ですが、vCSAが生きているのでvDSに接続できるため、それほど手間はかかりません。

 

 

キャプチャ付きで以下説明します。

 

まず、障害を模す為にvCSAを停止します。

FILESV01_Vxrail4.0.301_20170829_166.png

 

Web Clientは利用できなくなりますので、仮想マシンのリストアのためにvDPのコンソールにアクセスします。

緊急リストアのタブを確認すると、今vDPがいるホストが確認できます。

FILESV01_Vxrail4.0.301_20170829_176.png

 

対象のESXiホストのHTML5 Host Clientにアクセスします(Host ClientはESXi 6.0u1以降で標準で組み込まれています)

FILESV01_Vxrail4.0.301_20170829_170.png

 

rootアカウントでログイン後、vCenterからの切断を実行します。

FILESV01_Vxrail4.0.301_20170829_177.png

 

※ここでC#のvSphere Clientにある「vCenter Serverからのホストの関連付け解除」は実施しない方が良いので、上記のHost Client側での操作を推奨します。

FILESV01_Vxrail4.0.301_20170901_001.png

↑ 何度も切り分けした訳ではないのですが、この操作は後が面倒になった事があるので避けた方が良いです。

 

Host Clientを利用してvCenterからホストを切断状態にします。

FILESV01_Vxrail4.0.301_20170829_178.png

 

この状態で緊急リストアが可能になります。

最新の正常なvCSAのバックアップを選択します。

FILESV01_Vxrail4.0.301_20170829_180.png

 

ホストのroot情報を入力し、インベントリ名をオリジナルから変更、リストア先のデータストアをvSANデータストアで指定します。

FILESV01_Vxrail4.0.301_20170829_181.png

FILESV01_Vxrail4.0.301_20170829_182.png

 

リストアが開始されます。

FILESV01_Vxrail4.0.301_20170829_186.png

FILESV01_Vxrail4.0.301_20170829_183.png

 

■ vCSA接続用の仮vSSの作成


正常運用時にvDSに「短期バインド(Ephemeral Binding)」のポートグループを作成していればリストア完了後、そのポートグループに接続することができますが、作成していない場合はvCSAがvDSのポートグループに接続できないので別途vSSを作成し、管理ネットワークを割り当てる必要があります。

※vCenterの管理下にないvDSに新規VMの接続は出来ないため、「接続中」のチェックが有効になりません。

FILESV01_Vxrail4.0.301_20170829_197.png

FILESV01_Vxrail4.0.301_20170829_198.png

 

vSSの新規作成とVMネットワーク ポートグループの作成、およびvDSから物理NIC(vmnic0)を剥がしてvSSに追加します。

※ESXi 6.0のHTML5 Host Clientだとこの辺りの操作がいまいちなので、この設定はC# vSphere Clientを利用します。

vCSAをリストアしたESXiホストのネットワーク構成からvDSを選び、物理NICを片方削除します。

FILESV01_Vxrail4.0.301_20170829_208.png

 

新規のvSSに剥がした物理NICを割り当て、管理ネットワークのポートグループを作成します(VxRailのデフォルトはNative VLAN = VLAN 0 です)

FILESV01_Vxrail4.0.301_20170829_210.png

FILESV01_Vxrail4.0.301_20170829_212.png

FILESV01_Vxrail4.0.301_20170829_213.png

FILESV01_Vxrail4.0.301_20170829_216.png

 

作成したvSSのポートグループにリストアしたvCSAを接続します。

FILESV01_Vxrail4.0.301_20170829_219.png

 

vCSAがネットワークに接続されればWeb Clientにアクセスが可能になります。

FILESV01_Vxrail4.0.301_20170830_002.png

 

■ vSANクラスタの正常化


この時点では緊急リストアで切断されたESXiホスト上にリストアしたvCSAや、稼働していたvDPが正しくインベントリに登録されません。

対象のESXiホストを右クリックして「接続」を実行します。

FILESV01_Vxrail4.0.301_20170830_004.png

FILESV01_Vxrail4.0.301_20170830_005.png

 

接続後、リストアしたvCSAと稼働していたvDPが確認できます。

FILESV01_Vxrail4.0.301_20170830_006.png

 

この状態まで復旧出来ればvCSAをクラスタ内の他のESXiホストにvMotionで移動可能です。

vMotionする際に、移行先ではvDSの管理ネットワークに付け替えます。

FILESV01_Vxrail4.0.301_20170830_008.png

 

移行が完了します。

FILESV01_Vxrail4.0.301_20170830_011.png

 

ここまで復旧できれば、一時的に作成したvSSの削除後、物理NICを再度vDSに割り当てが出来ます。

vDSにネットワークが戻った後はVxRail Managerの管理画面でも状態が元に戻った事が確認できます。

FILESV01_Vxrail4.0.301_20170831_041.png

 

以上が、一通り確認したvCSA障害発生から復旧までの一連の手順です。


本投稿の手順はメーカー側が公式で提示している手順ではないので、もしかしたら私が確認しきれなかった何等かのVxRail Manager関連で接続・構成の不都合などがあるかもしれません。

vSphere・vSANクラスタとしての正常化は可能なので、重要なシステムを保護する普段として参考にして頂ければと思います。

 

 

■ 参考

 

場合によっては最初に記したようにESXiホストをFRU用のESXiインストーラを利用して初期化して、ノード交換の手順で交換してきれいにしてしまうという事も出来るはずです。(恐らくメーカー非サポートの手順ですがシステムの正常復旧のための手段としては有りかと考えています。)


VxRail Managerを利用した故障ノードの交換手順は非常に簡単に、短時間でノード交換が可能です。

 

FILESV01_Vxrail4.0.301_20170830_023.png

FILESV01_Vxrail4.0.301_20170830_028.png

FILESV01_Vxrail4.0.301_20170830_033.png

 

以上、VxRailの管理系VMのバックアップとリストアについてでした。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRail のデータ保護、特にVxRail Manager や vCenter・PSCなどの管理系VMのバックアップ・リストアについて、現時点でメーカー公式には手順が公開されておらず、一部では "これらが壊れたら初期化してください" という情報が流れています。

 

さすがにそれはあり得ないので、VxRailを導入する上で管理系VMの保護はどのように実装したほうが良いかをご紹介します。

VxRailに限らず、vSAN上にvCenterが稼働している場合には、バックアップとリストアにコツが必要なので、参考にしていただければと思います。


※本項の内容はメーカーが公式にサポートを明言した手法ではなく、弊社で検証、正常動作を確認した内容となります。

 

※2018/04 Update:
2018/04現在のVxRailバージョンでは、VxRail Managerなどのバックアップ手順が公式にリリースされました。SolveDesktopなどの手順を必ず確認してデータ保護対策を実施してください。

 


後半のリストア編はこちら:VxRail 管理系VMのバックアップ・リストア方法【リストア・復旧編】

 

■ 今回の前提


  • VxRail 4.0.x で実施(次期バージョンVxRail 4.5はvSphere 6.5ベースとなり、vCSAのバックアップ関連が機能向上しているので、後日検証レポートを掲載予定です)
  • バックアップソフトウェアはvSphere Data Proteciton(vDP 6.1.4)を利用(2020年3月でEOAですが無償でVADP構成としてはシンプルなので)。基本的にVADPイメージバックアップをサポートするソフトウェアであれば同様の構成が可能です。
  • vDPには既知のバグを回避するワークアラウンドを適用(詳細は後述)
  • vDPは外部ストレージとしてDataDomainを利用(データ保護の基本は保護対象と異なる場所に保護データを格納する事)。
  • 2U4Nモデルを利用(10G 2ポートという縛りの中での復旧方法の説明のため。PowerEdgeモデルは1Gオンボードもあるので復旧はより楽になります)。
  • vCenterは組み込み型を利用(外部vCenterモデルより復旧が面倒が面倒なので)。
    • ただし、vSphere(vSAN)クラスタでVxRailのようにvDSのみの構成の場合、通常のvDSの設定運用のままではvCenter障害時に新たにデプロイしたvCSAがvDSに接続できなく、vSSを作るなどの必要があります。
    • そのため、あらかじめvDSに障害時のリストア用に「短期バインド(Ephemeral Binding)」の管理ネットワーク用ポートグループを作成しておいてください。見落としがちですが私は超推奨します。vDSとポートバインドの詳細はKBを参照してください(VMware Knowledge Base)
  • vCenter(vCSA)のPostgresDBはスクリプトでバックアップも実施。

 

 

まずはバックアップの環境作りから紹介します。

 

■ vDPの準備1(デプロイ)

 

vDPの展開はvDPの管理者ドキュメントに沿って進めてください。

ポイントはFQDNを事前にDNSで解決出来るように登録しておくことくらいです。

vCenterは外部PSCモデルでのセットアップです。

FILESV01_VxRail_BackupRestore_20170726_016.png

 

今回はバックアップデータを外部のDataDomainに配置するので、vDPのローカル重複排除ボリュームは最小容量の0.5TBで作成します。

FILESV01_VxRail_BackupRestore_20170726_018.png

 

CPUとメモリもデフォルトで組みます。4vCPUを割り当てれば6ジョブ並列まではこの構成で処理可能です。

FILESV01_VxRail_BackupRestore_20170726_020.png

 

基本のvDPデプロイが完了したら次はDataDomainの接続です。

FILESV01_VxRail_BackupRestore_20170726_029.png

 

DataDomainを接続する際には必ず以下の「チェックポイントコピーの有効化」にチェックを入れてください。

このチェックを入れておけばvDPアプライアンスが壊れても、DataDomainからバックアップカタログとデータの復旧が可能です。

FILESV01_VxRail_BackupRestore_20170726_032.png

 


■ vDPの準備2(バグ修正のワークアラウンド適用)


vDP 6.1.xにはvSAN上の複数のVMDKを持つVMバックアップにおいて、バックアップが失敗・ジョブステータスが92%で止まる、といった不具合があります。

幾つかVMware、EMCでKBが出ていますが、vDPアプライアンスのVADP動作モードで本来不要なSANモードを無効にする事で解決します。

※幾つかのKBで「NBDモード」にする、「対象VMと同じvSAN上にvDP Proxyをデプロイ」するなどの記載がありますが気にしないでください。vSAN上にvDPデプロイしてHotAddモードのみの設定でバックアップできます。


▼詳細は以下KBを参照

VDP 6.1.3 stops responding while VMs with multiple VMDKs on vSAN are backed up

 

https://kb.vmware.com/kb/2149101

VDP appliance crashes and reboots during backup when performing HotAdd for VMDKs located on vSAN storage

https://support.emc.com/kb/485349


VDP backup fails for vSAN VMs when multiple VMDKs are included in one backup job due to automatically selecting SAN mode

https://support.emc.com/kb/493844

 

▼ワークアラウンドの適用

vDPアプライアンスにSSHで接続して操作します

  1. ログインユーザーはadmin、パスワードはデプロイ時の管理者パスワード
  2. su - で rootに
    admin@cl2-vdp2:~/>: su -
    Password:<password>
  3. /usr/local/avamarclient/var/vddkconfig.ini ファイルの最後に vixDiskLib.transport.san.DisableVmCheck=0 を追記
    root@cl2-vdp2:~/#: printf "vixDiskLib.transport.san.DisableVmCheck=0 \n" >> /usr/local/avamarclient/var/vddkconfig.ini
  4. KBでは vmwareflr と avagent-vmware のサービス再起動とありますが、vDPを再起動すれば済むのでWeb Clientから再起動かけます。


これで多数のVMDKファイルで構成されるvCSA、VxRail Managerのバックアップも問題ありません。

 

 

■ vCSAのPostgresDBのバックアップ・リストア

 

vCSA、PSCともにvDPでVADPイメージバックアップを行いますが、DBはスクリプトを利用して簡単にバックアップが可能です。

イメージバックアップ時にDBの不整合が起きることは稀ですが、念のためDBを公式手順でバックアップしておきます。

※vCSA上でcron設置するなどで定期的に取得可能です

※vCenter 6.5以降はvCSAのVAMI(https://<vCSA>:5480/)コンソールからGUIでバックアップ設定が可能になります。

 

※詳細は以下KB参照

Back up and restore vCenter Server Appliance/vCenter Server 6.0 vPostgres database

Back up and restore vCenter Server Appliance/vCenter Server 6.0 vPostgres database (2091961) | VMware KB

 

  1. 上記KBからDLしたLinux用のスクリプトをvCSAにSCPなどでアップロードし、解凍・実行権も付与を行います。
    in-vcsa-cl2:~ # unzip 2091961_linux_backup_restore.zip

    Archive: 2091961_linux_backup_restore.zip

      inflating: backup_lin.py

      inflating: restore_lin.py

    in-vcsa-cl2:~ # chmod +x backup_lin.py

    in-vcsa-cl2:~ # chmod +x restore_lin.py


  2. バックアップスクリプトを実行します(-f で保存パス、ファイル名を指定)
    in-vcsa-cl2:~ # python /root/backup_lin.py -f /root/in-vcsa-cl2_vcdb.bk

    Backup completed successfully.

     

  3. 必要に応じて出力したバックアップファイルを別の場所(ファイルサーバなど)にコピーしておきます。

 

今回はvCSA自身にDBのバックアップファイルを格納し、バックアップファイルごとvDPでVADPイメージバックアップで取得します。

こうする事でイメージバックアップからの戻しで正しくサービスが立ち上がらなかった際に、バックアップデータからDBを復旧する事が可能です。

 

DBのバックアップを内部に持つことで、VMDKの容量が枯渇する場合がありますので、取得したDBサイズを見ながら必要に応じてVMDKのサイズを変更してください。

※参考KB

Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.0 (2126276) | VMware KB

https://kb.vmware.com/kb/2126276

 

■ vDPで管理系VMのバックアップの実施

 

Web ClientのvDP管理画面でバックアップジョブを作成します。

バックアップタイプは「ゲストイメージ」>「フルイメージ」を指定します。

FILESV01_Vxrail4.0.301_20170829_025.png

 

バックアップ対象のVMを指定します(今回はVxRail Manager、vCSA、PSCでそれぞれジョブを分けましたが一括でも構いません)

FILESV01_Vxrail4.0.301_20170829_026.png

 

同様の手順で、vCSA、PSC、VxRail Managerのバックアップジョブを設定します。

※vCSAはDBのバックアップをスクリプトで取得済みの前提です。

FILESV01_Vxrail4.0.301_20170829_032.png

 

vDP単体でも重複排除が効きますが、DataDomainと連携すると転送されるトラフィックも重複排除が猛烈に効いているのが確認できます。

以下のキャプチャは初回バックアップ時のDataDomain上のステータス確認時のものですが、一番左が取得している対象データ量、左から2番目が重複排除後のデータ量です。

毎秒100MB~200MBがvDP内で重複排除され、DataDomainには毎秒30MB前後で転送されているのが確認できます。

FILESV01_Vxrail4.0.301_20170829_038.png

 

これが2回目以降のバックアップではVADPのCBT(Change Block Tracking)が効き、データのスキャンも猛烈な速度でチェックされ、さらにDataDomainへ転送されるデータは殆ど発生していないのが確認できます。

重複排除バックアップの威力ですね。

FILESV01_Vxrail4.0.301_20170829_065.png

 

バックアップ取得が完了します。RPO24時間で指定する場合は日次でジョブをスケジュールしてください。

FILESV01_Vxrail4.0.301_20170829_081.png

 

バックアップ設定・取得に関しては以上となります。

vSAN上にAll in Oneで構成可能なVxRailですが、万が一のクラスタ全断障害に備えて、バックアップデータを外部の器(DataDomainなど)に保存してデータ保護の仕組みを確立する事がポイントになります。

 

■ 外部vCenter利用時のバックアップについて

 

外部vCenter時の保護もイメージバックアップとDBのスクリプトバックアップの組み合わせがお勧めです。

特に、外部vCenter自身が、他のvCenter管理下のクラスタにデプロイされている場合は、リストアの運用も容易になります。

 

■ 組み込みvCenterをDBのスクリプトバックアップだけでは構成できないのか?

 

DBのスクリプトバックアップはリストア時にはvCSAを再度デプロイし、DBを復元する必要があります(vCenter6.0の場合)。

この際に同一FQDN、同一設定で再デプロイしつつ、DBを戻せば基本的にvCenterの機能は復旧しますが、VxRail Managerとの証明書連携の再設定や、VxRail特有のDNSMASQサービスの再インストールなど手作業が発生してしまうためイメージバックアップの利用を推奨します。


■ vCSA復旧用にvDSに短期バインド(Ephemeral Binding)のポートグループを作成


前提条件の項にも書きましたが、vCSA on vSAN  + vDSの構成の時、vCenterが障害で利用できなくなるとvDSに新しいVMを接続できなくなるので、vCSA自体の再デプロイに備えて「短期バインド」のポートグループを作成しておきます。

Ephemeral Binding_002.png


 

後編のリストア編に続きます。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


興味本位でVxRail アプライアンスにベンチマークツールで高負荷を掛けている時にバージョンアップを仕掛けるとどうなるか、試してみました。

 

今回はDELLモデル 4ノード、外部vCenterを利用した構成です。

CPU負荷が90%~100%とサチった状態を作って、この状態でアップグレードを試してみます。

VxRail_VerUp_20170726_016.png

 

結果ですが、VxRail Managerのバージョンアップは成功しますが、次の段階でESXiホストのバージョンアップが「CPU usage」の警告でバージョンアップがストップしてしまいました。

 

VxRail_VerUp_20170726_036.png

上で動くVMを他のノードに退避出来ないので当然と言えば当然ですが、この辺りはしっかりとvSphere上のアラートをチェックしてストップをかけるようです。

高負荷を掛けている原因のVMを止めるなど、CPU利用率を落とした後に「再試行」をクリックすればバージョンアップは無事に完了します。

 

負荷の少ない業務後や夜間などにVxRailのバージョンアップを実施する事が多いとは思いますが、

一斉に走るバッチ処理や、月次のWindows Updateの処理と重ならないように注意したほうが良さそうです。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


今年に入ってだいぶ導入実績の増えてきたDELLモデルのVxRail 4.0ですが、アップグレード時に注意しておくべきことがあります。

 

DELLモデルの導入時や、その後のテストの後にノードの初期化(内部SDカードのイメージをRASRを利用して復元)した場合、

そのままの状態のESXiノードのアップグレードがエラーで失敗します。

ユーザーの方が簡単にバージョンアップを実施できるのがVxRailの良いところですが、エラーがいきなり出るとかなり萎えます...

 

エラーのメッセージは以下の様に長いので読むのは一苦労ですが、「/etc/rc.local.d/99.evobackup」の文言が見えたら今回の事象の可能性が高いです。

VxRail_VerUp_20170726_055.png

 

これは、RASRでの初期化に、ESXiのローカルのreserディレクトリと、ESXiの構成バックアップファイルが作成されないために、marvin VIBのアップグレード時の事前チェックに失敗するというものです。

/vmfs/volumes/DE*****-01-01-service-datastore1/reset/configBundle.tgz

 

※DE***** は、ノードのシリアルNo(PSNT)です。

※ configBundle.tgz ファイルはEVO:RAILの頃からあった2U4Nモデルの初期化用バックアップファイルです。


ワークアラウンドは、ダミーの configBundle.tgz をtouchコマンドで作ってあげることです。

SSHでRASRを実施したESXiにログインして、以下のダミーディレクトリとファイルを作成します。

 

mkdir /vmfs/volumes/DE*****-01-01-service-datastore1/reset

touch /vmfs/volumes/DE*****-01-01-service-datastore1/reset/configBundle.tgz

 

これでアップグレードは成功するはずです。

※アップグレード前にRASRを実施したことのあるノードには全てこの作業をしておくことが推奨されます。

 

公式KBは以下を参照してください。

https://support.emc.com/kb/501659

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRail 4.0.200で初期化したアプライアンスのセットアップと、ノード交換などの検証を行ってみました。

 

地味に良くなっていた点として、ESXiのホスト名の「連番のオフセット」と「ポストフィックス」が設定がセットアップ時に追加されました。

FILESV01_VxRail 4.0.200_20170530_011.png

今までは

vxesxi-01.rail.local, vxesxi-02.rail.local, vxesxi-03.rail.local, vxesxi-04.rail.local, ...

と1から連番でFQDNが設定されていたのが、

オフセット設定が可能になったので、05 から開始したり、ポストフィックスとして連番の後に文字列の追加が可能になりました。

vxesxi-05a.rail.local, vxesxi-06a.rail.local, vxesxi-07a.rail.local, vxesxi-08a.rail.local, ...

 

クラスタは別だが、ホスト名は連番で振り管理したい場合などは便利な機能改善です。

 

 

また、4.0.100以降でセットアップ済みのアプライアンスの各種設定変更が可能になったので、

ノード交換時に投入するパスワードに関しても但し書きが追加されています(英文のままでしたが)

FILESV01_VxRail 4.0.200_20170531_001a.png

 

6/6にESXi 6.0P05となるパッチもリリースされ、月末にリリース予定のVxRail 4.0.300でもいくつかの機能が乗ってくるようなので、

この秋にリリース予定のVxRal 4.5に向けて、HCIとしての機能が充実してきました。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


GW明けにDELL EMC World 2017に参加して、その後の累積した業務に追われてなかなか更新できなかったのですが、

VxRail 4.0.200 まわりのアップデート情報、検証した内容をまとめます。

 

今回の確認点は以下の4点。

 

・vSphere Standard Editionライセンス利用時の半自動でのVxRail アップグレードの実装

・iSCSI データストア利用時にも問題なくバージョンアップできるようになった。.

(https://support.emc.com/kb/495553、iSCSIの外部データストアをマウントした状態のホストがあるとVxRailのアップグレードに失敗する問題)

・vCenter 6.0u3から推奨となったPSCのメモリ4GBが反映されないVMware側のKnown Issueへの備え

・アップグレード時に失敗すると面倒なイメージプロファイルの欠落事象の事前チェック


後半二つは弊社の検証環境やお客様の環境で確認したアップグレード時のエラーの回避策と事前にチェックについてまとめました。

 

 

【vSphere Standard Editionライセンス利用時の半自動でのVxRail アップグレードの実装】

 

VxRail 3.5からvSphere Standardが利用可能になりましたが、DRSが使えないため、ローリングアップグレードや、メンテナンスのタイミングで暗黙の了解というか、手動でいろいろやる必要がありました。

今回の更新で、Standard利用時にもGUI上に適切な操作指示が表示されるようになりました。

FILESV01_VxRail4.0.2-StdLic_20170506_001.png

Standardはこのような機能がEnabledですが、DRSはありません。※vDSの機能ははvSANライセンスに紐づく。

今回はテストしたのは管理VMを除いて100VMの稼働する環境です。

 

FILESV01_VxRail4.0.2-StdLic_20170506_009.png

DLしてきた4.0.200のパッケージをアップロードして、更新を「続行」します。

 

FILESV01_VxRail4.0.2-StdLic_20170506_020.png

VxRail ManagerやvCSA、PSCはいつも通り順調にアップグレード。

続いてホストの更新に入ったタイミングで、次のメッセージが出力されます。

FILESV01_VxRail4.0.2-StdLic_20170506_026.png

やはり自動でvMotionはしてくれませんね、当然ですが…

ただ、以前はわからなかった「どのタイミグで、どのホストのVMをvMotionで逃がせばよいか」が明確に指示されるので割と便利になりました。

 

都度vMotionを手動で実行するのは面倒なのでPowerCLIでスクリプト組んでおくか、8ノード以上のクラスタで利用する場合はやはりEnterprise Plus相当のライセンスでDRSを有効にしておくことがお勧めです。

 

 

【iSCSI データストア利用時にも問題なくバージョンアップできるようになった】

 

iSCSIの外部データストアをマウントした状態のホストがあるとVxRailのアップグレードに失敗する問題<https://support.emc.com/kb/495553> が解決しました。

 

 

事前準備として、今回はVxRail 3.5のクラスタでSoftware iSCSIを有効化して、外部のUnityからiSCSiデータストアを接続しました。

※一般的なiSCSIの有効化ですが、ネットワークの構成によってPortBindを利用するか否かが違いますので、詳細は<ESX/ESXi でソフトウェア iSCSI ポート バインディングを使用する際の考慮事項 (2080447) | VMware KB>を参照ください。

FILESV01_Unity-VxRail_20170502_053.png

iSCSI Software Adapterが有効化されます。

FILESV01_Unity-VxRail_20170502_057.png

 

vDSにiSCSI用のポートグループを作成し、2つの10GbE NICにそれぞれ1つずつ割り当てます(チーミングを組まない)

FILESV01_Unity-VxRail_20170502_081.png

FILESV01_Unity-VxRail_20170502_082.png

FILESV01_Unity-VxRail_20170502_072.png

※iSCSIの場合はNICチーミングではなく、マルチパスで冗長化します。

 

今回の構成ではPort Bindを有効にしておきます。

FILESV01_Unity-VxRail_20170502_086.png

 

ここまで来たら、Unity側にVxRailのvCenterを登録し、UnityのUIからiSCSIデータストアを作成し、同時にVxRailにもマウントしてしまいます。

 

UnityのUIでVxRailの各ホストがリストされる事を確認し、

FILESV01_Unity-VxRail_20170502_098.png

Unityの「Vmware」タブからデータストアを追加します。

FILESV01_Unity-VxRail_20170502_099.png

 

FILESV01_Unity-VxRail_20170502_099.png

FILESV01_Unity-VxRail_20170502_099.png

VxRailの4ホストにチェックを入れれば、

FILESV01_Unity-VxRail_20170502_106.png

データストアの作成完了と同時に、

FILESV01_Unity-VxRail_20170502_118.png

VxRailのvCenter Web ClientからもiSCSIデータストアがマルチパスでマウントされている事がすぐに確認できます。

FILESV01_Unity-VxRail_20170502_124.png

 

iSCSIデータストア有のVxRail 3.5からVxRail 4.0.200へのアップグレード

 

上で作成したVxRail 3.5の環境から4.0.200へのアップグレードは、

いったんVxRail Managerだけ4.0.100に更新し、その後vSphere含めて4.0.200のコンポーネントに更新します。

 

FILESV01_VxRail3.5-4.0.2_20170427_005.png

VxRail Manager 4.0.100に更新後、VxRail 4.0.200のパッケージをアップロードします。

FILESV01_VxRail3.5-4.0.2_20170427_016.png

そこからは、今までのVxRail アップグレードと同様にPSC、vCenter、各ホストが更新され、iSCSIデータストアがマウントされていても問題なくアップグレードが完了しましたので、キャプチャは省略します。

 

【vCenter 6.0u3から推奨となったPSCのメモリ4GBが反映されないVMware側のKnown Issueへの備え】

 

VxRail 4.0.132からvCenter 6.0U3となっていますが、6.0U3以降ではPSCのメモリは4GBが推奨となります。

vCenterのリリースノートの既知の不具合にありますが、VxRailの環境でもPSCが推奨の4GBには自動で更新されないので、必要に応じて手動で更新する必要があります。

 

※弊社の作業した環境で、1件、アップグレード中にPSCが正しく再起動せず、再起動後もメモリ不足のアラートが出ていたものがありましたが、これは事後に4GBにメモリを増量することでアラートが消えました。

アップグレード作業で本件が不安な場合は、事前にリリースノートの以下の手順でメモリを増やしておくことを推奨します。

 

----

VMware vCenter Server 6.0 Update 3 リリース ノート

  • vCenter Server Appliance 6.0.x から 6.0 Update 3 へのアップデート中に Platform Services Controller のメモリが変更されない
    vCenter Server Appliance の Platform Services Controller を 6.0.x から 6.0 Update 3 にアップデートするときに、Platform Services Controller のメモリが変更されず、2 GB のままになります。
    • 回避策:この問題を回避するには、次の手順を実行します。
      1. vCenter Server Appliance 仮想マシンの Platform Services Controller をパワーオフします。
      2. 仮想マシンの [設定の編集] から、メモリ サイズを手動で増やします。
      3. vCenter Server Appliance 仮想マシンの Platform Services Controller をパワーオンします。

注:vCenter Server Appliance の Platform Services Controller は、フレッシュ インストールおよび 5.5.x から 6.0 Update 3 へのアップグレード時には、デフォルトで 4 GB のメモリを使用します。

----

※PSCのメモリを増量して起動後、vCenterとの通信がうまくいかない場合はvCSAも再起動してください。

 

一応、Communityで質問したところ、開発側のAlekseyさんからも解答をもらえました。

About PSC memory size on VxRail 4.0.200 (vSphere6.0u3a~)

 

 

【アップグレード時に失敗すると面倒なイメージプロファイルの欠落事象の事前チェック】


極稀にホストのアップグレード中に失敗する事象があります。

原因はよくわからないのですが、赤枠で囲った部分、ホストの「イメージプロファイル」が欠落している場合、アップグレードのVIBが適用できずに失敗してしましますので、

アップグレードの事前に全ホストの「イメージプロファイル」の状態は確認しておいた方が良いです。

※VxRail Managerでの事前チェックではここが確認されない。

FILESV01_VxRail4.0.2-StdLic_20170506_032.png

 

このイメージプロファイル(ESXiホスト内のimgdb.tgz)が壊れる事象のワークアラウンドはKB<https://support.emc.com/kb/494822>も公開されているのですが、

アップグレード中にエラーが出るのは心臓によくないので、事前にチェックしておいた方が吉です。

※手順はほかの健全はホストからimgdb.tgzをコピーして適用します。

 


※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



先週4/26に割と大きなアップデートを含んだVxRail 4.0.200がリリースされたので、よく問い合わせいただく4.0.200で何が変わったかを簡単にまとめたいと思います。

 

【 VxRail 3.5以降のコンポーネントのバージョン】

昨年末にVxRail 4.0.0がリリースされてから、このところのvSphere側の脆弱性対応やマイナーバージョンアップに対応する形でパッチが矢継ぎ早にリリースされていたので各バージョンの内容を整理します。

 

VxRail 4.0.132以降で、vSphere 6.0u3がベースラインとなっているなど、vSAN周りの性能向上や安定性向上が期待できるので、今日現在はVxRail 4.0.200へのアップグレードが強く推奨されています。

 

■VxRail 3.5

  • vSphere 6.0 Update2 (ESXi 6.0u2 + vCSA 6.0u2)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 3.5 (Marvin 3.5)

■VxRail 4.0 (メジャーバージョンアップ)

  • vSphere 6.0 Update2+ (ESXi 6.0p03 + vCSA 6.0u2)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0 (Marvin 4.0)

 

■VxRail 4.0.100 (VxRail 3.5から直接のアップグレード可能)

  • vSphere 6.0 Update2a (ESXi 6.0p04 + vCSA 6.0u2a)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0.100 (Marvin 4.0.100)

 

■VxRail 4.0.132 (VxRail 3.5からはVxRail Managerを4.0.100に更新してからアップグレード)

  • vSphere 6.0 Update3 (ESXi 6.0u3 + vCSA 6.0u3)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0.131 (Marvin 4.0.131)

■VxRail 4.0.200 (VxRail 3.5からはVxRail Managerを4.0.100に更新してからアップグレード)

  • vSphere 6.0 Update3a (ESXi 6.0u3a + vCSA 6.0u3a)
  • vSAN 6.2
  • vRealize Log insight 3.3.1
  • VxRail Manager 4.0.200 (Marvin 4.0.200)

 

【VxRail 4.0.200のエンハンスメント】

詳細はリリースノート(要Support EMCログイン)に記載がありますが、数が多いので個人的にこの更新は嬉しいなと思うものを以下まとめます。

特に気になった項目は太字にしています。

 

  1. VxRail Appliances deployed with an internal vCenter can be moved to an external vCenter.
    (詳細は試してみないとわかりませんが、組み込みのvCenterを外部vCenterとしてVxRailクラスタの外に出す事ができる?ってことでしょうか。詳細は別途調べてみます)
  2. vSphere Distributed Switch (VDS) のデフォルトポートグループ名の変更
  3. vSAN、vMotion用 VMkernelのIPアドレスの変更
  4. VDSのvCenterなどの管理ポートグループのVLAN変更.
  5. 組み込みのvCenter、PSCの管理パスワードの調整
    administrator@vsphere.local
    root@localos
    root@vCSA
  6. アップグレード時のコンパチチェックの最適化.
    (以前の投稿でも書きましたが、地味にアップグレード時にリトライで治るエラーが出て心臓によくなかった)
  7. vSphere Standard Editionライセンス利用時の半自動でのVxRail アップグレードの実装
    (先月の投稿の時にお伝えしたvSphere Std利用時の煩わしさがなくなります)
  8. Fixed Issue : VxRail cluster upgrade fails if cluster hosts are connected to iSCSI data store.
    (https://support.emc.com/kb/495553 にもありましたが、iSCSIの外部データストアをマウントした状態のホストがあるとVxRailのアップグレードに失敗する問題、これが治ったことが個人的に一番大きなポイントです)
  9. Fixed Issue : Physical view not recovered when PTAgent doesn't get host agentinfo one time.
    (これも地味にDELL版 PowerEdgeのアプライアンスでたまにHardware Viewの取得に失敗する事があって困っていたので早期に直って安心しました)

 

VxRail 3.0で昨年リリースされてから1年で4.0.200まで刻んできましたが、リリース当初はサポートされていなかった各種初期構成時のデフォルト値の変更や、柔軟な構成にも対応するように数々の改善が加わってきました。

来月のDELL EMC World 2017でも何か発表があるはずですし、vSphere 6.5がベースとなるVxRail 4.5の登場もそろそろなので、今年度もいろいろ情報を追っていこうと思います。

 

来週GW半ばあたりにiSCSiデータストアをマウントしたVxRail 3.5からVxRail 4.0.200へのアップグレードと、vSphere Standard Edtionのクラスタの「半自動」アップグレードの検証レポートをアップしたいと思います。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※VxRail 4.5など2018年時点でのバージョンでは、vSphere Standard Editionを利用した環境でのアップグレード時にもVxRail Manager上でvMotionを促すメッセージなどフォロー機能が実装されています。


VxRail 3.5以降でvSphere Standard Editionの利用が可能になりましたが、

現時点ではアップグレードやメンテナンスにおいて一部制限があります。

 

具体的にどのような点に注意するべきか、

VxRail で vSphere Standard Editionを利用した場合の設定・運用ポイントを紹介します。


大きく以下の点がvSphere Standard Editionでは制限されます

  • DRS、リソースプールなどのvSphere Enterprise Plus Editionの機能は使えません。
  • DRSが使えないので、VxRailのアップグレード時などのホストのメンテナンスモード投入、再起動を伴う動作時に自動で仮想マシンが退避されない → vMotionを手動で実施する必要がある。
  • その他はvSphereのライセンス差分程度。


Standard Editionでも利用できた事

  • vDSはVxRailに含まれるvSAN Enterpriseのライセンスで提供されます。
  • NIOCも使えました。これは意外。


※2017年3月時点のVxRail 4.0.100、4.0.132ベースでの情報ですので今後のバージョンで変わる可能性があります。

※本投稿用に検証したバージョンがお蔵入りしたVxRail 4.0.131というバージョンだったので投稿しようか迷ったのですが、関連するKBとリリースノートが正式に公開されたので改めて公開します。

以下、よく質問のあるvSphere Standard Edition利用時の運用イメージをまとめました。

 

■vSphere Standard Editionの適用

 

VxRailは初期セットアップ後はvSphereの評価ライセンスが適用されているので、機能はフル機能利用できます。

当然、DRSやResourcePool、NIOCなども利用できてます

※vDSはvSAN Enterpriseでも利用可能です。

FILESV01_VxRail 4.1.131_20170303_005.png

 

自社にはvSphere StandardのNFRライセンスがなかったのですが、vExpertの特典の評価ライセンスにStdが含まれていたので今回はこれを利用しました。

当然、現在の利用中の機能が制限されると警告があります。

FILESV01_VxRail 4.1.131_20170303_006a.png

 

vSphere Standard 適用後、DRSが利用不可になるのでResourcePoolが削除され、インベントリに作成済みの仮想マシンが大量に並んでしまいました。

FILESV01_VxRail 4.1.131_20170303_012.png

■vSphere Standard Edition + vSAN Enterpriseでも利用可能な機能


vSphere StandardでDRSなどは制限されてしまいましたが、vSAN ライセンスが提供する機能にvDSが含まれるため、vDSは残っています。

今回初めて気づいたのですが、NIOCもどうやら継続して利用できるようです。無効化→有効化を試しても問題ありませんでした

ライセンスガイドなどにもNIOCはvSphere Enterprise plusに付いてくる機能とあるのですが、どうやらvSAN EnterpriseでvDSが利用できる環境であればNIOCも使えるのかもしれません。

FILESV01_VxRail 4.1.131_20170303_014.png


NIOCのシェア値もそのまま残っています。

FILESV01_VxRail 4.1.131_20170303_013.png

 

■vSphere Standardが適用されたVxRailのアップグレード


vSphere StandardではDRSが無効になるので、ホストのメンテナンスモード投入 → 他のホストに仮想マシンのvMotionによるオンライン移行が利用できません。

そのため、アップグレード中にホストの再起動が行われる際には、管理者が手動で仮想マシンの退避を行う必要があります。

 

※通常のアップグレード時の作業内容は過去投稿を参照ください。

 

 

VxRail Managerがアップグレード実行前にシステムのチェックを実施しますが、この際にvSphere Standardが適用されている場合は、ワンクリックアップグレード機能が実行できないので以下のような警告が表示されます。

FILESV01_VxRail 4.1.131_20170303_033.png

vSphere Standardの当たっている環境のアップグレード時には、以下のKBに沿ってアップグレード時のプリチェックを無効化する必要があります(パートナーレベルのKBなのでURLのみ記載します)

「VxRail: How to bypass upgrade pre-check」

https://support.emc.com/kb/493135

 

上記KBの内容を実行すると、プリチェックが除外されるのでvSphere Standerd Editionでもアップグレードが続行されるようになります。

 

★ここからがなかなか面倒です。

ホストがNode1からアップグレードが開始されますが、DRSが利用できないStandardでは毎回ホストのメンテナンスモード投入時に仮想マシンを手動で移動しなければなりません。

 

VxRail Manager上では各ホストのメンテナンスモード投入タイミングで「アップグレード時のPythonフック」表示で待ちになります。

FILESV01_VxRail 4.1.131_20170303_043.png


Web ClientでvCenterに接続し、Node1上のパワーオンの仮想マシンをvMotionでほかのホストに移動します。

FILESV01_VxRail 4.1.131_20170303_034.png


ホスト上の仮想マシンが空になると、

FILESV01_VxRail 4.1.131_20170303_036.png


Node1がメンテナンスモードに投入されるとアップグレードが続行されます。

FILESV01_VxRail 4.1.131_20170303_046.png


アップグレードのVIB適用後、ホストも再起動されます。

FILESV01_VxRail 4.1.131_20170303_045.png

Node1のアップグレードが終わると、次はNode2の処理が開始されるので、Node2上の仮想マシンの他のノードに退避させ、同様の操作を全ノード数分実行します。


※どのバージョンからどのバージョンにアップグレードするかによっても変わると思いますが、

1ホストあたりvSphereの差分VIBと、VxRailのエージェント(MARVIN)のVIBのインストール時にそれぞれ再起動が走ります。


最終的に全ノードの更新が完了しますが、やはりDRS機能の有無の差は非常に大きい印象です。

個人的には3ノード、4ノード構成などの最小構成以外はEnterprise plusで設計・導入する事が運用的にも強く推奨されるべきと考えています。

FILESV01_VxRail 4.1.131_20170303_068.png

■VxRail 4.0.131 の問題について

4.0.131は2017年3月上旬にリリースされましたが、すぐに4.0.132に差し替えられました。

4.0.131と132の違いは、vSphere ESXiに含まれるLSI SAS HBAのドライババージョンがvSAN HCL DBの更新を待たずに先行で131のバイナリには含まれていたため、vSAN Health Checkでも警告が出力されてしまいます。

 

詳細は以下KBに掲載されていますが、2017/3/23にVmware社のvSAN HCL DBが更新されvSAN警告は非表示となりました。

VxRail: vSAN Health page warning on LSI driver in 4.0.131 on Quanta appliance

https://support.emc.com/kb/497029


3/22以前のvSAN HCL DBだとドライバの互換警告が出ていましたが、

FILESV01_20170405_002.png

FILESV01_20170405_001.png


3/23移行のDBに更新すると、

FILESV01_20170405_004.png

グリーンに戻ります。

FILESV01_20170405_003.png

 

■まとめ

2017年3月時点ではVxRailをvSphere Standardで利用した際に、以下の点に注意が必要です。

・DRS、Resource Poolなどの機能が使えなくなる

・ホストのバージョンアップ時には、手動で別ホストへ仮想マシンの移動が必要となる。全ノード分なのでしんどいと思います。


NIOCはそのまま利用できるようです。


※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



VxRail 4.0からはVxRail Managerがインターネットにアクセスできる環境にある場合は、

VxRail ManagerのUIから直接アップグレード用パッケージをダウンロードし、パッチの適用が可能になりました。

先週、VxRail 4.0.100というマイナーバージョンがリリースされたので、どのようなものか試してみました。

 

ちなみに、それぞれのバージョンの中身は以下となります。

 

■VxRail 4.0.0

  • VMware vCenter Server Appliance 6.0.0 build-3634794 (6.0u2)
  • VXRail Manager 4.0.0-4631184
  • VxRail Manager VIB 4.0.0-4631184
  • VMware ESXi 6.0.0 build-4192238 (6.0p03)

 

■VxRail 4.0.100

  • VxRail Manager 4.0.100-4907696
  • VxRail Manager VIB 4.0.100-4907696
  • VMware vCenter Server Appliance 6.0.0 build-4541948 (6.0u2a)
  • VMware ESXi 6.0.0 build-4600944 (6.0p04)

 


以下、実際にVxRail Managerを利用したインターネット経由のアップグレードを試してみました。


新しいアップグレードが可能になると、UI左側のメニューに赤①のマークがつきます。

21.png

 

最新バージョンと現在のバージョンが確認できます。

22.png

23.png

 

「インターネットアップグレード」のボタンをクリックすると、VxRail ManagerがSupport EMCにアクセスし、

VxRail Manager用のアップグレードバイナリと、vSphereのパッケージ(vCSA 6.0.u2a + ESXi6.0P04)がダウンロードされます。

29.png

※軽い気持ちでDLを開始すると、合計4GBくらいのパッケージのDLが始まりますのでご注意ください。

 外部回線が細い検証環境で試したら3時間くらい掛かってしまいました...

 

ちなみにVxRail Managerにダウンロードされたファイルは[ /tmp/lcm ]に置かれます。


VxMng:/tmp/lcm # ls -alh

total 2.9G

drwxr-xr-x  3 tcserver pivotal 4.0K Feb  1 16:48 .

drwxrwxrwt 54 root     root    4.0K Feb  1 17:24 ..

-rw-r--r--  1 root     root   2.9G Feb  1 16:48 VXRAIL_COMPOSITE-4.0.100-4907697.zip  ← vSphere6.0u2a関連のパッケージ

drwxr-xr-x  3 tcserver pivotal 4.0K Feb  1 16:48 unpacked

 

 

VxMng:/tmp/lcm/unpacked/bundles # ls -alh

total 859M

drwxr-xr-x 2 tcserver pivotal 4.0K Feb  1 16:49 .

drwxr-xr-x 3 tcserver pivotal 4.0K Feb  1 16:48 ..

-rw-r--r-- 1 tcserver pivotal 858M Feb  1 16:48 VXRAIL_Manager-4.0.100.00000-4907696-updaterepo.zip ← VxRail Managerのパッケージ

 

 

ダウンロードが完了したら「続行」

30.png

 

アップグレードに必要な各コンポーネントの管理者アカウント情報を入力して続行します。

FILESV01_VxRail_ResourcePool_20170201_035.png

VxRail Managerの更新から始まります。

ここで一度VxRail Managerが再起動されるのでセッションが切れるようです。

 

FILESV01_VxRail_ResourcePool_20170201_039.png

 

ここで打ち合わせが入っていたので、ほったらかしにして2時間後くらいに再度ログインしてみました。

エラーで失敗してました...

FILESV01_VxRail_ResourcePool_20170201_040.png

 

KB488890を見よ、と記載があるのので確認すると、事前にチェックしておくべき項目(DRSが有効か?メンテナンスモードにしてないか?など)がいくつかありましたが、とりあえず検証環境ですし「Retry」ボタンがあったので軽い気持ちで再チャレンジ。

※本番環境のときも、エラーのときは現状維持で待機しているはずなので、慌てずエラーの内容を確認してEMCかパートナーに連絡してください。

42.png

 

今度はうまく進んでいました。

打ち合わせで途中の確認は飛ばしていたのすが、VxRail Managerの再起動後、vCSAとPSCの6.0u2aパッチ適用、各ホストへのP04パッチ適用が順次進んでいました。

FILESV01_VxRail_ResourcePool_20170201_052.png

 

あとは眺めているだけで、各ホストのバージョンアップ含め、すべてのコンポーネントが更新されました。

やっぱり便利ですねこの機能。

FILESV01_VxRail_ResourcePool_20170201_058.png

 

アップグレード直後は「監視抑制モード」モードでしたが、しばらくすると通常モードに戻ります。

FILESV01_VxRail_ResourcePool_20170201_060.png

 

ちなみに、vCSA 6.0u2aにアップグレードしたことで、vSAN HCL DBの情報がリセットされてしまう様でしたので、

アップグレード直後、以下のようにクラスタ稼働状態が「エラー」となってしまいます。

FILESV01_VxRail_ResourcePool_20170201_062.png


vSAN HCL DBを更新すればよいので、Web Clientのクラスタ管理画面でvSAN HCL DBを更新してください。

※インターネット経由のアップグレードした環境であれば即時更新可能です。

63.png

 

vSAN HCL DBを更新すれば、vSANヘルスチェックもOKになるのでvSANのアラームも解除で問題ありません。

FILESV01_VxRail_ResourcePool_20170201_064.png

 

以上、VxRail 4.0から利用可能になったインターネット経由でのアップグレード機能でした。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



2016年末にリリースされたVxRail 4.0から、従来の2U4NのQuanta製ハードウェアに加え、DELL製ラックマウントサーバをベースとしたモデルがラインナップに加わり、CPU、メモリ、ドライブ構成の他、ネットワーク構成の選択の幅も増え、より多くのお客様の要望、要件に対応できるようになりました。

 

今回は初期構成時のネットワークの組み方や、拡張時の制限など幾つかおさえておくポイントがありますので、以下にまとめたいと思います。

※あくまで私の所属する組織(NetOneSystems)で整理した情報となりますので、提案時の詳細確認や機能証明はDELL EMC社へのSRを上げてください。

※2017年1月31日時点で確認した情報となります。


※2017年4月11日に、DELLモデルのVxRailノードのPCIe追加NICの構成がオンボードNDCの10GbE形状と異なるRJ45 or SFP+で選択可能になった事を追記しました。

 

 

【VxRail 4.0の構成基本ルール】

  • 拡張時はVxRailソフトウェアバージョンが一致している事(VxRail 3.5 に VxRail 4.0のソフトウェアバージョンのノード拡張は不可、事前に3.5→4.0にバージョンアップしておく)
  • 異なるVxRailモデルの混在は可能(Gen2とGen3の混在、Quantaモデル、DELLモデルの混在など)
  • Virtual SANの基本ポリシーとして明らかに異なるパフォーマンスの混在は非サポート(1GbEと10GbEの混在、ハイブリッドとオールフラッシュの混在は不可)
  • VxRailとしての拡張はサポートしている構成であっても、容量・ドライブ性能が大きく異なるノードは全体のアンバランスとなるため、vSANのベストプラクティスとしてはなるべく避けた方がよい(Eシリーズ 8台の中にSシリーズ1台だけ拡張、など)

 

【ネットワーク構成のルール】

  • VxRailのノード拡張は同一ネットワーク速度の構成のみサポート。
    • 1GbEモデルと10GbEモデルの異なるネットワーク速度のノードの混在は不可(10GbE * 2ポートモデル と 1GbE * 4ポートモデルの混在NG)
  • 上位のスイッチがサポートしていればSFP+モデル(10G-SR)とRJ45モデル(10G BASE-T)の混在は可能
  • 1GbE * 4ポート構成はGシリーズ、Eシリーズ、Sシリーズのシングルプロセッサ構成 かつ RJ45モデルでのみサポート。
    • Eシリーズ、Sシリーズはオンボードの10G BASE-T * 2ポート + 1GbE * 2ポートの4ポートで構成され、10GbEポートは1GbEでリンクします。
  • シングルプロセッサ構成のEシリーズ、Sシリーズには追加の10GbE NICは搭載不可(オンボード10GbE NICのみ利用可能)

 

【ドライブ構成のルール】

  • ハイブリッドモデルとオールフラッシュモデルの混在拡張は不可(Virtual SANの仕様)。
  • シングルプロセッサ構成はハイブリッドモデルのみをサポート。
  • オールフラッシュモデルはデュアルプロセッサ構成、10GbEネットワーク構成のみをサポート。
  • 2U4Nモデル(Gシリーズなど)にドライブ追加する場合は、シャーシ筐体内の各ノードのドライブ構成は均等に追加する事。

 

【拡張時の制限・上限のルール】

  • 初期の4ノードは同一モデル・構成で組む
  • 1GbEモデルは最大8ノードまでの拡張が可能
  • 10GbEは最大64ノードまでの拡張が可能(33ノード以上の構成時はEMCへの構成確認の申請が必要)

 


それぞれ、文字だけだと分かり難いので簡単なイラストで説明します。

 

まずVxRailの拡張について、2U4Nのアプライアンス以外のモデルでも初期の4ノードは同一構成で組むことが求められます。

※5ノード以降は任意のモデルノードで拡張可能。

VxRail_Expand-01.png

 

初期構成に拡張のノードを追加すると、vSphereクラスタ(vSANクラスタ)が自動で拡張され、vSANのストレージ容量もオンラインで拡張されます。

VxRail_Expand-02.png

 

拡張がサポートされるのは、同じvSAN構成のノードのみです。

VxRail_Expand-03.png

VxRail_Expand-04.png

ハイブリッドとオールフラッシュの混在拡張、1GbEモデルと10GbEモデルの混在など、

パフォーマンスの違いが大きいノードを拡張する事はできません。

VxRail_Expand-05.png

VxRail_Expand-06.png

ノード単位での拡張は、初期の4ノードは同じ構成とする必要があります(Gシリーズならばシャーシスロットを全て埋める)

VxRail_Expand-07.png

5ノード以降は、任意のモデルを追加可能です。

※ただし、2U4Nモデルの場合は、同一シャーシ内の各4ノードは同一構成とする必要があります。

VxRail_Expand-08.png

SSD・HDDに空きスロットの余裕がある場合はオンラインで拡張可能です。

※ただし、2U4Nモデルはシャーシ内の各ノードで同一構成にそろえる必要があります。

VxRail_Expand-09.png

VxRail 4.0から登場したDELLサーバモデルは、オンボード ドーターカードにて

標準で10GbE 2ポート + 1GbE 2ポートが実装されています。

購入時にRJ45(10G BASE-T)モデル、またはSFP+(10G-SR)モデルを選択可能です。

※初期セットアップ時に利用しないオンボード1GbEは、EMCに申請(RPQ)を上げる事で、セットアップ後に仮想マシン用途などで利用可能。

VxRail_Expand-10.png

※DELLサーバモデルで1GbE * 4ポートの構成で組む場合は、Eシリーズ、またはSシリーズのシングルプロセッサ構成のRJ45モデルでのみサポートされます。

 

2CPU構成のDELLサーバモデルは、追加のPCIe デュアルポート 10GbE NICを装着可能です。

追加NICのインターフェースは、オンボードの10GbE NICの形状と同一のものとなります。

追加PCIe 10GbE NICの形状は、2017年4月のアップデートからオンボードNDCの形状と異なるものも選択可能となりました。


※初期セットアップ時はオンボードの10GbEでセットアップし、初期セットアップ完了後に任意の仮想マシンネットワークなどで拡張PCIe NICを利用可能です(拡張10GbEの利用時はRPQは不要)。

VxRail_Expand-11.png

追加PCIe 10GbE NICの形状は、2017年4月のアップデートからオンボードNDCの形状と異なるものも選択可能となりました。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


※本記事は2016年時点のVxRail 4.0での問題でしたが、その後のバージョンアップで改善しておりますので過去の情報として参照ください。



VxRail Managerを利用したクラスタの全シャットダウンは非常に便利な機能なのですが、

このシャットダウンのフローの中でクラスタの「DRS」が無効にされます。

 

DRSを無効にする事で、次回起動時に管理VMがノード1に集まっている状態で起動できるようにするための仕様なのですが、

DRSが無効になると「リソースプール」が全て削除されてしまいます。

 

仮想マシンのリソース割り当てをコントロールするためにも重要な機能ですし、

沢山の仮想マシンを用途ごとにまとめるフォルダとして利用される場合もありますので、

これが意図せず削除されてしまうと設定の戻しは非常に面倒です。

 

これを防ぐためには、

クラスタ全シャットダウンの前に、DRSを手動で無効化し、DRS設定のスナップショットを保存しておくことが必要です。

※全シャットダウン時とは別に、定期的にスナップショットを保存しておく事が推奨です。

 

以下、DRS リソースプールスナップショットの取得方法をご紹介します。

 

【通常のクラスタ全シャットダウン手順】

Shutdown_01png.png

クラスタのシャットダウンボタンを押します。

計画停電時や、機器の移設時に便利な機能です。

 

FILESV01_VxRail4.0_Upgrade_20161207_075.png

「確認」を押します。

Shutdown_02png.png

最初のステップで無慈悲にDRSが無効化されるので、リソースプールは残念ながらすべて削除されます

 

次回起動時にリソースプールが無い!と慌てないように、クラスタ全シャットダウンの前に、手動でDRSを無効化してスナップショットを取得しておきましょう。

 

 

【リソースプールのスナップショットの取得方法】

Shutdown_03.png

クラスタの管理ViewでvSphere DRSの「編集」ボタンをクリック

 

Shutdown_04.png

「vSphere DRSをオンにする」のチェックを外し、「OK」。

 

Shutdown_05.png

ここでリソースプールがクラスタに存在すると、リストア用のスナップショットを保存するかどうか確認されるので必ず「はい」を選択する。

 

Shutdown_06.png

スナップショットはvSphere上ではなく、Web Clientを開いているクライアントPC上にファイルで保存されます。

無くさないように、定期的に管理者が利用するファイルサーバなどに保存することをお勧めします。

スナップショットがあればリソースプールを間違って消してしまったり、違うリソースプールに仮想マシンを間違って移動してしまった場合にも一瞬で戻せるので重宝します。

 

 

【リソースプールスナップショットのリストア方法】

クラスタの再起動後、削除されてしまったリソースプールをスナップショットからリストアするには、

「クラスタ」を右クリックし表示されるメニューで「リソースプールツリーのリストア」を選択します。

Shutdown_07.png

 

すると以下の画面が表示されるので、保存していたスナップショットファイルを「参照」から選択します。

shutdown_08.png

「OK」を押せばリソースプールは仮想マシンの配置も含めて一瞬で元通りとなります。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


VxRailに限らずvSphereを導入する際、必ずvCenter、ESXiともに参照先DNSサーバの設定が必要となります。

※DNSサーバと合わせてNTPサーバの設定も重要です。

 

vSphere 6.x以降のWeb Clientを利用したことのある方は恐らく気付く動きですが、

Web ブラウザにvCenterのIPアドレスを打ち込んでWeb Clientを開いた場合も、必ずSSOが動作するPSCサーバに対してFQDNでブラウザ画面がリダイレクトされて認証連携されます。

仮想マシンコンソールが開かない、プラグインが正しく動作しない、といった場合もDNSの参照が正しく動作していない場合にみられる事象です。

 

それ以外にもvSphere 6.x以降では各コンポーネント間がSSOで連携する際に裏ではFQDNでお互いが参照されていますので、NSX、vRA、vDPなどコンポーネントの導入時もそれぞれがFQDNで名前解決できるようにする必要があります。

 

当然、VxRailでもDNSサーバの設定は重要となってきます。

VxRailには2つのvCenterのモード、VxRail 組み込みのvCenter、PSCを利用するモードと、お客様が利用している既存のvCenterを利用する外部vCenterモードがあります。

それぞれのモードで、各コンポーネントのDNS参照先が異なるので、以下イラストで説明します。

 

 

【組み込みvCenter、PSC利用時】

まず、VxRailにデフォルトで組み込まれているvCenterを利用する場合のDNS参照の向きです。

ここでポイントになるのは、VxRailではLinuxベースのvCSAに「dnsmasq」と呼ばれる簡易DNSサーバサービスをインストールして、

vCenter、PSCをそれぞれDNSサーバとして動くように設定します。

これにより、もし外部のDNSサーバが利用できない場合でも、VxRailのコンポーネント間でのFQDNの通信は可能となるので、

隔離環境でDNSサーバを用意できない場合でも、VxRailのセットアップ、利用は可能となります。

 

embedded_vcsa_vxrail.png

※VxRail 初期セットアップ時に実行される事前検証(Validation)時に、その時点でアクセスできないDNSが設定されていると検証が失敗するので、隔離環境でセットアップする際はセットアップウィザードのDNSサーバ欄は空欄としてください。

後々、外部のDNS参照先を設定する際はdnsmasqサービスが参照しているフォアーダ先のDNSサーバを設定変更する事が可能です。

 

dnsmasqサービスの設定変更については以下KBが公開されていますので参照願います。

▼VxRail: How to modify the DNS server IP address for VxRail after the initial configuration

https://support.emc.com/kb/492132

 

※上記以外にも、VxRail Managerのコンフィグファイルの値も別途修正しておく必要がありますが、詳細手順は正式には公開されていないのでSRを上げてサポートを依頼してください。

参考までにどの様な箇所の変更が必要かかはVxRailのDNS、NTP、Syslog設定変更 にコメントしていますのでご確認願います。

 


【外部vCenter利用時】

VxRail 3.5以降ではお客様がお持ちの環境に用意されたvCenter配下にVxRailの各ESXiを追加可能です。

外部vCenterを利用する際はvSphere 6.0u2以降であること、空のデータセンター、何も設定していない管理用アカウントの作成などいくつか条件があります。

vSAN Stretched Clusterなどを検討される場合は外部vCenter構成が必須です。

 

外部vCenter利用時はdnsmasqサービスはインストールされないため、

vCenter、PSC、ESXi、VxRail Managerの各コンポーネントは必ず事前に用意された外部DNSサーバを参照する形となりますので、

事前に各コンポーネントがFQDNで名前解決できるようにレコードを登録してください。

external_vcsa_vxrail.png

外部vCenter利用時のDNSサーバ参照先の矢印はすべて外部DNSサーバに向いているので、外部DNSサーバの可用性は重要になってきます。

 


【FQDN、ホスト名の設定の重要性】

VxRailをセットアップ完了後、ホスト名を変更したい、ドメイン名を別のものにしたい、という要望がたまにありますが、

基本的にこれらはサポートされず、VxRailの初期化を伴う再セットアップが必要となります。

 

WebUIで気軽にセットアップが可能なVxRailですが、ホスト名やIPアドレスなど重要なパラメータは事前にしっかり設計する必要があります。

 

▼VxRail: How to change hostname of each components in VxRAIL

https://support.emc.com/kb/486258

VxRAILとしては上記のKBがありますが、実際にはvCenter Serverの仕様によって変更が困難となります。

 

※関連KB:

▼vCenter Server または Platform Service Controller の IP アドレスまたはホスト名を変更するとサービスで障害が発生する (2139374)

https://kb.vmware.com/kb/2130599

----

vCenter Server または PSC の Primary Network Identifier (PNID) を変更することは現在サポートされておらず、そうすると vSphere サービスが起動に失敗します。

vCenter Server または PSC が PNID として FQDN または IP を使用してデプロイされている場合、この構成を変更することはできません。

 

この問題を解決するには、次のいずれかのオプションを使用します。

•IP アドレスまたはホスト名を変更する前にスナップショットまたはバックアップに戻す。

•vSphere 環境を再デプロイする。

----

 

▼VMware vCenter Server Appliance 6.0 の IP アドレスを変更しようとすると次のエラーで失敗する: このノードの IPv4 構成 (nic0) は、デプロイ後に編集することはできません。 (2132705)

https://kb.vmware.com/kb/2132705

 

 

【おまけ】

DNSサーバに次いで重要となるNTPサーバも、初期セットアップ後に設定を変更する場合のKBが公開されていますので、

変更する場合は以下のKBを参照願います。

 

▼VxRail: How to change NTP server after VxRail is built

https://support.emc.com/kb/493891

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


EVO:RAILのころから直近のVxRail 3.5までは、2U4Nのアプライアンス型で アップリンクのネットワークが10GbE * 2Port固定(または1GbE * 4Port)でしたが、 VxRail4.0ではDELL HWモデルが加わり10Gの追加ポートでの構成が可能になったため、 従来のvMotionネットワークの帯域制御や、VSANネットワークのAct-Stbのアップリンクをテレコに組んでのトラフィックの分散していたパターンから、vSphereの機能であるNetwork IO Control v3(NIOCv3)での帯域制御に切り替わりました。

何がどう変わったか、実機の画面キャプチャを交えてご説明します。

■VxRail 4.0のNIOCv3のデフォルト設定値

まずはVxRail 4.0での各物理NICポートとポートグループの冗長の組み合わせと、NIOCシェア値は以下のようになります。

■1GbE * 4Portモデル

トラフィックタイプUPLINK1(1Gb)UPLINK2(1Gb)UPLINK3(1Gb)Uplink4(1Gb)NIOCシェア値
ManagementStandbyActive--40
Virtual MachinesActiveStandby--60
vMotion--StandbyActive50
vSAN--ActiveStandby100

■10GbE * 2Portモデル

トラフィックタイプUPLINK1(10Gb)UPLINK2(10Gb)UPLINK3(1Gb)UPLINK4(1Gb)NIOCシェア値
ManagementActiveStandby--20
Virtual MachinesActiveStandby--30
vMotionActiveStandby--50
vSANStandbyActive--100

※追加の10GbE * 2Portの構成は、初期セットアップ後に新規のvDSを作成し接続する事で任意の利用が可能の様です。
※ 2017/1/16 現在では、DELL EMC公式には未サポートの様ですが、vSphere FT 6.0など、専用の10GbEのネットワークを用意する必要がある機能も、DELL HWを利用して追加10GbE NICがあればFT 6.0 + vSANも VxRailで組むことが可能になるのではと考えています。  

■VxRail 3.5 実機でのvDS設定

まずはVxRail 3.5の画面を確認します。

VxRail3.5-4.0_Upgrade_20170113_008.png

VxRail 3.5のvDS(分散スイッチ)の名称は懐かしのEVO:RAILの名前が残っています。
そしてNIOCは無効です。

VxRail3.5-4.0_Upgrade_20170113_010.png

NIOCは無効なのでシェア値もデフォルトのままです。

VxRail3.5-4.0_Upgrade_20170113_012.png

その代わり、vMotionなどバーストトラフィックが発生しやすいものは、vDSの機能を利用してIn-Outで4Gbpsに帯域制御をかけていました。

■ VxRail 4.0のNIOCv3の設定値

VxRail 4.0を新規にセットアップするとNIOCが有効となり、以下の設定値がデフォルトで投入されます。また、4.0ではvMotion Networkに設定されていた帯域制御は削除されています。
※実機で検証したところ、VxRail 3.5から4.0へのアップグレードした場合は、NIOCは有効とならず、以前のvMtion Networkの帯域制御が有効のままなので、必要に応じて手動でNIOCの設定を投入することとなる様です。

VxRail4.0_NW_20170111_001.png

VxRail 4.0でのvDSの設定はNIOCがデフォルト有効になっています。
また、以前かラの設定ですが、隣接スイッチの検出プロトコルはデフォルトのCDPなので、Cisco以外のスイッチを利用の際はLLDPに変更可能です。

そして大したことではないのですが、今まで「EVO:RAIL Distributed Switch」だったvDSの名称が「Vmware HCIA Distributed Switch」に変更となってしまいました。
VxRail 3.5からアップグレードされた場合はvDSの名称は変わらないので、EVO:RAILの名前に愛着がある方はそのままの利用をお勧めします。

VxRail4.0_NW_20170111_006.png

VxRail 4.0の機能向上の本命のNIOCの設定画面は上記のようになっています。

重要な点は「シェア値」の設定であって、「予約」や「制限」ではないので、帯域に余裕があるときは各ネットワークが必要な分だけトラフィックを流すことが出来る事です。

 

HCIとして、ポリシーベースの制御がネットワークでも実装されるようになったことは非常に有益なことだと思います。

これに加え、VxRail Gen3 ハードウェアとしてリリースされたDELL HWベースのノードは10GbE NICを追加して、10GbE * 4ポート構成も可能なので、外部ストレージやvSphere FT、Stretch Cluster用の専用ネットワークなどいろいろな用途に対応できるようになるので、エンジニアとして非常に楽しみな製品だと感じています。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。

 

VxRail 4.0で故障したドライブの交換操作が非常にやりやすく、親切になったのでご紹介します。

 

【確認できたVxRail 4.0でのドライブ交換の機能向上点】

  • ドライブ交換時にホストの再起動が不要になった(今まで再起動を要していたのが地味に嫌でした)
  • 取り外したドライブがアクティブな状態のときはパーティションを飛ばしてくれた
  • 装填したドライブにパーティションが存在すると警告を出してくれる(間違ってデータのあるドライブを挿した時のフェイルセーフ?)
  • とにかく簡単で早かった

 

■ドライブ交換の流れ

001.png

VxRail Managerで交換対象のドライブを選択し「ハードウェアの交換」をクリック。

※今回は正常なドライブで試したので、LEDがブルーですが気にしないでください。

 

002.png

「続行」をクリック

 

003.png

ドライブ交換を進めてよいかクラスタのチェックが走り、もう一度「続行」をクリック

 

005.png

取り外すドライブのデータを削除してパーティションを飛ばしてくれます。地味に親切。

 

008.png

ドライブを取り外す準備ができたので、ここで物理的に交換対象のドライブを引き抜き、新しいドライブを装填します。

そのあと「続行」をクリック。

※対象のドライブがどれか判るように、ドライブスロットのフロントLEDが点滅してくれます。

 

012.png

新しいドライブの初期化(Web Clientで確認するとvSANディスクグループへの追加)が走ります。

 

026.png

1分経たずに操作は終了です。ホストの再起動は不要であっさり終わりました。

 

028.png

今回、他の環境からドライブを持ってきたため、ディスクラベルが異なっていますが、ちゃんとvSAN ディスクグループに追加が完了したことが確認できます。

 

■番外編

今回、他のvSAN環境で利用していたドライブをそのまま挿してしまったため、「パーティションがあるぞ」と警告が出ました。

114.png

ちゃんと見ているんですね。

通常、故障ドライブの交換時にこういうことはないと思いますが、これが出たときはホストにSSHでログインして

/sbin/partedUtil delete <削除対象パーティション>

でパーティションを削除するか、vSphere 6.0u2以降ではWeb Clientでも簡単にパーティションの削除ができるので以下の手順を実施します。

 

116.png

対象のドライブを選択して「パーティションを消去」を実行。

 

118.png

今回はほかのvSANで利用していたため上記二つが確認できます。このまま削除してよいなら「OK」をクリック。

パーティションが削除されれば、あとは再度以下の画面で「再試行」をクリックすれば正しくvSANディスクグループに組み込まれました。

 

114.png

 

以上、簡単ですがVxRail 4.0でのドライブ交換手順でした。

※ドライブはCRUパーツですが、本番環境のドライブ交換はSolveDesktopの手順書を確認しながら慎重に実施しましょう。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。


本投稿はvExperts Advent Calendar 2016への寄稿も兼ねて、

あまり一般的には使われていないvSAN Stretched Clusterがどんなものか、実際に2台のVxRailを利用してクラスタを組む際のポイントをまとめてみました。

画面キャプチャ多用していますので、こういう導入手順なんだ、と眺めていただければ幸いです。

 

今回はデータセンターを跨いでRTT 5ms以下で10Gbpsの帯域を持つネットワークはとても用意できないので、隣のラック、別のTop Of Rack スイッチに接続された2セットのVxRailアプライアンスを利用しました。

 

ラックやサーバールーム、建屋を跨いだVSANの可用性担保をFault Domainの機能を用いて実装するのですが、

通常のFault Domainではなく、Stretched Cluster用のVSAN Witnessを利用することで、2セットのアプライアンスでもFault Domainが構成可能となります。

 

※今回はvSAN 2Node Clusterを組む要領で、VxRail 2アプライアンス Stretched Clusterを組んでみたのでそのレポートです。

 

※実際に本番環境でVxRailでStretched Clusterを組む際にはDELL EMCにRPQ(Request Per Qualification)を申請し、サポート承認を得る必要がありますのでご注意ください。

 

VxRailでのStretched Clusterに関しては以下のWhite Paper、Tech Bookを参照にしました。

今回はラック跨ぎのStretched Clusterとしたため、本来必要となるデータセンター間、Witnessサイト間とのネットワーク遅延やL3 スタティックルートの設計など、細かな要件を端折っています。それぞれの要件についてはドキュメントを参照願います。

 

【DELL EMC VxRAIL PLANNING GUIDE FOR VIRTUAL SAN STRETCHED CLUSTER 】

https://www.emc.com/collateral/white-papers/h15275-vxrail-planning-guide-virtual-san-stretched-cluster.pdf

 

【VMware Virtual SAN 6.2 Stretched Cluster & 2 Node Guide】

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-6.2-stretched-cluster-guide.pdf

 

【VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance】

https://www.vmware.com/files/pdf/products/vsan/vmware-virtual-san-6.1-stretched-cluster-bandwidth-sizing.pdf

 

 

 

■ VxRail 2Appliance vSAN Stretched Cluster の概要図

vsansc02.png

 

 

■ vSAN Stretched Clusterを組む前の事前準備

通常、VxRailはデフォルトでバンドルされている(出荷時にデプロイされている)vCenter Server Applianceを利用してクラスタをセットアップしますが、

vSAN Stretched Clusterの場合は、2セットのVxRailはデータと仮想マシンの格納場所として利用し、

vCenterは既設の管理クラスタ上に、vSAN Witness Applianceとともに設置したものを利用します。

 

※VxRail 3.5以降では外部vCenter(External vCenter)構成も正式にサポートされているので、既存で利用しているvCenter配下にVxRailのvSANクラスタを組み込むことも可能になりました。

 

FILESV01_VxRail4.0_StretchCluster_20161218_001a.png

今回はこのvCSAとPSCを別の管理クラスタ上に作成し、VxRailを格納する空のDetaCenter 「DataCenter-A」と「DataCenter-B」を作成しておきます。

 


■ vSAN Witness Appliance のデプロイ

vSAN Witness Appliance は所謂 Nested ESXiの様な形をしたvSAN Witness機能専用の軽量ESXiとして、vSphere上にデプロイします。

予めMy Vmwareから利用するvSANと同じバージョンのvSAN Witness Appliance のOVAファイルをダウンロードしておきます。

FILESV01_VxRail4.0_StretchCluster_20161218_037.png

OVAテンプレートのデプロイは通常の仮想アプライアンスの導入と変わりありません。


FILESV01_VxRail4.0_StretchCluster_20161218_046.png

サイズや配置先データストアは用途によって異なりますので割愛しますが、

vSAN Witness Appliance はvCenterとの通信、vSANの通信が必要となるためデプロイ先のクラスタのネットワークには、

予めvSANネットワークとの疎通のあるポートグループを作成しておきます。

※リモートサイトに置く場合など、L3でのルーティングが必要な場合はStatic Routeを設定しておきます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_009.png

デプロイしたvSAN Witness Appliance を起動すると、見た目は普通のESXiのコンソールが立ち上がります。

通常のESXiを初期設定するように、IP、ホスト名、DNSなどの設定を投入します。

ここではSSHを有効にしておくと後々の設定変更に便利です。

 

FILESV01_VxRail4.0_StretchCluster_20161219_017a.png

初期設定が終わったvSAN Witness Appliance は外部vCenterとなるvCSAとPSCと同じ環境に設置しました。

 


■ Stretched Cluster プライマリサイト側VxRail のセットアップ

 

今回は前項で事前に用意したExternal vCenter環境配下にVxRailを展開します。

FILESV01_VxRail4.0_StretchCluster_20161218_073.png

お馴染み(?)のようこそ画面からいつも通りVxRailをセットアップします。


FILESV01_VxRail4.0_StretchCluster_20161218_077.png

今回は最新のVxRail 4.0を利用したので、初期セットアップ時にどのアプライアンス、どのノードに対してセットアップを行うかがスキャンされるようになりました。

最小は3ノードから構成可能です。

 

FILESV01_VxRail4.0_StretchCluster_20161218_081a.png

いつもと違うセットアップ項目は以下の画面で「既存のvCenter Serverの結合」「外部 Platform Service Controller」にチェックを入れ、

既存環境のFQDN、vCenterの認証情報を投入しておく事です。

今回は予め作成済みの「DataCenter-A」 配下に「vSAN StretchCluster」を作成してVxRailが組み込まれるようにします。

 

FILESV01_VxRail4.0_StretchCluster_20161218_089.png

設定内容に問題がなくValidationが通ればVxRailのセットアップが始まります。

※ここでValidationが失敗する例として、DNSでのFQDNでの名前解決が通らない事や、VxRailのアップリンクの10Gスイッチの設定漏れ、特にvSANが利用するマルチキャストの設定漏れなどがありますので、エラーが出たらメッセージに従ってネットワーク周りを重点的に確認しましょう。

 

FILESV01_VxRail4.0_StretchCluster_20161218_099.png

External vCenterを利用する場合、vCSAのFirst boot scriptなど時間がかかる処理がないので、それこそ10分もあればVxRailのセットアップはあっという間に完了してしまいます。

 

FILESV01_VxRail4.0_StretchCluster_20161218_118.png

セットアップが完了すると、External vCenterでは以下のようにクラスタに格納されます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_004.png



■ 次にvSAN Witness Appliance を「DataCenter-B」にESXiホストとして追加します。

FILESV01_VxRail4.0_StretchCluster_20161219_023.png

追加方法はいたって簡単。

 

FILESV01_VxRail4.0_StretchCluster_20161219_027.png

デプロイ後、VMkernel アダプタの設定を確認するとvSAN用ポートが設定されていないので、IPを割り当てます。

FILESV01_VxRail4.0_StretchCluster_20161219_032.png

 

vSAN VMkernelにIPを割り当てた後は、

vSAN Witness Appliance にSSHでログインし、それぞれのVxRailノードのvSANカーネルに対してvmkpingでIP疎通があることを確認しておきましょう。

 


■ Stretched Cluster セカンダリサイト側のVxRailのセットアップ(既存へのノード追加)

FILESV01_VxRail4.0_StretchCluster_20161219_034a.png

VxRailのノード追加は非常に簡単で、既存VxRailと管理ネットワークの疎通がある状態で追加ノードの電源を投入すると自動検知され「ノードが検出されました」と追加ウィザードのボタンが有効になります。


FILESV01_VxRail4.0_StretchCluster_20161219_035.png

追加ノードに必要なパラメータは各ノードのVMkernelに割り当てるIP(管理・vMotion・vSAN)と、既存のESXi、vCenterのパスワードのみです。

ここで4ノード追加するので予め4つ分まとめてレンジでIPを投入しました。

 

FILESV01_VxRail4.0_StretchCluster_20161219_041.png

追加は初期導入よりもっとスピーディで、1ノードあたり3分~4分で完了します。

スケールアウトの簡単さはHCIのメリットですね。


FILESV01_VxRail4.0_StretchCluster_20161219_045.png

4ノードすべて正常に拡張が完了しました。

 

 

■ vSAN Stretched Clusterの有効化

 

今回のメイン、vSAN Stretched Clusterを有効化します。

FILESV01_VxRail4.0_StretchCluster_20161219_051a.png

前項までに初期セットアップが完了したVxRailノード合計8台があります。

ここではStretched Cluster(拡張クラスタ)もFault Domainもまだ設定されていません。

 

まずはStretched Clusterを有効化します。


FILESV01_VxRail4.0_StretchCluster_20161219_054.png

まず8台のノードを、プライマリサイトの4台と、セカンダリサイトの4台で分けます。

※今回は同一サイト内・別ラックで構成しているのでラック全断障害などを想定した構成です。

 

FILESV01_VxRail4.0_StretchCluster_20161219_056.png

監視ホスト(vSAN Witness)の設定は「DataCenter-B」に配置したvSAN Witness Appliance を選択します。

 

FILESV01_VxRail4.0_StretchCluster_20161219_061.png

設定はすぐに反映されます。

メインの作業はこれだけです。拍子抜けするほど簡単ですね。

 

■ vSAN Health Checkでエラーがないか確認

見た目なにもエラーがなくても油断しないでHealth Checkを確認しましょう。

vSphere 6.0 u1からはvCenterにデフォルトで組み込まれたHealth Check (以前はpluginで配布されていた)は

vSANの構成、データの同期状態など細かく状態確認が可能です。

FILESV01_VxRail4.0_StretchCluster_20161219_064a.png

ここではvSANを構成する8台のノードと、vSAN Witnessで詳細設定(ノード拡張上限、ネットワークヒープ値)が異なると指摘されているので、vSAN WitnessにSSHでログインしてさくっと直してしまいます。

 

[root@rgm-96x:~] esxcli system settings advanced set -o /VSAN/goto11 -i 1

[root@rgm-96x:~] esxcli system settings advanced set -o /Net/TcpipHeapMax -i 1024

 

変更したらvSAN Witnessを再起動し、警告が消えたことを確認します。


 

■ その他の健全なクラスタ運用のための諸設定

ここまででだいたいvSAN Stretched Clusterの設定は完了しましたが、

通常のHAクラスタの冗長性で考慮するN+1の構成ではなく、今回は1+1の構成なので、サイト障害時(片系アプライアンス全断)時には

リソースの負荷が残った方にすべてフェイルオーバーしてくるので、HAのアドミッションコントロールの予約値を50%に設定しておきます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_070a.png

Active - Active のStretched Clusterを組むからには太っ腹であることが重要ですね。

 

また、仮想マシンを作成する際にも、どの仮想マシンが通常時どちらのサイトで稼働するかを指定しておいた方が

負荷のバランスと管理が行いやすくなります。


FILESV01_VxRail4.0_StretchCluster_20161219_077a.png

ここではDRSのアフィニティルール 「仮想マシンからホストへ」を利用して、仮想マシンが稼働するサイトを指定します。


FILESV01_VxRail4.0_StretchCluster_20161219_078.png FILESV01_VxRail4.0_StretchCluster_20161219_079.png

プライマリサイトのホストと仮想マシン、セカンダリサイトのホストと仮想マシンをそれぞれ

「グループ内のホスト上で実行してください」という英語表記では「Shuld」でルールを作成します。

※ここで「グループ内のホスト上で実行する必要があります」という英語表記での「Must」でルールを作成すると仮想マシンがフェイルオーバーできなくなってしまうので注意してください。

 

ここまで作成すれば、正常な状態時には仮想マシンの配置と、データの配置がきれいに管理でき、vSAN Health Checkの以下の画面で仮想マシンのデータの配置場所(どのホストのどのドライブに格納されているか)が簡単に確認できます。

FILESV01_VxRail4.0_StretchCluster_20161219_080.png

 


■ vSAN Stretched Clusterでの障害試験、HA挙動

 

最後に、組みあがったvSAN Stretched Clusterで障害(片系アプライアンス全断)の挙動を確認してみます。

以下の画面はIPMIでセカンダリサイトの全ノードを強制電源Offにした直後の画面です。

FILESV01_VxRail4.0_StretchCluster_20161219_082.png

きれいに半分にアラートが上がっています。

上で動いていた仮想マシン、今回はMS-07 ~ MS-09までが稼働していましたが、無事にHAが働き、プライマリサイトのノード上で再起動されたようです。


FILESV01_VxRail4.0_StretchCluster_20161219_085a.png

片系アプライアンス全断時には各仮想マシンのミラーされたデータの片方へのアクセスが出来ないので、

vSAN Health Check 上では以下のようにコンプライアンスエラー状態となります。


FILESV01_VxRail4.0_StretchCluster_20161219_086.pngFILESV01_VxRail4.0_StretchCluster_20161219_090.png

このエラー状態も、全断していたアプライアンスが起動してくれば元通りになります(デフォルトでは1時間以内の復旧時は差分データの同期のみで完了)。


■ まとめ

今回はデータセンター跨ぎではなく、ラック跨ぎのvSAN Stretched Clusterの作成でしたので、WitnessサイトへのL3ルーティングの設定や、サイト間遅延時間の考慮などは特にせず簡単に作り上げることが出来ました。

アプライアンス筐体障害やラック電源障害などによる全断を回避するための構成として度々Fault Domain構成は提案する事があるのですが、最低3ドメイン必要となるためなかなかハードルが高かったところを、vSAN Witnessを代用する事でシンプルに組むことが出来ました。

 

VxRailとして本番利用するためにはRPQを通してサポート承認が必要となりますが、

vSANとしてはこのように簡単に組むことが出来るので、ぜひ皆さんも一度試してみていただければと思います。

※本記事は元々"kawaman"の個人ブログスペースに投稿しておりましたが、DECNからDELLコミュニティへのコミュニティ統合に伴う移行影響で"日本語コミュニティ"ブログ側に付け替えさせていただきました。



先週12月5日にVxRail 4.0がGAされたので早速アップグレードを試してみました。

非常に簡単で数クリックするだけで、4台のESXiへのpatch適用も含め、約60分でアップグレード作業が完了しました。


画面キャプチャばかりですが、アップグレードの作業の参考にしていただければ幸いです。

 

※EMC製品のアップグレードは必ず事前にプロダクトガイド、SolveDesktopの手順書を参照して作業することが前提です。

 

■アップグレードの事前準備

※アップグレードに必要なバイナリはSupport EMCからDL可能です。

https://support.emc.com/downloads/41560_VxRail-Appliance-Famil

 

FILESV01_vdp92error_20161212_020.png

VxRail 3.5からVxRail 4.0へのアップグレードには

  • VxRail Managerのアップグレード用パッケージ(VxRail Manager Upgrade Package 4.0.0)
  • ESXi 6.0u2 → 6.0P3 アップグレード用パッケージ(VxRail Composite Package 4.0.0)

の二つが必要となるので事前にDLしておきます。

 

■VxRail Managerのアップグレード

まずVxRail Managerを4.0にアップグレードします。

 

VxRail Managerにアクセスし、「構成」 > 「機能」を開き、「更新」ボタンから「ローカルバージョンのアップロード」を選択し、前項でDLしたVxRail Managerのアップグレードパッケージをアップロードします。

FILESV01_VxRail4.0_Upgrade_20161207_003a.png

FILESV01_VxRail4.0_Upgrade_20161207_005a.png


ファイルのアップロードをしばし待ちます。

FILESV01_VxRail4.0_Upgrade_20161207_007.png


アップロードが完了したら、「インストール」をクリックします。

FILESV01_VxRail4.0_Upgrade_20161207_008a.png


アップグレード実行前の診断プロセスが走りますので、完了後「今すぐアップグレードしてください」をクリックします。

FILESV01_VxRail4.0_Upgrade_20161207_014a.png


VxRail Managerの再起動含め、だいたい10分くらいでソフトウェアの更新が完了します。

FILESV01_VxRail4.0_Upgrade_20161207_018.png


■アップグレードの確認と、ESXiへのpatch適用


VxRail Managerのセッションに再度接続するとバージョンが4.0になった事が確認できました。

そしてメニューには「インターネットアップグレード」が標準の表示になっています。

今後のVxRail 4.0.x、4.xへのアップグレードはインターネットの接続が利用できれば、Support EMCから事前にファイルをDLしなくても、直接アップグレードが可能になるようです。

FILESV01_VxRail4.0_Upgrade_20161207_027a.png

※右下のロゴも「DELL EMC」に変更されてます。


次にESXiのアップグレード(patch適用)を行います。

今回は事前にDLしたESXiのパッケージを手動でアップロードします。

FILESV01_VxRail4.0_Upgrade_20161207_031a.png


アップロードが完了するまでしばらく待ちます。

FILESV01_VxRail4.0_Upgrade_20161207_035.png


アップロードが完了したら「続行」ボタンをクリックします。

※今回はVxRailのクライアントエージェント(marvin VIB)のアップグレードと、6.0u2 → 6.0p3へのアップグレードが行われます。


FILESV01_VxRail4.0_Upgrade_20161207_036a.png

 

アップグレードが開始されると、VxRail Managerのクラスタ管理モードが抑制モードに自動で切り替わり、

  • 各ノードのVxRail Manager VIB(marvin)のアップグレード
  • 各ノードのESXiのpatch適用(6.0u2 → 6.0p3)

が開始されます。

※「詳細」メニューを開くと、現在の進行状況が細かく把握できます。

FILESV01_VxRail4.0_Upgrade_20161207_050.png

 

裏で動くvCenterに接続してみると、ESXiへのpatch適用に関する一連のオペレーションが自動で実行されていることが確認できます。

※個人的には面倒だった個別VIBの適用や、仮想マシンの退避を含むpatch適用の一連操作がvUM(vSphere Update Manager)を準備しなくても一括で実行できるのが非常に気に入りました。

FILESV01_VxRail4.0_Upgrade_20161207_052a.png

 

アップグレードはVSAN クラスタを構成する各ノードが順々にメンテナンスモード → 再起動が実行される形で行われ、稼働中のVMは別のホストにvMotionで自動的に退避されながらローリングアップデートが実行されます。

※仮想マシンの自動退避しながらのローリングアップグレードは「DRS」が有効なライセンス(Enterprise plus、vSphere Desktopなど)が必要です。

vSphere Standard Editionの場合は仮想マシンのvMotionは手動で行う必要があるようです(私はまだ試せていません...)

 

■アップグレードの完了

今回はVxRail 120 Hybrid VSANモデルで試しましたが、

VxRail Managerのアップグレード(再起動含む)に約10分、4台のESXiのpatch適用(それぞれの再起動)に50分、合計60分でVxRail 4.0へのアップグレードが完了しました。

FILESV01_VxRail4.0_Upgrade_20161207_068.png

FILESV01_VxRail4.0_Upgrade_20161207_069a.png

 

今回はVxRail 3.5 → 4.0へのオンラインアップグレードの一連の流れをご紹介しました。


デビッド ウェブスター(David Webster)

APJエンタープライズ担当プレジデント、Dell EMC

 

自動運転車で通勤したり、夕食の献立について冷蔵庫と会話したり、AI(人工知能)を実装したチャットボットからカスタマー サービスを受けたりする。このようなことを生きているうちに体験できるかもしれないとは、驚くべきことです。テクノロジーの発展は、以前であればフィクションだったこのようなシナリオを、もうまもなく実現しようとしています。

 

Realizing 2030_Planets_TW.jpg

これらのソリューションを現実化するために飽くことなくイノベーション(革新)を進めていく中で、私たちはマシンとの相互関係を根本から変えることになります。実際、最近デル テクノロジーズが発表した「Realizing 2030: A Divided Vision of the Future」によると、アジア太平洋および日本(APJ)地域のビジネス リーダーの大部分(80%)が、5年以内に人とマシンが統合チームとして仕事をするだろうと考えています。

 

APJ地域の企業はデジタル トランスフォーメーションの過程で新しいテクノロジーを導入しており、これらのテクノロジーがより多くの人とマシンのパートナーシップへの道筋を作り出しています。例えばAIについて、この調査ではビジネスリーダーの81%が5年以内にAIによって顧客のニーズを先取りできるようになることを見込んでいます。これは前向きで明るい結果ですが、新しいテクノロジーおよびこれらのテクノロジーが生み出す膨大な増加データから企業が最大限の価値を引き出すためには、クラウド コンピューティングへのアプローチについて正しいITトランスフォーメーションの判断をすることが欠かせません。デジタルを背景にした新たな要件によって、既存のITインフラストラクチャはたやすく打ち破られるでしょう。

 

APJ地域のビジネス リーダーとITリーダーは、残念ながら今でも過去に下した意思決定からの重荷を引きずっています。大抵の場合、クラウドの導入は幅広い戦略の一部というよりは数ある項目の1つに過ぎません。これまで長年にわたりパブリック クラウドの導入が進められてきていましたが、現在プライベート クラウドやハイブリッド クラウドへのシフトおよび多様なビジネス ニーズとワークロードに応えるクラウド サービス プロバイダとのパートナーシップが進んでいます。例えば、スピードと効率の向上という観点から一定のワークロードがオンプレミスへ戻されている一方で、パブリック クラウドは非ミッション クリティカルなワークロードに対して利用される場面が増えています。実際、IDC社はAPJ地域のエンタープライズ企業の70%以上が2018年までにマルチクラウド戦略を採用するとしています。

 

multi-cloud.pngこのようにマルチクラウドが未来の方向性であることは明らかですが、企業はこの現実がもたらす複雑さとニーズの管理について、大きな課題に直面しています。企業には、データのやり取りを簡単に行えるとともにマルチクラウド インフラストラクチャをシンプルかつシームレスに管理できる戦略が必要です。

 

このような複雑さに対処して新たに出現するテクノロジーから最大限の価値を引き出せるようにするには、コラボレーションに重点を置く必要があります。企業が最適なコラボレーティブ アプローチを確立するためにはどうすべきなのか、その方法を紹介します。

 

顧客を中心に据える

今日の市場においてカスタマー エクスペリエンスは重要な差別化要因で、新しいカスタマー エンゲージメント モデルへの移行にマルチクラウド環境が使われる場面が増えてきています。前出の調査「Realizing 2030」において、カスタマー エクスペリエンスを役員会レベルの事案として取り組むことを優先事項であるとしているAPJ地域の企業は、10社中9社近くに上ります。社内外を通じたさまざまな相手先との世話役として、IT部門およびCIOの戦略的役割が高まるのに伴い、すべての関係者が質の高いカスタマー エクスペリエンスの提供に集中できるようにすることは、コラボレーションとパートナーシップを醸成する上での助けになります。

 

applications.pngデータがすべての要であることを認識する

あらゆる業種を通じて、イノベーションの実現、高品質なカスタマー エクスペリエンス、差別化の促進における鍵となるのが、クラウド ネイティブ アプリケーションです。APJ地域のビジネス リーダーのうち、すでにアプリケーションをパブリックまたはプライベート クラウド(ハイブリッド クラウドなど)へ移行するテクノロジーに投資しているとしたリーダーが45%に上り、今後5年間で投資を行う予定であるとしたリーダーが47%に上るのも不思議はないでしょう(「Realizing 2030」調査)。

 

ただし、これはテクノロジーだけの話ではなく、適切な人材とスキルへの投資も含まれています。今日のマルチクラウドの世界では、単なるクラウド ネイティブ アプリケーションの提供の先へと進化していくためのDevOps へのニーズも出現しています。新たに出現しているさまざまなテクノロジーによってデータ量が増加している中、DataOps の到来を認識し、効果的なコラボレーション方法を見つけてデータを管理できる企業が、デジタル トランスフォーメーションを加速させることができます。

 

将来に焦点を当てたパートナーシップを組む

マルチクラウドは単なる始まりにすぎません。私の同僚でDell EMCのCTOであるジョン ローズ(John Roese)は、2018年の予測の中で、複数のクラウドシステムが連携して相互作用するメガクラウドこそが未来であると述べています。メガクラウドは次世代のITインフラストラクチャで、IT部門と業務部門は社内で真の戦略的パートナーシップを構築することに集中し、これまで以上に緊密なコラボレーションを実現しなければなりません。

 

ITのリーダーシップについて、Dell EMCのAPJ担当CIOであるヘマル シャア(Hemal Shah)は、このパートナーシップ アプローチの発展に対する見解を的確にまとめています: 「規模が大きな企業では小規模で自己充足的な専任チームが出現しており、イノベーションに焦点を当てた活動を展開するとともに、アプリケーション開発者やデータ サイエンティスト、またIT部門で他の役割を担っているスタッフに、上級役員と連携して新たな機会を認識するための機会を提供しています」。

 

テクノロジーが進化を続けていく中で、企業は将来出現するトランスフォーメーションの大きな課題に対処できる十分な効率性と俊敏性を確立してメガクラウドの基盤を構築するために、今日、緊密なコラボレーションを構築することに集中する必要があります。

 

新たに出現しているさまざまなテクノロジーは、私たちの生活に信じられないような数多くの変革をもたらすでしょう。このような未来を現実化する上で、クラウドは欠かすことのできない重要な役割を果たします。私たちがクラウドを利用する方法は、急速に変化しつつあります。これらの新しいテクノロジーから真の価値を引き出すためには、このような進化と適切な文化を対にして組み合わせる必要があります。コラボレーションに重点を置くことによって、APJ地域のビジネス リーダーは、それぞれの企業組織をデジタル トランスフォーメーションに向けたより円滑でより高速な軌道に乗せることができるでしょう。

Filter Blog

By date:
By tag: