LTN Blog 〜 Lenovo Technology Network 〜

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

Nutanixの用語を覚えてみよう!~Nutanixの構成要素について~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixの基本的な用語について説明します。新入社員が入ってきてこれからNutanixを覚えようという人もいらっしゃいますので、Nutanix Bibleもいいけれどこちらのサイトも是非参考資料としてみて頂ければと思います。

 

1.Nutanixの用語について

f:id:t_komiya:20190429231944p:plain

Nutanixを構成する用語ですが、これらの用語です。それぞれの用語について一つずつ説明していきたいと思います。

・ノード

ノードはNutanixクラスタの基本単位になります。各ノードは標準ハイパーバイザーを実行し、SSDとHDDストレージの両方で構成されたプロセッサー、メモリー、およびローカルストレージを含みます。

・ブロック

ブロックは、最大4つのノードを含むNutanixのラックマウント型ユニットです。(2U4Nodesの高密度サーバーが対象になります)

・クラスタ

クラスタはAcropolis Distributed Storage Fabric(DSF)を形成するNutanixブロックとノードのセットです。

・データストア

データストアは仮想マシン操作に必要なファイルの論理コンテナです。

・vDisk

vDiskは仮想マシンにストレージを提供するコンテナ内の使用可能なストレージのサブセットです。コンテナがNFSボリュームとしてマウントされている場合、そのコンテナー内のvDiskの作成および管理はクラスターによって自動的に処理されます。

・コンテナ

コンテナはストレージプールの論理的なセグメンテーションで、仮想マシンまたはファイルのグループ(vDisk)を含みます。コンテナは通常、NFSデータストアまたはSMB共有の形式で共有ストレージとしてホストにマッピングされます

・ストレージプール

ストレージプールとは、クラスタ用のSSDやHDDなどの物理ストレージデバイスのグループです。ストレージプールは複数のNutanixノードにまたがることができ、クラスターの規模が拡大するにつれて拡張されます。

・ストレージティア

ストレージティアでは、MapReduce階層化テクノロジを利用して、データを最適なストレージ階層(フラッシュまたはHDD)にインテリジェントに配置し、最速のパフォーマンスを実現します。

 

ここには記載はありませんが、AOS5.9からブロックの集合体でRackという概念があります。詳しい内容について過去のブログの方を参照して頂ければと思います。

https://blog.lenovojp.com/entry/2018/10/07/022932

2.ノードについて

f:id:t_komiya:20190429232609p:plain

仮想マシンのホストのことを指しますが、Nutanixは通常のラックサーバと高密度のサーバーで構成されるため、それぞれのハードウェアでわかりやすく示してみました。高密度サーバーでは、筐体の中に収納されている一台のサーバーになります。

3.ブロック・クラスタについて

f:id:t_komiya:20190429232937p:plain

ブロックについては先に説明した通り、高密度サーバーのみに適応される概念です。4ノードを一つのブロックとして扱います。もちろん、筐体障害の場合はシステム停止になったりします。そこで、複数の筐体にまたがってデータを格納する方式(Block Awareness)を採用することが多いです。

4.Prism上での画面イメージ

f:id:t_komiya:20190429233656p:plain

Prism上からの画面で説明します。ハードウェアのメニューからDiagramを選択するとNutanixのクラスタを形成しているハードウェアが表示されます。(今回は2U4Nodeの筐体に3台分しか表示されておりませんが)

今回の構成では、クラスタとブロックが同じ枠で囲われておりますが、ノード数が多ければクラスタは組んでいる構成で表示されます。

青色で表示されているところはDiskになりますが、コンポーネントに障害が起きていれば、該当のパーツが赤く表示されます。

5.Distributed Storage Fabric

f:id:t_komiya:20190429235655p:plain

Nutanixのノードがグループとなって、分散ストレージファブリックを形成されます。この分散ストレージがハイパーバイザーを動作させる基盤になり、またi/Oはローカルで処理された後に、データの冗長化を保つためにデータを分散配置します。

6.データの構造

f:id:t_komiya:20190430000004p:plain

DSFのデータ構造はこのようなイメージで構成されます。物理ディスクグループのストレージプールを作成され全体の容量が定義されます。そこからコンテナを定義して使用可能な領域を定義して、コンテナ内にvDisk(仮想マシン用の領域)を割り当てます。こちらについては、ハイパーバイザーによって、サポートするプロトコルも異なりますので、ご注意下さい。AHVについてはiSCSIになります。

f:id:t_komiya:20190430000642p:plain

ストレージについて画面イメージをこちらに載せておきます。ストレージメニューからTableを選択します。ストレージプールを選択すると、テーブル情報とサマリ情報が表示されます。こちらで、ストレージプールやコンテナの情報が確認できます。また、データをExportすることもできます。

 

以上、Nutanixの構成要素の説明を終わります。

 

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

【太鼓判】ユニリタ・Actifio・レノボで実現するITモダナイゼーション

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

本日はユニリタ社・Actifio社・レノボ社で実現するITモダナイゼーションについてソリューションをご紹介したいと思います。

 

ソリューションのご紹介の前に、ユニリタ社およびActifio社がどのような会社なのかをご存じでない方もいらっしゃいますので、両社のご紹介したいと思います。

 

