Nutanix Calm について【続編】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanix Calmの記事について投稿したいと思います。

以前にもCalmの内容は投稿しておりますが、説明だけが多くどのような画面なのかがわからない方もいらっしゃいますので、一年ぶりに画面イメージも含めてもう少しわかりやすい内容でお伝えしたいと思います。

以前投稿した記事についてはこちらになります。参考程度に見て頂ければと思います。

ハイブリッドクラウド環境で必要になるアプリケーションのライフサイクル管理[第二弾]～Nutanix Calmの紹介～ - LTN Blog 〜 Lenovo Technology Network 〜

１．Calmを利用する目的

Calm（Cloud Application Lifecycle Management）はアプリケーションに特化した自動化ソリューションです。アプリケーションのデプロイを自動化したり、Self Service Portalでユーザ管理を行うことで、ユーザ専用のダッシュボードを用意して、インフラ管理者・アプリケーションの管理者向けの利用しやすいインタフェースを提供します。

また、ハイブリッドクラウド環境などでアプリケーションを利用する場合も、それぞれのクラウドインフラを意識することがなく導入、管理ができます。

また、最近は利用状況やコストなども把握（Xi Beamとの連携）も行いながら、最適なクラウド環境にアプリケーションを移行することも可能になっています。

２．Calmの機能的な要素について

Calmを利用する際に覚えておく単語があります。

Blueprints：アプリケーションのテンプレートです。こちらの中にアプリケーションの構成します。例えばある業務アプリケーションがあれば、Webサーバー・DBサーバー・Proxyサーバーを構成をしますが、この際Webサーバーと記載する前にDBサーバーが起動していないとアプリケーションがデータを検索できない状況になったりします。そのような状況を防ぐために、アプリケーションの起動順序や依存関係を定義するために必要になります。 

セルフサービス：Calmでアプリケーションを定義する際に、どのユーザーでどのような権限で利用するのかも定義する必要があります。その際にPrism Centralでサポートされているセルフサービスの機能を利用します。こちらを利用することで、アプリケーションにおける権限付けができて、必要なユーザーには参照させないことができます。

Marketplace：Calmを利用する際に、アプリケーションをお客様側ですべて用意しなければならないわけではありません。クラウドネイティブなアプリケーションやハードウェアメーカーのリリースしているアプリケーションはMarketplaceと呼ばれるアプリケーションがアップロードされているサイトからダウンロードが可能です。

また、他の人が作成したBlueprintsも共有（Githubなどにもあります）されておりますので、もしBlueprintsの作成方法がわからない場合は、参考にするのも良いかと思います。

３．Blueprintsについて

Blueprintsの中でアプリケーションに関する要素を定義していく訳ですが、アプリケーションは主に仮想マシンやその仮想マシンの構成やネットワークのベースとなる要素とそのインフラに必要な要件のセキュリティ、接続性、依存関係、オペレーションなどが含まれます。

それぞれが設定ファイルなどではなく、GUIなどで視覚された上で管理できるため、作成した管理者のみで俗人化された管理にはならないようにすることも目的になります。

アプリケーションを定義する際に、アプリケーションに必要な要件があります。例えば、ロードバランサ（NGINX）などのインフラに関する部分に定義も簡単に行うことができます。 Blueprints上に定義して、パラメータを入れる画面が右側に表示されます。

４．Calmのサービス

Calmのblueprintsの中でアプリケーションを定義する際に、どのようなパラメータで定義するのか行う必要があります。

Calmにおいては仮想マシン・パッケージ・サービスを定義できます。

仮想マシンについては、仮想マシンの名称、OSイメージ、リソース（CPU, コア, メモリ, ディスク容量）,ネットワークなどの情報を定義します。

パッケージ、サービスでは、インストールスクリプトや各種カスタマイズの設定情報も定義できます。

インフラの定義できる画面がこちらになります。各種変数を定義できる項目が右側に表示されます。

パッケージに関する説明ですが、インストール用にスクリプトを埋め込むことができます。ここでサポートされているのは、BashやPowershellになります。

パッケージを定義する際に、パラメータ・マクロ・依存関係の話をしたいと思います。

アプリケーションを定義する際に、VMなどの名称を定義しますが、名称には一意性を持たせる必要があります。

マクロ定義するときには、Bashなどを利用することができるお話をしましたが、パッケージのバージョンによって動作を判定させたい場合などはイメージのような条件を定義します。

またパスワードなどを要求されるものについても、RUN TIME で変数を定義できます。

依存関係のパートになります。こちらでは、DBのインスタンスが立ち上げあってからアプリケーションを立ち上げるように条件文がつけられますが、矢印などの視覚化わかるような表示がされていることがわかります。これらはスクリプト内で定義することも可能です。

最終的にアプリケーションをBlueprints内で定義し終えたら、ローンチ（起動）をするとアプリケーションが作成できます。これを利用して、複数のコンポーネントで構成されているアプリケーションを管理を行うことができるようになります。

また、Calmについてはクラウドにも対応しております。

例えば、WebサーバーがAWSに配置されており、DBがオンプレミスに配置されているシステムについては、各種仮想マシンのアイコンなどが、クラウド・オンプレミスであることがわかるようにすることができます。

是非Calmを利用してハイブリッド環境におけるアプリケーションの管理を行うことで、運用を簡素化できるようにしましょう。

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

SAP HANA on Nutanixのベストプラクティスについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は以前にもお話したSAP HANA on Nutanixに関するベストプラクティスについてお話したいと思います。

こちらの内容についてですが、ちょうど一年前にNutanixのAHVにおいて、SAP HANAでのAHV認定がちょうど発表された時期だったと思います。

Nutanix Enterprise Cloud OSのハイパーコンバージェンスベース・ソリューション、SAP HANA®認証を取得 | Nutanix

昨年のNutanix .NEXT TokyoでのセッションにてSAP HANA on Nutanixの話をさせて頂きましたが、当時はまだ製品リリース間もない頃で、必要なテクノロジーの話をさせて頂きました。

ついに出たミッションクリティカル向けのNutanixモデル(ThinkAgile HX for SAP HANA)～ThinkAgile HX7820/HX7821のご紹介～ - LTN Blog 〜 Lenovo Technology Network 〜

一年ほど経過現在では、HX7820の導入事例もいくつで出てきており、また一部のお客様ではSAP HANA on Nutanixの案件も出てきております。

そこで今回は、SAP HANA on Nutanix に関するポイントとなる点をお話したいと思います。

１．CPUに関するベストプラクティス

SAP HANA で認定を取るためにはパフォーマンス（SAP値）が出せるようなスペックでなければいけません。

そのため、選択CPUについても現状はSkylake世代（Cascade Lake世代の認定はまだとられておりません）のCPUになっておりますが、SkyLake世代においても、PlatinumのCPUもしくはGoldシリーズ以上が必要になります。加えて最低要件として8コア以上のCPUが必須になります。

NutanixのおいてはCVMがCPUのオーバーヘッドになることから、SAP HANAを動作させるノードにおいては、必ず1CPUはCVM用にリソースを取られることになります。（HANA以外のアプリケーションはCVMと同一CPUで動作させても問題ありません）

