LTN Blog 〜 Lenovo Technology Network 〜

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

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のポイントをまとめてきました。

 

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

Microsoftサポート、セキュリティ機能強化~AOS5.9の機能紹介~

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

本日は今週リリースされたAOS5.9の機能紹介をしたいと思います。

今回のAOS5.9の機能追加について、リリースノートで記載されている内容がありますので、そちらを紹介します。

http://vcdx56.com/2018/10/nutanix-aos-prism-central-version-5-9-and-more-released/

リリースノートには記載はありませんが、先日の記事でご紹介したSAP HANA対応のAOSもこのバージョンからになります。

 

今回の機能追加についてご紹介していきたいと思います。

f:id:t_komiya:20181007001705p:plain

 

主な機能追加はこちらの3つに集約されていますが、それ以外の機能追加も最後のほうに紹介いたします。

f:id:t_komiya:20181007002213p:plain

 

ラックの認識とありますが、ブロックの集合体を大きくしたものです。ラック構成にすることでトップオブラックのスイッチが障害が起きた場合でもデータのアクセスすることができます。かなり大規模の構成の場合に利用するケースはありますが、小規模ではあまり利用することはないと思います。

ラックにおけるフォールトトレランスの内容については、サポートポータルに記載がありましたので、こちらに合わせて記載致します。なお、ラックのフォールトトレランスが利用できるのはAHVおよびESXiのみとなります。

f:id:t_komiya:20181007003123p:plain

NearSyncの機能拡張になります。VSSをサポートすることによりアプリケーションの整合性を意識したスナップショットを実行できるようになりました。またNearSync対応ドメインでサードパーティベンダーのバックアップをサポートします。

f:id:t_komiya:20181007003401p:plain

セキュリティ機能の強化となります。バックグランドで暗号化をサポートしています。

  • ソフトウェアの暗号化は、既存のデータを持つクラスタまたはコンテナで有効
  • ネイティブキー管理サーバー(KMS)と外部KMSの切り替えがサポート

 

AOS 5.9でのソフトウェアの暗号化サポートを拡大

  • 外部(EKM)およびローカル(LKM)キー管理で動作
  • FIPS認証は「対応予定」でステータスであり、リリースは2018年末に予定されています
  • ESXiおよびHyper-Vについてはコンテナレベルの暗号化はオプション
  • AHVはクラスタレベルのみ -  2018年末でVMレベルも対応予定ですが、5.9で既存のデータで有効にすることができます

AOS 5.9の新機能は、既存のデータの暗号化をサポートする機能です。 5.8での暗号化は、ESXiの空のコンテナまたはAHVの空のクラスタでのみサポートされていました。これは、既存のデータに対してソフトウェア暗号化を使用するために複雑な移行が必要でした。

AOS 5.9では、ハイパーバイザー上の既存のデータを無停止で暗号化するために、お客様は「1回限りの」バックグラウンドプロセスを活用できます。ワンクリックで簡単誰でもSW暗号化を開くことができます。

 

f:id:t_komiya:20181007020004p:plain

Microsoftのサポートについてですが、AOS5.9に対応内容としては、CalmでのAzureのデプロイが可能になったこと、Hyper-VでMetro Availabilityが対応したことです。これで主要のクラウドプロバイダーに対してマルチクラウドの環境が整います。

 

その他の機能について、追加されたものを見てみましょう。 

f:id:t_komiya:20181007021250p:plain

NVIDIAのTesla V100のサポートが記載されていますが、OEM各社のサポートはそちらに依存しますので、ご注意下さい。(ESXiの正式サポートも同様です)

RDMAについてもサポートについて同様ですが、LenovoのHXシリーズについてコメントすると全機種2つ以上のインタフェースを搭載可能になりますので、プラットフォームでの未サポートはないと考えられます。

f:id:t_komiya:20181007021605p:plain

f:id:t_komiya:20181007021906p:plain

Prism CentralでのNGT管理ができるようになりました。またLinuxのゲストクラスタリングのサポートもしています。メニューについても変更されておりますので、一瞬違和感を感じるかもしれません。

Nutanix KarbonがTech Previewでリリースされております。

f:id:t_komiya:20181007022215p:plain

 Prism Centralの追加機能になります。Azure対応以外にWhat If分析の機能追加とJenkinsプラグインなどが入っています。また、マーケットプレイスにBlueprintを共有できるようになりました。

 

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

ADS(Acropolis Distributed Scheduler)に関して

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

本日はNutanixのAHV上で仮想マシンのスケジューリングするADS(Acropolis Distributed Scheduler)のお話をしたいと思います。

本機能については、VMwareのことをご存知の方はお気づき方と思いますが、こちらはDRS(Distributed Resource Scheduler)と同様の機能だと思って頂ければと思いますが、機能は非常にシンプルになっています。 

