Self Service Restore (SSR)の注意点

Nutanixのファイルベースのリストア機能、Self Service Restore（SSR)は大変便利な機能です。ただ、この機能を使う上で押さえておくべき点もありますので、今回は注意点をお伝えします。

その１

SSRを利用するためには、仮想マシンとNutanixの「CLUSTER VIRTUAL IP ADDRESS(Cluster VIP)」2074/TCPで通信ができる必要があります

これは、NGTの仕様にもかかわるところなのですが、仮想マシンにインストールされた
Self Service Restore GatewayがNutanix Cluster VIPにアクセスし情報を取得するため、仮想マシンとNutanixクラスターの管理IPのあいだで、2074/TCPの通信が行われます。
DMZに配置するサーバー等では一部セキュリティ上の課題が出てくるケースもありますので注意が必要です。

その２

SSRからマウントしたドライブ読み取り専用ではマウントされない

これは、実際にファイルのリストアをする際に、スナップショットをマウントしたドライブにもファイルの書き込みなどができてしまいます。もちろん、誤ってファイルを上書きしたり消したりしてしまっても、そのディスクをアンマウントして再度スナップショットをマウントすれば元に戻るのですが、現状のドライブとスナップショットをマウントしたドライブは基本同じマシンのディスクのため勘違いしやすいので、ファイルリストア作業時は注意が必要です。

その３

PRISM側で仮想マシンで「Enable Nutaix Guest Tools」と「Self Service Restore (SSR)」のチェックを有効にしておくこと

こちらは、NGTのメディアマウント機能とNGTやSSRを有効にするチェックボックスが同じ画面にあるため、NGTのインストール完了後、まとめてチェックを外してしまうケースがありますが、上記の2つのチェックを外すと、SSRが正常に起動しません。仮想マシンをクローンした場合も元の仮想マシンのNGTの状態は保持されませんので、クローン完了後、個別にNGTとSSRの機能を有効にする必要があります。

（参考）Manage Guest Toolsの設定

尚、Self Service Restore(SSR)が有効になっていない場合、SSRのポータル画面でログインすると「Error executing command: File Level Restore capability is not enabled」というメッセージが表示されます。

（参考）

その４

SSRポータルにドメインユーザーでログインする場合、「DOMAIN\Username」形式で入力する。ドメイン名、ユーザー名も大文字・小文字の判断が入ることに注意

これは"Self Service Restore (SSR)が便利　その３"の項でも紹介をしましたが、「Username@DOMAIN」という形式ではログインができません。
また、ドメイン名やユーザー名も大文字小文字を判断していますので、Active Directory側で入力された内容を正しく反映する必要があります。（例えば、ドメインのアドミニストレーターユーザーの場合「DOMAIN\Administrator」という表記になります。

その５

対応OSは、WindowsOSのみ

これは、表記のとおりです。Linuxはまだ対応していませんので、Sambaでファイルサーバー等を作成している場合は、注意が必要です。

その６

vSphere環境の場合は、仮想マシンオプションに「disk.enableUUID=TRUE」が付与されていること

こちらもご案内済みですが、スナップショットのディスクがマウントされますのでその際のトラブルをなくすためのパラメーターです。vSphere6であれば、基本Windows2008R2以上の仮想マシンを作成すると自動的にこのパラメーターは付与されると思います。


SSRが正しく動作しないと思ったら、まず上記の内容を確認してみましょう。

Nutanix Guest Toolsのメディアがマウントされない場合

Nutanix Guest Toolsは、Nutanix上で仮想マシンを動作させる場合、入れておいたほうが便利な機能が詰まったものです。
Nutanix Guest Toolsは、Nutanix上から、ISO Media Mountの機能を利用して仮想マシンの仮想CDROMドライブにマウントされます。

このメディアマウント機能ですが、仮想マシンの仮想CDROMドライブになにもメディアがマウントされていないにもかかわらず、「Guest Tools cannot be mounted as there not enough empty CD-ROM(s)」とメッセージが表示されメディアがマウントできないことがあります。

（参考）メディアマウント時のエラー

AOS5.0の場合、vSphereであっても、vCenter Serverとの登録を行っている場合、仮想マシンの構成を見ることができます。
ここで見ると、Disksの中にCDROMドライブが存在しないことがわかります。

（参考）仮想マシンのドライブを確認

ただ、仮想マシンにはCDROMドライブが搭載されていることがわかります。

（参考）仮想マシンから見たCDROMデバイス

さて、この現象に遭遇した際の対処法ですが、CDROMドライブがSATAで構成されているときにこの症状が出るようです。