SAP HANAはインメモリデータベースということもあり、仮想マシン起動時に仮想マシンのメモリ上にデータベースのデータをロードを行います。数百GBもしくは1TBレベルのメモリを必要としますので、1CPUのメモリ領域では収まらないこともありますので、CPU間でメモリ利用できるように共有できるようなアーキテクチャ（NUMA）を利用して、大容量のインメモリデータベースを形成します。

例えば、小さなSAP HANAのデータベースがホスト内の3台存在する場合について、このようになります。

768GB以下の容量で起動可能なレベルであれば、1CPUのメモリ空間をそのまま利用できますので、各SAP HANA VMがそのまま固定して動作します。NUMAノードのすべてのCPUのリソースを効率良く活用できるようになります。

今度は２つのSAP HANA VMが存在するケースで１つのSAP HANA VMが大きくメモリ領域を確保してしまうケースはこのように最大1.5TBまで確保するVMと768GBまでしか確保できないSAP HANA VMが存在するような形になります。

次に１つの巨大VMが３つのCPU分のメモリ領域を利用した場合に関してのイメージです。この場合は３つのCPU（NUMAノード）が固定で利用されます。

このように、CPUとメモリ領域を把握した上での運用がSAP HANAに関しては必要になってきます。

２．メモリに関するベストプラクティス

メモリに関する注意事項についてですが、インメモリデータベースということもあり、メモリのパフォーマンスは同一である必要があります。選択するCPUにより、メモリのスピード（周波数）が異なります。必ずメモリのスピードは合わせるようにして下さい。また、メモリオーバーコミットは許可されておりません。

Cascade LakeシリーズのCPUについては、CPUの種類によってメモリ容量が異なります。CPUの型番の末尾に「M」もしくは「L」のタイプのものを選択するようにして下さい。

３．ディスクに関するベストプラクティス

ディスク（ストレージ）部分については、トランザクションを即座に処理できるようなデバイスが求められております。

通常はオールフラッシュは必須ですが、インメモリデータベースのトランザクションのため、早いことに越したことはありません。ThinkAgile HX for SAP HANAのアプライアンスに関しては、デフォルトでNVMeの利用を推奨されております。

ディスクに関する細かな仕様をこちらに記載します。

SSD部分に関してはは8本以上が必須になります。また、SAP HANA DBのメモリサイズの2.5倍の容量が最小ディスクサイズになります。

サイジングする際はReplication Factorのオーバーヘッドも考慮したサイジングが必要になります。

４．ネットワークに関するベストプラクティス

ネットワークについてですが、SAP HANA環境では10GbE以上が推奨となっております。10GbE以上のスループットがあれば、速い分にはいくらでも構いませんが、SAP HANA on Nutanixにおいては、データをネットワーク経由でアクセスする際に、CPUにおけるオーバーヘッドを少なくするために、RDMAの技術を利用することが推奨とされております。この場合、SAP HANAを構成するノードはすべてRDMA対応のNICで構成されていることが前提であり、非RDMAノードとの混在は許可されておりません。

RDMAはデフォルトでCVMのeth3のインタフェースにデプロイされます。

５．仮想マシンのデザインに関するベストプラクティス

仮想マシンのデザインについては、先ほどお話したNUMAの領域に準拠する必要があります。それ以外の内容についてはイメージに記載してあり通りになります。
落とし穴として考慮しなければいけないところは省電力状態の内容になります。
６．運用に関するベストプラクティス

運用に関しては、注意すべき点はやはりAOSのバージョンです。本番環境にSTSのバージョンを利用することは基本的に推奨されておりません。LTSのバージョンで運用するようにして下さい。

詳細はCertified and Supported SAP HANA Hardware Directoryをご参照ください。

７．可用性・バックアップに関するベストプラクティス

可用性およびバックアップに関する内容ですが、N+1の考慮は当然のお話として対応しなければいけませんが、4ノードスタートで十分なリソースで運用することをお薦めします。

また、データベースのレプリケーション機能は利用するようにして下さい。NutanixのDRソリューションは現状未サポートになっております。
バックアップについては現状3rdパーティのバックアップソフトウェアを推奨しております。対応しているソフトウェアとしては、Veeam,HYCUなどがあります。

また、バックアップしたデータについては、必ずリストアのテストを行うようにして下さい。バックアップしたデータがリストアできないケースもありますので、非常事態に備えることも必要です。

以上、SAP HANA on Nutanixするときには一度参考にして頂ければと思います。

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

 

Nutanix Flowのユースケースに関して

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのFlowに関しての内容をお話したいと思います。Nutanix Flowについては約1年前にもブログで内容を記載しておりますが、少し内容が古いため新しい内容でお伝えしたいと思います。

過去に掲載したブログは以下のURLになります。

Nutanix FLOWについて【第二弾】 - LTN Blog 〜 Lenovo Technology Network 〜

イメージについては、Nutanix社の資料を利用させて頂いております。

一般的なFlowのユースではどのようなパターンで利用されるのかを以下のイメージに示しております。それぞれのケースで簡単にお話したいと思います。

１．インフラ環境を隔離

Nutanix Flowは、高度なネットワークおよびセキュリティサービスを提供し、仮想ネットワークの可視性、ネットワーク脅威からのアプリケーション中心の保護、および一般的なネットワーク操作の自動化を提供します。

従来のインフラ環境においては、VLANベースの隔離やファイアウォールでのゾーン化を主なアプローチとして対応してきておりましたが、VLANの隔離はそもそもセキュリティの観点で隔離するのではありません。また、マニュアル作業のため安全とは言い切れません。また、横方向のネットワークには対応できないというデメリットがあります。

ファイアウォールのゾーン化については、VLANベースの隔離に比べればセキュリティという観点では優れておりますが、機器の値段はそれほど安いものではありません。

Flowは、完全な可視性とトラフィック制御を可能にするアプリケーション中心のポリシーを提供します。このポリシーモデルにより、管理者はトラフィックの送信元と宛先、またはマイクロセグメンテーションに関するきめ細かいルールを実装できます。これらの同じポリシーにより、アプリケーションVM内およびアプリケーションVM間を流れるトラフィックを視覚化できます。

Flowによるインフラの隔離であれば、部署ごとによりポリシーを容易に決めることができて、それがPrism Central上から操作が簡単にできるというところが特徴です。 

２．アプリケーションの隔離

アプリケーションのセグメンテーションについては、従来のものに関しては、各アプリケーションレイヤでVLANを割り当ててから、各アプリケーション/アプリケーションレイヤのFWポリシーを作成します。

この方法の場合、トラフィックはすべてFWに固定されてしまいますし、複雑化してコストもかかってしまいます。また、スケーラブルではないので、せっかくのハイパーコンバージド環境での利用も台無しになります。

FlowによるアプリケーションのセグメンテーションはVM単位にカテゴリ化します。（VLAN/クラスタ/ホストは任意）また、インバウンド／アウトバウンドのポリシー定義やティア内のポリシー定義を行います。
FWを利用した時に比べて非常にシンプルに設定が可能です。

３．セキュアなVDI環境の実現

こちらは従来のVDI環境におけるセキュアな環境ですが、こちらもFW内にアプリケーションに関するポリシーを設定するなどしなければならないため、複雑であり、VDI環境が拡張するにあたり、ポリシールールも手作業で大変になります。

