LTN Blog 〜 Lenovo Technology Network 〜

レノボのソリューション・サーバー製品に関する技術情報、お役立ち情報をお届けします

LCM(Life Cycle Management)について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はLCM(Life Cycle Management)についてお話したいと思います。

まずは、LCMとは何か?ということをお話します。LCMの役割はNutanixのクラスタ内のすべてのエンティティ(構成要素)のソフトウェアとファームウェアのバージョンを管理するものです。単にファームウェアを管理するだけなら普通にできるのではと思いますが、これが重要なのはNutanixで特徴である1クリックアップグレードの要素の一つになっています。つまり1クリックアップグレードはこのLCMの機能で成り立っているといっても過言ではありません。

ではその仕組みについて、説明していきたいと思います。

f:id:t_komiya:20181213012110p:plain

従来型の1クリックアップグレードはAOSをアップグレードする際に、アップグレードするタイプを選択し、メタデータとイメージをアップロードします。その後アップデートをクリックするとアップグレードは始まります。

今まではNutanix単独のいプラットフォームだけだったので、これでよかったのですが、今後は他のハードウェアベンダーや様々なデバイスが出てくることもあり、それらのプラットフォームにも1クリックアップグレードが対応する必要があります。

そのために、LCMのインターフェースを変更するがあります。

f:id:t_komiya:20181213025902p:plain

こちらのイメージはNutanixをご存じな方は見たことがあると思いますが、今後Nutanixは様々な規模での展開、プラットフォーム、アップグレードする要素が多様化することを示しています。

これらを今までアップグレードするときにはそれぞれ個別のオペレーションが必要であり、依存性も管理されておらず、中にはパフォーマンスに悪影響を及ぼすものもあります。

f:id:t_komiya:20181213030221p:plain

例えば、Linuxなどを例に挙げてみると、パッケージをアップデートする際にはyumコマンドで一発でできるようになっています。これがNutanixの場合はどうなっているのか?GUIで1クリックでアップデートできるようになっているのがNutanixユーザの理想だと思います。

f:id:t_komiya:20181213083623p:plain

こちらはPRISM上のLife Cycle Managementの画面をキャプチャしたものです。GUIでアップデート可能で、これが1クリックアップグレードできるようになれば良いことです。

f:id:t_komiya:20181213083857p:plain

f:id:t_komiya:20181213084527p:plain

f:id:t_komiya:20181213084744p:plain

LCMのアーキテクチャを図式化してみました。こちらはNXをベースにしております。AOS、ハイパーバイザーおよびその他の機能がLCMとクラスタ内のCVMが連携して(ローリング)アップデートを行います。もちろん、こちらはPRISM Centralからもアップデートが可能になっています。

f:id:t_komiya:20181213084221p:plain

f:id:t_komiya:20181213084610p:plain

LCMのRepositoryの構造になります。アップデートを行う際にアップデート対象のリストが必要になります。そのリストをもとにどのモジュールをアップデートするのかということでリストに書かれたモジュールをアップデートする際にダウンロードを行います。AOS、AHVなどの関連モジュール以外にそれぞれのハードウェアメーカー毎のモジュールもダウンロードします。

f:id:t_komiya:20181213084835p:plain

現状のLCMの機能について、最後にコメントします。

現状は複数社のハードウェアにも対応しています。LenovoのHXもその対象ですが、一部の機種はまだ未対応のものがあります。(近日対応予定)また、このLCMでアップデートする際に、他のホストに仮想マシンをvMotionしたり、ローリングアップグレードで各ホストを再起動してくれます。

また、複数のコンポーネントが選択されている場合はその依存関係もチェックした上で正しい更新順序でアップグレードを行います。

ダークサイト(インターネットがつながらない環境)下でもアップグレードできるようにインタフェースを持っています。(オフラインでのアップグレード)

 

是非試してみてはいかがでしょうか。検証環境をお持ちの方は気軽にやってみましょう。

 

よろしくお願いします。

Lenovo ThinkAgile HX for SAP HANA アップデート情報

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は以前にも話題で取り上げたThinkAgile HX for SAP HANAのアップデート情報を掲載します。構成組むうえで重要な情報を記載致しますので、参考にして頂ければと思います。

1. SAP HANAをNutanix環境で実現するにあたり必要なものとは?

SAP HANAはインメモリデータベースであり、その特徴はメモリ上にデータを保有しているためハードディスク上で動作するRDBMS製品と比較して、10~100,000倍の速度でデータを処理できます。そのデータベースが遅延なく動かすために、AHVのI/O高速化アーキテクチャであるAHV Turbo、25Gb以上の高速なネットワークかつRDMA(Remote Direct Memory Access)対応のNIC、高速なI/Oスループットを実現するNVMe/3D Xpointなどのデバイスが必要となります。

f:id:t_komiya:20181205233612p:plain

それに加えて、Nutanixプラットフォームを利用することにより従来型(3Tier)の構成に比べて最大31%のTCO削減が見込まれます。そのため、今後SAP HANAのインフラはNutanixで提案しましょうというお話になります。詳細の内容はこの後お話致します。

 

2. AHV Turboについて

f:id:t_komiya:20181205233801p:plain

AHV Turboをお話する前にNutanixのデータローカリティについて覚えておく必要があります。仮想マシンから書き込みがあったデータを別ノードの冗長性を保つためにデータをレプリケーションします。この一連の動作を高速化することがSAP HANANutanixで実現するために必要な要素になります。

f:id:t_komiya:20181205233908p:plain

AHV Turboについてご説明致します。AHV TurboとはAHV環境におけるI/Oを高速化する技術になります。主な用途としてはアプリケーションの高速化に効果として望まれます。従来のNutanixCVMは仮想マシンからのI/Oを一つのコアで処理をしていましたため、たくさん仮想マシンが動作している環境ではCVMがボトルネックになってパフォーマンスが出ないケースがありました。

f:id:t_komiya:20181205234039p:plain

それをAOS5.5からCVMCPUコアを分割してI/O処理できるようにすることで、並列処理が可能になりパフォーマンスを上げることができるようになりました。(上図でわかりやすく紹介)

しかしながら、本当にAHV Turboを導入したからと言ってI/Oが高速するのでしょうか?実はストレージデバイス側も並列処理に対応している必要があります。

f:id:t_komiya:20181205234147p:plain

ストレージデバイスについてご説明致します。現状のハードディスクやSSDについてはSATAデバイス、SASデバイスで接続されています。こちらのデバイスの場合1つのコマンドキューしか対応していないため、いくらAHV Turboに対応してもデバイス側その効果を発揮できるものではありませんでした。そこで必要になるのはNVMeなどの高速ストレージデバイスになります。こちらのNVMe64Kのコマンドキューをサポートしており、AHV Turboのような並列のI/O処理にも対応できるため、高IOPSを実現できる環境が整います。実際にNutanixでリリースされているNVMeモデルでは1仮想マシンあたり120IOPSを実現しているものもあります。

そのため、AHV Turbo + NVMeは高スループット実現する環境になります。

f:id:t_komiya:20181205234324p:plain

AHV Turbo環境で高スループット実現するにはNVMeなどのストレージデバイスだけで足らず、データローカリティ部分の高速化をするためにはネットワーク部分についても高速化が必要となります。実際にHCI環境のネットワークは10GbEで十分だという認識でいると思われます。それは従来型の利用方法では十分でしたが、今回のような64Kの並列処理を行うようなI/O環境ではネットワークの負荷も膨大なものになってきます。そのため、10Gbでは足らないケースも起こりますし、逆にデータ転送における遅延にもつながります。そのため、AHV Turbo + NVMeの環境では25GbEが必須になってきます。データローカリティでホスト内の処理を高速に処理できたとしても、データローカリティのシーケンスはデータの冗長化ができて初めてシーケンスが終了します。この理由から25GbE以上のネットワークが必要となります。

f:id:t_komiya:20181205234505p:plain