vSphere Web Clientから仮想マシンを編集で開き、CDROMドライブの仮想デバイスノードを「SATA」から「IDE」に変更します。（仮想マシンはパワーオフしておく必要があります）

（参考）SATAからIDEへ変更する箇所

IDEに変更する際、チャネルを0:1や1:0など好きなチャネルに設定していただいてかまいません。（昔からながらで考えるとIDEディスクは、チャネル0:0で、CDROMドライブは1:0か1:1という時代もありましたが・・・）今回はIDEチャネルを0:1で設定します。

そのうえで、再度PRISMの仮想マシンメニューから、「Manage Guest Tools」をクリックし、「Mount Nutanix Guest Tools」のチェックをクリックしてもエラーメッセージが表示されません。

NutanixからISOをマウントする際に利用できる仮想CDROMドライブが、IDEでないとNGTはマウントできないということのようです。（AOS5.0.0.2にて確認）

もし、「Guest Tools cannot be mounted as there not enough empty CD-ROM(s)」
というメッセージに遭遇したら、他のメディアがマウントマウントされていないかの確認と、仮想CDROMドライブのバスがIDEになっているかを確認しましょう。

Self Service Restore (SSR)が便利 その３

前回までのSSRの活用目的や動作環境の確認を行いました。
では、実際にSSRを活用してみたいともいます。

まずは、デスクトップにある「Nutanix SSR」を開きます。
このプログラムは、Pythonで作成されており、ローカルの5000/TCPでリッスンしています。

ここで入力するユーザー名は、ローカルの管理者アカウントです。
ローカルのAdministratorの場合はそのまま「Administrator」と入力し、OSのパスワードを入力します。
ここで2点ほど注意点があります。それは、ドメインユーザーでのログイン時です。

1. ドメインユーザー時におけるログインの注意点は2点です。入力方法は、「DOMAIN\UserName」形式
2. ドメイン名、ユーザー名も大文字小文字が判断される

となります。
特に2点目は注意事項が必要です。ドメイン名も大文字文字を判断されます。
Windowsで操作をする場合、ドメイン名やユーザー名は小文字大文字を判断しないため、あまり気にしないケースが多いですが、SSRは明確に判断されます。

確認方法としては、該当の仮想マシンで「net localgroup administrators」コマンドを実行して、Administratorsグループに属しているユーザーの詳細情報を確認します。

（参考）net localgroup administartorsの結果

上記のルールに従い、大文字小文字を正しくした形で「ドメイン名\ユーザー名」でログインを行います。

（参考）TORITEN\SekiajiSekisabaユーザーアカウントを利用した場合のログイン時

ログインが正常に行われると、Nutanix側で取得したスナップショットの一覧が表示されます。ここから、マウントしたスナップショットの世代を選択します。

（参考）ログイン後のスナップショット一覧

選択すると、そのスナップショットで取得したドライブが表示されます。
マウントしたいディスクにチェックを入れ、確認後、Disk Actionからマウントを行います。

（参考）ディスクマウント方法

ドライブがマウントされると、操作をした仮想マシンにドライブがマウントされていることがわかります。尚、Cドライブだけマウントしたらドライブが２つ出てきていますが、これはWindowsの起動領域のパーティションが見えているためです。

あとは、実際にリストアしたいファイルをマウントしたドライブから選択し、ファイルをローカルのディスクにコピーすれば作業は完了です。

コピーが完了したら、先ほどのSSRポータル画面に戻り、「Mounted Snapshots」画面を開き、マウントしているディスクをチェックを入れ「Unmount」ボタンをクリックすれば、ディスクはアンマウントされます。

（参考）ディスクマウント情報確認とアンマウントの方法

SSRの利用は、これだけの手順です。
NGTのインストールからファイルのリストア、アンマウントまでの作業を一連でお伝えしましたが、非常に簡単な操作でファイルのリストアが可能であることと、仮想化基盤管理者と分離して特定のマシン管理担当者のレベルで作業が可能であることは、ユーザーからの要求に対するスピードアップと管理の効率化があがると思います。

Self Service Restore (SSR)が便利 その２

前回の項でSSRの概要をお伝えしました。
では、具板的にSSRの利用方法をお伝えします。

その前に、SSRが活用できる環境と条件を押さえておきましょう。

1. SSRを利用するには、NutanixのProライセンス以上が必要になります。
2. 対応しているゲストOSは、Windowsのみであり、Linuxには対応していません。
3. ASO4.5以上で作成されたスナップショットが対応可能です。
4. ESXi仮想マシンは、「disk.enableUUID=TRUE」パラメーターが有効になっている必要があります。
5. スナップショットをマウントする際にドライブレターを利用するため、ドライブレター文字列に余裕がある必要があります。
6. ボリュームグループはサポートされていません。RAID5やミラーボリュームなどのダイナミックディスクはサポートされません。
7. SATAディスク、仮想マシンスナップショットで取得された差分ディスクはサポートされません。