逆にFlowで管理する場合はどうでしょうか。デスクトップユーザーの識別ができていることから、実際に人事異動でしたユーザーのポリシーについて、カテゴリごとにアプリケーション単位で適応できていれば、わざわざファイアウォール側での設定を行う必要はありません。またポリシー設定されていればマルウェアの拡散の防止にもなります。NutanixのAHV環境でVDIを構成する場合は、Flow導入するとセキュリティ対策も含めて便利になります。

４．コンプライアンスについて

カード決済などでよく利用されるPCIアプリケーションについては、かなり厳しいコンプライアンスが要求されると思います。各PCIアプリケーションについてファイアウォールのルールの適応を行うとともに、これを自動化していかないと毎回ユーザー登録するたびにマニュアルのオペレーションが発生します。これにより作業コストも上がりますし、横移動する際のセキュリティについても慎重に考えなければなりません。

Flowであれば、カテゴリ別設定することからマニュアル作業は極力削減することができます。また、ポリシーなどの監査についてもリモートホストのSyslogに転送することもできます。セキュリティオペレーターはそれらをモニタリングして、ポリシー違反なども発見することができます。

モニタリングとロギングに関する点については、実は先週のブログで紹介したAOS5.11に関するPrism Centralに関する記述の中で一部触れております。

Syslogに送信する機能およびセキュリティポリシーのインポート・エクスポート機能もサポートしておりますので、コンプライアンスを意識お客様は是非検証してみてはいかがでしょうか。

https://blog.lenovojp.com/entry/2019/08/19/000942

以上、よろしくお願い致します。

AOS 5.11に関して～Prism / AHV機能編～

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は前回に引き続いてNutanix AOS 5.11についてお話したいと思います。 今回はPrism Cental およびAHVに関する機能についてお話したいと思います。

Nutanix社提供の資料を利用させて頂いております。

１．Prism Central 5.11の新機能およびアップデート機能

Prism Centralのアップデート内容としては以下の点になります。

• Nutanix オブジェクトストレージのサポート
• コードレスタスクオートメーション（X-Play)
• Syslogモニタリング
• セキュリティポリシーのエクスポートおよびインポート

• イメージ配置ポリシー
• Flowのログでポリシーヒットをサポート
• Nutanix Networking Service (Xi Cloud Services)
• Xi Cloud ServicesでNutanix Guest Tools(NGT)のサポート
• カテゴリでESXiをサポート

• エンティティメトリックの強化されたモニタリング
• VM管理用のカテゴリベースのRBAC
• カテゴリのマルチカーディナリティのサポート

全部を説明するとかなりの長文になってしまいますので、いくつかをピックアップしてお話します。

Nutanix オブジェクトストレージは前回にもご紹介させて頂きましたが、今回Prism CentralのUIから簡単にアクセスが可能になっております。

コードレスタスクオートメーションに関しては、次章にお話したいと思います。

それ以外にSyslogのモニタリング機能やセキュリティポリシーのエクスポート・インポート機能のサポート、Xi Cloud Serviceへのオンプレミス環境からの接続時におけるVPN機能のサポートやNutanix Guest Toolsのサポートがあります。

２．コードレスタスクオートメーション（X-Play)

イメージの中にも記載がありますが、こちらはIFTTT（イフト）の機能がサポートされおります。

IFTTTとは、一言でいうと連携機能のことです。「IF This Then That」の頭文字をとって、「もし、これをしたら、あれをする」という意味です。

例えば、特定の仮想マシンのメモリが足りなくなった場合に、リソースが余っているなら特定の仮想マシンに対してメモリ容量を増やしてあげるなどの対策を自動的に行うものです。

IFTTTを起動させる条件を「トリガー」、それによって自動的に行われる動作を「アクション」と呼びます。

自動化を試してみたい方には是非お奨めの機能だと思います。

なお、X-Playを利用するためにはPrism Proライセンスが必要です。また、X-Playでは、Prism Centralのみが5.11である必要があり、Prism Elementを5.11にアップグレードする必要はありません。

３．AHV 5.11の新機能およびアップデート機能

AHVに関するアップデート内容としては以下の点になります。

• br0アップリンク構成のアップデートをサポート
• AHVクラスターでのコンピュート専用ノードのサポート（AHVのみ）
• AHVおよびHyper-VクラスターのVMにおけるUEFIサポート

br0アップリンクに関する内容については、イメージ内に詳細内容を記載しております。

コンピュート専用ノードに関する内容は次章にご紹介いたします。

UEFIサポートについては、AHVおよびHyper-Vの２つのプラットフォームでUEFIファームウェアを使用したVMの起動をサポートするようになりました。

４．AHV 5.11の新機能およびアップデート機能

コンピュート専用ノードはCPUおよびメモリのリソースのみをNutanixクラスタに追加するノードになります。そのため、CVMは内部に存在しません。AHVでサポートしているHAやADSなどの機能もそのまま利用できます。

ファームウェアのアップデートはLCMで行います。

現状こちらの機能はNXシリーズおよびXCシリーズ、Ciscoのプラットフォームがサポートとのことで、今後他社のプラットフォームにもサポートして頂きたいですね。

また、コンピュート専用ノード構成するにあたり、最低要件もありますので合わせて記載致します。

コンピュート専用ノードを利用する際の最低要件

• コンピュート専用ノードを追加する前に、Nutanixクラスターは少なくとも4ノードのクラスター構成が必要
• クラスター内のコンピュートノードとHCノードの比率は 1CO:2HCを超えてはいけない
• クラスター内のHCノードはオールフラッシュで構成する必要がある
• HCノード上のCVMに割り当てられるvCPUの数は、クラスター内のすべてのコンピュート専用ノードで利用可能な コアの総数以上である必要があります
• すべてのHCノードに割り当てられたNICの帯域幅の合計は、クラスター内のすべてのコンピュート専用ノードに 割り当てられた合計NIC帯域幅の2倍である必要がある
• コンピュート専用ノードのAHVバージョンは、クラスター内の他のノードと同じにする必要がある

コンピュートノードを構成する場合はFoundationからコンピュート専用ノードを構成してから、既存のPrismからノード追加でコンピュート専用ノードを選択する形になります。

是非構成する際はご注意下さい。

最後に、5.11になってソフトウェアのライフサイクルについてもお話しておきたいと思います。

５．LTSとSTSについて（アップデート）

今回リリースしたAOS 5.11については、STS（Short Term Support）になります。そのため、サポート期間は6か月になります。

前回ご紹介した時から内容が若干修正されているようですので、赤字でわかるようにしておきました。（イメージ参照）

６．AOSのライフサイクル

こちらが最新のAOSのライフサイクルになります。

前回内容と比べると、AOS5.5に関するサポートが長くなっております。

AOS5.11を利用される方は、サポート期間中に注意しながらご利用下さい。

７．AOSのアップグレードパスについて

アップグレードパスについては、Nutanixのポータルサイトからも確認できます。

今回は一例として、AOS5.5.9からのアップグレードパスを記載してみました。

実際にアップグレード作業する前に、ご確認下さい。

また、作業前に注意事項もポータルサイトに記載がありますので、是非ご覧ください。

https://portal.nutanix.com/#/page/docs/details?targetId=Web-Console-Guide-Prism-v510:upg-upgrade-checklist-r.html

以上、よろしくお願い致します。

AOS 5.11に関して～AOS機能編～

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は8月6日にリリースされたNutanix AOS 5.11についてお話したいと思います。

機能がかなり追加されておりますので、今回はAOSの機能をメインで紹介いたします。

