LTN Blog 〜 Lenovo Technology Network 〜

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

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

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

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

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

f:id:t_komiya:20190715012214p:plain

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

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

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

f:id:t_komiya:20190715012735p:plain

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

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

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

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

f:id:t_komiya:20190715013154p:plain

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

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

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

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

f:id:t_komiya:20190715162344p:plain

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

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

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

 

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

 

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

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

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

 

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

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

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

f:id:t_komiya:20190715162947p:plain

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

 

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

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

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

f:id:t_komiya:20190715163627p:plain

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

 

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

 

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

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

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

 

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

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

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

f:id:t_komiya:20190714002426p:plain

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

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

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

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

 

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

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

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

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

f:id:t_komiya:20190714003809p:plain

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

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

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

3.nCLIのインストール

f:id:t_komiya:20190714003921p:plain

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


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


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

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

f:id:t_komiya:20190714004333p:plain

 

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

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

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

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

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

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

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

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

 

 

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

f:id:t_komiya:20190714004503p:plain

f:id:t_komiya:20190714004602p:plain

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

Acropolis Command-Line Interface (aCLI)

f:id:t_komiya:20190714004702p:plain

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

Acropolis CLIへのアクセス

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

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

PowerShell Cmdlets

f:id:t_komiya:20190714004905p:plain

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

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

PowerShell Cmdletsのインストール

利用する

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

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

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

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

PowerShell Cmdletsの使用方法

f:id:t_komiya:20190714005025p:plain

クラスタ接続について

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

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

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

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

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

 

接続クラスタ情報

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

 

Cmdletsバージョン情報

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

 

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

 

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

 

 

Prism Proに関して理解してみよう!(その2)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はPrism Proの2回目を投稿致します。

 

前回紹介できなかった内容について、今回ご説明していきたいと思います。

・リソースが無駄な仮想マシンを見つけて適切なリソースに(今回追加)

ジャストインタイム予測

・複数クラスタのアップグレード(今回追加)

 

リソースが無駄な仮想マシンを見つけて適切なリソースに・・・という内容を説明する前に、実際に利用している仮想環境がどうなっているのか・・・を把握していない人もいらっしゃるかと思います。

実際に、仮想マシンにリソースを割り当てているが、本当に予想通りに動いているのか?どうかは常に監視していないとわからないものです。そんな無秩序な仮想マシン環境をイメージで説明したいと思います。

f:id:t_komiya:20190707000952p:plain

f:id:t_komiya:20190707001032p:plain

例を3つほど上げておりますが、まず最初にある例として、アプリベンダーさんからアプリスペックに応じてリソースが指定されて設定したけれど、実際に指定されたリソース通りに動いていないものがあるような場合や、1つのアプリケーションが大きくリソースを利用して、他のアプリに影響を与えているケース、あとは他の部門が利用したリソースがちゃんと開放されていない状況なども考えられます。これを監視して、正しいリソース配分にするためのRecommendationするのが、NutanixでいうPrism Proに当たります。以下はその内容の説明と、過去に私が投稿した記事も参考に載せておりますので、ご覧いただければと思います。

 

6.リソースが無駄な仮想マシンを見つけて適切なリソースに

f:id:t_komiya:20190707002332p:plain

仮想化環境では、リソースはグローバルに、またはVMごとに制約を受ける可能性があります。管理者は、容量を追加 するか既存のリソースを回収することによってリソースをスケールアウトすることで、グローバルな容量の制約に対処 できます。Prism ProのVM効率機能では、未使用のリソースを回収してクラスターに戻すことができる候補となる環境内のVMをお勧めします。個々のVMは、要求を満たすのに十分なリソースがない場合にも制約を受ける可能性があります。

Prism Proは、ウィジェット内でVM効率の候補として識別されたVMを提示し、効率データを識別しやすいように4つの 異なるカテゴリーに分割します。オーバープロビジョニング、非アクティブ、制約、および極度にリソースを利用する 仮想マシンの存在です。過剰にプロビジョニングされたカテゴリと非アクティブなカテゴリは、各VMから回収できる 潜在的なリソースの量の概要を提供します。

 

こちらに関しては、以下のURLにある情報が参考になるかもしれませんので、合わせてご参照ください。

thwack.solarwinds.com

 

キャパシティプランニング

f:id:t_komiya:20190706001344p:plain

キャパシティランウェイ機能は顧客が何日分のリソースを残したかを理解するのに役立ちます。ランウェイの日数を延ばす準備をしたい場合、または既存のワークロードを拡張したり新しいワークロードを クラスターに追加したりすることがリソースに与える影響を調査したい場合は、キャパシティプランニング機能が役立ちます。

十分なリソースを取り戻すことができないとき、または組織が全体的な環境を拡張する必要があるときは、キャパシティプランニング機能はノードベースの推奨を行うことができます。これらのノードの推奨事項は、消費率と成長を考慮し、目標のランウェイ期間を満たすためにX-FITデータを使用します。ランウェイの 期間が180日に設定されている場合、Prism Proは要求された180日のキャパシティを提供するために スケーリングに推奨されるノードの数、タイプ、および構成を計算します。

.ジャストインタイム予測

Prism Proのキャパシティプランニングの一部として、新しいワークロードをクラスターに追加し、

それらの新しいワークロードがキャパシティに与える影響をモデル化できます。クラスター容量の拡張は、既存および将来のアプリケーションが楽しい経験を享受できるようにするための重要な運用機能

です。組織は即興の計算と推測に基づいて、レガシー環境でこれらのスケーリング決定してきました。

Prism Proを使用すると、Nutanix Enterprise Cloudは、容量計画を通知するために、Sizer アプリケーションを通じて時間をかけて慎重にキュレーションされたX-FITおよびワークロードモデルのデータを使用します。ワークロード追加機能を使用すると、キャパシティプランニングにさまざまなアプリケーションを追加できます。

使用可能なワークロードプランニングオプションは以下のとおりです

  • SQL Server:さまざまなワークロードサイズとデータベースの種類に基づいてデータベースワークロードのサイズを決定
  • VM:モデル化対象の汎用VMサイズを手動で指定するか、または増加するクラスター上の既存のVMを選択できます。
  • VDI:ブローカーテクノロジ、プロビジョニング方法、ユーザーの種類、およびユーザー数を選択するための オプションを提供
  • Splunk:1日のインデックスサイズ、ホットリテンションタイムとコールドリテンションタイム、検索ユーザー数に基づくサイズ
  • XenApp:VDIと同様で、ブローカーの種類、サーバーのOS、プロビジョニングの種類、および同時ユーザー数のデータポイントを使用した、サイズに基づくサーバーベースのコンピューティング

f:id:t_komiya:20190706001529p:plain

ワークロードをクラスターに追加することを計画するには、クラスターを選択してワークロードの追加を選択します。ダイアログボックス上部のドロップダウンメニューからワークロードを選択し、それに 関する特定のデータポイントを完成させます。ワークロードの特性を指定したら、それをクラスタに追加する日付を入力して[ワークロード追加]をクリックします。(図1)

