LTN Blog 〜 Lenovo Technology Network 〜

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

Nutanixが提供するオブジェクトストレージ ~Nutanix Bucketsの紹介~(その1)

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

こちらの内容ですが、以前にもこちらのブログで紹介していますが、内容が変更されているため、もう一度アップデートの意味で投稿しています。

以前の記事は以下のURLをご参照ください。

Nutanixのオブジェクトストレージのアーキテクチャについて - LTN Blog 〜 Lenovo Technology Network 〜

1.オブジェクトストレージの必要性について

f:id:t_komiya:20190422001044p:plain

技術の進化に伴い、スマートデバイス、センサー、ヘルスケアアプリケーション、カメラ、ボディカメラ、およびその他のデバイスによって収集されたデータは指数関数的に増加データを管理するために使用する方法も、データの保存、取得、処理が必要となる規模と速度の急激な増加に対応するために進化しています。

モノのインターネット(IoT)の継続的な進歩により、オブジェクトストレージは、マシン生成型でペタバイト規模の、継続的に増大するデータセットを迅速に格納および取得するための最良の方法の1つとして広く採用されるようになった

1.オブジェクトは本質的に不変であり、長期保存に理想的

2.オブジェクトのバージョン管理は変更を許可しますが、古いデータはそのまま残します(スナップショットのようなものです) 

3.オブジェクトストレージは容量に最適化されています。CPU/メモリ/フラッシュに関する制限された要件 ->高密度でコスト最適化されたプラットフォームを可能にします

4.丈夫でアクセスしやすい3rdプラットフォームのバックアップ(3-2-1 バックアップ)

5.複数拠点コラボレーションのためのグローバルネームスペース

6.標準のS3プロトコルで[ビルド] -> [テスト] -> [デプロイ] -> [スケール]を有効にします

 

2.ブロック、ファイル、オブジェクトの違い

f:id:t_komiya:20190511035741p:plain

ここでオブジェクトストレージの本来の定義をお話したいと思います。

そもそもオブジェクトストレージは、ファイルまたはブロックストレージとは異なり、オブジェクトストレージアーキテクチャモデルはデータを非構造化方式でオブジェクトとして扱います。このデータは、センサーデータ、写真、ログ、ビデオなど、どのような種類でもかまいません。

非構造化データは、ディレクトリ構造や従来のブロックを含まないフラットな階層構造に編成されたデータです。

このタイプのストレージアーキテクチャは、データを処理するときのアクセス性と速度が向上しています。これは、フォーマットの複数層によってもたらされる複雑さとオーバーヘッドを排除するためです。

各オブジェクトは、データ、そのメタデータ、およびオブジェクトを識別するために使用される固有のキーを含みます。

オブジェクトストレージで使用されるメタデータは、それが記述するオブジェクトに関するきめ細かい情報を含み、ライフサイクルの任意の時点でオブジェクトを管理および操作するときに柔軟性と制御性が向上するため、リッチメタデータと見なされます。ファイルシステムやリレーショナルデータベースなどの他のストレージソリューションには通常、より高レベルのメタデータがあり、そのデータを使用する高レベルアプリケーションでデータに関するコンテキスト情報の追加処理が行われます。

3.Nutanix Bucketsについて

f:id:t_komiya:20190511035916p:plain

Nutanix Bucketsでは、すべてがオブジェクト中心であり、オブジェクトのニーズを満たすために非常に柔軟になっています。

オブジェクトはバケット内に格納します。バケットは、何十億ものオブジェクトを格納できるストレージコンテナです。

これらのオブジェクトにアクセスするには、PUT、GET、DELETEなどの単純なHTTP REST API呼び出しを使用します。

Nutanix Bucketsは、AmazonのSimple Storage Service API(S3 API)と互換性があります。S3 APIは、広く知られており、AWSのアプリケーション以外で広く使用されています。

Nutanixは、このAPIをアクセスプロトコルとして採用し、Nutanixバケットに移行するときに既存のコードを変更する必要がほとんどないかまったくない、使い慣れたインターフェイスを開発者に提供します。

さらに、Bucketsにより、Nutanixプラットフォームのユーザは、高度にスケーラブルなハイパーコンバージドアーキテクチャの上に非構造化データを格納および管理できます。

クラウドホステッドソリューションと比較すると、このオンプレミスモデルは、オブジェクトの保存に関連するコストをより一貫した方法で管理し、それらのオブジェクトの場所に関する透明性を高めます。

f:id:t_komiya:20190511040034p:plain

Nutanix Bucketsの特徴として、シンプルなアーキテクチャでかつセキュアな環境を提供します。また、Nutanixの特徴でもあるスケールアウトにも対応しています。

NutanixのAOSの機能をフルに活用できるように、容量効率のも優れた機能を持ち、自己修復機能もサポートしています。

4.Nutanix Bucketsのアーキテクチャについて

f:id:t_komiya:20190511040404p:plain

先にもお話したようにNutanix BucketsはS3APIをサポートし、単一のグローバルネームスペースをサポートします。オブジェクトストレージを形成する部分については、K8Sベースのマイクロサービスで提供します。以前ご説明したオブジェクトストレージはOVSの仮想マシンが入っていましたが、今回はコンテナ化することで、とてもメモリ容量も小さくできるようなサービスで実現します。

 

 

次回のブログでアーキテクチャに触れていきたいと思います。

 

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

 

Nutanix .NEXT 2019 速報(その3)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は2019年5月7~9日の日程でアナハイムで開催中のNutanix .NEXT 2019のキーノートセッションでの内容(今回は第3編)をお伝えしたいと思います。

 

1.Xi Cloud サービスの追加とハイパーコンバージングクラウドへ

f:id:t_komiya:20190509163750j:plain

Xi Cloudサービスの追加としてTest Driveが新規リリースとなっております。

対応している内容としては以下のものになりますが、追って内容を紹介したいと思います。

 