Nutanix社提供の資料を利用させて頂いております。

１．AOS 5.11のメジャーアップデート

今回のアップデート内容としては以下の点になります。

• ストレージのサービス品質 (QoS) 【パフォーマンスと復元力】 
• Volumesのネットワークセグメンテーション(iSCSI)トラフィック【セキュリティ】
• ストレージ容量 【スケール】
• DR 【データ保護】
• Nutanix Guest ToolsにおけるESXiのサポート

QoSに関しては、VMwareでいうところのStorage I/O Controlになります。
Volumesに関してもネットワークセグメントを分けられるようになっています。

ストレージ容量については、大容量ディスクに対応しておりますが、こちらは制限事項もありますので、合わせてご紹介したいと思います。

また、オブジェクトストレージもリリースされておりますが、名称が変更（Nutanix Objects）されておりますので合わせてお話します。

DRについては、ESXi関連の対応がメインになりますが、今回SRM(Site Recovery Manager)において、NearSyncが対応しております。

２．ストレージQoS

ストレージQoSは、管理者が仮想マシンのパフォーマンスを管理するためのきめ細かな制御を提供し、システムがすべてのワークロードに対して一貫したパフォーマンスを提供するようにします。制御可能なノブを使用して、ストレージレイヤーが個々の仮想マシンに提供するIOPSを制限できます。

ライセンスはProエディション以降で利用可能になります。ハイパーバイザーはESXiとAHVで対応しています。

QoSライクの機能はすでにNutanixには実装済みで、例えば容量とパフォーマンスに基づいたデータのコピー機能ががあります。（説明は省略させて頂きます）

さらに機能追加という形でADS（Acropolis Distributed Scheduler）などもNutanix全体のリソースを見ながら、単一ホスト内でリソースが不足した場合の仮想マシンの移行先を決定します。（説明は省略させて頂きます）

IOPSはストレージレイヤーが1秒間に処理できるリクエストの数になります。ノイジーネイバーの多いVMがシステムリソースを過度に使用しないように、VMにスロットル制限を設定できます。

ノイジーネイバー（うるさい隣人）に関する記事はインターネット上でも数多く紹介されているので、是非ご覧ください。

https://www.itmedia.co.jp/enterprise/articles/1611/10/news010.html

３．ネットワークセグメンテーション 

サービスのネットワークセグメンテーション

トラフィックをコントローラーVM上の別のvNICに制限し、独自の物理NICを持つ専用仮想ネットワークを使用して、サービスに関連付けられたトラフィックを保護できるようになりました。このタイプのセグメンテーションは、サービス固有のトラフィックの真の物理的分離を提供します。このリリースは、Nutanix Volumesのネットワークセグメンテーションをサポートしています。

ライセンスはStarterエディション以降で利用可能になります。ハイパーバイザーはESXiとAHVで対応しています。

この機能を利用することにより、基本的にサービス (この場合はVolumes)を新しいBridge （またはESXiの場合は仮想スイッチ）に接続し、 クラスター内部の各ノードの特定の物理ポートのみに 接続可能。 そのサービスからのすべてのトラフィックは、 そのBridge/物理ポートの組み合わせのみを通過させます。

３．高密度ストレージノード

１ノードあたり最大120 TiBのサポート

・Foundation 4.4以降のAOS 5.11は、ノードあたり最大120テビバイト（TiB）のストレージをサポートするようになりました。（正確には容量表記はこちらになります）

・Foundationソフトウェアは、プラットフォームモデルまたはストレージ容量に応じて、各コントローラーVMに割り当てられたデフォルトのメモリとvCPUの数をプロビジョニングします。

また、今回のストレージノードを利用するにあたり、必要な要件がありますので、以下に記載致します。

必要な要件：

1.最大ノード容量あたり120TB （12TB x 10）

2.ノードごとに少なくとも2つのSSDが必要

3.HDDとSSDの比率は少なくとも2：1

4.ノードごとに合計7.68TB以上のSSD容量が必要 (3.84TB x 2)

5.CPUごとに最低12の物理コアが必要。ノード自体はデュアルソケットが必須

6.各CVMには12個のvCPUと36GBのサイズが必要

こちらのストレージノードについては、現状は以下の機種で対応しています。

NX-8155-G6

NX-5155-G6

ThinkAgile HX5520 (Lenovo)

上記の以外の他社製品は各社にご確認下さい。

4．オブジェクトストレージ（Nutanix Objects）

オブジェクトストレージについては、先にもお話しましたが、今回からNutanix BucketsからNutanix Objectsに変更に名称が変更になっております。

S3互換のAPIがサポートされ、導入も簡素化されています。

データの保管についてもWORM対応やセキュリティもSEC 17a-4準拠になっております。

バックアップとしても利用可能で、10ノードで1PB程度の容量にもスケールアウトします。

こちらのNutanix Objectですが、2TBの容量があればお試しでご利用可能だそうです。

バックアップソフトウェアなどで利用する場合にも、REST APIでオブジェクトストレージバックアップ可能なソフトウェア（Veeam , Commvault）などが必要になりますので、対応プラットフォームなどを確認してご利用下さい。
 

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

Blockchainに関して（その２）～Hyperledger Fabricおよびアーキテクチャについて～

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はBlockchainのその２と題して、オープンソースのブロックチェーン技術のHyperledgerについての簡単なご紹介と、ソリューションにおけるアーキテクチャをご紹介したいと思います。

１．Hyperledger Fabricについて

Hyperledger Fabricはブロックチェーンフレームワークの実装であり、The Linux FoundationがホストするHyperledgerプロジェクトの1つです。モジュラーアーキテクチャを備えたアプリケーションまたはソリューションを開発するための基盤として、Hyperledger Fabricを使用すると、コンセンサスサービスやメンバーシップサービスなどのコンポーネントをプラグアンドプレイできます。Hyperledger Fabricはコンテナ技術を活用して、システムのアプリケーションロジックを構成する「チェーンコード」と呼ばれるスマートコントラクトをホストします。Hyperledger Fabricは、最初のハッカソンの結果として、当初はDigital AssetとIBMから提供されました。

オープンソース、エンタープライズグレード、許可された分散型台帳テクノロジープラットフォーム であり、高度なモジュール化および構成可能なアーキテクチャにより、幅広いユースケースに対応した革新性、汎用性、 最適化を実現します。

各メンバーが見ることができる台帳のトランザクションを制限するために、チャネルを持つ許可されたネットワークを作成する機能を有し、Goで記述され、Dockerコンテナで実行されるチェーン コード（スマートコントラクト） で構成されます。

２．Hyperledger Fabricのコンポーネント

Hyperledger Fabricのコンポーネントは以下の３つから構成されます。

CA（Certificate Authority：認証機関）

• IDの登録、証明書の発行、証明書の更新と取り消し

オーダーサービス

• 承認されたトランザクションを受け入れ、ブロックに順序付けし、ブロックをコミットしているピア（対等者）に配信します

ピア（対等者）：

• 台帳のインスタンスとチェーンコードのインスタンスをホストします
• ピアの承認
• トランザクションのシミュレーションと承認
• ピアのコミット
• トランザクションをブロックチェーンにコミットする前に、承認されたトランザクションを検証し、 トランザクション結果を検証します

それでは、ブロックチェーンにブロックが追加されるフローについて、イメージで紹介したいと思います。

