« 2018年10月 | メイン | 2018年12月 »

2018年11月

2018/11/30

.NEXT 2018 London モーニング キーノート速報

2日目は1時間のMorning General Session となります。

VP and GM of IoT and AIのSatyam Vaghani氏による登場で開始されました。

2日目のキーノートは前日に発表がされたEnterPrise Cloud Platformの中からEdge Cloud にフォーカスされている内容でした。

このキーノートはXi IoT , Kubernetesのみの説明となっており、Nutanix社はソフトウェアさらに真のマルチクラウドの為のPlatformを提供しているのだという事を実感する事になりました。

1

既存のDigital Transformation Crossoverに関する内容ですが実際に利用されているデータはEnterprise Cloudは2017年で8.6Billion ZBでしたが、IoTのデータは256Billion ZBと驚異的な勢いでデータが増えている事がうかがえます。

2

Xi IoTを実現するまで求められているものは

Edgeからアーカイブされたものをリアルタイムプロセッシングするという事が鍵となるようですが、このXi IoTで最もと難しかったものの3つでは次のようです

1,何万ものマイクロデーターセンターの管理

2,IoTのアプリケーション( AIや分析など)全く違うという事

3,シームレスに統合できるデータプレーンの作成

3_2

そして事例の紹介となりましたが、Compass GroupのChief Digital and Information OfficerであるOlivier Malvezin氏の登場となり、デモの動画の紹介となっています。

デモ動画では食事の際にお客様が好きな料理を取得しレジ台にトレーを置くとレジにあるカメラがトレーにある食事のスキャンを行い値段のお知らせと、そのまま支払いが出来るという面白いものでした。

仕組みは下の通りでカメラ+Xi Edgeの組み合わです。

4

その後デモに入っていくのですが、Compass Groupの成功を例えてカメラデバイス<->Xi Edge<->Xi Cloudが連携しており、Xi Cloudから一括で対象のアプリケーションの更新が行えるというものでした。

 こちらはXi IoTの画面になります。

5

アップテートしたいアプリケーションを定義した後に展開したいEdge を選ぶだけで一つの画面より選択した対象のエリアを簡単に更新する事が出来るようになるようです。

6

こちらが展開先です、青文字で書かれているEdge名はリージョンがあり、パリやフランクフルトがあります。クリックするだけで必要な店舗のEdgeを簡単に更新が行えていました。

7

この仕組みの構成は下の写真の通りでXi IoT Application ManagerよりFOOD ID で定義しているコンテナサービス、Edgeを管理できるというものです。

8

続いてのデモはデータパイプラインに関してとなりますが、こちらもGUIより設定する事で定義しているアプリケーションのデータがEdgeへ保存される仕組みを簡単に実現していました。

まずはこちらのXi IoTよりパイプラインを作成していくのですが、デモでは非常に解りやすいように作りこまれており、まずは下が示すようにソースを追加します。

9

こちらがパイプラインの定義です。

まずは[Input]ですが、ここではRegionを定義していきその後に[Transformation]でFunctionの定義です、例はVideo をJpegに変換 -> 食べ物の認識 -> Edgeへ保存というものですが、これが下の写真のように定義していれば簡単に選択するだけでIoTの運用が出来るようになるのです。

10

つまり下のようにEdgeアプリケーションの展開が非常に簡単になっているという事が伺えます。

11

まとめのスライドではIoTを実現するためにセンサーから来たものをXi Edgeと連携しさらにデータパイプラインとしては様々なクラウドと連携しており、全ては Xi IoTから行えるという事です。

実際にこれの実現にはセンサーデバイスからくるプロトコルをIP変換しXi Edgeへ送るという処理が必要になるはずですが、IoTの管理は全てNutanixのXi IoTを経由して行えるという事はつまり、すでに押し寄せているAI,IoTの膨大なデータ量の管理、処理に最適な製品となってくるのではないかと感じる内容でした。

12

VP Product Management のGreg Muscarella氏の登壇でContainer、Kubernetes関連の話になります。

まず比率ですが、Kubernetesの展開の比率はオンプレミスで52%ですが、Kubernetesなどのソフトウェア開発をホストしている団体「Cloud Native Computing Foundation」(CNCF)の資料の様です、興味があるのがMatureつまり熟成しており、本番環境で使えるという事になりますが、アプリケーションが5000以上のマシンを利用している人のKubernetesへの展開の割合だとMatureの方が多いので、これが今後オンプレミスでのKubernetesの導入をさらに加速していくとの事で非常に納得のいく資料でした。

13

KubernetesのCloud Native Stack ですが、必要なStackはNutanixが提供している事がわかります。

データベースはEra , マイクロサービスの管理ではEpoch, ストレージはすでに10年以上もの経験がありますし、Buckets , Files , Volumesがあります、さらにコンピュートではKarbon があり、1クリックでの展開、HAが構成できます

14

そしてここからデモの前段ですが、コードの変更なしにAWSのKubernetes環境をNutanixへ変更するという内容です。

15

ここからデモになりますが、AWSで稼働しているKubernetes環境をNutanixのオンプレミスに動作させるという内容です。

以下のサイトはAWS上のKubernetes環境になります。

16

モニタリングも移行前はAWSでDB,Webサービスなどのマップが確認できています。

17

ここから実際に移行するのですが、オペレーションで使用するyamlファイルは下のようにS3のアドレスがAWS->Nutanixのオンプレミスになっているだけです

18

その後にkuberctlコマンドで提供していくだけで完了となります。

kubectl config get-contextsではAWSで動作しているのがわかりますが、最後のコマンドラインのkubectl get svcではKubernetes環境がオンプレミスで稼働しているのが解りました。

19

移行後ですが、実際にWebへアクセスしてみるとAWSのアドレス体系からオンプレミスのIPでアクセスが出来ている事が確認できます。

20

EpochからみてもNutanix環境でマップはAWSと同じように管理が出来ている事がわかりますね。

21

このKubernetesのセッションではパブリッククラウド、オンプレミスの環境ですでに多くの

Kubernetes環境が展開、利用されているのでマルチクラウド環境の管理が必須になってくることは言うまでも無く求められてきます。

さらにパブリッククラウド -> オンプレミス環境へコード変更なしに移行できるのは非常に大きな利点を提供できるようになるのではないでしょうか

Kubernetes環境のKarbonは現在Tech Previewの状態ではありますが、HAの構成をしない環境でのご利用は頂けます。

その他のXi クラウドサービス製品は既にGAがされており、モーニングキーノートがこのXi IoTとKubernetesのみで完了している事からしてHCIと呼べるものではすでになくなっており、Enterprise Cloud PlatformとしてのNutanixというメッセージを明確に受け取る事が出来たモーニングセッションとなりました。

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/11/29

.NEXT 2018 London キーノート速報

本日より .NEXT EUROPEがロンドンで開催されております。

早速ですがGAされた機能や最新機能を中心にキーノートセッションを投稿しておきます。

  • キーノート開始

開始は元ドイツ代表の伝説のプレーヤとも呼ばれるミヒャエル・バラック選手が登場し、オープニングキーノートが始まりました。

1_2

次にChief Marketing officerであるBen Gibsonが紹介され多くの事例を紹介した後にIDCの発表で2019年まで世界の企業は主にクラウドベースのIT環境への完全なシフトが求められているという事でした。

同様にENEAでも多くの企業が同様の事を求めているとのことです。

下の写真からも、やはやりクラウドベースのIT移行というのはEUでも同様に求められているものという事がうかがえました。

2

その後にCo-Founder,CEO&ChairmanであるDheeraj Pandey氏の登場です!!

3

まずはSHATTERING MONOLITHSという事で一体となっているものを砕くつまり

ATOMIZATION 細分化についてです。

解りやすいようにPCの細分化、Enterpriseの細分化を説明していきエンタープライズの細分化となっていきます

下の写真の示す通りで通常のPCがこのようにDesktop ,ノートパソコン、タブレット端末やスマートホンとなっておりEnterprise Computingも同様に細分化した後にNutanixの例の説明となりました。

4

5

Nutanixのケースの細分化という事ではコンピュート、ストレージ、ネットワークを細分化してHCIにしたことをあげています。

6

SVP, Databases & Data Management であるChris Hallenbeck氏が登場し