モデリングのためにクラスターにワークロードを追加すると、計画機能はその追加を反映するように クラスターランウェイを調整します。新しいワークロードを追加するために入力した日付によっては、 ランウェイの時間がすぐに短くなることがあります。目標ランウェイに合わせて調整するために、Prism Proはシナリオ用の追加ノードを推奨します。(図2)

 

複数クラスタのアップグレード

Nutanixクラスタのアップグレードは、長い間ワンクリックでアップグレードできる楽しい経験でした。ワンクリックプロセスでは、高度な自動化と消費者レベルのデザインエクスペリエンスを使用することで、非常に複雑な作業を隠しています。歴史的に、各クラスタは一度に1つずつアップグレードする必要がありました。プロセス自体は簡単でしたが、この制約により、マルチクラスター環境のアップグレードを完了するのに必要な時間がさらに長くなりました。

Prism Proは、1つのPrism Centralインスタンスから複数のクラスターをアップグレードする機能を提供します。この機能を使用して、管理者は複数のクラスタを選択し、利用可能なソフトウェアバージョンを選択し、それらのクラスタにアップグレードをプッシュできます。選択した複数のクラスターがすべて1つのアップグレードグループ内にある場合は、それらのクラスターに対してプロセスを順次実行するか並列に実行するかを決定できます。

この一元的なアップグレード方法では、アップグレードと同時にステータスとアラートを監視できる単一のポイントが提供されます。現在、複数のクラスタアップグレードはAOSソフトウェアでのみ利用可能です。ハイパーバイザーとファームウェアのアップグレードは、クラスターレベルでワンクリックで実行されます。

 

Prism Proを導入して最適かつ使いやすい仮想インフラ環境にしましょう!

 

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

 

