2019年12月2日月曜日

LCM(Life Cycle Manager)の使い方

では、実際にLCMの画面を見ていきたいと思います。

LCMは、Prism画面に統合されています。
AOS5.10までは、右上のギアアイコン(歯車ボタン)をクリックし、LCMを選択します。
AOS5.11からは、左側のメニューに独立した項目としてLCMメニューが存在しておりますので、それをクリックします。

AOS5.10

AOS5.11~

どちらであっても、LCMのバージョンが同じであれば操作方法は同じです。

では、どのような情報が見えるのかを確認していきましょう。
Installed versions on x hostの項目は、ホストごとで各コンポーネントのファームウェア等のバージョン情報を見ることができます。

では、左メニューの「Software」項目をクリックすると、ソフトウェアのアップデート一覧が表示されます。こちらの画面では何も表示されておりませんが、現行では以下のソフトウェアがLCMによるアップデートがサポートされております。

  • Files Analytics
  • Objects (Prism Central)
  • Karbon (Prism Central)
  • Calm (Prism Central)

Prism CentralのSoftwareアップデート項目


左メニューのFirmwareの項目では、ハードウェアに対してファームウェアーのアップデートが必要な項目が出てきます。

この環境では、ノード3のHost Boot Device(この環境はXCの13Gなので、SATA-DOM)のファームウェアーアップグレードが必要となります。


LCM自体は、ただのアップデート支援ツールであり普段の運用であまり要するものではありませんが、定期的なファームウェアやソフトウェアのアップデートは安定した仮想化基盤を運用するうえでは不可欠な要素です。
従来の3Tierではそれぞれファームウェアやコンパチビリティにあわせて、適用できるファームウェアを自分で入手し1つずつアップデートをする必要がありましたが、LCMを利用すれば、コンパチビリティの通ったファームウェアを自動で取得してくれますので、アップデートを行える時間帯にUpdateボタンをクリックするだけで作業完了です。

なお、LCMのアップグレード項目はNCCと連携しているため、ファームウェア等のアップデートが必要な場合、NCC側で警告が表示されるため、アップデートが必要な時期は何もせずに理解することができます。(最新版のアップデートのためにはNCCアップデートが必要です)

あとから障害を生まないためにも、定期的なLCMによるアップデートを心がけることが大切かと思います。



2019年12月1日日曜日

IPMIを使ってISOメディアマウントを行う方法

Nutanix NXモデルの物理ノードにISOメディアをマウントさせたい場合、いくつかの方法があります。昨今ではG5モデルの一部でHDDやSSDのファームアップが要求されるケースがあり、LCMを利用できない環境の場合、Phoenix ISOから作業を行う必要があります。この際にもPhoenix ISOを物理ノードにマウントする必要があります。
今日は、メディアマウントにおける方法をいくつかお知らせいたします。

1.物理ノードにUSB DVDドライブを取り付ける
最もわかりやす物理的なアプローチです。Phoenix ISOをCD-RやDVD-Rに事前に焼いておく必要がありますので、事前準備が面倒ではありますが、一番わかりやすく確実な手法です。Nutanixのノードは背面にUSBポートが用意されています。

▼NX-1065-G7の背面USB一


2.バーチャルコンソールのメディアマウントを利用する
IPMIのRemote Controlから「Console Redirection」機能を利用し、バーチャルコンソールを起動しそこからメディアマウントを行うことができます。

▼Console Redirectionを開く画面(IPMI)

バーチャルコンソールは、Java(JRE)が必要となりますので、事前にインストールを行っておく必要があります。

▼バーチャルコンソールからISOをマウントする様子

NutanixのドキュメントにおいてもISOをマウントする際はこの手法を使ってISOをマウントするように指示が出てきます。しかし、昨今のJAVAのライセンスに対する問題や、Javaのバージョンによりセキュリティレベルが変更されているなどの仕様の背景から正常にJava経由でコンソールが起動しないことも環境によっては起きえます。


3.IPMIから直接SMB共有を開く
IPMIのVirtual Mediaの画面から直接ISOをマウントすることができます。
この場合、Windowsの共有機能(CIFS)を使ってISOファイルをマウントすることができます。

▼共有フォルダにISOを配置し、マウントした様子

メディアマウントのためには、共有フォルダを提供するサーバーのIPとマウントしたいISOファイルのパスとファイル名、アクセスするためのユーザー名とパスワードを入力します。メディアマウントが正常に行われた場合「Device 1」のところが「There is an iso mounted」という表示に変わります。

ISOマウントにおいてはこの作業が一番簡単に見えますが、1つだけ注意事項があります。それは、このCIFSマウントは、SMB1.0しかサポートされていません。
Windows 10やWindows Server 2016においては、デフォルトではSMB1.0は有効化されていないため、メディアマウントさせるためには、共有フォルダを提供する側のWindows 10/Server 2016/2019で、SMB1.0を有効化する必要があります。


▼Windows 10におけるSMB1.0の有効化方法


今回は、Nutanixの物理ノードにISOをマウントさせる方法をご紹介しました。
実際にはあまり利用することがない機能だけに、いざ必要になるとたかがISOマウントだけでもいろいろ手間取ることがあります。
事前に押さえておいて損がない小技ですので、ぜひ覚えておきましょう。






LCM(Life Cycle Manager)とは

Nutanixといえば、AOSやハイパーバイザーをアップグレード出来る「One Click Upgrade」が有名ですし、今までの面倒なアップグレード作業を自動化出来る大変便利な機能です。

もともとOne Click Upgradeでアップグレードができるものは、
  • AOS
  • ハイパーバイザー(ESXi/AHV/Hyper-V/XenServer)
  • SSD/HDDのファームウェア
  • BMC/BIOS

となっておりました。
AOSやハイパーバイザーは純粋なソフトウェアのアップグレードとなるため、特段問題は無いのですが、SSDやHDD、BMC、BIOSなどハードウェアに起因するファームウェアのアップデートは、元来NXモデルをベースに作成されていたため、DellXCやLenovoHXなどでは、一部未対応な部分がありました。

また、ファームウェアのアップデート機能は、自分で必要なファームウェアファイルを入手してそれを手動でアップロードした上で行う作業となっており、アップグレードまでの手段は、従来と変わらず幾分面倒な作業が残っていました。

Nutanixは、純粋なソフトウェアメーカーとして、対応するハードウェアの幅も広げているため、このようなハードウェアメーカーによって出来る機能差が出てくることは望ましくないと言うことで、様々なハードウェアにあわせて、また、現行のNutanix環境(AOSやハイパーバイザーのバージョンなど)をひとまとめにして、管理するというのが、LCM(Life Cycle Manager)の役割となります。

LCMは、Nutanixを正しく運用するためには、定期的なファームウェアやソフトウェアのアップデートは欠かせません。このアップデートのとりまとめを行うLCMは、Nutanixにおいて大変重要なコンポーネントです。

では、LCMを利用する際の注意点をまとめておきます。
  • LCM2.xは、AOS5.5.6移行の環境で利用が可能です
  • 1ノードクラスター(主にSNRT)では、LCMを利用出来ません
  • 2ノードクラスターは、AOS5.10.5移行でサポートされています
  • LCMを利用する前に、Nutanixクラスター内部で保有するFoundationバイナリを最新にしてください

明日は、LCMの使い方についてご紹介します。






2019年8月13日火曜日

AOS5.11を紹介(その5) AHVでもEFIがサポートされました。