Acropolis Distributed Schedulerについて 

f:id:t_komiya:20181002212903p:plain

ADSの目的は以下の通りです。

仮想マシンの初期配置

  • 新しい仮想マシンを最適なホストに配置する

ホスト内のリソースの競合を避ける

  • CPU(ホストのCPUが閾値85%を超えると移行が始まる)
  • ストレージコントローラ(CVMのCPUが閾値85%をStargateに使用されると移行が始まる)
    ABS(Nutanix Volume)も対象
  • ルール違反のスケジューリング
ホットスポットを検出するインテリジェントシステム
  • ホットスポットの回避
  • ワークロードの変化に反応しない

  • ワークロードに必要なリソースを確保
  • オペレータの介入なし
  • 負荷分散しない

仮想マシンのアフィニティポリシー

  • 選択したホストグループに仮想マシンを保持

仮想マシン間のアンチアフィニティポリシー

  • 異なるホスト上で仮想マシンの分離を保証

プロビジョニングした仮想マシンを最適なホストに配置して、ホスト内のリソース競合を避けるためようにすることが目的であり、VMwareのDRSのように細かな設定を行うことはありません。アフィニティポリシーについても非常にシンプルなものとして設定可能になっています。

また、仮想マシン起動時の初期配置および15分間隔で状態をチェックします。

 

 異常が見つかった場合は、次の方法で修復します。

  a)仮想マシン移行計画

  b)ABS iSCSIセッションの再指示

 

 異常検出

・15分毎

・ホストリソースが過負荷になっていないか確認する

  • 潜在的に十分なリソースを獲得できない仮想マシンがないとチェック

・ポリシーに違反していないかどうかをチェック

 

需要予測

・競合するノード上のリソースの需要予測が困難

・統計は現在どのくらいの割合で取得しているのか指定

・現在の値を選択すると、移行がたらいまわしにされる可能性があります

・現在の解決策は、コンバージェンスがより迅速になるように固定比率(+20%)で需要を拡大すること

 

ストレージCPUの計算

・Stargateはスレッドカウンターを発行

  • 各vdiskコントローラが費やした時間を指定(vdiskにマップされます)

・Vdiskカウンタは対応する仮想マシンおよびSoSANをターゲットに集約

・StargateのCPU使用率に基づく割り当て

・Storage CPU が通常の仮想マシンCPUに追加

  • I/Oヘビーな仮想マシンをコンピュートヘビーノードへの移行を妨げます
  • ハイパーコンバージド環境での特定が重要

 

VMwareのDRSと異なり、仮想マシンと合わせてストレージパフォーマンスをモデル化しません。

固定化されている機能であるため、特別にカスタマイズすることなく利用できます。

 

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

ついに出たミッションクリティカル向けのNutanixモデル(ThinkAgile HX for SAP HANA)~ThinkAgile HX7820/HX7821のご紹介~

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

本日は先日USで発表されたSAP HANA向けのNutanixモデルのThinkAgile HX7820/7821をご紹介したいと思います。

本記事をご参照頂くにあたり、以下のブログの記事も合わせて参考にして頂くとモデルの詳細を理解できると思いますので、よろしくお願いします。

 

HCIの10Gbで本当に大丈夫!?~AHV Turboを少し調べてみよう~ - LTN Blog 〜 Lenovo Technology Network 〜

 

Nutanixがパフォーマンスを必要とするエンタープライズアプリケーションに最適なソリューションである理由 - LTN Blog 〜 Lenovo Technology Network 〜

 

SAP環境にNutanixは最適なんです!~Nutanix Solution for SAP on Lenovo HX Series~ - LTN Blog 〜 Lenovo Technology Network 〜

 

まず初めにSAPに関する要件について一度ご説明したいと思います。

SAP HANAがリリースされる前はOracleやSQL Serverなどを利用してプラットフォームを構築していましたが、一つのプラットフォームに統一しリアルタイムにデータを分析してビジネスをサポートしながら、ハードウェアやオペレーションコストを削減してきました。 

f:id:t_komiya:20180923232002p:plain

しかしながら、従来型に比べて1/3のラックスペースとあるが、SAP HANAであっても3Tier構成である以上、インフラのオペレーションは一向に楽になるわけではなくハードウェアを含むインフラの柔軟性が必要となります。そこで考えつくのがハイパーコンバージドのようなインフラに対応していればよいと考えつくと思います。

f:id:t_komiya:20180923232515p:plain

ハイパーコンバージドは迅速性・柔軟性に加え、自動修復機能などの障害時のオペレーションにも非常に効果的なソリューションであります。運用についても1クリックで運用できることで、これがSAP HANAが対応していれば問題ないのですが、つい最近までNutanix(特にAHV)には対応しておりませんでした。

これが先月ようやくAHVでの認定が発表されたことにより、Nutanix上でのプラットフォームでSAP HANAが提案できるようになります。(製品リリース秋頃の予定)