Prism Proに関して理解してみよう!(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は1年ぶりにPrism Proのお話をしたいと思います。(内容については2回に分けてご紹介します)

前回Prism Proを取り上げた際は、Prism Centralと合わせてお話したこともあり、Prism Proの機能にフォーカスした紹介ができなかったこともあり、今回は前回お話できなかったことを内容に盛り込みたいと思います。

blog.lenovojp.com

 

また、Prism Proについては5月の.NEXT においてもIntelligent Opmizationで今後機能として盛り込まれるものありますので、是非注目しておく必要があるかと思います。

blog.lenovojp.com

1.Prism Proでできること

f:id:t_komiya:20190705234119p:plain

前回の紹介時は以下の内容をPrism Proでできるとご紹介しましたが、それ以外にも対応している機能があります。

・キャパシティプランニングと将来予測

・ジャストインタイム予測

・カスタマイズ可能なダッシュボード

・実行可能な結果で検索

・レポート機能(今回追加)

・動的モニタリング(今回追加)

・リソースが無駄な仮想マシンを見つけて適切なリソースに(今回追加)

・複数クラスタのアップグレード(今回追加)

今回は画面イメージも含めてご紹介します。

2.Prism Proについて

Prism Proは、Nutanix環境を管理するための高度な分析とインテリジェントな洞察を提供する一連の 機能です。これらの機能には、パフォーマンス異常の検出、キャパシティプランニング、カスタム ダッシュボード、レポート作成、および高度な検索機能が含まれます。Prism Central内でロックを 解除するには、Prism Pro機能セットのライセンスを取得します。

・ライセンス

Prism Proは年間サブスクリプションを通じてノードごとに利用できます。Prism Proの機能が有効になっているPrism Centralインスタンスによって管理されるすべてのノードにライセンスが必要

カスタマイズ可能な運用ダッシュボード

カスタムダッシュボード機能を使用すると、ウィジェットのコレクションに基づいてダッシュボードを構築できます。画面にウィジェットを配置して、自分に最適な環境へのビューを正確に作成できます。

ダッシュボードのコンテンツは、単一のウィジェットからウィジェットでいっぱいの画面までさまざまです。Prism Proはデフォルトのダッシュボードが付属しているため、容量、正常性、パフォーマンス、およびアラートのビューが表示されます。

Prism Proはダッシュボードに追加できるいくつかの固定およびカスタマイズ可能なウィジェットが 含まれています。カスタマイズ可能なウィジェットを使用すると、トップリスト、アラート、および 分析を表示できます。

f:id:t_komiya:20190705235049p:plain

f:id:t_komiya:20190705235144p:plainスタムダッシュボード機能を使用するとデータに重点​​を置いたダッシュボードなど、複数のダッシュ ボードを作成できます。組織は、さまざまな物理的なサイト、ビジネスユニット、管理者、またはその他の さまざまな機能に対して別々のダッシュボードを作成できます。

3.レポート機能

f:id:t_komiya:20190705235302p:plain

Prism Proのレポート機能を使用すると、スケジュール済みレポートと必要に応じてレポートの両方を作成できます。Prism Proには、カスタマイズ可能な定義済みレポートのセットが含まれています。 または、組み込みのWYSIWYGエディタを使用して新しいレポートを作成できます。エディタで、 データポイントを選択し、それらを目的のレイアウトに配置してレポートを作成します。レポート内でグループ化する機能により、特定のデータポイントの全体像を把握したり、クラスターごとに エンティティを見たりすることができます。

f:id:t_komiya:20190705235412p:plain

f:id:t_komiya:20190705235448p:plain

Report機能はウィザードを利用して項目を選択できるようになっています。カスタマイズ項目でグラフ表示などやメトリクス表示を行うことができ、CPU・メモリ・ストレージなどの項目から、レポートする項目を選択してまとめることも可能です。

週次のレポートを求められる運用管理者の方にはオススメの機能になります。

4.動的モニタリング

f:id:t_komiya:20190706000024p:plain

動的モニタリングはX-FITのテクノロジを利用したVMの振る舞いを学習して、VMレベルのリソース監視を構築します。システムは各VMの動作を学習し、そのVMに割り当てられている各リソースのパフォーマンスベースラインとして動的しきい値を設定します。各リソースチャートは、青い影付き範囲としてベースラインを表します。VMの特定のデータポイントがベースラインの範囲外(上限または下限)に外れた場合、システムは異常を検出してアラートを生成します。異常は、簡単に参照して追跡できるようにパフォーマンスチャートに記載されています。

データポイントの異常な結果が長期にわたって続く場合、システムはVMの新しい動作を学習し、そのリソースのベースラインを調整します。振る舞いを学習することにより、Prism Proを介して配信されるパフォーマンスレポートは、組織がワークロードをよりよく理解し、従来の静的なしきい値監視では検出できなかった問題についての早期知識を得るのに役立ちます。

5.キャパシティランウェイ

f:id:t_komiya:20190706000205p:plain

キャパシティプランニングは3つのリソースバケット(ストレージ容量、CPU、およびメモリ)からの消費されているところを焦点を当てています。キャパシティ結果は、キャパシティメトリックの過去の消費量と推定されるキャパシティランウェイを示すチャートとして示されます。キャパシティランウェイは、リソース項目が完全に消費されるまでの残り日数です。Nutanix X-FITアルゴリズムは履歴データに基づいて容量計算を実行します。Prism Proは最初に各Prism インスタンスからの90日間の履歴データを使用してから、計算に使用する追加データを収集し続けます。Prism ProはPrismよりも長い容量データポイントを保持するため、組織はより大きなデータサンプルを分析に利用できます。

X-FITの方式は、残りのランウェイの日数の計算において、消費されたリソースとシステムが追加の金額を消費する割合を考慮します。ストレージの計算では、ライブでの使用量、システム使用量、予約済み容量、およびスナップショット容量をランウェイの計算に含めます。ストレージキャパシティランウェイはコンテナを認識しているため、異なる速度で成長している複数のコンテナーが単一のストレージ・プールを消費するときに容量を計算できます。コンテナの認識により、X-FITはより正確なランウェイの推定値を作成することができます。

 

Prism Proの1回目の記事はここまでとさせて頂きます。

 

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

 

NutanixのREST APIについて知ってみよう!

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日Nutanixで利用できるREST APIについてお話したいと思います。

REST APIについてご存じない方もいらっしゃると思いますので少しご説明したいと思います。

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

REST (Representational State Transfer) APIは、Webシステムを外部から利用するためのプログラムの呼び出し規約(API)の種類の一つです。RESTそのものは適用範囲の広い抽象的なモデルであるが、一般的にはRESTの考え方をWeb APIに適用したものをRESTful APIと呼んでいる。

RESTful APIでは、URL/URIですべてのリソースを一意に識別し、セッション管理や状態管理などを行わない(ステートレス)。同じURLに対する呼び出しには常に同じ結果が返されることが期待される。

また、リソースの操作はHTTPメソッドによって指定(取得ならGETメソッド、書き込みならPOSTメソッド)され、結果はXMLやHTML、JSONなどで返される。また、処理結果はHTTPステータスコードで通知するという原則が含まれることもある。

引用:IT用語辞典 e-Words

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

NutanixにおいてはREST APIがどのように使われて、どのように利用するのかを今回お話したいと思います。

1.Nutanix REST API

f:id:t_komiya:20190629094350p:plain

Nutanix REST APIを使用すると、Nutanixクラスタに対してシステム管理コマンドを実行するスクリプトを作成できます。APIを使用すると、HTTP要求を使用してクラスターに関する情報を取得したり、構成変更可能になります。コマンドからの出力はJSON形式で返されます。

動作イメージについても合わせてご覧いただければと思いますが、送信側(クライアント)から受信側(Nutanixクラスタ)に対して、必要としているクラスタ情報を取得ししたり、作成・更新・削除する際にHTTPをベースに操作を行います。

HTTPで送信した命令を元に出力結果をHTTPのコードとJSONファイルで出力します。

このようにして、HTTPのリクエストからNutanix上の操作を行うことができるようになっているのが、Nutanix REST APIになっています。

2.Nutanix REST APIを利用するには

f:id:t_komiya:20190629094953p:plain

Nutanix REST APIを利用するには、Nutanix REST APIが何ができるのかを知る必要があります。Prismの管理画面の右上にあるアカウントのメニューからREST API Explorerがメニューにあるので、こちらをクリックします。

REST API Explorerが起動されるとNutanix APIが表示されますが、REST APIにはバージョンもございます。バージョンの指定は右側のプルダウンメニューから選択することができます。現状はVersion3まであります。

f:id:t_komiya:20190629095350p:plain

REST API ExplorerでAPIで管理できるクラスターオブジェクトとのリストを表示します。オブジェクトについては、ベースがURI形式の相対パスになって表示されます。該当のPrism(Nutanix クラスタ)のIPアドレスおよびREST APIのバージョンを指定することで利用できます。

今回はNutanixで利用できるREST APIでClusterのコマンドについて説明したいと思います。ここでClusterに関して操作を展開してみます。

3.オペレーションに関して

f:id:t_komiya:20190629095831p:plain

Clusterに関するオペレーションが表示されます。例えばGet clusterなどはNutanixのクラスタ情報をクライアント側から取得するAPIになっています。それ以外にも様々な変数をNutanix クラスタの情報を作成、更新するAPIもあります。

ここで、Get clusterをクリックするとクラスタの情報がウィンドウで展開されて表示されます。ここでウィンドウで表示されているのがクライアント側から送信するGet clusterのREST APIの中身になります。

4.APIをテストする

f:id:t_komiya:20190629100240p:plain

APIをテストには、「Try it out!」をクリックすることで、クラスタ内で使用するAPIを呼び出してテストできます。

クリックするとクラスタに設定されているIPアドレス情報やマシンのシリアル情報などが取得できるようになります。こちらはブラウザベースでテストしていますが、実際はクライアント側からコマンドを実行することになります。

CentOSがインストールされている仮想マシンからコマンドで、curl コマンドを利用することで、リモートのサーバーに対してコマンドを投入することができます。

$ curl -X GET --header 'Accept application/json' 'http://NutanixのクラスタのIPアドレス:9440/api/nutanix/v2.0/cluster'

このようなAPIを利用することにより、オペレーションがコードされて自動化するためのツールとして利用できます。以前こちらのブログで紹介したCalmなどはこのREST APIなどが連携されて構成されているソリューションだと思って頂ければと思います。

 

では、REST APIを利用するとどのようなことができるのかをまとめてみました。

5.APIを使用した完全なライフサイクルの自動化

f:id:t_komiya:20190629101256p:plain

利用できるようなシーンとして、イメージのようなものを想定しています。

例えばプロビジョニングについて説明します。

新入社員で研修などで開発環境をたくさん作成しなければいけない場合、管理者が一つずつ手動で構築するのは非常に効率が悪くなります。そこで、オペレーションをすべてコードしておくことで必要に作業がシンプル化し、作業時間もかからずに導入が終わります。

f:id:t_komiya:20190629101515p:plain

どのように対応するかについては、仮想マシンのプロビジョニングに必要なイメージを用意して、それを必要な台数分をPOSTで作成することで対応できます。

その結果、プロビジョニングの時間が数分程度で終了して、管理者が準備に費やす時間を削減することができます。

f:id:t_komiya:20190629101850p:plain

システムの最適化にこのAPIを使うためにはどうするのかをお話したいと思います。

例えば制約を受けるようなVMを常にシステムを更新することによって発見して、リソースに影響を与えるような仮想マシンを保護するようなものを探したい場合にもこちらのREST APIを利用することで対応可能になります。

f:id:t_komiya:20190629102201p:plain

発見方法については、Powershellなどの連携で対応できます。システム全体の情報はREST APIで取得し、仮想マシンへの指示はPowerShellなどでそれぞれでできる部分をうまく連携することでパフォーマンスおよびセキュリティなどからシステム守るようなことができるようになります。

NutanixはGUIですべてできるようななっているように見えますが、細かい操作が必要な場合は是非REST APIなども利用してみると良いと思います。

f:id:t_komiya:20190629102540p:plain

最後にNutanixのREST APIにおける簡単なアーキテクチャを紹介したいと思います。参考程度に見て頂ければと思います。

 

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

Single Node Replication Targetについて学んでみよう!

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

Nutanixは通常3ノードで構成しますが、バックアップ用のノードに限り1ノードで構成することができます。ただし、こちらについては仕様を理解した上で構成しないとプライマリノードのバックアップとして構成できないことがありますので、注意が必要です。

それでは、説明したいと思います。

1.シングルノードレプリケーションターゲットとは?

f:id:t_komiya:20190623015733p:plain

シングルノードレプリケーションターゲットは、リカバリ場所として使用できるシングルノードクラスタです。中小企業(SMB)およびリモートオフィス/ブランチオフィス(ROBO)の展開では、DHCPサーバー、DNSサーバー、SQLサーバーなどのインフラストラクチャVMのバックアップと復元に単一のクラスターを使用できます。プライマリサイトのVMに障害が発生した場合は、それらのレプリケートスナップショットを使用して復旧できます。

詳しい内容はイメージを見て頂ければと思います。

では、こちらがNutanixのどのモデルで利用できるのかをこちらに記載しておりますが、全モデル利用できるわけではなく、NXシリーズでも限られたモデルとLenovoのHXでも1機種のみとなっております。

1ノードで構成するため、通常のRF2などとは違い、ノード内での処理で行います。また、RF3などの構成は組むことができませんのでご注意下さい。

また、LenovoのHX1520-Rについては、NXに比べCPUやメモリの選択肢が多くなっております。

 

2.ディスク障害について

シングルノードレプリケーションターゲットクラスタは、ディスクレベルでデータの冗長性を提供します。

したがって、ディスクに障害が発生した場合は、データを別のディスクに保存できます

メタデータは2つのSSD間で複製されます。

SSDに障害が発生した場合は、2番目のSSDでデータとメタデータを利用できます

ディスク障害は2つのカテゴリに分類できます。

  • SSD障害:SSD障害が発生した場合またはSSDが削除対象としてマークされている場合、シングルノード レプリケーションターゲットクラスターは読み取り専用クラスターになり、受信用のレプリケーショントラフィックの受け入れを停止します プライマリおよびシングルノードのレプリケーションターゲットクラスタにアラートが表示されます また、クラスターの回復力ステータスが[Critical]に変わります。回復プロセスも遅くなります したがって、新しいSSDをクラスターに追加して、クラスターを通常状態に戻すことをお勧めします 障害のあるディスクを取り外して新しいSSDと交換すると、この新しいSSDが自動的に検出され、 クラスターは通常の状態に戻ります(読み取り/書き込みモード)
  • HDD障害:HDD障害は通常のクラスターと同じ方法で処理され、(前述のように)SSDが障害になったときに 発生する状況は、HDD障害の場合には発生しません

3.データの回復力(Resiliency)のステータスについ

f:id:t_komiya:20190623020404p:plain

[データ回復力ステータス]ウィンドウには、より詳細なクラスター回復力のステータス情報が表示されます。このウィンドウには、クラスタが安全に耐えることができる障害の数と種類に関する情報が表示されます。シングルノードレプリケーションのターゲットクラスタの場合、[Failures Tolerable]列には、許容できるそのコンポーネントタイプ(ホストとブロックではなくディスクとホスト)の同時障害数(0、1、または2)が表示されます。失敗を許容できない場合は、制限を強調するためのメッセージが表示されます。

4.シングルノードレプリケーションターゲットの要件と制限

f:id:t_komiya:20190623020537p:plain

要件と制限についての注意点としては、NXシリーズの場合は制限がちゃんとSupport Portal上に記載されています。シングルノードレプリケーションターゲットについては、仮想マシンをインプリすることができますが、搭載しても良い条件が5台まで、IOPSも1000以下にする必要があります。

ちなみにLenovoのHX1520-Rについては、このような条件はスペックによって異なるため、明確な要件の記載はありませんが、搭載するCPUコアやメモリ量と合わせて確認する必要があります。

また、重複排除やEraser Codingなどのサポートはありません。

プライマリ環境も確認の上で、是非ノードの構成をご検討下さい。

f:id:t_komiya:20190623021130p:plain

また、ガイドラインとしてRPOなどや1日の変更量にも規定があります。

RPOは6時間、1日の変更量も5TBです。また、ライセンスについても通常はStarterでも問題ありませんが、プライマリノードに依存します。暗号化などを利用している場合はレプリケーションターゲットでもUltimateが必要になりますのでご注意下さい。

5.シングルノードレプリケーションターゲットノードのイメージング

Controller VM FoundationとStandalone Foundation(※)の両方を使用して、シングルノード レプリケーションターゲットノードをイメージングできます。

)注 Standalone Foundationを使用したイメージングは​​、Nutanixのセールスエンジニア、サポートエンジニア、およびパートナーに限定されています。この手順については、Nutanixカスタマーサポートまたはパートナーにお問い合わせください。

 