実際にSAP HANAのようなインメモリデータベースの場合、ストレージ部分だけの高速化だけでは処理としてはまだ不十分です。ホスト間のデータ通信を早くするだけでなく、いち早くアプリケーションレイヤまでデータ通信させる必要があります。そこで必要な技術としてRDMARemote Direct Memory Access)になります。RDMAについてはHPCHigh Performance Computing)などのスーパーコンピュータ関連で使われている技術でアプリケーションにデータ転送するためにCPUをオフロードして高速化を実現します。

f:id:t_komiya:20181205234616p:plain

こちらのRDMAについては、最新のAOS 5.9から対応しています。(対応NICはMellanox社)

3. ThinkAgile HX Solution for SAP HANAについて

SAP 導入後の運用者の悩み事について

①SAPのクリティカルな問題として、本番環境開発環境での 自己修復、稼働時間、データ保護とリカバリにフォーカスが 置かれています
  • 本番環境の生産性の低下は収益の損失と顧客からの信頼を失います
  • 開発環境がダウンすると開発者の生産性を失うことになります
SAPのお客様はピーク時を想定して定常状態のリソースをオーバーサイジングします③SAPのお客様は新しいSAPランドスケープの導入やサービス カタログの欠如に多くの時間と労力をかけている
④SAPのお客様は実装が簡単でコスト効率の高い開発/テストおよびディザスタリカバリのソリューションを求めています
⑤無秩序にサーバが増えることが問題になっています

これらを解決するためにSAP環境を仮想化していくことが重要になりますが、しかしそこには様々な障害が存在します。

 

SAPのランドスケープはますます複雑化

  • ビジネスとITの要件のバランスを取る必要がある
  • 2025年までにSAP HANAへの移行に伴い、管理コストが高く未使用のシステムが多数変化してきている

ハイパーバイザーがスケールアップ可能

  • より強力なコアとソケットあたりのコア数の増加により、仮想化は実行可能なオプションになります

簡素化された導入と高可用性

  • 仮想化されたクラスタがアプリケーションを意識している

 

これらを解決するにはSAP HANAがNutanixに対応していれば解決するのではないかと考える方もいらっしゃるかと思います。実はそのきっかけになる話があります。

f:id:t_komiya:20181206000103p:plain

SAP社から2015年に2025年からは次世代ERPSAP HANAを前提としたプラットフォームにします」という発表がありました。そのため、ERPを導入している各社は現状の環境からSAP HANAの環境への移行を行う必要があります。

また、SAPなどのミッションクリティカルな環境は基本3Tier構成で組むことを前提としているため、ハードウェアのリプレース時のデータ移行やリソース不足による増設などでシステム停止などの運用で大きな負荷がかかっています。そのため、HCIなどの運用および拡張性に柔軟性のありプラットフォームやクラウド対応などもSAPERP環境にも求められていることから、数年前からSAPおよびNutanixの両社でNutanixS/4 HANA対応を行ってきました。

f:id:t_komiya:20181206000246p:plain

SAP HANA対応について現状のハイパーコンバージドでの構成ではどうなるのか?ということについてご説明します。

SAPERPなどはHANAのデータベースとそれ以外のアプリケーションで構成されます。HANA以外のアプリケーションについては今までの仮想化環境で十分対応できていました。しかしながら、SAP HANAに関してはSAPの認定するパフォーマンスについてNutanixのプラットフォームとして十分ではなかったからです。そのため、インメモリデータベースで動作するための環境作りがNutanix側で必要になってきており、今までは実現できていませんでした。それが、20188月末になり、NutanixAHV環境(Enterprise Cloud OS)においてようやくHANAの認定が取ることができました。

f:id:t_komiya:20181206000516p:plain

実は、NutanixのAHVが最初にSAP HANAの認定を受けたHCIのプラットフォームになります。

ここで、SAP HANAにおけるソリューションのポジショニングを整理しておきます。

f:id:t_komiya:20181206001104p:plain

Nutanix対応のSAP HANAのお話する前にLenovoが提供するSAP HANAソリューションは上図になります。TDI(Traditional Datacenter Infrastructure)は通常のカスタムベースの構成になります。一番構成として出しやすいです。アプライアンスについては構成としては決められているモデルになります。こちらのモデルについては、Lenovoは一番出荷量が多いモデルになります。仮想化された環境という意味では、今まではVMwareのみが対応していましたが、残念ながらHCIには未対応の状況でした。それが今回AHVに対応になったのが、今回紹介のモデルになります。(11月にはvSANやSimplivityもSAP HANAになっています)

f:id:t_komiya:20181206000804p:plain

ThinkAgile HXのSAP HANA対応についてご説明します。

こちらはThinkAgile HX7820(アプライアンス)/HX7821(認定ノード)のラインナップでSAP HANA対応のスペックになっています。詳細は上図をご参照下さい。

実際に赤字になっているところがポイントです。

CPUについては、メモリ構成上で3CPU以上が必須な構成のため、今回のSAP HANA

モデルはLenovo ThinkSystemの4CPUモデルで採用しています。(3TB構成は実際に利用可能なメモリ容量としては2.3TBになります)

次にNVMeと25GbE NICについては、先にご説明したAHV Turboの必要要件になっています。10GbEでの構成もサポートしていますが、10GbEのネットワーク構成としては最低でも4本以上が必要なります。

RDMAについては、ROC Capable NICsがそれに相当します。これが、AOS5.9の環境で動作することになります。

ちなみに、この構成でSAP HANAを組むことによって、AHVでのストレージオーバーサイジングは4%程度に収まっています。通常の場合は1.6倍程度のオーバーサイジングを考慮することが前提のため、この数字は素晴らしい数値になります。(vSANでの構成時は4%にはなりません)

また、SAPでLenovoを選択するメリットもあります。

LenovoはグローバルでSAPのマーケットで(アプライアンスで)リーダーの地位にいます。また、パフォーマンスのベンチマークとしても世界記録を持っています。最後にAHVについては、LenovoはハードウェアベンダーでAHV対応が一番進んでいる(ネットワークの自動化、XClarity Integrator)ことから、このソリューションにおいては他のベンダーに比べて優位性があります。

また、こちらのSAP HANA対応機種について、実はNutanixのNXシリーズではラインナップがございません。SAP HANAのNutanix対応については、是非Lenovoのプラットフォームをご選択頂けると幸いです。

 

4. ThinkAgile HX782xはSAP HANAのために作られたの?

f:id:t_komiya:20181206001604p:plain

先ほど紹介したモデルはSAP HANAにしか対応していないのか?と思う方もいらっしゃるかと思います。実はそうではなく、ブロックチェーンなどのP2Pのネットワークにも利用するできます。ブロックチェーンは一定期間内のトランザクションをつなげ合わせて処理を行っていくものであり、前の人の処理がメモリ上からアクセスできるような環境ができれば、いち早く処理を行えることからインメモリの環境にあるのは非常に最適な環境になるわけです。

f:id:t_komiya:20181206002051p:plain

そのブロックチェーンの基盤を支えるのが、こちらのNUMAのテクノロジーになります。こちらの技術を利用することにより、CPU間で接続されているI/O Controllerを通じて異なるCPUのメモリをアクセスすることができます。これを仮想環境でも利用できるようにするために、vNUMAがサポートされている必要がありますが、現時点ではAHVもVMwareもサポートしています。

 

5. SAP HANA for Nutanixサイジングにおけるちょっとしたコツ

f:id:t_komiya:20181206005629p:plain

f:id:t_komiya:20181206005730p:plain

ThinkAgile HX for SAP HANAにおけるプラットフォームの仕様とクラスタのガイダンスはこちらになります。3ノードが必要なのはNutanixの仕様上の話ですが、HX782xは最低でも2台と他のノードをHX782x以外で組むことはできます。しかしその場合はHAの仕様に制限出てきますので、本番環境で利用する場合にはできれば4ノード以上で構成することを推奨します。