昨今では、パソコンにおいてもサーバーにおいても大容量化が進んでおり、1つの物理的なHDDでも10TBを超えるものも存在しています。
Windowsの場合、旧来のBIOSを利用すると2TBを超えるディスクを起動ディスクとすると、2TB以上の領域を利用できないなど、大容量化に対して旧来の技術では対応ができないという課題がありました。
また、Hyper-Vの第2世代で構成された仮想マシンはUEFIと構成され、AHVへの移行にはかなり手のかかる作業が必要でした。

今回AOS5.11から正式にAHVにおいてもUEFIがサポートされました。
従来からAHVにおいてもUEFIはacliコマンドで設定することでEFIモードにすることはできましたが、非サポート扱いでしたがこのタイミングでUEFIもサポータブルになりました。

2019/4末の段階で、AHVでEFIを設定した仮想マシンの起動ロゴが変わっていることに気が付いておりました。(以前はロゴのない文字しかない画面でした)


これがおそらく「AHV-20170830.256」のバージョンであると思いますので、4月末ぐらいには水面下にAHVだけが先行的にバイナリが提供されたのかもしれません。

このUEFI対応に伴い、Prismの仮想マシン作成画面でもBIOSかUEFIかを選択できる画面が追加されました。

また、BIOS利用時は、優先Bootメディアを選択できるようになり、デフォルトのCDROMドライブではなく最初から任意のメディアにGUIで変更できるようになりました。

なお、AHVとして正式にUEFIに対応しているゲストOSは以下の通りです。

  • Microsoft Windows 10 Home/Pro
  • Microsoft Windows server 2012 R2/2016
  • CentOS 7.4/7.5
  • Red Hat enterprise Linux 7.1
  • Ubuntu 12.04.x LTS Desktop/Server
  • Ubuntu 16.04.x LTS Desktop/Server
  • Ubuntu 18.04.x LTS Desktop/Server
  • SUSE Linux Enterprise Server 12 SP3

最新の情報は、AHV Administrator Guideを参照してください。
https://portal.nutanix.com/#/page/docs/details?targetId=AHV-Admin-Guide-v511:vmm-compatibility-matrix-for-uefi-supported-vm-r.html

UEFIが正式に対応したこととNutanix Move 3.0からHyper-VからAHVへの移行がサポートされたことにより、Hyper-V第2世代(UEFI)で作成された仮想マシンも問題なく移行することができるようになったのは、AHVの利用の幅を広げる大きな理由の1つになったと思います。




2019年8月12日月曜日

AOS5.11を紹介(その4) Storage QoS機能の搭載でノイジネイバーの影響を低減する

今期は、AOS5.11に搭載されたStorage QoS機能についてご紹介します。

仮想化において厄介なのは特定の仮想マシンがストレージのI/O負荷を大きくかけて、仮想化基盤にいる他の仮想マシン全体に迷惑をかける、いわゆるノイジーネイバー(うるさい隣人)の存在です。

Nutanixは、CVMが各仮想マシンのI/Oを把握しているため、それぞれのマシンに対してフェアなI/Oを提供するようにできています。
しかし、I/Oに対しての制限(リミット)を設定することができませんでしたが、このAOS5.11からIOPSの制限を入れる機能が追加されました。
これがStorage QoS機能となります。

このStorage QoSの設定にはするには以下の環境である必要があります。

  • ハイパーバイザーは「ESXi」または「AHV」である必要があります。
  • Nutanixクラスターのライセンスが「Pro」以上である必要があります。
  • 設定には、Prism Central(Prism Starterでよい)を利用します。
  • IOPSの最小値は100です。100未満は設定できません。
  • IOPSを設定した仮想マシンは、IOの遅延が出てくる可能性があります。
  • リンククローンで作成した仮想マシンの場合、マスターvDiskはQoSの対象になりません。
  • VolumeGroup及びVolumeGroupが設定された仮想マシンには適用されません。

では具体的に設定方法を見てみましょう。
まずは、Prism CentralのVMsから、I/Oを制限したい仮想マシンにチェックを入れ、上のActionメニューから「Set QoS Attributes」をクリックします。

ここで指定したいIOPSまたは、スループットを入力します。
下側の表には入力したIOPSに基づいたスループットが自動的に計算されて表示されます。

ここでポイントは、32Kを超えるブロックサイズの場合、IOPSではなくスループットで自動的にリミテーションがかかる仕組みとなっています。
IOPSですから、1ブロックのサイズが大きくなれば当然ながら少ないIOPSであっても、ある程度の負荷がストレージ側にかかってきます。そのため、このStorage QoSに関しては、32Kを超えるストレージブロックは、スループットに置き換え最終的に受け渡されるデーターのサイズに違いがないようにし、フェアな速度を提供するように作られています。

IOPSの制限を入れることにより、例えば普段負荷がかからない仮想マシンにリミテーションを入れて、Windows Updateやウイルス対策ソフトのフルスキャンなどの業務外の作業で仮想化基盤全体の負荷がかかり、本来利用したいサービスが稼働している仮想マシンの動作影響を抑えることや、マルチテナントにおけるノイジネイバーによる他のテナントへの影響範囲を制限することができます。

StorageのIO制限は、ストレージにおいてよく要求される事項の一つでもあります。
NutanixのStorage QoSは、LUN単位ではなく仮想マシン単位で行えることはNutanixのメリットであると思います。



2019年8月11日日曜日

コンピュート専用ノードの動きを見てみる

前回の記事で、AOS5.11からコンピュート専用ノードの紹介をさせていただきました。
今回は具体的に、コンピュートノードをクラスターに追加する方法と追加後にどのようにPrism,に表示されるかなどをご紹介したいと思います。

まず、前提条件として、コンピュートノードは、既に4ノード以上で稼動しているNutanixクラスターに追加する形でしか構成されません。3ノード構成でうち1ノードをコンピュート専用ノードにするといったことは出来ませんので、ご留意ください。

まずは、既存のコンピュートノードを見てみましょう。
AHVはインストールされていますが、CVMが存在しないことが分かります。
[root@COMPUTE-NODE ~]# uname -a
Linux COMPUTE-NODE 4.4.77-1.el6.nutanix.20170830.301.x86_64 #1 SMP Wed Jun 26 17:05:47 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[root@COMPUTE-NODE ~]# virsh list --all
Id               名前               状態
----------------------------------------------------

[root@COMPUTE-NODE ~]#

これは、FoundationVMで、ComputeOnlyNodeでFoundationすることでこの環境を作成することが出来ます。

では次に、既存クラスターへの追加を行います。
追加は、前回説明したとおりExpandClusterから、行います。


通常のノードの場合、ExpandClusterを行うとIPv6リンクローカルアドレスを使ったDicoveryが行われますが、CVMが存在しないコンピュート専用ノードは自動検出されません。そのため以下のようにマニュアルでAHVホストIPを入力し、検出を行います。

ここで、AHVのIPアドレスを入力します。


検出を行うと、そのノードのモデルやシリアル番号は表示されます。
通常この情報はCVMが保有しているのですが、コンピュート専用モデルでイメージングされた場合にのみ、AHVハイパーバイザー上にモデル情報等が記録されます。
コンピュートノードのためCVMのIPアドレスは入力欄がありません。


Expand Clusterの作業自体は、AOSのバージョンチェックがないことや、追加ノードのディスクメンバーをStoragePoolへの仲間入りさせる作業が発生しない分、かなり早く終わります。

追加されたコンピュート専用ノードは通常と同じハードウェアに上がってきます。
ここで、コンピュート専用ノードは以下の画面の通り、TypeにCompute Onlyノード(日本語では計算のみ)として記載され、通常のHCIノード(コンピュートとストレージの両方を持つ通常ノード)と異なる事が確認でできます。
パフォーマンスグラフを見ても、ストレージに関するグラフが表示されていないことが分かります。