SAP HANA / AIや多くのデータ解析がより良い製品を作るという事でIoTなどの普及に伴いSAP HANA といったハイパフォーマンス+シンプル管理が求められて来ている事がうかがえました。

 その後、まずGAされた製品 Eraの登場です

7

既にEraの存在は知っている方も多いと思いますが、データベースの展開、CDMが1クリックで簡単に行えるようになっている製品となり、正式にGAとなりました。

すでにEraに関してはご存知の方も多いと思いますので、GAと今後のロードマップ的なものとしてはLifecycle Management (パッチ、アップグレード)と共にDBベースのDR、さらにSAP HANAが大きなポイントになっています。

8

次にNutanixの製品カテゴリに関しての発表ですが、

次の用にカテゴリが分類されていますので、Nutanix Enterprise = Enterprise cloud OS とならないようにしましょう!

Nutanix Core : AOS , Prism , AHV

Nutanix Essentials : Calm , Prism Pro , Flow , Files

Nutanix Enterprise : Era , Volumes , Buckets , Karbon , Xi IoT , Xi Leap , Xi Epoch , Xi Frame , Xi Beam

9

その後にChief Product & Develop office であるSunil Potti氏による製品の発表が始まっていきます。

まず、HCIはHyperconverging Cloudsへと進化してきています。

進化の過程で当然稼働するPlatformも変わる必要があり、Enterprise Cloud Platformはもやは、アプライアンスではなくあらゆるクラウドを含めたものをNutanix Enterprise Cloud Platformと定義していましたので、HCIという括りではなくクラウドも含め真のマルチクラウドの為のPlatformと言えるのではないかと考えられますね。

10

11

そして次の3つの区分に対してGAまたは製品の発表です!

12

【HCI】

まずHCIでの一つ目の発表ですが、1-Click RunBooksが発表されました。

こちらは先日リリースされた5.10で対応とのことです。

これによりRecovery へ対するRPOなどさらに細かい設定が可能となり、さらに多くのお客様に求められる機能となってくると考えられます。

この辺りはすでに5.10とPrism Centralをお使いの方はお試しいただけると思いますので是非これを機会にお試し頂ければと思います。

13

次にアーキテクチャ部分の要素です

次世代のエンタープライズアプリケーションや、次世代のハードウェアは下の写真が示す通りでこれまでと異なってくる事は間違いありません。

早いハードウェアが出てくれば対応しなければいけないわけですね。

以前のAHV Tuboモードが思い浮かびますが。。

14

15

そこで求められるものは何か?そうです、新しい時代のアプリケーションとテクノロジーには新しい時代のAOSが必要という事です

16

そしてCoreアーキテクチャに変化が!                    

AESが登場しました。この辺は詳細が述べられていなかったのですが

今年にNutanix Tech Summitに参加した際に触れられていましたので内容的には

ランダムのIOの際にmetadetaとvDiskのOplogの関係上書き込みにパフォーマンスの波形が発生してしまうのですが、ここを改善するためにmetadetaまわりを改善しRPCを通常の書き込みより少なくすることによって主にRandomのパフォーマンスを改善させるという事でしたが、こちらは同じ内容なのか詳細が解り次第再度ご報告したいと考えています。

17

18

次に出てきたのはSAP HANAの本番環境のサポートです。

19

【Cloud Platform】

Cloud Platformでは全体的にFlow , Calm連携がメインの発表でした。

20

【Calm関連】

アプリケーションタイプでしたの図のように可視化が可能となり、さらにサービスレベルでもフィルタが今後できるようになってくるようです。

21

Flowへ対する定義も出来るようになっており、Visualizeに加えてOrchestrateが追加されています。

22

こちらはデモでありましたが、実際にPlayBookと呼ばれるもので定義する事によっておかしい動きをするものを自動的に遮断したりできるようになってきます。

 下の写真が実際のデモの内容ですが、定義したものに対してアラート、メール通知や遮断のアクションなどが取れるようになってくるようです。

Flow+自動化がこれで実現できるようになると言えるのではないでしょうか?

23

気になる機能名は【Prism X-RAY】です。

こちらも詳細が判明したらお伝えしたいと思います。

24

次にAFSから名前を変えたFilesですが、運用周りに便利な機能が入りそうです

Analysis , File Auditing機能のBuilt-inが入ってくるようで、こちらが出来るとNASとしての利用用途も格段に増えてくる可能性があるかもしれません

25_2

その他はBuckets , Karbon(kubernates環境)でしたが、いずれもGAではありませんでした。

Karbonに関しては別途Break outセッションを受けた内容ではプロダクション利用にHAが必須の為、この対応が終わればできるようなことでした、デモではすでにHAも完了しておりGAも来年に入ってきているので1クリックでKubernatesを展開、管理、アップデートさらにkubactlコマンドなども利用できるとのことで、GAはQ1 C19と発表がありましたので遠くないうちにGAとなると思います。

【Multi Cloud】

マルチクラウドではXiクラウドサービス関連が軒並みGAとなりました。

以下は全てGAされている製品になります。

26

Xi Leap , Xi IoTなどはXiクラウドサービスがまだ日本でGAとなっていないのですが、

Xi Leapは1クリックでのオンプレミス – Xi CloudとのDR移行が可能となるサービスです。

リカバリープランに関してもテスト、フェイルオーバー、フェイルバックなど選べるようになっていました。

また接続はVPN or Direct 接続がサポートされるとのことです。

こちらに関してはXiクラウドサービスの日本上陸がまだかかりそうなので引き続き情報を収集していきたいと思います。

そこでXiクラウドサービスが提供される次のリージョンは【ロンドン】でした・・が・Japanも含め

計画があるようです。

【Xi Test Drive】

こちらはGCE上に仮想化環境 AHV を提供できる他、AOSも稼働が出来るようになってくるようです。

27

【Frame】

1クリック DaaS(Desktop As a service)はこれまでAWS , Azureの対応でしたが新規にXiクラウドサービスへの対応が発表されました。

FrameからVDIの展開は非常に簡単に行う事が出来るようになっており、VDIを展開する際にどこのクラウドで展開するかを簡単にチェックするだけで可能のようです。

さらにVDIとは思えないほどの良いレスポンスのデモを見ることが出来きましたので、こちらも期待は高まってきています。

28

【最後に】

きましたーー One More Thing 

Nutanixの.NEXT ニューオリンズに行かれたからはおそらくxTract for VMsのAWS対応を聞かれたかもしれませんが、実際はxTract for VMsでの提供ではなく、Calm連携となりバックグラウンド処理としてxTract VMsが動作する製品になっています。

 

29

実際にデモの内容が、下にあるのがAWSで稼働している仮想マシンとなっており

写真右上にあるMigrateボタンによりマイグレーションできるようになります。

31

実際にMigrationがこちらで1クリックマイグレーションを実現し

マイグレーションの状態は次の写真のように、どうマイグレーションがされるかもきちんと表示されていました。

32

移行に関しては、xTract for VMsを利用した方であれば同じような感覚で移行が出来る印象です。

移行中もきちんと状況が確認出来る為に解りやすいです。

33

これだけでは終わらない!!のがEnterprise Cloud Platformなんです

Xi Beamとの連携をさせることでAWSとオンプレミスのAHVの状態を確認しどこで動かすのが最適なのかを教えてくれるようになります。

まさにこれがマルチクラウドなのではないかと思いました。

Beamから下のように現在のガバナンスを確認し、マイグレーションした方が良いものを教えてくれるのです

ここで[Migrate]を選択するとマイグレーションが出来るようになります。

34

Xi Beamにより連携で最適な環境を最適な場所に動かす事が出来るようになってくるのです。

こちらはAWSとオンプレミスのNutanix環境ですので、日本でも十分に利用できるのではないでしょうか?

35

移行に関してはxTractと同様にAWSからのDiscover -> 仮想マシンの作成 -> 同期という流れでしたが、ここの同期はCBTのテクノロジーを利用しているので従来のxTractと同様に一度実施したら最後のカットオーバーまでは定期的に同期、カットオーバー時に最終同期という事になるようです。

動作の動きからしてCalmで展開したマルチクラウド環境のApp =仮想マシンのガバナンス管理をBeamが行い、適正に仮想マシンを稼働するように1クリックマイグレーションでAWS - オンプレミスのマイグレーションを実現させているところからしても完全にマルチクラウド間での操作がNutanixではすでに実現または Achieve invisible >> Togetherを実現させるために必要なものと考えられるのではないかと実感したオープニングキーノートでした。