なぜ、ハイパーコンバージドでSAP HANAが動作させる必要があるのかをご説明します。f:id:t_komiya:20180923233432p:plain

ハイパーコンバージドを選択することにより、コンピュート・ストレージのノードをノード単位でスケールさせることが可能です。これで増設時もサイジングも苦労することありませんし、何よりオンラインで増設が可能になることから、業務への影響は少なくなります。

もちろん現状のサーバでSAP HANAが動作するサーバで適応すればよいのですが、SAP HANAの要件として4ソケットモデルが必須要件になるため、従来の2ソケットサーバでは対応不可となります。レノボの場合、ThinkSystem SR950(最大8ソケットまで搭載可能)のモデル(ThinkAgile HX7820/HX7821)でこちらのソリューションに対応します。

SAP HANAがパフォーマンス的に構成で認定されたモデルが今回リリースされたわけですが、こちらのモデルはNutanixのNXシリーズではラインナップにございません。

こちらのモデルについての強みも含めてご説明したいと思います。

f:id:t_komiya:20180923235447p:plain

そもそもLenovoがSAPのビジネスに関してWWではトップシェア(アプライアンスモデル)になっています。そのため、SAPビジネスについては熟知した知識をフルに活用して出来上がったモデルです。もちろん、ハードウェアそのもので高速性、可用性も兼ね備えております。そのモデルをLenovo/Nutanixで共同イノベーションでリリースしたわけであります。(ミッションクリティカル要件のため、信頼性の高いハードウェアが必要)

パフォーマンスについてもWorld Recordを持っていますので、非常に高評価のプロダクトになります。

 

ここで、一度ThinkAgile HXのラインナップを整理してみましょう。

f:id:t_komiya:20180923235030p:plain

f:id:t_komiya:20180923235047p:plain

今回のThinkAgile HX7820/HX7821はハイエンドモデルになります。従来のHX7500シリーズに比べてCPUスペックだけでなく、搭載しているストレージに関してもより高速なデバイスが選択可能になっています。(今回は認定ノードも合わせてリリースしています)

f:id:t_komiya:20180923235546p:plain

詳細なスペックはこちらのスライドです。ここでポイントなのは搭載ドライブとネットワークインタフェースです。NVMeと25GbEについて以前AHV Turboで話題を取り上げましたが、ようやくこちらのデバイスを利用することでAHV Turboの本領を発揮できるようになります。もちろんインメモリデータベースのSAP HANAは高速でアプリケーション上のメモリのアクセスも必要となりますので、MellanoxのRDMAなどもサポートしていれば、さらに高速することは間違いないのですが、現状RDMAは未サポートになります。

また、こちらのモデルはAOS5.9(次期AOSのバージョン)でサポートになります。

ここでいくつか補足致します。

・CPUについては本番環境で利用する場合はPlatinumのCPUを選択が必須

・現状は3CPUが物理で必要なため、4ソケットモデルが必須

・メモリは最大2.3TBまでサポート

・TDIモデルではNVMeや25GbEのNICは現状未サポート

f:id:t_komiya:20180924002701p:plain

また、大容量メモリの環境をサポートするために、NUMA環境をサポートする必要があります。今回これを仮想マシンからも利用できるためのvNUMAも合わせてサポートする必要がありますが、こちらはすでにAHVでは実装されております。

f:id:t_komiya:20180924000221p:plain

上記スライドは今回のソリューションが適していると思われるお客様の一例を記載しております。既存のHANAユーザはインフラのスケーラビリティとTCO削減する運用ができることが特徴になります。

SAPの2025年問題のことを考えると既存で3rdパーティのDBを利用しているお客様から見た場合、DBは作り直しになりますので、それを機にSAP HANAへの移行を検討したほうが良いと思われます。

既存HCIのユーザから見た場合は、新規にSAP HANAのサークロードをサポートすることで、さらにHCIへの環境にアプリケーションを移行できることがプラスの材料になることでしょう。

f:id:t_komiya:20180924001632p:plain

ThinkAgile HX7820/HX7821がSAP HANA専用にリリースされているように見えるわけですが、実はほかにも利用用途があります。

こちらのスライドで載せていますが、ブロックチェーンなどの用途利用することが想定されます。ビットコインのように複数のトランザクションの結果をネットワーク上で共有するようなワークロードについては今回のマシンが最適であると考えられています。そのため、冗長性なども考えると高可用性(ファイブナインレベル)が要求されます。

 

Enterprise Cloud OSもミッションクリティカルのアプリケーションをサポートしてきております。これを機にAHVの導入を本格検討してみてはいかがでしょうか。

 

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

 

AHVのHighAvailability(高可用性)について

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