Controller VM Foundation

  • Controller VMファンデーションでは、ファンデーションプロセス中にプライマリクラスターノード (3つ以上のノード)とシングルノードレプリケーションターゲットクラスターノード(1つのノード)をマップできます
  • Standaloneのシングルノードレプリケーションターゲットクラスタを作成することもできます プライマリクラスタとレプリケーションターゲットクラスタをマッピングしない場合は、 レプリケーションターゲットクラスタをリモートサイトとしてプライマリクラスタに追加が必要

Standalone Foundation

Standalone Foundationを使用している場合、プライマリクラスタとレプリケーションターゲットクラスタのマッピングは実行できません。レプリケーションターゲットクラスタをリモートサイトとして主クラスタに追加する必要があります。

 

6.シングルノードレプリケーションターゲットクラスタの設定

基本プロセス中にプライマルクラスタとレプリケーションターゲットクラスタをマッピング していない場合は、このクラスタをリモートサイトターゲットとして手動で設定して、 保護ドメインのデータレプリケーションを保存できます

シングルノードレプリケーションターゲットクラスタでリモートサイトを設定するプロセスは、バックアップのみの機能を使用してリモートサイトを設定する必要があることを除いて、 通常のクラスタ用にリモートサイトを設定する方法と同じです

7.シングルノードレプリケーションターゲットクラスタ使用したリカバリ手順

何らかの理由で主クラスタ上のエンティティに障害が発生した場合は、シングルノード レプリケーションターゲットクラスタに複製されているスナップショットを使用してエンティティをリカバリできます

シングルノードレプリケーションターゲットクラスタから保護エンティティを復元するプロセスは、通常のクラスタのエンティティを復元する方法と同じです

 

 