ハードウェア一覧でのストレージIO部分が、コンピュート専用ノードでは表示されないことがわかります。

持ちろん、仮想マシンのライブマイグレーションホストの選択も可能ですし、ライブマイグレーションは問題なく動作します。


では、ノードの取り外し(Remove)についても最後に紹介しておきます。
ノードの取り外しもExpandと同様、ノードのディスクがストレージメンバーに存在しないため、わずか1〜2分でRemove処理が完了します。
(通常のHCIノードの場合、ノード取り外し時に、自分のデーターを他のノードにコピーし、SSD/ディスクをStoragePoolのメンバーから外す作業が発生するためそれなりの時間がかかります)


今回はコンピュートノードについて確認をしてみましたが、最初のFoundationのところがひと手間ありますが、それ以降のノード拡張作業などはいつものNutanixのオペレーションと同じくシンプルな操作で、コンピュートノードであることをあまり意識しないNutanixらしい使いやすさを実現していると感じます。






2019年8月8日木曜日

AOS5.11を紹介(その3) コンピュート専用ノードの誕生

Nutanixは、ストレージとコンピュートノードのセットになったノードが一般的ですが、容量だけ増やすこのことの出来るストレージ専用ノードの2つがラインナップされています。さらにAOS5.11から、コンピュートだけを追加するコンピュート専用ノードがリリースされました。コンピュート専用ノードは、Nutanixのドキュメント上では「CO」(Compute Only)として記載されていることがありますので、COという表現を見たらコンピュート専用ノードのことと思い出してください。

さて、このコンピュート専用ノードは、読んで字のごとくストレージ機能を提供しない演算処理だけのノードとなります。
ディスク容量はそこまで必要ないけれども、CPUやメモリーを多く消費するワークロードにおいては、このコンピュート専用ノード重宝する物だと思います。

このコンピュート専用ノードを既存クラスターに追加するためにはいくつかの制限事項があります。ではその制限事項を確認しておきましょう。

<構成の注意点>
  • Nutanixクラスターは少なくとも4ノードの通常ノードで構成されたされている必要があります。
  • クラスタ内のコンピュート専用ノードとハイパーコンバージドノード(通常のノード)の比率は、
    「1 コンピュート専用ノード:2 ハイパーコンバージド」
    である必要があります。
  • クラスタ内のすべてのハイパーコンバージドノードは、オールフラッシュノードである必要があります。
  • ハイパーコンバージドノード上のCVMに割り当てられるvCPUの数は、クラスター内のすべてのコンピュート専用ノードで利用可能なコアの総数以上である必要があります。(つまりコンピュートノードが8コアの場合、CVMのvCPUコアも8コア以上にする必要がある)
  • すべてのハイパーコンバージドノードに割り当てられたNIC帯域幅の合計は、クラスター内のすべての計算専用ノードに割り当てられた合計NIC帯域幅の2倍である必要があります。(コンピュートノードが10GbpsのNICで通信する場合、ハイパーコンバージドノードのネットワークは20Gbps以上、つまり25Gネットワークが必要となります)
  • コンピュート専用ノードのAHVのみ対応します。AHVのバージョンは、クラスター内の他ノードと同じである必要があります。
  • コンピュート専用ノードを作成するためには、Foundationであらかじめコンピュート専用ノードでイメージングする必要があります。 

<機能上の注意点>
  • ホストブートディスク(M.2 or BOSS)の交換(PrismUIからの操作)
  • ネットワークセグメンテーション
  • AOS5.11からのサポート

<サポートされているハードウェア>
  • NXシリーズ
  • Dell XC Core
  • Cisco UCS

構成の制限ざっと見る限り、え???みたいな制限がかなりあります...。
(普通のハイパーコンバージドノードを買う方がきっと安くなる気がします)

なお、コンピュートノードは、闇雲に好きなサーバーを追加するわけでは無く、Nutanixのコンパチビリティが通ったモデルだけがサポータブルであることが、サポートされているハードウェアの一覧から分かります。

では、このコンピュートノードの作り方とノードの追加方法をお知らせします。

まずコンピュートノードの追加方法です。
コンピュートノードは、Foundationツール(Foundation VM)を利用して、CVMの存在しないコンピュート専用ノードでイメージングする必要があります。
しかし、Foundation4.4.1では、このコンピュート専用のメニューは表示されません。このモードを表示するためには、FoundationVMで以下の設定を入れる必要があります。

FounadtionVMで以下のファイルを作成します。
vi /home/nutanix/foundation/config/features.json

以下の内容を記載し、保存してviを終了します
{"compute_only": true}

Foundationサービスを再起動します。
/home/nutanix/foundation/bin/foundation_service restart

これで、FoundationのノードDiscovery画面の右上メニューで、「Add Compute-only Node」が表示されるようになります。

イメージングが完了したノードは、既存クラスターのPrism画面から、Expand Clusterの画面を利用してノード拡張を行います。
ただし、CVMが存在しないノードのためNode Discoveryによる自動的なノードの検出は出来ません。 そのため、Manual Host Discoveryから、AHVのIPアドレスを入れてノードを手動で検出させた後、Expand Cluster機能でノードを追加する流れとなります。

HCIは本来、ストレージとコンピュートノードが一体化することでハイパフォーマンスと利便性を提供する物であり、コンピュートノードだけの追加となると、HCIの意味合いが薄まる感じもしますが、ユーザーのニーズに合わせて提供された機能であると思います。









2019年8月7日水曜日

AOS5.11を紹介(その2) 1ノード120TBオーバーモデルの誕生

今日はハイパーバイザーに依存しない話しを1つご紹介します。

NutanixはSoftware Defiedベースの分散アーキテクチャーを利用した完全なる分散型のストレージを実現しています。
ソフトウェアベースである以上、ソフトウェアのパフォーマンスとの勝負の部分も一部ありますが、AOS5.11よりノードあたり120TBの容量を保持できるノードを対応しました。これにより、3ノードであってもかなりの容量を担保できる仮想化環境を構築できます。

この対応により、1ノードに対して搭載できるディスクとして12TBモデルがサポートされるようになります。

なお、2つほど注意点があります。

1)1ノード40TBを超える場合、スナップショットのRPOは6時間となります。
これは、AOS5.11より前に話が出ていましたが、40TiBを超えるノードで構成されている場合、スナップショットのサイクルは、6時間に1回となります。Nutanixは、通常1時間に1回のスナップショットが設定可能ですが、環境によっては出来ないことがありますので注意が必要です。

2)CVMのメモリーサイズに注意
ノードあたり120TBを構成する場合、CVMのメモリーサイズは36GBに設定する必要があります。

今後Nutanixは、ノードあたり200TiBのサポートもでているようですので、ますます容量単価も下がり、大容量化に対応するNuttanixを利用することで、スト手レージヘビーな要件も対応できる幅が広がると思います。

(参考)
Supported Snapshot RPO for Storage Heavy Nodes
※Accessには、Nutanix Support Portalへのログインが必要です。



2019年8月6日火曜日

AOS5.11を紹介(その1) アップリンクチーミングモード変更GUI機能を紹介

ついに2019/6/8、待ちに待ったAOS5.11がリリースされました。
このブログもAOS5.11を待っており昨年から更新が出来ておらず、奇しくも今年1発目の投稿となります。(これから巻き返せればと思います...)

さて、AOS5.11にはたくさんの機能が盛り込まれているのですが、その中の1つであるbr0のアップリンク構成変更のGUI化について紹介します。