２．ブロックチェーンにブロックを追加

認証機関とオーダーサービスおよびピアの承認とピアのコミットおよびクライアントアプリケーションをイメージのように配置されていたとします。

クライアントアプリケーションからトランザクションをブロックチェーンに送信します。

ピアの承認に関して、ブロックチェーンの現時点の状態からトランザクションをシミュレートして、Read/Writeのセットを生成してクライアントアプリケーションに応答を返します。

クライアントアプリケーションはRead/Writeのセットを取得して、その情報をオーダーサービスに転送します。

オーダーサービスは送信されたRead/Writeのセットをブロックに配置します。

オーダーサービスはピアに対してブロックの情報を送信します。

ピアのコミットからRead/Writeのセットを実行して、トランザクションがまだ有効かどうか確認し、有効な場合はブロックチェーンにコミットするか、無効なトランザクションを送り返します。

ブロックチェーンの状態の終わりがクライアントアプリケーションに返送されます。

これらの一連の動作がブロック追加時に行われます。

次にブロックチェーンのソリューションを利用するときに必要なアーキテクチャについてお話したいと思います。

ブロックチェーンを利用する際に利用するプラットフォームとして、主に利用されるのがKubernatesのコンテナになります。

Kubernetes（K8s）は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するためのオープンソースシステムであり、アプリケーションのグループ化、デプロイ、スケーリング、自己修復が可能です。

Kubernatesは以下のもので管理されています。

チャート

• Kubernatesコンポーネントを定義するテンプレートのバンドル

Helm（パッケージマネージャ）

• チャートをパッケージ化、検索、および展開を可能にします

３．ソリューションアーキテクチャ

Kubernatesレイヤにおけるアーキテクチャをお話します。

今回はThinkAgile HXにフォーカスしてお話したいと思います。

ThinkAgile HXで利用可能なコンテナプラットフォームとしては、Nutanix KarbonおよびRedhat Openshiftの２つになります。

こちらの二つに関しての特徴は以下の通りです。

Nutanix Karbon

• 効率的なワンクリックKubernates
• 高可用性な導入が可能
• 永続的なストレージのサポート：Volumes / FilesをサポートしたCSI

Red Hat OpenShift

• レノボのリファレンスアーキテクチャ
• 高可用性な導入が可能
• 永続的なストレージのサポート：NFS

Karbonについては、Nutanixプラットフォームの使いやすさの兼ね備えたコンテナプラットフォームであり、Redhat Openshiftについてはレノボのリファレンスアーキテクチャになっています。

こちらが揃ったら、次にアプリケーションを搭載していきます。

コンテナ上にブロックチェーンに必要なアプリケーションのPodsを作成し、その中で認証機関のパッケージをインストールしてIDを作成します。

次にオーダーサービスをインストールします。オーダーサービスに相当するものはApache Kafka（スケーラビリティに優れた分散メッセージキュー）およびFabric Orderer(クライアントから送付されたトランザクションの順序付けをし、ブロックチェーンネットワーク内の Peer に送信)になります。

インストール後はOrder IDをセットアップします。

最後にインストールするのが、Peerに関するアプリケーションになります。Apache CouchDB（ドキュメント指向のオープンソースデータベース。NoSQLの分類に属します）とFabric Peerになります。

こちらをセットアップ後にChannelを作成して、Channelに参加することでブロックチェーンを利用できます。

最後にHyperledgerの画面をご紹介しておきます。

【メイン画面】

【Script File】

【Transaction Record】

以上、よろしくお願い致します。

Blockchainに関して（その１）

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はBitCoinなどで利用されているテクノロジーのブロックチェーンをお話したいと思います。内容については、複数回でお話したいと思います。

まず、ブロックチェーンをWikipediaなどで調べると、分散型台帳技術、または、分散型ネットワークと呼ばれ、ビットコインの中核技術を原型とするデータベースである。ブロックと呼ばれる順序付けられたレコードの連続的に増加するリストを持つ。各ブロックには、タイムスタンプと前のブロックへのリンクが含まれている。理論上、一度記録すると、ブロック内のデータを遡及的に変更することはできない。ブロックチェーンデータベースは、Peer to Peerネットワークと分散型タイムスタンプサーバーの使用により、自律的に管理される。と記載があります。

WikiPediaのURL（Blockchain）

https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3

では、そのブロックチェーンにどのようなコンポーネントが存在するのかお話したいと思います。

１．ブロックチェーンについてして理解してみよう

ブロックチェーンは３つの主要コンポーネントでなりなっています。

３つの主要コンポーネント

• Distributed Ledger Database【分散台帳データベース】
• Consensus Network mechanism【コンセンサス（合意型）ネットワークアルゴリズム】
• Smart Contract execution environment【スマートコントラクトな実行環境】

Peer to Peerで動作していることから、それぞれのクライアントがデータベースを持ち、お互いのトランザクションを合意しながら処理を行うようにします。そのため、過去に発生したログなどは基本的に削除することはできません。

このように、過去の履歴をもとに処理を行うことから、サプライチェーンなどやオークションサイトなどにも利用されることがあります。

２．Distributed Ledger Database【分散台帳データベース】

分散台帳データベースとありますが、フルマネージド型のデータベースとも言えます。人によってはデータベースではないという方もいらっしゃいますが、一般的なデータベースと比較するものではないと考えます。

データの変更不可能性

ブロックチェーンはブロックと呼ばれる単位のデータの固まりを繋げたものになります。

ビットコインのブロックチェーンのブロックはgenesis blockと言う最初のブロックから始まり、ブロック内にはそのブロックのメタデータであるヘッダー部がある。

ヘッダーにはそのブロックが何個目（ブロック高）かや前のブロックのハッシュ値（previous block hash）が含まれる

前のブロックの内容が変更されるとブロックに含まれるprevious block hashも変更されるので、このブロック自体のhashも変更される。

ブロックの内容を変更するにはその後の世代のすべてのhash値を再計算しなければならず、これは非常に困難なためこのことがブロックチェーンの変更不可能性の肝となっている。

ブロックの構造ですが、5種類のフィールドで定義され、ブロックヘッダーについては、さらに6種類のフィールドで定義されます。

詳しい説明は長くなるので割愛させて頂きますが、過去に処理したトランザクションを参照しながらブロックが構成されることから、ネットワーク全体で巨大なジャーナルを所有することになるため、非常に大きなデータ量や処理能力を求められるシステムになります。

３．Consensus Network mechanism 【コンセンサス(合意型)ネットワークアルゴリズム】

Proof of Workとは、参加者全員が、同じブロックをブロックチェーンに追加するための仕組みです。
ビットコインでは、同じブロック（取引データ）を含むブロックチェーンが、参加者によって管理されています。
仮に、参加者が自分の好きなブロックを、ブロックチェーンに追加できるとしたら、同じデータを持つブロックチェーンを、みんなで管理することはできません。
Proof of Workとは全体で適切な意思決定を行うために、必要な仕組みと、まえがきで解説しましたが、 『全体の意思決定』=『参加者が同じブロックチェーンを管理する』ということです。

https://moblock.jp/articles/17193 　から引用

Proof of Elapsed Timeとは、Proof of Workにおけるマイニングによる作業証明の代わりに、その名が示すところの通り消費した時間の証明になっております。

