PrismのパスワードポリシーとAD連携の方法

Prismのパスワードポリシーは昔は結構緩かったのですが、AOS5.8現在では、以下のようなパスワードポリシーがデフォルトで設定されております。（おそらくこれを緩くすることはできない気がします）

• 8文字以上入力
• 少なくとも1つの小文字を含む
• 少なくとも1つの大文字を含む
• 少なくとも1桁の数字を含む
• 少なくとも1つの特殊文字を含む
• 以前のパスワードと少なくとも4文字異なる
• 最新の5つのパスワードと同じでないこと
• 2つ以上の連続する文字が同じではないこと
• 次の4つの文字条件のうち少なくとも4つを含むこと
  （大文字、小文字、数字、および特殊文字）
• 簡単な言葉でも、辞書で登録されていない単語であること

かなり制約が多いです。

この制約を無視してアカウントを管理する方法の1つとしてAD連携の方法があります。
AD連携によるアカウント管理は簡単にできます。

まずは、AdminユーザーでPrismにログインし歯車メニューから「Authentication」を選択します。

ADを登録するので、「New Directory」 をクリックします。

ADの登録情報を入力します。ADの参照のため、あらかじめCVMが参照するDNSもADのDNSに向けておく必要があります。

これでADの登録ができました。

ちなみに、Authentication Typeを選択すると、ローカルユーザーかDirectory Serviceかの認証方法を制限することができます。

あとは、ユーザーやOUごとにPrism側の権限設定を行っていきます。
Prismの歯車メニューから「Role Mapping」を選択します。

新たにロールを追加しまので、「New Mapping」をクリックします。

ユーザーの登録を行います。

ユーザーやOUなどの入力は手入力となりますので間違えないように注意が必要です。

登録すれば、これで設定は終わりです。

実際にログインをしてみましょう。
ログイン時は、ユーザー名＠ドメイン名というUPN形式で入力をします。

これで普通にPrismにログインができます。

AD連携をすると、パスワードポリシーをADに委ねることができますので、難しいパスーワード管理が不要になることと1つのパスワード管理でよくなるという点は非常に便利です。

Nutanixにおける暗号化(Data at Rest Encryption)の紹介（その2）

前回は暗号化の機能についてみていきました。
今回は、AOS5.8で利用できるKMSもAOS内に含めた形の暗号化機能の設定方法についてみていきたいと思います。

まずは、Prismを開き、歯車ボタンから「Data at Rest Encryption」を選択します。

暗号化の設定は現在されておりませんので、Edit Configrationをクリックします。
また画面真ん中の2つの丸が描かれている部分も注目しておいてください。

設定画面が表示されたら、今回はAOS5.8で搭載されたAOSだけで完結する暗号化機能を利用するため「Cluster's local KMS」を選択します。
※外部のKMSを利用する場合は、「An external KMS」を選択します。
選択後、「Save KMS Type」をクリックします。

その後表示される「Enable Encryption」をクリックすると暗号化するために「ENCRYPT」と入力巣をする旨が表示されますので、その通りに（ENCRYPT）入力後Encryptボタンをクリックします。

先ほどの画面に戻ると丸のとろこに鍵マークが表示されています。
これは暗号化設定が完了したことを意味しています。

暗号化設定が完了

なお、KMSの設定を行って最後にEnable Encryption設定を行わないと、以下のように鍵が銀色で表示されます。

暗号化の設定は、実はこれだけです。
今までのKMSの設定や各種パラメーターの不要でさくっと暗号化ができるのは大変便利です。

なお、この暗号化機能はUltimateラインセンスもしくはSelf Encrypting Drives Passwordのライセンスが適用されていない場合、最後のEnable Encryptionボタンが押せないようになっていますので、ライセンスの手配と適用もお忘れなくどうぞ。

Nutanixにおける暗号化(Data at Rest Encryption)の紹介（その1）

Nutanixには、仮想マシンからの書き込まれるデーター等をを暗号化する機能を持っています。この機能がAOS5.6以降、徐々に進化しいよいよ最終形に近い形となりました。
今回はこの暗号化機能について紹介したいと思います。

まずは、暗号化(Data at Rest Encryption)を行うパターンの種別を見ていきましょう。

パターン1（SEDとKMS）
これはNutanixで古くから対応している暗号化形式です。
SEDディスクとは、データーを書き込む際に暗号化に対応した専用のディスクとSSDで、暗号化を行う場合、このSED対応のディスクをあらかじめ購入する必要があります。
また、鍵管理サーバーとしてKMSをNutanixの外に展開しておく必要があります。
（SEDとは、Self Encrypted Diskの略です）

このパターン1は、最もコストがかかり、かつNutanixのソリューションだけで完結することができないというのが特徴です。

この課題から生まれたのがパターン2と3になります。


パターン2（SED不要の暗号化）
パータン1は、やはり専用のディスク（SSD）とKMSという、コストがかかると言うことが課題でした。
そのため、AOS5.6でSEDを採用せず、通常のDiskやSSDで暗号化されたデーターを書き込むようにソフトウェアで処理できる機能が搭載されました。
これにより、今まで暗号化していなかったNutanix環境を暗号化したいと思ったときに、SEDディスクに買い換える必要なく、そのまま暗号化できるようなり大変自由度があがる構成ができるようになったと思います。
ここでの課題は、KMSは、まだ外出し（かつサードパーティー製品）が必要であるということでした。


パターン3（SEDもKMSも不要）
パターン2の課題は、KMSを別途用意するということでした。
KMS自身はサードパーティー製がいくつかありますが、どれがどう対応しているかのコンパチビリティの確認や、そもそもNutanixだけで完結しないと言うことは、シンプルではないというNutanixのコンセプトに合わない問題がありました。
そこでKMS機能もAOSの機能として保有し、そもそも気軽に暗号化ができるようにしようという機能がAOS5.8で搭載されました。
暗号化が必要になったタイミングで、Prism画面をちょちょっと操作するだけでデーターの暗号化ができるようになるという、大変自由度の高い機能が搭載されました。


では、このAOS5.8で搭載された暗号化（Data at Rest Encryption）の機能についてもう少し細かく見ていきたいと思います。

• データーは完全に暗号化され、ディスクを抜いてそれを読み込んでも読める状態にはなりません。
• 暗号化されていてもパフォーマンスが悪くなることはありません
• 暗号化機能は、いつでも無効にすることができます
• 暗号化機能（Data at Rest Encryption）は、UltimateライセンスもしくはAddOnライセンスを手配する必要があります。
• AHVの場合、クラスター構成後に暗号化設定を行う必要があります。
  （仮想マシンの作成やImageServiceにイメージを登録後の暗号化設定はできません）
• ESXiやHyperVは、ストレージコンテナ単位で暗号化を行います。
  そのため、新たにからのストレージコンテナを作成し、暗号化設定を行うと、空のストレージコンテナが暗号化されたコンテナとなります。
• 最低3ノード以上のCVMが稼働するNutanixクラスターが必要
• ドライブ上にあるデータセキュリティを強化しますが、CVM間の通信など、ネットワークを経由した転送中のデータは保護しません。

ここで重要なことは、まずAHVの場合は、クラスター作成後にすぐに暗号化設定をしないといけないということです。いろんな仮想マシンを稼働させた後、暗号化させたくなったとしてもAHVの場合はそのクラスターで暗号化を有効化させることができません。

