2018/12/12

エンタープライズクラウドへの最初の一歩

本記事の原文はFrame社(Nutanix社)のSenior Global Accounts Marketing ManagerであるEJ Bodnar氏, よるものです。

原文を参照したい方は「Take the First Step on Your Journey to the Enterprise Cloud」をご覧ください。

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

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

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

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


Dfa0e894cc2f4f22b15731489308ee4b_th

”旅も一歩からはじまる” つまり千里の道も一歩より起こる ということですね

何事も一歩を踏み出すことが大事ですし、NutanixのEnterprise Cloud Platformという概念がつい先日に行われた.NEXT Londonで発表されています。

主なIT組織の方はパブリッククラウドの俊敏さ、シンプルさとプライベートクラウド内で必要な制御、セキュリティを併せ持っているNutanix Enterprise Cloud への移行が始まっています。

Enterprise Cloudへの移行は旅であり、ここから始めることが成功へつながる最初の一歩という事は既にしられており、この以降かは初め、お客様はよく計画された方法で明確なロードマップに従い目的を達成する事が出来るのです。

企業のEnterprise Cloudへの旅とし、最初のステップはIT組織がIT組織がIT Maturityに関して知る事です。既存のIT成熟具合をすることでEnterprise cloudへ移行するための開始時点がきまり、取り掛かる事でEnterprise Cloudという目的地へ達成する成功となるのです。

Nutanixは全体的にIT成熟度のアクセスに利用するためにテクノロジー、オペレーション、組織という3つの重要なポイントにアクセスする直感的かつ包括的なツールを開発しています。

Nutanix Maturity Modelと共にお客様は技術、利用状況、IT操作状態と全体的な組織の為の準備を理解する事が出来ます。

お客様はまた個別のIT Maturityスコア、推奨事項を含むカスタムレポートやIT組織がEnterprise Cloudへの旅を加速させるためにとることのできる次のステップを受け取ることができます。

加えてお客様の産業のなかでIT組織がどうなっているかを他の会社と比較して理解する事ができるでしょう。

成熟度モデルに関してはこれを見ていただくと完全に理解できると思います。

是非 Enterprise Cloudへの一歩を踏み出してください。

先日.NEXT Londonで発表があったようにEnterprise CloudのカテゴライズによりCoreから開始し様々な面から拡張しEnterprise Cloudの利用という事を発表していました。

このEnterprise  Cloudの世界へ踏み出すことが成功の一歩としており、Coreというカテゴリから入っていき必要に応じて必要な機能 Freedom to Choise を踏み出してみてはいかがでしょうか?




©️ 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技術本部 カッシー @Networld_NTNX

2018/12/09

今日のVMware PowerCLI : NetAppのNFS用パラメータを一撃で設定

こんにちは、ネットワールドの海野です。
vExpert Advent Calendar 2018の 12月9日分ということで、ブログ記事を作成しました。
PowerCLIを使うと、WindowsのPowerShellによってVMware製品の環境を操作することができます。
PowerCLIのインストール方法は以前の記事をご覧ください。


【できること】

 NetAppをNFSストレージとしてESXiへマウントする場合、NetAppのドキュメントに基づいた設定値をESXiへ入力することでストレージのパフォーマンスや安定性の向上が期待できます。
 今回ご紹介するPowerCLIを利用することで、上記の設定値を一発で入力できるようになります。

 

【注意事項】

 このサンプルスクリプトは弊社並びに私個人で何らかの動作を保証するものではありません。ご自身の責任にてご利用いただくことを前提としております。
 以下のドキュメントに基づいて作成されていますが、適宜最新の情報をご確認ください。
 ESXi host values set by VSC for VMware vSphere
 https://library.netapp.com/ecmdocs/ECMLP2843689/html/GUID-346ACB95-6AD4-4DEA-8901-C9697AC3530F.html
 また、このサンプルスクリプトはESXi 6.5を対象としており、ESXi 6.5でのみテストをしています。

 