①包括的なNutanixの機能
②GCPネイティブ
③エクスペリエンスXi Leap DR

 

f:id:t_komiya:20190509164339j:plain

今まではオンプレミスだけに使っていたハイパーコンバージドという言葉でしたが、今回からハイパーコンバージドクラウドという名称で利用することになります。インフラをクラウドを含めて1クリックでデプロイを実現できたりします。

f:id:t_komiya:20190509164629j:plain

オンプレの時にハイパーコンバージドと言っていたのは、コンピュート・ストレージ・ネットワーク・セキュリティなどを1つにまとめて管理することやData Mobility/App Mobilityの言葉の定義のように、仮想マシンなどをvMotionのようにホスト間でデータが途切れることなく移動できるようなことやアプリケーションを停止することなく移動することを考えられてきました。これを今後はクラウド間でも実現できるようにすることがハイパーコンバージドクラウドの意味でもあります。


2.クラウド間のApp Mobilityの実現

f:id:t_komiya:20190509170827j:plain

今までのマルチクラウド環境において、オンプレからクラウド環境への移行は難しいものでした。実際にクラウドに移行したのちやはりクラウド側での環境は適さない場合に再度オンプレミスに移行する場合は、クラウドへの移行以上に難しくなっていたり、料金もかさむことがあったりします。

f:id:t_komiya:20190509171146j:plain

それを解決するために、今回対応したものが、(App Mobilityを備えた)Nutanix Moveになります。こちらはCalmを利用して導入することになりますが、現状対応しているクラウドベンダーがAWSのみとなっております。f:id:t_komiya:20190509171438j:plain

こちらがCalmのBlueprintになりますが、WebサーバーやDBサーバーがAWSにデプロイされています。これをMoveを利用することで、クラウドからオンプレミスへのデータのマイグレーションが可能となります。f:id:t_komiya:20190509182518j:plain また、こちらはBeamを利用することでコストを可視化することができ、最適なクラウド環境を導き出すことができます。この結果を先ほどのMoveで移動させてしまうことで最終的にApp Mobilityも意識したハイパーコンバージドクラウド環境が作れるということになります。

 

f:id:t_komiya:20190509183007j:plain

f:id:t_komiya:20190509183335j:plain

現状のNutanixのハイパーコンバージドにおけるLocationとそのFootprintにおける対応についてはオンプレミスまでどどまっておりますが、今後はオンプレミスという環境が必ずお客様の環境である必要はないということが、先ほどのTestDriveの話であり、今回のTest DriveはGCP(Google Cloud Platform)内にオンプレミス的な環境を作ってしまいましょうということです。

 

ここで、GCPに関しては、昨年のロンドンでDR環境のNutanixが構築できる話がありましたが、今回はGCPだけにとどまらないのが、今回の.NEXTになります。

3.Nutanix on AWSの発表について

f:id:t_komiya:20190509183558j:plain

今回の発表として、Nutanix on AWSの対応がその大きな発表の一つになります。

f:id:t_komiya:20190509183829j:plain

こちらについては、AWSのEC2上にベアメタルのNutanix環境を作ることができます。VMware 社のVMware Cloud on AWSと構成は似ており、vSANの意味合いではストレッチクラスタに同様のことができます。(NSXなどを構成することはない)

f:id:t_komiya:20190509184041j:plain

f:id:t_komiya:20190509184103j:plain

特徴としては2つあり、シームレスは拡張として、ネットワーク環境はAWS Directコネクトを利用するか既存のVPCを利用して接続することができます。AWSを今まで通り利用している人はそのままの状態で利用できます。

もう一つは容量はオンデマンドで拡張できます。実際のデモにおいては、オンプレミスで構築したVDI環境をオンプレ上で拡張することはしないで、AWS上のNutanixでクラスタのノードを追加して、あたかもオンプレのように増設することができるようなものを実演しておりました。

f:id:t_komiya:20190509184652j:plain

f:id:t_komiya:20190509184715j:plain
そのほかにも、セキュリティをそのまま適用したConsistent Securityや開発用のワークロード向けにS3のストレージを拡張することもできるHibernateなどの紹介もありクラウドをうまく活用した使い方の紹介もありました。

f:id:t_komiya:20190509184949j:plain

f:id:t_komiya:20190509185008j:plain

f:id:t_komiya:20190509185201j:plain

また、AWSを利用しているユーザーが常にオンラインにしておくと課金されることが気になることがあります。そこで、通常はオンラインにすることなく、構成をResumeしておく機能やEC2のパブリックで利用している環境に直接アプリケーションのモビリティをサポートする機能も今回提供できるようになっています。

4.Nutanix のEnterpise Cloud Platform

f:id:t_komiya:20190509185507j:plain

f:id:t_komiya:20190509185526j:plain

今回の様々な発表により、NutanixのEnterprise Cloud Platformが変わってきます。

Extended Cloudの項目が今回追加されて、Nutanixが実行する環境はオンプレミスだけでなくXI Cloud以外のクラウド環境にも展開されています。Nutanixはどこに行っても使えますということがそろそろ言える時期が来たということになります。また、実行するアプリケーションについてもApp MobilityをGCPやAWSにも展開できるようなことになったことから、Nutanixが逆に標準プラットフォームとして導入しても悪くないような感じに思えた今回の.NEXTの発表内容だと思いました。

 

ご参考までに読んで頂ければと思います。

 

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

 

 

 

 

 


 

 

Nutanix .NEXT 2019 速報(その2)

 
皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は2019年5月7~9日の日程でアナハイムで開催中のNutanix .NEXT 2019のキーノートセッションでの内容(今回は第2編)をお伝えしたいと思います。
 
1.プラットフォームにHPE社の追加

f:id:t_komiya:20190509054744j:plain