また、先の説明でメモリは2.3TBしか利用できないについてもこちらでご説明したいと思います。

 

6. 3TBのメモリ構成が2.3TBしか利用できない理由とNUMAの関係性について

f:id:t_komiya:20181206010217p:plain

1台の巨大なVMを実装する場合に3つのCPUを利用することはできますが、一つの物理CPUはCVM用に割り当てる必要があり、すべてのメモリ領域を利用できるわけではありません。今までにそこまで大きなメモリ領域を使用することは少ないと思いますが、SAP HANAのようなインメモリデータベースは、会計上のデータなどの通常ストレージに入れるようなデータをメモリ上に展開する関係上、メモリの大容量化が必須になっているため、このようなリソースが必要となります。ハイパーコンバージド環境でSAP HANAを導入される場合は、ストレージリソースでどのくらい消費するのかも考慮しながら設計する必要があります。これは、Nutanixに限らず他のハイパーバイザーにも同様のことが言えます。

 

是非今回の内容を参考にして頂ければと思います。

 

よろしくお願い致します。

 

Nutanixクラスタの正常性の確認について~Health Monitoring~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanixの正常性の確認(Health Monitoring)についてご説明したいと思います。

まず、はじめにNutanixの正常性を確認するというが何を見ることができるのか?ということをお話します。

f:id:t_komiya:20181201231034p:plain

モニタリングできるものは仮想マシン、ホスト、ディスクなどの状態を表示、深刻度などを表示します。またスケジューリングして表示したり、Nutanixのクラスタのチェックを定期的に行ったり、ログ収集を行います。

それぞれの機能についての詳細は上図をご参照下さい。

 

それでは、それらについて画面イメージも交えながらお話します。

 

ヘルスダッシュボードには、クラスタ内のVM、ホスト、およびディスクに関する動的に更新された正常性 情報が表示されます。ヘルスダッシュボードを表示するには、メインメニューの左側にあるプルダウンリストから[Health]を選択します。

  • メニューオプション

ヘルスダッシュボードには、メインメニュー以外のメニューオプションはありません。

画面の詳細

ヘルスダッシュボードは3つの列に分かれています。

  • 左側の列には、各エンティティタイプ(VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタ サービス、および[構成されている場合]保護ドメインとリモートサイト)のタブが表示されます。各タブには、クラスタのエンティティの合計(ディスクの総数など)と各正常性状態の数が表示されます。タブをクリックすると、表示された 情報が展開されます(次のセクションを参照)。
  • 中央の列には、左側の列で選択されているものに関する詳細情報が表示されます。
  • 右側の列には、すべてのヘルスチェックの要約が表示されます。また、チェックボタン(成功、警告、失敗、無効)から個々のチェックを表示するオプションもあります。
  • [ Summary ]タブには、チェックステータスとチェックタイプに従って、すべてのヘルスチェックのSummaryが表示
  • [ Checks ]タブには、個々のチェックに関する情報が表示されます。カーソルを項目の上に移動すると、その ヘルスチェックに関する詳細情報が表示されます(次の図を参照)。適切なフィールドタイプをクリックして[ Apply ]をクリックすると、チェックをフィルタリングできます。チェック内容は以下のように分類されます。
  • ステータスでフィルタリング
    合格(Passed), 失敗(Failed), 警告(Warning), エラー(Error), オフ(Off),またはすべて(all)
  • タイプでフィルタリング

    スケジュールされていない、スケジュールされていない、イベントトリガーされている、またはすべて

  • エンティティタイプ別にフィルタリングする

    VM、ホスト、ディスク、ストレージプール、ストレージコンテナ、クラスタサービス、またはすべて

f:id:t_komiya:20181201232054p:plain
たとえば、Failureをチェックのみを表示する場合は、[ Failure ]オプションを選択してチェックをフィルタします。 特定のチェックをクリックすると、中央の列に、チェックが失敗した日時とチェック失敗の割合の詳細な履歴が 表示されます。バーをクリックすると、合格と失敗の履歴の詳細グラフが表示されます(上図参照)。

マウスをグラフの線に沿って動かすと、その時点に関する情報が表示されます。

 

f:id:t_komiya:20181201232258p:plainまた検索ボックスに文字列を入力することで、特定のチェックを検索することもできます。「Actionタブにはチェックを管理し、チェックを実行し、ログを収集するオプションがあります。

f:id:t_komiya:20181201232412p:plain

フィルタリングもVMやホスト、ディスクなどで行うことができます。

  • グループ化カテゴリをクリックすると、そのグループ化に関する詳細情報が表示されます。左側の列が展開され、グループ化とフィルタオプションのセットが表示されます。選択したグループが強調表示されます。そのグループをクリックすると、別のグループを選択できます。各グループエントリには、そのグループに含まれるカテゴリの数が表示され、中央のセクションにはそれらのカテゴリに関する情報が表示されます。次の例では、ディスクストレージ階層が選択されており、そのグループには2つのカテゴリ(SSDとHDD)があります。デフォルトでは、すべてのエンティティ(この例ではすべてのディスク)がカテゴリ情報に含まれています。1つまたは複数のフィルタをクリックすると、含まれているリストを絞り込むことができます。
  • 中央の列には、選択したグループ内の各カテゴリのフィールドが表示されます。各フィールドには、そのカテゴリの詳細が表示されます。特定のエントリにカーソルを置くと、追加情報が表示されます。フィルタリング用のドロップダウン選択リスト(グループ化フィルタと同じ)と、情報を並べ替えるためのリストによるドロップダウンソートがあります。
  • 右側の列には、そのエンティティタイプに関連するヘルスチェックが引き続き表示されます。

f:id:t_komiya:20181201232753p:plain

f:id:t_komiya:20181201232912p:plain

それぞれのエンティティについて、ダイアグラムビューで見ることも、それぞれの詳細な情報で出力することもできます。

 

一連のヘルスチェックが定期的に実行され、一連のクラスタヘルスインジケータが提供されます。実行する検査を 指定し、スケジューリング可能な検査および各ヘルスチェックのための他のパラメータを構成することができます。

クラスターヘルスチェックは、AOS、ハイパーバイザー、およびハードウェアコンポーネントを含むさまざまな エンティティをカバーします。チェックのセットはデフォルトで有効になっていますが、いつでもチェックの実行、無効化、または再設定ができます。1つまたは複数のヘルスチェックを再設定するには、次の手順を実行します。

 

1.ヘルスのダッシュボードでは、Action Manage Check クリックします

ヘルスダッシュボードには、ヘルスチェックに関する情報が再表示されます。特定のヘルスチェックをクリックすると、その チェックが強調表示されます。ヘルスチェックを選択するか(最初に選択するか)、以前に選択したヘルスチェックが強調表示されます。次の情報が表示されます。

  • 左側の列には、ハイライトされた状態が正常性チェックの一覧として表示されます。いずれかのエントリをクリックして、そのヘルスチェックを選択して強調表示します。
  • 中央の列には、このヘルスチェックの機能が記載されており、影響を受けるエンティティ(ホスト、ディスク、またはVM)全体で実行スケジュールと履歴が提供されます。
  • 右の列には、このヘルスチェックが失敗した原因(原因、解決、影響)が記載されています。

2.特定のチェックを実行するには、[ Run Check ]をクリックします。

3.ヘルスチェックをオフにする(またはオンにする)には、中央の列の上部にあるチェックオフ(またはチェックオン)リンクをクリックし、ダイアログボックスで[ Yes ]ボタンをクリックします。

4.パラメータの設定を変更するには(設定可能なパラメータがあるヘルスチェックの場合)、中央の列の上部にあるパラメータリンクをクリックし、ドロップダウンウィンドウでパラメータ値の1つ以上を変更して、[ Update ]ボタンをクリックします。このリンクは、ヘルスチェックに設定可能なパラメータが含まれている場合にのみ表示されます。設定可能なパラメータは、そのヘルスチェックに固有です。たとえば、CPU Utilizationヘルスチェックには、ホスト平均CPU使用率のしきい値とホストピークCPU使用率のしきい値の割合を指定するパラメータが含まれています。