AHVにおける操作性が悪いところの1つが、アップリンクNICのチーミングモードの設定現行でした。AHVで構成されたNutanixクラスターは、初期出荷時にAcrive/Backupモードでチーミングモードが設定されています。Nutanixの推奨チーミングモードはこのActive/Backupモードとなりますが、より多くのトラフィックを処理するために状況によってはLAG(Link Aggregation)を利用する事もあるかと思います。
AHVにおいてアップリンクのチーミングモードを変更するためには、「manage_ovs」コマンドをCVM上で実行する必要があるのですが、パラメーターが複雑であったり、状況によってはAHVホスト側で直接「ovs-vcsctl」を実行する必要があるなど、あまりユーザーフレンドリーではありませんでした。

しかし、AOS5.11からこのアップリンクモードの変更がPrism Elementから出来るようになりました!(個人的には待望の機能1つ)

では早速、使い方をご紹介します。
まず、Prism Element画面から「Network」を選択します。

続いて、現在のアップリンクに属しいているNICを確認します。
各ホストのホスト名称をクリックします。

この状態では、アップリンクNICに1Gと10Gが混在しています。


この状況はAHVで稼動する場合において推奨されない構成となります。
その理由は、10G/1G混在時に1GNICがリンクアップすると、10GNICを利用していても、速度がすべて1Gに統一されてしまうからです。1Gを明示的に利用しない場合はこのような事故は防げるかと思いますが、接続間違いが起きてもトラブルがおきないようアップリンクの構成から1GNICをはずすことが推奨とされています。 なお「0G」というNICもアップリンクに存在(表示)されていますが、こちらはDELL XCで構成されている場合、iDRACとの通信用の内部NICが表示されているためです。このNICは、本来アップリンクに存在してはいけない(Foundationを行った場合、自動的にこのNICは、アップリンクの対象から外されます)のでこちらも除外したいと思います。

では、早速アップリンクモードの変更を行いたいと思います。
先程のネットワーク画面の右上にある「+アップリンク設定」をクリックします。

ここでアップリンクのモードを変更できます。
今回は、Active/Backupのまま、1GNICをアップリンクの対象から外してみます。

アップリンクモードは「アクティブ-バックアップ」を選択し、NICの設定で、「Select All 10G NICs」を選択した後「保存」をクリックします。

設定はこれだけです。

実際に設定反映をしてみると、Taskにはホストをメンテナンスモードにし、再起動していることが分かります。アップリンクモードの変更は仮想マシンの通信停止に陥る可能性もあるため、ホストを1台ずつメンテナンスモードにし、仮想マシンをライブマイグレーションされた後、チーミングモードが変更されるという仕組みす。この作業がホスト分だけ1つずつローリングで設定される仕組みとなります。(この仕組みから、N+1で構成されていない環境ではこの設定は利用できません)

設定変更はノード数にもよりますが1ノードあたりだいたい5〜7分程度ではないかと思います。設定が完了すると、ちゃんとアップリンクNICが10Gだけになっていることが分かります。

今までのコマンドとの戦いも無く、マウス数クリックだけで変更できるのは、大変便利です。

次回はまた別のAOS5.11の機能をご紹介できればと思います。





2018年12月25日火曜日

AHVのメンテナンスモードの紹介

この記事はNutanix Advent Calendar(1枚目) 2018/12/25の記事です
vSphere ESXiには、クラスターが組まれているホストのうち、メンテナンスを行いたいホストに対してメンテナンスモードというモードを設定することで、DRSによる仮想マシンのマイグレーションの抑制や、稼働中の仮想マシンを他のホストにマイグレーションする機能が存在ます。
AHVにおいても同様に、ホストのメンテナンスのためのメンテナンスモードが存在します。
今日はこのメンテナンスモードについて紹介いたします。

まず、メンテナンスモードの設定は、acliを利用します。
まず、メンテナンスをしたいホストの上にあるCVMにSSHでログインします。

まずは、メンテナンスモードにしたいホストが、メンテナンスモードに移行できる状況かを確認します。
host.enter_maintenance_mode_check 192.168.XX.XXX
コマンドの後ろには、メンテナンスモードにしたいホストのIPを入力します。

以下の結果が出てくれば、問題なくメンテナンスモードに移行できます。
"Ok to enter maintenance mode."

では、実際にメンテナンスモードにしてみましょう。
host.enter_maintenance_mode 192.168.XX.XXX mode=live
このコマンドの実行後、「EnterMaintenanceMode: pending」が表示されますが、これは仮想マシンをライブマイグレーションして他のホストに移行中です。
Prismでタスクを確認すると、メンテナンスモードに移行中であることがわかります。


最終的にCompleteの結果が表示されます。
EnterMaintenanceMode: complete

試しに、メンテナンスモードにしたAHVにSSHでログインし、稼働している仮想マシンの状況を確認してみます。
[root@NX-AHV-1 ~]# virsh list
 Id    Name                           State
----------------------------------------------------
 28    NTNX-NX-AHV-1-CVM              running
CVM以外の仮想マシンが、いないことがわかります。

では、ホストがメンテナンスモードになっているかどうかを確認するコマンドも紹介しておきます。
host.list
以下のような一覧が表示されます。
Hypervisor address  Host UUID       Schedulable  Hypervisor Type  Hypervisor Name
192.168.XX.XXX      003dc913-XXX..  False        kKvm             AHV           
192.168.XX.YYY      349bfb31-YYY..  True         kKvm             AHV           
192.168.XX.ZZZ      2e5422d5-ZZZ..  True         kKvm             AHV
メンテナンスモードにしたホストは、SchedulableがFalseになっていることがわかります。


では、このメンテナンスモードにするコマンドのパラメーターを紹介します。

mode

メンテナンスモードにするホスト上にいる仮想マシンのマイグレーション方法について指定します。'live', 'cold', 'power_off'から選択できます。デフォルトはliveです。

non_migratable_vm_action

マイグレーションができない仮想マシンが存在した場合にどのようなアクションをするかの指定を行います。'block', 'acpi_shutdown'から選択し、デフォルトはblockです、

wait

メンテナンスモードに設定した際に、ライブマイグレーションを行うまで、待つかどうかを指定します。trueかfalseで指定し、デフォルトはtrueです。

ここまでくれば、あとは、CVMをシャットダウンし、AHVホストをシャットダウンすれば終わりです。

まずはCVMのシャットダウンは、メンテナンスを行いたいホストの上に存在するCVMにSSHでログインし、以下のコマンドを実行します。
cvm_shutdown -P now

CVMがシャットダウンしたかどうかは、メンテナンスしたいホストのAHVにSSHでログインし、以下のコマンドを実行し確認します。
virsh list --all
仮想マシンのリストが表示され、CVMの仮想マシンが「shut off」になっていれば、CVMはシャットダウンされています。
 Id    Name                           State
----------------------------------------------------
 -     NTNX-NX-AHV-1-CVM              shut off

なお、メンテナンスモードになった子を確認するには、acliから以下のコマンドを実行します。



これで、CVMのシャットダウンは終わりました。
では、次にAHVホストをシャットダウンします。
ホストのシャットダウンは、メンテナンスしたいホストのAHVにSSHで接続し、以下のコマンドを実行します。
shutdown -h now

これで、ホストもシャットダウンされます。

では、メンテナンス完了後の作業についても紹介しておきます。
AHVホストを起動すると、自動的にCVMも起動します。
CVMが起動し、クラスターメンバーに復帰するまで、待ちます。
なお、クラスターに復帰したかどうかを確認するには、クラスターの任意のCVMにログインし、以下のコマンドを実行します。
cluster status