異なるハイパーバイザー間のDR(Cross Hypervisor DR)について学んでみよう

 
皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は異なるハイパーバイザー間のDR機能のCross Hypervisor DRをご紹介したいと思います。そもそも異なるハイパーバイザーでDRをするのはなんで?かと思う方もいらっしゃるかと思いますが、ハイパーバイザーの移行時はもちろんのこと、インフラ管理を複雑さの軽減、システム全体のコスト削減、そして動作させるワークロードの要件によってリモートオフィスの環境などを変えていく必要があります。
 
まずは、Cross Hypervisor DRの詳細に入る前に、リモート環境に少しお話したいと思います。
1.リモートオフィスでの課題について

f:id:t_komiya:20190616095641p:plain

リモートオフィスを設備を構築する際に、データセンターと同様なシステムを組んでしまうとインフラそのものが複雑することもありますが、そもそもリモート拠点に運用を熟知したエンジニアを配置することはコスト的に難しいです。また、誰でも運用できるようなものでなければ意味がありません。それに動作させるワークロードなどの要件もあり、データセンターと同様のスペックで構成することは難しいケースがあります。
しかしながら、Nutanixを利用することで、少しでもその問題を解決することができます。
2.小規模構成の問題点やWAN回線の問題点をNutanixが解決

f:id:t_komiya:20190616100449p:plain

リモートオフィスでの環境で問題となることは、まずシステム構成とWANの回線などに関する内容です。リモートの拠点では基本的に小規模構成でシステムを組まれることが多くなります。2台くらい小規模も組まれることを考えると、先日ご紹介したWitness VMなどを構成してシステムを組むことがあります。Nutanixでは1台のWitnessサーバーで複数拠点の管理も可能になります。先日の記事は以下にリンクをつけておきます。
また、WANについて要件も完全同期のソリューションでなければ、WAN回線の速度やレイテンシなどの要件も厳しいものはございません。そのため、DRの要件がある場合はNutanixソリューションを考えてみるのは良いかと思います。
 
3.データ保護におけるリモート・ブランチオフィスでのフルスタックソリューション

f:id:t_komiya:20190616101625p:plain

Nutanixにおけるデータ保護を考えるにあたり、クラウドを利用するケースもありますが、オンプレミスを前提で考えた場合、Nutanixの機能を利用したスナップショットを利用することが考えらます。このケースの場合に運用面やコスト面そして、ワークロードを踏まえた場合にどのようなソリューションが一番良いのかというと、Cross Hypervisor DRが選ばれることがあります。
4.Cross Hypervisor DR (CH-DR)について

f:id:t_komiya:20190616102433p:plain

異なるハイパーバイザー(Cross Hypervisor)間のDRについてですが、Nutanixでなければできない機能ではありません。実際にはZerto社のソフトウェアでもESXi ~ Hyper-V間の異なるハイパーバイザーでのDR環境を提供できるプラットフォームはすでにあります。Nutanixはそれを追加コストがかけることがなく実現することができます。(ESXi ~ AHV もしくは AHV ~ ESXi)
これを実現することにより、例えばエッジに近いお客様がESXiでしか認定されていないアプリケーションを利用してシステムをESXiで導入した場合、他の拠点でのハイパーバイザーまで同一のものにしなければいけないかというお話です。データの保護だけがしっかりできていれば、別に異なるハイパーバイザーでも問題ないと考えます

f:id:t_komiya:20190616103428p:plain

その時に異機種間のDRプラットフォームを利用することでシステムが効率化することもあります。このように柔軟にプラットフォームを選択することでシステム運用を簡素化することができます。
【CH-DRはデータの保護は行いますが、異なるハイパーバイザーになるため、動的なワークロードの移行(vMotionなど)はサポートしていません】
5.Cross Hypervisor DR (CH-DR)の詳細

f:id:t_komiya:20190616103737p:plain

Cross Hypervisorディザスタリカバリ(CH-DR)は、VMの保護、スナップショットの作成、スナップショットの複製、およびその後のVMのリカバリーの保護ドメイン・セマンティクスを使用することによって、ある ハイパーバイザーから別のハイパーバイザー(ESXi から AHV もしくは AHV から ESXi)に仮想マシンを 移行する機能を提供します。スナップショットから。これらの操作を実行するには、すべてのVMにNGTをインストールして設定する必要があります。NGTは、VMの移植性に必要なすべてのドライバを使用してVMを構成します。ソースVMを準備 したら、それらを別のハイパーバイザータイプでリカバリできます。

 

Cross Hypervisorディザスタリカバリ(CH-DR)を利用時の注意点は上記のほかに2点あります。

複数のSCSIディスクをオンラインにする

マルチパス用のデバイスのブラックリスト

 

6.複数のSCSIディスクをオンラインにする

復旧後に複数のSCSIディスクをオンラインにする方法について説明します。

WindowsではSANポリシーによって、新しく検出されたディスクをオンラインにするかオフラインにするか、および読み取り/書き込みにするか読み取り専用にするかを決定します。SANポリシーが正しく構成されていない場合は、起動ディスクのみがオンラインになります。

ディスクがオフラインになると、パーティションまたはボリュームは使用できなくなり、ドライブ文字は割り当てられません。したがって、ディスクをオンラインにする必要があります。

複数のSCSIディスクを使用してVMを復旧すると非ブートディスクはWindowsに接続されずに表示されます。リカバリ後にこれらのディスクをオンラインにする必要があります。(手順は以下のイメージをご参照下さい)

f:id:t_komiya:20190616104323p:plain

f:id:t_komiya:20190616104411p:plain

7.マルチパス用のデバイスのブラックリスト

SCSIデバイスでマルチパスが有効になっていて、fstabにデバイス名が含まれていると/dev/sd*、VMをESXiからAHVに移行するときにVMが起動せず、次のようなメッセージが表示されます。e2fsckを使用中のデバイス/ dev / sd *は続行できません 表示されています。

VMを起動するには、fstabの名前を持つSCSIデバイスをマルチパスからブラックリストに登録する必要があります。 これを実現するには、コンソールでメンテナンスモードに入り、次の手順を実行します。

1.ルートファイルシステムをルート(rw)としてマウント

$ mount / -o rw,remount

2.multipath.confファイルに次の行を追加して、問題の原因となっているデバイスをブラックリストに登録

blacklist{

devnode "^sd[a-z]"

}

3.VMを再起動します。

 

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

 

NutanixのAffinityポリシーとADS(Acropolis Distributed Scheduling)について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixにおけるAffinityポリシーと過去にも紹介したADSについてお話したいと思います。

Nutanixのイメージは1クリックですべて設定するため、ポリシーについては標準のものをすべて利用するという感じに思われますが、Affinityポリシーもちゃんと設定することで、各アプリケーション間でのルールを決めることができ、運用も楽にすることができます。今日はAffinityポリシーの設定についても一度ご紹介したいと考えております。

 

1. Affinity Policy for AHV

Acropolisの管理対象クラスターの管理者として、AHVクラスター上の仮想 マシンのスケジューリングポリシーを指定できます。これらのポリシーを定義することで、クラスタ内のホスト上の仮想マシンの配置を制御できます。