【使い方】

 PowerCLIがインストールされたWindows環境において、NFSストレージをマウントするESXiと通信できることが前提です。
 このPowerCLIを.ps1形式で実行すると、ESXiホストの名前 / ユーザー名 / パスワードを確認されます。
 正しく入力され、認証に成功すると対象となるESXiホストのパラメータを更新します。
 更新されるパラメータの項目名と設定値は次の通りです。

  • TcpipHeapSize : 32
  • TcpipHeapMax : 1536
  • MaxVolumes : 256
  • MaxVolumes : 256
  • MaxQueueDepth : 64
  • HeartbeatMaxFailures : 0
  • HeartbeatFrequency : 12
  • HeartbeatTimeout : 5

 設定が完了するとESXiの再起動を促されますので、確認の上で再起動を実行します。
 なお、このときユーザープロファイルのドキュメントに実行ログを出力する仕様になっています。

以下、サンプルコードです。


##################################################

# Section 1 - Initialize VMware PowerCLI

##################################################

Import-Module VMware.PowerCLI

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

 

##################################################

# Section 2 - Apply Best Practice for NetApp

##################################################

 

Start-Transcript

 

Write-Host '

*********************************** 注 意 ***********************************

NFS Best Practices for NetAppの設定を行うPowerCLIスクリプトです。

*****************************************************************************

'

 

$esxi = Read-Host 'ESXiホスト名を入力してください'

$username = Read-Host 'ユーザー名を入力してください'

$password = Read-Host 'パスワードを入力してください'

 

try{

Connect-VIServer -Server $esxi -User $username -Password $password -ErrorAction Stop

} catch{ Write-host "認証エラー"

exit

}

 

Get-VMHost $esxi | Get-AdvancedSetting -name Net.TcpipHeapSize | Set-AdvancedSetting -Value 32 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name Net.TcpipHeapMax | Set-AdvancedSetting -Value 1536 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name NFS.MaxVolumes | Set-AdvancedSetting -Value 256 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name NFS41.MaxVolumes | Set-AdvancedSetting -Value 256 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name NFS.MaxQueueDepth | Set-AdvancedSetting -Value 64 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name NFS.HeartbeatMaxFailures | Set-AdvancedSetting -Value 10 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name NFS.HeartbeatFrequency | Set-AdvancedSetting -Value 12 -confirm:$false

Get-VMHost $esxi | Get-AdvancedSetting -name NFS.HeartbeatTimeout | Set-AdvancedSetting -Value 5 -confirm:$false

 

Restart-VMHost $esxi -Force -RunAsync -Confirm:$true

 

Stop-Transcript # ロギング終了

 


 上記のサンプルコードは以下のURLからもダウンロードできます。

 https://networld.citrixdata.com/d-s0c830fe24d34eeb8

 PowerCLIを使ってミスを少なくし、時間を節約しましょう。

※追記 : スクリプトの内容を一部修正しました。Get-VMHostのあとに$esxi変数を指定し、設定値が全体に適用されないように修正しています。(2018年12月9日 17:00)

記事担当者 : SI技術本部 海野 航 (うんの わたる)

2018/12/05

Nutanixサイジングツール "Sizer 入力の勘所"

Nutanixのサイジングにあたり、Nutanix社ではSizerと呼ばれるサイジングツールを提供しております。

当社でもこのサイジングツールを利用してサイジングを実施しておりますが、今回はサイジングにあたり考慮すべき点などをあげさせて頂きます。

まずNutanix社ではEnterprise Cloud Platformとしてマルチクラウド管理の実現を行える製品を多くだしていますが、オンプレミスでNutanix環境を稼働させるにはワークロードをベースにNutanixを選定していきます。

重要なのはハードウェア、Hypervisorというよりもどれだけのワークロードを動かすか?となるわけです。

Rvtool_2つまり既存のハードウェアのリプレイスにNutanixを検討されている場合に

既存のハードウェアスペックに対してサイジングを行ってしまうと、既存のハードウェア=ワークロードとなってしまいます。

もし既存環境が60~70%以下の利用率となっているケースではかなりのオーバースペックが選定されてしまいます。

もう一度繰り返しになりますが、サイジングで必要なのはワークロードとなります。

4

実際にワークロードの作成までの流れを見ていきましょう。

  1. シナリオ名、ハードウェアの選定
  2. ワークロードの登録
  3. シナリオ結果の確認

Nutanixを稼働させるハードウェアは純正のNXモデル以外にもLenovoHXモデルなど選択が可能となっております。