以下のような形で、CVMが起動していない場合、Downと表示されます。
正しく起動している場合、Upと表示され、起動しているプロセスが表示されます。
2018-12-24 09:04:55 INFO zookeeper_session.py:113 cluster is attempting to connect to Zookeeper
2018-12-24 09:04:55 INFO cluster:2634 Executing action status on SVMs 192.168.XX.XXX,192.168.XX.YYY,192.168.XX.ZZZ
The state of the cluster: start
Lockdown mode: Disabled

        CVM: 192.168.XX.XXX Down


        CVM: 192.168.XX.YYY Up, ZeusLeader

                                Zeus   UP       [6572, 6602, 6603, 6604, 6652, 6670]
                           Scavenger   UP       [7504, 7533, 7534, 7535]
                       SSLTerminator   UP       [9725, 9766, 9767, 9768]
                      SecureFileSync   UP       [9729, 9785, 9786, 9787]
                              Medusa   UP       [9958, 9996, 9997, 10002, 10558]
                  DynamicRingChanger   UP       [10816, 10867, 10868, 10953]
                              Pithos   UP       [10820, 10883, 10884, 10935]
                              Mantle   UP       [10824, 10932, 10933, 10971]
                                Hera   UP       [10844, 10929, 10930, 12192]
                            Stargate   UP       [11115, 11144, 11145, 11146, 11147]
                          InsightsDB   UP       [11382, 11416, 11417, 11488]
                InsightsDataTransfer   UP       [11386, 11477, 11478, 11518, 11520, 11522, 11523]
                               Ergon   UP       [11397, 11457, 11458, 11459]
                             Cerebro   UP       [11425, 11524, 11525, 11650]
  ・・・

メンテナンスしたホストのCVMがDownからUpに変わるまで、待ちましょう。

では、最後にメンテナンスモードになっていたホストに、メンテナンスモード解除のコマンドを実行します。こちらは、任意のCVMから、acliで以下のように実行します。
host.exit_maiuntenance_mode 192.168.XX.XXX

最後にきちんとメンテナンスモードから抜け出せたかを確認しておきましょう。
host.list
Schedulableが、Trueになっていることを確認します。
Hypervisor address  Host UUID       Schedulable  Hypervisor Type  Hypervisor Name
192.168.XX.XXX      003dc913-XXX..  True         kKvm             AHV           
192.168.XX.YYY      349bfb31-YYY..  True         kKvm             AHV           
192.168.XX.ZZZ      2e5422d5-ZZZ..  True         kKvm             AHV

きちんとTrueになっているので、メンテナンスモードは解除されています。

以上で、ホストメンテナンス時のメンテナンスモード設定と解除方法になります。

なお、AOS5.10.0.1+AHV20170830.184の環境においては、ホストの再起動はPrism画面から行うことができます。

しかし、クラスターを停止せずに一部のホストをメンテナンスする場合(例えばメモリー増設)は、今回ご紹介したようにメンテナンスしたいホストをメンテナンスモードに移行してシャットダウン後に作業を行うことで、クラスターは活性のままででのメンテナンス作業を行うことができます。

なお、この記事を書いた後に、@gowatanaさんの記事と一部内容が重複していたことに気づきましたが、ここまで書いたので予定通り公開いたします。
※私の検証している環境は、純正のNX環境(商用版)で行っておりますが、AHVの手順等はCEでも商用版でもオペレーションに基本的に違いはありません。
なお、@gowatanaさんの記事はこちらですので、あわせてご覧ください。
Nutanix AHV のメンテナンス モード。



さて、今年も無事にクリスマスを迎えることができました。
来年はもっとAdvent Calendarに参加する人が増えると嬉しいなと思っています。
(でないと、負担が...)

では、皆様よい年末をお過ごしください。





2018年12月24日月曜日

Nutanixの様々な自動通知機能を紹介

この記事はNutanix Advent Calendar(1枚目) 2018/12/24の記事です

Nutanixには、障害通知などを通知する機能を標準で搭載しています。
また、リモートサポートを迅速に行う機能も搭載されています。
今まで各機能紹介や名称は、時折簡単に紹介をしておりましたが、今一歩深くご紹介をしたことがありませんでしたので、今回はこれら機能について紹介いたします。

まず、Nutanixには2つの通知機能があります。

Pulse

パルスと読みます。Nutanix Pulseは、診断システム(NCC)のデータをNutanixサポートチームに提供します。Pulseは、システムのパフォーマンスに影響を与えることないように設計されており、自動的にこの情報を収集します。(オフにすることもできます)
Pulseは、Nutanixクラスタの正常性と状態を監視するために必要な基本的なシステムレベルの情報のみを共有します。IPアドレスや各種アカウント情報は、送信されません。
送られた情報をもとに、サポートが対応するため、サポート連絡時にAOSのバージョンやハイパーバイザーのバージョンなどを毎回ヒアリングされることなく、そのままサポート業務に入ることができるため、迅速なサポートを受けるためにも一役を買っています。

Pulseの設定画面
(Pulse自信をオフにすることも可能ですし、送信する情報を制限することも可能)



Alert

アラートはNutanixにイベントの種類、問題イベントの説明(たとえば、電源切断)を識別するいくつかの変数を含むアラートイベントの基本情報を送信します。アラートには、クラスターID、NOS / AOSのバージョン、およびコントローラーVMのIPアドレスも送信されます。
なお、AlertをNutanixサポートに送信する設定をした際、重要なエラーに関してはNutanixから自動的にCase(サポートインシデント)が発行され、サポートから連絡が来る仕組みになっております。

Alertの設定画面
(アラート情報をNutanixサポートには送らず、自社のみにメールで通知させることも可能)



ドキュメントによっては、Pulseが障害情報を通知するものと記載されているものがありますが、実際には、Pulseは統計・環境情報しか送信されず、実際の障害等が発生した際の通知は、Alertの設定をしておかなければなりません。

また、Nutanixの障害時に迅速な対応をするために、Nutanixサポートが遠隔操作をするための機能があります。

RemoteSupport

Nutanixのサポートが直接CVMにアクセスできるようにするための機能です。
通常は無効になっており、ユーザー側で有効にしない限り自動的に有効になることはない。なお、有効にした場合、有効期限時間を設定する必要があり、その期限を過ぎると自動的にRemoteSupport機能はオフとなります。

RemoteSupportにおいては、日本ではWebEXを利用したメンテナンスを行う方法が多くこのRemoteSupport機能は利用されている話をあまり聞きませんが、機能としては実装済みであり、日本国内であってももちろん利用可能です。
また、セキュリティに配慮し、ユーザー側でオンにしないと有効にならず、自動的にオフになるというところは、ユーザーのセキュリティ意識に配慮された設計と考えられます。

では、これらの通信環境について見ていきましょう。
まず、PulseもAlertも原則CVMがインターネットに接続されている必要があります。

では、各機能におけるNutanixへの通信を見ていきます。

この図を見るとわかる通り、まずCVMがインターネットに接続されていることが前提となります。インターネットに接続できない場合は、AlertとPulse機能は、SMTPサーバーを指定することにより、サポート情報を送付することができます。

SMTPサーバーの設定
(SMTPの通信モードはPlainのほかにSTARTTLSとSSLに対応)


ここで1つ注意事項があります。
insightsは、HTTPSの通信のため、UTMやFirewallからは、443/TCPの解放だけで構いませんが、nsc01とnsc02の通信は、80/TCPと記載がありますが、これはHTTP通信ではなく、SSH通信となります。
そのため、UTMやFirewallで、80/TCPや8443/TCPを開放することが必要ですが、WebフィルターやIPS機能などが有効になっていると、SSH通信をブロックされる可能性があります。そのため、UTM装置がインターネット接続の間に設置されている場合は、このnsc01とnsc02の通信に関しては、WebフィルターやIPS機能をオフにしておくことが重要です。