本日はAHVのHighAvailability(以下HAで省略)に関して説明したいと思います。過去にAHVの機能比較の記事でHAの内容に触れていたかと思いますが、簡単に説明しただけで終わっていましたので、今回はもう少し説明したいと思います。

記事については、以下を参照してください。

blog.lenovojp.com

 

HAの方式については、以前のブログでお話した通り2種類存在します。

1.ベストエフォート

2.リザベーション

 

・ベストエフォート方式について

f:id:t_komiya:20180917223824p:plain

HAの設定についてはFoundationでセットアップ後に組まれていますが、Prismのメニューで「Manage VM High Availablity」というメニューで「Enable HA Reservation」のチェックのON/OFFで設定が決まります。

設定をOFFのままであれば、ベストエフォートになり、ONにすればリザベーション(予約)になります。

  • Acropolisは、ホストがダウンした場合に管理する仮想マシンの高可用性を提供
  • 正常でないホストが修復されている間に、別の正常なホスト上で仮想マシンが再起動されます
  • ホストが修復されている間、仮想マシンが長期間停止する心配はありません
  • ストレージの高可用性の最大はRF-3であるため、最大2つのホスト障害をサポートします

 

ベストエフォートの場合、障害発生後は自動で再起動しますが、デフォルト設定なので、ノードで使用可能なリソースに基づいて、他のクラスタノード上の仮想マシンの復旧と電源投入を行います。エンタープライズクラスの機能を最初から有効にすることは非常に効果的ですが、ベストエフォート型のオプションでは、リソースの制限のために仮想マシンの電源がオンにならない状況が発生する可能性があります。

f:id:t_komiya:20180917224834p:plain

より定義された復旧モデルの場合、AHVは仮想マシンの高可用性を保証するために、クラスタ内に必要なリソースを予約することができます。デフォルトのベストエフォート機能と同様に、リザベーション(予約)モードも用意されており、ワンクリックで選択できます。

 

・リザベーション(予約)方式について

f:id:t_komiya:20180917225732p:plain

チェックを入れることにより、AHVはNutanixクラスタを分析し、復旧に最適な高可用性ポリシーを選択します。現時点では、システムは、確立された高可用性ポリシーに基づいて新しいVMを確実に回復できるようにポリシーを設定します。AHVは、ポリシーをクラスタ内の使用可能なメモリに基づいており、次の可用性ポリシーを提供します。

  • ホストのCPUとメモリの使用状況を追跡します
  • ホスト機能の対象となり、仮想マシンのポリシーに準拠した仮想マシンを配置
  • 仮想マシンの高可用性を保証するリソースを予約

 

リザーブド・セグメント:AHVは、単一ノードを専用ノードに割り当てるのではなく、クラスタ内のノード全体に高可用性リカバリ・ポイントを分散します。ハイアベイラビリティイベントが発生すると、障害の発生したホスト上で実行されている仮想マシンは、クラスタ内の他のノードで再起動します。

 

サポートするポリシーについて

  • データローカリティを維持します
  • QoSを保証します
  • 特定のリソースタイプとの相関関係を決定づける
  • ハードウェア/ソフトウェアポリシーの制約に従う
  • ワークロード間の干渉を避ける
  • 集合的なリソース要件を優先する

f:id:t_komiya:20180917230334p:plain

予約された構成では、仮想マシンの高可用性設定は、確立されたNutanixクラスタのフォールトトレランスレベルに応じて、クラスタ全体でリソースを予約します。仮想マシンの高可用性の構成では、次のことから保護するために必要なリソースが予約されています。

  1. NutanixコンテナがReplication Factorが2で構成されている場合、1台のAHVホスト障害まで許容
  2. NutanixコンテナがReplication Factorが3で構成されている場合、2台のAHVホスト障害まで許容

Nutanixは、クラスタから入手可能な詳細に基づいてリカバリオプションを自動的に選択することにより、高可用性のリカバリ方法の選択を簡素化します。ベストエフォート型のデフォルトを超えて仮想マシンの高可用性を有効にすると、新しい仮想マシンの高可用性に対応するのに十分なリソースがポリシーで確保できる限り、新しく作成された仮想マシンの電源を入れることができます。

仮想マシンの高可用性はハイパーバイザベースの高可用性のイベントでのみ、実行中の仮想マシンのリカバリ性を考慮した構成にする必要があります。ハイパーバイザベースのイベントは、Nutanixソリューション内のストレージまたはCVMイベントを含む高可用性とは異なります。ストレージまたはCVMイベントには、(定義されたレプリケーションファクタに基づいて)データレプリケーションによるリカバリと、クラスタ内のリモートCVMへのリダイレクトが含まれます。

 

詳細はNutanixのポータルサイトに記載がございます。

https://portal.nutanix.com/#/page/docs/details?targetId=Web-Console-Guide-Prism-v52:wc-high-availability-acropolis-c.html

 

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

 

AHVの仮想ネットワーク設定について

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