どのハードウェアを利用したいかを決めてワークロードを登録していきます。

タークロードタイプはどのようなワークロードを稼働させるか?によって決まってきますが、簡単に構成を確認するにはRawと呼ばれるものを利用してワークロード全体の入力を実施するか、仮想サーバの数そして、仮想サーバ単位でのワークロードの入力となります。

5

本Blogではサーバ仮想化におけるRawの値、またRVtoolsを利用したサイジングについて触れていきます。

サーバの仮想化についてまず知るべきなのはアプリケーションの分類を分ける事です

仮想マシンごとに次のタイプが解っている事がベターです。

[仮想マシンのスペックの例]

 - memory , CPU (Mhz) , OS ドライブ, データドライブ(Hot / Cold データ)

ただし、最初の段階でこの辺り(特にCPU やHot / Cold データ)を把握して置くのが難しい場合は

次を基準に登録してみましょう。

[vCPUとmemory]

vCPU と pCPUのRatio比率

- BCAアプリケーションでは 1:1 (または2:1)

- 一般的なサーバ 4:1

- OTA 環境で最大10:1(この場合はパフォーマンステスト事前に実施する事を推奨します)

[ディスク領域のポイント]

データの複製は2重化にするか、3重化にするか?

-RF2の場合はデータは常に2重化されるので、利用可能な領域は50%

-RF3の場合はデータは常に3重化されるので、利用可能な領域は33% -Proライセンスが別途必要

EC-Xを有効にする場合で最小ノード数が変更になる -Proライセンスが別途必要

-RF2 + EC-X では最小スタートノードは4ノード

-RF3 + EC-X では最小スタートノードが6ノード

Hybrid構成の場合はSSD Tierの割り当て量を考慮します。

SSDのTierの領域はExtent Store , Oplog また、Metadeta ,Curatorなども動作するためにサイジングは多めに設定する事を推奨しています。

SSDの目安としてはデータセットの10%程度から開始して状況と予算に合わせて調整するとよいのではないでしょうか

【圧縮・重複排除の扱い】

データセットが不明な場合は考慮に入れない

構成によってはProライセンスが必要になりますし、圧縮率の判断が難しいところですので

最初の段階では無効に設定しておく方が無難なケースが多いです。

(例えばLinked ClonesへのDedupe , jpgファイルへの圧縮効果は期待できません)

[障害考慮のポイント]

NutanixのSizerでは1ノード障害、2ノード障害を考慮したサイジング可能となっております。

構成時は障害を考慮してN+1などで構成しましょう。

次にストレージノードを構成する場合ですが、ストーレジノードの障害時はデータ分散が他のノードにされますので、これに対応できるようにしましょう!

容量の少ないノードとストレージノードの組み合わせだとストレージノード障害時にデータ分散で他のノードの容量が多くなる可能性があります。

78

既存の環境の状況を把握する場合にはRVToolsを利用するという方法もあります。

ここではRVToolsを利用したRawの入力値の参考になる項目などを記載しています。

Sizerに入力するRawの値を確認するには必要な項目はvInfo, vPartition, vHostとなります。

他の不要な項目はいったん削除しておきましょう。

前提としてサーバのカテゴリ分類をしていませんので、実際に確認される場合はカテゴリ毎にRawの値を見るようにしていただければより最適なものになっていきます。

10

次に稼働しているワークロードのフィルタをかけるためPower Onのフィルタを実施します。

また、SizerへこのRvtoolsのimportも行えますが、この際も同様にPower OFFの物は除外されます。

12Memoryタブでは実際に稼働している仮想マシンに対して合計のメモリーサイズが確認できます。

14

CPUタブでは仮想マシンのCPU数が確認できます。

15vPartitionでは仮想マシンのディスクサイズが確認できます。

16

ここまでで仮想マシンの合計のCPU数、メモリーサイズ、Diskサイズが確認できました。

つまり、これでRawに登録するvCPU数,メモリーサイズ,Diskサイズが入力できるわけですが、

Diskサイズに関してはSwapファイルを考慮するとDisk サイズ+ Memoryサイズとなります。

この例では登録するアクティブなワークロードの合計としては

vCPU数を145