f:id:t_komiya:20181201233422p:plain

f:id:t_komiya:20181201233545p:plain

  1. ヘルスチェックを実行するスケジュールを変更するには、中央の列の上部にあるスケジュール可能なチェックの スケジュールリンクをクリックし、ドロップダウンリストから間隔を選択します。1分から48時間までの間隔を選択 できます。各Checkにはデフォルトの間隔があり、ヘルスチェックに応じて1分に1回から1日に1回まで変更可能。 ほとんどの場合、デフォルトの間隔が最適であり間隔を変更することは推奨されません (Nutanixのカスタマーサポートによって要求されない限り)。

f:id:t_komiya:20181201234101p:plain

NCC(Nutanix Cluster Check)の間隔の設定について説明します。

こちらはNutanixのサポートに必要な情報を定期的にNutanixのサポートに送信します。(Pulseで設定します)

設定項目については上図をご参照下さい。 

f:id:t_komiya:20181201234158p:plain

Webコンソールを使用したCheckの実行について説明します。

Prism WebコンソールのHealthダッシュボードからNCCチェックを実行可能です。すべてのチェックを一度に実行するように選択することができます。失敗したチェックや警告を表示したり、選択した特定のチェックを表示したりすることができます。

f:id:t_komiya:20181201234247p:plain

Webコンソールを使用したログの収集について説明します。

Prism Webコンソールのホームダッシュボードから直接ログを収集可能。コントローラVM、ファイルサーバ、ハードウェア、アラート、ハイパーバイザ、およびシステムのログを収集可能。タスクが完了すると、タスクダッシュボードからログバンドルをダウンロード可能です。

 

参考にして頂ければ幸いです。よろしくお願い致します。

Windows Serverで実現するHCI ThinkAgile MXシリーズのご紹介

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は先日発表されたWindows Serverで実現するHCI 「ThinkAgile MXシリーズ」をご紹介します。

以前にもHCIに関しては、Nutanix社のHCI製品である「ThinkAgile HXシリーズ」やVMware社のvSANアプライアンスの「ThinkAgile VXシリーズ」を紹介してきましたが、今回の「ThinkAgile MX」はMicrosoftのWindows ServerベースのHCIになります。

もう少し詳細に説明すると、以下のようになります。(レノボ プレスリリースページから引用)

ThinkAgile MXシリーズ認定ノードは、Microsoft WSSDソリューションをベースに、事前検証済みハードウェアとファームウェアを構成、Windows Server 2016 Datacenter Editionをプリロードしパッケージ化したレノボおよびMicrosoftで認定したアプライアンスです。ストレージ構成として、フラッシュとHDDを組み合わせたハイブリッド構成と、フラッシュのみで構成されるオールフラッシュ構成を提供します。また、RDMA対応の高速ネットワークアダプターを標準で搭載、WSSDの性能を最大限に引き出す構成です。

f:id:t_komiya:20181123104903p:plain

赤枠で囲っている部分がThinkAgile MXの説明になります)

マイクロソフトの標準ハイパーバイザーであるHyper-Vを使い、Windows ServerのみでベースとなるHCIシステム構築が可能となります。別途、ソフトウェア製品を購入する必要がないため、初期投資を抑え、高い価格性能比のシステム導入が実現します。間もなくサポート終了となるWindows Server 2008から仮想サーバー統合や、中堅・中小企業におけるVDI導入に最適です。

ThinkAgile MXシリーズでは、現行のWindows Server 2016 Data Center Editionに加え、最新のWindows Server 2019 Data Center Editionに対応します。Windows Server 2019では、同社のパブリッククラウドサービスMicrosoft Azureとの連携も大幅に強化され、ThinkAgile MXシリーズを ベースとするハイブリッドクラウド環境の構築が可能となります。Windows Serverのライセンスはオプションとなり、OEMライセンスあるいはMicrosoft認定パートナーより提供されるライセンスを選択頂くことが可能です。

また、ハード、ソフトのテクニカルサポートを一括で提供するThinkAgileアドバンテージサポートは標準で含まれており、導入後のお客様の運用を強力に支援いたします。

 

通常のS2Dとの違いということであれば、ファームウェアの組み合わせ(Lenovoではこの組み合わせをベストレシピと呼ぶ)で検証されたハードウェアの構成により、パーツレベルでの相性も良いアプライアンスになります。そのため、パーツレベルで組み合わせれば単純に構成組んだとしても、ファームウェアの相性が悪ければブルースクリーンなども表示されてしまうこともあります。そのため、レノボでその構成を認定しているものを今回リリースしているわけです。

f:id:t_komiya:20181123105655p:plain

こちらが実際のコンセプトになります。もともとThinkAgile SXMというオンプレのAzureStackをリリースしていたのですが、今回Windows2019のリリースに合わせてS2DベースのHyper-VにおいてもAzure連携可能なプラットフォームにもなっているため、今回のThinkAgile MXシリーズはハイブリッドデータセンターというコンセプトを掲げて製品化しております。もちろん小規模のお客様にも手軽に導入でき、かつクラウドと連携しながら、リソースの有効活用しながら利用することもできます。

実はこのS2DベースのHCIが今一番成長率が高く、今年の3月から9月までの半年間で約50%の成長率になっています。現在注目のHCIと言っても過言ではありません。

f:id:t_komiya:20181123110357p:plain

S2Dに関してですが、Windows2012からベースの技術はありましたが、HCIの利用としてはWindows2016からになっています。しかしながら、Windows2016の時はHCIとしての機能はあったものの冗長性に関しては他社に比べて劣る部分があり、その点は改善してきました。(詳細な説明は今後ブログで紹介するかもしれません)

それに加えて今回は2ノード構成についてもプラスの要素がありますので、それは後程ご説明致します。

f:id:t_komiya:20181123111309p:plain

ここでS2Dのメリットをまとめてみました。

売り文句は費用対効果の高いストレージということです。ハイパフォーマンスということを売りにしているのですが、ストレージデバイスやネットワーク機器については日進月歩でテクノロジーが進化していきます。ソフトウェアでアーキテクチャを開発しなくても、高速ハードウェアの認定があればより効率性もあがるため、S2D(レノボのThinkAgile MX)はまさにそこをアピールしています。

昨今は大容量化も進んできていることもあり、少ないノード数でPBクラスの構成もサポートしています。

f:id:t_komiya:20181123111819p:plain

f:id:t_komiya:20181123112416p:plain

レノボでS2Dソリューション(ThinkAgile MX)を選択する理由について記載します。先ほども説明したベストレシピで認定構成をリリースしていることもありますが、今回の売りはThinkAgile Advantageサポートにあります。レノボのサポート窓口でハードウェアおよびソフトウェアを一括してサポートします。こちらの話はThinkAgile HXの認定ノードでも同様のことをお話しましたが、その内容と同等になります。

レノボが提供するソフトウェア選択型のNutanixノード~ThinkAgile HX認定ノードの登場!~ - LTN Blog 〜 Lenovo Technology Network 〜

 

f:id:t_komiya:20181123113254p:plain

f:id:t_komiya:20181123112544p:plain

f:id:t_komiya:20181123112658p:plain

ThinkAgile MXのハードウェアスペックをまとめてみました。NVMeやRDMAなどの最新ハードウェアの対応もありますが、ここでのポイントとしてはWindowsのAdminCenterとLenovo XClarityの連携により、XClarityのInventoryからWindows Server側のLogも閲覧できるようになっていて、管理性を向上させていますf:id:t_komiya:20181123113711p:plain

f:id:t_komiya:20181123113755p:plain