これらのポリシーを定義することで、クラスタ内のホスト上の仮想マシンの 配置を制御できます。 2種類のアフィニティポリシーを定義できます。以下の内容を紹介します。

  • VMホストアフィニティポリシー
  • VM-VMアンチアフィニティポリシー
  • アフィニティルールの制限

2. VMホストアフィニティポリシー

VMホストアフィニティポリシーはVMの配置を制御します。このポリシーを使用して選択したVMがアフィニティホストリストのメンバー上でのみ実行できるように指定できます。

このポリシーは、ユーザーがVMの電源を投入したとき、またはVMを移​​行したときに、VMをどこにホストできるかを確認して適用します。

 

注意:

  • VMホストアフィニティポリシーを適用することを選択した場合、アフィニティポリシーの要件に適合しないホストに 仮想マシンをパワーオンまたは移行できないように、Acropolis HAおよびAcropolis Distributed Sc​​heduling(ADS)が 制限されます。この方針は強制的に施行されているため。
  • VMホストのアンチアフィニティポリシーはサポートされていません。
  • 以前のAOSリリースでは、ホストアフィニティ設定で構成されたVMはVMが新しいクラスターに移行されてもこれらの 設定を保持します。通常、これらのVMの電源を入れようとしても失敗しました。このようなVMは、CBRに対応して いない(バックアップとリカバリが可能)、保護されていない、保護ドメイン操作の一部として移行されていないなどのタグが付けられました。このVMタイプを選択すると、Webコンソールのメッセージが表示されます。このVMは バックアップとリカバリに対応していません。
    考えられる理由:VMとホストのアフィニティが設定されている。

VMの作成またはアップデート操作中にPrismを使用して、VMとホストのアフィニティポリシーを定義可能

3. VM-VMアンチアフィニティポリシー

このポリシーを使用して仮想マシン間の非アフィニティを指定できます。VM-VMのアンチ アフィニティポリシーでは、1台のホストで問題が発生したときに両方の仮想マシンを 失うことがないように、指定された仮想マシンを区別します。しかし、これは優先的な方針です。 このポリシーは、リソースの制約が発生した場合にAcropolisの動的スケジューリング(ADS)機能が必要な措置を講じることを制限するものではありません。

注意:

  • 現時点では、aCLIを使用してのみVM-VMのアンチアフィニティポリシーを定義できます
  • VM-VMアフィニティポリシーはサポートされていません
  • アフィニティポリシーが設定された仮想マシンのクローンが作成されている場合、ポリシーはクローン作成された 仮想マシンに自動的には適用されません。ただし、VMがDRスナップショットから復元されると、ポリシーは自動的にVMに適用されます

4. アフィニティルールの制限

  • ホストがクラスタから削除されても、ホストUUIDはVMのホストアフィニティリストから削除されません。
  • 予約ホスト方式を使用してHAが構成されているクラスタでは、VMホストアフィニティを構成できません。
  • 電源がオンになっているVMのVMホストアフィニティをPrismから削除することはできません。acliコマンドを使用してこの操作を実行できます。vm.affinity_unset vm_list

 

ここで、Affinityルールの設定をPrismの画面とacliで紹介したいと思います。

f:id:t_komiya:20190609132810p:plain

Nutanixのクラスタで1ホスト内でExchangeとSQLが動作している場合に、これらを同時に1ホストで動かさない設定(AntiAffinity)を設定したいと思います。

f:id:t_komiya:20190609132956p:plain

まずは、ExchangeのVMにおいて、Affinity設定を行います。VMのメニューからUpdateを選択して、Set Affinityをクリックして、動作するホストを選択します。

f:id:t_komiya:20190609133134p:plain

同様にSQLのVMについても同様の設定を行います。

f:id:t_komiya:20190609133226p:plain

ここで、一度SQL VMのマイグレーション設定を確認します。マイグレーションをクリックすると青い枠に注意書きがあり、先ほど設定したAffinityルールが適応されていることが確認できます。その後マイグレーションできるホストに関しても自動で移行する設定とホストA/Bが表示されています。

f:id:t_komiya:20190609133504p:plain

ここで、acliを利用してAntiAffinityの設定を行います。SSHでCVMにログインして設定します。以下は一例を記載します。

nutanix@NTNX-*******-A-CVM:~$ acli

<acropolis> vm_group.create SQL_Exch

<acropolis> vm_group.add_vms SQL_Exch vm_list=SQL,Exchange

<acropolis> vm_group.antiaffinity_set SQL_Exch

こちらを設定後にPrismの画面をしばらく見ていると、AntiAffinityを設定された条件でSQL VMがホストBにマイグレーションされることがわかります。

ここで、タスク画面にADS: Remove Resource Contentionと表示されます。

リソースの競合を排除するという話ですが、ここでADSの話をしたいと思います。

5. Acropolis Distributed Scheduler (ADS)

Acropolisの管理対象クラスターでは、Acropolisの動的スケジューリング(ADS)機能により、 一定期間にわたるコンピューティングおよび/またはストレージのI/Oの競合またはホット スポットについてクラスターを予防的に監視します。問題が検出された場合は、移行計画が 作成されて実行され、VMをあるホストから別のホストに移行することで、クラスタ内の ホットスポットが排除されます。この機能は現在進行中の競合のみを検出します。これらの タスクは、Prism Webコンソールのタスクダッシュボードから監視できます。VMリンクを クリックして、移行先(AHVホストへの)移行パスを含む移行情報を表示できます。

ADS機能のその他の利点は次のとおりです。

  • この機能は、VM構成に応じてVMの初期配置も改善します
  • アクロポリスのブロックサービス機能は、外部から見えるiSCSIターゲットのセッションのバランスをとるためにADS機能を使用します。

デフォルトではこの機能は有効になっています。Nutanixではこの機能を有効にしておくことを推奨しています。 ただし、aCLIを使用してこの機能を無効にすることができます。この機能を無効にしても、競合やホットスポットのチェックはバックグラウンドで実行され、何らかの異常が検出された場合は、3回目の通知後に[アラート]ダッシュ ボードにアラートが表示されます。ただし、これらの競合を解決するためのADS機能による処理はありません。マニュアルで修正措置を取る必要があります。

6. Acropolis動的スケジューリングの要件と制限

  • すべてのホストがAOS 5.0以降で実行していること
  • iSCSIターゲットは空のエンティティとして表示されます。ただし、iSCSIターゲットで何らかの操作が行われると、関連するメッセージが[タスク]ダッシュボードに表示されます。
  • 問題が検出され、ADSがその問題を解決できない場合(たとえば、CPUまたはストレージリソースが 限られているため)、移行計画は失敗する可能性があります。このような場合、アラートが 生成されます。Prism Webコンソールの[アラート] ダッシュボードからこれらのアラートを監視し、 必要な修正措置を取る必要があります。
  • ホスト、ファームウェア、またはAOSのアップグレードが進行中で、リソースの競合が発生した場合、アップグレード期間中はリソースの競合の再調整は行われません。

Acropolis動的スケジューリングを無効にする