今回のキーノートではそソフトウェアシフトによりあらゆる選択のFreedomを!というように感じれる.NEXTのロンドンとなっています! 

現地より速報をお届けしました。

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/11/28

Nutanix Pulse: Nutanix Enterprise Cloudのビッグデータ分析

本記事の原文はNutanix社に務めているPrashant Batra氏によるものです。
原文を参照したい方は <こちら > をご覧ください。
情報は原文の投稿時のものですので、現時点では投稿時の情報と製品とで差異が生じている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はIDおよびパスワードの取得が必要です。)


B5a57939cc484876baa4752e0877fdbd_th

こちらの本文の前にPulseを有効にするとプロアクティブなサポートを受けられるという事をご存知の方は多いかもしれませんが、Pulseの利用では実際にそのほかにいろいろな用途で利用されているのです

例えば、製品開発これもPulseからのデータがベースとなっている機能もあり、圧縮関連についてはこのPulseデータのインスピレーションから来ているようです。

その他にもPortalサイトからケースを上げる際に記入していくと類似のKBが表示されたりしますがこれもPulseのデータをinsights.Nutanix.comでビックデータ分析がされカスタマーポータルで表示されることでNutanixの管理者はケースをオープンすることなく問題解決が出来るようになったりもします。

Pulse送信されるデータの識別子(VM名など)は匿名化されますので、ご利用可能な環境でしたら皆様是非この設定を有効にしていただくことで、問題の自己解決のみならず、私たちが求めているような機能が実装させるかもしれません。

また、このPulseは各ノードから送られますが、Prism Centralを利用するとPrism CentralがProxyしinsights.nutanix.comへ送信するため、ネットワークはPrism Centralのアウトバウンドのみを設定すれば設定可能です。

台数が増えて来る環境ではこのようにPrism Centralなどの展開と合わせてご利用を検討頂ければと思います。

(Prism Centralの展開、利用自体は無償です)


私たちは情報世代に生きていて、周りのすべてのものはますますスマートで、情報の変化に気づきながら、インテリジェントなサービスを私たちに提供する明確な目的で設計されています。

これらのインテリジェントなサービスの普及はもはや驚くものではなくなっており、標準化しています。
それは貴方が好きな友人と向かい合うソーシャルフィードや、あなたの生活のイデオロギーであったり、ここ最近にあなたが実際に知りたいと思うものをどこでも知ることが出来るようになっています。

ITの世界は難しくなく、全てのベンダーはデータの力を活用する義務があり、より知的に、シームレスにカスタマーエクスペリエンスを向上させていくのです。

Nutanixでは私たちは日々一つの目的/指名に向けて前進しています。
それはインフラストラクチャをインビジブルに!

このミッションは2つのパートとなります。

  1. シンプルを柱としたお客様目線でのデザインを基盤としたIT業界をリードする製品の構築
  2. ここ直近5年連続でNPSスコアを90以上提供するワールドクラスサポートの確立は
    IT業界では素晴らしい偉業であり、素晴らしいサポートと良く設計された製品の組み合わせは喜ばしいカスタマエクスペリエンスと勝利戦略へと変わります。

 

間違いなくお客様はNutanixの利用を増やしていき、シームレスでスケーラブル、リライアブルでいつもNutanixのEnterprise Cloudを向上するもっと多くのユースケースを探しているのですが、これはNutanixが今安心しているという事ではなく、反対にこれはNutanixのお客様に信頼を置いてもらい、良い製品の革新、素晴らしいサポートの為に常に努力する義務があるのです。


NutanixのPulseについて紹介しましょう!

Pulseとは何か?

NutanixのPulse機能は全てのお客様の導入しているNutanixクラスタからNutanix社のInsights Service上でパルスチェックを行うために設計されています。
一度お客様がClusterのPulseを有効にするとNutanixによるプロアクティブサポートを行うためにシステム診断情報を送ります。



391a31acad3a4e8986fd45ec033eb326

マジックはすべての診断データをNutanixに送るわけではありません。これが最初の一歩です
マジックはinsights.nutanix.comでデータが集められ、アクション可能なもになった際に起こります。
これはNutanixがビッグデータパイプラインを実行し、プロセス、変換、のデータ収集の為に設計され、全てのコンフィグデータ、メトリック、アラート、タスク、ログ、他のイベントを分析しインサイトを作成します。
これらのインサイトは良い製品と世界レベルのサポートの提供に役立っています


11a8178e50b54bf9b2d6fc1221f69e52


NutanixがこのPulse データを活用する幾つかのキーを紹介します:

  • Nutanix サポートチームがこのデータを活用しプロアクティブなNutanixソリューションにコンテキストアウェアネスなサポートを提供できるのです。
  • データからのアラート、インサイトによりお客様のIT管理者がNtuanixのカスタマーポータル内で自己解決数する為の実行可能な方法をお知らせする事が出来ます。
  • 致命的なアラートの為にサポートチームはプロアクティブにケースをオープンし、お客様のIT管理者が実際に問題を発見する前に問題可決を取り組みます。
  • Nutanixはまた製品分析、機能と効果の為にデータを利用し、得られたデータはその後にプロダクト、機能のロードマップ計画へ送られ製品開発が独立して行われないようにし実際に使われている機能をベースにします。

Pulseが有効にされるとNutanixクラスタは自動的にシステムのパフォーマンスに影響無く必要な診断データを取得します、Nutanixの健全性の確認の為のベーシックシステムレベルの情報を送信します。
この情報は次の情報が含まれていります。

  • System alerts
  • System Tasks
  • System Logs
  • System Configuration
  • Performance Metrics
  • Current Nutanix software version
  • Nutanix processes and Controller VM information
  • Hypervisor details such as type and version

上記のすべての情報はお客様のNutanixシステムの特定の情報であって、お客様のワークロード、アプリケーションの識別するものではありません。さらに、Nutanix insights platformへ情報を送る前にすべてのPII文字列の匿名化を含む個人識別情報がデフォルトで収集されないようにするために、必要な手順を実施しています。

どんなメリットを期待しているか?


Nutanixの利用している方はNutanix PlatformのPulseを有効にすることで更に良いサポートエクスペリエンスをお客様に提供するだけでなく、素晴らしいインサイトがお客様のNutanix Enterprise Cloud管理を良くしていきます。
幾つかの期待できるキーは次の通りです。

  • Nutanixのサポートチームを利用する度、サポートチームはインフラストラクチャの観点からお客様のNutanix環境へ明確なアドバイスを提供するためのデータを利用する事が出来るようになります。
    お客様のインフラの明確なアセスメントはNutanixサポートチームが問題にすぐに取り掛かり解決する事に役立つのです。
  • 致命的なエラーの為、Nutanixサポートチームはプロアクティブにケースをオープンし、お客様には問題の詳細と解決方法が届けられます。
    例えば、Disk一台の障害の場合、アラートはNutanixサポートチームが確認し、たとえお客様が問題を発見する前であっても、サポートチームは交換のプロセスを開始しお客様へ詳細を送ることが可能なのです。
  • お客様が必要とするものについてはNutanix Custmoer Portal内で、明確な推奨事項とどの様に問題に取り組んでいくかという事が提供されます。
    これらはお客様がサポートのケースオープンや誰にも連絡をしないで、致命的でないイベントに対して自己解決をする事が出来ることになるので、Nutanix管理者がITヒーローとなるのです!
  • お客様はNutanix Platformをどのように利用するかという正しい理解を基準に、Nutanixの新しい製品、機能、品質、パフォーマンスの向上を優れた敏捷性と関連性を備えた改善を期待する事が出来きます。

    例えば、データ削減のいくつかの機能はNutanix Pulseからの分析のインスピレーションを受けているのです。

私たちはこれがNutanixの本当のお客様目線での製品アプローチであると考えています。
殆どの製品ベンダーは最も大きなアカウントを持つ顧客と会議をし、製品に関するフィードバックを得ています。これはProduct Roadmapに強く影響しています。
これは顧客層のトップを最重点にした製品開発を行うので、他のお客様の多くを犠牲にしているのです。
Pulseによりすべてのお客様からの本当のデータを背景にNutanixは現在、このような偏見をせずにすべてのお客様にあった製品を作ることが出来るのです。