最後に2ノード構成のS2Dについて説明します。今回のWindows2019から新たにUSB Witnessの機能が追加されています。通常は外部でWitness用のサーバを立てる必要がありますが、こちらはルーター機器にUSBデバイスを差し込んで、2ノードのS2Dの監視を行うものです。構成図もイメージを載せておきますが、USB Witnessに対応しているルーターも現時点ではまだ数多く無いようです。今後増えていくと思いますので、いろんな周辺機器メーカーのページを参照して頂ければと思います。この構成により、ROBO(Remote Office / Branch Office)利用のHCIも出てくるかと思います。

 

WindowsプラットフォームでのHCIでお手軽の導入を考えていらっしゃるお客様は、是非検討頂ければと思います。

 

よろしくお願いします。

 

Nutanix Files(旧Acropolis File Services)の機能紹介【第二弾】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

以前のブログで紹介したNutanix Files(旧Acroplis File Services)の詳細についてお話したいと思います。今までは機能紹介で終わっていましたが、今回はもう少しオペレーションも含めてお話していきたいと思います。詳細はスライドの中にほぼすべて記載しているので、コメントは少なめです。

 

1.Nutanix Filesとは?

f:id:t_komiya:20181117214603p:plain

Nutanix FilesはNutanix上で実現するファイルサーバのことです。ホームディレクトリ、ユーザプロファイル、部門共有サーバなど様々な用途利用できます。Nutanix Filesは物理ホストで実現するのではなく、ファイルサービス用の仮想マシンを専用に構築する必要があります。実現できるハイパーバイザーとしてはAHVとESXiになり、現状はCIFS,NFSの両方のプロトコルに対応しています。容量増設もDSFに対応していることからとても簡単に行うことができます。

f:id:t_komiya:20181117215129p:plain

アーキテクチャについてお話します。Nutanixのクラスタ上に最小構成で3台の仮想ファイルサーバVMを構築する必要があります。この3台構成が必須になるのはNutanix上で高可用性を維持するために必要となります。

f:id:t_komiya:20181117215345p:plain

f:id:t_komiya:20181118162021p:plain機能についてお話します。共有サービスをディレクトリ・ファイルレベルで提供し、アクセス制御も行うことができます。また、高可用性で障害発生した場合にもFSVMでリソースが引き継げるようなアーキテクチャになっています。ユーザ毎に容量制限(クオータ)を設定することができます。1:Nのレプリケーションは対応していますが、NearSyncなどのRPOの短い要件には現状対応しておりません。f:id:t_komiya:20181117215709p:plain

ファイル共有については機能説明を省略させて頂きます。上記をご参照下さい。

2.ファイルサーバー用の仮想マシン

f:id:t_komiya:20181117220015p:plain

ファイルサーバーVMについてですが、最小4vCPU、12GBで構成され、ユーザの規模に応じてリソースの割り当てを変更してスケールさせていきます。詳細は後程紹介します。ファイルサーバーVMはNutanixのクラスタ以下にしなければならないため、3ノードの時は3ノード構成になりますが、最新のFilesでは1ノードや2ノード用のクラスタもサポートしているようです。また、上図で下のほうにABSと記載があるように、FSVMはストレージ部分とはiSCSI接続で利用します。

 

f:id:t_komiya:20181118161344p:plain

Nutanix FilesはSMB(CIFS) / NFSの両方のプラットフォームをサポートしていますが、共有やExportの設定はいづれかの設定になります。

f:id:t_komiya:20181118161532p:plain

 次にネットワークについてお話したいと思います。Nutanix Filesはクライアント側と通信を行う外部ネットワークとFSVMやCVMが冗長性を確保するための内部ネットワークを分けて形成します。そのため、FSVMを構築する際には、図のような形の構成を意識する必要がありますが、状況によってはネットワークの構成の変更が入る可能性もありますので、十分注意が必要となります。外部ネットワークにもActiveDirectoryやLDAP通信をできるようなネットワークを確保することが必要になります。

f:id:t_komiya:20181118162507p:plain

f:id:t_komiya:20181118162523p:plain

f:id:t_komiya:20181118162541p:plain

次にNutanix Filesでサポートされている機能を記載します。まずはサポートOSについてです。WindowsのクライアントOSはWindows7以降、WindowsサーバーOSはWndows2008以降になりますが、Windows2016に記載については現状NutanixのSupport Portal上も記載がないため、こちらを真として頂ければと思います。

また、FSVMの仕様についても記載しておりますが、こちらはNutanix社のReferenceになります。こちら以上の仕様については、複数台のFSVMを構築してスケールして設定して下さい。非同期DRの設定についても現状NearSyncなどの対応はしていないので、ご注意下さい。

f:id:t_komiya:20181118163111p:plain

f:id:t_komiya:20181118163151p:plain

クオータについて説明します。クオータについては、ユーザーとグループの2種類が設定できます。説明の通りでユーザー毎に容量を設定するのか、グループ毎に容量を設定するのかの違いです。また、クオータの設定内容については、ハードウェア的に制限するものと、ソフトウェア的に制限するものがあります。ソフトウェア的な制限を利用した場合は、利用者にメールで通知を行うことができます。

f:id:t_komiya:20181118175609p:plain

f:id:t_komiya:20181118175623p:plain

f:id:t_komiya:20181118175643p:plain

ファイルのパフォーマンスの最適化は、ファイルサーバーが負荷を受けているときにユーザーに通知し、最適化を改善するために変更を必要とします。この機能には、スケールアップ、スケールアウト、および再バランスのアクションが含まれます。

ストレージグループの中断によりパフォーマンスが低下するかどうかは、Prism Webコンソールから自動的に通知されます。ファイルサーバーページには、最適なパフォーマンスオプションの推奨事項が表示されます。

詳細はイメージにもコメントがありますので、参考にして頂ければと思います。

 

よろしくお願い致します。

 

Nutanixの障害シナリオについて学んでみよう!

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanixの障害シナリオについてお話したいと思います。

 

Nutanixはハードウェアおよびソフトウェアで構成されておりますが、ホストなどのハードウェアが障害があるケース、CVMなどのソフトウェアの障害またはネットワークなどの障害により挙動が違ってきます。今回はその想定される障害シナリオについていろいろとお話したいと思います。

f:id:t_komiya:20181111101419p:plain

障害シナリオについては、上記の記載した内容があります。

この中で、高密度型で導入していないお客様については、ブロックに関する障害はあまり関係ありませんが、どのようなケースなのかを覚えて頂くことも良いかもしれません。

f:id:t_komiya:20181111101835p:plain

ノード障害についてお話したいと思います。

物理障害であるため、ホスト・CVMの両コンポーネントがアクセスできなくなります。そのため、正常な物理ホストのみでクラスタを構成できるようになります。

こちらのスライドはその障害判断プロセスを記載しています。

実際に障害あった場合、ユーザはどのようにして気が付くのでしょうか?それを以下に記載します。

 

ユーザーには何が通知されるのでしょうか?

切り替え処理中に障害が発生したコントローラVMを持つホストは、共有ストレージが使用できないと報告 することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」 しているように見えます。ゲストVMデータのプライマリコピーは、障害が発生したコントローラVMにマップされたディスクに格納されているため使用できませんが、そのデータのレプリカにはまだアクセス できます。リダイレクトが行われるとすぐに、VMは読み取りと書き込みを再開できます。

IOが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10GbEネットワークを通過するため、 ほとんどのワークロードはユーザーに認識されるようには減少しません。

 

のノードが障害になった場合はどうなりますか?

2番目のコントローラVMの障害は他のホストのVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。しかし、さらに重要なことは、ゲストVMデータに追加のリスクがあることです。2つのコントローラVMを使用できないため、アクセス不能な2つの物理ディスクセットが存在するようになりました。RF2を持つクラスタでは少なくとも1つのコントローラVMが動作を再開するまで、一部のVMデータエクステントが完全に欠落する可能性があります。

 