OSは、Windowsのみであること、NutanixのライセンスがPro以上が必要であることは重要な要件事項ですので、押さえておきましょう。

3点目は、スナップショットベースのバックアップソフトウェアやVMware DataProtection（VDP)などでも要求される事項です。仮想マシンオプションでパラメーターが入っていることを確認しておきましょう。（vSphere6.0でWindows Server 2012R2などで構成した場合、自動で入っていると思われます）

（参考）EnableUUIDの確認方法

また、Windowsのダイナミックディスクで複数の仮想ディスクを束ねて運用している場合、仮想ディスク単位で管理されているNutanixは、ディスクを束ねている状況を理解できないため利用不可であることを押さえてください。

（参考）セルフサービスリストアの要件と制限

https://portal.nutanix.com/#/page/docs/details?targetId=Web-Console-Guide-Prism-v50:man-file-level-restore-requirements-r.html

SSRの利用には、事前の作業が必要です。

作業１：対象の仮想マシンに対して、NGT（Nutanix Guest Tools）をインストールする
作業２：Data Protectionでスナップショットを取得する
作業３：SSRログイン用の管理者ローカルアカウントを作成（すでに存在している場合それを活用可能）

となります。

まずは作業1のNGTのインストール方法です。PRISM画面から仮想マシンを選択後、「Manage Guest Tools」をクリックします。

まずは、NGTインストールのために、「Mount Nutanix Guest Tools」を有効にし、メディアをマウントします。また、SSRを利用しますので、「Enable Nutanix Guest Tools」と「Self Sertvice Restore (SSR)」を有効にします。

■ 注意点 ■
NGTをインストールして、SSRを利用する場合、「Enable Nutanix Guest Tools」と「Self Sertvice Restore (SSR)」を必ず有効にしておく必要があります。この設定は仮想マシン単位であることと、クローンした仮想マシンはデフォルトで有効にはなりませんので、手動で有効にする必要があります。

NGTのメディアが仮想CDROMドライブにマウントされますので、Autorun機能を利用\するか、CDROMドライブの中の「setup.exe」からインストールを行います。

NGTインストール後、デスクトップにSSRのアイコンが出現します。

また併せて、NGTにかかわるサービスが登録・起動していることがわかります。

作業２は、スナップショットの取得作業です。すでに該当の仮想マシンをData Protectionでスナップショットの設定作業済みであれば、特に追加の作業は必要ありません。

（参考）スナップショットの取得設定と確認

作業３は、ローカルの管理者ユーザーが必要という話なだけです。ローカルのAdministratorユーザーをそのまま活用いただいてもかまいません。必要に応じてユーザーを追加します。
ローカルのユーザーを追加せずに、特定の仮想マシンだけのAdministrator権限をドメインユーザーに割り当てることも可能です。

この場合の用途は、仮想マシンのローカルアカウント出の管理者アカウントは、管理が煩雑になりますが、特定のマシンだけを管理者権限を渡すために、Domain Adminsを与えることはできないといった問題を解決することができます。

その場合は、権限をつけたい仮想マシンの「コンピューターの管理」を開き、ローカルユーザーとグループのグループの中から「Administrators」を右クリックし、「グループに追加」をクリックします。

（参考）コンピューターの管理

グループに参加しているユーザーの一覧が出ますので、追加ボタンをクリックし、「ユーザー、コンピューター、サービスアカウントまたはグループの選択」の画面で「場所」ボタンをクリックし、参加させたいドメインユーザーが所属するドメインまたはその配下のOUを選択します。

（参考）場所の選択

追加したいユーザー名を入力し、名前の確認をクリックし、ユーザー名情報が正しく取得できたことを確認し、OKをクリックします。
（詳細設定から検索してもよいです）

（参考）ユーザ名を入力し、名前の確認をクリック後OKをクリック

このスクリーンショットでは、「toriten.oita」ドメインに所属する「karaage」アカウント（ユーザー権限）をこの仮想マシンのAdministrators権限を不要されたことがわかります。
※karaageユーザーは、ドメイン全体ではUser権限ですが、この仮想マシンの中だけAdministraor権限が付与されることになります。

（参考）ユーザー追加後

では、次回に実際のSSR利用方法をご紹介します。

Self Service Restore (SSR)が便利 その１

サーバー仮想化で、仮想化の対象にするかが悩ましいところが、ファイルサーバーというエンジニアの方は多いのではないかともいます。