お客様は、迅速な問題解決、あらゆるケースの情報交換、およびより快適なカスタマーエクスペリエンスを期待できます。



Pulseはどうやって利用するのですか?


簡単です。すべてのクラスタの全てのノードが診断データをNutanix Insights Service へ送信する必要がある一方で全てのデーターはPrism Centralを通してプロキシされます。
これにより、展開をとてもシンプルにし、セキュリティチームはPCからの一つのアウトバウンドだけを許可する必要があります。

Pulseを有効にするために、次を実行してください:

1.Prism Central からギアアイコン -> Pulse

Dedfa7921c0f4b9ca0b42908377bddad

まだPrism Centralを展開していない、またはPrism Centralの配下にいない場合はPrism Elementから同じように
Pulse の設定を見つけることが出来ますが、簡単にPrism Centralを展開できるので
Prism Central経由での利用をお奨めします

2. ポップアップでPulseの画面が出るので単純にEnable をして保存します。

175c07acebe941a38826b528851544bd

2つ目のチェックボックスも有効にする事を強くお勧めします。
これは追加のサポート情報が含まれるためです。

デフォルトでは全てのエンティティ名とアドレスなどの全ての文字列はデータ取集時に匿名化されます。
これは良い事である一方、エンティティ名が曖昧になっている以上、NutanixのサポートチームがどのVM,何のIP、どのディスクが問題が起こっているのかを特定するのが少し難しくなります。
このチェックボックスの有効によりエンティティ名の確認がNutanixのサポートをよりスムーズにします。



3. 一度有効にした後、Pulse Connection Status ボックスで状態を確認する事が出来ます。

649d1bcb465141be800632d2c2c3b76e


NOTE: PEとPCはProxyをサポートしており、全てのpulse データをProxy アウトバウンドを通してルートするように設定する事が出来ます

NOTE: 全てのPulseトラフィックはアウトバウンドなので、クラスタへのインバウンドは不要です


NOTE: プロアクティブサポートとケース作成の為にもアラート E-メール設定を実施いただくことも推奨します。設定はPrism Web Console GuideのConfiguring Alert Emailsに紹介されています。

Recommended Software Versions


There are two key components that enable Pulse to function

  • NCC – Latest (at the time of publishing this blog, latest NCC version is v3.6.1.1)
  • PC > 5.8 (when using PC, you will need at least NCC v3.5)

Next Steps


Go ahead and enable Pulse. You can find more information on Pulse at:


You can always talk to the awesome Nutanix Support for more in-depth details as well.

©️ 2018 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and the other Nutanix products and features mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/11/21

予測可能でNutanix AHVで稼働するスケーラブル MS Exchange 2016パフォーマンス

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はPredictable & Scalable MS Exchange 2016 Performance on Nutanix with AHVをご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


私は最近 Nutanix AOS(5.8)を利用していくつかのテストを実施したので、いくつかのMS Exchange Jetstressのパフォーマンステストを試すことを
決めました。

つまり、私はどのようにExchangeのストレージパフォーマンスをうまくスケール出来るかチェックしたかったので、3つのテストを実施しました。
4スレッド、8スレッドで最後に12スレッドをJetstress With Exchange 2016 ESE データベースモジュールを利用して開始しました。

テストにあたり、キャシュからのパフォーマンスを意図的に向上しないようにするため、Nutanixのメモリーリードキャッシュを無効にし全てのリードは物理SSDから行われるようにしています。

そして、また圧縮、EC-X、重複排除も無効にしています、これらはまた意図的にパフォーマンスを向上するためです。

今回のハードウェアはNX-8150 でSSDが6本搭載、IntelのBroadwell CPUを搭載したものでした。
それがデーターサイズが下に示している合計の利用可能容量で1.7TBしかない理由です。

ここに示されているように望ましいワーキングセットサイズの為にCVM内のメーターデータキャシュが設定されている時はより大きなデーターベースでもパフォーマンスは同じです。

HypervisorはMS SVVP programme と同様 MS ESRP certified for MS Exchangeのもので完全に認定がされているAHVを使っています

こちらが4スレッドでの結果になります。

Jetstress2016_4threads

4スレッドで5580 IOPSはとても良いパフォーマンスで、少なくとも数百のメッセージが一日にある5,000でも効率的と言えるでしょう。


では次の質問は:データーベースのリードとログの書き込みのレイテンシはどうか?(これらは2つのJetstress Pass /Failの結果のパフォーマンスの重要なメトリックです)

Jetstress2016_4threads_latency

ここでは私たちはログ書き込みの4つの全てのでのディスクにまたがるものが1ms以下(0.99ms)そしてリードの平均は1.16msです。

次は8スレッドの結果です

Jetstress2016_8threads


8スレッドで10147 IOPSは素晴らしいパフォーマンスで、Nutanixが簡単にExchange MSR サーバー毎の最大アクティブユーザーの推奨の要求事項である数百のメールがある1万以上のメールボックスに対応するパフォーマンスが出たのです。

再度、レイテンシを見てみましょう。4つのドライブにまたがるログの書き込み平均は未だに1ms以下(0.99ms)であり、データーベースのリードレイテンシは1.29msです。
IOPSが倍になっている間、リードではたったの0.13ms、リードのレイテンシが上がり、書込みのレイテンシは4スレッドと同じレイテンシなのです

Jetstress2016_8threads_latency

最後にこちらが12スレッドの結果です

Jetstress2016_12threads

12スレッドで14351 IOPSとなり、IOPSをリニアに増やすことで、Nutanixプラットフォームがどんなにスケーラブルに優れているかを証明しています。

レイテンシを見てみると、ログの書き込みは1ms以下(0.98ms) , リードのデータベースは1.42ms となります。
リニアにIOPSのパフォーマンスを上げている一方でたったの0.14msの平均リードが高くなり、ほんの少しではあるものの書込みのレイテンシが低くなっています。

Jetstress2016_12threads_latency

概要:

Nutanix provides extremely high, predictable performance for even the most demanding MS Exchange environments.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/11/20

IBM Cloud Private 3.1 Multi Cloud Manager インストール手順

こんにちは。前回はICP3.1のインストールについてご案内させていただきました。
今回は、ICP上で動作するIBM Multicloud Manager(以下、MCM)という製品のインストール方法を書いていきます。


MCMってなんぞや?

IBM Multicloud Managerですがその名の通り、複数のクラウドを管理するマネージャーになります。
このクラウドの中にはICP(オンプレ製品ですが)はもちろん、IBM発表の情報では、IKS(IBM Cloud上のKubernetesサービス)やAWS、Azure等々の他ベンダーのクラウドにあるKubernetesサービスも管理できるようになるという製品です。

MCM上でほかのKubernetesクラスターの状況確認はもちろん、Helmからリモートでデプロイする機能も含まれているようです。
ただ、まだまだ情報が出そろってはいません。
このあたりの機能などの情報については情報が出そろったらまたご案内できればと思います!


環境

ICPのインストール方法で作成したICP環境を 2セット 用意します。
前回の環境情報はこんな感じです。
/////////////////////////////////////////////////////////////////////
2台のサーバーを使いICPをインストールします。

1台目:Master node (Master,Management,etcd,Proxy)
2台目:Worker node (Worker)
※インストール手順では、1台目を「Master」、2台目を「Worker」を表記します。

サーバーはどちらも同一スペックを用意しています。

OS RedHat Endterprise Linux 7.4
物理/仮想 仮想
CPU(Core) 8
Memory 24GB
Disk 300GB
NIC 1つ

FirewallとSELinuxについては無効にしています。
//////////////////////////////////////////////////////////////////////


ファイルの準備

下記のファイルを入手します。

  • IBM Multi-cloud Manager 3.1.0 Kubernetes Images for Linux (CNVV6EN )
    size:962MB

事前にダウンロードしたファイルを解凍して、Tokyo Master,Osaka Master上それぞれにコピーしておきます。該当のファイル名は mcm-3.1.0_x86.tgz になります。

今回、このファイルは ~/ 配下にコピーしています。


やること

今回はMCMのインストールともう一つのICPクラスターをMCM配下のクラスターとして登録します。