本日はAHVの仮想ネットワークに関してお話したいと思います。

 

仮想環境を構築するときに、仮想マシンが通信するネットワークを設定すると思います。今回はVMwareでの設定における内容とAHV上でどのように管理させるのかをご説明したいと思います。

まずは、VMwareで設定する場合について、以下でご説明したいと思います。

ESXのホスト上で仮想スイッチの設定する場合には、すべてのESXホストで同一の設定にする必要があります。

f:id:t_komiya:20180909155336p:plain

一つのホスト上に物事が完結するのであれば特に何も気にすることはありませんが、例えば仮想マシンをvMotionで他のホストに移動させる場合、移動先のホストで仮想マシンが接続する仮想スイッチが同じような設定がされていない場合、vMotionは失敗します。ESXのホストが台数が少なければ、まだ設定の修正をするのに時間はかかりませんが、台数が多い場合には骨が折れるような作業になります。

f:id:t_komiya:20180909155719p:plain

これを回避するために、すべてのホストの仮想スイッチ統合する機能として、分散スイッチ(Distribution Switch)を利用することがあります。これを利用することにより、すべてのホストの仮想マシンにポートを割り与えられ、アップリンクポートからどの物理ホストに割り振るかを設定することで、ホストを跨いだスイッチの管理ができるようになります。

f:id:t_komiya:20180909160541p:plain

設定についてはvCenterで簡単にできるようになっていますが、どのように仮想マシンを管理するのかを図式化しておかないと、管理者が変わる際にすぐに理解できないと思いますので、そのあたりは注意が必要です。

今お話した分散スイッチですが、標準で利用できるものではありません。小規模のユーザではスイッチの管理も難しくはないので、VMwareのライセンス体系では上位エディションに食い込まれています。

f:id:t_komiya:20180909160747p:plain

大規模(データセンター系)のお客様に非常に効果的なソリューションであると思います。非常に便利なこちらの機能ですが、NutanixのハイパーバイザーであるAHVではどうなっているでしょうか。

f:id:t_komiya:20180909160945p:plain

AHVでは、vDS(分散スイッチ)と同様の機能が標準で利用できるようになっています。しかもそれが自動管理で利用できるようになっています。そもそもNutanixについては、VMwareのように歴史が古いわけではありません。1Gのネットワークできめ細かにネットワークのサイジングをやっているVMwareに比べて、Nutanixは10GのネットワークでそのネットワークでvLANなどを設定して細分化するような形になっていることから、逆にネットワークが簡素化された状態で設定できるようになっています。そのため、仮想マシンの作成時にvLANを設定するとそれをすべての仮想スイッチに分散して設定できることから、Lenovoもしくは各社のスイッチなどでvLAN設定の自動化追加のソリューションなどにも対応できるようになっています。

先ほどお話したvMotionなどが失敗するような設定漏れなどもなくなります。

f:id:t_komiya:20180909161604p:plain

f:id:t_komiya:20180909161645p:plain

また、AHVでの仮想ネットワークには可視化する機能もあります。仮想マシンからどのホストのインタフェースからどのネットワークスイッチに接続しているのがすぐにわかるようになっています。また、ホスト上のBond設定についてもGUIで確認できるようにもなっているため、非常に使いやすくなっています。

 

ひと昔前まではAHVは「タダだけど、機能は限定されているからあまり使い物にならない」という話でしたが、ようやく機能も出揃ってきており、ここまで使えるのか!というレベルにまで来ております。画面イメージでこだわりを持たれる方もおられると思いますが、機能面で簡素化を望まれる方は是非検討してみてはいかがでしょうか。

 

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

物理サーバも有効活用できるNutanixのブロックストレージサービス~ABSのご紹介~

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

本日はNutanixのブロックサービスの機能であるABS(Acropolis Block Service)についてご紹介します。ABSはNutanix上でブロックストレージを提供するサービスです。
過去のブログで何度か文言が出ているABSですが、一度もこちらのブログで紹介したことがありませんでしたので、今回はテクニカルな内容は少なめにしてご紹介したいと思います。
1.ABSはEnterprise Cloudの機能です!
f:id:t_komiya:20180902011128p:plain

そもそもHCI(ハイパーコンバージドインフラストラクチャ)で仮想基盤なのにブロックストレージという話もありますが、Nutanixはすべてハイパーコンバージドのベンダーとは自らは言っていません。現在はEnterprise Cloudのベンダーであるということで、仮想化だけではなく企業のインフラをすべて自分のソリューションに入れてしまいましょうというモットーを掲げております。そのため、以前ご紹介したファイルサービスと同様にブロックストレージも利用できるようになっています。

 