接続される先はわずか3サイトだけで完了しますので、Firewall等のゲートウェイ装置の設定変更箇所はわずかではありますが、Nutanix設置後は忘れずに、PulseやAlertの設定と通信確立ができているかを確認しましょう。

PulseやAlertの詳細は以下の情報が参考になるかと思います。
(Support Portalにアクセスできる環境が必要です)

Nutanix Support Services: Pulse and Alerts
https://portal.nutanix.com/kb/2595

Information collected by Pulse.
https://portal.nutanix.com/kb/2232

Which Alerts Automatically Generate a Support Case with Nutanix Support?
https://portal.nutanix.com/kb/1959


クリスマスまであと1日、明日も私が担当です...。


2018年12月17日月曜日

PrismCentalの使いどころ(その12)ダッシュボードを自分で作成する

この記事はNutanix Advent Calendar(1枚目) 2018 12/17の記事です

PrismCentralを一番最初に開くと表示されるダッシュボード。
このダッシュボードは、PrismProライセンスを保有している場合、自分流のダッシュボードを複数作成したり、既存ダッシュボードにウィジェットを追加することができます。

では、実際に自分流のダッシュボードを作成してみましょう。
まずは、「Manage Dashboards」をクリックします。

現在はDash Boardsがデフォルトしかありませんので、「New Dashboard」で追加します。

そのまま、ダッシュボードに名前を入れてSaveをクリックします。

新規で作成されたダッシュボードは何もウィジェットが入っておりませんので、「Add Widgets」をクリックし、ウィジェットを追加します。

画面左側に、登録できるウィジェットが表示されます。
真ん中にはウィジェットのプレビュー、右側には、CUSTOME WIDGETを選択した場合、表示をフィルターしたい内容をフィルター可能です。

ウィジェットで登録できる内容は以下の通りです。

CUSTOM WIDGETS
Custom Alerts Widget
Top Lists Widget
Custom Chart Widget
Cluster Info Widget
CLUSTER WIDGETS
Cluster CPU Usage
Cluster Latency
Cluster Memory Usage
Cluster Quick Access
Cluster Runway
Cluster Storage
Controller IOPS
Impacted Cluster
VM Efficiency
Performance
Tasks
reports
APP WIDGETS
Deployed Applications

ウィジェットを登録して、右上の×もしくは、右下の「Or, Add & Return to Dashboard」をクリックすることで、作成したダッシュボードが表示されます。

作成したダッシュボードに配置されているウィジェットは、マウスのドラック&ドロップで自由に位置を変更できます。


仮想マシン個別のパフォーマンスなどチャートの情報を出すことはできませんので、あくまでもダッシュボードレベルとはなりますが、ウィジェットのリンクからダイレクトにそのオブジェクトにアクセスできますので、上手に活用するとメニュー操作なしに簡単に欲しい情報までアクセスができるようになります。

明日は、NutanixのOEMであるDell XCの情報をたくさんお持ち(私も色々教えてもらっています)の@makotoさんです!




2018年12月11日火曜日

Nutanixの新しい試験体系2018年版をあらためて確認

この記事はNutanix Advent Calendar(2枚目) 2018 12/11の記事です

※この記事は2018年現在の資格制度情報です。2020年~2021年の資格制度は、「2020年(2021年度版)Nutanix資格試験制度について」を御確認ください。

Nutanixの試験制度は、昔からあったのですがこの2018年に試験内容や試験名称などが大きく変わりました。
今回は、この試験の名称やそのカバレッジ範囲、受験対象者などの情報をみていきたいと思います。

まずは、エンジニア向けにオープンな資格です。

NCP(Nutanix Certified Professional)
Nutanixのコアコンポーネントの理解を問われる内容が中心に出てくるNutanixの登竜門的な資格です。VMware Certified Professional(VCP)のように、Nutanixを使うにあったってい理解しておくべきことを問われる問題が多数出ます。
試験は全てオンラインで行われます。(全て英語)
2019年1月末までは、1回まで無償で受験することができます。


NCAP(Nutanix Advanced Certified Profesional)
NCPのさらに上の問題。メトロアベイラビリティなど、高度な機能が多く問題に出題される傾向です。また、実際の運用をベースにして、最適解を求められるような問題も出題されるため、ただの技術というよりかは、実践のスキルが必要となります。
試験は全てオンラインで行われます。(全て英語)
NCAPは、まだ正式リリースされていないため現在は受験することはできません。


NPX(Nutanix Platform Expert)
エンジニア系における最高峰の試験。
NPXトレーニングは全て英語で、かつ、試験官からのお題に対してプレゼンをする必要があるなどかなりハードルが高い試験内容です。試験官の当たり外れもあるように思いますが、英語でのプレゼントなるため日本人にとってハードルは高いものになります。

NCP→NCAP→NPXは、Nutanixのパートナーの有無に関係なく受験ができる試験となります。

これ以下は、Nutanixのパートナー向けつまり、Nutanix Partner Network(NPN)に提供される試験体系です。
まずは、エンジニア向けからです。


NCSE(Nutanix Certified Systems Engineer) Level.1
Nutanixを販売するSE、つまり、セールスエンジニアやプリセースルエンジニア向けに提供される試験です。オンラインのビデオとそれに付随した内容が約60問の試験になって出てきます、昔はNSESと呼ばれていたレンジにものになるが、問題はセールスにおけるテクノロジーの紹介が中心となっています。


NCSE(Nutanix Certified Systems Engineer) Level.2
まだリリースされていないため、全容は不明ですが、おそらくNCSE Level.1の次のステップに当たると思います。

NPNパートナーSE向けの試験は現在、NCSE Level.1しか提供されていません。



次に、コンサルティングパートナー向けのものを紹介します。

NCPI
こちらは、試験というよりもトレーニングを受講することで取得できる資格です。
Foundationの実施による初期キッティングから、vCenter ServerやSCVMMの基本的な設定のお作法を中心に学習するコースです。


CCIC (Core Competency Install & Config)
CCICは、Nutanixパートナーがオンラインで学習できるトレーニングになります。
ラッキングや初期の設定方法などNCPIの内容と合わせて学習することで導入に関する内容が主となります。トレーニングは2日間です。


NCS(Nutanix Consulting Specialist )
Nutanixコンサルティングスペシャリストとしてのデプロイメントやマイグレーションなどを学習するトレーニングです。トレーニングは4日間で、このトレーニングとテストを受けることで、NCSの認定を受けることができます。

では次にパートナー向けの営業向けトレーニングをご紹介します。

NCSR(Nutanix Certified Sales Representative) Level.1〜3
Nutanixの営業向けのトレーニングです。販売の仕方(構成)や事例などを学び、Nutanixの基本を語ることができるスキルを身につけることができます。


NCSX(Nutanix Certified Sales Expert)
営業のスペシャリスト向けの問題です。現在受験できるかは不明...


業種別に簡単にまとめると以下のようになります。

エンジニアリングが伴うものは、どの業種であっても、NCPが必要になります。
最後にNPXが関わってくるもつらいのですが、そういう流れのようです。
コンサルタントをやりながら、エンジニアリングをするのであれば、NCAPも状況によって必要になってくるでしょう。
こう考えると、トレーニングや試験制度は充実していますが、上を極めるにはかなりハードルが高くなっていることも事実です。
Nutanixの販売パートナーであるNPNは、このルールに準じて、パートナーレベルに応じた必要なトレーニングや資格を取得する必要があります。