f:id:t_komiya:20181111102415p:plain

ホスト障害時の挙動についてはこちらをご覧ください。

ノード障害が発生すると、他のノードでVMが再起動しますが他のノードにデータが存在していれば、問題なくデータにアクセスすることができます。ただし、3ノードで構成した場合は、障害時は正常なクラスタではありませんので、早急に復旧が必要になります。

 

ユーザーには何が通知されるのでしょうか?

HA保護されたVMにアクセスしているユーザーは、新しいホストでVMを再起動している間はそのVMを 使用できないことに気付きます。HAなしでは、VMを手動で再起動する必要があります。

 

別のノードが障害になった場合はどうなりますか?

2番目のホストの障害により、残りのホストの処理能力が不十分になり、2番目のホストからVMを再起動 する可能性があります。ただし、負荷の軽いクラスタであってもゲストVMデータに対する追加のリスクが懸念されます。

アクセス不能な2組の物理ディスクを使用すると、一部のVMデータエクステントが完全に失われる可能性があります。

 

f:id:t_komiya:20181111102836p:plain

f:id:t_komiya:20181111103024p:plain

次にドライブ障害について説明します。

ドライブには起動用の領域のブートドライブ、階層化データやOplog(書き込みデータ)がSSDおよびHDDなどのデバイスに格納されています。

それそれに対しての説明については、私の文章で記載することはなく、スライドの内容を参照して頂ければと思います。

ブートドライブについては、Lenovoの場合、2枚のM.2のSSDを利用してRAID1構成について冗長化していることから、1回の障害は保護できるような構成になっています。

 

ユーザーには何が通知されるのでしょうか?

スイッチング処理中に障害が発生したSSDのホストは、共有ストレージが使用できないと報告することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」するように見えます。

リダイレクトが行われるとすぐにVMは読み取りと書き込みを再開できます。IOが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10 GbEネットワークを経由するため、ほとんどのワークロードはユーザーに認識されるようには減少しません。

別のノードが障害になった場合はどうなりますか?

2番目のメタデータドライブの障害は、他のホスト上のVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。Cassandra Ringの回復機能は、第2の障害が回復プロセスが完了する前に起こらない限り、第2のノードを失うことに伴うリスクを軽減する。

f:id:t_komiya:20181111103122p:plain

メタデータドライブ(SSD)とデータドライブ(HDD・オールフラッシュ構成はSSD)については、クラスタ全体で複製されているため、単一障害では特に影響できることはありません。f:id:t_komiya:20181111103229p:plain

ネットワークの障害については、冗長化構成であれば、単一障害は問題ありません。1GbEのリンクにフェイルオーバーする場合とありますが、10GbEで組む構成が多いと思いますので、現状は気にすることはないと考えられます。

f:id:t_komiya:20181111103310p:plain

f:id:t_komiya:20181111103347p:plain

f:id:t_komiya:20181111103445p:plain

f:id:t_komiya:20181111103527p:plain

ブロックフォールトトレランスについては、ブロック(2U4Nのケースではあります)の時に関連する内容です。メタデータについてもBlockAwarenessも意識した構成が必要になりますので、十分注意が必要です。また、バージョンによってはEraser Codingのサポートにも影響があります

f:id:t_komiya:20181111103626p:plainブロックフォールトトレランスについてはデータ配置も構成も含めて図で示したほうがわかりやすいので、以下はイメージもつけて説明しております。

f:id:t_komiya:20181111103709p:plain

次にRedundancy Factorの話をしたいと思います。

こちらはRedundancy Factor3の内容になりますが、2ノードおよび異なるブロックの障害に耐えうる構成が必要になるオプションです。

デフォルトでは、Redundancy Factor2になるわけですが、クラスタのノードが増えれば増えるほど複数ノードの障害を考える必要があるので、こちらの設定が必要となります。詳細は以下のスライドをご参照下さい。

f:id:t_komiya:20181111103835p:plain

f:id:t_komiya:20181111103912p:plain

f:id:t_komiya:20181111103953p:plain

最後に劣化(Degrade)ノードについてお話したいと思います。

劣化したノードについてはパフォーマンスに悪影響を及ぼします。劣化ノードについては早期に検出して、リスクの軽減するための対策を立てる必要があります。詳細についてはスライドをご参照下さい。

f:id:t_komiya:20181111104036p:plain

f:id:t_komiya:20181111104157p:plain

ブログ内での説明よりもスライドの記載内容が多いため、コメントは少なめになってしまっておりますが、参考にして頂ければと思います。

 

よろしくお願いします。

 

Nutanix Guest Toolsについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanix Guest Tools(以下NGTと省略させて頂きます)のお話をしたいと思います。

 

VMwareなどをご利用されている方は(VMware Tools)ご存知かと思いますが、同様の機能でサービスとモジュールのセットです。

こちらを利用することにより、Nutanixの中で様々な機能を利用できるようになり、仮想マシンの管理性を向上させることができ、ユーザーとのシームレスなやりとりができるようになります。

f:id:t_komiya:20181110163040p:plain

NGTの機能については主に5つあります。

  • Nutanixゲストエージェント(NGA)サービス
  • ファイルレベルリストア用のCLIの提供
  • Nutanix VMモビリティドライバの提供
  • Windows VM用のVSSリクエスタとハードウェアプロバイダ
  • Linux VM用のアプリケーション一貫性のあるスナップショット

NGTをインストールして、CVMと通信できるようにして、機能を連携できるようにします。

VMのスナップショットからセルフサービスのリカバリ(ファイルレベルの復元とも呼ばれます)機能により、仮想マシン管理者の介入を最小限に抑えてNutanixデータ保護スナップショットからセルフサービス回復を実行できます。NGTを有効にして、VMにログインしてゲストVM管理者がディスクを接続すると、ゲストVM管理者はゲストOS内のファイルを回復できます。ゲストのVM管理者がディスクの切り離しに失敗した場合、24時間後に自動的にVMから切り離されます。

ESXiとAHV間のVMマイグレーションのためのドライバ、インプレースハイパーバイザ変換、およびクロスハイパーバイザディザスタリカバリ(CHDR)機能を提供することによってサポートします。NGTをインストールすることにより、クロスハイパーバイザディザスタリカバリ(CHDR)は、スナップショットからVMの保護、スナップショットの作成、スナップショットの複製、およびVMの復旧という保護ドメインを使用することにより、あるハイパーバイザから別のハイパーバイザへのVMの移行(ESXiからAHV、AHVからAHVへの移行)できるようになります。

AHVまたはESXi Windows VMのアプリケーション一貫性のあるスナップショットを有効にします。NGTがVMにインストールされる前に作成されたハイパーバイザベースのスナップショットからNGTを実行しているVMが復元されると、VMはNGTなしで復元されます。

仮想マシン静止時に特定のスクリプトを 実行することによってLinux仮想マシンのアプリケーション整合のスナップショットをサポートします。WindowsとLinuxのNGT対応の詳細については以下をご参照ください。

f:id:t_komiya:20181110171419p:plain

Nutanixゲストツールの要件と制限

NGTを使用するすべての機能は、次の要件を満たす必要があります

一般的な要件と制限

  • 仮想IPアドレスはNutanixクラスタで設定する必要があります。クラスタの仮想IPアドレスが変更されると、 クラスタ内で実行されているすべてのNGTインスタンスが影響を受けます。
  • VMにはISOを添付するための空のIDE CD-ROMスロットが少なくとも1つ必要。
  • NGT-Controller VMサービスと通信するには、ポート2074を開いておく必要があります。
  • ハイパーバイザー:ESXi 5.1以降のリリース、AHV(20160215以降のバージョン)
  • VMはクラスタの仮想IPアドレスを使用してアクセスできるネットワークに接続する必要があります。
  • Windows Server版VMの場合、NGTのインストールを開始する前にMicrosoft VSSサービスが有効になっていること。
  • VM IQNを変更し、NGTのリフレッシュサイクル(現状5分)が発生する前に、VMのスナップショットを作成すると、 スナップショット操作がVM-VG接続をキャプチャできないため、NGTは自動復元機能を提供できません。 この問題を回避するには、Linux VMで$ sudo service ngt_guest_agent restartコマンドを実行し、Windows VMのサービスタブでNGTを更新することでnutanixゲストエージェントサービスを手動で再起動できます。
  • PowershellのパスはNGTのインストール環境で利用できる必要があります。それ以外の場合、NGTのインストールは失敗します。
  • Linuxオペレーティングシステムの場合、NGTは/ usr / localにインストールされます。したがって、ユーザーにこの場所に対する書き込み権限があることを確認する必要があります。

