LTN Blog 〜 Lenovo Technology Network 〜

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

Blockchainに関して(その2)~Hyperledger Fabricおよびアーキテクチャについて~

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

 

1.Hyperledger Fabricについて

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

f:id:t_komiya:20190812213727p:plain

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

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

 

2.Hyperledger Fabricのコンポーネント

f:id:t_komiya:20190812214020p:plain

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

 

CACertificate Authority:認証機関

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

オーダーサービス

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

ピア(対等者):

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

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

 

2.ブロックチェーンにブロックを追加

f:id:t_komiya:20190812214300p:plain

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

f:id:t_komiya:20190812214644p:plain

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

f:id:t_komiya:20190812214754p:plain

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

f:id:t_komiya:20190812214944p:plain

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

f:id:t_komiya:20190812215113p:plain

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

f:id:t_komiya:20190812215255p:plain

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

f:id:t_komiya:20190812215355p:plain

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

f:id:t_komiya:20190812215555p:plain

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

 

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

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

f:id:t_komiya:20190812215833p:plain

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

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

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

 

チャート

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

Helm(パッケージマネージャ)

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

 

3.ソリューションアーキテクチャ

f:id:t_komiya:20190812220352p:plain

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

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

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

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

Nutanix Karbon

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

Red Hat OpenShift

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

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

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

f:id:t_komiya:20190812221237p:plain

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

f:id:t_komiya:20190813002127p:plain

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

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

f:id:t_komiya:20190812222042p:plain

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

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

 

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

f:id:t_komiya:20190812223139p:plain

【メイン画面】

f:id:t_komiya:20190812223245p:plain

【Script File】

f:id:t_komiya:20190812223404p:plain

【Transaction Record】

 

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