明日は、私の指導者でもある@gowatanaさんです。






2018年12月10日月曜日

PrismCentalの使いどころ(その12) PrismCentral 5.10のメニューを確認する

この記事はNutanix Advent Calendar(1枚目) 2018 12/10の記事です

PrismCentralを紹介して数ヶ月がたちましたが、11月末にPrismCentral 5.10がリリースされました。
このPrismCentral 5.10は、画面が大幅に変わっています。

新しくなった画面をご紹介します。

まず、いままでは、「ホーム」「探索」「計画」「分析」「Calm」「アラート」という項目でいました。
仮想マシンのオペレーションやクラスターの情報、レポート作成など大半のオペレーションは「探索」(Explore)から行っていましたが、この探索メニューがそもそもなくなりました。

では、新しいメニューを見てみましょう。


まず大きな変更としてメニュー画面が、横から縦に変わりました。
ここから大きな変更なのですが、カテゴリも大きく変わっています。

探索メニューにあった物は、かなり細かく分散されて、再カテゴリ化されています。
では、まず仮想インフラから見てみましょう。


■仮想インフラメニュー

ここでは、仮想マシンを始め、ストレージコンテナやイメージサービスの設定が可能です。回復可能なエンティティは、どうやらXi Leapもしくは、PlayBook機能と連携して使うようです。
カテゴリは、Flowで利用していたカテゴリがこちらに動いています。今後はFlow以外でもこのカテゴリは利用される可能性が高いです。


■ポリシー

ポリシーは様々なポリシー周りが全部まとまっています。
セキュリティーポリシーはFlowで利用、保護ポリシーとリカバリープランは新たに機能追加されたXi LeapとNutanixでのRunBookによるDR構築時に利用するようです。
NGTポリシーはPrismCentral 5.9であたらに追加されたNGTのオートインストールと再起動のスケジュール設定ポリシーが作成できます。


■ハードウェア

ハードウェアの項目は今までの探索にあったハードウェアの項目が集まっているだけです。クラスターやホスト、ディスクにvGPUも見ることができます。


■アクティビティ

アクティビティは、アラートやタスクなど、障害発生時やそのほかクラスターの挙動を見る際に利用する物が集まったメニューとなっています。


■オペレーション


オペレーションは、分析(チャート画面)、計画は、今までの計画タブのシナリオ、計画はランウェイの画面に行くことができます。レポートは今まで、探索のレポートメニューがこちらに動いています。

■管理

こちらは、主にSelfServicePortalで利用する、プロジェクトやロール、ユーザーの設定ができます。アベイラビリティゾーンは、SelfServicePortalと異なり、Xi LeapなどでDRを設定する際にゾーン設定を行う画面です。


■サービス

サービスが、Nutanixの機能であるCalmとKarbonのメニューがこちらにまとめられました。Karbonは、PrismCentralの別ポートで別画面が稼働しており、実質的にはこのPrismCentralの画面に完全にインプリメントされているわけではありません。


今日は、PrismCentral 5.10の画面についてみていきました。
画面が変わって、あれっと思ってもメニューの構造だけをもう一度把握すれば、今までのスキルはそのまま活用可能ですから、恐れることなく、使っていきましょう。

明日は、Nutanix Technology Championで、私もお世話になっている@hiroito1118さんです!








2018年12月8日土曜日

Nutanixの製品群をおさらい

この記事はNutanix Advent Calendar(2枚目) 2018 12/8の記事です

Nutanixといえば、HCIの会社というイメージが強いかもしれません。Nutanixは、たしかにHCIを作った会社ではありますが、HCIはNutanixのコンセプトであるインビジブルインフラストラクチャーを実現する一つの手段に過ぎません。

エンドユーザーが欲しいものは、高速なストレージでも、ハイパフォーマンスなサーバーでもない。アプリケーションを満足に使える環境がほしいだけ。Nutanixは、そんなエンドユーザーの本来の目的のために、インフラを気にせず、アプリケーションに集中できる環境を提供したいというコンセプトからできています。これをインビジブルインフラストラクチャーという言葉で表現しています。

Nutanixは、オンプレミスを中心に今までは展開してきましたが、昨今様々な製品が増えており、あまりなじみのない名前の製品も耳にすることが増えてきました。

今日は最近お目見えした製品の名称とどんな製品なのかを簡単にまとめてみましょう。

Acropolis HCI Plarform

皆さんご存じのHCIのNutanixです。
Nutanixと表現する場合これを指すことが多い。

AHV

Nutanixが提供するKVMをベースとしたハイパーバイザー。
このハイパーバイザーは原則Nutanix HCI Platformの上のみで動作します。(AHV単体での利用はできません)
なお、昔はAcropolis Hypervisorとよばれていましたが、2017年よりAHVが正しい読み方となる。


Nutanix Files

Nutanixが提供する無停止拡張に対応したファイルサーバー。
CIFS3.0の他にNFSにも対応しする。Nutanix HCI Platform上でのみ動作する。
なおハイパーバイザーは、AHVとvSphere ESXiに対応。


Nutanix Volumes

昔は、Acropolis Block Servicesと呼ばれていた機能。
Nutanix HCI Platform上で提供される、Nutanixのストレージの一部をNutanixの外部にあるサーバーにiSCSIでディスクボリュームを提供する機能。


Nutanix Buckets

Nutanix HCI Platform上で提供される、S3互換のオブジェクトストレージ機能。
今日現在まだリリースされていないがまもなくリリース開始の見込み


Flow

Nutanix HCI PlatformとAHV上で動作する、仮想マシン単位でのファイアーウォール機能を提供する。Flowライセンスを別途手配する必要がある。なお、画面オペレーションはPrism Centralを利用する。


Calm

仮想マシンのデプロイメントを自動化するオートメーションツール。
PrismCentralでオペレーション画面が提供される。Calmのラインセンスは展開される仮想マシン台数によってきます。25VMまで無償で利用できる。


Era

Databaseのコピーマネージメントツール。
初期バージョンはOracleとPostgreSQLの自動展開、自動バックアップの取得、スナップショットによるクローンDB作成など、DBにおける構築と運用作業をGUIで大幅に楽にすることができるDB管理ソフトウェア。AWSでいう、RDSに近い機能を提供。


Karbon

kubernetesの自動展開や運用機能をサポートする。
PrismCentralからUIが提供される。


Nutanix Xi

Nutanixが提供するクラウドサービスの総称。


Xi Beam

マルチクラウドの管理、セキュリティポリシーの監査、コスト試算などを行う、クラウドマネージメントツール


Xi Epoch

マルチクラウドにおけるネットワーク通信を可視化するツール。
マイクロサービスの通信やL7レベルのエラーを可視化することで、ネットワークトラブル時の解決を早めることが可能になる。


Xi Frame

Nutanixが提供するDaaSサービス。
クライアントは、WebブラウザでH264エンコードで画面転送される。
なお、VDIインスタンスは、GCPかAzureが選択可能。


Xi IoT

昔はProject Sherlockといわれていた。IoTセンサーデバイスからの送られてくる情報を、処理・精査し適切なところにデーターを保存させるセンサーゲートウェイの機能をもつ。
IoTセンサーから送られたデーターにAIの処理を挟ませたり、顔識別をさせたりなどの、各種処理をプログラムベースで埋め込むことが可能。


Xi Leap

Nutanix HCI Platformで稼働している仮想マシンを、クラウド上でDRできるサービス。