メモリーサイズ:496GiB (507904/1024)

Diskサイズ:2.24TiB (1841729+507904) / 1024 / 1024

この値は確認する計測期間がながく、確認するタイミングが多ければ多いほどより適正なサイジングに近づいてきます。

次にvCPU:pCPUを見ていきますが、これにはvHost から物理CPUを確認していきます

18

稼働している仮想マシンと物理コアが確認できましたので、アクティブワークロードのでの

vCPU , pCPUの比率は145 / 48 となります。

が1ノード障害が発生した場合はどうなるかという事をここで考慮してみましょう。

物理コアは48 -> 36 となりますので、1ノード障害時でもすべての仮想マシンが現在正常に稼働していると考えると、145 / 36 = 4.02  この値が最適では無いかと考えられます。

これでRawに入れる値がすべてそろいました。

まとめると

vCPU数:145

vCPU:pCPU: 4

memory:496

Disk:2.24

HotTire:0.24 (10%)

vCPUとpCPUの比率ですが、実際に昔のCPUと新しいCPUではパフォーマンスが異なります。

古いハードウェアほど、vCPU:pCPUコア比率は上げる事が出来るわけです。

ここでは実際に既存のハードウェアのプロセッサをvHostから見てみます。

17既存のCPUの値とサイジング結果で出たCPUの結果の値をCPU Benchmarks (外部リンク) というサイトで簡単に比較する事も出来ます。

実際にサイジングで入力してみると今回の最適なモデルはNX1065-G6となりCPUはSilver4114となっています。

Detail

Cpu

ここで先ほどのCPU Benchmarksの値を確認すると以下であることが解ります。

Intel Xeon E5649 @ 2.53GHz     スコア:1,170
Intel Xeon Silver 4114 @ 2.20GHz     スコア:1,661

既存のCPUから新しいスペックへ置き換えると既存と比較しても凡そ1.42倍のスコアになるわけです。

vCPU:pCPUですが、実際に稼働する場合は4:1ではなく、4x1.42:1となります。

つまり同じスペックをそのまま引き継ぐと4:1ですが、世代がことなるので実稼働は

5.68:1 程度で動作させることが可能となります。

これをサイジングでAuto -> manualに変換してみると CPUの利用率は50%程度まで下がることがわかり、十分余裕のあるサイジングである事が解ります。

After_cpu2

RVToolsを利用する事で実際の仮想マシンの利用率ではなく、プロビジョンに対してサイジングを

する事も出来ますし、既存環境がすべてONという状況を想定したサイジングも可能です。

ただし、Nutanix自体はスケールアウトが1クリックで行える製品になります。

様々な角度でサイジングを行ってみて、このタイミングでSizerの利用方法について慣れてみては如何でしょうか?

【あとがき】

この記事はNutanix Advent Calendar 2018の2枚目の12/5日分として投稿しています。

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

2018/12/04

すぐできるシングルサインオン : Azure ADとNutanix Xi Frame

本記事の原文はFrame社(Nutanix社)のソリューションアーキテクトであるBill氏によるものです。

原文を参照したい方は「SSO in 10 minutes with Azure AD and Frame」をご覧ください。

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

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

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

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


【はじめに】

 この記事はNutanix Xi Frame Advent Calendar 2018の4日目分として投稿しています。

 現在主流となっているVDI製品ではセキュリティ意識の高まりに伴い認証系のソリューションとの組み合わせが流行しておりますが、もちろんXi FrameでもSAMLを利用したシングルサインオン連携が可能です。次回更新以降はAD連携の手順をご紹介する予定ですが、今回はその前振りとして本家Frameのブログから関連記事を日本語訳としてご紹介致します。


「あなたはどれだけのパスワードを覚えていますか?」

「アクセスができなくなったユーザーのロック解除にはどれくらいの時間がかかりますか?」