登場人物

  • ICPクラスター2セット

    • クラスター名: Tokyo
      • Master: Tokyo Master IP末尾 50
      • Worker: Tokyo Worker IP末尾 51
    • クラスター名: Osaka
      • Master: Osaka Master IP末尾 60
      • Worker: Osaka Worker IP末尾 61
  • Multi Cloud Manager
    MCMの管理コンポーネント。Helmからインストール。

    • Tokyo Masterにインストール
  • Klusterlet
    MCM用のAgent。Helmからインストール。

  • hub-cluster
    IBM Multicloud ManagerをインストールしたICP Master(今回は Tokyo Master)のこと。

  • cluster_CA_domain
    Clusterのドメイン名。デフォルトは mycluster.icp
    ※変更するのはICPのインストール時になります。


手順の概要

  1. Tokyo Masterに MCM をインストール
  2. Tokyo Masterに Klusterlet をインストール
  3. Osaka Masterに Klusterlet をインストール

MCMインストール

インストールはCLIベースでの作業と管理コンソールでの作業があります。
CLIベースの作業は各クラスターの Master で作業を実施します。
CLIではRootにログインして作業します。


Tokyo Master 作業(CLI)


Docker にログイン

docker login mycluster.icp:8500
  • User : admin
  • Password : admin

IBM Cloud Private CLIにログイン

cloudctl login -a https://<Tokyo Master IP Address>:8443 -n kube-system --skip-ssl-validation
# サンプル cloudctl login -a https://xxx.xxx.xxx.50:8443 -n kube-system --skip-ssl-validation Username> admin #←ユーザー名:admin を入力 Password>  #←パスワード:admin を入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1  #← 1 を入力 Targeted account mycluster Account (id-mycluster-account) Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

Helmチャートにファイルをロード

cd ~/ cloudctl catalog load-ppa-archive -a mcm-3.1.0_x86.tgz --registry mycluster.icp:8500

Tokyo Master 作業(GUI)


コンテナイメージの確認

管理コンソール上でMCMに必要なイメージがロードされていることを確認します。

  • 管理コンソールにログイン
  • 左上のメニューを開き、「イメージ」に移動
  • 検索窓で「kube-system」と入力し、イメージを確認

20181116_11h00_38



Helmカタログの確認

管理コンソールでHelmにカタログが登録されていることを確認します。

  • 管理コンソールにログイン
  • 右上の「カタログ」に移動
  • 検索窓で「mcm」と入力し、カタログを確認

20181116_11h02_55



カタログからデプロイ

管理コンソールからカタログに移動し、 ibm-mcm-controller を選択します。

20181116_11h02_55a


右下の 構成 をクリックします。

20181116_11h16_06_2



デプロイに必要なパラメータを入力します。

設定名 設定値
Helmリリース名 任意の名前を入力
ターゲット名前空間 kube-system
Multi-cloud Manager Namespace 専用の名前空間

名前空間はIBM Multicloud Manager用に専用の名前空間が必要になります。 ここでは mcm-tokyo と指定します。

20181116_11h16_47_2


インストール をクリックしインストールを実行します。 実行後、Helmリリースの状況を確認します。

20181116_11h21_27


よくあるミスとしては、ターゲット名前空間を間違えてしまうということがあります。
その場合 デプロイメント のなかの multicloudmanager-ibm-mcm-controller-controller の使用可能部分が 0 となっていることがあります。この場合は、Helmを使って、一度削除してが必要になります。(削除できないことがありますのでなるべく間違えないように気を付けてください。)

数分待ったあとに一度管理コンソールからログアウトし、再度ログインします。
正常動作している場合は、管理コンソールのメニューに マルチクラスター という項目が増えます。

20181116_11h25_34



Tokyo Master 作業(CLI)


Hub Clusterのへのログイン

cloudctl login -a https://<hub_cluster_host_name>:8443 --skip-ssl-validation

<hub_cluster_host_name>はTokyo Masterのホスト名もしくはIPアドレスになります。

cloudctl login -a https://xxx.xxx.xxx.50:8443 --skip-ssl-validation Username> admin # adminと入力 Password> # adminと入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 # 1と入力 Targeted account mycluster Account (id-mycluster-account) Select a namespace: 1. cert-manager 2. default 3. ibmcom 4. istio-system 5. kube-public 6. kube-system 7. mcm-tokyo 8. platform 9. services Enter a number> 6 # 6と入力 Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

MCM用のNameSpaceの作成

kubectl create namespace <mcm_namespace>

カタログからMCMをデプロイした際のNameSpaceと同一にします。
ここでは mcm-tokyoと指定しました。


Hub ClusterからのリモートHelmインストール機能を有効にする

export CLUSTER_IP=<hub_cluster_host_name> kubectl patch daemonset catalog-ui --patch '{"spec": {"template":{"spec":{"containers":[{"name":"catalog-ui","env":[{"name":"hcmCapabilityEnabled","value":"true"},{"name":"hcmRedirectUrl","value":"https://'${CLUSTER_IP}':8443/hcmconsole/remoteinstall"}]}]}}}}' -n kube-system

※<hub_cluster_host_name>部分をMCMをいれたICP Masterのホスト名にします。名前解決ができない場合はIPアドレスを指定します。


Klusterletのインストール(Tokyo Master)

次にMCMと通信を行うKlusterletをインストール(デプロイ)します。クラスターTokyoに対しても作業が必要になります。

Tokyo Master 作業(GUI)


事前準備

デプロイに必要なパラメータを確認します。
Tokyo Masterの管理コンソールにログインし、右上の人型アイコンをクリックし、クライアントの構成 をクリックします。

20181116_11h31_45


「クライアントの構成」のポップアップが表示されます。

20181116_11h33_54a


パラメータが表示されている部分を2列分をコピーします。

kubectl config set-cluster cluster.local --server=https://xxx.xxx.xxx.50:8001 --insecure-skip-tls-verify=true
kubectl config set-credentials admin --token=eyJ0(以下、略)

このあとに使用する部分は、

  • --server= https://xxx.xxx.xxx.50:8001
  • --token= eyJ0(以下、略)
    略部分はもちろん略さず利用します。

Tokyo Master 作業(CLI)


Tokyoクラスターにログイン

cloudctl login -a https://mycluster.icp:8443 --skip-ssl-validation Username> admin # adminと入力 Password> # adminと入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 # 1と入力 Targeted account mycluster Account (id-mycluster-account) Select a namespace: 1. cert-manager 2. default 3. ibmcom 4. istio-system 5. kube-public 6. kube-system 7. mcm-tokyo 8. platform 9. services Enter a number> 6 # 6と入力 Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

※ICPクラスター名をインストール時に変更している場合は適宜クラスター名を変更します。


Secret の作成

kubectl create secret tls <klusterlet_tiller_secret> --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

<klusterlet_tiller_secret> に任意の名称を入力します。ここでは、klusterlet-tiller-secret として入力します。

kubectl create secret tls klusterlet-tiller-secret --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

Secretの確認

Secretが正常に作成されているか確認します。

kubectl get secret | grep klusterlet-tiller-secret

Klusterlet用のNameSpaceの作成

kubectl create namespace <mcm_namespace>

ここでは mcm-tokyo-klusterletと指定しました。


Tokyo Master 作業(GUI)

デプロイ

管理コンソールにログインし右上のカタログをクリックします。
検索画面で mcm と入力し、表示された ibm-mcm-klusterlet を選択します。

20181116_11h02_55b


遷移した画面で構成 をクリックします。
それぞれパラメータを指定していきます。

設定名 設定値
Helmリリース名 任意の名前を入力
ターゲット名前空間 kube-system
Cluster Name 任意のクラスター名
Cluster Namespace Klusterlet専用の名前空間
Klusterlet Tiller Secret Name 事前に作成してSecret名
Hub Cluster Kubernetes API Server 事前に確認したAPIサーバー名
Hub Cluster Kubernetes API server token 事前に確認したToken

今回の環境では下記のようになります(しました)。

設定名 設定値
Helmリリース名 tokyo-cluster-klusterlet
ターゲット名前空間 kube-system
Cluster Name tokyo-cluster
Cluster Namespace mcm-tokyo-klusterlet
Klusterlet Tiller Secret Name klusterlet-tiller-secret
Hub Cluster Kubernetes API Server https://xxx.xxx.xxx.50:8001
Hub Cluster Kubernetes API server token eyJ0(以下、略)