ビザンティン・フォールトトレラントとは、分散コンピューティングにおいて、アルゴリズムを実行中に発生する故障・障害であり、不作為障害 (omission failures) と作為障害 (commission failures) が含まれる。不作為障害とは、クラッシュ、要求を受信しそこなうこと、応答を返しそこなうことなどを指す。一方、作為障害とは、要求を不正に処理すること、局所状態が壊れること、要求に対して不正または一貫しない応答を返すことなどを指す。ビザンティン・フォールトトレラントが発生すると、ビザンティン・フォールトトレラント性を備えていないシステムは、予期しない動作をすることがある。

https://ja.wikipedia.org/wiki/%E3%83%93%E3%82%B6%E3%83%B3%E3%83%81%E3%83%B3%E5%B0%86%E8%BB%8D%E5%95%8F%E9%A1%8C　から引用

Proof of Authorityとは、参加者が意見が一致せず、正しい意思決定できない場合、中央で管理している管理者に意思決定を委ねるものです。二重支払いなどを防ぐために必要になる機能となります。

４．Smart Contract execution environment 【スマートコントラクトな実行環境】

スマートコントラクトは、その名前の通り、コントラクト（契約）をスマートに行えるプロトコルのことです。つまりスマートコントラクトとは契約の自動化であり、契約の条件確認や履行までを自動的に実行させることができます。
取引プロセスを自動化できるため、決済期間の短縮や不正防止、仲介者を介さないことによるコスト削減にも寄与すると期待されており、各国で取り組みが行われています。また、ブロックチェーン上でスマートコントラクトを利用すると、ユーザー同士が直接取引を行う非中央集権型のサービスを実現でき、社会に大きな変化をもたらす可能性があると言われています。

５．パブリックブロックチェーンと許可されたブロックチェーン

ブロックチェーンには2種類あります。

パブリックブロックチェーン（パブリックチェーン）：

• 誰でもネットワークに参加でき、トランザクションを読み書きできます
• ネットワーク内の悪意のあるアクターの可能性を高める、不明な参加者のID

許可されたブロックチェーン（プライベートチェーン）：

• セキュリティリスクの軽減、取引を希望するパートナーのみが取引の一部です
• 関係者のみに見える取引
• 機能：データプライバシー、情報共有、不変性

こちらの種類にはそれぞれメリット・デメリットがあります。内容についてはイメージを参照して頂ければと思います。

実際にブロックチェーンを利用する場合には、正しい適合を見つけていく必要があります。

正しい適合性を見つけるためには、データベースの中で参加者の意思決定や過去のトランザクションに基づいて処理を行う必要があります。実際には利用シーンによってはブロックチェーンが必要にならないようなケースもあります。イメージは参考情報としてみて頂ければと思います。

参考として、サプライチェーンにおけるブロックチェーンの説明のイメージを載せておきます。

次回のブログは、オープンソースで実現するブロックチェーンHyperledgerやソリューションのアーキテクチャについてお話したいと思います。

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

VDIにおけるいくつかの注意事項

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はVDIにおける注意事項をいくつかお話したいと思います。

VDIを導入したものの、運用上使い物にならないものを構築しては意味がなくなってしまいますので、今回は運用上役立つ点をいくつか紹介したいと思います。

１．Windows10のライフサイクルについて

Windows10のライフサイクルについてですが、エディションにより期間が異なりますが、通常利用されるProエディションは機能更新プログラムがリリースされてから18か月というスパンになります。今までは長期間のサポートになっていましたが、期間毎にリリースされるバージョンで管理していく必要があります。これにより、Nutanixで管理する場合に対応しなければならないのが、AOSも合わせてこちらをアップデートする必要があります。

AOSのライフサイクルについては以下のURLをご参照下さい。

1年ぶりのLTS対応AOS5.10 とその追加機能のご紹介～AOS5.10の機能紹介～ - LTN Blog 〜 Lenovo Technology Network 〜

ここでAHVに関してはコメントしていきたいと思います。

Windows10については、現状だと1803以降についてお話します。

Windows10はHyper-Vのプラットフォームを推奨しているようですが、それはWindows10が仮想化環境を意識して最適な状況で動作しようとします。（詳細は上の説明を参照して頂ければと思います）

また、Windows10 1803以降でハイパーバイザーレベルのSyNC タイマー（Windows10においてTimeサーバーを管理）になることになります。 

こちらの機能はAOSの5.5.8 以降のLTSで対応可能になっております。

（STSはAOS5.9.1以上になります）

２．Officeのバージョンやセキュリティパッチについて

 こちらにブログにはOfficeのバージョンごとのパフォーマンスデータを掲載することはしませんが、Office 2016とOffice2019でLogin VSIなどの数値は異なります。どのようなシーン・どのような環境なのかも含めて、VDI導入の際にOffficeのバージョンも含めてテストされることを推奨いたします。（Office2019のVSIの数値が劣ることがあります）

また、セキュリティパッチについては、IntelのCPUレベル（Spectre / Meltdown / ForeShadow）の脆弱性が発見されています。是非導入時にセキュリティパッチも含めての検証をお願いします。

３．GPUがVDIソリューションにもたらすメリット

 GPUというとWorkStationに利用されることが思い浮かぶと思いますが、もちろんCAD向けVDIについてはGPUを利用することも考えられますが、昨今はNVIDIA社のGPUを利用したWindowsのVDI環境で利用されることがあります。Officeアプリケーションもスピードの向上も考えられますが、特にGPUがVDIで利用されるシーンとしては、Skypeなどの音声処理の時の効果が大きいようです。

また、GPUについては、VDI環境で利用した場合について顧客満足度が高い結果も出ております。以下のURLにLakeSide Softwareが測定した結果もございますので、参考にして頂ければと思います。

https://twitter.com/WillFulmer/status/1102968227213254656

 また、利用シーンについてGPUがもたらす効果をまとめてみました。GPUボードは少し高価にように思えますが、業務が効率化することが望めるなら是非検討してみてはいかがでしょうか。

４．VDIのサイジングルールとガイドライン

VDIのサイジングルールとガイドラインについてですが、様々なルールがインターねネット上に上がっているので、こちらでは一般的なコメントをしたいと思います。

事前のアセスする環境があるかと思いますが、最近はLiquidwareやLakesideなどのツールを利用して実施することがありますが、仮想環境で導入されているお客様は仮想化でユーザーの収容度を測れるツールなどもありますので、そのようなツールで現状把握してみてはいかがでしょうか。

データからサイジングする場合についてですが、メモリ・CPU（MHz単位）の使用率、ディスク容量などがあります。アプリケーションの仮想化を行う場合はアプリケーションの一覧も対象になります。

OSのバージョンなどやOfficeのバージョン、セキュリティパッチもサイジングに大きく影響与える要素であるため、そのあたりの考慮を忘れずにお願いします。

VDIを検討する際に、CPUの選択がユーザーの集約度に大きく変わります。

ただ、ユーザーに詰め込みすぎるのもHAでの切り替え時間もあったり、消費電力に大きく影響することもありますので、コアの多いものや周波数の高いものを選択するかはアプリケーション次第で決定したほうがと良いと思われます。

また、どのようなユースケースなのかも把握する必要があります。

リソース要件もありますが、アプリケーションの利用方法やデスクトップが永続的に利用するタイプか毎回ログインするたびにデスクトップがクリアされる非永続型なのかによって、システムの選択方式が変わりますのでご注意下さい。