「パスワードのルールや変更ポリシーを強制しますか?」

 

 私たちはお客様にこれらの質問をしました。多くのお客様が認証(ログイン)システムを構築するために多くの時間とお金を費やしており、Frameに移行したとしてもその認証システムを使い続けたいと考えているようです。

 つまり、シングルサインオン(SSO)をサポートするための迅速で簡単な方法が必要であるということです。SSOを使用すると、ユーザーはFrameに別途ログインすることなくアプリケーションや仮想デスクトップを起動できます。また、既存の認証システムでユーザーのアクセスを無効にすると、Frameへのアクセスが無効とすることができます。

 SSOはこのような重要なツールであり、2つのシステムを簡単かつ安全に連携させるための業界標準が作成されています。いくつかの方式が存在しますが、フレームは最も広くサポートされている方式であるSAML2を採用しています。そのため、SAML2をサポートするすべてのIDプロバイダー(ログインサーバー)と連携できます。

 最も一般的なIDプロバイダーの1つは、MicrosoftのActive Directoryです。Active DirectoryとFrameを統合する最もシンプルな方法は、MicrosoftのAzure ADプラットフォームのActive Directory Connect機能を使用することです。これにより情報システム部門は、Microsoftによるツールのみを利用して特定のユーザーやグループを認証させることができます。Azure ADはインターネットとの統合をハンドリングし、セキュリティ部門がファイアウォールのルールやセキュリティポリシーを作成する手間を省きます。

 Active DirectoryをAzure ADへ接続したら、Frameを使用してカスタム認証を作成します。Frame Platform Ultimateアカウントでこの機能を有効にするには、Frameのアカウントマネージャーにお問い合わせください。その後、FrameとAzure ADと連携させるためのURLとIDをコピペするだけです。10分ほどセットアップに要しますので、お茶でも飲んでお待ちください。また、詳細につきましてはFrame Documentationのステップバイステップガイドをご覧ください。


【あとがき】

これからが本当の地獄だ。

 

記事担当者 : SI技術本部 海野航 (うんのわたる) @Networld_NTNX

 

2018/12/02

FinTechとブロックチェーン : HCIと「シリコン・アレー」の交わる場所

本記事の原文はNutanix社のグローバル金融サービスソリューション部門の責任者のKevin Lash氏によるものです。

原文を参照したい方は「FinTech and Blockchain: Where Silicon Alley meets Hyperconverged Infrastructure」をご覧ください。

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

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

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

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


【はじめに】

日本でもちょっと前にブロックチェーンによる仮想通貨がいろいろな意味で盛り上がりを見せており、「FinTech」や「仮想通貨」という言葉は一般的になっていると思います。

最近ではQRコードを利用した決済スキームや電子マネーの提供が多くなっており、ますます金融技術が身近なものになってくるでしょう。

そうした金融技術を支えるためのプラットフォームとしてのNutanixに関連する記事を翻訳してみました。


あなたは「シリコン・アレー」という場所を聞いたことがないかもしれませんが、そこから始まった革新的な金融技術であるFinTech (Financial Technology)はご存知であると思います。

 

「シリコン・アレー」は、マンハッタンのフラットアイアン周辺にあるスタートアップ企業を惹きつけるキーワードとして、1990年代の半ばに造られました。

この「シリコン・アレー」はFinTechと金融におけるデジタルトランスフォーメーションを推進させる場所ですが、私はこの言葉がドットコムバブルに関するあなたの嫌な記憶をフラッシュバックさせないことを願います…。

 

最近ニューヨークで行われたEmpire FinTech Weekというイベントではスタートアップのソリューションの多くが展示されました。

NutanixはFinTech事業者やさまざまな金融機関とともに、これらのソリューションについて開発・統合、そしてグローバル市場に展開するための課題を研究するカンファレンスを開催しました。

 

【シリコン・アレーとシリコンバレーの未来は金融機関と絡み合っている】

FinTech事業者と金融機関の間でパートナーシップは急速に強化されています。

FinTech事業者は新しい顧客を獲得し、自らのサービスを利用してもらう必要がある一方で、金融機関は自社の成長を維持するとともにスタートアップのFinTech事業者からビジネスモデルを守るための革新が必要です。

そのため、金融機関はFinTechソリューションを従来のベンダー同様にシステムを調達するだけでなく、エコシステムと直接的に連携させたり、パートナーシップを強化させたり、投資、場合によっては買収をしています。

 

そこで疑問となるのは、なぜシリコンバレーにありHCIやエンタープライズクラウドを推進するNutanixが、FinTechとブロックチェーンを扱う新興企業にフォーカスしたいのかということです。

 