オペレーティングシステムが特定の機能に対してサポートされているかどうかを確認するには、特定のNGT機能について、サポートされているオペレーティングシステム情報を参照。

その他の制限については以下に掲載しておきます。

f:id:t_komiya:20181110171742p:plain

Nutanix導入後は仮想マシンにNGTの導入を忘れずにお願いします。

よろしくお願いします。

 

AOSのサポートポリシーについて~LTSとSTSについて~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はAOSのサポートポリシーについてお話したいと思います。

今後のAOSのソフトウェア管理のナレッジにして頂ければと考えております。

  1. LTSとSTSについて

f:id:t_komiya:20181102214039p:plain

Nutanixは2018年4月にリリースしたAOS5.6以降で製品のライフサイクルを変えてきております。今回はその変更になったソフトウェアのサポートについてお話したいと思います。

LTS(Long Time Support)とSTS(Short Time Support)

AOS5.5までは通常通りのソフトウェアリリースでサポートも15か月のメンテナンスサポートを提供してきましたが、AOS5.6より機能を重視したSTS(短期間のサポートであるが、機能を重視したソフトウェアリリース)LTS(機能性よりもバグフィックスで長期間ソフトウェアをサポート可能にしたソフトウェアリリース)の2つのサポートになっています。

私もAOSの新規リリースで機能紹介をしてきておりますが、実際に短期間(6か月間)しかないサポートでお客様が利用することは少ないことから、日本のお客様はほぼAOS5.5以降はアップグレードを見送るケースが増えてきております。

実際にLTSのファームウェアは現在AOS5.5になるわけですが、こちらのバージョンで利用するお客様が多いのですが、これがいつまでサポートされるかと考えると、安心できるものではありません。

f:id:t_komiya:20181102221430p:plain

こちらは現在サポートされる一番古いバージョンから最新のファームウェアまでのEOLスケジュールを記載しております。

これを見ると、AOS4.7が2019年1月までとなっております。それ以外にもAOS5.1もまもなくサポートが終わりますし、STSではAOS5.8が2019年1月に終了となります。

LTSでの最新はAOS5.5でありSTSではAOS5.9となります。

f:id:t_komiya:20181102215837p:plain

しかしながら、AOS5.5にアップグレードに上げたとしても、2019年4月にはEnd of Maintenanceを迎えてしまうため、次のLTSのAOSのリリースが待ち望まれます。

現在、AOS5.5にアップグレードしていないお客様は是非アップグレードをお願い致します。

2. アップグレードパスについて

f:id:t_komiya:20181102220012p:plain

AOSのバージョンアップを実施するにあたり、アップグレードのパスを確認する必要があります。アップグレードパスの確認は上記にも記載があるURLをご参照下さい。

こちらで現状AOSのバージョンから指定されたAOSまで直接アップグレード可能なのかそうでないのか含めて確認することが可能です。

是非アップグレード前にチェックをお願いします。(アップグレードの画面においても確認するができます)

 

3. アップグレードについて

f:id:t_komiya:20181102220412p:plain

アップグレードについては、Prismの画面から歯車のアイコンをクリックしてUpgrade Softwareを選択することで対応可能です、

アップグレードしたいバージョンのAOSを選択してInternet経由でAOSのイメージダウンロードしてオンラインでアップグレードする方法とAOSのイメージとAOSにMETADATAをアップロードしてオンラインでアップグレードする2種類があります。

オンラインのアップグレードについては、主にインターネットに接続されていない環境で利用します。

 

サポート期間の短いAOSをお使いのお客様は是非ご確認頂ければと思っております。

 

よろしくお願い致します。

Nutanixのクラスタのコンポーネントを覚えてみよう!

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はNutanixのクラスタについてお話したいと思います。

 