次の手順を実行してADS機能を無効にします。ADS機能を無効にすること推奨していません

1.SSHセッションクラスター内のコントローラーVMにログインしacliアクセスします

2.ADS機能を無効にします

acli> ads.update enable = false

Acropolis動的スケジューリングの有効化

ADS機能を無効状態で機能を有効にしたい場合は、次の手順を実行してください

1.SSHセッションからクラスター内のコントローラーVMにログインし、acliアクセスします

2.ADS機能を有効にします

acli> ads.update enable = true

 

最後にADSの概念図についてイメージを掲載します。

f:id:t_komiya:20190609134305p:plain

f:id:t_komiya:20190609134340p:plain

参考までに見て頂ければと思います。

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

Nutanix のデータ保護について(その2)

 

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は先週に引き続いてNutanixのデータ保護に関してについてご紹介します。
先週の内容は保護ドメインやスナップショットのお話ですが、今回の内容はデータ保護の方式についてです。(画像は一部Nutanix様の資料から拝借させて頂いております)
 
最新のライセンス情報の更新も合わせて記事を記載致しますので、以前の記事を購読した人も再度読んで頂けると幸いです。
 
1.データ保護の方式について

f:id:t_komiya:20190601221222p:plain

一般的にデータの保護は前回お話したスナップショットなどのほかにDR意識したデータ保護もあります。NutanixにおいてもDRを意識したデータの保護がございます。
こちらのイメージはサイト間でのレプリケーションでデータ保護行う方式について説明しています。詳細の説明は以降のスライドで説明します。

f:id:t_komiya:20190601221636p:plain

すべてのサイトがアクティブトラフィックをサポートする必要がある環境では、複数のサイト間で仮想マシンの複製をミラーリングする機能が必要です。2サイトの例を挙げてみます。サイト2は、サイト1で実行されている選択されたワークロードのターゲットとして使用されます。同時に、サイト1は サイト2で実行されている指定ワークロードのデータ保護ターゲットとして機能します。どちらの場所にもアイドルリソースはありません。両方の場所でストレージ、コンピューティング、およびネット ワーキングリソースを利用することは、将来のデータ災害の発生を見越してサーバーがアイドル状態にあるという従来のデータ保護の考え方よりも大きなメリットです。

f:id:t_komiya:20190601221755p:plain

別のシナリオでは、複数のリモートロケーションを持つ1つの中央サイトがあるかもしれません。ティア1のワークロードがサイト1で実行され、サイト2と3がリモートバックアップロケーションとして機能する例を考えてみると、サイト1のワークロードを2箇所と3箇所の両方に複製できます。データ障害が発生した場合、保護されたワークロードは、仮想マシン全体の可用性を高めるために、必要なレプリケーションサイトのいずれかで開始できます。

1対多トポロジは、サイト間の帯域幅を最適化するように設計することもできます。たとえば、サイト1と3の間で 利用できるワイドエリアネットワーク(WAN)の帯域幅が、サイト1と2の間の帯域幅よりも大きいとします (サイト1と2は同じ都市にあり、サイト3は全国にあります)。この場合、帯域幅を節約してパフォーマンスを向上させるために、サイト1で実行されているサイズの大きい仮想マシンがサイト2に複製されるように複製 スケジュールを設定できます。同様に、小規模の仮想マシンはサイト3にバックアップされ、帯域幅の狭いリソースをより有効に活用できます。

f:id:t_komiya:20190601221924p:plain

たとえば、ハブスポークアーキテクチャでは、サイト1と2で実行されているワークロードを中央 サイト3に複製できます。単一サイトへの複製の集中化により、地理的に分散した環境の運用効率が 向上します。リモートオフィスとブランチオフィス(ROBO)は、多対1トポロジーの従来型の ユースケースです。

f:id:t_komiya:20190601222017p:plain

このトポロジーは最も柔軟な設定を可能にします。ここで、IT部門はアプリケーションとサービスのレベルの継続性を保証するために最大限の制御と柔軟性を持っています。

2.データ保護のダッシュボード

データ保護のダッシュボードには、クラスター内のデータ保護の構成に関する動的に更新された情報が表示されます。ダッシュボードでの表示画面も含めて以下のイメージを紹介いたします。

・ビューセレクタ

f:id:t_komiya:20190601222339p:plain

・ページセレクタ

f:id:t_komiya:20190601222450p:plain

テーブルビューでは、リモートサイトと保護ドメインはページあたり10個表示されます。リストに10項目を超える項目がある場合は、合計ページ数と現在のページのページ数とともに、左右のページング矢印が右側に表示されます。

・テーブルの内容をエクスポート

f:id:t_komiya:20190601222713p:plain

テーブルビューでは、歯車のアイコンをクリックしてCSVまたはJSON形式のいずれかのファイルにテーブル情報をエクスポートすることができます。プルダウンメニューから[Export CSV]または[Export JSON]を選択します。

・テーブルの内容を検索

f:id:t_komiya:20190601222849p:plain

テーブルビューでは、検索フィールドに文字列を入力してテーブル内の特定のコンテンツを検索できます

3.Metro Availability Witness Option