vSphereやHyper-Vの場合は、途中からの暗号化は可能ですが、その時点で空のストレージコンテナにのみ暗号化してデーターが書き込まれます。

そのため、vSphereやHyperVの場合、暗号化の設定が終わった後に空のストレージコンテナに仮想マシンをストレージライブマイグレーション（Storage vMotion）を行うことで、データーが暗号化されます。AHVの場合、このStorage vMotionに相当する機能が存在しないため、このような仕様制限が出ていると思われます。

あと、2ノードや1ノードで構成されたNutanixにおいては暗号化機能を利用することはできません。

ライセンスもUltimateかAddOnライセンスでSelf Encrypting Drives Passwordのライセンスを購入する必要があります。

設定は簡単ですが、ちょっとした落とし穴もありますので、注意が必要です。

では、次回は具体的な設定について見ていきたいと思います。

AHV Turboモードによる高速I/O処理（その２）RHE7.2以降でAHV Turbo推奨利用の方法

前回はAHV Turboを利用するために推奨されるカーネルパラメーターがそもそも対応しているかの確認を行ってみました。
前回の記事通り、Redhat Enterprise Linux7.2(CentOS7.2)以降であれば、「scsi_mod.use_blk_mq」のパラメーターは利用可能となっていますが、デフォルトで無効になっています。

では、今回はこのパラメーターを有効にする方法をご紹介します。

まず、「scsi_mod.use_blk_mq」 は、カーネルパラメーターであることから、「/etc/sysctl.conf」に記載するイメージがありますが、このパラメーターは異なります。

このパラメーターはI/O処理にかかわるため、Linuxカーネル起動時に設定する必要があります。つまり、grubの設定に入れる必要があります。

では具体的に設定内容を見ていきたいと思います。

まず、grubファイルを編集します。

vi /etc/default/grub

もともとは以下のように記載されています。

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"
GRUB_DISABLE_RECOVERY="true"