でも、昨今仮想化やクラウドが流行っているのに、なぜブロックストレージなどが必要なのでしょうか?それは以下の理由があるからです。

  • ライセンスの制約、レガシーアプリケーションの移植性、または既存のインフラへの投資のために、一部のワークロードはベアメタルサーバー上に残ります
  • ABSは、Nutanixが仮想化されたワークロードと物理的なワークロードのためのファイルストレージに提供するのと同じシンプルさを提供することで、ストレージサイロを排除します
  • 物理的な世界と仮想的な世界を橋渡しする

2.いまさらベアメタルなの?

f:id:t_komiya:20180902012140p:plain

Oracleのライセンスの課題

Oracleの仮想化は技術的には簡単ですが、ライセンス費用に関しては非常に頭を悩ませます。その理由については以前ブログに記載しているので、そちらをご参照ください。

HCIが向いている!向いていない!?ケースを考えてみよう [第二弾] - LTN Blog 〜 Lenovo Technology Network 〜

 

これらの問題を解決するためにも、物理環境は残るケースがいくつかあります。

それでは、ABSの説明をしたいと思います。

3.ABSは物理環境と仮想環境との架け橋

f:id:t_komiya:20180902012407p:plain

今回のABSはまさに物理環境と仮想環境の架け橋になります。上図のように仮想環境のところに、Nutanix環境を既存の物理サーバからiSCSIで利用させることで、既存の仮想環境も分けることなく利用することができます。また、ノードを追加することで、パフォーマンスも向上させることができるので、仮想化環境のときのメリットがブロックストレージでも享受できることになり、その結果すべてのアプリケーションを統合して、仮想化、ファイル、およびブロックサービスに同じインフラストラクチャを使用するようにします 効率を高め、リスクを軽減し、管理を容易にします。

4.ABSはどう動くの?

f:id:t_komiya:20180902012906p:plain

ABSがどのような動作をするのかをお話したいと思います。まずはiSCSIでよく必要となるMPIO(MultiPath IO)のソフトウェアをインストールすることを想像すると思いますが、今回それは不要でNutanix側で制御します。それ以外は以下の内容になります。

  • 対象となるお客様の現在のリストには、RHEL 6+、Oracle Linux 6+、およびWin 2012 R2 / 2008 R2が含まれます。さらにOracle RACとSQLが含まれるとします。
  • 概念的にわかるように、外部サーバーは、クラスター内のすべてのノード間で負荷分散を行います。
  • ノードに障害が発生すると、クライアントはクラスタ内の他のノードにトラフィックをリダイレクトするだけで、障害時のフェイルオーバーはシームレスに行われます
  • 最適なパス選択、負荷分散、クライアントの介入などを回避してIPを利用します。 すべてのNutanix機能セットを継承して動作します。

5.ABSはスケールアウトします!

f:id:t_komiya:20180902013551p:plain

iSCSIを利用するために、データサービスIPが必要となりますが、それを設定しまうと物理サーバからはノードが増えても全く意識しなくてもよくなります。また、増設するにあたってもシステム中断もないわけなので非常に便利になっています。

6.ABSは高信頼性・高可用性

f:id:t_komiya:20180902014133p:plain

Nutanixで構成するABSは可用性が高く、ファイブナイン(99.999%)の可用性を実現します。これはハイエンドレベルのストレージと同じ可用性です。また、フェールオーバーも自動で行われます。容量効率もよくすることができます。

7.ユースケース

f:id:t_komiya:20180902020456p:plain

f:id:t_komiya:20180902020600p:plain

f:id:t_komiya:20180902020721p:plain

 

ユースケースについては、ライセンスコストを落とすソリューションが一番よく見えてしまいますが、既存環境の有効活用と一番最後のユースケースのように開発環境でのアプリ開発と機能試験は仮想環境で実施して、本番環境でABSを利用した環境で有効的にインフラを生かすことが一番良いと利用方法だと考えます。

8.最後に・・・

f:id:t_komiya:20180902021157p:plain

最後にABSについて一つまとめてみました。

コスト削減・規模に合わせて構築可能でさらに信頼性があるというのがキーメッセージになります。

良いことばかり申し上げてきましたが、注意する点もあります。

アプリケーションによっては、構成に認定をとる必要があるものがあります。(OracleVMなどの構成は現状NXのABSしか認定されていません)

そのため、利用するアプリケーションによって、環境は確認するようにしてください。

 

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

 

vSANにもついに出た!パートナー主導型モデルThinkAgileVX認定ノード

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。
先週vSANの話をさせて頂きましたが、今週もそれに関連するお話をしたいと思います。今回レノボから新たなvSANのモデルがリリースされております。US時間で8月28日に発表されております。
こちらのモデルは先月ThinkAgile HX認定ノードに続いて、レノボのvSANアプライアンスで提供しているThinkAgileVXの認定ノードになっております。こちらもThinkAgileHXの認定ノードと同様パートナー様の主導モデルであり、ソフトウェア別調達でもレノボの保守を受けることが可能になっているモデルです。
vSANを検討されている皆様、ビジネスパートナー様皆様には日本市場にぴったりなモデルとなっておりますので、是非今後の導入検討にいかがでしょうか。
 