登壇したのはHPE社のPhil Davis氏。今回のHPE社のプラットフォーム追加のメリットは何かという質問で、HPEのプラットフォームの信頼性やGreenLakeをベースとした、従量制課金での提供が挙げられます。Nutanixを提供していく上で、今後はオンプレ・オフプレをトータルで同一料金体系でできることのメリットをコメントしている。
2.プラットフォームのさらなる高速化

f:id:t_komiya:20190509055205j:plain

AOS5.11になり、システムの大容量化やプラットフォームの柔軟性に対応するために、様々な点で高速化のためにシステムを改良しています。

f:id:t_komiya:20190509063719j:plain

一つには、AES(Autonomous Extent Store)を導入することで、自律型のストレージにすることにより、従来のオールフラッシュ環境よりも最大2倍程度高速化を実現します。
.クラウドまでインビジブルに

f:id:t_komiya:20190509055857j:plain

今までのNutanixはプライベートクラウドの環境をインビジブルにすることで運用を簡素化してきましたが、今後はクラウドにもフォーカスを当てて1クリック化進めていきます。

f:id:t_komiya:20190509060053j:plain

Prism Pro : Ops
Calm : Automation
Files: Unstructured Data
Flow: Security
Era: Database Services
Xi Services: Cloud Services
上記のサービスを様々なロケーションやソリューションに対応することで、最大の価値の提供やお客様への最高の満足が提供できるようになります。今回Nutanixの各ソリューションにおける機能強化により、それが実現することができるようになります。
Nutanix Core / Essentialsについて

f:id:t_komiya:20190509060748j:plain

f:id:t_komiya:20190509063400j:plain

様々な機能が今までに機能強化してきましたが、今後も引き続き強化を続けていきます。AHVの導入の割合については、最新調査で40%になっています。最新のテクノロジーの対応としては、SAP HANAへの対応やOracle, PostgreSQLなどの対応(Era)だけでなく、データレークやAIなども挙げられます。それ以外にもMEDITECHへの対応などが最近のトレンドとして増えてきています。

f:id:t_komiya:20190509064105j:plain

また、コンテナ(Karbon)の対応などもあります。コンテナについてはDockerベースでの対応で当初考えられていたのが、kubernateベースに変わったことによりロードマップを急遽変えなければならない話がありましたが、こちらのソリューションを対応することにより、Nutanixのソリューションをマイクロサービスでの提供ができるようになりプロビジョニングが5分で終了し、自動化されたコンテナ環境ができる上に、統合管理を実現します。

f:id:t_komiya:20190509064606j:plain

f:id:t_komiya:20190509070206j:plain

Filesについては、従来のファイルサーバー機能に加えて、分析機能がTechPreviewでサポートしました。こちらにより、特定ユーザーのファイルアクセスなどのユーザー監査機能のサポート、ファイルの使用期間なども確認することができるようになっております。

f:id:t_komiya:20190509064648j:plain

 
オブジェクトストレージについてはS3準拠のAPIをサポートしており、現状でも12ノードで1PBを提供できるようなプラットフォームが提供可能です。
5Mine

f:id:t_komiya:20190509065407j:plain

f:id:t_komiya:20190509065931j:plain

f:id:t_komiya:20190509070300j:plain

f:id:t_komiya:20190509070350j:plain

今回の新規機能の一つにMineがあります。この機能はクラウドにおけるデータマネージメントを提供する機能になります。はじめはバックアップソフトウェアのVeeamとタイアップして1クリックでのデータ管理を実現します。製品で例えると、Cohesityのようなセカンダリストレージに近いものになります。この機能の開発には約1年の期間を要しています。これを利用することでアーカイブ機能なども提供できるようになり、Nutanixの中に格納されているすべてのデータを有効利用することができます。

.自律型データセンターの実現  

f:id:t_komiya:20190509073020j:plain今後データセンターに求められるもの、それは自動化よりも自律化になります。自動車なので、目的地まで自動的に移動して戻ってくるというものが出来上がっているように、データセンターでも自律型のソリューションが必要となってきております。ボトルネックになる前にまず手を打っておかなければならないこともあると思います。以前こちらのブログでも紹介したテレメトリ―などはその内容の一つだと思います。

f:id:t_komiya:20190509073136j:plain

f:id:t_komiya:20190509073556j:plain

それをNutanixでは、Calm/Flow + Beam Compliance/Prism Proのセットで実現します。
こちらのブログでも紹介しましたが、Beamではマルチクラウド上での最適化やガバナンスを管理するソリューションです。Flowで設定したセキュリティポリシーに準拠しない仮想マシンなどを可視化したり、必要に応じて隔離するなどの対策を施すことができます。(デモもありました) 

f:id:t_komiya:20190509094750j:plain

FlowベースでのEpochの可視化もできるようになっています。ADの統合もできていますし、開発環境から本番環境への移行にポリシー変更で移行できます。

f:id:t_komiya:20190509095048j:plain

f:id:t_komiya:20190509095142j:plain

もう一つの利用シーンとして、例えばデータベースを利用していてバッチ処理でリソースが高くなり、明らかにデータベースのリソースを追加しなければならないケースでPrism Proiでオペレーションの自動化として、X-Playが最新のAOSから対応できるようになっています。アプリケーションの監視も行うながら、トラブル対応も行う自律型のシステムにより、管理者がもっと楽になるようなシステムを提供できるようになりました。 

f:id:t_komiya:20190509095938j:plain

f:id:t_komiya:20190509100020j:plain



 
 
その3の内容でクラウド関連の内容をお伝えしたいと思います。
 
よろしくお願い致します。
 
 
 
 