Metro Availability構成にWitnessを追加することもできます。「Witness」とは、Metro Availabilityの設定状態を監視する特別な仮想マシンです。Witnessは別の障害ドメインに常駐し、Metro Availabilityサイト間のネットワーク障害とサイト障害を区別できる外部ビューを提供します。Witnessの目的は、サイトの障害やサイト間のネットワーク障害が発生した場合にフェールオーバーを自動化することです。Witnessの主な機能は次のとおりです。(現状はESXiのみをサポート

  • サイトまたはサイト間のネットワークに障害が発生した場合にフェイルオーバーを決定する
  • (たとえば)WAN障害のために両方のサイトで同じストレージコンテナーがアクティブに なっているスプリットブレイン状態を回避する
  • 単一のストレージまたはネットワークドメインで障害が発生した場合の処理
Metro Availability 障害プロセス(Witnessなし)

f:id:t_komiya:20190601223154p:plain

プライマリサイトの障害(Metroストレージコンテナーが現在アクティブなサイト)またはサイト間のリンクがオフラインになった場合、Nutanix管理者はMetro Availabilityを手動で無効にしてリモートのターゲットストレージコンテナーを昇格する必要があります(または現在の)サイトをアクティブに します。

セカンダリサイトとの通信に障害が発生した場合(サイトの停止またはサイト間のネットワークリンクの停止による)、Metro Availabilityは設定に応じて次のいずれかを実行します(自動または手動)。

Metro Availability 障害プロセス(Witness

f:id:t_komiya:20190601223425p:plain

Witnessを追加すると、サイトの機能停止やネットワーク障害が発生した場合にMetro Availabilityを 無効にしてストレージコンテナを昇格させるプロセスが完全に自動化されます。Witness機能は障害が発生した場合にのみ使用されます。つまり、Witness障害自体はどちらのサイトで実行されている仮想マシンにも影響しません。

Metro Availability 運用モード

Witnessを追加した後、3つのMetro Availability操作モード(Witnessモード(新)、自動再開モード、手動モード)から選択できます。障害シナリオに対するMetro Availabilityの応答は、選択されている 動作モードによって異なります。次の表に、動作シナリオに基づく障害シナリオと応答動作を詳しく 示します。

f:id:t_komiya:20190601223538p:plain

Witnessの要件

f:id:t_komiya:20190601223628p:plain

Witnessを設定する際には、いくつかの要件があります。

  • Witness VMには(少なくとも)以下の要件があります。
   2つのvCPU
   6 GBのメモリ
   25 GBのストレージ
  • Witness VMは個別の障害ドメインに存在する必要があります。これは、各Metro Availabilityサイトからの独立した電源およびネットワーク接続を意味します。Witness VMは3番目の物理 サイトに配置することをお勧めします。 このサイトでは、単一障害点を回避するために、サイト1と サイト2への専用ネットワーク接続が必要です。
  • Metro Witnessとの通信はポートTCP 9440を介して行われるため、Witnessを使用するMetroクラスタ上の コントローラVMに対してこのポートを開く必要があります。
  • 各Metro AvailabilityサイトとWitness VM間のネットワーク 遅延は、200ミリ秒未満でなければなりません。
  • Witness VMは、サポートされている任意のハイパー バイザーに常駐することができ、NutanixまたはNutanix以外のハードウェアのどちらでも実行できます。
  • 1つのWitness VMに複数の(異なる)Metroクラスタペアを 登録できますが、クラスタペアあたり50のWitnessed Metro 保護ドメインという制限があります。
 
以上がNutanixのデータ保護に関する説明になります。
 
よろしくお願いします。
 
 
 
 
 

Nutanix のデータ保護について(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのデータ保護に関してについてご紹介します。

昨年データ保護については記事を記載しておりますが、詳細な点については記載していなかったため、今回は2回に分けて内容をお伝えしたいと思います。(画像は一部Nutanix様の資料から拝借させて頂いております)

昨年掲載した記事はこちらになります。

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

Nutanixのデータ保護について覚えてみよう~Metro Availability と Near Syncの違いについて~

https://blog.lenovojp.com/entry/2018/06/09/105913

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

1.Site Failover Operations

サイトがフェイルオーバーした時のオペレーションのことを考えてみましょう。

まず、スナップショットとレプリケーションのスケジュールを設定した後で、あるサイトから別のサイトにフェイルオーバーする必要があるかもしれません。 3つのフェイルオーバーシナリオが可能です。

 

計画的フェイルオーバー

両方のサイトが稼働していて、その構成が正しく機能することをテストしたい場合、または1次サイトの計画的保守またはサイト拡張の前にフェイルオーバーします

災害時フェイルオーバー

プライマリサイトが停止したときのフェイルオーバー

フェイルバック:

システム停止を解決してプライマリサイトに戻したい場合に、復旧サイトから計画的フェイルオーバーを開始します

 

(詳細は説明は文字数の関係で画像の中に記載させて頂きます) 

 

2.計画的なフェイルオーバーもしくはフェイルバック

f:id:t_komiya:20190526172350p:plain

3.災害時フェイルオーバー/保護ドメインの変更

f:id:t_komiya:20190526172505p:plain

4.保護ドメインのガイドライン f:id:t_komiya:20190526172645p:plain

f:id:t_komiya:20190526172709p:plain

 

5.VMセントリックのデータ保護

AOSは、ネイティブのオンサイトバックアップと、オフサイトバックアップおよびディザスタリカバリ用のリモートレプリケーションの両方に統合データ保護ソリューションを提供します。

これらの機能は、スナップショットがソースVMと同じクラスターに格納されるタイムストリームと、スナップショットがクラスター間で非同期に複製されるサイト間レプリケーションの2つのユースケースで使用できます。

VMのスナップショットはクラッシュコンシステントです。つまり、VMDKのオンディスクイメージは一時点で一貫性を保っています。つまり、スナップショットはVMがクラッシュしたかのようにディスク上のデータを表します。状況によっては、スナップショットもアプリケーションと整合性があります。

つまり、スナップショットの時点でアプリケーションデータが静止します。アプリケーション整合性のあるスナップショットは、ESXiハイパーバイザーによってホストされているVMにインストールできる一連のユーティリティであるVMware Toolsを介して適用されます。この機能はVSSを起動してVM用のアプリケーション整合性のあるスナップショットを作成します。これは単一のVMを持つ整合性グループに限定されます。

スナップショットは、定義されたスケジュールまたは必要に応じて作成できます。作成されたすべてのスナップショットは有効期限に関連付けられており、有効期限が過ぎるとNutanixクラスタは自動的にスナップショットを削除します。重要ではないVMファイル(スワップファイルやログファイルなど)はスナップショットに含まれません。

6.データ保護の概念

f:id:t_komiya:20190526172909p:plain

データ保護に関してはこちらのような概念があります。それぞれに関しての説明について、説明したいと思います。(文字数が多くなるため、画面イメージに文字も記載致します)

・保護ドメイン

f:id:t_komiya:20190526173144p:plain

保護ドメインについては非同期DRとMetroAvailabilityの2種類でドメインが存在することを覚えて頂ければと思います。

・整合性グループ(Consistency Group)

f:id:t_komiya:20190526173317p:plain

データ保護を行う上で重要なのは、スナップショットを取ったデータが整合性を保っていることが重要です。リストア後に整合性が保った状態に戻すのはアプリケーション次第ではあるが、クラッシュコンシステントのバックアップで停電後でも仮想マシンの電源入れている状態に戻せるようにしておきましょう。仮想マシンには必ずNGT(Nutanix Guest Tools)を入れておきましょう。

・スナップショット

f:id:t_komiya:20190526174148p:plain

スナップショットについては、特に説明する内容はほとんどないので、画面イメージを載せておきます。

・タイムストリーム

f:id:t_komiya:20190526174313p:plain

タイムストリームについても、スナップショットと同様のお話ですので、画面イメージを掲載のみです。

・リモートサイト

f:id:t_komiya:20190526174458p:plain

リモートサイトへバックアップを複製することになり舞うsが、通常はオンプレミス上の別ロケーションというイメージが強いですが、Nutanixではパブリッククラウドにもレプリケーションを指定することができます。(現在はXi Leapも利用可能です)

・レプリケーション

f:id:t_komiya:20190526174742p:plain

レプリケーションについては、1つもしくは複数サイトにレプリカを作成することができます。注意事項としては、マルチサイトで複製取る場合には、ライセンスのエディションにご注意下さい。(Ultimateが必要になります)

・スケジュール

f:id:t_komiya:20190526175005p:plain

スケジューリングについては、非同期DRについては間隔が短い場合はNear Syncになりますので、その場合は仕様も含めて確認してから設定してください。

 

本日のデータ保護の説明は以上とさせて頂きます。

次回は、複製の方式についてご説明したいと思います。

 

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