Blockchainに関して(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は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

 

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

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

f:id:t_komiya:20190812090612p:plain

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

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

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

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

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

2.Distributed Ledger Database【分散台帳データベース

f:id:t_komiya:20190812092803p:plain

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

 

データの変更不可能性

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

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

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

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

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

f:id:t_komiya:20190812093631p:plain

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

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

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

f:id:t_komiya:20190812095102p:plain

 

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

 

4.Smart Contract execution environment 【スマートコントラクトな実行環境

f:id:t_komiya:20190812102620p:plain

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

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

f:id:t_komiya:20190812102947p:plain

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

パブリックブロックチェーン(パブリックチェーン):

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

許可されたブロックチェーン(プライベートチェーン):

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

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

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

f:id:t_komiya:20190812103345p:plain

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

 

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

f:id:t_komiya:20190812212052p:plain

 

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

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

 

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

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

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

 

1.Windows10のライフサイクルについて

f:id:t_komiya:20190804162904p:plain

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

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

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

ここでAHVに関してはコメントしていきたいと思います。f:id:t_komiya:20190804163944p:plain

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

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

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

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

(STSはAOS5.9.1以上になります)

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

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

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

 

3.GPUVDIソリューションにもたらすメリット

f:id:t_komiya:20190804170034p:plain

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

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

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

f:id:t_komiya:20190804170643p:plain

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

4.VDIのサイジングルールとガイドライン

f:id:t_komiya:20190804171011p:plain

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

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

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

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

f:id:t_komiya:20190804171509p:plain

f:id:t_komiya:20190804171526p:plain

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

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

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

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

5.クラスタのサイズの決定

f:id:t_komiya:20190804172207p:plain

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

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

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

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

f:id:t_komiya:20190804172813p:plain

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

 

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

 

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

 
皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのVDIソリューションのお話の第一弾としてファイルサーバーに関するお話とWindows10のVDI化におけるお話したいと思います。
 
VDIを検討するにあたり、容量やパフォーマンスなど要件を満たしながら、運用もシンプルにしていく必要があると思いますが、例えば1ユーザーあたりの容量が30GB必要で2000人ものユーザーを収容するとなるとストレージだけでも相当な容量になったりします。
また、パフォーマンスについても利用するユーザーの始業時のログオンストームなどを考慮してIOPSの高いストレージを実現するにあたり、かつてはVDIで大規模をストレージを導入することも少なくありませんでした。

f:id:t_komiya:20190803225819p:plain

Nutanixに限らず、昨今はSSDの単価も下がってきていることからハイブリッドおよびオールフラッシュのストレージなども導入できるようになっており、大規模なストレージを導入する必要がなくなってきております。
1.ホームディレクトリとユーザープロファイル
f:id:t_komiya:20190803224934p:plain
ホームディレクトリで利用するデータについては、テキスト・写真・音声など様々なデータがあります。
パフォーマンス面ではデバイスの進化でハイエンドのストレージの必要性はなくなっているものの、ホームディレクトリとユーザープロファイルで必要な容量についてはファイルサーバーで用意しなければなりません。
Nutanixに関しては、Nutanix Filesでファイルサーバーを実現することができます。以前まではファイルサーバーのストレージを用意することは非常に高価になっておりましたが、昨今Nutanixのライセンス体系もHDDの容量に関しては課金対象からは外れることもあり、非常に提案することが容易になっております。
2.部門間のファイル共有

f:id:t_komiya:20190803232746p:plain

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

f:id:t_komiya:20190803234043p:plain

EUCの導入については、Nutanixは最適なソリューションです。
VDIの環境はスケールアウトで拡張することもできますし、マルチハイパーバイザーであることでVMwareもしくはCitrixの環境でも利用することができますf:id:t_komiya:20190803234445p:plain
また、Nutanix FilesもWindowsのファイルシステムも対応していることかつ、スケールアウトのファイルサーバーとしても利用可能なため、すべて統合されてかつ管理も一括でできる優れものです。
HA/DR機能も標準でサポートしており、VDIインフラのおけるサイロを排除できる単一プラットフォームです。
メリットについても以下に記載致しますので、参考までに見て頂ければと思います。

f:id:t_komiya:20190803234823p:plain

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

f:id:t_komiya:20190803235259p:plain

こちらの図に項目をまとめています。
最適化するにあたり、無効化する必要があるもの、設定を削除するもの、設定を変更するものなどがあります。これらに注意しながら最適化を行って頂ければと思います。
最適化にあたり、必要なガイドとツールについては英語の内容になりますが、以下のURLをご参照頂ければと思います。
 
最適化ガイドとツール

ガイド

ツール

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

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

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

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

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

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

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

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

1.UFP(Unified Fabric Protocol)とは?

f:id:t_komiya:20190728223027p:plain

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

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

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

 

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

・アダプターッチポート間チャル チャネル(論理経路毎の
 
域制が可能

 UFP1Gbps以上100Mbps単位

 vNIC100Mbps単位

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

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

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

 

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

 

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

2.UFP(Unified Fabric Protocol)の特徴

f:id:t_komiya:20190728223727p:plain

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

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

 

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

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

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

 

3.UFPの構成について

f:id:t_komiya:20190728224348p:plain

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

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

 

f:id:t_komiya:20190728224731p:plain

パケット構造については、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

4.UFPの帯域制御について

f:id:t_komiya:20190728225311p:plain

・従来の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を指定可能

5.VLAGー仮想リンクアグリゲーション

f:id:t_komiya:20190728215214p:plain

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

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

f:id:t_komiya:20190728230634p:plain

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

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

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

 

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

f:id:t_komiya:20190728230910p:plain

例えば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対応モード

f:id:t_komiya:20190728231223p:plain

この設計/設定では、すべて必要な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

 

6.UFPローカルドメインモードーアクセスとトランクf:id:t_komiya:20190728231731p:plain

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

 

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

 

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

 

HCIで高速Ethernetとクラウドネットワーク環境に必要なものとは?

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

似たような内容は以前にも紹介しているので、過去の記事のURLも合わせて載せておきますので、参考にして頂きながら読んで頂くことが良いと思います。

 

HCIをご利用される際に、もう10Gbあれば十分であると思っている方も多いかと思います。小規模のHCIであればそれはある意味正しいと思いますし、すべての利用シーンでそれが正しいと言えるのでしょうか。

仮想マシンを動作させる場合に、リソースをあまり使用しないアプリケーションなどであれば、問題ないかもしれませんが、IOPSやメモリ容量を必要としているワークロードにもそれは正しいとは言えないかと思います。 

過去に記載したブログで、NutanixのAHVTurboなどAOSでIOパフォーマンスは向上させる技術をお話したかと思いますが、デバイスなども進化してきている中で、ソフトウェア側だけの技術だけに頼るのではなく、もう少しハードウェアの視点で理解した上で、効率的はインフラ構成を考えていくことも必要だと思います。 

 

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

Intel Cascade Lake (Xeon Scalable 第2世代) CPUとOptane Persistent Memoryについて - LTN Blog 〜 Lenovo Technology Network 〜

 

先週のブログの中で、Intel社のPersistent Memoryのお話をさせて頂いたかと思いますが、そのあたりも含めてネットワークのお話させて頂きたいと思います。

1.高速Ehternetが必要な理由とは?

f:id:t_komiya:20190728144546p:plain

Persistent Memoryが必要になってきた背景にSAP HANAなどのインメモリデータベースなど高速処理で低遅延が求められるワークロード(AIなども含む)が求められています。それらのワークロードを実行するにあたり、他のノードとのデータをやり取りする上で低遅延を実現するには高速Ethernetが必要となります。

Persistent Memoryに限らず、NVMeなどは最大スループットが28Gb/sが出せるデバイスが登場してきており、10Gbのネットワーク帯域では足りなくなってきます。

このように、今後登場するデバイスに対して、最適な環境を準備する意味でもハードウェアを理解することは非常に重要なお話になります。

2.高速レーンが良い理由とは?

f:id:t_komiya:20190728145622p:plain

 高速なネットワークということですが、実際に10GbE以上のネットワークがどのようなものかを市場を見てお話したいと思います。

まずは25GbEと10GbEについて簡単に比較してみましょう

価格面で1.5倍程度、帯域幅では2.5倍になっています。

また、10GbEと25GbEとは互換性もありますが、それだけでメリットでしょうか?

以下のリンク(英語)を見て頂きますと、25GbEを導入することで、消費電力の観点で非常に良い内容が記載されております。一般のお客様にはあまり関係ないように思われますが、データセンターの事業者様は積極的に導入される方がよいかもしれません。

B'com Shifts Switch to 12.8 Tbits/s | EE Times

また、25GbEを選択することにより、100GbEへの視野も見えてきます。

それは40GbEと50GbEの比較を見てもわかるように、金額帯は同じでもスイッチの密度も上がります。

そのため、今後はワークロード処理性能を少しでも求めるお客様は是非CPU/メモリ/ストレージ/ネットワークの選択は上位のものを選択することも検討したほうがよいと思います。

3.クラウドネットワーク環境に必要なもの

クラウドのネットワーク環境に求められるもの、それはおそらく以下のようなものになるのではないかと思います。

・拡張性

・柔軟性

・堅牢性

実際にHCIなどで良く出てくる言葉になりますが、拡張性に関しては一度導入したネットワークがサーバーを増設するような形で簡単に拡張できること、堅牢性についても一つのデバイスが障害が起きて全損するようなシステムでは意味がありません。

また、柔軟性に関しても頻繁に変更が行われるクラウド環境において、変化に追随できなければなりません。Infrastructure as Code という言葉もある通り、インフラの構築、設定変更などを迅速行うためには、インフラそのものをコード化して管理していく必要があります。そのために、ネットワーク機器についてもREST APIやCCA(Continuous Configuration Automation)ツールなどの対応になります。

Infrastructure as Code - Wikipedia

上記のような内容について、Lenovoのネットワーク製品も対応してきております。

f:id:t_komiya:20190728152344p:plain

Lenovoのネットワーク製品(旧Blade Network Technology社)については元々データセンター向けのスイッチとして開発されていました。

現在はCloud Networking Operating Systemというクラウド対応のOSを開発しており、クラウド・プロセス自動化(Network Orchestration)対応についても行っております。また、Telemetryなどの予兆検知および将来予測なども含めて分析に関する処理も行うことができるようになっております。

ThinkAgile Network Orchestratorでネットワーク管理を簡素化! - LTN Blog 〜 Lenovo Technology Network 〜

Telemetryによるクラウド型ネットワークの可視化 - LTN Blog 〜 Lenovo Technology Network 〜 

f:id:t_komiya:20190728153709p:plain

こちらがLenovoのネットワーキング製品の構図になります。

一番下にハードウェア機器がありますが、先ほどご紹介したCNOSが中間層に構成され、その上で提供されるソフトウェアレベルのソリューションが提供されます。

4.CNOSのエコシステム統合
 f:id:t_komiya:20190728154053p:plain

CNOSについてはエコシステム対応がそれぞれしています。

プロセスの自動化という観点においては、Ansible/Chef/Peppetなどにも対応しております。また、仮想化との連携などについてもvRealizeシリーズの製品やNutanix Prismなども含めて対応しております。

一般的に利用方法としては、XClarityを導入してサーバー機器以外に、ネットワーク機器については監視することで、ネットワーク機器の障害でコールホーム連携で管理者からサポートへ連絡しなくても、サポート側プロアクティブな連絡をお客様にすることが可能になり、迅速な障害対応が行うことができます。

高速Ethernet対応も含めて、プロセスの自動化を含めてエコシステム対応を是非ご検討下さい。

 

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

Xi Frame Update情報および画面イメージ

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はXi Frameの情報のアップデートおよび画面イメージをいくつかご紹介したいと思います。

 

Xi Frameについては、以前こちらのブログでもご紹介しましたが、一部表現を訂正させて頂きたいと思います。

前回の投稿において、Xi FrameはマルチクラウドのDaaSのプラットフォームと申し上げましたが、Xi FrameはそのものはPaaSです。DaaSそのものはデスクトップまでを提供することになりますが、Xi Frameはあくまで各DaaS間のプラットフォームを管理しているところまで行っていますが、デスクトップサービスを提供しておりません。

Xi Frameは以下のURLにも載せておりますので、合わせてご参照頂きますようよろしくお願い致します。

https://blog.lenovojp.com/entry/2019/04/04/212235

 

それでは、今回の改めてXi Frameを紹介したいと思います。

1.Xi Frameを選択する理由

f:id:t_komiya:20190721174022p:plain

一般的なVDIは複雑でかつ柔軟性が乏しく、クラウド環境との世界との互換性がありません。また、1クリックなどの操作性や拡張性を望んでおり、またマルチテナント・マルチクラウドなどお客様にクラウドの選択の自由を与えることができます。

では、Xi Frameはどのように設定されるのかをお話したいと思います。

2.各ステップにおけるユーザーの選択

f:id:t_komiya:20190721174456p:plain

Xi Frameを利用するにあたり、選択する項目が5つあります。

・インフラの選択

 お客様はインフラを選択するにあたり、パブリッククラウド(AWS/Azure)とNutanix(AHV)を選択することができます。(今後対応クラウドも増えていきます)

f:id:t_komiya:20190721175352p:plain

・ユーザ認証基盤の選択

 お客様はいくつかの認証基盤を選択することできます。ADFS(オンプレ・Azure AD等)や様々な選択肢がありますが、SSOなどがサポートされていないケースもありますので、詳しくは選択する前にNutanix社に仕様を確認すると良いと思います。

・アプリケーションの選択

 利用するアプリケーションを選択することができます。

・ストレージの選択

 クライアントデータを保存する先のストレージを選択することができます。オンプレおよびクラウドストレージの指定ができます。

・ロケーション/デバイスの選択

 PCからも利用できますが、ブラウザでアクセスして利用することから、タブレットなどでも利用可能です。

 スマートフォンについては、利用可能ですが画面サイズの関係もありますので、ご注意下さい。

3.Xi Frameのプラットフォーム

f:id:t_komiya:20190721175848p:plain

Xi FrameはクライアントのイメージとなるSandboxと呼ばれるゴールドマスターを作成します。ゴールドマスターをLaunchして各ユーザーが利用可能なプールに展開します。

アプリケーションについて、Launch Padが別途用意されており、アプリケーションのみ提供しているUIもあります。

f:id:t_komiya:20190721180701p:plain

クライアントで動作させるアプリケーションなどでライセンスサーバーなどが別途必要であれば、外部で別途サーバーを用意して管理します。その他のサーバーも同様です。

4.プラットフォーム管理について

f:id:t_komiya:20190721180230p:plain

XiFrameはIDプロバイダーと呼ばれる管理プラットフォームで階層的に管理できます。Nutanixと契約する単位は顧客になりますが、顧客の範囲の元であればアプリケーションをいくらでも展開できますが、インスタンスの上限数には十分に気をつける必要があります。

5.実際の画面イメージ

f:id:t_komiya:20190721180815p:plain

こちらは、デスクトップ画面とLaunch Padの画面イメージです。

デスクトップの画面上にはアプリケーションの表示以外に、Xi Frameの動作状況が表示されています。バンド幅・レイテンシ・接続時間などの情報が表示されています。

Launch Padはアプリケーションの一覧が表示されます。対象のなるデスクトップは画面右下から選択して切り替えることも可能です。

f:id:t_komiya:20190721181109p:plain

ダッシュボードの画面になりますが、LaunchPadの設定および認証方式・Poolのキャパシティ設定になります。

デスクトップおよびアプリケーションはこちらの項目から設定します。利用するイメージの指定やデスクトップの画面を設定できます。

認証方式もFrame Accountでの設定だけでなく、SAMLやGoogleアカウントも設定可能です。

Poolの設定については、仮想マシンの最大数を制限できます。

f:id:t_komiya:20190721181541p:plain

Sandboxの設定画面です。こちらでゴールドイメージを作成します。イメージについては現在どのような状況(ON/OFF/起動中/停止中)なのかをイメージを表示されます。また、作成したイメージについては、スナップショットを取得することができます。(5世代)イメージをLaunchするときにもスナップショットは作成されます。

f:id:t_komiya:20190721181841p:plain

デスクトップを利用しているユーザーが作業で作成したファイルを保存する場合、基本は外部のファイルサーバーなどでデータを保存する必要があります。(再起動後はデータが保存している設定にはなっていない)【Persistentの設定していない限り】

そのため、外部のファイルサーバーと同期して、保存できるように設定するために、ダッシュボードから外部のストレージを設定しています。

設定後はデスクトップの右下でクラウドのアイコンが点滅します。点滅中は同期可能になっているため、アイコンを確認してデータを保存するようにしましょう。

f:id:t_komiya:20190721182432p:plain

アプリケーションを追加する場合は、ゴールドイメージにあたり仮想マシンに操作を行います。デスクトップに接続して、アプリケーションを新規をインストールをします。アプリケーションがインストール終了した後に、ポップアップが表示されます。

ポップアップに表示されているアプリケーションにチェックを入れるとアプリケーションがLaunch Padにアプリケーションが登録されます。

f:id:t_komiya:20190721182733p:plain

SandBox上のアプリケーションのタブを確認すると、チェック入れたアプリケーションが追加されています。これでアプリケーションをPool内のユーザーは共有できます。

また、登録したアプリケーションを削除するには、カーソルをマウスオーバーするとゴミ箱が表示されますので、クリックするアプリケーションが削除されます。

 

全ての操作がブラウザからすべて完結しますので、様々な端末から利用できます。

 

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

 

Intel Cascade Lake (Xeon Scalable 第2世代) CPUとOptane Persistent Memoryについて

 
皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのお話から離れてIntel CPUとPersistent Memory(永続性メモリ)についてお話したいと思います。
 
2019年4月にIntel社から第二世代のXeon Scalable プロセッサとしてCascade LakeシリーズのCPUとそれに合わせてPersistent Memoryについて発表がありました。
サーバー各社こちらのCPUを搭載サーバーを販売しておりますが、LenovoについてもThinkSystemシリーズは4月から、ThinkAgileシリーズはHX/VXシリーズは5月から、MXシリーズは6月から出荷開始しております。
今回はこちらのCPUの特徴とPersistent Memoryについてご説明するのですが、特にPersistent Memoryについては、様々な領域に影響を与えるテクノロジーであることから、焦点を当ててお話します。 
1.Cascade Lakeプロセッサについて

f:id:t_komiya:20190720223741p:plain

CasCade Lakeのプロセッサは前世代のSkyLakeの後継プラットフォームでリリースされていますが、今回のプラットフォームについては、CPUのリフレッシュだけではなく、Intel Optane DC Persistent MemoryのサポートとDeep Learning およびAI向けの処理にも対応した機能が盛り込まれております。
 

f:id:t_komiya:20190720224636p:plain

・向上したパフォーマンス
 前世代に比べてCPUのパフォーマンスとメモリのパフォーマンスが向上しております。
・DC Persistent Memoryのサポート
 次章で詳しく紹介します
・Deep Learning およびAIワークロードをサポート
 VNNI(Vector Neural Network Instructions)と呼ばれる AVX512 の拡張命令に対応し、従来世代よりもよりディープラーニングの処理が高速になる「Intel Deep Learning Boost」などの新機能が搭載
 
ここで、Cascade LakeのCPUに関して説明したいと思います。
2.Intel Xeon Processor Scalable ファミリー

f:id:t_komiya:20190720224835p:plain

CPUの型番としては、3桁目の百のくらいが2に変わっただけに思えますが、実は型番の最後のアルファベットに今回特徴があります。
リソースの優先順位をつけて周波数を変更することによりワークロードの処理を効率化するSpeed Select TechnologyやNFV向けに最適化された技術や高密度の仮想化環境を実現するものやメモリ搭載容量が増やせるモデルも存在しております。
つまり、ワークロードの種類により、お客様の要望に応じたCPUの選択が実現することになります。
CPUのラインナップについては以下のページご確認頂けます。
 
今回はSpeed Select Technologyについて簡単に説明したいと思います。
3.Speed Select Technology(SST)

f:id:t_komiya:20190720230818p:plain

SSTは1台のサーバー内で動作しているワークロードを効率良く処理させるために、ワークロードに優先順位をつけて、CPUのリソースを一時的に多く割り当てます。
詳細内容については、イメージを参照して頂ければと思います。
また、他のページにも記載はありますので、そちらも合わせて参照して頂ければと思います。
4.Intel Optane DC Persistent Memory

f:id:t_komiya:20190720231137p:plain

このソリューションは、大量のデータをCPUの近くに移動するため、(最初にストレージから取得することなく)リアルタイムでアクセス、処理、および分析できます。この製品は高性能で、低レイテンシでDDR4 DRAMに匹敵します。さらに、NAND SSDに一般的に見られる、より大容量のデータ持続性機能があります。1サーバーあたり100万近いIOPSを実現することも可能です。(ワークロード次第です)

f:id:t_komiya:20190720231730p:plain

つまりお客様はより多くのデータをより高速に処理するためにCPUに近づけることができ、システムの電源を入れ直すとデータがメモリに残ることになります。

5.2つのメモリアクセスモード

f:id:t_komiya:20190720231858p:plain

Persistent Memoryについては、2つのアクセスモードがあります。
・Memory Mode
 混在しているDRAMとOptane DC Persistent Memoryのうち、DRAMをキャッシュとして、Optaneをメインメモリとして使います
・App Direct Mode
 アプリケーションがDRAMとOptaneをそれぞれ別々に利用することができ、Optaneは高速ストレージとして利用することができます
(Persistent Memoryは現時点では512GB最大容量となります)
6.CPUとメモリ構成について

f:id:t_komiya:20190720233404p:plain

また、CPUとメモリ構成については、イメージのようになっています。1CPUから最大6枚のPersistent Memoryが利用可能ですが、チャネルの関係で偶数枚を選択する必要があります。また、6枚構成時が最大パフォーマンスを発揮できるようになっていますので、6枚単位で必要な容量を選択すると良いでしょう。
7.DCPMMのターゲットユースケース

f:id:t_komiya:20190720233644p:plain

Persistent Memoryのターゲットとしているエリアは高速メモリアクセスが必要としている、インメモリデータベースや負荷が高いデータベース、仮想化環境が対象になります。VDIなどの同時アクセスが発生するワークロードについても効果的と言えるでしょう。
また、RDMAなどの技術と組み合わせてPMoF(Persistent Memory over Fabric)などで利用されることが想定されます。そのほか、NFViなどのエリアでも利用は想定されますが、エッジコンピューティングでAI環境でこちらが利用できると非常に効果的に投資できるかもしれません。
VMwareやMicrosoftについてこちらの技術に対応しておりますが、各種ソリューションについては未対応のところもありますので、ご確認頂ければと思います。
 
以上、よろしくお願い致します。
 

HCIの容量増設時の注意事項について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は最近お問い合わせが多いHCIの容量増設時における注意事項について説明したいと思います。

一般的なHCIにおいて、リソースを増やす場合にノードを追加すると思います。ただし、ノードの増設方法によってはリソースを有効的に利用されないこともあります。そのため、今回は容量増設において注意点も含めてお話したいと思います。
(今回は容量は効率的に利用されますが、運用上知っておいた方がよいお話になります)

1.HCIでリソースが少なくなった場合のノード追加

f:id:t_komiya:20190715012214p:plain

HCI環境においてCPU・メモリリソースが不足した場合、ノード増設で対応すると思います。こちらのイメージのようにHCIを構成しているクラスタに対して、ノードを追加することで、リソースは追加されます。ホスト単位で利用可能なリソースは限られるもののクラスタ全体としては、リソースが追加されているので特に問題ありません。また、異機種混在であっても、追加ノードのCPU・メモリリソースだけが多くなるだけで利用する分には問題ありません。(HAなどでリソース不足があった場合、仮想マシンが立ち上がらない場合はありますが、通常利用では問題ありません)

ただし、これがストレージのリソースについて、同様のことが言えるのかどうか説明したいと思います。

2.ストレージ容量を増設するときの場合

f:id:t_komiya:20190715012735p:plain

ストレージ容量を増やす場合、普通に追加作業するだけで問題ないだろうか?

実際に各社のHCIの仕様は様々でありますが、今回はNutanixのアーキテクチャでお話したいと思います。

イメージで記載する分には問題ないように思えますが、Nutanixのストレージの仕様について一度整理してみましょう。

3.データローカリティについて

f:id:t_komiya:20190715013154p:plain

データローカリティについて、お話したいと思います。

データローカリティでホスト上の仮想マシンはホスト上のCVMを経由して、ローカルホスト上のSSDにデータを書き込みます。書き込み後はデータの冗長性を保つために、RF2であれば、他のホストにデータをコピーします。(RF3であれば2つのホストにコピー)

つまり、データをクラスタ内に二つが存在する状態がHCIであるべき姿になるため、これを踏まえて、ノード増設した場合にどのような動きになるのかを整理してみたいと思います。

4.1台しか増設しなかった時のストレージ容量について

f:id:t_komiya:20190715162344p:plain

1台しか増設しなかった場合において、二つのケースが考えられます。

・同一スペックでストレージ容量を増設した場合

・異なるスペックでストレージ容量を増設した場合

 

同一スペックでストレージ容量を増設した場合、Nutanixのクラスタ内で増設したノードの容量も含めてクラスタで管理している容量が大きくなる時に、クラスタ内でデータが再配置されます。この時にクラスタ全体にデータが均等化して配置するようにNutanixが動作します。つまり同一スペックであれば、特に問題なく動作することになりますので、何事もありません。

 

それでは、異なるスペックでストレージ容量を増設した場合はどうなるでしょうか?

例えば、はじめは1Uのラックサーバーで容量を少なく導入したものの、ストレージ容量が足りなくなり、2Uのノードを増設した場合はどうなるでしょうか?

実際に同一スペックで増設した時と同様に2Uノードを追加した場合にもNutanixが均等にデータを再配置を行いますが、異なるスペックの場合、水色の部分も含めて均等にデータを再配置してくれるのでしょうか?

 

5.異なる容量を追加した時のデータの分散について

f:id:t_komiya:20190715162555p:plainNutanix Bibleに異なるスペックを増設した場合の動作について、イメージのように書かれています。NutanixはCuratorにて一定の閾値をもって動作しています。その閾値を超えてデータの均等化がされていないことが判明した場合に、Curatorにて異なるスペックのノードとディスク使用率を見て容量のバランシングを行います。その場合にアクセス頻度が低いデータを他のノードに移動させようとします。これにより、ストレージ容量が大きいノードが増設された場合においても、均等化を図ろうとしてデータの再配置を行います。

異なる容量のノードを増設しても動作上何も問題はありません。

f:id:t_komiya:20190715162947p:plain

ストレージ専用のアプライアンスでも同様のことが言えます。ストレージ専用ノードの場合、ストレージ専用ノードにはCVM以外の仮想マシンは載せてはいけないことになっているため、基本的には他のノードのコールドデータ(アクセス頻度の少ないデータ)がストレージ専用ノードに保存されるようになります。

 

ここで、異なるスペックのノードを増設しても問題ないことはわかったが、容量の大きいノードが障害起きた場合はどうなるのか?について考えてみましょう。

容量のバランシングで容量の大きいノードに一番多くデータが保存されることもあります。その時に、容量の多いノードが障害あった場合に他のノードで容量を受けきれない場合もあります。もちろんこれはサイジング上のお話もあるかと思いますが、基本ルールとして覚えていたほうがよいのは、障害が起きた場合にはデータの受け皿として受け入れられるだけの容量を確保することが重要です。

6.同一スペックのノードを増設時にもう1台購入

f:id:t_komiya:20190715163627p:plain

増設時にもう1台(2台以上)の増設ノードがあれば、障害時も問題なく運用できます。もちろんこれは予算の限りであると思いますが、ストレージ専用アプライアンスを購入した場合にはこの話を理解しておかないと容量だけ足せばよいという意見にもなりかねないため、是非頭に入れておいた方がよいと思います。

 

こちらの内容を理解した上で、将来の増設プランにもうまく対応できると思います。

 

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

Nutanixで利用可能なCLI(Command Line Interface)を覚えてみよう!

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixで利用可能なCLI(Command Line Interface)についてご説明しようと思います。

 

普段Nutanixを運用する場合、Prismを利用して操作を行いますが、コマンドなどで自動化したい人などはどうしてもCLIが必要になります。実際にNutanixには複数CLIのインタフェースが用意されており、運用者の使い勝手で選ぶことも可能です。

CLIに対する使い方も含めてご説明したいと思います。

1.Nutanixで利用可能なCLIについて

f:id:t_komiya:20190714002426p:plain

主に3つのCLIが用意されています。

・nCLI(Nutanix CLI):Nutanixのクラスタ(AOS)に対してコマンドで操作できます。主にクラスタやコンテナの情報の参照・設定などを行うときに利用します。(利用する場合はJREのインストールが必須になります)

・aCLI(Acropolis CLI):AHVのハイパーバイザーに対してコマンドで操作できます。仮想マシンや仮想ネットワークおよびイメージやサービスに関する内容を設定・変更するときに利用します。

・PowerShell Cmdlets:Nutanixのクラスタに対してコマンドで操作できます。nCLIと同様の操作が可能です。(利用する場合は、Windows環境が必須になります)

 

また、CLIを利用する場合はCVMなどに直接ログインすることで利用することは可能ですが、root権限でオペレーションしてシステムをおかしくすることも考えられます。そのため、どうしても利用する場合は、リモートの端末に必要なツールをインストールして利用することをお薦めします。

aCLIについては、AHVにログインせずCVM経由でSSHでログインするで利用可能です。【192.168.5.1のアドレスでrootでログインすることで利用します】

コマンドラインでシステム停止もできますが、コマンドの打ち間違いで正常終了しないようなオペレーションしないためにも、通常はPrismでのオペレーションをお願いします。

2.Nutanix Command Line Interface (nCLI)について

f:id:t_komiya:20190714003809p:plain

Nutanixコマンドラインインターフェース(nCLI)を使用すると、次のいずれかのマシンからNutanixクラスターに対してシステム管理コマンドを実行できます。

  • ローカルマシン(推奨)
  • クラスタ内の任意のコントローラVM

ローカルマシンへのインストールを推奨しているのは、CVMに対してログインせずにIPアドレスなどの引数で操作ができます。これにより、クラスター全体にローカルマシンから操作できるようになります。

3.nCLIのインストール

f:id:t_komiya:20190714003921p:plain

1.ローカルマシンから利用するJava Runtime Environment(JRE)のバージョンが5.0以上であることを確認最新版はこちら(http://www.java.com/en/download/installed.jsp)からダウンロード可能です


2.nCLIをダウンロードします
・Nutanix Webコンソールに接続します
・コンソール上部のユーザーアイコンをクリックし、[Download nCLI]を選択
・ローカルマシンにインストールします


3.Windowsの%PATH%またはLinuxの$ PATH環境変数を設定します
・ncliディレクトリ(例:c:\ncli)
・JRE binディレクトリ(例:c:\ProgramFiles\Java\jrexxxx\bin)

4.ローカルマシンからnCLIセッションを開始

f:id:t_komiya:20190714004333p:plain

 

ローカルマシンへのnCLIのインストール手順に従って、ローカルシステムにnCLIをインストールします

1.ローカルマシンでコマンドプロンプトを開きます(Linuxの場合はbash、Windowsの場合はCMDなど)

2.コマンドプロンプトで、次のいずれかのコマンドを使用してnCLIを起動します

lncli -s management_ip_addr -u ' username ' -p ' user_password ‘ この場合、コンソールにパスワードが表示されます

lncli -s management_ip_addr -u ' ユーザー名 ' –p この場合、パスワードを指定するように求められます

3.management_ip_addrをクラスタ内のNutanixコントローラVMのIPアドレスに置き換えます

4.usernameユーザーの名前に置き換えます(指定されていない場合、デフォルトはadminです)

5.(オプション)user_passwordをユーザーのパスワードに置き換えます

 

 

コマンドフォーマット・埋め込みのヘルプ

f:id:t_komiya:20190714004503p:plain

f:id:t_komiya:20190714004602p:plain

コマンドフォーマットおよび埋め込みのヘルプについては、スライドの内容をご確認下さい。

Acropolis Command-Line Interface (aCLI)

f:id:t_komiya:20190714004702p:plain

Acropolisは、ホスト、ネットワーク、スナップショット、VMを管理するためのコマンドライン インターフェースを提供します

Acropolis CLIへのアクセス

Acropolis CLIにアクセスするには、SSHでクラスター内のController VMにログオンacliし、シェルプロンプトで入力

Acropolis CLIを終了してシェルに戻るには、<acropolis>プロンプトでexitと入力します

PowerShell Cmdlets

f:id:t_komiya:20190714004905p:plain

Nutanixはクラスターと対話するためのPowerShellのCmdletsを提供しています

CmdletsはNutanix クラスターからダウンロードされ、Windowsマシンにインストールされます。Cmdletsがインストールされたら、Nutanix CmdletsをクリックするとデスクトップのショートカットがロードされNutanix CmdletsがPowerShellウィンドウで起動します

PowerShell Cmdletsのインストール

利用する

PowerShellバージョン2以降および.NET Framework 4.0をワークステーションにインストールします

1.Nutanix Webコンソールにサインイン

2.Webコンソールの右上隅にあるユーザーアイコンをクリックして、 [Download Cmdlets Installer]を選択

3.インストーラのダウンロードが完了したら、インストーラをダブルクリックして プロンプトに従います。コマンドレットがインストールされ、デスクトップショート カットNutanix Cmdletsが作成されます。ショートカットをダブルクリックして、Nutanix CmdletsがロードされたPowerShellウィンドウを起動します。

PowerShell Cmdletsの使用方法

f:id:t_komiya:20190714005025p:plain

クラスタ接続について

コマンドを実行する前に、セッションを1つ以上のNutanixクラスタに接続する必要があります

> Connect-NutanixCluster -Server cluster_ip_address -UserName admin_username ` -Password admin_password

  • cluster_ip_addressをクラスターの仮想IPアドレスまたはコントローラーVMのIPアドレスに置き換えます
  • 置き換えadmin_usernameニュータニックスのユーザー名(通常でadmin)
  • admin_passwordをNutanixのユーザーパスワードに置き換えます

複数のConnect-NutanixClusterステートメントを使用して複数のクラスターに接続します。セッションが複数の クラスターに接続されている場合は、他のコマンドレットのServerパラメーターを使用してコマンドを実行するための クラスターを指定します

接続されているクラスターから切断するには、切断元のサーバーのIPアドレスを指定してDisconnect-NutanixClusterを実行します

 

接続クラスタ情報

セッションで接続しているクラスターの詳細を取得するには、Get-NutanixClusterコマンドレットを実行します 複数のクラスターに接続されている場合は、接続されているクラスターごとに同じ出力を取得するように実行できますGet-NutanixCluster -Server cvm_ip_addr

 

Cmdletsバージョン情報

実行しているコマンドレットのバージョン詳細を取得するには、Get-NutanixCmdletsInfoのCmdletsを実行します

 

Nutanixの環境を自動化したい人は利用方法に気をつけながら是非使ってみてください。

 

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