1つ目の理由は、Nutanixは革新を求め、創造的な破壊を必要としていることです。

これはハイパーコンバージェンスとエンタープライズクラウドを含む最も急速に成長する業界の1つを代表する金融サービス業界で特に当てはまります。

2つ目の理由は、Nutanixはこれらの革新的な金融ソリューションを継続的に開発・展開するための安全性と俊敏性を備え、最適でユニークなインフラストラクチャプラットフォームの提供ができるということです。

 

【FinTechはオンプレミスとパブリック・クラウドのハイブリッド実装である】

驚くべきことは、金融機関とFinTech事業者の間でこれらのソリューションが互いの顧客に対してシームレスに利用できるように相互補完をしているということです。

成功を収めたFinTechソリューションは、これらのコンポーネントの各部を最小限に抑えて統合されていました。

 

  1. ユーザーエクスペリエンス(UX)
  2. APIと "ミドルウェア"
  3. データ共有リポジトリ
  4. コア処理プラットフォームとバックエンドシステム

 

FinTechカンファレンスでの大きな成果の1つは、スタートアップFinTech事業者が大きな懸念を抱いていることがわかったことです。

FinTech事業者は金融機関の持つレガシーなインフラと複雑で厳密な実装およびそのテストの方法論に悩まされていました。

これはFinTech事業者に対してクラウドプロバイダーによって提供されるシンプルなAPIとデータ共有を利用したいと考えさせるようになりました。

 

一方で、金融機関は、規制やプライバシー、セキュリティやレピュテーションリスクが、特にデータ利用に関連するより厳しい社内管理を要求するハイブリッドとマルチクラウドの実装を必要とするソリューションであると考えています。これらの懸念は、データの誤用や開示されたセキュリティケースでこそ高まります。

 

【FinTech&Blockchainの実装でハイパーコンバージドインフラストラクチャが魅力的な理由】

ハイパーコンバージド・インフラストラクチャ(HCI)は、パブリック・クラウドと同じような市場への提供スピード、プロビジョニング・エクスペリエンス、コスト優位性を提供します。

また、それと同時にオンプレミスならではの管理と最大限のデータ・セキュリティを実現させることで、FinTechおよびBlockchainソリューションを開発・検証・実装する金融機関は、ガバナンスやリスクおよびコンプライアンスポリシーを妥協することなく、ラボや検証環境を構築して実務環境(本番環境)に移行させることができます。

このハイブリッドクラウドおよびマルチクラウドアーキテクチャは、FinTech事業者と金融機関の懸念に対応します。

 

NutanixはFinTechとBlockchainインフラストラクチャをプロビジョニングするためのシンプルなワンクリックサポートを提供します。

 

  1. 強化された制御、セキュリティ、コンプライアンス
  2. 開発、テスト、展開のためのセットアップの改善
  3. マルチクラウド環境(パブリック&プライベート)でのアプリケーション配信

 

ご自身の施設やビジネスについてディスカッションしたい場合は info@nutanix.comまたはTwitter @Nutanix にご連絡ください。

 

Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.


【あとがき】

この記事はNutanix Advent Calendar 2018の2枚目の2日目分として投稿しています。

私個人はクレジットカードをコレクションすることが趣味なのですが、それに付随していわゆるFinTechにも興味があります。

ということで、NutanixとFinTechというカテゴリでこの記事を見つけましたので、ぜひ翻訳をという運びでした。

数年前からメガバンクやその関連機関でもクラウド採用が発表されており、ますます複数のクラウドを使い分けるマルチクラウドや、オンプレと連携させるハイブリッドクラウドなどが一般的になっていくでしょう。

ということで、日本国内でもXi Cloudサービスの本格的な展開を期待しています。

記事担当者 : SI技術本部 海野航 (うんのわたる) @Networld_NTNX

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を利用されている皆様には良い機能かと思いますので是非是非使ってみてください。
評価等のご希望がありましたら、こちらの「お問い合わせ・ご相談はこちら」からブログを見て!とご連絡を頂ければと思います。
すずきけ

アクセスランキング

お問い合わせ先
ネットワールド ブログ運営事務局
blog.doc-info@networld.co.jp
フォトアルバム