なんだか、覚えにくかったり製品名からイメージしづらい物もありますが、あれなんだっけ?と思ったら是非このページをもう一度見直してみてください。


明日は、私がいつもお世話になっている@hanakara_milkさんの投稿です!



2018年12月3日月曜日

Nutanixにかんするウワサを検証その5

この記事はNutanix Advent Calendar(1枚目) 2018/12/1の記事です
今回はNutanixに関する、ちまたで流れているウワサとその答えを紹介していきたいとおもいます。

ウワサ1
Nutanixは、RF3(データー三重書き込み)でないと、データーロストする可能性が高い

真相
ウソ

はっきりいって、全くのデタラメです。
Nutanixは、データーを二重書きするRF2が標準で、5ノード以上ある場合はRF3で構成することができます。
Nutanixは、ストレージの機能がかなり強いことで有名です。Nutanixのコア機能はストレージ機能と言ってもよいかもしれません。
スケジュール設定ができるストレージスナップショットの機能やレプリケーションは、高度なストレージ機能であることを象徴しています。
Nutanixは、パフォーマンスよりもデーターの保全性を大事にする作りになっており、データーロストはそう簡単に起きるような物ではありません。


ウワサ2
Nutanixは、AHV以外のハイパーバイザーは動作しない

真相
ウソ

これもウソでしかない話ですね。
Nutanixは、AHVはもちろんですが、vSphereやHyper-V、Citrix Hypervisorに対応しています。これはユーザーさんに使い慣れたハイパーバイザーをそのまま使っていただき、Nutanixの良さに触れていただくという、選択の自由というコンセプトから来ています。
好きなハイパーバイザーを選べるのがNutanixのメリットであり、これを制限するとNutanixのコンセプトから外れてしまいます。


ウワサ3
Nutanixは、ソフトウェアなのでストレージの信頼性が低い

真相
ウソ

これは、もはや昨今のストレージ事情を知らないとしか言えないウワサです。
昨今はネットワークなどを含めSDx(ソフトウェア定義)が非常に流行っています。
そもそもストレージ専業メーカーのストレージコントローラーも、IntelCPUが搭載されており、Linuxの上で動いている物も多くあります。
つまり、最近のストレージはソフトウェアで動いています。
コントローラーが別のハードウェア筐体になっているか、仮想アプライアンスで動いているかの違い程度でしかないでしょう。
信頼性は、ソフトウェアだから低いというのは、昨今のストレージの構造を考えると理屈的に間違っていることがわかります。


ウワサ4
Nutanixのワンクリックアップグレードは高い確率で失敗する

真相
ウソ

アップグレードに対するプロセスは、確実に失敗しませんとは言えませんが、失敗はかなり少ないです。それには理由があります。
アップグレード前に、アップグレードができる状態かを確認するPreUpgrade処理が行われ、アップグレード処理ができるかを確認しています。
このプロセスが通過できない場合そもそもアップグレードはできません。
そのため、アップグレードに失敗してクラスターが停止するといったことは起きません。



ウワサ5
AHVは、信頼性が低く本番用途では、使い物にならない

真相
ウソ

AHVは、KVMをベースにしていますが、ライブマイグレーションはもちろん、HAの機能や仮想マシンのリソースを平準化するADSという機能を搭載しており、エンタープライズな環境でも十分に利用できるハイパーバイザーです。
AHVについては、こちらを見ていただくと参考になるとおもいます。
なおAHVは、公共や医療、製造業など様々な業種で利用されており、その信頼性の高さはこの実績からもわかるかとおもいます。



今回も5つのウワサを解説しました。
新しい製品となるとどうしても根も葉もないウワサが飛び交う物ですが、正しい情報を入れることが大切ですね。






2018年12月1日土曜日

AOSアップグレード前に/home/nutanixをチェックする

この記事はNutanix Advent Calendar(1枚目) 2018/12/1の記事です
AOS5.10がLTSバージョンとして、11月末にリリースされました。
年末が近いこともあり、年末年始でインフラ周りのメンテナンスの際に、AOSアップグレード行う方も多くいるかと思います。
まあ、そもそもAOSはシステム稼働中であったとしても安全にシステムを止めることなくアップグレードすることができます(業務がフル稼働中にあまりやる作業ではありませんが)ので、そんなにかしこまってやる作業ではないのですが、従来のシステムメンテナンス形態を取られているデーターセンター等では、今までのルールに則り、業務外の時間にメンテナンス時間を作成し作業をされる方が多いと思います。

さて、AOSのアップグレード時に注意する事項が一つあります。
それは、「/home/nutanix」の容量枯渇です

Nutanixを長く利用していますと、いろいろな物がたまってくることと、AOSバイナリは今は4GBを超える大きな容量であるため、AOSアップグレード前チェックで/home/nutanixの容量不足でアップデートが失敗することがあります。

(参考)/home/nutanixの容量が枯渇すると、OneClickUpgradeに失敗します

この際にお掃除するべきは、/home/nutanixです。

まずは、消費しているディレクトリを確認します。
SSHでCVMにログインします。

まずは、使用容量を確認します。
nutanix@NTNX-1-B-CVM:X.X.X.X:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        9.8G  6.0G  3.3G  65% /
devtmpfs         16G     0   16G   0% /dev
tmpfs           512M  4.0K  512M   1% /dev/shm
tmpfs            16G  640K   16G   1% /run
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/loop0      240M  3.1M  221M   2% /tmp
/dev/md2         40G   24G   15G  62% /home
/dev/sdb4       600G   82G  513G  14% /home/nutanix/data/stargate-storage/disks/BTHC6490032S800NGN
/dev/sda4       600G   82G  513G  14% /home/nutanix/data/stargate-storage/disks/BTHC648105XJ800NGN
/dev/sdc1       660G   85G  568G  13% /home/nutanix/data/stargate-storage/disks/BTHC64810ABU800NGN
tmpfs           3.2G     0  3.2G   0% /run/user/1000

この環境では、/home/nutanixが、62%の使用率ということでまだ余裕ですが、実際の環境では長く使っていると90%を超えていることもよくあります。

この際のお掃除をすべきディレクトリは以下のディレクトリ配下です
/home/nutanix/data/cores/
/home/nutanix/data/binary_logs/
/home/nutanix/data/installer/
/home/nutanix/data/ncc/installer/
/home/nutanix/data/log_collector/
/home/nutanix/foundation/isos/
/home/nutanix/foundation/tmp/


ここで、注意が必要です。
まず、これらはこのディレクトリ配下のファイルやディレクトリを消す必要があります。
このディレクトリを直接消してはいけません。

/home/nutanix/data/installer」は、現在インストール使用としているAOS5.6バージョンのバイナリ以外を消す必要があります。

/home/nutanix/foundation/isos/」は、使っていないハイパーバイザーのバイナリだけを消してください。

なお、「df -h」で見ていると「/home/nutanix/software_downloads/」も容量
を多く使ってくる一覧で上がってきますが、こちらは、OneClickUpgradeの画面で管理されている関係から、直接ファイルを消すことは禁止されています。


またこのディレクトリ配下のファイルもお掃除対象です
/home/nutanix/data/binary_logs/*
/home/nutanix/data/cores/*

こちらは、このディレクトリ配下のディレクトリは削除せず(当然このディレクトリも削除してはいけません)にファイルだけを消す形になります。

なお、CVMはノードの数だけありますが「allssh」でrmコマンドを実行すると、がっさりきえてしまいますので、面倒かもしれませんが、1台ずつ確認しながらファイルを消すことをおすすめします。

詳細は以下のKBを参考にしてください。
http://portal.nutanix.com/kb/1540