５．クラスタのサイズの決定

VDIでHCIを選択する際にスケールアウトできるからVDI！という感じでシステムを決定して、１つのクラスタの中にVDIのノードを定義してしまうと、運用上の問題が出てきてしまいます。

例えば、こちらは一例としてESXiでクラスタを構成した場合、ファームウェアのアップデートするときのメンテナンス（システム停止はしませんが）を記載しています。

16ノードのクラスタで運用した場合に約4時間程度のメンテナンスになりますが、これが32ノードの場合は8時間くらいかかります。

アップデート作業中は管理者は現地にずっと待機しなければならず、システム停止はしなくとも、メンテナンスの作業が長くなることは管理者の対応も大変ですので、１クラスタのノード数は是非部署単位で小分けることをお薦めします。

こちらは約2000ユーザーを１つのポッドに定義して、25000ユーザーを収容した例になります。VDI案件は大規模になりやすいことから、運用しやすいポッドの定義して是非メンテナンスの短いシステムの検討をよろしくお願い致します。

以上、よろしくお願い致します。

VDIとNutanix Filesの組み合わせのメリットとWindows10イメージの最適化に関して

 

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのVDIソリューションのお話の第一弾としてファイルサーバーに関するお話とWindows10のVDI化におけるお話したいと思います。

 

VDIを検討するにあたり、容量やパフォーマンスなど要件を満たしながら、運用もシンプルにしていく必要があると思いますが、例えば1ユーザーあたりの容量が30GB必要で2000人ものユーザーを収容するとなるとストレージだけでも相当な容量になったりします。

また、パフォーマンスについても利用するユーザーの始業時のログオンストームなどを考慮してIOPSの高いストレージを実現するにあたり、かつてはVDIで大規模をストレージを導入することも少なくありませんでした。

Nutanixに限らず、昨今はSSDの単価も下がってきていることからハイブリッドおよびオールフラッシュのストレージなども導入できるようになっており、大規模なストレージを導入する必要がなくなってきております。

１．ホームディレクトリとユーザープロファイル

ホームディレクトリで利用するデータについては、テキスト・写真・音声など様々なデータがあります。

パフォーマンス面ではデバイスの進化でハイエンドのストレージの必要性はなくなっているものの、ホームディレクトリとユーザープロファイルで必要な容量についてはファイルサーバーで用意しなければなりません。

Nutanixに関しては、Nutanix Filesでファイルサーバーを実現することができます。以前まではファイルサーバーのストレージを用意することは非常に高価になっておりましたが、昨今Nutanixのライセンス体系もHDDの容量に関しては課金対象からは外れることもあり、非常に提案することが容易になっております。

２．部門間のファイル共有

部門間のファイル共有について考えてみましょう、各部門のファイルサーバーと言えば今まではNetApp/EMC社のストレージを利用したり、クラウドストレージ（Dropbox/Google Drive）などを利用していたかと思います。統合ストレージを利用することで、ストレージを効率することができる一方でスケールアウトということではパフォーマンスにボトルネックが生じてしまうことが考えられます。

３．Nutanix FilesとVDI – EUC導入のためにさらなる一歩

EUCの導入については、Nutanixは最適なソリューションです。

VDIの環境はスケールアウトで拡張することもできますし、マルチハイパーバイザーであることでVMwareもしくはCitrixの環境でも利用することができます

また、Nutanix FilesもWindowsのファイルシステムも対応していることかつ、スケールアウトのファイルサーバーとしても利用可能なため、すべて統合されてかつ管理も一括でできる優れものです。

HA/DR機能も標準でサポートしており、VDIインフラのおけるサイロを排除できる単一プラットフォームです。

メリットについても以下に記載致しますので、参考までに見て頂ければと思います。

次にWindows10に関する点で少し説明したいと思います。

 

４．Windows10のイメージを最適化

2020年1月にWindows7がEOLを迎えることで、Windows10への移行が現状行っているユーザー様もいらっしゃるかと思いますが、Windows10を利用するにあたりイメージを最適化する必要があります。

こちらの図に項目をまとめています。

最適化するにあたり、無効化する必要があるもの、設定を削除するもの、設定を変更するものなどがあります。これらに注意しながら最適化を行って頂ければと思います。

最適化にあたり、必要なガイドとツールについては英語の内容になりますが、以下のURLをご参照頂ければと思います。

 

最適化ガイドとツール

ガイド

• Windows 10 Optimization Guide from Citrix : https://support.citrix.com/article/CTX216252
• Windows 10 guide from VMware :
  https://techzone.vmware.com/creating-optimized-windows-image-vmware-horizon-virtual-desktop

ツール

• Citrix Optimizer :
  https://support.citrix.com/article/CTX224676
• VMware OS Optimization tool :
  https://labs.vmware.com/flings/vmware-os-optimization-tool
• Desktop Virtualisation BPA :
  http://www.bpanalyzer.com/

 

次回の投稿についてもVDIの内容を予定しておりますので、引き続きよろしくお願い致します。

 

高速イーサネットの帯域を有効利用可能なテクノロジーUFP（Unified Fabric Protocol）について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は表題のテーマでお話をしたいと思います。

前回のブログにて高速Ethernetの必要性のお話させて頂いたかと思いますが、実際に高速ネットワークを有効的に利用しなければ意味はありません。

今回ご紹介するUFP（Unified Fabric Protocol）は、仮想環境におけるネットワーク環境を有効活用可能な技術になります。実際にはブレードサーバーなどで利用されるテクノロジーですが、ラックスイッチやラックサーバーでも利用可能な技術です。

Lenovoがスイッチ製品を取り扱う前からこの技術はすでに利用されておりました。

様々なワークロードを動作させる上で、アプリケーションによってはネットワーク帯域を必要とするものもあります。

それではUFPの説明に移りたいと思います。 

１．UFP（Unified Fabric Protocol）とは？

UFPを説明する前にVirtual Fabric Adapter（VFA）をご説明致します。

VFAは10Gb（以上の）イーサネットをポートを分割することで帯域を効率良く使用することができる機能です。

※UFPはVFAで動作する帯域分割する機能です。

VFAには柔軟かつ信頼性の高い各機能が備わっており以下のようなものがあります。

・アダプター～スイッチポート間でのバーチャル チャネル（論理経路）毎の
　帯域制御が可能

　UFP：1Gbps以上100Mbps単位

　vNIC：100Mbps単位

・送信、受信、双方の通信で帯域制御が可能

・ダイナミックな帯域制御値の割り当て変更が 可能

・ハードウェアFCoE もしくはHW iSCSIのサポート

複雑になりがちな仮想化環境においてVirtual Fabricならユーザーネットワーク環境の要求に対して柔軟に対応可能になります。

それでは、VFAおよびUFPの特徴については次のイメージでご説明致します。

２．UFP（Unified Fabric Protocol）の特徴

VFAとUFPの特徴として、いくつかのモードがあります。すべてのモードについてはせ説明はしませんが、UFPについては以下の機能が可能になっています。

• 帯域制御値などの変更時にサーバー再起動が不要
• 双方向（送受信）の帯域割り当ておよび制御が可能
• ４つのモードで用途に合わせた柔軟な構成が可能
• トンネルモード、トランクモード、アクセスモード、FCoEモード
• UFPをサポートするLenovo Networking スイッチと10G以上のアダプターの
  組み合わせ