ファイルサーバーが大量のストレージ容量を消費するのもそうですが、この大容量のファイルをいかに手軽にバックアップをとるかとなると、今までの仮想化基盤で難しい側面がありました。また、仮想化環境におけるイメージバックアップソフトウェアでは、ファイルレベルのリストアを行うのが苦手であったり、複数の手順を踏まないとファイルのサルベージ（救い出し）ができないケースも見かけられます。

Nutanixにおいては、仮想マシンを素早くバックアップ状態を取得する、ストレージベースのスナップショット（Data Protection）がありますが。

これは、仮想マシンに紐づく仮想ディスクのストレージブロックを固める機能で、従来のバージョンからこのスナップショットベースで取得した任意の世代の仮想ディスクを稼働中の仮想マシンにマウントして、ファイルベースでリストアを行う機能が搭載されていました。

ただ、今までの機能ではコマンドでの操作が必要であり消してシンプルな操作でファイルリストアができるとは言い難い状況でした。

そこで、AOS5.0からリリースされた機能が、「Self Service Restore (通称SRR）」です。

この機能の目的は、

1. Nutanixで取得したスナップショットから任意のファイルをリストアできる
2. Nutanixの管理者のオペレーションを介さず、稼働している仮想マシンの管理者の操作だけでファイルのリストアが可能

という点です。

1点目は、そもそも課題であった問題を解決するものであり、容易に想像できますが2点目は、どういう意味？と思われる方もいるかもしれません。

これは、Nutanixを仮想化基盤として運用し、部門別のファイルサーバーなどはその部門サーバーの管理者が運用するケースを想定しています。

バックアップは、仮想化基盤管理者が一括で行うケースが多く、一方でファイルサーバーの利用者が、ファイルを誤って上書き・削除したなどでサルベージを求めて依頼をするのは、部門ファイルサーバー管理者になります。依頼を受けたファイルサーバー管理者は、仮想化基盤で一括で取得されたバックアップデーターを直接操作することができないため、仮想化基盤管理者にファイルのリストアを依頼することになります。

この場合、１つのファイルをリストアするために複数人がかかわることになります。ただこのようなファイルリストアオペレーションは、日常茶飯事であり情報システムを利用する社員が多い会社の場合、この作業だけでシステム管理者の1日が終わってしまうこともあるかもしれません。

ユーザーから見ると、お願いしても複数人を介すので非常に面倒

仮想化基盤管理者から見ると、たくさんの部門の人からこのような依頼が来ると、たいしたことが買い作業ではあるが、手間が増え非常に面倒。ただ、部門管理者に基盤全体のバックアップリポジトリを開放すると、その部門に関係のないバックアップデーター等を閲覧されるとセキュリティ的な問題が発生するなどの課題があり、どうしても基盤管理者の仕事として受けざるを得ないというジレンマがありました。

このような問題を根本解決するというのが、SSRなのです。

次回の項で具体的にSSRの利用方法を見ていきましょう。

CVMのVLANを変更する方法

Nutanixは初期出荷時からCVM(Controller VM)がデプロイされた形で出荷されるため、導入作業において、CVMのデプロイ作業等を行う必要は特にありません。

Nutanix的には、CVMは特別な存在の仮想マシンとして取り扱われ、PRISMの画面で、仮想マシン一覧を表示してもCVMは、デフォルトでは表示されません。

また、このCVMを意図的にシャットダウンをすることもできません。

このCVMは、デフォルトVLAN（つまりUntag）で設定されています。
CVMの通信を意図的に別のVLANに変更した場合、vSphereの場合は、ポートグループを変更することだけで対応可能ですが、AHVの場合はコマンドを使っての対応となります。

今回は、その手法をご紹介します。
尚、この作業は各AHVホストで作業を行います。Nutanixのノードが10台あるのであれば、10台共に行う必要がある作業となりますのでご注意ください。

1.まず、TeraTerm等でSSHにてAHVホストにログインします。

2.AHVから、CVMに「192.168.5.254」を使ってログインします。
（192.168.5.254は、CVMの内部通信側のIPアドレスとなります。そのためどのAHVホストから接続してもCVMのIPアドレスは192.168.5.254で接続可能です）
ログインは、nutanixユーザーでログインしましょう。

#ssh nutanix@192.168.5.254

3.VLAN変更コマンドを実行します。（この場合、VLAN10に変更）

$ change_cvm_vlan 10

最後に「CVM external NIC successfully updated.」というメッセージが出たら終わりです。「exit」コマンドでCVMへの接続を終了します。
また、AHVの接続も「exit」コマンドで終了します。

CVMのVLAN変更は特に何も難しいものではありません。