20181116_17h11_05b


ローカルインストール を選択し、デプロイを開始します。


デプロイの確認

デプロイ状況を確認します。
管理コンソールのメニューから[ワークロード]-[Helmリリース]を開きます。

20181116_17h15_59


検索画面にtokyo と入力し、tokyo-cluster-klusterletを選択します。

20181116_17h16_55


使用可能の値が必要数と異なっていたり、エラー等が発生していないことを確認します。

20181116_17h17_34


管理コンソールのメニューから[マルチクラスター]-[クラスター]を開きます。

20181116_17h18_06


tokyo-cluster が表示され、Statusが正常なことを確認します。

20181116_17h18_58



Klusterletのインストール(Osaka Master)

Osaka MasterにKlusterletをインストール(デプロイ)します。

Osaka Master 作業(CUI)

Docker にログイン

docker login mycluster.icp:8500
  • User : admin
  • Password : admin

IBM Cloud Private CLIにログイン

cloudctl login -a https://<Osaka Master IP Address>:8443 -n kube-system --skip-ssl-validation
# サンプル cloudctl login -a https://xxx.xxx.xxx.60:8443 -n kube-system --skip-ssl-validation Username> admin Password> Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 Targeted account mycluster Account (id-mycluster-account) Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

Helmチャートにファイルをロード

cd ~/ cloudctl catalog load-ppa-archive -a mcm-3.1.0_x86.tgz --registry mycluster.icp:8500

Osakaクラスターにログイン

cloudctl login -a https://mycluster.icp:8443 --skip-ssl-validation Username> admin # adminと入力 Password> # adminと入力 Authenticating... OK Select an account: 1. mycluster Account (id-mycluster-account) Enter a number> 1 # 1と入力 Targeted account mycluster Account (id-mycluster-account) Select a namespace: 1. cert-manager 2. default 3. ibmcom 4. istio-system 5. kube-public 6. kube-system 7. mcm-tokyo 8. platform 9. services Enter a number> 6 # 6と入力 Targeted namespace kube-system Configuring kubectl ... Property "clusters.mycluster" unset. Property "users.mycluster-user" unset. Property "contexts.mycluster-context" unset. Cluster "mycluster" set. User "mycluster-user" set. Context "mycluster-context" created. Switched to context "mycluster-context". OK Configuring helm: /root/.helm OK

※ICPクラスター名をインストール時に変更している場合は適宜クラスター名を変更します。


Secret の作成

kubectl create secret tls <klusterlet_tiller_secret> --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

<klusterlet_tiller_secret> に任意の名称を入力します。ここでは、klusterlet-tiller-secret として入力します。
※Tokyo Clusterと同じで問題ありません。

kubectl create secret tls klusterlet-tiller-secret --cert ~/.helm/cert.pem --key ~/.helm/key.pem -n kube-system

Secretの確認

Secretが正常に作成されているか確認します。

kubectl get secret | grep klusterlet-tiller-secret

Klusterlet用のNameSpaceの作成

kubectl create namespace <mcm_namespace>

ここでは mcm-osaka-klusterletと指定しました。



Tokyo Master 作業(GUI)

事前準備

Tokyo MasterにKlusterletをデプロイした直後であれば確認は必要ありません。しかし、時間をあけてデプロイする場合は、Tokenの値が更新されていることがありますので必ずご確認ください。

デプロイに必要なパラメータを確認します。
Tokyo Masterの管理コンソールにログインし、右上の人型アイコンをクリックし、クライアントの構成 をクリックします。

20181116_11h31_45_2


「クライアントの構成」のポップアップが表示されます。 パラメータが表示されている部分を2列分をコピーします。

kubectl config set-cluster cluster.local --server=https://xxx.xxx.xxx.50:8001 --insecure-skip-tls-verify=true
kubectl config set-credentials admin --token=eyJ0(以下、略)

このあとに使用する部分は、

  • --server= https://xxx.xxx.xxx.50:8001
  • --token= eyJ0(以下、略)
    略部分はもちろん略さず利用します。

Osaka Master 作業(GUI)


デプロイ

管理コンソールにログインし右上のカタログをクリックします。
検索画面で mcm と入力し、表示された ibm-mcm-klusterlet を選択します。

20181116_17h29_36


遷移した画面で構成 をクリックします。
それぞれパラメータを指定していきます。

設定名 設定値
Helmリリース名 任意の名前を入力
ターゲット名前空間 kube-system
Cluster Name 任意のクラスター名
Cluster Namespace Klusterlet専用の名前空間
Klusterlet Tiller Secret Name 事前に作成してSecret名
Hub Cluster Kubernetes API Server 事前に確認したAPIサーバー名
Hub Cluster Kubernetes API server token 事前に確認したToken

今回の環境では下記のようになります(しました)。

設定名 設定値
Helmリリース名 osaka-cluster-klusterlet
ターゲット名前空間 kube-system
Cluster Name osaka-cluster
Cluster Namespace mcm-osaka-klusterlet
Klusterlet Tiller Secret Name klusterlet-tiller-secret
Hub Cluster Kubernetes API Server https://xxx.xxx.xxx.50:8001
Hub Cluster Kubernetes API server token eyJ0(以下、略)

20181116_17h34_08


また、今回はClusterの場所の表示を変えるためにすべてのパラメーターを下記のように設定します。
※記載のないパラメーターは変更していません。

設定名 設定値
Cluster Region AP
Cluster Datacenter Osaka
Cluster Owner it

20181116_17h35_20


ローカルインストール を選択し、デプロイを開始します。


Tokyo Master 作業(GUI)


デプロイの確認

デプロイ状況を確認します。
管理コンソールのメニューから[ワークロード]-[Helmリリース]を開きます。

20181116_17h43_12


検索画面にosaka と入力し、osaka-cluster-klusterletを選択します。

20181116_17h43_40


使用可能の値が必要数と異なっていたり、エラー等が発生していないことを確認します。

20181116_17h45_19



Tokyo Master 作業(GUI)


デプロイの確認

管理コンソールのメニューから[マルチクラスター]-[クラスター]を開きます。

20181116_17h46_05


osaka-cluster が表示され、Statusが正常なことを確認します。


その他


NameSpaceの確認

作成したNameSpaceはコマンドでも管理コンソールでも確認できます。
コマンドの場合は

kubectl get namespace

管理コンソールの場合は、メニューの[管理]-[名前空間]から確認ができます。


Hub Cluster上のNameSpace(名前空間)

Hub Cluster上には管理するクラスターでKlusterletデプロイ時に指定したNameSpaceが作成されます。

20181116_17h47_08




MCMの情報ソース

現在は下記のURLにMCMの構築手順や管理手順が記載されていますので、不明点がありましたらご参照ください。
IBM Multi-cloud Manager
※日本語は用意されていませんので必ず英語でご確認ください。
※メニューは「Table of Contents」をクリックすると開きます。

今回は以上になります!複数のKubernetes Serviceを利用されている皆様には良い機能かと思いますので是非是非使ってみてください。
評価等のご希望がありましたら、こちらの「お問い合わせ・ご相談はこちら」からブログを見て!とご連絡を頂ければと思います。
すずきけ

2018/11/14

スゥィート シンフォニー: マルチクラウドへのNutanix AHVとMellanox DCI

本記事の原文はMellanox社に務めている友人によるものです。
原文を参照したい方は <こちら > をご覧ください。
情報は原文の投稿時のものですので、現時点では投稿時の情報と製品とで差異が生じている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はIDおよびパスワードの取得が必要です。)


431b347011474674aca098f26ad77e2e_th

自動化されたネットワーク仮想化はマルチクラウド環境でのビジネス継続に必要なものになっています。VXLAN-EVPNベースのオープンスタンダードは効率的でありながらマルチクラウドの為のデーターセンターの拡張(DCI)となります。

統合されたネットワーク管理はマルチクラウドを展開する鍵となります。
NutanixとMellanoxはより高いアプリケーションの稼働時間、ビジネス継続を提供しながら
シームレスなマルチクラウドネットワークソリューションの統合を行います。

エンタープライズクラウドネットワーク管理をシンプルにそして効率的にする一方で
ここらスイート シンフォニーの始まりです。

最初の動向:クラウド、ハイブリッドクラウドとNutanix Enterprise Cloud