ユニリタ [https://www.unirita.co.jp/]

データ活用領域、ITシステム運用管理領域のパッケージソフトウェア開発・販売・サポートおよびソリューション、コンサルティングサービスの提供しております。

「Information」「Service」「Cloud」3つのコアテクノロジーを通じてお客様のビジネスにおける価値を創造するDX(デジタルトランスフォーメーション)を加速させる真のパートナーを目指します。

 

Actifio[https://www.actifio.com/jp/]

データセンターバックアップソリューションの総合評価でNo.1(Gartner社)の実績、データの仮想化、コピーデータマネージメントで容量消費なく仮想コピー生成、任意の場所で即時アクセスを実現可能にし、増大するデータを削減するソリューションを提供しています。30ヶ国以上の国々で千社を超えるグローバル企業やサービスプロバイダーのお客様にソリューションを提供しています。

 

今回ご紹介するITモダナイゼーションについてですが、3社のソリューションをレガシーシステムのデータ移行を簡素化して、データの効率的な利用でDevOps 環境を最適化する「IT モダナイゼーション」ソリューションを提供します。

それぞれの会社製品も合わせて今回の内容をご紹介します。

 

1.現在のアプリケーションのITインフラの課題について

近年、企業が保有するデータ量は増え続けています。これらのデータを効率良く活用することが、DX(デジタルトランスフォーメーション)時代を生き抜くカギになります。そのため、データの集計、加工だけでなく、データの分析および開発テスト環境などさまざまな用途でデータをレガシーシステムから取り出し、活用することが必須になっています。しかし、DXを実現するには、ITモダナイゼーション(近代化)が必要です。

 

レガシーシステムは非常に高価であり、また運用も複雑化しています。データもレガシーシステム向けに入力することが必要であり、非常に手間がかかっています。また、アプリケーションも複雑なコードで構成されており、アップデートや変更に時間を要し、テスト工程も含めると莫大な時間と費用がかかります。今後はクラウドを活用した、SaaS(Software as a Service)などの活用や、Windowsアプリケーションからのデータ連携やテストデータなどの効率的な活用が必要です。

f:id:t_komiya:20190429123314p:plain

 「Waha! Transformer」「Actifio」「ThinkAgile HXシリーズ」の3つのソ
リューションを利用することで、ITモダナイゼーションの実現が可能とな
り、ビジネスに俊敏性が生まれ、戦略的なサービスが創造できるように
なります。

 

.3社のソリューションのご紹介

  • Waha! Transformer (ユニリタ社)
    「Waha! Transformer」でメインフレーム/UNIXといったレガシーシステ
    ムからのデータの変換/加工を行い、ユーザ環境に適したフォーマット
    に変換します。

    https://www.unirita.co.jp/products/waha.html

    f:id:t_komiya:20190429131644p:plain

  • Actifio (Actifio社)
    「Actifio」を利用することで、反復して利用するテストデータによるスト
    レージ容量を削減し、テストデータを短時間で提供することができます。
    コピーデータを一元管理した上でデータのマスキングも「Waha!
    Transformer」で連携して行います。
    https://www.actifio.com/jp/technology/solutions-architecture/

    f:id:t_komiya:20190429132446p:plain

  • ThinkAgile HXシリーズ (レノボ・エンタープライズ・ソリューションズ)
    レガシーシステムで抽出したデータを分析する基盤およびDevOps環境
    などで利用するテストデータの活用場所として、LenovoのNutanixアプ
    ライアンスである「ThinkAgile HXシリーズ」を利用することで、インフラ
    ストラクチャーの運用を簡素化します。さらにハイブリッドクラウドとの
    連携により、仮想環境およびアプリケーションが最適に動作可能な環
    境を提供します。

    https://www.lenovo.com/jp/ja/data-center/software-defined-infrastructure/ThinkAgile-HX-Series/p/WMD00000326

    f:id:t_komiya:20190429132929p:plain
    Lenovoの「ThinkAgile HXシリーズ」はハイブリッドクラウドの連携や運用の簡素化だけでなく、Lenovoが持っているハードウェアの特性やサポート体制が品質向上につながります。
    ハードウェアの信頼性については、サーバーベンダーのなかで4年連続No.1を獲得しております。運用管理についてもハードウェア管理するソフトウェアとNutanixとの連携でシステム全体を監視できるようになっています。また、ネットワークインフラとの親和性もあり、仮想マシン作成時にネットワーク機器に同時に設定を施すことができるようになっております。これはクラウドで利用される技術を採用することにより実現しています。また、お客様に提供する前にハイパーコンバージドインフラを事前導入することで、納品後すぐに利用できるサービスを提供しています。
    サポート体制に関しても、障害時のハードウェア・ソフトウェア含めた一括の窓口を提供しており、お客様は一つの電話番号でシステム障害の問い合わせが可能になっています。
    ハイパーコンバージドインフラの特徴に、無停止によるシステム拡張があります。事前に社内にシステム停止の連絡することなく、システムの拡張が可能で、IT管理者のTCO削減に大きく貢献します。SAPなどのミッションクリティカルな環境でも「ThinkAgile HXシリーズ」はサポートします。Lenovoは、SAPのグローバルマーケットリーダーであり、ベンチマークにおいてもパフォーマンスNo.1のベンダーです。レガシーの環境に比べてTCOを大きく削減することが可能です。

.ITモダナイゼーション実現の向けて

f:id:t_komiya:20190429133351p:plain


3社のソリューションを組み合わせたITモダナイゼーションをイメージ化したものがこちらになります。

是非、ITモダナイゼーションとDX時代を生き抜くために、「Waha! Transformer」
「Actifio」「ThinkAgile HXシリーズ」の組み合わせを、ぜひご検討ください。

 こちらは、レノボ・エンタープライズ・ソリューションの太鼓判にも掲載予定です。

 

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

 

Nutanixが提供するコンテナプラットフォーム~Karbonのご紹介~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixが提供しているコンテナサービスのKarbonをご紹介します。

Karbonのことをご説明する前に、まずはコンテナとコンテナが必要な背景をお話したいと思います。

1.コンテナが必要な背景

f:id:t_komiya:20190413222737p:plain

Nutanixでは様々な機能を提供しています。ハイパーコンバージドインフラとして複雑さをなくし運用をシンプル化して高い俊敏性を兼ね備えてデータセンターのモダナイゼーションを実現しています。

Enterprise Cloudによりビジネスアプリケーションをできる完全一体型の単一ソフトウェアを提供していますし、オンプレミスとクラウド(Xi Cloud)を統合できる環境もすでに持っています。

今回のコンテナが関係するところについては、アプリケーションの開発者向けのプラットフォームの部分です。クラウド環境でアプリケーションを利用する場合、クラウド環境に適した環境でなければなりません。その場合に、従来型のようなスクラッチでの開発を行っていては、時間もお金もかかってしまうだけでなく、クラウド適した(俊敏性を要求される)環境には全く適しません。そこで、最新のアプリケーションとサービスを一つの環境で実行できるものとしてコンテナが必要となるわけです。

f:id:t_komiya:20190413223941p:plain

アプリケーションも進化しています。従来のアプリケーションは一つのモジュールで提供されていることからコードが複雑な構造になってしまい、アップデートや変更を行おうとするとすべての部分に影響が出てしまい、作り直しに手間がかかります。それによりテストの工数も増えてしまいインフラが俊敏性を兼ね備えてもアプリケーションが俊敏性を下げてしまう結果になります。

最近のアプリケーションはマイクロサービスと呼ばれるものに移行されています。マイクロサービスは、アプリケーションを複数のサービスに分割するため、アプリケーションの更新や変更が簡単になります。したがって、ビジネスの競争力を維持しながら更新が迅速に導入されます。

マイクロサービスにとって重要な要因となるインフラストラクチャのシフトがあります。それがコンテナです。

2.コンテナとはどういうもの?

f:id:t_komiya:20190413224450p:plain

コンテナと比較されるものとして、仮想マシンがあります。コンテナは仮想マシンに比べて、軽量であり、コンテナでホストOSをシェアできますし、OSを仮想化します。起動も早くメモリ消費も少ないのが特徴で持ち運びが非常に優れています。詳細はイメージをご参照ください。

3.コンテナのオーケストレーション

f:id:t_komiya:20190413224909p:plain

コンテナにはオーケストレーションが必要です。コンテナーオーケストレーションは、特に大規模で動的な環境において、コンテナーのライフサイクルを管理することがすべてです。ソフトウェアチームは、コンテナオーケストレーションを使用して多くのタスクを制御および自動化します。

・コンテナのプロビジョニングと配置

・コンテナの冗長性と可用性

・ホストインフラストラクチャ全体にアプリケーションの負荷を均等に分散するためのコンテナのスケールアップまたは削除

・ホスト内のリソースが不足している場合、またはホストが死んだ場合の、あるホストから別のホストへのコンテナの移動

・コンテナ間のリソース割り当て 外の世界を持つコンテナ内で実行されているサービスの外部への公開

・コンテナ間のサービスディスカバリのロードバランシング

・コンテナとホストのヘルスモニタリング

・アプリケーションを実行しているコンテナーに関連したアプリケーションの構成

4.Nutanix Karbon

f:id:t_komiya:20190413232958p:plainNutanix Karbonはお客様の環境を全体的にKubernetesクラスタを展開および管理するためのターンキーソリューションですKarbonはNutanixで上流およびネイティブのKubernetes機能を提供し、繰り返し作業を自動化し、複雑な作業を簡素化します。また、組織が自社のコード、コンテナ、およびアプリケーション開発にフォーカス できるようになりますf:id:t_komiya:20190413234116p:plain

 Karbonのメリットは使いやすく、管理しやすいプラットフォームにあります。インフラストラクチャと同時にライフサイクルを管理できるところ、サードパーティどのAPI連携できるのも特徴にあります。今後出てくる機能はAPI連携するものがリリースされる予定です。

.Kubernetes クラスタマネージャ

f:id:t_komiya:20190413234713p:plain

KarbonはPrism Centralで管理されるプラットフォームであり、Prismでのアラートやクラスタのヘルス管理も連携します。また、Karbon内部の解析も行うことができるようになるので、よりNutanixがインフラ(オンプレミスおよびクラウド含めて)アプリケーションの統合環境が実現されていくことになります。 

f:id:t_komiya:20190413235129p:plain

従来型のアプリケーションとクラウドネイティブのアプリケーションをNutanixで統合管理することができます。これにより、アプリケーションにとって望ましい環境でコンピュート環境を提供されることになります。

.Karbonでできること

f:id:t_komiya:20190413235610p:plain

Karbonを利用することで、Calmで作成するBlueprintは仮想マシンとコンテナの両方をサポートします。K8sのAPIはサードパーティとも連携し、統合したライフサイクル管理を実現します。 

f:id:t_komiya:20190413235814p:plain

Karbonを利用することで、LCM(LifeCycle Management)でファームウェアのみならず、マイクロサービスもまとめてアップグレードします。これにより、Era、Calm、Filesなどのアプリケーションも合わせてアップグレードされます。(今後これらがマイクロサービスで提供されるようになります)

 

今後はコンテナプラットフォームへの対応がNutanixで移行が進んでいくようになります。これによりインフラストラクチャとアプリケーションがもっと連携するような基盤がNutanixで出来上がっていくと思われます。

 

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

Nutanixのサイジングとベストプラクティスについて(その2)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixにおけるサイジングとベストプラクティスについての第二弾の内容をお伝えしたいと思います。

前回はNutanix Sizerの紹介とサイジングに関するそれぞれのリソースにおける注意事項をご紹介しましたが、今回はベストプラクティスを中心にお話したいと思います。

1.Nutanixのサイジングについて

f:id:t_komiya:20190407231503p:plain

 Nutanix Sizerでサイジングできる主なソリューションとして上記の内容になります。

VDIなどに関しては、VMware ViewやCitrix XenDesktopベースにしたサイジングやユーザ種別(タスクワーカー・オフィスワーカーなど)でサイジングできます。

サーバ仮想化については、仮想サーバの大きさを大・中・小と言った3種類で試算できます。

ほかにはデータベースやファイルサーバなどもソリューションもありますが、リソース全体でどのくらい必要なのか(例えば全体でCPUが200、メモリが500GB、容量が10TB程度など)を指定して算出するケースはRAW Inputなどを利用して算出できます。

 

サイジングするデータが事前にわかっていればよいが、実際の環境からそれを算出する方法はないのかと思う方もいらっしゃるかと思います。

2.仮想環境におけるデータの収集方法

f:id:t_komiya:20190407232936p:plain

既存のVMwareの環境がどれくらいの仮想でどのくらいのリソースを利用しているのかを簡単にわかるツールとして、RVToolsがあります。

お客様から既存環境の仮想マシンの一覧を頂くケースもありますが、実際に管理をしっかりやっていれば問題ないと思いますが、常にデータを管理できていれば良いですが、抜けがある場合も考えられます。

f:id:t_komiya:20190407233736p:plain

RVToolsは実際に仮想環境を管理するvCenterサーバもしくはESXホストから直接Credential情報をベースのログインして仮想マシンの情報を収集します。

収集した情報をレポートにまとめてもらえるので、仮想マシンのリソースが簡単に把握することができます。

f:id:t_komiya:20190407233844p:plain

f:id:t_komiya:20190407234015p:plain

RVToolsのレポートは上のイメージにもありますが、Excelライクな表示になります。こちらでリソースが把握できるわけですが、実際にどのように見ていくのかも合わせてもまとめておきました。
こちらをまとめて、RAW InputでサイジングをかけるとNutanixに必要な構成もすぐに出すこともできますので、是非ご利用下さい。

3.正しいサイジングについて

f:id:t_komiya:20190407234520p:plain

f:id:t_komiya:20190407234558p:plain

前回の内容からCPUとメモリのサイジング内容については記載していますが、改めて記載しておきます。メモリについては仮想マシンあたりのメモリオーバーヘッドの例を記載していますので、参考程度に見て頂ければと思います。

f:id:t_komiya:20190407234830p:plain

サイジングにおける注意事項を今回は記載したいと思います。

仮想環境でサイジングを行う場合、単に仮想マシンのリソースだけでサイジングするのではなく、CVMのオーバーヘッドも考慮する必要がありますので、数値を差し引くことを忘れずにお願いします。

また、CVMについてはCPUやメモリもありますので数値は前回のブログをご参照下さい。

圧縮。重複排除については、機能として利用できるが、CVMのオーバーヘッドにつながることから、利用しないほうがベターです。(利用しても良いがオーバーヘッドの考慮は忘れずに)

IOパフォーマンスを考慮する場合は、SSDの作業領域を多めにしておくことを忘れずに

既存環境もアセスメントしてからサイジングすることをお薦めします。

4.やってはいけないこと

f:id:t_komiya:20190407235344p:plain

Nutanixを提案する際によくあることを含めてコメントしたいと思います。

Nutanixはよく高いと言われて、価格を下げるためにRF2で提案している構成で、N+1台構成(例えば4台)からN台構成(例えば3台)に変更しようと言われます。

Nutanixや他のHCIも3台でも問題なく動作しますが、N台(特に3台)のケースでは、一台障害で落ちた場合に正常な状態での動作にはならないことから、障害対応も迅速に行う必要があります。そのため、N+1の構成はお客様に対する運用負荷を軽減させることもあるので、簡単に提案を変えることをしないようにお願いします。

変更する場合も、お客様にリスクを説明した上での対応を考えたほうがよいです。

気をつけよう!HCIに潜む落とし穴~知っておくとちょっと得をします~ - LTN Blog 〜 Lenovo Technology Network 〜

設計上の考慮事項についてですが、高密度型サーバー(2U4ノードのサーバー)を提案する場合に、筐体障害を考慮してBlock Awarenessを提案することをお忘れなく、一つの筐体でシステムが収まるという価値提案はできるものの、エンクロージャ障害には耐えられないため、Block Awarenessが必要になります。

Rack Awarenessは大規模の構成時に設計する概念になるため、小規模では意識する必要がありません。

Microsoftサポート、セキュリティ機能強化~AOS5.9の機能紹介~ - LTN Blog 〜 Lenovo Technology Network 〜

VDIやGPUのプロファイルについては、アプリケーション要件があるために、CPUの周波数を意識する必要があります。

f:id:t_komiya:20190408000325p:plain

レプリケーション要件については、仕様やライセンス要件をご確認下さい。

LTN Blogにも過去にNear SyncやMetroAvailabilityの記事は紹介しております。

Nutanixのデータ保護について覚えてみよう~Metro Availability と Near Syncの違いについて~ - LTN Blog 〜 Lenovo Technology Network 〜

また、異なるノードを追加する際についてですが、皆さん普通に1ノード追加すればよいと考える方もいらっしゃいますが、異なる容量の受け皿はもう一台追加する必要があるので、ご注意下さい。

一台しか増設しない場合リソース計算を間違えないようにお願いします。

ライセンスについてはレプリケーション要件などで関連してきます。Ultimateライセンスにしておけば問題ないケースは多いですが、Filesや暗号化のソフトウェアライセンスはProライセンスでも利用できることから、エディションの選択は間違えないようにお願いします。

 

最後の方は、特に提案時に気をつける内容として、まとめさせていただきました。

 

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

 

Nutanixのサイジングとベストプラクティスについて(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixにおけるサイジングとベストプラクティスについて2回の記事に分けてご紹介したいと思います。

Nutanixを構成する場合、提案するお客様の要件をヒアリングしてサイジングしたり、既存の環境などを調査してサイジングすることがあると思います。特に要件をヒアリングしてヒアリングする場合には、一般的にCPUやメモリやストレージをサイジングする場合に何か指標がないと困ると思います。(以下イメージはNutanix様の資料から拝借させて頂いております)

f:id:t_komiya:20190407160632p:plain

サイジングするにはまずワークロードのサイズを正しく知る必要があります。仮想マシンの数や種類、設定パラメータ、お客様が要求するSLAなどです。

上記の内容から簡単にサイジングすることは容易ではなく、ものによっては数日かかることもありました。

そんなサイジングを簡単にしてくれるのがNutanix Sizerです。

1.Nutanix Sizerとは?

f:id:t_komiya:20190407161000p:plain

Nutanix SizerはNutanix向けのサイジングツールで、実際に必要なワークロードを入力すれば、条件を満たすNutanixの構成をBOM(Bill of Material)の形で出力してくれます。

こちらのNutanix Sizerですが、my.nutanix.comから登録して利用することができます。

こにツールはSEさんまたは技術ユーザーが自分のニーズを満たす最適なソリューションを作成するためのツールです。利用する方は基本的にNutanixのアーキテクチャを理解されていることが前提としています。

2.サイジングするコンポーネントについて

f:id:t_komiya:20190407161543p:plain

サイジングするコンポーネントについてですが、イメージにもある通りCPU・メモリ・SSD・HDDなどが対象になります。(NICなどはサイジングに直接必要になるわけではありません)

必要な要件をNutanix Sizerに入力すれば、それぞれのメーカー毎に最適なマシンと必要な台数が出力されるわけですが、それぞれの項目について考慮する内容がありますので、そちらについて述べていきたいと思います。

.プロセッサの考慮について

f:id:t_komiya:20190407162341p:plain

プロセッサの考慮について、物理CPUと仮想CPUの考え方があります。仮想CPUは物理コアを割り当てることを考えていますが、ここで考慮する内容はワークロードによって物理コアを仮想CPUに対する割合が異なります。

一般的な仮想化では1:4の比率で割り当てることが多いですが、負荷の高いワークロードであれば、1:2になることもありますし、1:1のケースもあります。

VDIに関しては、一般的な環境では約1:8~1:10が一般的になりますが、こちらの数値は実際に各社のエンジニアでナレッジがありますので、もし各社の見積もりに開きがある場合はその観点かもしれません。

4.メモリの考慮について

f:id:t_komiya:20190407162258p:plain

 メモリに関する事項については、主に2点です。

一つはオーバーコミットについてです。VMwareをご存じの方はオーバーコミットなどを意識することがあるかと思いますが、NutanixのAHVについては現状メモリのオーバーコミットはないと考えてサイジングをお願いします。

また、CVMについてのメモリ容量も考慮しましょう。実際にNutanixのサポートポータルに載っている情報を記載しておりますが、こちらでVDIとサーバー仮想化で20GBがデフォルトで利用されると記載がありますが、実際の運用では20GBでもメモリが足りなくなるケースもあります。念のため、VDIやサーバー仮想化のワークロードでもCVMのメモリは28GBで定義しておくと良いでしょう。

5.機能毎のCVMの追加メモリ構成

f:id:t_komiya:20190407164650p:plain

Nutanixではストレージを有効活用するにあたり重複排除・圧縮機能やイレージャーコーディングなどがあります。この機能はCVMのリソースを消費しますので、その分をサイジングで考慮する必要があります。実際にストレージを容量効率を優先することも必要ですが、大容量でもない構成の場合には重複排除や圧縮などは利用しないほうがよいと思います。

6.SSDの考慮について

f:id:t_komiya:20190407165856p:plain

f:id:t_komiya:20190407165920p:plain

SSDについては、仮想マシンのデータの書き込みデータ用のキャッシュとして利用され、その後リモートのSSDにコピーされます。

また、SSDの階層は容量が75%を超えると、データをコールドティアのHDDにマイグレーションしてSSDの容量を75%以下にキープしようとします。

また、SSDに関しては、次のスライドで紹介しますが、以下のような構成になっています。

・Nutanix Home(CVMコア)

・Cassandra(メタデータストレージ)

・OpLog(持続書き込みバッファ)

・統合キャッシュ(SSDキャッシュ部分)

・エクステントストア(永続ストレージ)

f:id:t_komiya:20190407170559p:plain

ストレージとして最高のパフォーマンスを得るためにはSSDのサイジングは不可欠です。ここでは作業領域として必要領域をSSDの領域として確保することを記載しております。

 

注意:OpLogのサイズ変更は、AOSのリリース4.0.1の時点から動的に行われるようになりました。これにより、エクステントストア部分が動的に拡大することが可能になります。使用される値は完全に利用されたOpLogを仮定しています。例えば、OpLogの計算に使用される残りのGiBは、フォ​​ーマットされたSSD容量からNutanix HomeとCassandraが差し引かれた後になります。OpLogはすべてのSSDデバイスに配布されています。

可用性を確保するために、Nutanix Homeは最初の2つのSSD間でミラーリングされています。 5.0以降ではCassandraはノード内のSSD間でシャードされ(現在は最大4つ)、SSDあたり15GiBの初期に予約があります(メタデータの使用量が増えると一部のStargate SSDを利用できます)。デュアルSSDシステムでは、メタデータはSSD間でミラーリングされます。 SSDあたりのメタデータ予約は15GiBです(デュアルSSDの場合は30GiB、4本のSSDの場合は60GiB)

7.HDDの考慮について 

f:id:t_komiya:20190407170922p:plain

HDDについては、ストレージとしてのトータル容量になります。ここではReplication Factorにより容量が大きく変わるので要注意です。

また、お客様の要件によっては圧縮・重複排除を利用するか否かを判断する必要があります。

SSDおよびHDDの考慮点を全体的に言えることとしては、容量全体の閾値は約75%~80%でもっておくとよいでしょう。それ以上の容量で利用するとパフォーマンスが劣化することがありますので、その時はノード増設を行えるようにPrism側でアラート上げる設定を行っておく必要があります。

8.Storage Capacity Calculator

f:id:t_komiya:20190407171554p:plain

f:id:t_komiya:20190407171614p:plain

最後のNutanix Sizerで出力したデータを少し紹介します。

先ほどの章でお話したSSDの項目について、CVMのオーバーヘッドの内容でコメントをつけておきました。

 

是非ワークロードを意識してNutanixをサイジングしていくように心がけていきましょう。

 

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

マルチクラウドのDaaSプラットフォーム ~Nutanix Xi Frameについて~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。
本日はマルチクラウド環境でDaaSプラットフォームを実現するNutanix Xi Frameについてご説明したいと思います。
こちらは、HCIのプラットフォームとは違い、クラウドサービスの内容になります。そのため、提供形態は月額もしくは時間単位の課金になります。
まず、Xi Frameとはどのようなものか説明したいと思います。

Xi Frameは以下のようなものです。
ブラウザを使用して任意のデバイス上のユーザーに Windowsアプリケーションとデスクトップを配信する安全なクラウドプラットフォーム
今までのDaaSは提供するまでに、システムの構築・ワークロードの構築に時間がかかり、接続するPCの構成や利用者のマニュアルなどを作成したり構築までに非常に時間がかかります。また構築が終わったあとも起動時間が遅い、使い勝手が悪い、USBが使えない、アプリがインストールできないなど従来のPCで利用していたものに比べてユーザーエクスペリエンスが良いものではないケースもあります。
Xi Frameはブラウザを利用してクラウド上のデスクトップ環境を利用させることにより、セキュアで使い勝手の良いDaaS環境を実現しています。

1.なぜFrameが必要なのか?

f:id:t_komiya:20190404211232p:plain

従来型のHCI環境のVDI環境はNutanixの1クリックでデプロイできる環境(Calmなどを利用)が構築できますが、マルチクラウドの環境でそれができれば好きな時に好きな環境でデスクトップ環境が構築できるようになります。その最適なプラットフォームがXi Frameになります。(イメージを参照)
Xi Frameを利用してダッシュボードから1クリックでデスクトップ環境をできるようになります。
2.Nutanix Xi Frameの機能

f:id:t_komiya:20190330234642p:plain

Xi Frameの機能についてご説明します。HTML5やH.264などの言語やコーデックに対応しており、ブラウザも多種に対応しています。仮想デスクトップおよびアプリケーション仮想化にも対応しています。またクラウド上で対応しているかの話になりますが、GPUにも対応しており、AWSおよびAzureなどのクラウドにも対応しています。

f:id:t_komiya:20190330235350p:plain

f:id:t_komiya:20190331001424p:plain

ワークスペースの配信が1クリックで行うことができ管理がシンプルになっています。ブラウザアクセスで利用できることからクライアント側のプラットフォームに柔軟に対応できます。また、クラウドストレージサービスとの親和性も高く、Xiクラウドを含めパブリッククラウド上にデスクトップが展開できることが特徴です。
3.エンタープライズ対応のデスクトップとしてのサービス

f:id:t_komiya:20190330235659p:plain

マルチクラウドにデスクトップが展開できると言っても、セキュリティが担保されていなければ何も意味がありません。Xi Frameは簡素化した管理だけでなく、セキュリティ対応としてユーザー認証はもちろんのことSOC-2、FedRAMP、FIPSなどのセキュリティにも対応しています。こちらはあくまで米国基準のセキュリティであるため、日本での対応については、別途確認が必要になります。
4.オンデマンドでの容量のモニタリング・自動スケーリング

f:id:t_komiya:20190331000412p:plain

マルチクラウドでデスクトップを利用することは良いが、リソースの監視およびリソースのスケーリングはどうするのかと思うことがあります。Xi Frameは週次の利用率をモニタリングすることができます。また、オンプレミスのVDIなどではピーク時のトラフィックを見積もった上でシステムを構築する必要がありますが、Xi Frameの場合はその必要がありません。そのため、インフラを瞬時に拡張し時には縮小することが容易にできる柔軟性を備えております。
5.Frameの特徴

f:id:t_komiya:20190331001424p:plain

Xi FrameはマルチクラウドでDaaSを利用できるとお話しましたが、普通にRDPを利用してデスクトップを使用するとプロトコルのオーバーヘッドが大きくなり最適化したものではありません。Frameは元々ブラウザへのビデオストリーミングの開発を行っており、H.264ベースのコーデックに対応したQoSを提供して、WANおよび低帯域のネットワークにも対応できるようになっています。また、通常のPCで要求されるような要件(イメージを参照)にも数多く対応しています。
6.Frameが提供するデスクトップ管理の簡素化

f:id:t_komiya:20190331002319p:plain

Xi Frameを利用する際、どのようにシステム実現するか検討する必要があります。
1.インフラの選定(オンプレミス・クラウド)
2.利用するアプリケーション
3.ユーザーの認証方法
4.利用するファイルサーバー
5.利用する端末
これらの要件を決めていく必要がありますが、難しいシステム設定は必要ありません。クライアントの目線からデスクトップを利用することを考えればよいのです。
今までVDI導入でクラウドを利用することをためらっていた管理者もいらっしゃるかと思いますが、このXi Frameを利用することにより、ユーザーエクスペリエンスの高いDaaS環境を提供することができます。管理者はむしろクライアントの管理の方に目を向けてシステムの管理部分については、クラウドやXi Frameの機能で統合してみてはいかがでしょうか。

また、こちらのFrameはロケーションに関係なくストレスに利用できます。
実際に日本のNutanixのSEさんがFrameを新幹線の中で利用した動画がYoutubeにアップロードされておりますので、是非参考に見て頂ければと思います。

youtu.be


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

Nutanix Files 3.5 機能紹介

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

本日はNutanix Files 3.5の機能紹介をしたいと思います。

今回のFilesについては、いくつかの機能追加がされており、3TierストレージのNASと機能的には揃ってきましたが、マルチバイトの言語対応は未対応部分もあります。

では、機能の説明を行いたいと思います。

 

1.Nutanix Files 3.5の新機能

f:id:t_komiya:20190327224939p:plain

前回のFiles3.2のリリースでNFSv4が対応していましたが、今回はNFSv3が追加されました。またNFSについてもセルフサービスリストアがサポートされ、ファイルのリストアが簡単にできるようになりました。

変更ファイルのトラッキング(CFT)については、バックアップソフトウェア側の対応もありますので、すべてに利用できるものではありませんが、大容量のバックアップには非常に役立つ機能がサポートされています。

そのほかに暗号化対応とマルチバイト対応がありますが、こちらはAOSでの対応レベルの暗号化対応とNFSでのマルチバイトは現状未対応とのことです。

2. Nutanix Files 3.5の新機能 -Tech Preview-

f:id:t_komiya:20190327230019p:plain

次にTech Previewの機能についてご紹介いたします。

マルチプロトコルのサポート:こちらは一つのファイルをSMBおよびNFSの両方のプロトコルを利用してアクセスすることができる機能です。ただし、こちらはADを利用しない場合は管理者でユーザーマッピングする必要があるため注意が必要です。

Filesの利用状況の分析:こちらの機能はファイルサーバとしてユーザーの利用状況を監視するための機能になります。こちらの機能を有効すると分析データを保存するFSVMが新たにデプロイされます。主な内容としては、ユーザーとファイルの監査/利用状況を表示したダッシュボード/異常検知などが挙げられます。

3.Change File Tracking (CFT) の概要について

f:id:t_komiya:20190327231008p:plain

CFT(変更ファイルのトラッキング)については、ファイルの差分情報(スナップショット)を取得して、過去のスナップショットと現在のスナップショットの差分情報をファイルサーバーからデータを取得します。この時に、スナップショットの連携機能はあくまでバックアップソフトウェアとの互換性になりますので、対応ソフトウェアが必要となります。この対応によりバックアップウィンドウの削減で大きく貢献することになります。

.ファイル分析機能の概要について

f:id:t_komiya:20190327231439p:plain

f:id:t_komiya:20190327231506p:plain

機能紹介では一部しか説明しておりませんでしたが、主な内容はイメージの内容になります。利用状況を把握するためにPrismとの連携が必須になります。また異常アラートについてはポリシー設定も必要になります。画面イメージも合わせて載せておきます。

監査ログ機能は日本ではALOGなどがありますが、こちらのFilesにはオールインワンとしてくっついているイメージとなります。

.Files 3.5の仕様に関して

f:id:t_komiya:20190327232038p:plain

f:id:t_komiya:20190327232054p:plain

f:id:t_komiya:20190327232110p:plain

Files 3.5についての仕様をまとめております。AOSのバージョンについてはLTSの5.10.2が推奨バージョンになっているので安心して利用できます。また、FSVMは接続数によりスペックが異なりますので、十分注意して設定する必要があります。

また、容量や構成についてはライセンスにも関連するため、どのような用途で利用するのか?またアプライアンスモデル・認定ノード(Software Choice)などによっても異なります。(ライセンスに関しては今後記事で記載する予定です)

 

機能追加されたNutanix Files 3.5を是非ご利用してみてはいかがでしょうか。

 

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

Nutanixだけではない!SAP HANA対応のHCIプラットフォーム(vSAN)について

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

本日はSAP HANA対応のHCIプラットフォームについてお話したいと思います。

以前こちらのブログでもご紹介していますが、SAP HANA対応については記事についてはすべてNutanixに関する記事になっておりました。(詳細は以下のURLをご参照下さい)

 

 SAP環境にNutanixは最適なんです!~Nutanix Solution for SAP on Lenovo HX Series~ 

https://blog.hatena.ne.jp/SymphonyMarketing/symphonymarketing.hatenablog.com/edit?entry=10257846132607954181


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

https://blog.hatena.ne.jp/SymphonyMarketing/symphonymarketing.hatenablog.com/edit?entry=10257846132638025276

 

Lenovo ThinkAgile HX for SAP HANA アップデート情報

https://blog.hatena.ne.jp/SymphonyMarketing/symphonymarketing.hatenablog.com/edit?entry=10257846132680893218

 

今回紹介するのはVMwareのvSAN対応SAP HANAに関する記事を記載したいと思います。まず、VMwareのvSANにSAP HANAがいつ対応したのか?というお話になりますが、こちらについては2018年11月7日に発表されております。(詳細は以下のURLをご参照下さい)

https://blogs.vmware.com/virtualblocks/2018/10/18/vsan-sap-hana-production/

それでは、VMwareのvSANのSAP HANA対応についてお話します。

 

1.SAPアプリケーションとデータベースをシンプルに仮想化

f:id:t_komiya:20190318002137p:plain

SAP HANA対応についてVMwareとしては5年近く前からすでに対応はしていましたが、HCI環境についてはまだ対応しておりませんでした。vSANと緊密に連携したアーキテクチャが必要とされ、検証に長い年月が費やされてきました。また、業務の自動化およびクラウド対応など目まぐるしく変化する環境に対応するべく、SAPアプリケーションも対応が必要になってきました。今回は運用ビジネスの観点でvRealizeの必要性とSAPのランドスケープの対応にvSANのアーキテクチャが対応できたことが大きな要因となっており、これが実現されることにより、より優れたサービスレベルの維持、導入までの時間短縮、TCOの削減が実現可能となります。

2.vSAN環境でSAP HANAを実現すること

f:id:t_komiya:20190318002737p:plain

f:id:t_komiya:20190318003114p:plain

SAP HANAをvSAN環境で動作させるメリットとして、x86サーバー上でSAPのプラットフォームがすべて動作させることができることです。また、スケールアウトで拡張可能で仮想マシンごとにポリシー管理も可能です。(上記ではHDDと記載ありますが、構成上はオールフラッシュが前提の構成になります)

また、OEMベンダーごとに特有のHCI認定構成が提供可能なことも大きな特徴になります。

3.インメモリデータベースの性能をさらに強化させるデバイス

f:id:t_komiya:20190318003502p:plain

f:id:t_komiya:20190318003515p:plain

SAP HANAはインメモリデータベースになりますが、性能を向上させることについてはデバイス強化があります。vSphere 6.7では高速デバイスがサポートされており、今回はその中の一つでPersistent Memoryの対応があります。こちらは現状対応ベンダーが限られますが、このデバイスを利用することで(ワークロードにより)数百万IOPSのパフォーマンスを引き出すことも可能です。詳細はスライドをご覧ください。

4.LenovoのSAP HANA対応 for HCIプラットフォームについて

f:id:t_komiya:20190318003931p:plain

f:id:t_komiya:20190318004238p:plain

以前紹介したThinkAgileHX7820/HX7821についてはNutanixのプラットフォームでしたが、今回はThinkAgileVXのプラットフォームでのリリースとなります。Nutanixの時は4Uサーバーかつアプライアンス・認定ノードの両方のプラットフォームに対応しておりましたが、今回のvSAN対応については、ThinkAgile VX認定ノードのみの対応となり、CPUも2ソケットまでの対応になります。(2019年3月17日現在)

.LenovoのvSANプラットフォームで利用するメリットについて

f:id:t_komiya:20190318004405p:plain

f:id:t_komiya:20190318004451p:plain

メリットについては、vSANプラットフォームを選択する内容がほとんどになってしまいますが、SAPについてはLenovoはワールドワイドでの実績は豊富にあります。また、vSANと含めてサポートも切り分けて対応致します。

.SAP HANA for HCI(vSAN)を支えるテクノロジーとアーキテクチャ

f:id:t_komiya:20190318004821p:plain

f:id:t_komiya:20190318004839p:plain

こちらにテクノロジーとアーキテクチャを記載致します。

NutanixのSAP HANA対応については、AHV TurboなどのNutanix側のプラットフォームではI/O高速化技術が必要でしたが、VMwareについてはvSphere 6.5からNVMeの対応しておりましたし、今回のvSphere6.7についてはPersistent Memoryの高速アクセス可能なデバイスが対応済みとなっております。また、RDMAについても対応できており、vNUMAについても対応済みです。

アーキテクチャについては簡単ではありますが、スライドに記載しております。

 

引き続き情報がございましたら、アップデートさせて頂きます。

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

SMB向けモデルThinkAgile HX2320/HX2321と小規模向けのバックアップ付き構成について


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

本日はSMB(中小企業)向けにリリースされたThinkAgile HX2320/HX2321および小規模構成についての説明をしたいと思います。

今回製品説明だけではブログとしては内容は少ないため、小規模向けのバックアップ付きの構成について追加で説明したいと思います。

まず、ThinkAgile HX2320/HX2321に関してですがUS時間の2/20にリリースされています。(製品ガイドはもう少し前からあります)

https://lenovopress.com/lp1027-lenovo-thinkagile-hx2320-appliance 

日本では後日正式に製品発表予定となっております。

1.ThinkAgile HX2320 / HX2321に関してf:id:t_komiya:20190225142007p:plain

以前からレノボのNutanixのラインナップをご存じの方は”あれ?”と思うかもしれません。レノボでSMBモデルとしては今まではThinkAgile HX2320-E / HX2720-EのXpressのライセンスが搭載していた2機種が存在しておりました。今回Xpressライセンスがなくなり、新モデルとしてHX2320/HX2321のモデルがリリースされています。

2U4Nのフォームファクターがなくなり1Uモデルのみとなりましたが、今まで認定ノードにラインナップされていなかったモデルにようやく認定ノードモデルが追加されました。

それでは、今回リリースされたThinkAgileHX2320/HX2321についてもう少し内容を見ていきたいと思います。

f:id:t_komiya:20190225143010p:plain

ThinkAgileHX2320/HX2321についてはCPUも低スペックのCPU(Xeon Goldクラスまで)が選択可能になっています。また、HDDドライブについては3.5インチクラスのディスクが選択可能になっているため、パフォーマンスが低く容量が大きめのワークロードにちょうど良いため、バックオフィス系の用途に向いてます。

f:id:t_komiya:20190225143649p:plain

1か月ほど前にアプライアンスと認定ノードの紹介のスライドにおいて、認定ノードでSMBモデルが「該当モデル」という記載になっておりましたが、ようやく製品が発表されて全ラインナップが埋まりました。

是非こちらのモデルもご検討下さい。

 

2.小規模バックアップ構成に関して

小規模構成でデータのバックアップを行う構成を組む場合どのように組むのか悩むところだと思います。バックアップサーバを別で購入してバックアップサーバとして使用するのは良いがNutanix以外のクラスタを組まなければならないし、Nutanixのクラスタの中で管理しようとするともう一つ別のクラスタを用意する必要があります。

今まであまりお話をしておりませんでしたが、ThinkAgile HX1520-R/ThinkAgile HX1521-Rというレプリケーションターゲット用というモデルがございます。こちらを利用したバックアップ構成についてお話したいと思います。

f:id:t_komiya:20190225145631p:plain

 こちらのイメージを見て頂きたいのですが、SMBモデルのHX2320x3ノードでクラスタを構成します。そのバックアップ先としてHX1520-Rをシングルノードで構築します。この構成でバックアップをどのように取得するかということになりますが、NutanixのAsync DR(非同期DR)でそのまま設定してバックアップを取得することもできます。これであれば、Nutanixのライセンスの範囲内でバックアップが取得できますし、もちろんファイルレベルでもリストアは可能です。

ただし、この方法の場合はアプリケーションを特に意識したバックアップにはなっていないため、その点を考慮するとVeeamなどのサードパーティ製のバックアップソフトウェアなどを利用するのも良いと思います。Veeamを利用することで、バックアップソフトウェアの購入で費用はかかってしまうものの、例えばActive Directoryなどでユーザ単位でリストアしたり、データベースをテーブル単位でリストアすることも可能です。

 

3.2ノード構成に関して

f:id:t_komiya:20190225194857p:plain

以前の記事で2ノード構成のお話をしたかと思いますが、その2ノード構成についてはWitnessサーバーの存在が欠かせないことをお伝えしました。(詳細は以下のURLにて)

http://blog.lenovojp.com/entry/2018/05/06/020320

このWitnessサーバーを構築するノードを別に設ける必要があったのですが、これをバックアップターゲットで実現するのはどうでしょうか?実際にバックアップターゲットのノードにおいてたくさんの仮想マシンを動作させることは基本は想定されておりません。しかしながら、ThinkAgile HX1520-Rについては12コアまでCPUを選択可能になっていることから、CVM以外の仮想マシンをインストールすることは可能です。そのため、Witnessサーバーをインストールして、2ノードのクラスタを監視するように設定して、小規模構成も実現できます。

Nutanixで管理されていないノードを用意することなく、Nutanixの管理下ですべてが完結する構成も良いかと思います。

 

一度ご検討してみてはいかがでしょうか。

 

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

 

 

マルチクラウドにおけるアプリケーションの監視ソリューション~Xi Epochのご紹介~

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

本日はマルチクラウドにおけるアプリケーション監視ソリューションのXi Epochについてご紹介したいと思います。

こちらのソリューションですが、名称にXiとついていることからXi Cloudで提供されるSaaSソリューションになります。実際にどのようなソリューションなのか以下に説明致します。

1.Xi Epochは何をするもの?

f:id:t_komiya:20190216234645p:plain

Nutanixのソリューションでクラウド連携するソリューションは以前にもCalmやBeamをご紹介してきましたが、CalmやBeamやアプリケーション導入の自動化やマルチクラウドのコストの最適化・ガバナンスの統制を行うものとして利用するものでした。今回のEpochやクラウド上のアプリケーションにおける監視になりますが、すべてのアプリケーションが対象にしているわけではありません。

Nutanix社に買収される前はNetsil社としてサービスをしておりましたが、その当時からクラウドネイティブのアプリケーションをベースに監視ソリューションを提供しています。そもそも、どのような背景でこのソリューションが利用されているのかをスライド交えて説明したいと思います。

2.クラウドネイティブアプリケーションの出現

f:id:t_komiya:20190216235726p:plain

クラウドネイティブアプリケーションと言われる前は、アプリケーションはモノリシック(一枚岩)で、全体が一つのモジュールでできていました。クラウドネイティブの環境においてはアプリケーションが複数の言語に実行されていることから標準化もできないこと、コードレベルでサービス追加を行うことが非常に複雑でインスタンス毎にサービスの提供期間も異なり、それぞれの問題を切り分けるにも非常に困難な状況を生んでしまいます。それで、分散アーキテクチャの環境で実行されるアプリケーションを定期的に観察し、パフォーマンスを監視するソリューションが必要になります。似たような製品としてはDataDog、Sysdig、New Relic、AppDynamics(Cisco社が買収)やDynaTraceなどがあります。

3.Xi Epochができること?

f:id:t_komiya:20190217001929p:plain

Xi Epochはマルチクラウド上でアプリケーションを観察。監視を行うことができます。アプリケーションの監視については基本はエージェントレス(Credential情報を利用)で行います。監視内容はアプリケーションの健全性・レイテンシ・スループット・エラー率などを細かくシグナル表示します。

  • タグとトラフィック属性でホストとコンテナをフィルタリングしてグループ化することで、マップを作成および共有
  • サービスとその依存関係の検索と発見
  • すべての内部サービスと外部サービスの間のリアルタイムのトラフィックフローを監視
  • 展開前後の過去の行動を比較するためのタイムトラベル
  • Kubernetes(ポッドと名前空間)などのようなポピュラーなプラットフォーム用の箱から出してすぐに使えるマップ

f:id:t_komiya:20190217003522p:plain

Epochは使用言語やクラウド環境などの依存性を関係なくアプリケーションを可視化します。また、アプリケーションを定期的に観察することで、ボトルネックになっている情報を把握して原因究明を早めることができます。

  • 待ち時間、スループットなどの主要パフォーマンス指標は、API呼び出し、DBクエリー、DNSクエリーなどのためにサービスおよびそれらのリンクで利用可能
  • サービスとインフラストラクチャの完全なヘルスメトリックへのワンクリックドリルダウン
  • スロービュー、ハイデマンドAPIコールなどをソートおよび識別するためのテーブルビュー

4. Xi Epochのアーキテクチャ

f:id:t_komiya:20190217003643p:plain

Epochのアーキテクチャについてですが、実際にはアプリケーションが動作しているサーバーリソース監視、パフォーマンス監視、ネットワーク監視を同時に行っています。以前DPI(Deep Packet Inspection)は行っていないのではないかというコメントしたことがありますが、こちらを見る限りアプリケーション間の通信のパケットを解析することでボトルネックを究明できるアーキテクチャになっているようです。また、テレメトリなどの原因究明だけでなく将来予測などの機能も備えているようです。

DPIとテレメトリについては、過去の記事で紹介しておりますので、参考程度にご紹介します。

・DPIについて

blog.lenovojp.com

・テレメトリについ

blog.lenovojp.com

 5.Xi Epochのアプリケーションモニタリング

f:id:t_komiya:20190217004808p:plain

Xi Epochのアプリケーションモニタリングはアプリケーションを観察することで、障害の発生率の改善、迅速な根本原因分析を行います。一部のアプリケーションについては、メトリクスですべてのコンポーネントを監視できるようになっており、そのためナレッジも含めて包括的な監視ソリューションを提供できています。現在はJMX、NGINX、MySQLなどとの70以上のアプリケーション統合が実現できています。

そのほかにも、以下のようなことが可能です。

  • サービスインタラクションのパフォーマンスを監視するためのパケットキャプチャと分析
  • 暗号化されたトラフィックを観察するためにSSLSplitを利用する
  • ヒープサイズ、スレッド数、接続などのメトリクスについては、JMX、NGINX、MySQLなどとの70以上のアプリケーション統合
  • コードレベルの洞察のための、statsdを使用したカスタムメトリック
  • AWS RDSの待ち時間、DynamoDBクエリ、Route53検索でのDNSエラーなどの外部サービスとのやり取りパフォーマンス分析

6.Xi Epochのインフラモニタリング

f:id:t_komiya:20190217005736p:plain

Xi Epochはアプリケーションだけでなくインフラの監視を行います。仮想マシン・コンテナなども対象にしており、監視対象はCPU、メモリ、ディスクI/Oなども含まれます。

DBのモニタリングも行うことができます。よくある話として、SQL分などで必要以上のデータを引き出してしまって、分析の際のデータ量を多くして処理しているケースなどがある場合、適切なSQL分などに修正するなどのアドバイスなども必要になります。

迅速な回答を得るための強力なクエリ中心のインタフェースと低遅延クエリエンジンが備わっています。

  • メトリックスを調査および視覚化し、アラートまたはダッシュボードとして結果を保存するためのAnalytics Sandbox
  • ポッド名、ホスト名、またはHTTP URI、MySQLクエリタイプなどのプロトコル属性など、複数のディメンションからのデータを分析するための広範なフィルタとグループ化オプション
  • HTTP、MySQL、DNSなどの一般的なシステムすべて、およびKubernetesなどのフレームワーク用のすぐに使えるダッシュボード
  • 多次元からのデータをセグメント化して分析するためのチャートからの動的ドリルイン

7.Xi Epochの効果について

f:id:t_komiya:20190217010557p:plain

ノード・エッジ・KPIについてそれぞれ監視を行うことができるようになっており、マップ表示されることで、障害の原因究明を迅速化することができます。また、それぞれの項目についてナレッジを利用することで監視設定を簡素化していることもEpochを導入することも効果にもなります。

8.実際の表示画面について

f:id:t_komiya:20190217011421p:plain

事象発生前の画面と発生後の画面を合わせて載せていますが、マップ表示で赤くなっているところ、その周辺のエンティティに実際の遅延の数値が表示されます。実際にこれをクリックすることで原因も究明できるような仕組みなっています。

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