1.ThinkAgileVX認定ノードについて 

f:id:t_komiya:20180829114520p:plain

ThinkAgileVXに認定ノードについてですが、先ほどソフトウェアを別調達と記載しましたが、ESXiそのものはプリロードされております。そのため、ライセンスキーをあればアクティベーションできるようになりますので、そのライセンスキーをディストリビュータ様から調達する必要があります。
本来このようなことをせずにレノボのOEMのESXiのライセンス提供することが一番提供方法として楽だと思える方もいらっしゃるかと思いますが、日本でのVMwareのビジネスの大半はディストリビューター様からのライセンス調達で成り立っています。そのため、今回のようなモデルでなく、ハードウェア各社がリリースしているvSAN Ready NodesなどのVMware社の認定モデルで十分のはずです。ただし、VMware社の認定構成はあくまで固定の構成であり、ほとんどがカスタマイズして提案することがほとんどです。今回のThinkAgileVX認定ノードはライセンス調達および、(レノボの)認定構成で数多くの構成がレノボの一元サポートでご提案できるというのが大きな特徴です。
また、VXインストーラという専用のインストールツールが用意されて認定されたファームウェアでのインストールがサポートされてライフサイクルの管理もできるようになって、一段と信頼性を増したvSAN環境が提供できるようになっています。
2.どんなことでメリットになるのか?

f:id:t_komiya:20180829114632p:plain

認定ノードのメリット、それはLenovoがvSAN環境で問題なく動作するハードウェア(ファームウェア含む)を数多く認定していることです。実際の認定している構成を数えると、CPU・メモリ・SSD・HDD・その他のパーツの組み合わせになるため、数万通りの構成になります。もちろん、同一のマザーボードで動作することから、それらは問題なく動作することになります。(パフォーマンスの規定はなし)そのため、vSAN Ready Nodesのカスタマイズバージョンとほぼ同じ構成が作れるだけでなく、例えばHDDの容量が多いモデルなどvSAN Ready Nodesにはない構成もThinkAgileVX(認定ノード含む)で構成可能なことからHCLなどのチェックも必要ありません。インストールもプリロードされていることはもちろんのこと、VXインストーラによる簡素化、検証されたファームウェアでの互換性の取れているハードウェアでの納品であることから、安心してご利用できます。ツール類についてもLenovoが提供しているXClarityを利用してハードウェアの一括管理するツールを導入して運用簡素化するお客様もいらっしゃると思います。そのツールについても導入するかはお客様側で選択が可能となります。またHCIで当たり前のようになっているファームウェアローリングアップグレードもサポートしております。

3.レノボvSANのソリューションのラインナップ 

f:id:t_komiya:20180829115615p:plain

 今回紹介するThinkAgileVX認定ノードはもちろんのこと、もう一度レノボの提供できるvSANソリューションのラインナップを整理してみました。

ThinkAgileVXVMwareのOEMライセンスでレノボが認定するハードウェア(ファームウェアを含む)で構成されている。(構成は数万通り)導入作業はレノボ側で実施し、サポートはレノボ側でハードウェア・ソフトウェア関係なく一元窓口を実現

ThinkAgileVX認定ノード:VMwareライセンスをOEMもしくはパートナー様にて調達するライセンス(リテール版)を利用することが可能。(ハードウェア構成は数万通り)導入作業についてパートナー様で導入することも可能であるが、オプションでレノボの導入を利用することも可能。また、サポートについてはお客様にてVMware(ESXi)とレノボ(ハードウェア)を切り分けて対応することも可能であるが、レノボがソフトウェア・ハードウェアの一元窓口として対応することも可能

vSAN Ready Nodes:VMware社が検証した構成がベースになっている。(レノボだと現状約100数通り)構成については、カスタマイズ可能であるが、検証している構成ではない。ライセンスについてもOEM版とリテール版の両方を利用可能。導入についてはパートナー様で導入し、サポートもお客様・パートナー様にてハードウェア・ソフトウェアを切り分けて対応して頂くことになります。 

4.それぞれのソリューションの違いについて 

f:id:t_komiya:20180829125058p:plain

前述でコメントしておりますが、比較表としてわかるものをこちらに掲載いたします。

それぞれは競合製品ではなく、あくまでそれぞれで足りない部分を補っている製品になります。 

5.ThinkAgileVX認定ノードのラインナップ

f:id:t_komiya:20180829132538p:plainf:id:t_komiya:20180829135838p:plain