クラウドコンピューティングはここ最近にかなりの勢いで採用されてきています。
クラウドは新しいビジネスを素早く拡張、ビジネスの効率性の向上をするプラットフォームとして、インフラ基盤、SaaSを仮想化環境として提供しています。


独自のオンプレミスクラウドの構築やAmazon Web Services(AWS),Microsoft Azureを利用する一方
多くのエンタープライのお客様はクラウド制御、プライベートセキュリティ、拡張性とパブリッククラウドからの俊敏性からくるを最大限に活かせるハイブリッドクラウド戦略を始めています。

このアプローチによりマルチクラウドにわたる業務の合理化をするので、エンタープライズは統合されたクラウドインフラストラクチャーを頼るのです。

Be48d5ff098e4f5d9b5093b126358513

エンタープライズクラウドソリューションのリーダーとして、Nutanixは、オンプレミスのプライベートクラウトからリモートオフィス・ブランチオフィス(ROBO)、そしてパブリッククラウド、リモートDRサイトのITファブリック全体にわたるハイブリッドクラウドのエクスペリエンスを提供しています。


エンタープライズクラウドOSとAHV ハイパーコンバージドインフラストラクチャの構築で
Nutanixのソリューションは俊敏さとパブリッククラウドのセキュリティ、コントロール、予測可能な経費、プライベートクラウドで必要なパフォーマンスをOne-Clickというシンプルな形に統合します。


クラウドで稼働しているアプリケーションに注目してみると、Nutanix ハイブリッドクラウドソリューション(AOS5.6以降)では
VMのマイクロセグメンテーションをFlowを利用する事でアプリケーションのセキュリティを向上します。

Flowではポリシー強化、ネットワークの拡張とセキュリティ機能と3rd パーティソフトウェアの組み込みによる自動化の為の
ネットワークの可視化を提供しており、結果的にワンクリックによるDR、ミッションクリティカルのビジネス継続をするお客様ベースの管理性が複雑なクラウド管理を簡単にするのです。

第二の動向 : ネットワークの仮想化とデータセンター相互接続

クラウドがネットワークの可視化し、複数のクラウドはデーターセンター相互接続(DCI)によって接続されます。
別々のテナントのトラフィックは仮想化ネットワークセグメントに入り、データーセンター間のアプリケーションの移動を
サポートし、モビリティ、スケーラビリティ、アプリケーションをマルチテナントにサービスるための為のセキュリティを
提供する事でクラウドインフラストラクチャーはアプリケーション指向となっています。

ネットワークセグメンテーションはレイヤー2のネットワークが仮想ローカルエリア(VLAN)化したデータセンターから
始まっています。
VLANはホストまたは、仮想マシンの接続、セグメント内での移動、セキュリティの為に他のVLANからの孤立を提供しましたが、
VLANには拡張の制限があります。 それは4000セグメントで一つのデータセンターを越えて拡張する事が出来なかったのです。


L3のネットワークと通してデーターセンターの間でVLANを拡張する為に、L3アンダーレイの上にL2をオーバーレイするVXLAN(Virtual eXtensible Local Area Network)技術が開発されています。
L3越しのトンネリングにより、VXLANはホスト、仮想マシンを配置し同じVLANに所属しているかのようにコミュニケーションが出来るようになります。
次の図はVXLANトポロジーの簡単なものです。
ホストAとホストBは2つのデーターセンターのリーフスイッチに接続されています。
2つのリーフスイッチはまたVXLANトンネルのエンドポイント(別称VTEP)としてサービスしています。

8195bdb81741405985be4aad6380bb25

VXLAトンネルVNI1000を通してこれらの2つのホストはたとえそれが2つの別々のデータセンターにあったとしても同じVLAN100で通信できます。
24ビットの識別番号によりクラウドスケールの為に合計で1600万ものVXLANセグメントがサポートされるのです。
L3アンダーレイを通るデータトラフィックとして、ネットワークはより高い拡張性と柔軟性(BGP)、信頼性(マルチパス)と完全利用(ECMP)が再びクラウドネットワークの要求事項となります。


VXLANはVXLANセグメント内でVTEP DiscoveryとMac アドレス学習とVTEP Discoveryの為にFlood-and-Learnメカニズムを利用しています。例えば、L3マルチキャストと通してBUMトラフィックの転送(ARP 要求) , フラッディングを避けるために、IT管理者はVXLANをコントロールプレーンと一緒に展開しますが、独自のVXLANコントローラーを利用する際にユーザーはシングルコントローラーのボトルネックや、高価なソフトウェアライセンス、ベンダーロックインという新たな問題に取り組み必要が出てきます。
今日、BGP-EVPNベースのコントロールプレーンを利用する事で、より多くのVXLANはコントローラーレスが出来るようになっています。


主にL3プロトコルはとても広大なスケールのネットワークをサポートし、そしてEVPN拡張の統合、BGP分散ネットワークのL2 MACとIPの到達情報、結果として自動的にVTEP Discovery、効率的なアドレス学習と最適化のルーティング/スイッチングが行われます。
分散されたAnycast ゲートウェイはまたシングルコントローラのボトルネックを排除します。もっとも大事な事は BGP-EVPNコントロールプレーンが基準となりクラウドスケールと提供するという事です。

1b993bbecf6b4249b88caf574dc6d496

VXLAN-EVPNベースのDCIの利用できるソリューションとしてMellanox Spectrum スイッチで構築されたMellanox DCがあり
パフォーマンス、エンタープライズクラスの信頼性とクラウドスケールで際立っています。


SptectrumスイッチでのVTEPサポートにより、Mellanox DCIはハードウェアVXLANカプセル、脱カプセル化、対称、非対称のVXLANの100Gb/sでのルーティングを提供します。
他のソリューションと比べてもサーバー6大分と同等の750までのVTEPおよび、10万のVXLANトンネルとサポートし、Mellanox DCIは制限のないVXLANスケールを実現をするのです。


Mellanox DCIは共通のVXLANコントローラーとしても使われます。

3つめの動向: 統合されたネットワークオーケストレーション

BGP-EVPN DCIはマルチクラウドをまたがる物理ネットワークインフラストラクチャの基盤からくるネットワークコントロールプレーンを
抽象化するので、私たちは ネットワーク仮想化によるL2-L3の統合とクラウドソリューションのセキュリティ管理プレーンによるマルチクラウドの操作を簡素化しています。


NutanixとMellanoxは実際にPrism Centralを利用してアプリケーションの展開、Flowによるセキュリティの自動化、サービスチェインによるinsertion,Chainingが出来るようになりました。
Mellanox ネットワークオケ―ストレーターとしてはNEO™️とPrism Centralがあります。


Mellanox NEOはネットワークのオーケストレーション、管理の為の素晴らしいソリューションです。
NEOはネットワークのコンフィグとリアルタイムのステータスを見れるようにし、データーセンターのネットワークの構成、監視、エンドツーエンドのEthernet のトラブルシュートを数クリックで行えるようにします。

RESTful APIベースであり、NEOはでのネットワークデザインのシンプル化、一つのクラウドの中のローカルネットワーク、マルチクラウド環境での操作性、トラブルシューティングの提供をする3rdパーティの管理ソフトウェアとシームレスに統合します。


Webhook APIsを通してNutanixとMellanoxはNEOとPrismを統合しました。この統合は自動化されたVLANマッピングとDiscovery、DCIでのVLAN/VXLANマッピングを可能とします。そして、ネットワークプロビジョニングをVM GRUDイベント(作成、移動、削除)に対して行います。
さらにVMレベルのネットワーク可視性があり、NEOはNutanix AHVのお客様が可視化とVMがどこで動いているのを知ることが出来きますし、仮想化と特定のアプリケーションが必要とするネットワークの管理と監視を行えるようになります。


例えば、アプリケーションがリモートサイト(DRなど)へフェイルオーバーが発生した際、NEOはPrism CentralからのAPIトリガを受け取ります。
それを基準ににNEOはリモートサイトに関連付けされているアプリケーションのバックアップとリカバリの為にDCIを構成します。
オーケストレーションは主に先の内容で説明しているEVPN DCIベースで、VXLANがプライマリーの場所からバックアップの場所へVLANをのまま伸ばしていきます。
Anycast gatewayはEPVN機能のシームレスなワークロードの移行を補助し、基本的にお客様の視点でネットワークを抽象化します。
お客様はこの全体のプロセスの間に如何なる中断もなくアプリケーションへアクセス継続は可能です。