今回の内容については、Nutanix Bible(http://nutanixbible.jp/)にも記載している内容になりますが、実際には単語レベルでの説明はあるものの各プロセスについての詳細に書かれていないため、筆者が理解できるようにいろいろとまとめてみました。

f:id:t_komiya:20181031003027p:plain

Nutanixクラスターには分散アーキテクチャーがあり、クラスター内の各ノードはクラスターリソースおよびその重要性を共有しています。各ノードにはクラスタ操作中に特定のタスクを実行するソフトウェアコンポーネントがあります。

すべてのコンポーネントは、クラスタ内の複数のノードで実行され、コンポーネントを実行する役割の間で接続が依存しています。ほとんどのコンポーネントは、他のコンポーネントにも依存しています。

 

Zeus

分散システムの重要な要素は、すべてのノードがクラスターの構成を保管して更新します。内容はホストやディスクなどのクラスタ内の物理コンポーネント、およびストレージコンテナなどの論理コンポーネントに関する詳細が含まれます。これらのコンポーネントの状態(IPアドレス、容量、データ複製ルールなど)もクラスタ構成に格納されます。

Zeusは他のすべてのコンポーネントがクラスタ構成にアクセスするために使用するNutanixライブラリです。現在、Apache Zookeeperを使用して実装されています。

 

Cassandra

CassandraはNutanixデータストアに格納されているゲストVMデータに関するすべてのメタデータを格納している分散型の高性能でスケーラブルなデータベースです。NFSデータストアの場合、Cassandraはデータストアに保存された小さなファイルも保持します。ファイルのサイズが512Kに達すると、クラスタはデータを保持するvDiskを作成します。

Cassandraはクラスタのすべてのノードで実行されます。これらのノードはGossipプロトコルを使用して1秒に1回、互いに通信し、データベースの状態がすべてのノードで最新であることを保証します。

CassandraはZeusに依存して、クラスタ構成に関する情報を収集します。

ZooKeeper

Zookeeperはクラスタに適用される冗長度に応じて、3つ(RF2)または5つ(RF3)のノードで実行されます。複数のノードを使用すると失効したデータが他のコンポーネントに返されるのを防ぎます。一方、奇数を使用すると、2つのノードが異なる情報を持つ場合に繋ぎを解除する方法が提供されます。

これらの3つのノードのうち、1つのZooKeeperノードがリーダーとして選出されます。リーダは情報の要求をすべて受信し、2つのフォロワノードに付与します。リーダーが応答を停止すると、新しいリーダーが自動的に選出されます。

Zookeeperには依存関係がないため、他のクラスタコンポーネントを実行しなくても起動できます。

 

f:id:t_komiya:20181031004531p:plain

Medusa

他のシステム(仮想マシンをホストするハイパーバイザーなど)のデータを格納する分散システムには、そのデータの格納場所を把握する方法が必要です。Nutanixクラスタの場合、そのデータのレプリカが格納されている場所を追跡することも重要です。

Medusaは、このメタデータを保持するデータベースの前に存在しているNutanixの抽象化レイヤーです。データベースは、Apache Cassandraの変更された形式を使用して、クラスタ内のすべてのノードに分散されます。

Stargate

他のシステム(ハイパーバイザなど)にストレージを提供する分散システムでは、受信するデータを受信し処理するための統合コンポーネントが必要です。Nutanixクラスタには、この責任を管理するStargateという大きなソフトウェアコンポーネントがあります。

ハイパーバイザーの視点からStargateはNutanixクラスターの主要な接点です。すべての読み取りおよび書き込み要求は、NutanixのvSwitchを介して、そのノード上で実行されているStargateプロセスに送信されます。

Stargateはメタデータを収集するMedusaとクラスタ構成データを収集するZeusに依存します。

Curator

分散システムではプロセス全体を監視するコンポーネントを持つことが重要です。未使用のデータブロックを指すメタデータが蓄積されたり、ノード間またはディスク階層間でデータのアンバランスが発生する可能性があります。

Nutanixクラスタでは、各ノードがこれらの責任を扱うCuratorプロセスを実行します。Curatorのマスターノードは、メタデータデータベースを定期的にスキャンし、スターゲイトまたは他のコンポーネントが実行すべきクリーンアップおよび最適化タスクを識別します。メタデータの分析は、MapReduceアルゴリズムを使用して他のCuratorノード間で共有されます。

Curatorはどのノードが利用可能であるかを知るためにZeusに依存し、メタデータを収集するためにMedusaを使用します。その分析に基づいて、Stargateにコマンドを送信します。

Prism

ユーザーがアクセスできない場合、分散システムは役に立たない。Prismは管理者がNutanixクラスタを構成および監視するための管理ゲートウェイを提供します。これには、nCLIおよびWebコンソールが含まれます。

Prismはクラスタ内のすべてのノードで動作し、他のコンポーネントと同様に、リーダーを選択します。すべてのリクエストは、Linux ip tablesを使用してフォロワーからリーダーに転送されます。これにより、管理者は任意のコントローラVM IPアドレスを使用してPrismにアクセスできます。Prismリーダーが失敗した場合、新しいリーダーが選出されます。

Prismはクラスタ構成データ用にZeusと通信し、統計情報はユーザーに提示するためにCassandraと通信します。また、VMステータスおよび関連情報についてESXiホストと通信します。

 

少し難しい内容になっておりますが、Nutanixの重要なコンポーネントであるため、今後Nutanix Bibleを読むときに役立てて頂ければ幸いです。

 

よろしくお願い致します。

 

Nutanix FLOWについて【第二弾】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はFLOWについてのご説明をしたいと思います。以前記事の中で取り上げたのですが、マイクロセグメンテーションの機能に思われるところがありましたので、今回はもう少し内容を説明したいと思います。

 

以前FLOWに関して投稿した記事

マイクロセグメンテーション(FLOW)の詳細について~AOS5.6機能紹介~ - LTN Blog 〜 Lenovo Technology Network 〜

 

f:id:t_komiya:20181022212149p:plain

AHV仮想ネットワーキングに固有のもので、Open Virtual Switch(OVS)に基づいています。 Flowの機能を活用するためにインストールする追加のソフトウェアやコントローラはありません。

機能としては、視覚化・ポリシー決め・マイクロセグメンテーション・ネットワーキングです。

直感的でスケーラブルなソリューションでかつ1クリックで利用可能です。

 

f:id:t_komiya:20181022212744p:plain

FLOWは、アプリケーションの可視性、VM マイクロセグメンテーション(仮想マシン間のファイアウォール)、およびサービスチェイニングの3つの主要機能から構成されます。FLOWのビジョンは、包括的なSDN製品であることです。

 

FLOWの可視化

  • VM間のフローの自動検出
  • アプリケーションのトラフィックと関係を視覚化する
  • 最小のアプリケーションドメインの知識が必要

適切なアプリケーション中心のネットワークポリシーを設定するには、ワークロードの動作を完全に理解する必要があります。 Nutanix Flowは、VM間の通信をリアルタイムで視覚化し、環境に適したポリシーを簡単に設定することができます。

すべてがここから始まります。ポリシーの構築を開始するには、アプリケーションに関連するVMの基本知識のみが必要です。

FLOW マイクロセグメンテーション

  • 常時接続のステートフルVMレベルファイアウォール
  • 簡単なポリシーの作成と適用
  • App centric - ネットワークIDから切り離された
  • VM変更管理の自動更新
  • VMを変更する(新しいプロビジョニング、新しいIP、マイグレーション)場合、ポリシーはユーザーの介入なしに自動的に更新できます

マイクロセグメンテーションは、仮想マシン(VM)またはVMのグループとの間のすべてのトラフィックの詳細な制御とガバナンスを提供します。これにより、アプリケーション層または他の論理境界間の許可されたトラフィックのみが許可され、仮想環境内に伝播する高度な脅威から保護されます。

マイクロセグメンテーションは、従来の境界ファイアウォールとは異なり、特定のネットワークセグメント(VLANSなど)や識別子(IPアドレス)ではなく、VMとアプリケーションにネットワークポリシーを割り当てることができます。ポリシーは、VMライフサイクル全体を通じて自動更新され、ポリシー変更管理の負担を取り除きます。

サービスチェーン/ネットワーク機能

  • パートナーとの統合によるネットワーク機能の拡張
  • VM間で複数のサービスを接続する
  • トラフィックリダイレクションの詳細な制御

Nutanix Flow機能を拡張して、サードパーティのソフトウェアから仮想化ネットワーク機能を活用することができます。これらのサービスは、VMトラフィックとインラインで挿入され、すべてのトラフィックに対して簡単に有効にすることも、特定のネットワークトラフィックに対してのみ展開することもできます。挿入可能な一般的なネットワーク機能には、仮想ファイアウォール、ネットワーク脅威検出(IPS / IDS)、アプリケーションパフォーマンス監視(APM)、または一般的なアプリケーションネットワーク診断が含まれます。

f:id:t_komiya:20181022213320p:plain

視覚化についてはポリシーを含めて対応します。またアプリケーションレベルで視覚化するために、Netsil(今後はEpoch)を統合して機能を対応します。

f:id:t_komiya:20181022213946p:plain

FLOWはネットワークの機能とセキュリティの自動化の機能を兼ね備えております。

Webhook APIでVLANのマッピングやディスカバリを行います。LenovoのスイッチもAPIを利用することでプロビジョニングの自動化を行います。

また、アプリケーション・仮想マシンの展開もPrism Central/Calmを利用することで対応します。 

将来の対応については、VXLANの対応などがあげられます。

 

f:id:t_komiya:20181022215753p:plain

お客様がどのようなシーンでFLOWを利用するのかを考えてみましょう。

マルチクラウドによるソフトウェアな境界線であることから今までのようなアプローチでセキュリティ対策を行いとコストがかかります。

またセキュリティの攻撃やスピードも増加するなどで高価値のデータがターゲットになりますし、インフラが複雑化することでモダンなアーキテクチャを利用したり、マイクロサービス/コンテナなどの対応もしなければならない。

セキュリティのオペレーションするスタッフも手動で対応することがボトルネックなることもあり、1クリックや自動化でセキュリティ行う必要があります。

 

f:id:t_komiya:20181022221141p:plain

f:id:t_komiya:20181022221303p:plain

 

f:id:t_komiya:20181022221842p:plain

上記3つのシナリオについては、前回の記事にも記載がありますので、説明は割愛させて頂きますが、VDIのスライドについては再度説明します。

隔離ポリシーは完全なVM隔離(ネットワークなし)または管理上定義された一連のアプリケーションが隔離されたVMと通信できる「フォレンジック」にすることができます

検疫はAPIを使用して手動またはプログラムで行うことができます

インバウンドフォレンジックの例には、リモートアクセス用のSSH / RDP、パッチツール、または分析やウイルスの駆除にITが使用するその他のツールがあります

 

f:id:t_komiya:20181022222022p:plain

FLOW+マイクロセグメンテーションによってHCI(Enterprise Cloud)の保護を行うことができます。セキュリティの境界化・マイクロセグメーションによる細かい制御やスケールを実現し、セキュリティ運用を簡素化します。

f:id:t_komiya:20181022222236p:plain

最後にFLOWのポイントをまとめてきました。

 

よろしくお願い致します。