双方向で帯域制御ができることと４つのモード（Tagの制御などの違いになります）で仮想ネットワークをVLAN単位で帯域制御します。

４つのモードの詳細は以下のURLリンクのドキュメントをご参照ください。

http://www.lenovojp-cms.com/cmscontents/gdfiles.php?md=144

３．UFPの構成について

UFPを構成するにあたり、物理側のNIC（VFA）とハイパーバイザーにてVLAN設定を行います。また、物理スイッチ側でInnerとOuterでそれぞれ設定を行います。

物理側のスイッチ側では、入り側のVLANについて帯域制御の設定を行います。それに合わせてTaggingの設定も行う必要があります。

パケット構造については、InnerとOuterのタグについてそれぞれCuster TAG-VLAN とService TAGで制御を行います。設定行う際にいくつか制限があります。以下は制限の一部ですが、詳細は以下URLのドキュメントをご参照下さい。

・仮想ポートで設定できるVLANの最大数は256

・VLAN ID 4002～4005はサービスタグ（Outer-Tag）用に予約されているため、カスタマーVLANとして使用できません

・UFPを構成した仮想ポートを使ってVLAGを構成することはできません

https://flexsystem.lenovofiles.com/help/index.jsp?topic=/com.lenovo.acc.en4093.doc/IO_Module_EN4093R.html

４．UFPの帯域制御について

・従来のVNIC1テクノロジーや、他社類似技術は、厳格な帯域割り当てを実行するために、割り当て帯域の上限に到達した場合には、超過する部分についてはパケットドロップを実行しています。

・UFPテクノロジーでは新たに”Minimum（最低保証値）”および”Maximum（最大値）”の考え方を導入する ことにより、未使用状況の帯域が存在する場合には、最大値まで空き帯域を活用することが可能となりました。輻輳時には最低保障値の値をもとに帯域制御が行われます。

帯域制御が行われている図については、イメージをご参照ください。

その他、最低帯域と最大帯域については以下の説明をご参照ください。

最低帯域（min)
各仮想ポートのデフォルト値は2.5Gbps
– qos bandwidth {min <10-100>}の設定を明示的に行わなかった場合、この値が割り当てられた状態になります。
各仮想ポートに対し、割り当て可能な値は最低で1Gbps
100Mbps毎に帯域を設定可能
同じ物理ポート上の4つの仮想ポートで使用可能な最低帯域（min）の合計は、 最大で物理ポートの帯域（10Gbps）

最大帯域（max)
各仮想ポートのデフォルト値は10Gbps（qos bandwidth {max <10-100>}の設定を明示的に行わなかった場合、この値が割り当てられた状態になります）
100Mbps毎に帯域を設定可能
同じ物理ポート上の4つの仮想ポート全てで10Gbpsを指定可能

５．VLAGー仮想リンクアグリゲーション

HCIなどの構成でVLAGを構成する際は上記の構成を取ります。これはVLAGの動作を示していますが、一般的にサーバーから送信されるパケットは各スイッチ間で同期がとられながら、マックアドレスを登録していきます。

ですが、これがそのままUFPのトンネリング機能で使えるかそうかです。

UFPトンネルモードは同一物理ポート上の異なる二つ以上の vNIC(仮想ポート)が同じVLAN(S-TAG) に属することは出来ません。

つまり、アップリンクは1つのパススルードメインにのみ関連付けることができますが、複数のドメインで共有することはできません

この場合にどのように対処するのかをコンフィグもコンフィグも含めて記載します。

例：Lenovo CNOS上の802.1Qトンネリングモード

例えば802.1Qのトンネリングモードの場合はイメージのような構成にした上で、以下のようなコンフィグを行います。

【コンフィグ例】

!   Recommended to configure a host name - change as desired

hostname NE2572-1

! Disable STP since no loops

spanning-tree mode disable

!   Create desired VLAN (VLAN 1 exists by default)

vlan 3091

name "Tunnel-VLAN"

vlan 3090

name "vLAG-ISL-native"

!   Configure Server facing ports for access with Q-in-Q tunneling

int eth 1/1-46

desc "Server-Data-Ports"

switchport access vlan 3091

switchport mode dot1q-tunnel

!   Configure uplinks to be used as part of vLAG aggregation

int eth 1/47-48

desc vLAG-uplinks

switchport access vlan 3091

switchport mode dot1q-tunnel

channel-group 3001 mode active

!   Configure vLAG ISL links

int eth 1/53-54

desc vLAG-ISL

switchport mode trunk

switchport trunk native vlan 3090

switchport trunk allow vlan 3090,3091

channel-group 4001 mode active

!   Configure vLAG (healthcheck pointing at other mgmt. 0 address)

vlag enable

vlag tier-id 10

vlag isl port-channel 4001

vlag hlthchk peer-ip 192.168.50.52 vrf management

vlag instance 1 port-channel 3001 enable

!   Configure MGT for vLAG healthcheck and out of band management

int mgmt 0

ip add 192.168.50.51/24

! Configure default gateway for MGT port if needed

vrf context management

ip route 0.0.0.0 0.0.0.0 192.168.50.1

! Exit and save config

end

save

この設計/設定では、すべてのVLANタグ付きトラフィックはすべてのVLANを設定することなくLenovoスイッチを通過します。

例：Lenovo CNOS上のVLAN対応モード

この設計/設定では、すべての必要なVLANが事前に作成・許可されます。 この例においてはVLAN100~VLAN300を使用しています。

【コンフィグ例】

!   Recommended to configure a host name - change as desired

hostname NE2572-1

! Disable STP since no loops

spanning-tree mode disable

!   Create desired VLAN (100-300 will be used by ACI and hosts)

vlan 100-300

vlan 3090

name "vLAG-ISL-native"

!   Configure Server facing ports to allow all VLANs

int eth 1/1-46

desc "Server-Data-Ports"

switchport mode trunk

!   Configure uplinks to be used as part of vLAG aggregation

int eth 1/47-48

desc vLAG-uplinks

switchport mode trunk

channel-group 3001 mode active

!   Configure vLAG ISL links (similar to Cisco Peer-link in vPC)

int eth 1/53-54

desc vLAG-ISL

switchport mode trunk

switchport trunk native vlan 3090

channel-group 4001 mode active

! Configure vLAG (healthcheck pointing at other mgmt. 0 address)

vlag enable

vlag tier-id 10

vlag isl port-channel 4001

vlag hlthchk peer-ip 192.168.50.52 vrf management

vlag instance 1 port-channel 3001 enable

! configure MGT for vLAG healthcheck and out of band management

int mgmt 0

ip add 192.168.50.51/24

! Configure default gateway for MGT port if needed

vrf context management

ip route 0.0.0.0 0.0.0.0 192.168.50.1

! Exit and save config

end

save

６．UFPローカルドメインモードーアクセスとトランク

UFPのローカルドメインモードの時のアクセスモードとトランクモードについてはイメージだけ載せておきます。VLANを通してそれぞれのポートへのアクセスも可能になりますし、InnerからのネットワークパケットもVLANを通じてOuterへ流れるようになります。

高速Ethernetの場合には、このような技術などを利用しながら、ワークロードが利用するネットワークを設計することをお薦めします。

以上、よろしくお願い致します。