1342af073ebc4137acc08aacaed2fc47


Mellanox NEOは現在 NutanixのPrism Central + Calmの構成をして頂ければダウンロードと展開がワンクリックで実施できます。

最後に:マルチクラウドでのビジネス継続性を確かなものへ

マルチクラウド環境でのビジネス継続は必須条件です。アプリケーションが拡張や、DRの為に移動するので、ネットワークは
ビジネス継続で求められる課題の一つです。
NutanixとMellanoxのソリューションを採用頂ければ、NutanixとMellanoxの間で自動的にライフサイクル管理の一部としてネットワークのプロビジョニングを行い、ワークロードはDRサイトに移動してもIPを保持する事で一部また、完全なフェイルオーバーの間のビジネス継続を実現します。
これらの機能はネットワークを透過的にプライマリー、セカンダリーサイトに伸ばすことが出来るVXLAN/EPVNオーバーレイを利用して行われます。

VXLAN-EVPNはマルチクラウドをまたがるDCIを簡素化するオープンスタンダードな技術です。
EVPNベースのDCIはLayer2をデーターセンター間で拡張し、仮想マシンという形でのアプリケーションは簡単に同じIPとゲートウェイを持たまま移動する事が可能となり、これまでのDNSエントリーを手動で再構成する手間がなくなります。
アプリケーションのフェイルオーバー、DRがあると、EVPNベースのコントロールプレーンはVMの場所を自動的に更新しクライアントはVMが移動したことを知らなくてもアクセスは継続されます。

この素晴らしいオーケストレーションはMellanox ネットワークオーケストレーター NEOとNutanixのPrism Centralに統合されています。
透過的、ビジネス継続を確実にするためにNEOが提供する機能は次の通りです:

・VMレベルでのネットワークの可視化
・VM操作の為のVLAN/VXLANのプロビジョニング
・ワンクリックでのmLAG , RoCE構成
・監視の為のリアルタイムとトラフィック/パフォーマンスネットワークデータ履歴
・規模に応じたソフトウェアのアップグレードの変更
・Nutanix CALMからのNEOのワンクリック展開

もっと興味がある方はSweet Symphony for Multi-Cloud NetworkingのWebinerにご参加ください


Follow us on Twitter: @MellanoxTech, @nutanix. Also visit us for the solution demo at .NEXT London and upcoming Mellanox/Nutanix events in your area.

Related resources:


©️ 2018 Nutanix, Inc. All rights reserved. Nutanix, the Enterprise Cloud Platform, the Nutanix logo and the other Nutanix products, features, and/or programs mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand and product names mentioned herein are for identification purposes only and are the property of their respective holder(s), and Nutanix may not be associated with, or sponsored or endorsed by such holder(s). This document is provided for informational purposes only and is presented ‘as is’ with no warranties of any kind, whether implied, statutory or otherwise.

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/11/07

Veeam Availability プラットフォーム: ハイパー アベイラビリティがHCIのバックアップへ

本記事の原文はVeeam社のSenior Writerである Julie Tepe氏によるものです。
原文を参照したい方は <こちら > をご覧ください。
情報は原文の投稿時のものですので、現時点では投稿時の情報と製品とで差異が生じている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はIDおよびパスワードの取得が必要です。)


2967ffac12be4b28ae2b3405111bad51_th

多くの方がご存じで、認識していきているように従来のITインフラ基盤は時代遅れになっています。

ハイパーコンバージドインフラストラクチャが私たちが環境について考えている事を変えています。

そして、エンタープライズ事業者の方は次の動向を計画しています。

お客様はリスクとコスト(これは現在のレガシーなシステムで構成されているものを仮想化によるすばらしい機敏性を手に入れる事)を最小化したいと考えているのです。

これらの新しい優先順位により、IT部門の方はギアをシフトし日々負荷が高く稼働しているワークロードを予算内に収めるソリューションを探すことがプレッシャーとなっています。同感ですか?良いことにNutanixはお客様が求めているスケールを簡単に実現できるものなのです。

Nutanix のAHVはレガシーのソリューションからクラウドへ再注目しているお客様へ仮想化機能を提供、主導しマルチクラウド環境はビジネスのストレージサイロを排除し管理を分離することにより、ストレージスペース、ビジネス計画開発に必要なスタッフのリソースを節約する事が出来ます。

また、AHVではスナップショットを通したデータ保護と遠隔レプリケーションの機能がありますが、エンタープライズの高いスケーラビリティーがあっても、膨大なデーターリスクとIT部門の方が考慮しなければいけないオンラインでのダウタイムの可能性があります。

NutanixのAcropolisインフラストラクチャーはエンタープライズクラスで、エージェントが不要なデータ保護の為の冗長性が必要なのです。


NutanixはVeeam社とこの冗長性このギャップ(ここのギャップとはお客様が求めている事とITが提供できるもの)を埋めるために提携しました。

Hyper-Available HCIを包括したソリューションでお客様を安心させるものとなります。Nutanix エンタープライズのお客様は現在、IT管理者の方を夜中に起こす "データ保護" という頭痛から解放されています。

Veeam Availablity for Nutanix AHVはVeeamのPlatformの一部でNutanixユーザーの為に特別に設計されました。

これは簡単にWebベースのUIでの利用やPrismと同じような感覚で操作できるようにしているためです。

Veeam Availability for Nutanix AHVは実際にNutanixが作成するSnapshotと連携します。

2つのオプションによりお客様はNutanixAHVのSnapshotによる早いバックアップ、仮想マシンのバックアップや個別ファイル、アプリケーションアイテムの復旧といった事が出来るようになります。

Veeam Availability for Nutanix AHVは簡単操作で、慣れているデザインであるため安心して利用いただけるはずです。

アプリケーション第一の考えはこのソリューション開発における大部分を占めており、私たちが求めているエンタープライズクラスソリューションでの重要な利益を提供するものなので、インフラ全体でのデータロス、従来のインフラストラクチャに付随する管理コスト、やデータ保護の対応に関連するものです。

エンタプライズのお客様は現在HCIへの一歩を踏み出すだけでなく、Veeam Availability for Nutanix AHVによるデータ保護、投資を有効という機会があるのです。

VeeamはNutanix社とのパートナーとお客様へ全てのアプリケーションの保護の為のHyper-Availabilityをお客様へ提供できることをとても誇らしく思っています。

もっと多くの情報を知りたい方はwww.veeam.com.まで

記事担当者 : SI技術本部 カッシー @Nutanix_NTNX

2018/11/06

Lenovo ThinkAgile HX for SAP HANAについて学んでみよう!

この記事はレノボ・エンタープライズ・ソリューションズの小宮様に寄稿いただきました。

第3回目となります今回は、Lenovo社が提供する ThinkAgile HXのSAP HANA対応についてご紹介になります。

------------------------------------------------------------------------------

レノボ・エンタープライズ・ソリューションズ小宮です。本日はNutanix上でミッションクリティカルなワークロード環境を実現するThinkAgile HX for SAP HANAのソリューションについて取り上げてみたいと思います。

まずは、SAP HANAのNutanix対応をお話する前に、必要となるソリューションをお話したいと思います。

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

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

1_2

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

2. AHV Turboについて

2

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

3

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

4

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

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

5

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

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

6

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

7

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

8

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

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

9

SAP HANAがなぜいきなりNutanix対応になった経緯についてご説明致します。

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

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

10

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

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

11

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

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

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

CPUについては、メモリ構成上で3CPU以上が必須な構成のため、今回のSAP HANAモデルはLenovo ThinkSystemの4CPUモデルで採用しています。(3TB構成は実際に利用可能なメモリ容量としては2.3TBになります)

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

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

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

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

12

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

今後ともよろしくお願い致します。

------------------------------------------------------------------------------

今回は小宮様に Lenovo 社の ThinkAgile HXのSAP HANA対応についてご紹介いただきました。Nutanix 上で、SAP HANA を動かすために必要なコンポーネントから、SAP HANA の Nutanix 対応に至る背景、SAP HANA 対応の Lenovo ThinkAgile HX のモデルについて解説いただいてきました。
小宮様には今後も定期的に寄稿いただく予定ですので、みなさまどうぞご期待ください!