これを以下のように変更します。
(GRUB_CMDLINE_LINUXに追加します）

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb scsi_mod.use_blk_mq=Y dm_mod.use_blk_mq=Y quiet"
GRUB_DISABLE_RECOVERY="true"

以下の2つのキーワードを、「GRIB_CMDLINE_LINUX」のquietより前に入れます。
挿入するパラメーター

• scsi_mod.use_blk_mq=Y 
• dm_mod.use_blk_mq=Y

パラメーターを追加後、作成したgrubファイルを適用する必要がありますが、Ubuntuでおなじみの「grub2-mkconfig」というコマンドをどうもCentOS(RHEL)では入っていないようです。
そのため直接GRUBファイルを作成するため、以下のコマンドを実行します。

grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

その後OSを再起動します。

reboot

さて再起動後にパラメーターが正しく反映されたかを確認します。

cat /sys/module/scsi_mod/parameters/use_blk_mq
cat /sys/module/scsi_mod/parameters/dm_mod.use_blk_mq

いずれも結果に以下のようにYと帰ってくれば正しく反映されています。

Y

これで、AHV Turboの対応は完了です。

さらに高速になったAHV Turboをぜひ体感してみてください。

AHV Turboモードによる高速I/O処理（その１）AHV Turboの推奨利用条件を確認

AHVにおけるI/Oのさらなる高速化技術として、AHV Turboモードがリリースされました。この機能によりAHVでのI/O性能が格段に上がると言われています。
Turboモードは（Frodo）という名前で開発されていたもので、今までQEMUを介してI/O処理をする部分をマルチキューで処理できるように変えたエンジンです。
アーキテクチャーの詳細は、こちらをごらんください。

機能的に早くなるのであればすぐ使いたいと思うのが人間の心理でありますが、この機能は標準で実装されていますが、LinuxOSの仮想マシンに対してAHV Turboを最大限に利用するためにあ一定の条件が必要となります。

その条件や実際の利用するまでのところを見ていきたいと思います。

AHV Turboの推奨利用条件

• AOS5.5以上（必須）
• Linux Kernel 3.17以上（もちろん4系にも対応）
• 仮想マシンのOSがLinuxのみ
• scsi_mod.use_blk_mqの有効化

という条件になります。

一つ目のAOSバージョンは特に問題が無いと思いますが、2番目のKernelバージョンの問題はちょっとややこしいです。Redhat Enterprise Linux(RHEL)はベースカーネルバージョンは、「3.10.0」(RHEL7.5の場合)であり、3.17に達していません。

ただ、そこはまり心配しなくても良いです。RHEL7.2から、「scsi_mod.use_blk_mq」の対応がなされていると記載があります。

（参考）RHEL7.2 リリースノート

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/7.2_release_notes/index#storage

ただ、こちらには、

「scsi-mq を有効にするにはカーネルコマンドラインで scsi_mod.use_blk_mq=y を指定します。デフォルト値は n (無効) です。」と書いてあり、デフォルトでは無効であることが記載されています。つまり手動で有効化する必要があります。

では、RHEL6系のユーザーやRHEL7.1までのユーザーの場合はどうすれば良いかというと、現状では、そのままの手法ではTurboモードは利用できません。

カーネルを新しいバージョンに入れ替える必要があります。

今回はこの「scsi_mod.use_blk_mq」を有効にするための手法を数回に分けてご紹介したいと思います。

まず、この「scsi_mod.use_blk_mq」が、現時点で有効かを確認してみたいと思います。

Linuxのシェル画面で、以下のコマンドを入力します。

cat /sys/module/scsi_mod/parameters/use_blk_mq

これを入力して、「そのようなファイルやディレクトリはありません」 と言われた場合は、そもそもカーネルバージョンがこのパラメーターに対応していない可能性が高いです。

以下のコマンドでカーネルバージョンを確認してみます。

uname -a

で、カーネルバージョンを確認してみましょう。

一方で、「Y」と出てきた場合は、scsi_mod.use_blk_mq=yが有効になっていますので、そのままAHV Turboが利用できている状態となります。
では、「N」と出てきた場合は、パラメーター設定をすることでAHV Turboを利用することができます。

次回は、このパラメーターの有効化についてお話ししたいと思います。

NutanixのVSS連携バックアップについて

Nutanixには、バックアップ機能が無いと思われている方もいますが、Nutanixはストレージベースのスナップショットを取得できる機能を保有しています。
装置内のスナップショットだけではバックアップにならないと思われる方もいるかと思いますが、Nutanixはスナップショットのレプリケーションが出来ますので、バックアップとして利用することが出来ます。

このスナップショット取得機能には、WindowsのVSSと連携して静止点を取得する機能があります。今回はこのVSS連携についてお話をしたいと思います。

VSSはご存じの通りWindows Server 2003以降に搭載された、静止点を取得するための仕組みです。これをNutanixからコールすることにより、アプリケーションの書き込みなどを一時的に止めて静止点（データーの書き込み途中といった状況が存在しないようにする）を作りその間にスナップショットを取得します。
これにより、リストアした際にデーターが壊れていたといったことを防ぐことが出来ます。

vSphereとバックアップソフトウェアの場合、vShereのスナップショット機能を利用して、静止点を取得しますが、Nutanixはマルチハイパーバイザー対応機器ですので、特定のハイパーバイザーに依存せずこのVSS連携によるスナップショット取得が出来るように独自の実装がなされています。

まず、VSS連携を利用するためには、

• 仮想マシンにNutanix Guest Toolsをインストール
• Nutanix Cluster VIPと2074/TCPで通信可能であること

が条件となります。

また、ABSを利用して外部からiSCSIのボリュームをマウントした物理マシンに対するiSCSIボリュームの静止点取得は出来ません。（Nutanix上で動作している仮想マシンかVolume Serviceを利用してiSCSIマウントしたボリュームは静止点の取得が可能です）

では、早速このVSSキックまでの動きを見てみたいと思います。
今回はAHVの環境(AOS5.6.1)に、Windows Server 2016をインストールしその上でSQL Server 2017 Standardが稼働する環境を用意しました。

1.VSSで静止点を取得したい仮想マシンにNGTをインストールします。

インストールの方法は簡単です。Prism画面からISOをマウントしてインストーラーに従います。少々古いですがインストール方法はこちらを参照してください。

インストールが終わったら、Windowsの仮想マシンにサービスが入ったことを確認します。(Self Service RestoreとGuest Tools Agentがインストールされている）

2.Nutanix Prism側で仮想マシンにVSSサービスを設定

Prismから、VSSを遊行したいか総マシンを選択し、Manage Guest Toolsをクリックします。

Enable Nutanix Guest Toolsと「Volume Snapshot Service / Application Consistent Snapshot(VSS)」にチェックを入れます。

これにより、VSS機能が利用できる状態となりました。

3.DataProtectionで、VSSキックを設定。

DataProtectionからいつものように仮想マシンを登録します。

仮想マシンを登録する際に「Use application consistent snapshot」にチェックを入れて「Protect Selected Entities」をクリックします。

この場合、仮想マシン名の後ろに「●」が表示されます。この●にマウスポインターを当てると、「The group targets application consistent snapshots.」と表示されます。

4.あとはスケジュールをまつだけ...

まつだけなのですが、実際に動作した場合に正しく動作しているかを確認してみましょう。

Nutanix側から7/1 10:39にスナップショット取得イベントを走らせました。

そのタイミングのイベントログを見ていると、Nutanix VSS Providerが呼ばれたことが記録されています。

10時39分31秒～44秒のあいだにVSSが動作したことがわかります。

PrismのDataProtection画面からスナップショットの時間を見てみると「10時39分44秒」であることがわかりますので、静止点を取得した後に、VSS Providerが停止したことがわかります。

では、SQL Serverのログも見てみましょう。

SQL Management Studioでログを見てみると、VSS経由でI/O処理が一時的に中断状態になったことが記録されています。

このログを見ると、10:39:42の時点で、I/Oの処理中断は解除され、バックアップに成功したと記録が出ています。これはこの時点での静止点取得が出来たことを表しています。

Nutanixのドキュメントには、VSSに対応しているという記載はSQL Server 2012までしか記載がありませんが、VSSの動作にきちんと対応していれば、基本問題なく動作することがこの事からもよくわかるかと思います。

VSS連携は、バックアップにおける基本機能ですが、このVSSを呼び静止点を取得できるバックアップ機能をNutanixは標準機能で装備しているので、別にバックアップソフトウェアを購入することもなくきちんとしたバックアップが出来るのは大きな魅力だと思います。

Redundancy FactorとReplication Factorの考え方

Nutanixを導入するにあたって、考えなければいけないことは、どこまでの障害を許容範囲とするかです。
これは、Nutanixに限らず、様々なHCIメーカーでも同様のことが言え、もっというと仮想化基盤の導入における基本の設計事項でもあります。

Nutanixにおいて、障害に対する考えか方は、２つあり、この２つをどう使うかというのをNutanix導入時にあらかじめ設計しておく必要があります。

では具体的にその２つを見ていきましょう。

Redundancy Factor

リダンダンシーファクターとは、 Nutanixのノードが何台落ちても稼働し続けるかという設定です。通常の仮想化環境の場合HAを構成する際にフェールオーバーホストを１台に設定することが多いかと思いますが、これは１ホストの障害までを許容する（１ホストダウンしても仮想化環境は動き続ける）という設定になります。
Nutanixにおいては、ホストのことをノードと呼びます。上記の１ホストの障害までを許容する場合、Nutanixの場合、「Redundancy Factor 2」 という設定を行います。
２ノードまでの障害を許容する（２ホストまで障害でダウンしても仮想化環境は動き続ける）場合は、「Redundancy Factor 3」を設定します。
従来Nutanixでは、Redundancy FactorはFoundationという初期設定時のみ設定が可能でその後の変更ができませんでしたが、AOS5になってNutanixクラスターが稼働後にも変更ができるようになっています。（ただし、Redundancy Factor 3からRedundancy Factor 2へ障害許容範囲を小さくすることはできません）
Redundancy Factor3を利用する場合、Nutanixのノードは最低５ノード必要となります。また、NutanixライセンスがPro以上が必要となります。またCVMのメモリーは24GB以上を設定する必要があります。

Redundancy Factorのイメージ

Redundancy Factorの操作は、Prismから簡単に変更可能

 現在の設定状態の確認と変更が可能

Redundancy Factorのまとめ

Redundancy Factor	ノード障害 対応数	必要 ノード数	Nutanix ライセンス	CVM メモリ	稼働後 変更
2	1	3〜	Starter以上	20GB〜	2→3 OK
3	2	5〜	Pro以上	24GB〜	3→2 NG

Replication Factor (RF)

レプリケーションファクターとは、Nutanix上で扱うデーターの冗長数を表します。
ドキュメントやPrism上の表現上では、「RF」と略称で掲載されることが多々あります。
Nutanixは、古来のデーター冗長化であるRAIDアーキテクチャーを採用していません。
データーの２重化（２面コピー）、３重化（３面コピー）によるデーターの保全機能を提供します。Nutanixは、ノードをまたいでデーターをコピーするため、特定のノードに障害が発生しても、冗長化されたデーターが複数同じタイミングでロストすることはありません。
「Replication Factor 2」は、データーの２重書込、「Replication Factor 3」は、データーの３重書き込みを行います。Replication Factor 3は、Redundancy Factor 3のNutanix環境のみ利用できます。（ということは、最低５ノードかつProライセンスが必要ということになります）
Replication FactorもAOS5.5現在、稼働後のRF2からRF3、RF3からRF2への変更がオンラインのまま設定変更することができます。
ただし、設定変更はPrism画面からではなく、ncliコマンドで実行する必要があります。
 なお、Nutanixを構築すると標準で作成される、ストレージコンテナ「NutanixManagementShare」は、RF2からRF3に変更することはできません・。

Replication Factorのイメージ

ncliを利用したRF2からRF3への変更

コンテナの一覧を表示させる

ncli> ctr list

コンテナのIDを取得

    Id                        : 00056a69-c1d8-fe67-0000-000000014005::1190
    Uuid                      : e4db671a-6bff-4324-ab88-a33a677ccdda
    Name                      : DEFAULT-CONTAINER
    Storage Pool Id           : 00056a69-c1d8-fe67-0000-000000014005::9
    Storage Pool Uuid         : 770e9c54-2722-40da-83d1-d013ef5c6b30
    Free Space (Logical)      : 5.06 TiB (5,566,102,449,437 bytes)
    Used Space (Logical)      : 335.66 GiB (360,412,356,608 bytes)
    Allowed Max Capacity      : 5.39 TiB (5,926,514,806,045 bytes)
    Used by other Containers  : 165.55 GiB (177,757,927,424 bytes)
    Explicit Reservation      : 0 bytes
    Thick Provisioned         : 0 bytes
    Replication Factor        : 2　　←現在のRF設定がわかる
    Oplog Replication Factor  : 2
    NFS Whitelist Inherited   : false
    Container NFS Whitelist   : 192.168.38.139/255.255.255.0
    VStore Name(s)            : DEFAULT-CONTAINER
    Random I/O Pri Order      : SSD-PCIe, SSD-SATA, DAS-SATA
    Sequential I/O Pri Order  : SSD-PCIe, SSD-SATA, DAS-SATA
    Compression               : off
    Fingerprint On Write      : off
    On-Disk Dedup             : none
    Erasure Code              : off
    Software Encryption       : off
The containers listed below are storage containers

RFの設定変更は、変更したいストレージコンテナのID（::より後ろの番号）を入力する
以下はRF3に変更したい場合の例

ncli> ctr edit rf=3 id=1190

※RF3からRF2に変えたい場合は、コマンドパラメーターをrf=2に変更すれば良い

Replication Factorのまとめ

Replication Factor	Redundancy Fuctor	必要 ノード数	Nutanix ライセンス	稼働後の変更
2	2 or 3	3	Starter以上	RF2 → RF3 OK
3	3	5	Pro以上	RF3 → RF2 OK

Redundancy FactorとReplication Factorのマトリックス

Redundancy Factor	Replication Factor	設定可否
2	2	○
2	3	×
3	2	○
3	3	○

Redundancy FactorとReplication Factorは混同しやすいですが、冗長化の見ている観点が異なりますので注意が必要です。

Redundancy Factor3であっても、Replication Factor2を利用することができます。Replication Factor 3は、単純に計算をするとデーターを３重書込するぶん必要容量も３倍になる関係から、最もクリティカルな仮想マシンはRF3のストレージコンテナにし、一般的な保護レベルであればRF2で業務上何も問題はありません。容量の効率化と可用性のバランスを勘案した構成を組むことができるのはNutanixのポイントです。

いろんなアクロポリスの名称を確認

Nutanixというと「アクロポリス」というキーワードがよく出てきます。
Nutanixおいてアクロポリスというキーワードは非常に重要ですが、時にアクロポリスというキーワードの誤った使い方を耳にすることがあります。
今日はNutanixにあるたくさんのアクロポリスをひもといて、是非ただしいアクロポリスというキーワードを知ってほしいと思います。

AOS (Acropolis OS)
CVMの中で稼働するOSのこと。Prismなどの画面サービスもそうですが、ハイパーバイザーへのストレージサービスなどの機能を提供する。
アクロポリスというと、一般的にAOSを指すことが多い。なお、AOSは、ハイパーバイザーの種類に関係なくNutanix上で提供される。

AHV（旧Acroplis Hyper Visor）
昔はアクロポリスハイパーバイザーといっていましたが、今はAHVが正式名称です。
Nutanixが提供するハイパーバイザーの製品です。KVMがベースとはなっておりますが、Enterpriseで必要な機能が各種拡張されており、企業のシステム基盤で利用するになにも心配のすることのないハイパーバイザーとして完成度が非常に高まっている。
よく、AHVで稼働させることをアクロポリスで稼働させるという表現を聞きますが、これは間違いです。正しくはAHVで稼働させるとなります。

ABS（Acropolis Block Services）
Nutanixが提供する、iSCSIベースのブロックストレージサービス。
Nutanix上で稼働する仮想マシンに対して提供する場合は、Starterライセンスで良いが、Nutanixの外に設置した物理サーバー等からiSCSIでマウントする場合には、Proライセンスが必要。スナップショットの取得や、取得したスナップショットの別の仮想マシンへのマウントなど、エンタープライズストレージが持つ機能を保有している。

AFS（Acroplis File Services）
Nutanix上で稼働するファイルサーバーサービス。AFS2.XまではCIFSのみだったが、AFS3.0からNFS4.1にも対応した。
Windows上立てるファイルサーバーと違い、Nutanixの良さである必要に応じて無停止での拡張ができることと、NASヘッドが最大16台のVAで分散処理されるため大変高速な処理が行える、尚、VSS機能はABE機能など、ファイルサーバーとしての機能も大変充実している。

ACS（Acroplis Container Services）
Nutanix上でDockerコンテナを操作する製品。ACS1.0は残念ながら終息した。

5つのアクロポリスについて説明をしました。
アクロポリスという名称で説明をするとどれを指しているのかがわかりにくくなりますので、是非略称を覚えていただき､AOSやAHVなど正しい名前で呼んであげてください。

NutanixのvSphere VAAI機能をCommunity Edtionで体感する

Nutanixの良さの1つにストレージが非常に高機能であることがあげられます。

• SSD・HDDの自動階層型ストレージ
• 圧縮・重複排除機能
• ストレージベースのリンククローン
• ストレージベーススナップショット

この機能を手軽にお試しできるように、Nutanixでは、Community Edition(CE)といわれる、無償でホームラボや検証用途に利用できるものを提供しています。

しかし、このCEは、AHVのみの提供で有り、vSphereを利用するユーザーは、Nutanixの製品を購入しなければ、そのすごさを体感することは出来ません。

じゃあ、買ってくださいという話しなのですが、個人がおいそれと購入できる金額ではあありません。そこで、今回は、Nutanix CEを利用して、vSphere上で、VAAIを利用した高速クローンを体感する方法をご紹介します。

手法は、以下の通りです。

1. CEの構築
2. ストレージコンテナにESXiホストのIPをホワイトリストに登録
3. VIBの取得と登録
4. ストレージのマウント
5. 仮想マシンの作成とクローンの実行
6. 
   

Nutanix CEの展開方法は、たくさん情報が出ておりますが、Nestedの場合は、GoWatanabeさんの記事がわかりやすくまとまっております。

• ESXi 6.0 で Nested Nutanix CE を構成してみる。
• Nutanix CE ce-2018.01.31-stable を ESXi で起動してみる。

さて、インストールしたCEは、当然ながらAHVで稼働しており、この上で仮想マシンを高速クローン出来るのは当然ながら話ですが、このNutanixのストレージをvSphereで利用するというのが今回のミソになります。

まず、CEのPrism画面から、Storage画面にいき、AHV上のストレージコンテナを選択し、Updateをクリックします。

でてきたプロパティ画面から、Advanced Settingsをクリックし、FILESYSTEM WHITELISTSの中に、実際にESXiホストのIPアドレスとマスクを記載します。

記載方法は、CIDR形式ではなく「IP(X.X.X.X)/MASK(Y.Y.Y.Y)」という書き方となり少々特殊ですので注意が必要です。

さて、ここまでは普通のNFSマウントでこれだけでは、VAAIの恩恵を受けることは出来ません。ここからがポイントです。そうVAAIを呼ぶVIBファイルです。

これは、CEの中に保存されているCVMのなかに保存されています。

場所は、

/home/nutanix/ce_vibs/esxiのバージョン/nfs-vaai-plugin.vib

となります。

WinSCP等を利用してこのVIBファイルを取得します。

取得したファイルは、ESXiに同じくWinSCPやvSphere Web Client等の機能を利用してESXiホスト上に保存します。

次に、ESXiホストにてこのVIBファイルをインストールします。
SSHにて、ESXiホストにログインし、下のコマンドで行います。

esxcli software vib install -v vib置いたファイルパス/nfs-vaai-plugin.vib

コマンド実行後、
「The Upgrade completed succesaafully, But the system needs to be rebooted for the change to be affective.」
というメッセージが出たら完了です。
ESXiホストを再起動します。

再起動後、もう一度SSHでESXiホストにログインし、以下のコマンドでVIBが正しくインストールされているかを確認します。

esxcli software vib list

結果が表示され

[root@localhost:~] esxcli software vib list
Name                           Version                              Vendor   Acceptance Level  Install Date
-----------------------------  -----------------------------------  -------  ----------------  ------------
～途中略～
nfs-vaai-plugin                2.0-5dfbc550                         Nutanix  VMwareAccepted    2018-03-04

と言う形で、nfsのvibがインストールされていることを確認します。

あとは、ESXi側でNFSストレージをマウントするだけです。

vSphere Web Clientから、マウントしたいESXiホストを選択し、データーストアタブを選択肢、新しいデーターストアをクリックします。

ウィザードが表示されたら、データーストアの種類はNFSを選択します。

Nutanix CEのCVMが提供するストレージサービスはNFS3なので「NFS 3」を選択します。

マウントポイントのパラメーター入力画面が評宇治されます。
・データストア名には、vSphereで管理するデーターストアの名称を
・フォルダには、/(スラッシュ)の後に、Nutanixで作成したストレージコンテナの名称を入力します。（こちらは英語の大文字小文字もきちんと合わせます）
・サーバーは、CVMのIPアドレスを入力します。

これで、マウントは完成です。
他のデーターストアにある仮想マシンを、Nutanix CEが提供するストレージコンテナにクローンしてもVAAIは利用できません。
まず、Nutanix CEが提供するデーターストアに仮想マシンを作成またはクローンした上で、その仮想マシンを同じNutanix CEが提供するデーターストア上にクローンしてみると、あっという間の数秒間のうちに仮想マシンのクローンができあがるはずです。

今回はESXi上からAHV用に提供されているストレージコンテナを無理矢理マウントしていますので、NutanixのData Protection機能によるストレージベースのスナップショットは体験することが出来ません。
また、本来このような使い方は、サポートの範囲外であることも理解しておいていただきたいと思います。

vSphere上で、高速クローンを体感した方は、お試しください。

XRay 2.2をvSphere環境にデプロイする方法

昨年12月末にXRayバージョン2.2がリリースされました。
今までのXRayの機能はそのままに従来課題であったシナリオのカスタマイズもできるようになり、より便利になっています。

XRayは、AHV用のqcow2とvSphere環境向けのOVAが提供されています。

XRayのダウンロードページ

XRayのダウロード先
http://next.nutanix.com/t5/Nutanix-X-Ray/Nutanix-X-Ray-2-2-Download-Binaries-and-Docs/m-p/26386#M65

vSphere環境にこのXRayを展開しようとすると、以下のようにvCenter Serverでエラーが表示されます。

これは、OVAの中に格納されているVMDKファイルが、圧縮されていることに起因しています。この場合、OVFTOOLを利用すればインポートは可能ですが、コマンド操作で各種パラメーターを設定するのも面倒ですので、GUI操作でデプロイする方法をお伝えします。

まず、ダウンロードした、xray-2.2.ovaをxray-2.2.ova.tar.gzにファイル名を変更し、このファイルを解凍します。

今回は、個人利用は無償で利用可能で、小回りの利く「ExpLzh」を利用します。
ExpLzhの詳細は以下でご覧ください。
https://www.ponsoftware.com/archiver/product/product.htm

解凍すると、 「xray-disk1.vmdk.gz」というファイルが出てきます。
これが、エラーの原因であるVMDKが圧縮されているという、そのファイルとなります。
このファイルも解凍し、VMDKファイルを同じフォルダに配置します。

しかし、このままではインポートはうまくいきません。
次にテキストエディタで「xray.ovf」を開きます。

上記にある「<References>」配下を書き換えます。

（変更前）

  <References>
    <File ovf:compression="gzip" ovf:href="xray-disk1.vmdk.gz" ovf:id="file1" ovf:size="3405331650"/>
  </References>

（変更後）

  <References>
    <File ovf:href="xray-disk1.vmdk" ovf:id="file1" />
  </References>

変更後ファイルを上書きします。

この後、OVFをインポートします。
インポートする際に選択するファイルは、「xray-disk1.vmdk」と「xray.ovf」の2つだけを選択します。

これで、インポートを継続することができます。

OVFToolを使うと面倒くさいので、楽してvSphere環境にX-Rayを入れたい場合には、試してみてください。

Nutanix AHVの紹介 その３ AHVへのお引越しはどうすればいいの？

この記事はNutanix Advent Calendar 2017/12/23 の記事です

前回までのにAHVが実用的に利用できるのかを中心に見てきました。
では、既存の環境からAHVに移行するためにはどうすればよいのでしょうか？
実際に移行のプロセスについて検討をしてみたいと思います。

1.OSの対応状況
まず、移行するOSがAHVに対応しているかを確認しましょう。
Windows Server 2003など古めのOSは、AHVではサポートされていないことに注意が必要です。

2.VirtIO Driverのインストール
AHVは、ディスクバスをSCSIにした際、WindowsOSでは標準で保有していないデバイスドライバーが必要になります。また、LinuxOSにおいても、Nutanixが提供するVirtIOドライバーを入れることが推奨されます。
移行を計画するマシンには、あらかじめVirtIO Driverのインストールを行いましょう。
VirtIO Driverは、Nutanix Supoprt PortalのDownloadメニューの「Tools & Firmware 」のページからダウンロードできます。

Windowsの場合、msiファイルとなっていますので、インストールウィザードに従うだけで簡単にインストール可能です。

3.移行の手法を考える
さて、ここまでの準備ができたら、移行の手法について具体的に考える必要があります。

vSphereの場合

ポイントは、３つあります。
まず、vSphere 5.5以上(ESXi 5.5以上)を利用している場合、Nutanixから提供される、Xtract for VMsを利用するのが、最もRPOが短く、かつ簡単なオペレーションで作業が可能です。Xtarct for VMsは、vCenter Serverとの接続が必要になるため、vSphere Essentials 以上が移行対象のエディションとなります。
2つ目のポイントは、vSphere(ESXi)5.1の場合、Standard以上のエディションを利用していれば、Storage vMotionが利用可能ですので、NutanixのストレージコンテナをESXi環境であらかじめマウントしておき、仮想マシンの仮想ディスク等、オンラインのままあらかじめ移行しておくことが可能になります。
vSphere(ESXi)5.0以下、また、vSphere(ESXi)5.1であっても、Essentials Plus以下の場合は、Storage vMotionが利用できませんので、仮想マシンをシャットダウンしパワーオフになった後、「仮想マシンの移行」を利用して、仮想ディスクをNutanixのストレージ移行することができます。
Xtarct for VMsを利用しない場合、Nutanixのストレージコンテナに仮想マシンデーターを移行できても、形式を変更しなければAHVでは利用できません。
そのため、ストレージの移行が完了した仮想マシンは、ESXi上で稼働している場合は、シャットダウンし、パワーオフ状態になった後、「-flat.vmdk」のファイルをNutanixのImage Serviceに登録し、AHV形式のディスクに変換を行い、移行は完了です。

HyperVの場合

HyperVの場合、仮想マシンの世代数で移行の方法が異なります。
BIOSレベルで起動する第一世代の場合、VHD/VHDXファイルを、Image Serviceに登録するだけで移行は完了します。HyperVの場合、ファイルフォーマットとしてNFSのストレージをマウントすることができませんので、仮想マシンのパワーオフ後、VHD/VHDXファイルを、Webブラウザ経由で、Prismの画面からPUTするか、Windowsマシンから、NFS共有フォルダをマウント後、コピーする形でNutanixのストレージコンテナに移行可能です。

物理サーバーの場合

物理サーバーからの移行の場合、いくつかの方法があります。
一番確実なのは、市販のイメージバックアップソフトウェアを利用し、リストアする方法が確実です。
ただ、物理サーバーのディスクを、何らかの形で仮想ディスクの形式変換すれば、HyperVやvSphereと同じようにImage Service経由で仮想マシンを変換することが可能です。
例えば、Windowsの場合、DISK2VHDを利用すれば、物理・仮想に関係なくWindows上で見えるディスクドライブの内容をVHDXファイルに変換することできます。
変換後の仮想ディスクファイルは、NutanixのストレージコンテナにPUT後、Image Serviceに入れることでAHVで稼働可能な形式に変換することができます。

AHVで新規に仮想マシンを作成するのは、非常に手軽にできますが、既存資産からの移行の場合も、手順さえあらかじめ押さえておけばそこまで、大掛かりな作業でも、大変な手法が必要でもありません。
これは、NutanixのImage Serviceの機能に、仮想ディスク形式の変換機能が実装されているという利便性になります。

クリスマスはもうすぐそこです。
明日は、日本人数人しかいない希少なNutanix Technology Championホルダーの@hiroito1118さんです。

PrismCentral 5.5の小ネタ

この記事はNutanix Advent Calendar[2枚目] 2017/12/20 の記事です

AOS及びPrism Central5.5が、12月の上旬に発表されました。
たくさんの機能が追加またはアップデートされたことは言うまでもありません。
ただ、一部仕様変更が加わったところも有り、今回はその中でもPrism Centralのことについてご紹介をしたいと思います。

まず、Prism Centralとは、簡単に言うと複数のNutanixクラスターを統合管理する管理アプライアンスとして登場しました。その後、ただの統合管理という枠を超え、分析やプランニング機能が搭載され、AOS5.5からは、Nutanixのオー消すとレーションツールであるCalmの搭載など、より管理面を強化した管理アプライアンスとしての立ち位置を持っています。

では、このPrism Centralの変更点は何かと言いますと、単純に言うとたくさんあるのですが、ここは、2枚目カレンダーですのでニッチな情報をお伝えしたいと思います。

それは、Prism Centralへの登録は、各NutanixクラスターのPrism Element画面から行うことが出来るのですが、Prism Centralからの登録解除が、Prism Element及びPrism CentralのWebGUIから出来なくなったと言うことです。

AOS

しかし、AOS5.5からは、Prism Centralの登録解除をしようとしても以下の画面が表示され、手順が記載されたドキュメントが案内されるだけになっています。

これは、機能ダウンではなくオペレーションミスによるPrism Centralへの登録解除により、今までのワークロードデーターなどの実績データーや設定データーの消失を防ぐためについたいわば防護機能です。
詳細は、NutanixのKB:4944を参考にしてください。

本番運用においては、この機能がありがたい反面、検証環境等で定期的に環境を作り直す場合においては、GUIでできなくなったところはいささか不便ではありますが、その手順をきちんと押さえておく必要があります。
では、どうやって登録解除をすればよいのでしょうか？

まずは、CVMにSSHで接続します。
その後、ncliにログインします。その際にただのncliではなく、以下のコマンドを利用し、ncliに入ります。

ncliへ入る方法

ncli -h true

次にPrism Centralの登録解除コマンドを実行します。

multicluster remove-from-multicluster external-ip-address-or-svm-ips=PrismCentraのIPまたはFQDN username=admin password=PrismCentralのパスワード force=true

最後にStatusが、trueで帰ってくればOKです。

Status : true

これで、NutanixクラスターのPrism Centralの登録が解除されました。
しかし、これではPrism Central側にメトリックが取得できないNutanixクラスターの状態が残ったままになってしまいます。
そのため、Prism Central側でも登録情報を削除する必要があります。

こちらはまず、Prism CentralにSSHでログインします。
次にncliに入ります。

ncliへ入る方法

ncli -h true

次に、登録されているNutanixクラスターのID情報を取得します。

multicluster get-cluster-state

このコマンドによって、クラスターIDを取得します。

    Cluster Id                : 00054f22-24fc-c164-6145-246e961925b0
    Cluster Name              : AHV-CLST
    Is Multicluster           : false
    Controller VM IP Addre... : [192.168.38.XX, 192.168.38.YY, 192.168.38.ZZ]
    External IP Address       : 192.168.38.A
    Marked for Removal        : false
    Remote Connection Exists  : false
    Cluster Id                : 00054f21-3043-5f5d-0000-000000014005
    Cluster Name              : ESXi-CLST
    Is Multicluster           : false
    Controller VM IP Addre... : [192.168.37.XX, 192.168.37.YY, 192.168.37.ZZ]
    External IP Address       : 192.168.37.A
    Marked for Removal        : false
    Remote Connection Exists  : true

ここで、Prism Centralから登録解除したいNutanixクラスターのCluster IDを取得します。

では次に、登録削除のコマンドを実行します。

multicluster delete-cluster-state cluster-id=削除したいクラスタID

結果でSuccessfulが帰ってくれば作業完了です。

Cluster state deleted successfully

これで、作業は完了です。

作業としてはたいした作業ではありませんが、検証環境としてNutanixを利用している側としては一手間増える作業となっていますので、あらかじめこの手順は押さえておきたい物です。

明日は、毎度たくさんのNutanix情報を日本語で提供していただいている@Networld_NTNXさんです。

Nutanix AHVの紹介 その２ AHVは、オールマイティなの？

この記事はNutanix Advent Calendar 2017/12/16 の記事です

前回は、AHVというハイパーバイザーがきちんとしたエンタープライズな機能を保有していることを紹介しました。
では、世の中で広く使われている一般的なハイパーバイザーと同じようにAHVは、使えるのかというのを、見ていきたいと思います。

対応しているゲストOS

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

サポートゲスト（SCSI/IDE）

Windows 7, 8, 8.1, 10

Windows Server 2008 R2, 2012, 2012 R2,2016

RHEL 6.4, 6.5, 6.6, 7.0, 7.1, 7.2,7.3

CentOS 6.4, 6.5, 6.6, 7.0, 7.1, 7.2,7.3

Ubuntu 12.04.5, 14.04.x, 16.04.x, 16.10, Server, Desktop (32-bit and 64-bit)

FreeBSD 9.3, 10.0, 10.1

SUSE Linux Enterprise Server 11 SP3 / SP4, 12

Oracle Linux 6.x, 7.x

サポートゲスト（PCI/IDE）

RHEL 5.10, 5.11, 6.3

CentOS 5.10, 5.11, 6.3

Ubuntu 12.04

ここ10年ぐらいに発売されたOSであれば、問題なく動作することがここからわかります。
言い換えると、仮想化されて塩漬けされたゲストOS、例えばWindows NT4.0などはどうさせることが出来ません。
ただ、すでにOS提供メーカーがサポートを終了したOSを使うこと自体がリスクであり、本来は新しいOSに移行するべきで有り、メンテナンスを放棄したただの延命という意味での仮想化は正しい使い方ではありません。

AHVホストの上限

AHVにおける制限事項は以下の通りです。

ホストあたりのオンラインVM数	128
ホストあたりのオンライン仮想ディスクの数	256
コンシステンシーグループごとのVM数(スナップショット利用時)	8
同時に編集するVMの数（たとえば、 vm.create / deleteおよびpower操作etc）	64

正直、一般的に利用する場合なにも気にすることがない事項だtrお思いマス。
コンシステンシーグループ毎のスナップショットは、Nutanixオリジナルのデーター保護機能であり、この機能を利用して複数の仮想マシンの一貫性のあるバックアップを取得する機能があり、そのグルーピングの上限が8台の仮想マシンと言うことになります。

仮想マシンの上限

VMごとの最大vCPU	ホストあたりの物理コア数
VMあたりの最大メモリ	2TB
VMごとの仮想ディスク数	SCSI: 256 PCI: 6 IDE: 4

Nutanixから提供されるドキュメントを読む限り、これ以上の情報を見つけることは出来ませんでした。
では、実際に仮想マシンに12個のNICを割与えた場合、どうなるのでしょうか？
（vSphere仮想マシンの場合、1つの仮想マシンに割り与えられるNIC数は、10個となります）

実際に、Prismの画面から仮想マシンにNICを12個割与えるとことができました。

では、OSから見るとどようになっているでしょうか？
今回はWindows Server 2016で試してみましたが、きちんとNICが12枚認識されています。

実際に12個のNICが必要となるケースはほとんど無いと思いますが、仮想マシンに対して自由な構成が出来ることがわかります。

そのほか

AHVでのそのほかの対応事項も併せて書いておきます。

• 仮想マシンNICにトランクポート（VLANトランク）での接続が可能
• vGPU/GPUパススルーの対応
• CPU仮想化（ネスト）の対応
• CPU/RAMのホットプラグに対応

vGPUなどは、VDIの用途に最適ですし、CPUの仮想化は、検証環境等で利用する際にも威力を発揮します。

まとめ

今回は、AHVの制限事項を中心に見てきました。
結果、AHVがオールマイティかどうかというと、一般的な仮想マシンの利用において何も困ることはないと言うことが証明できると思います。仮想ハードウェアの制限事項やサポートのゲストOSも、これからNutanixを導入する場合においてなにも気にすることはないと思われます。

明日は、仮想化の魔術師@Wataru Unnoさんです。

Nutanix AHVの紹介 その１ ぶっちゃけAHVって使えるの？

この記事はNutanix Advent Calendar 2017/12/10 の記事です

Nutanixの知名度が上がると同時に、AHVの存在も徐々に知られるようになりってきました。しかし、AHVにおける情報は未だ少ないということもあり、AHVのおいて、懐疑的に思われている方もいます。
今回は、まずAHVの紹介をしていきたいと思います。

その１ AHVは、Nutanixを買えば使える無料のハイパーバイザー

このAHVが無料というキーワードは多く浸透している気がしますが、ただほど高い物はないと考えられる方もいるため、疑いを持っている方も居るかもしれません。
AHVは、KVMをベースとしたハイパーバイザーですが、KVMは世界で多く使われているオープンソースのハイパーバイザーです。
ただ、KVMの機能だけでは、Enterpriseな環境ではどうしても機能として不足する面があります。そこを補う形にしてEnterpriseな企業においても利用できるハイパーバイザーとしてAHVが誕生したのです。

その２ AHVエンタープライズな機能を搭載

AHVは、エンタープライズな機能を搭載していると言っていますが具体的にどのような機能かを含め、紹介したいと思います。
まずは、仮想マシンとしては今までの仮想基盤と同じ、vCPUやRAM等必要なコンポーネントを作成すると言うことは何も変わりません。

（参考）AHVでの仮想マシン作成の画面

エンタープライズな機能とは、まさ、「可用性」の話しです。
まずは、仮想化ホストのダウンに伴う、仮想マシンの共倒れについてです。
これを防ぐための機能として一般的なハイパーバイザーでは「HA (High Availability)」が搭載されています。
Nutanixにももちろん、HA機能が搭載されています。しかも、この機能はデフォルトで有効です。ホストがダウンした場合、自動的に別の稼働中のホストで仮想マシンを再起動する機能は標準で有効です。また、ホストダウンを考慮し、N+1の概念に基づき、1台分のリソースをあらかじめ確保する動きを自動で行う機能も有効化することが出来ます。

（参考）HAによるリソース確保の設定画面

では、特定の仮想マシンが大幅にCPUリソースを消費してしまう、いわばNoisyNaverの対応に関してはどうでしょうか。VMware vSphereの場合は、NoisyNaiverの仮想マシンが居るホストに所属する他の仮想マシンを、あいているESXiホストに自動で動かしてくれる機能「DRS」があります。
Nutanixも同様に、NoisyNaverな仮想マシンを見つけると、同じホストに所属するそのほかの仮想マシンをよそのホストに移動する「ADS」という機能が存在しています。
また、特定の仮想マシンはこのホストだけでしか動作してほしくないと言ったアフィニティルールの設定ももちろん可能です。

（参考）アフィニティルールの設定画面（仮想マシンが稼働可能なホストをマウスで選択）

さて、ハイパーバイザーとしての高機能性はわかりましたが、アプリケーションの冗長構成を行い、OSやマシンレベルではなくサービスレベルでの冗長性を組みたいと要望されるケースもあります。その際に、よく使われるのがWindows Serverの場合、WSFC(Windows Server Failover Cluster)だと思います。
WSFCを構成する場合、SCSIやFCを利用したQuorumディスクを構成し、Active/Stanbyの構成を組みます。これは通常の仮想ディスクの構成では、組むことが出来ないので、VMware vSphereの場合は、RDM(Raw Device Mapping)とよばれる、FC等で接続された共有ディスクを直接仮想マシンに見せる機能を利用していました。
では、これがNutanixの場合どうなるのでしょうか？
Nutanixには、ABS(Acropolis Block Service)といわれる、仮想マシンや物理マシンに対して、iSCSIを利用してディスクを共有ディスクを提供できます。これを利用することで、WSFCの構成も簡単にできます。
また、iSCSIで提供するディスクボリュームもNutanixオリジナル機能である、スナップショット機能でバックアップやレプリケーションも出来ます。

（参考）iSCSIでマウントできるディスクボリュームの作成画面(ABS)

（参考）Oracle Fail Safeも問題なくAHV上で構成可能です。

さて、ここまで見てみると、AHVは、企業のミッションクリティカルな現場で利用するにも十分な機能をもっていることがわかりました。
では、次回以降で、AHVを利用する際の注意点や使いどころをご紹介したいと思います。

明日は、仮想化からそれ以外までの幅広い知識をお持ちのエンジニア @intertoさんです。

Nutanix AHVで、Intel e1000のNICデバイスを利用する方法をご紹介

この記事はNutanix Advent Calendar 2017/12/3 の記事です

今日は、AHVにおける小ネタをご紹介します。

AHVから仮想マシンに提供されるNICは、「Nutanix VirtIO Ethernet Adapter」が提供されます。これは、Windowsの場合、Nutanixから提供されるドライバーを適用しないと利用できません。

▼Windows Server 2016にNGTインストール後のNICの様子

仮想アプライアンス製品や、OSにカスタマイズが出来ない場合、デバイスドライバーを後から入れることが困難なこともありますので、vSphere ESXiの場合、昔から互換性の高い「Intel NIC」の1つである「e1000」の互換デバイスを仮想マシンに提供できます。

実はNutanixのAHVにおいても「e1000」の互換NICを仮想マシンに提供可能です。
今日は、この「e1000」NICの追加方法をお教えします。

この方法は、コマンドでしか出来ません。
まず、任意のCVMにSSHでログインします。
その後、acliに入り、以下のコマンドを入力します。

vm.nic_create 仮想マシン名称 model=e1000 network=ネットワーク名

仮想マシン名称には、Prismで登録した仮想マシン名称を入力します。
ネットワーク名は、Prismで登録したVLAN名称を入力します。

登録が完了すると、「NicReate: complete」と表示されます。
なお、このコマンドは対象の仮想マシンがパワーオン状態でも作業可能です。

そうすると、仮想マシン上ではe1000のNICが認識していることがわかります。
Windows Server 2016の場合、e1000ドライバーはWindows標準で搭載しているので、そのまま認識されます。

Nutanixから、NGTによりNICドライバーは提供されていますので、通常はe1000ドライバーを使うことはまず無いかと思いますが、OSやそのほか互換性の都合でIntel NICを利用為たい場合は、AHVでも対応可能であることは是非知っておいていただきたいです。

明日は、広くて深いスキルをお持ちの@intertoさんです！

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

この記事はNutanix Advent Calendar 2017 12/1の記事です。

今回は、毎度ながら好評のNutanixでよく聞くウワサの真相を確認する、ウワサシリーズです。
Nutanixを提案していると、競合他社からこういう話を聞いたとか、こんなウワサを聞いたなど、Nutanixに関していろいろなうわさ話を耳にすることがあります。
Nutanixは、2016年に上場しもはや大手企業の仲間入りをしていますが、まだNutanixという会社の知名度は低いところが有り、怪しい会社の怪しい製品と時に勘違いされることがあります。
今日は、その噂の真相第４回目となります。

ウワサ１

Nutanixのストレージは、シック(Thic)プロビジョニングの仮想ディスクが作成できないので、Disk I/Oパフォーマンスが悪い

真相

ウソ

これは、誤解が無いように説明をしておきたいのですが、NutanixとAHVにおいては、シックディスクを作成することはできません。基本シンプロビジョニングとなります。
vSphereの場合は、VAAIドライバーが組み込まれているため、シックディスクの構成が可能です。
ココで問題なのは、シックかシンかで、パフォーマンスが異なるかと言うことです。
Nutanixは、階層型のストレージであることから、上手にキャッシュを利用することと、SSDのハイパフォーマンスを利用して、高速I/Oを提供します。
一部のデーターベースソフトウェアでは、シックディスクでないとパフォーマンスが出ないと思われている方がいますが、これは、まだHDDでしかストレージが構成出来なかった時代の話しです。Nutanix+AHVでもNutanix+vSphereで、シンディスクを利用しても、Nutanixの高速I/Oを体感できることに変わりがありません。

ウワサ２

Nutanixは、オープンソースソフトウェアを多用しており、信頼性に欠ける

真相

ウソ

残念ながら、OSSという文化を否定すると、世の中で稼働しているたくさんのシステムそのものを信用できないと言っていることになります。
例えば、SSHの世界ではOpenSSH、SSLの世界ではOpenSSL、もっといえば、世の中に様々な機器はLinuxというOSSの代表格のようなOSに支えられています。
GoogleやFacebookも、OSSを多用して大量のアクセスをさばける分散システムを構築しています。
OSSは、フリーウェアーや個人が作成した物ではなく、世界中のスゴイ技術者達が知恵を持ち寄って作っている物で有り、バグの報告やFixや機能追加も積極的に行われています。OSSで高い信頼性があるものが提供されているのに、同じことができるソフトウェアをわざわざ自社で開発しその開発コストを製品に転嫁する形は無駄で有り、ユーザーの求める物ではありません。
OSSは、信頼性がないというのは、ただの印象操作の話しです。



ウワサ３

Nutanixは分散ストレージのため1本のディスクが故障するとリビルドに長時間がかかる。

真相

ウソ

これは残念ながら完全なウソです。なぜならNutanixには、RAIDの概念がありませんので、そもそもリビルドは発生しません。
Nutanixは、1本のでぃすくが故障した場合、故障したディスクに入っていたデーターは当然冗長化を失いますが、ディスク故障を検知した瞬間、その他のディスクに分散されて配置されたデーターを瞬時に別のノードにコピーします。
リビルドはRAIDグループの全てのディスクに対してリビルド処理が走るため、負荷がかかりますが、Nutanixは、失われたデーターブロックだけをコピーして終わりですので、1本のディスクが壊れても、数十分の単位で修復が終わります。



ウワサ４

Nutanixは、小さい会社なのでどこかに買収される可能性がある

真相

小さい会社というのは、もはやウソと言っていいでしょう。
買収は状況によりわかりませんが、現状その可能性はまずないでしょう。

そもそも、小さい会社ではないということは、
これは、投資家やそのほか経営的な問題ですので、絶対という話はありません。
ただ、Nutanixはすでに上場企業であり、その行方はわかりませんが、まず経営者の戦略的に売却をしたり、競合から金を積まれて買収されると言ったことはないでしょう。
ストレージの王者であるEMCでさえも、Dellに買収される時代ですので、企業の行方はわかりませんが、Nutanixは、元気な上場企業ですので、このタイミングでの買収は考えられないでしょう。



ウワサ５

Nutanixは、ハード保守会社を選べないので自由がきかない

真相

ウソ

Nutanix単体で見たときは、Nutanix純正の場合、保守は全てNutanixになります。
IBMのAS400などすでにIBM製品をコアで利用されているユーザーの場合、IBM保守の高い品質を好まれ、IBM保守を指定で希望ケースに出会うことがあります。
Nutanixの場合、IBM PowerのモデルのNutanixは、IBM自身が販売しているモデルになるため、IBM保守を受けることが出来ます。
また、Intel CPUを希望される場合、Dell XCを利用すると、IBM保守を利用できるオプションが存在しています。
保守も、ハードウェアも自由に選べるのが、Nutanixの「選択の自由」なのです。

今回も5つのウワサに言及しました。
端的に答えられない話もありますが、技術的な話しや機能的な話しでは、まだまだデマが流れていることがあります。
Nutanixに対する正しい情報を入手し、正しく判断をしていくことが大事です。

明日は、私と最も近い（場所？関係？）、@mmorishiさんです！