ThinkAgileVX認定ノードのラインナップをご紹介します。昨年末に発表されたThinkAgileVXシリーズのラインナップと合わせて掲載します。今回のノードについては、型番があるわけではなく、フォームファクターを選択して、認定ノードを構成します。実際にvSAN Ready Nodesに相当するのが、VX3320とVX7520に2機種になります。それ以外の機種については、vSAN Ready Nodesにも存在していないので、お客様の要望の応じてサイジングし、そのスペックを選びやすくなっております。認定ノードについては、フォームファクターを選択した、CPU・メモリ・SSD・HDDなどの構成のほかにNICやGPU(VX3520-Gと同じフォームファクターのみ)なども選択できるようになっています。これでvSAN Ready Nodesのカスタマイズすることもありませんし、LenovoのWebサイトからも認定構成を選ぶことができます。

6.パートナ主導で認定ノードがなぜ得するのか?

f:id:t_komiya:20180829134141p:plain

こちらの図を見て頂ければわかるかと思いますが、パートナー主導ということはすべての工程はパートナーで進めることが可能です。例えばアプライアンスの場合、レノボの作業が必須であることから、レノボ・パートナーの作業が重なったりして混乱する場合があります。責任分界点も考慮する必要もあります。ただし、それが認定ノードの場合、レノボの工場で生産されたハードウェアが出荷されて以降、パートナー様で作業を行うことができます。そのため、WBSなどを作成するにあたるスケジュールが組みやすいなどのメリットがあります。パートナー様で案件を進めるにはこちらのモデルは非常に有効です。

7.サポートフローについて

f:id:t_komiya:20180829135945p:plain

サポートフローについて説明します。こちらについては7月にご説明したThinkAgileHX認定ノードとフローは同じです。(上図参照)Nutanixの部分がVMwareに変わっただけのお話です。認定ノードそのものがサポート重視の製品であることから、今後もこのような製品がリリースされることが期待したいと思います。

8.m.2のミラー化でESXiの冗長化

f:id:t_komiya:20180829140550p:plain

ThinkAgileVXリリース時から内容になりますが、起動デバイスが冗長化対応します。これにより、SSDやHDDを利用することなく起動デバイスの冗長化の専用デバイスの対応ができます。今回は480GBのm.2もリリースされてさらにログの領域としても利用可能になります。

9.vCenter + XClarityにより仮想・物理の一括管理

f:id:t_komiya:20180829140939p:plain

ハードウェアメーカー各社がvCenterと連携可能なハードウェアの管理ツールをリリースされています。レノボもXClarityを利用して、vCenterのプラグインとして導入することで、vCenterからハードウェアの管理が可能です。今回はこれに加えてVX インストーラのローリングアップグレード対応もありますので、さらに使いやすくなっています。

10.ThinkAgileVXシリーズ(認定ノードも含む)の構成について

f:id:t_komiya:20180829141347p:plain

ThinkAgileVXの構成についてご説明しますが、その前にvSAN Ready Nodesでの構成についてお話します。

vSAN Ready Nodesについては、VMware社の検証した固定の構成のため、その構成がVMware社のページに掲載されています。認定構成でサイジングすると、コンピュートノードとしてスペックが小さいものがほとんどで非常に提案もしづらいものになっています。各社のハードウェアが固定の構成しか選択できないはずはなく、もちろんCPU・メモリ・SSD・HDDを柔軟に変更することができます。レノボのThinkAgileVXはその点を考慮してレノボが認定する構成でサポートをしますという前提で、お墨付き構成を増やしています。

f:id:t_komiya:20180829141912p:plain

f:id:t_komiya:20180829141956p:plain

ここでThinkAgileVXシリーズ(VX3320とVX7520)を確認してみましょう。

ThinkAgileVXを構成するにあたり必要となる概念がグループです。このグループ(キャッシュ領域とキャパシティ領域)を必ず1つ以上が必要になりますが、この構成に柔軟性があります。ThinkAgileVX3320であれば、最大スペックはSSDが2本、HDDが8本になるわけですが、この構成は本数も可変で容量も可変です。もちろんCPUもメモリ容量も数十種類から選択可能です。このような柔軟さが認定ハードウェアの数を増やす結果となっています。

f:id:t_komiya:20180829142436p:plain

f:id:t_komiya:20180829142515p:plain

ThinkAgile VX2000/5000シリーズはvSAN Ready Nodesには存在しない構成になります。主な用途はCPU、メモリよりもHDDをの容量を要求されるようなケースです。このケースの場合は3.5インチのDiskを利用して大容量を確保します。SSDで15.36TBなどの容量もありますが、こちらは非常に高くなるので、安価で容量を必要とされる場合は選択するノードとしては一番良いと思います。

それ以外にもGPUモデルと2U4Nの高密度モデルがあります。考え方は同じですが、2CPUが必須だったりするため、メモリ容量の選択は要注意です。

 

vSANソリューションを検討の際にはこちらのモデルも是非ご検討ください。

 

よろしくお願いします。