Nutanix .NEXT 2019 速報(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は2019年5月7~9日の日程でアナハイムで開催中のNutanix .NEXT 2019のキーノートセッションでの内容をお伝えしたいと思います。

 

内容は多岐にわたるため、何回かに分けてお伝えいたします。

 

1.Nutanixは今年で10年目

f:id:t_komiya:20190509045230j:plain

今年で10周年を迎えるNutanixですが、まず初めにこの10年で古くからご利用のお客様が壇上に上がり10周年をお祝いをしていましたが、日本ではTISさんが壇上に上がられておりました。

f:id:t_komiya:20190509045535j:plain

f:id:t_komiya:20190509045854j:plain

この10年間を振り返る内容のTwitterやラボの風景が紹介されていました。さらに、10年もの間で、この時代はまだAOSのみで展開していた時期になります。3つのD(Data / Design / Delivery)が大きく変わったことを紹介していましたが、当時は3Tier構成からハイパーコンバージドへの変換で、仮想のワークロードをSANの環境からHCIへの変えていく活動を主にしていたのですが、システムの完成度は高くない状況でした。

f:id:t_komiya:20190509050125j:plain

またUIについても現状のものと比べると非常にシンプルなもので、今では当たり前の1クリックでのデプロイはまだまだ実現するレベルには至っていないとのことでした。

2.マルチハイパーバイザーをサポートしての用途が多くなってきた

f:id:t_komiya:20190509050508j:plain

今までVMwareのみでのサポートから、AHVやMicrosoftのハイパーバイザーのサポートをすることで、災害対策(DR)やデータ保護、メトロクラスタなどがサポートされて、特定の技術やロケーションに縛られることがなくなり、HCI市場が盛り上がるきっかけになっています。

f:id:t_komiya:20190509050804j:plain

f:id:t_komiya:20190509050850j:plain

2015年くらいからAHVやPrismが登場して今まで仮想のワークロードのみで動かしていたNutanixがEnterprise Cloudの変革になるきっかけがここから出てきており、コンピュートとストレージが一体化したものから、コンピュートのみでもNutanixを使えるようになったのがこの時期になっています。

f:id:t_komiya:20190509051151j:plain

この頃からNutanixの純正以外のメーカーでDELLやLenovoが出てきた時期になっています。

.オンプレミスだけでなくクラウドにも対応

f:id:t_komiya:20190509051342j:plain

2015年から2018年にかけてNutanixはアプリケーションの自動化やマルチクラウド対応を行ってきており、オンプレミスだけでなくオフプレミスにも対応してきました。

f:id:t_komiya:20190509051508j:plain

f:id:t_komiya:20190509051742j:plainマイクロセグメンテーションのようなことに数日間も作業に時間を取られるようなものではなく、Flowのように1クリックでシンプルでセキュリティポリシーも適用できるようなインフラのデプロイが実現されて、インフラの管理に時間をかけないもので価値を提供してきています。現在のEssentialsにあたるソリューションはまさにそのレイヤーをサポートしているものになっています。

.Enterpriseレベルのソリューションに関して

f:id:t_komiya:20190509052107j:plain

今後はAI/IoTなどの利用も含めて、格納されるデータも様々なものになってきており、従来の構造化されたデータのみではなく、非構造化データにも対応していく必要があります。そのため、今回オブジェクトストレージにあたるBucketsがリリースされました。実際には開発コンセプトを変更したこともあり、リリースに半年くらい遅れて出てきたものの、プラットフォームとしては、マイクロサービス化されたものとしてリリースされているようです。

f:id:t_komiya:20190509052528j:plain

CalmのBlueprintにおいても、作成したBlueprintをMarketplace上で共有できたり、エコシステムの対応も増えてきて、さらに使い勝手がよくなってきています。

f:id:t_komiya:20190509052649j:plain

UIの面については、Prismの画面の改良(AOS5.9以降)もありますが、DaaSプラットフォームのFrameなどはUIだけでなく、プラットフォームの改良も含めてのアナウンスがありました。

f:id:t_komiya:20190509052849j:plain

今回のFrameの対応については、NutanixのAHVへのプラットフォームの追加です。Nutanixのコンセプトは1クリックでの展開もさることながら、セキュアなVDI環境の提供やすぐに利用できるVDIサービスが売りになります。

f:id:t_komiya:20190509053359j:plain

今回の対応により、1クリックでのプロビジョニングだけでなく、新たなVDIの環境も2分程度でデプロイ可能なデモも実施されておりました。今回の発表されたFrameについては、本日から利用可能であり、購入すればもう一つセットでライセンスが付いてくる(1+1)ようです。

f:id:t_komiya:20190509053628j:plain

今後のNutanixの適用範囲について、データセンターが中心でビジネスをやってきていますが、今後はIoTなどの出現でEDGEコンピューティングにも対応していきます。また、ハードウェアについてもSoftware Choiceのモデルだけでなく、クラウド対応もあります。サービスの面においてもDRaaSだけでなく、今後はFaaS(Function as a Service)やOaaS(Operarions as a Service)に変わっていくようになります。

 

続きは続編の方で記載させて頂きます。

 

引き続きよろしくお願いします。

 

 

 

 

Nutanixにおけるハイパーバイザーの変換プロセスについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのハイパーバイザーの変換プロセスについてお話したいと思います。

NutanixでよくESXiからAHVへの変換ができるというコメントをこちらのブログでも紹介しておりますが、ハイパーバイザーを変換する際のプロセスがいくつかあるので覚えて頂ければと思います。

1.ESXi から AHVへの変換について

f:id:t_komiya:20190505232225p:plain

ESXiからAHVに変換する際、ノード1台ずつAHVに変換されますが、ESXiのホスト状態は一度保存してから変換します。コントローラVMが1台ずつESXiからAHVのマイグレーションを行います。AHVに変換後は手動で仮想マシンを起動します。ここで仮想マシンの変換について細かく説明したいと思います。

2.仮想マシンの変換

f:id:t_komiya:20190505232714p:plain

仮想マシンの変換にはNGT(Nutanix Guest Tools)が必要です。こちらを仮想マシン内にインストールしておきます。

詳細の説明は過去のブログのURLを記載しておきますので、ご参照下さい。

https://blog.lenovojp.com/entry/2018/11/10/172603

 

変換プロセスは4つの工程で行われます。

①検証

クラスタ内の仮想マシンが変換可能かどうか検証します。

②起動

変換を行います。変換のプロセスは記録されます。

③仮想マシン変換ためのノードを準備

ノード内の仮想マシンの情報はノードのUUIDに応じて収集され、仮想マシンが保護されているときには変換はできません。仮想マシンはマスター変換レコードに格納されていて、仮想マシンファイルは変更されません。

④仮想マシンの変換を実行

ノードの変換レコードを参照して、ハイパーバイザータイプを比較して、変換先のハイパーバイザーに変換します。仮想マシン変換後は仮想ネットワークなどもハイパーバイザーの情報に合わせて変換を行います。変換が完了すると変換元の仮想マシンファイルは削除されます。

 

3.ポートグループとVLANの変換 および AHVからESXiへの変換について

f:id:t_komiya:20190505233700p:plain

ESXiのポートグループやVLAN IDなどがすべてキャプチャされてAHV用に変換されます。対応するVLAN IDが割り当てわれて仮想マシンが正しい仮想ネットワークに転送されます。

ESXiからAHVへの変換だけでなく、その逆のAHVからESXiのプロセスもあります。こちらの変換するESXiのイメージが必要になりますのでご注意下さい。

.クラスタ変換作業の中止について

f:id:t_komiya:20190505234153p:plain

クラスタ変換作業も必ず成功するわけではありません。失敗してしまった時に戻せなくなるのではないかと心配する方もいらっしゃるかと思いますが、Nutanixの変換作業で失敗したときは失敗した内容のポップアップが表示されます。こちらで元の環境に戻すかどうか聞かれるので、「Yes」をクリックすると元の環境に戻すことが可能です。

 

ハイパーバイザーの変換は通常の変換作業以外にも、DR先にレプリケーションする時もクロスハイパーバイザーでDRするときも同様のことが行われます。

 

以上、参考情報として読んで頂ければと思います。

 

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

NutanixのVLANによる仮想ネットワークセグメントおよび構成変更不可のコンポーネントについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は2つの話題は1回の記事でご紹介したいと思います。

 

・VLANによる仮想ネットワークセグメント

構成変更不可のコンポーネント

 

Nutanixのネットワークを構成するときに重要なものはVLANです。VLANを利用した仮想ネットワークのセグメント化がわかっていないとネットワーク構成ができません。今回はAHVホスト・コントローラーVM・仮想NICに対しての割り当てについてお話したいと思います。

また、Nutanixの設定の中では変更不可の項目がいくつかございます。あらかじめ設定変更不可の項目を覚えておくと構築で困ることがないと思います。(現時点の情報です)

 

1.VLANによる仮想ネットワークセグメント

f:id:t_komiya:20190504231304p:plain

・AHVホストをVLANに割り当てる

AHVホストをVLANに割り当てるには、クラスタ内のすべてのAHVホストで次の手順を実行します。

1. SSHでAcropolisホストにログオンします

2. ポートbr0(デフォルトのOVSブリッジの内部ポート、br0)を、ホストにするVLANに割り当てます


root@ahv# ovs-vsctl set port br0 tag=host_vlan_tag

 

host_vlan_tagをホストのVLANタグに置き換えます

3. ポートbr0のVLANタギングを確認 root@ahv# ovs-vsctl list port br0

4. 表示されたタグパラメータの値を確認

5. pingテストを実行して、AHVホストのIPアドレスへの接続を確認します

 

コントローラVMのVLANへの割り当て

デフォルトではコントローラVMのパブリックインターフェイスはVLAN 0に 割り当てられています。

コントローラVMを別のVLANに割り当てるには、そのパブリックインターフェイスのVLAN IDを 変更します。変更後、新しいVLAN上にあるデバイスからパブリックインターフェイスにアクセスします。

 

注:コントローラVMへの接続が失われないようにするには、パブリックインターフェイスを 介してコントローラVMにログオンしているときにVLAN IDを変更しないでください。VLAN IDを変更するには、IPアドレス192.168.5.254を持つ内部インターフェイスにログオンします。

 

アクセスモードまたはトランクモードで動作するための仮想NICの設定

デフォルトではゲストVM上の仮想NICはアクセスモードで動作します。 このモードでは仮想NICは、それが接続されている仮想ネットワークのVLANである自分の VLAN上でのみトラフィックを送受信できます。アクセスモードインターフェイスの使用に 制限されている場合、複数のVLAN上でアプリケーションを実行している仮想マシン (ファイアウォールアプリケーションなど)は、複数の仮想NIC(各VLANに1つ)を使用する 必要があります。

アクセスモードで複数の仮想NICを設定する代わりに、トランクモードで動作するように 仮想マシン上に単一の仮想NICを設定できます。 トランクモードの仮想NICは、独自のVLANに加えて、任意の数のVLANを介してトラフィックを送受信できます。 特定のVLANをトランクすることも、すべてのVLANをトランクすることもできます。

仮想NICをトランクモードからアクセスモードに変換することもできます。

その場合、仮想NICは自身のVLAN上でのみトラフィックの送受信に戻ります。


2
.構成変更不可のコンポーネント

f:id:t_komiya:20190504232202p:plain

Nutanixソフトウェア

  • ローカルデータストア名
  • 名前や仮想ハードウェア構成を含む、任意のController VMの設定と内容(特定の機能を有効にするために必要な場合は、メモリを除く)

・AHV設定

  • インストールのパッケージを含むハイパーバイザーの設定
  • iSCSI設定
  • Open vSwitch設定
  • コントローラーVMのスナップショット取得

・ESXi設定

重要事項:vSphereのリソースプールを作成したら、NutanixのコントローラーVMは一番上の共有に配置しなければならない

  • NFS設定
  • VMスワップファイルのロケーション
  • VMの起動/シャットダウンの順番
  • iSCSIソフトウェアアダプタの設定
  • vSwitchNutanix 標準仮想スイッチ
  • 「管理ネットワーク」ポートグループ内のvmk0インターフェース
  • SSH enabled
  • ホストのファイアウォールポートが空いていること
  • コントローラーVMのスナップショット取得

・Hyper-V設定

  • 英語の言語パック
    現状、他の言語パックでのインストールがサポートがされていない
  • クラスタ名(ウェブコンソールを利用時)
  • ホスト名(ホスト名は、クラスタの拡張作成時にのみ設定できます)
  • 内部スイッチの設定と外部ネットワークアダプタ名

    Nutanixホスト上にExternalSwitchとInternalSwitchの2つの仮想スイッチが作成されます。
    これらの仮想スイッチに対応する2つの仮想アダプタ、vEthernet(ExternalSwitch)とvEthernet (InternalSwitch)がホスト上に作成されます。
    注:これらのスイッチとアダプタを削除したり、これらの仮想スイッチと仮想ネットワークアダプタの名前を変更したりしないでください

  • Windowsのロールと機能 Nutanixホストに新しいWindowsの役割や機能をインストールする必要はありません。これには特にマルチパスIO機能が含まれ、これによりNutanixストレージが使用できなくなる可能性があります。
  • 自動起動アクションのコントローラVM事前設定VM設定
  • コントローラVMの高可用性設定
  • コントローラVMの操作:コントローラVMの移行、状態の保存、またはチェックポイントの取得

参考情報までにチェックして頂ければ幸いです。

 

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

 

AHVのネットワーク設定について[第二弾]

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はAHVのネットワーク設定についてお話したいと思います。

以前にもこちらのトピックについてはお話しておりますが、前回は仮想スイッチのみのお話で終わってしまいましたので、今回は全般的なお話をしたいと思います。

前回の内容は以下のURLから確認ができます。

https://blog.lenovojp.com/entry/2018/09/09/162719

1.AHVのネットワーク概要

f:id:t_komiya:20190504130925p:plain

AHVはOpen vSwitchを利用してネットワークを構成します。OVS(Open vSwitchを略します)のサービスはそれぞれコンポーネントがありますのでそれぞれ説明したいと思います。

.Open vSwitch

f:id:t_komiya:20190504131316p:plain

Open vSwitchはLinuxカーネルで実装されており、マルチサーバーの環境環境で動作するように設計されております。OVSはMACアドレスを学習してテーブル管理しております。ハイパーバイザーと仮想マシンはスイッチの仮想ポートに接続します。各ハイパーバイザーはOVSインスタンスをホストして、すべてのOVSインスタンスが組み合わさって単一のスイッチを形成しています。(以前のブログで紹介した内容がこちらになります)

 

.ブリッジ

ブリッジは、物理インターフェイスと仮想インターフェイス間のネットワークトラフィックを管理するための仮想スイッチとして機能します。

デフォルトのAHV構成には、br0というOVSブリッジとvirbr0というネイティブLinuxブリッジが含まれています。

virbr0 Linuxブリッジは、CVMとAHVホスト間の管理通信専用に使用されます。他のすべてのストレージ、ホスト、およびVMネットワークトラフィックは、br0 OVSブリッジを通過します。

AHVホスト、仮想マシン、および物理インターフェイスは、ブリッジへの接続に「ポート」を使用します。

 

.ボンド

ボンドポートはAHVホストの物理インターフェースにNICチーミングを提供します。

デフォルトでは、bond0という名前のbondがブリッジbr0に作成されます。ノードイメージングプロセスの後、すべてのインターフェースは単一のBond内に配置されます。これはFoundationイメージングプロセスの要件です。

デフォルトの設定は、初期の展開時にbond0から1ギガビットポートを削除するように変更する必要があります。10ギガビットポートだけが残ります。 Open vSwitchボンディングでは、アクティブバックアップ、balance-slb、balance-tcpなど、いくつかの負荷分散モードが可能。

リンクアグリゲーション制御プロトコル(LACP)もボンドに対してアクティブにできます。 "bond_mode"設定はインストール中に指定されないため、デフォルトでactive-backupになります。

f:id:t_komiya:20190504131936p:plain

5.IPアドレス管理(IPAM)

ネットワークの作成とVLAN管理に加えて、AcropolisはDHCPを使用して仮想マシンへの IPアドレスもサポートします。

各仮想ネットワークと関連VLANは、特定のIPサブセット、関連ドメイン設定、および割り当てに使用可能なIPアドレスプールのグループを使用して設定できます。 Acropolisは、設定されたIPアドレスプールと設定が使用されるように、OVSのVXLANとOpenFlowルールを使用してユーザーVMからのDHCP要求を傍受します。

管理者はAcropolisとIPAMを使用して統合されたPrismインターフェースからネットワーク管理を含む完全な仮想化導入を実現できます。これにより、仮想マシンのプロビジョニングと ネットワークアドレスの割り当てに関連する従来の複雑なネットワーク管理が大幅に 簡素化されます。 IPAM機能を有効にしてアドレスの重複を回避する前に、必ずネットワーク チームと協力して仮想マシンのアドレス範囲を逆にしてください。

管理対象VMのNICが作成されると、IPアドレスがアドレスプールから割り当てられます。 VM NICまたはVMが削除されるまで、アドレスはプールに解放されません。

.ネットワーク設定におけるベストプラクティス

f:id:t_komiya:20190504132307p:plain

ベストプラクティス内容については、AHVのネットワークの内容における注意点ではありますが、必ずしもこれを満たさなければ接続できないわけではなく、ベストケースであることをあらかじめご了承ください。

OVSブリッジのOpenFlowテーブルは変更しないでください。

1GbEおよび10GbEについてはそれぞれのインタフェースの注意事項がイメージに記載しております。VLANについてもデフォルトで設定されているものもありますので、注意しながら変更して下さい。 

f:id:t_komiya:20190504132354p:plain

上位のネットワークスイッチについては、基本はノンブロッキングがおススメです。諸条件はイメージ内に記載しておりますので、ご覧ください。 

IPMIインタフェースはトランクしないでください。

f:id:t_komiya:20190504132433p:plain

CVMについては設定は削除していけないものがありますのでご注意下さい。OVSのボンディングについては10GbEで設定をお願いします。

 

AHVのネットワークを設定する前に是非注意事項として覚えて頂ければ幸いです。

 

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

 

Nutanixのストレージ設定について~Erasure Coding / Compression / Deduplication~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのストレージに関して説明したいと思います。

 

Nutanix Enterprise Cloud Platformには、あらゆるワークロードで利用可能な容量を効率的に利用するために連携して機能する、幅広いストレージ最適化テクノロジが組み込まれています。 これらのテクノロジはインテリジェントでワークロードの特性に対応しているため、手動による設定や微調整が不要です。

以下のストレージ最適化手法を活用できます。

  • イレージャーコーディング(Erasure Coding):
    クラスタの有効容量または使用可能容量を増やします。Erasure Codingを有効にした後に生じる容量削減は、圧縮および重複排除の容量削減に追加されます
  • 圧縮(Compression):
    2種類の圧縮のうちの1つを可能にするオプションのコンテナ設定・ポストプロセスの圧縮:データは書き込まれた後に圧縮されます・インラインの圧縮:データが書き込まれる際に圧縮されます

  • 重複排除(Deduplication):
    パフォーマンスを向上させるためのプレミアム層(RAMとフラッシュ)、またはストレージスペースの節約のための容量層(HDD)での同一のゲスト仮想マシンデータの共有。コンテナーまたはvDiskのプロパティによって有効になります

それでは、各設定についてイメージで説明したいと思います。

 

1.イレージャーコーディング

f:id:t_komiya:20190505114726p:plain

 今回の構成は6ノードで4つのデータブロックをRF2の構成時のイレージャーコーディングの説明になります。一言で言いますと、ノードをディスクに見立ててRAIDを構成するイメージになります。通常はミラー構成なので容量は半分になりますが、イレージャーコーディングは約70%程度効率が上がります。ノード数が増えるほど、容量効率が上がるような仕組みになります。

まず、RF2なのでクラスタ内に2つのデータコピーが維持されます。

f:id:t_komiya:20190505114746p:plain

4つのデータが6つのノードに格納されますが、赤字がそのイメージだと思って頂ければと思います。

f:id:t_komiya:20190505114801p:plain

ノードを保護するためにパリティを配置して、一つのノードがダウンしてもデータを再調整行われるようになっています。詳細はイメージをご参照ください。

f:id:t_komiya:20190505114820p:plain



こちらの図はノードが一台障害があった場合の動作になります。CのデータがPを利用してもう一つ別のノードで再調整されてデータが配置されます。

ノード数が多い場合には、この方式が大変有効になります。

 

.圧縮(Compression)

コンテナは圧縮を有効にできます。 Snappy圧縮ライブラリを使用した書き込み操作中または 書き込み操作後にデータの圧縮が行われます。 Nutanixによるテストでは、ディスクスペース 使用量の約30%の削減が示されていますが、実際のディスクスペース使用量の削減は環境ごとに異なります。

 

次の種類の圧縮が利用可能です

  • ポストプロセスの圧縮:データは書き込まれた後に圧縮されます
    書き込みと圧縮の間の遅延時間は設定可能です。
    ワークロードごとに異なるI/Oプロファイルが あるため、Nutanixに推奨される遅延値はありません。
    このタイプの圧縮は、ほとんどのワークロードにお勧めです
  • インラインの圧縮:データが書き込まれる際に圧縮されます
    このタイプの圧縮は、バッチ処理を実行するほとんどのワークロードに推奨

f:id:t_komiya:20190503185920p:plain

圧縮については、ワークロードにより適しているものがあるため、ケースによって使い分けることが良いでしょう。

 

.重複排除(Deduplication)
f:id:t_komiya:20190503190206p:plain

重複排除については、リードキャッシュ用の重複排除と容量削減用の重複排除の二つがあります。どちらの機能を利用するかは、購入するエディションにも依存するので注意してください。

さらに、重複排除が有効になっているクラスター内のコントローラーVMは、追加のRAMで構成する必要があります。

・キャッシュ重複排除:24GB RAM

・容量重複排除:32GB RAM

f:id:t_komiya:20190503190448p:plain

重複排除についてもベストプラクティスがあります。データの特性やワークロードにより、使用しても意味がない場合がありますので、十分に注意して利用してください。

 

ストレージ機能としては当たり前のようにサポートしている機能ですが、どのようなもので利用するのかを含めて、最適なストレージの設定を行うようにして頂ければと思います。

 

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

 

 

 

Nutanixの分散ストレージファブリック(Distributed Storage Fabric)について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixの分散ストレージファブリック(Distributed Storage Fabric)についてご説明します。前回のブログでDSFについては一部説明はしているものの、詳細の説明については今回のブログでお話したいと思います。

 

1.分散ストレージファブリック(Distributed Storage Fabric)について

Nutanix Acropolis DSF(Distributed Storage Fabric)は、同じホスト上のローカルVMに ストレージリソースを提供することで、ゲストVMのパフォーマンスを向上させます。この方法により、ローカルストレージコントローラ(Nutanixノードごとに1つ)は、同じ物理ノード上で実行されている仮想マシンによって行われたI/O要求の処理にリソースを割り当てることが できます。クラスタ内で実行されている他のコントローラは、自分のローカルゲストVMに よって行われたI/O要求を自由に処理できます。このアーキテクチャは、リモートストレージ コントローラとネットワーク(SANまたはNAS)全体に配置されたリソースを持つ従来の ストレージアレイとは対照的です。

Nutanixアーキテクチャには、いくつかの重要なパフォーマンス上の利点があります。まず、 ストレージリソースはローカルであるため、各要求はネットワークを通過しません。これにより、I/Oパスから物理ネットワークが排除されるため、待ち時間が大幅に短縮されます。さらに、 各ホスト(またはNutanixノード)には独自の仮想ストレージコントローラ(CVM)があるため、共有ストレージアーキテクチャで一般的なストレージのボトルネックが解消されます。新しいNutanixノードをクラスタに追加すると、CVMも同じ割合で追加され、予測可能でスケーラブル、そしてリニアなパフォーマンスを提供します。スケールアウトアーキテクチャにより、予測可能な高いストレージパフォーマンスが可能になります。

 

2.ストレージのコンポーネント

f:id:t_komiya:20190502234719p:plain

ここで、各コンポーネントについての説明をしたいと思います。(一部前回内容と重複しますが)

・ストレージティア

ストレージティアは利用可能な物理ストレージの種類を定義します。 Webコンソールから、ストレージプール内のディスクの階層の内訳を判断できます。

・ストレージプール

ストレージプールは1つ以上の層からの物理ディスクのグループです。 ストレージデバイスは一度に1つのストレージプールにしか割り当てることができないため、ストレージプールは仮想マシン間の物理的な分離を提供します。 Nutanixはクラスタ内のすべてのディスクを保持するために単一のストレージプールを作成することをお勧めします。 ほとんどのユースケースをサポートするこの構成により、クラスターは容量やIOPSなどのリソースの分配を動的に最適化できます。 ディスクを別々のストレージプールに分離すると、仮想マシン間の物理的な分離が可能になりますが、ディスクがアクティブに使用されていない場合は、これらのリソースが均衡にならない可能性もあります。 新しいノードを追加してクラスタを拡張すると、新しいディスクも既存のストレージプールに追加できます。このスケールアウトアーキテクチャにより、ニーズに合わせて成長するクラスタを構築できます。

・ストレージコンテナ

ストレージコンテナはストレージプール内の使用可能なストレージのサブセットです。 ストレージコンテナは仮想マシンによって使用される仮想ディスク(vDisk)を保持します。 新しいストレージコンテナのストレージプールを選択すると、vDiskが格納されている物理ディスクが定義されます。 Nutanixクラスター内のノードはNFSデータストア(vSphere)、SMB共有(Hyper-V)、またはiSCSIターゲット(vSphereまたはAHV)としてストレージコンテナをマウントして、仮想マシンファイル用の共有ストレージを提供できます。

このストレージはシンプロビジョニングされます。つまり、ストレージコンテナの作成時に合計最大容量を割り当てるのではなく、データが書き込まれるときに必要に応じてストレージがストレージコンテナに割り当てられます。 ストレージコンテナレベルでのオプションの1つは、(書き込まれているとおりに)インラインで、または書き込まれた後に圧縮を有効にすることです。

・ボリュームグループ

ボリュームグループは論理的に関連する仮想ディスク(またはボリューム)の集まりです。ボリュームグループはボリュームグループ内のディスクを共有する1つ以上の実行コンテキスト(仮想マシンまたは他のiSCSIイニシエータ)にアタッチされています。ボリュームグループをファーストクラスのエンティティとして管理できます。 1つ以上の実行コンテキスト、それらを障害回復ポリシーに含め、他の管理タスクを実行します。ボリュームグループを現在の実行コンテキストからデタッチして、同じアプリケーションのインスタンスを実行している別の実行コンテキストにアタッチすることもできます。これは、おそらくボリュームの複製先のリモートの場所にあります。

ボリュームグループは1つの単位として管理できます。 iSCSIターゲットとしてボリュームグループ全体をアタッチし、ボリュームグループ全体をデタッチします。
ただし、ボリュームグループ内のディスクのサイズを変更することはできます。

各ボリュームグループは、UUID、名前、およびiSCSIターゲット名によって識別されます。ボリュームグループ内の各ディスクには、UUIDと、ボリュームグループ内の順序を指定するLUN番号もあります。ボリュームグループは、排他アクセスまたは共有アクセスのどちらにも構成できます。

バックアップ、保護、復元(インプレース復元とアウトオブプレース復元)、およびボリュームグループの移行ができます。非同期データ複製(Async DR)用に構成された保護ドメインに、排他的にまたは仮想マシンと一緒にボリュームグループを含めることができます。ただし、メトロアベイラビリティに構成された保護ドメイン、保護されたvStore、またはアプリケーション整合性スナップショット作成が有効になっている整合性グループにボリュームグループを含めることはできません。

・vDisks

vDiskは仮想マシンにストレージを提供するストレージコンテナ内の使用可能なストレージのサブセットです。

ストレージコンテナーがNFSボリュームとしてマウントされている場合、そのストレージコンテナー内のvDiskの作成と管理はクラスターによって自動的に処理されます。

 

データストアについては、以下でイメージと併せてご説明します。

 

3.データストア/SMB共有

f:id:t_komiya:20190503000128p:plain vSphereで利用する場合はNFSもしくはiSCSIで提供されますが、通常利用するのはNFSの方が多いと思います。データをホストにローカライズすることでネットワークでのより取りを削減します。(データローカリティ)

ESXでNutanixコンテナを正しくマップするときは水色の内容に注意してください。

f:id:t_komiya:20190503000647p:plain

Hyper-V環境ではSMB共有でマウントします。基本的にはハイパーバイザーに最適なプロトコルをNutanixとして推奨しております。

f:id:t_komiya:20190503000848p:plain

前回のブログでも載せておりましたが、画面イメージをもう一度載せておきます。

ストレージのダッシュボードより、DSFに関する情報を確認することができます。

 

次回はストレージの設定についてご説明する予定です。

 

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

 

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の構成要素の説明を終わります。

 

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