2020年9月29日火曜日

Splunk 8.0.5をCentOS 7にインストールしてみた② (Universal Forwarderのインストール)

前回、Splunkの本体のインストール手順を記載した。

★前回の記事はこちら↓

本体のインストールが完了したので、次はログ送信側の設定を行う。Splunkではログ送信を行うエージェントとして、「Universal Forwarder」、「Light Forwarder」、「Heavy Forwarder」の3種類がある。それぞれの違いはSplunkの以下マニュアルにて記載されている。

ログを送信する用途だけであればUniversal Forwarderを、ログ送信の際にログの分析・加工が必要な場合はLight Forwarder、Heavy Forwarderを利用するようだ。なお、Universal Forwarderのインストーラは個別で用意されているが、Light Forwarder、Heavy Forwarderのインストーラは本体と同じインストーラを利用し、Splunk本体の機能の中からログ送信の機能のみ有効にする形で利用する。

今回は、Universal ForwarderをCentOSにインストールし、Splunkの検索画面にてログ検索ができることを確認する。

環境

  • OS : CentOS 7.6
  • インストール状態 : 最小限のインストール

Universal Forwarderインストール手順

1. インストーラのダウンロード

インストーラは以下URLからダウンロードできる。ダウンロードするためにはSplunkサイトのユーザ登録が必要となるので注意

2. 事前準備

インストール手順簡略化のため、firewalldとSELinuxは停止しておく。

# systemctl stop firewalld
# systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.

# sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/sysconfig/selinux

3. インストール

Spulunk本体と同様にインストールはtgzファイルを解凍するだけよい。追加でパッケージインストールなども不要であり、インストール自体は極めてシンプルになるよう設計されている。

# tar xvzf splunkforwarder-8.0.5-a1a6394cc5ae-Linux-x86_64.tgz -C /opt

Universal Forwarderは「/opt/splunkforwarder」に解凍される。以下ディレクトリでよく使うものは以下となる。

ディレクトリ 説明
bin 実行ファイルが配置されている。特にsplunkコマンドは起動・停止や設定確認などで頻繁に使用する。
etc Universal Forwarderの設定ファイルとなるconfファイルが配置されている。CLIによる設定を行った内容は、本ディレクトリ配下のconfファイルに反映され保存される。なお、直接confファイルに設定追加することも可能。
# ls -l /opt/splunkforwarder/
合計 156
-r--r--r--.  1 10777 10777   841  7月  8 16:52 README-splunk.txt
drwxr-xr-x.  3 10777 10777  4096  7月  8 17:13 bin
-r--r--r--.  1 10777 10777    57  7月  8 16:49 copyright.txt
drwxr-xr-x. 13 10777 10777  4096  7月  8 17:10 etc
-rw-r--r--.  1 10777 10777     0  7月  8 17:10 ftr
drwxr-xr-x.  2 10777 10777    27  7月  8 17:10 include
drwxr-xr-x.  5 10777 10777  4096  7月  8 17:13 lib
-r--r--r--.  1 10777 10777 85709  7月  8 16:49 license-eula.txt
drwxr-xr-x.  3 10777 10777    58  7月  8 17:10 openssl
drwxr-xr-x.  4 10777 10777    63  7月  8 17:10 share
-r--r--r--.  1 10777 10777 50969  7月  8 17:13 splunkforwarder-8.0.5-a1a6394cc5ae-linux-2.6-x86_64-manifest

4. Universal Forwarderの初回起動と初期設定

「/opt/splunkforwarder/bin」ディレクトリにUniversal Forwarder本体の実行ファイルがあるので、以下の通り実行することで、初回起動時の以下処理が実行される。

  • ライセンス条項に同意
  • 管理ユーザ名の設定 (デフォルトはadmin)
  • 管理ユーザのパスワードの設定
# cd /opt/splunkforwarder/bin/
# ./splunk start

SPLUNK GENERAL TERMS

Last updated: February 13, 2020

These Splunk General Terms ("General Terms") between
Splunk Inc., a Delaware corporation, with its principal place
of business at 270 Brannan Street, San Francisco,
California 94107, U.S.A ("Splunk" or "we" or "us" or "our")
and you ("Customer" or "you" or "your") apply to the
purchase of licenses and subscriptions for Splunk's
Offerings. By clicking on the appropriate button, or by
downloading, installing, accessing or using the Offerings,
you agree to these General Terms. If you are entering into
these General Terms on behalf of Customer, you represent
that you have the authority to bind Customer. If you do not
agree to these General Terms, or if you are not authorized
to accept the General Terms on behalf of the Customer, do
not download, install, access, or use any of the Offerings.

See the General Terms Definitions Exhibit attached for
definitions of capitalized terms not defined herein.

1. License Rights

~(中略)~

"Statement of Work" means the statements of work and/or any all
applicable Orders that describe the specific services to be performed by
Splunk, including any materials and deliverables to be delivered by
Splunk.


SPLUNK GENERAL TERMS (v1.2020)


Do you agree with this license? [y/n]: y   ←★"y"を入力

This appears to be your first time running this version of Splunk.

Splunk software must create an administrator account during startup. Otherwise, you cannot log in.
Create credentials for the administrator account.
Characters do not appear on the screen when you type in credentials.

Please enter an administrator username: admin ←★管理者ユーザ名を入力
Password must contain at least:
   * 8 total printable ASCII character(s).
Please enter a new password:   ←★パスワードを入力
Please confirm new password:   ←★パスワードを再入力

Splunk> All batbelt. No tights.

Checking prerequisites...
        Checking mgmt port [8089]: open
                Creating: /opt/splunkforwarder/var/lib/splunk
                Creating: /opt/splunkforwarder/var/run/splunk
                Creating: /opt/splunkforwarder/var/run/splunk/appserver/i18n
                Creating: /opt/splunkforwarder/var/run/splunk/appserver/modules/static/css
                Creating: /opt/splunkforwarder/var/run/splunk/upload
                Creating: /opt/splunkforwarder/var/run/splunk/search_telemetry
                Creating: /opt/splunkforwarder/var/spool/splunk
                Creating: /opt/splunkforwarder/var/spool/dirmoncache
                Creating: /opt/splunkforwarder/var/lib/splunk/authDb
                Creating: /opt/splunkforwarder/var/lib/splunk/hashDb
New certs have been generated in '/opt/splunkforwarder/etc/auth'.
        Checking conf files for problems...
        Done
        Checking default conf files for edits...
        Validating installed files against hashes from '/opt/splunkforwarder/splunkforwarder-8.0.5-a1a6394cc5ae-linux-2.6-x86_64-manifest'
        All installed files intact.
        Done
All preliminary checks passed.

Starting splunk server daemon (splunkd)...
Done
                                                           [  OK  ]

5. 自動起動設定

tgzファイルを解凍しただけなので、これだけではサーバ再起動時に自動起動してくれないため、以下コマンドで自動起動するよう設定する。

# cd /opt/splunkforwarder/bin/
# ./splunk enable boot-start
Init script installed at /etc/init.d/splunk.
Init script is configured to run at boot.

6. 送信先のサーバ (インデクサー) を設定

Splunkのログ受信および解析を行う機能を「インデクサー」と呼ぶ。Universal Forwarderのログ送信先としてインデクサーを指定する必要があるため、splunk add forward-server <インデクサーのIPアドレス or ホスト名>:<ポート番号>コマンドにて行う。

# cd /opt/splunkforwarder/bin/
# ./splunk add forward-server 192.168.11.71:9997
Splunk username: admin
Password:
Added forwarding to: 192.168.11.71:9997.
# ./splunk list forward-server
Active forwards:
        None
Configured but inactive forwards:
        192.168.11.71:9997

本設定は、「/opt/splunkforwarder/etc/system/local/outputs.conf」に記述される。

# cat /opt/splunkforwarder/etc/system/local/outputs.conf
[tcpout]
defaultGroup = default-autolb-group

[tcpout:default-autolb-group]
server = 192.168.11.71:9997

[tcpout-server://192.168.11.71:9997]

7. Splunk本体 (インデクサー) 側で受信設定を追加

Splunkはデフォルトでは受信設定がされていない。Splunk本体の管理GUIにログインし、「設定」→「転送と受信」→「データの受信」を開いたのち、ポート番号「9997」にて新規作成を行う。

設定後に、Splunk本体で設定したポートでListenしていることを確認しておこう。

# ss -nl | grep 9997
tcp    LISTEN     0      128       *:9997                  *:*

8. モニター対象のログを追加

今回は例として/var/log配下のログをすべて監視対象として、Splunk本体のインデクサーに送信する。splunk add monitor <モニター対象のファイル or ディレクトリ>コマンドで設定する。

# cd /opt/splunkforwarder/bin/
# ./splunk add monitor /var/log
Added monitor of '/var/log'.

splunk list monitorで設定確認を行う。

# ./splunk list monitor
Monitored Directories:
        $SPLUNK_HOME/var/log/splunk
                /opt/splunkforwarder/var/log/splunk/btool.log
                /opt/splunkforwarder/var/log/splunk/first_install.log
                /opt/splunkforwarder/var/log/splunk/splunkd-utility.log
        $SPLUNK_HOME/var/log/splunk/splunkd.log
                /opt/splunkforwarder/var/log/splunk/splunkd.log
        $SPLUNK_HOME/var/log/watchdog/watchdog.log*
        $SPLUNK_HOME/var/run/splunk/search_telemetry/*search_telemetry.json
        $SPLUNK_HOME/var/spool/splunk/...stash_new
Monitored Files:
        $SPLUNK_HOME/etc/splunk.version
        /var/log   ←★対象が追加されている

設定の反映のため、Universal Forwarderをリスタートする。再起動は30秒ほど要したが問題なく完了した。

# ./splunk restart
Stopping splunkd...
Shutting down.  Please wait, as this may take a few minutes.
.............                                              [  OK  ]
Stopping splunk helpers...
                                                           [  OK  ]
Done.

Splunk> All batbelt. No tights.

Checking prerequisites...
        Checking mgmt port [8089]: open
        Checking conf files for problems...
        Done
        Checking default conf files for edits...
        Validating installed files against hashes from '/opt/splunkforwarder/splunkforwarder-8.0.5-a1a6394cc5ae-linux-2.6-x86_64-manifest'
        All installed files intact.
        Done
All preliminary checks passed.

Starting splunk server daemon (splunkd)...
Done
                                                           [  OK  ]

再度splunk list monitorで設定確認を行うと、/var/log配下のログファイルがファイル単位でモニター対象となっていることがわかる。

# ./splunk list monitor
Your session is invalid.  Please login.
Splunk username: admin
Password:
Monitored Directories:

~(中略)~

        /var/log
                /var/log/anaconda
                /var/log/anaconda/anaconda.log
                /var/log/anaconda/ifcfg.log
                /var/log/anaconda/journal.log
                /var/log/anaconda/ks-script-wAP9r2.log
                /var/log/anaconda/packaging.log
                /var/log/anaconda/program.log
                /var/log/anaconda/storage.log
                /var/log/anaconda/syslog
                /var/log/anaconda/X.log
                /var/log/audit
                /var/log/audit/audit.log
                /var/log/boot.log
                /var/log/btmp
                /var/log/chrony
                /var/log/cron
                /var/log/dmesg
                /var/log/dmesg.old
                /var/log/firewalld
                /var/log/grubby_prune_debug
                /var/log/lastlog
                /var/log/maillog
                /var/log/messages
                /var/log/rhsm
                /var/log/secure
                /var/log/spooler
                /var/log/tallylog
                /var/log/tuned
                /var/log/tuned/tuned.log
                /var/log/vmware-network.log
                /var/log/vmware-vgauthsvc.log.0
                /var/log/vmware-vmsvc.log
                /var/log/wtmp
Monitored Files:
        $SPLUNK_HOME/etc/splunk.version

以上で、Universal Forwarderの設定は完了となる。

Splunkにてログを検索してみる

実際に取得したログを検索してみよう。Splunkはログを解析するための設定として、「ソースタイプ」があり、ログの日付フォーマットやログのフィールドの内容 (たとえば、syslogなら日付情報の次にホスト名が来るなど) が定義されている。

以下マニュアルに記載の通り、Splunkはログの内容を分析し、適切なソースタイプが決定されるようだ。

Splunk software next attempts to use automatic source type recognition to match similar-looking files and assign a source type.
たとえば、以下のようにファイルごとにソースタイプが設定される。

実際の環境で確認すると、以下のように/var/log配下のログのソースタイプは、特にソースタイプを指定しなくとも自動的に以下のように適切に設定されていることがわかる。

ログファイル ソースタイプ
/var/log/audit/audit.log linux_audit
/var/log/messages syslog
/var/log/secure linux_secure


Universal Forwarderの起動・停止

インストール自体は完了しているが、Universal Forwarderの起動・停止のコマンドも紹介する。

コマンド 説明
/opt/splunkforwarder/bin/splunk start 起動
/opt/splunkforwarder/bin/splunk stop 停止
/opt/splunkforwarder/bin/splunk restart 再起動
/opt/splunkforwarder/bin/splunk status ステータス確認

以下実行例となる。

まとめ

以上でUniversal Forwarderインストールは完了となる。Splunk本体同様、tgzファイルを解凍して、いくつか設定をするだけですぐに利用することができる。一度設定手順を経験しておけば、次回以降は容易にインストール作業をすることができるだろう。

2020年9月26日土曜日

Splunk 8.0.5をCentOS 7にインストールしてみた① (Splunk本体のインストール)

ログ管理ツール (SIEM : Security Information and Event Management) で有名なソフトウェアである「Splunk Enterprise (以降、Splunk) 」は、インストール後60日間は無料トライアル版による全機能の利用が可能であり、さらに60日後は一部機能限定とはなるものの、そのまま「Splunk Free」として利用することができる (当然ライセンスを購入すれば商用版として利用が可能)。

各製品の機能比較は以下URLに記載がされている。

Splunkは、Windows、Linux、Mac OSと幅広いプラットフォームをサポートしている。今回はCentOS 7環境にSplunkを導入する手順を紹介する。

なお、今回はSplunk本体 (ログ受信側) のインストールまでを記載し、次回以降で「Splunk Universal Forwarder」を利用したログ送信およびSplunk本体にてログ受信を行う設定手順を記載する。

★↓Splunk Universal Forwarderのインストールと設定手順はこちら。

環境

  • OS : CentOS 7.6
  • インストール状態 : 最小限のインストール

Splunkインストール手順

1. インストーラのダウンロード

インストーラは以下URLからダウンロードできる。無料トライアル版もFree版も同じものがダウンロードできる。ダウンロードするためにはSplunkサイトのユーザ登録が必要となるので注意

.deb、.tgz、.rpmの3種類が用意されているが、ディストリビューションが変わっても手順に応用が利くことから、今回は「.tgz版」をダウンロードする。

2. 事前準備

インストール手順簡略化のため、firewalldとSELinuxは停止しておく。

# systemctl stop firewalld
# systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.

# sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/sysconfig/selinux

3. インストール

インストールはtgzファイルを解凍するだけよい。追加でパッケージインストールなども不要であり、インストール自体は極めてシンプルになるよう設計されている。

# tar xvzf splunk-8.0.5-a1a6394cc5ae-Linux-x86_64.tgz -C /opt

Splunkは「/opt/splunk」に解凍される。以下ディレクトリでよく使うものは以下となる。

ディレクトリ 説明
bin 実行ファイルが配置されている。特にsplunkコマンドは起動・停止や設定確認などで頻繁に使用する。
etc Splunkの設定ファイルとなるconfファイルが配置されている。今回は詳しくは説明しないが、Web管理画面で設定追加されたものは、すべて本ディレクトリ配下のconfファイルに設定がテキストで書き込まれると考えて差し支えない。直接confファイルに設定追加することも可能。
# ls -l /opt/splunk/
合計 2916
-r--r--r--.  1 10777 10777     841  7月  8 16:52 README-splunk.txt
drwxr-xr-x.  4 10777 10777    4096  7月  8 17:12 bin
-r--r--r--.  1 10777 10777      57  7月  8 16:49 copyright.txt
drwxr-xr-x. 15 10777 10777    4096  7月  8 17:10 etc
-rw-r--r--.  1 10777 10777       0  7月  8 17:10 ftr
drwxr-xr-x.  4 10777 10777      62  7月  8 17:10 include
drwxr-xr-x.  8 10777 10777    4096  7月  8 17:13 lib
-r--r--r--.  1 10777 10777   85709  7月  8 16:49 license-eula.txt
drwxr-xr-x.  3 10777 10777      58  7月  8 17:10 openssl
drwxr-xr-x.  4 10777 10777     108  7月  8 17:10 share
-r--r--r--.  1 10777 10777 2875790  7月  8 17:13 splunk-8.0.5-a1a6394cc5ae-linux-2.6-x86_64-manifest

4. Splunkの初回起動と初期設定

「/opt/splunk/bin」ディレクトリにSplunk本体の実行ファイルがあるので、以下の通り実行することで、初回起動時の以下処理が実行される。

  • ライセンス条項に同意
  • 管理ユーザ名の設定 (デフォルトはadmin)
  • 管理ユーザのパスワードの設定
# cd /opt/splunk/bin/
# ./splunk start

SPLUNK GENERAL TERMS

Last updated: February 13, 2020

These Splunk General Terms ("General Terms") between
Splunk Inc., a Delaware corporation, with its principal place
of business at 270 Brannan Street, San Francisco,
California 94107, U.S.A ("Splunk" or "we" or "us" or "our")
and you ("Customer" or "you" or "your") apply to the
purchase of licenses and subscriptions for Splunk's
Offerings. By clicking on the appropriate button, or by
downloading, installing, accessing or using the Offerings,
you agree to these General Terms. If you are entering into
these General Terms on behalf of Customer, you represent
that you have the authority to bind Customer. If you do not
agree to these General Terms, or if you are not authorized
to accept the General Terms on behalf of the Customer, do
not download, install, access, or use any of the Offerings.

See the General Terms Definitions Exhibit attached for
definitions of capitalized terms not defined herein.

1. License Rights

~(中略)~

"Statement of Work" means the statements of work and/or any all
applicable Orders that describe the specific services to be performed by
Splunk, including any materials and deliverables to be delivered by
Splunk.


SPLUNK GENERAL TERMS (v1.2020)


Do you agree with this license? [y/n]: y   ←★"y"を入力

This appears to be your first time running this version of Splunk.

Splunk software must create an administrator account during startup. Otherwise, you cannot log in.
Create credentials for the administrator account.
Characters do not appear on the screen when you type in credentials.

Please enter an administrator username: admin ←★管理者ユーザ名を入力
Password must contain at least:
   * 8 total printable ASCII character(s).
Please enter a new password:   ←★パスワードを入力
Please confirm new password:   ←★パスワードを再入力
Copying '/opt/splunk/etc/openldap/ldap.conf.default' to '/opt/splunk/etc/openldap/ldap.conf'.
Generating RSA private key, 2048 bit long modulus
.........................................+++++
..............................+++++
e is 65537 (0x10001)
writing RSA key

~(中略)~

If you get stuck, we're here to help.
Look for answers here: http://docs.splunk.com

The Splunk web interface is at http://t1071splk:8000

5. 自動起動設定

tgzファイルを解凍しただけなので、これだけではサーバ再起動時に自動起動してくれないため、以下コマンドで自動起動するよう設定する。

# /opt/splunk/bin/splunk enable boot-start
Init script installed at /etc/init.d/splunk.
Init script is configured to run at boot.

試しに再起動を行ったのちステータスを確認したところ、問題なくSplunkが「running」ステータスとなっていた。

# /opt/splunk/bin/splunk status
splunkd is running (PID: 1616).
splunk helpers are running (PIDs: 1620 1635 1711 1831).

6. 管理Web画面にアクセス

以上を実施したのち「http://<インストールしたホスト名 or IPアドレス>:8000」にアクセスすると、管理画面が表示されるはずなので、初回起動時に設定した管理者ユーザとパスワードでログインしてみよう。

初回ログイン時のみ以下2つの警告が表示されるが、どちらも「了解です!」、「再度表示しない」を選択しておけばよい。


問題なければ以下のようなSplunkの管理画面が表示される。


Splunkの起動・停止

インストール自体は完了しているが、Splunkの起動・停止のコマンドも紹介する。

コマンド 説明
/opt/splunk/bin/splunk start 起動
/opt/splunk/bin/splunk stop 停止
/opt/splunk/bin/splunk restart 再起動
/opt/splunk/bin/splunk status ステータス確認

以下実行例となる。

停止

# /opt/splunk/bin/splunk stop
Stopping splunkd...
Shutting down.  Please wait, as this may take a few minutes.
..                                                         [  OK  ]
Stopping splunk helpers...
                                                           [  OK  ]
Done.

起動

# /opt/splunk/bin/splunk start

Splunk> All batbelt. No tights.

Checking prerequisites...
        Checking http port [8000]: open
        Checking mgmt port [8089]: open
        Checking appserver port [127.0.0.1:8065]: open
        Checking kvstore port [8191]: open
        Checking configuration... Done.
        Checking critical directories...        Done
        Checking indexes...
                Validated: _audit _internal _introspection _metrics _metrics_rollup _telemetry _thefishbucket history main summary
        Done
        Checking filesystem compatibility...  Done
        Checking conf files for problems...
        Done
        Checking default conf files for edits...
        Validating installed files against hashes from '/opt/splunk/splunk-8.0.5-a1a6394cc5ae-linux-2.6-x86_64-manifest'
        All installed files intact.
        Done
All preliminary checks passed.

Starting splunk server daemon (splunkd)...
Done
                                                           [  OK  ]

Waiting for web server at http://127.0.0.1:8000 to be available. Done


If you get stuck, we're here to help.
Look for answers here: http://docs.splunk.com

The Splunk web interface is at http://t1071splk:8000

ステータス確認

# /opt/splunk/bin/splunk status
splunkd is running (PID: 3105).
splunk helpers are running (PIDs: 3112 3126 3254 3308 3418).

まとめ

以上でSplunkインストールは完了となる。この状態からログ受信の設定を少し設定するだけでログ収集が開始できる。実施する前は、Splunkのインストールはもっと手間のかかるものと予想していたが、極めて容易かつ短時間でインストールできてしまうことに驚いた。

次回は「Splunk Universal Forwarder」をインストールし、LinuxのログをSplunkに送信し、ログ検索ができることまでを確認する。

2020年9月21日月曜日

【RHEL】コピーしたディスクを別のサーバにマウントする手順

前回、RHELにてコピーしたディスクを自分自身にマウントする手順を記事にした。

コピーしたディスクを自分自身にマウントする場合は、LVMやXFSのUUIDが重複するため、UUIDの変更を実施する必要があり、手順として手数の多いものになっていた。

今回は、自分自身ではなくコピーしたディスクを別のサーバにマウントする手順を記載する。一部手順は同一となっており、XFSのUUID変更が不要となるため、比較的シンプルな手順となる。

環境

  • 仮想環境 : ESXi 6.7
  • コピー元OS : RHEL 7
  • コピー元ディスク : OSインストール領域 /dev/sda2 16GB
  • マウント先OS : RHEL 8
  • 複製ディスク : /dev/sdb2

コピーしたディスクをマウントする手順

1. ディスクの状態確認

ディスクの状態確認として、PV、VG、LVの状態をそれぞれ確認してみる。別のサーバのディスクなので、VG名が重複するものの、UUIDは重複しないため警告メッセージは表示されない。

# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda3  rhel lvm2 a--   14.41g    0
  /dev/sdb2  rhel lvm2 a--  <15.00g    0

# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  rhel   1   2   0 wz--n- <15.00g    0
  rhel   1   2   0 wz--n-  14.41g    0

# lvs
  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root rhel -wi-------  13.39g                                                  
  root rhel -wi-ao---- <12.81g                                                  
  swap rhel -wi-------   1.60g                                                  
  swap rhel -wi-ao----   1.60g                                                  

2. vgimportcloneにて重複したVGをインポート

VG名を変更するため、前回同様、vgimportcloneにてVGのインポートを行う。インポート後、VG名が修正 (末尾に"1"が付与) されていれば問題ない。

# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  rhel   1   2   0 wz--n- <15.00g    0
  rhel   1   2   0 wz--n-  14.41g    0

# vgimportclone /dev/sdb2

# vgs
  VG    #PV #LV #SN Attr   VSize   VFree
  rhel    1   2   0 wz--n-  14.41g    0
  rhel1   1   2   0 wz--n- <15.00g    0

3. VGのアクティブ化

vgimportcloneを実行後のVGは非アクティブとなっている。非アクティブとなっていることは、vgdisplay -A表示されないことで確認できる。

# vgdisplay -A
  --- Volume group ---
  VG Name               rhel
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
~(以下略)~

VGを使用できるようにするため、以下コマンドでアクティブにする。

# vgchange -ay rhel1
  2 logical volume(s) in volume group "rhel1" now active

再度vgdisplay -Aで確認すると、VGが表示される (アクティブ化されている) ことがわかる。

# vgdisplay -A
  --- Volume group ---
  VG Name               rhel1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
~(中略)~

  --- Volume group ---
  VG Name               rhel
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
~(以下略)~

4. マウントして確認

この段階でマウントできるようになっている。実際にマウントして確認した結果は以下の通り。

# mount /dev/mapper/rhel1-root /mnt/
# ls -l /mnt/
合計 12
lrwxrwxrwx.  1 root root    7  8月 30 03:25 bin -> usr/bin
drwxr-xr-x.  2 root root    6  8月 30 03:24 boot
drwxr-xr-x.  2 root root    6  8月 30 03:24 dev
drwxr-xr-x. 77 root root 8192  8月 30 03:31 etc
drwxr-xr-x.  2 root root    6 12月 14  2017 home
lrwxrwxrwx.  1 root root    7  8月 30 03:25 lib -> usr/lib
lrwxrwxrwx.  1 root root    9  8月 30 03:25 lib64 -> usr/lib64
drwxr-xr-x.  2 root root    6 12月 14  2017 media
drwxr-xr-x.  2 root root    6 12月 14  2017 mnt
drwxr-xr-x.  2 root root    6 12月 14  2017 opt
drwxr-xr-x.  2 root root    6  8月 30 03:24 proc
dr-xr-x---.  2 root root  135  8月 30 03:29 root
drwxr-xr-x.  2 root root    6  8月 30 03:24 run
lrwxrwxrwx.  1 root root    8  8月 30 03:25 sbin -> usr/sbin
drwxr-xr-x.  2 root root    6 12月 14  2017 srv
drwxr-xr-x.  2 root root    6  8月 30 03:24 sys
drwxrwxrwt.  9 root root  202  8月 30 03:31 tmp
drwxr-xr-x. 13 root root  155  8月 30 03:25 usr
drwxr-xr-x. 19 root root  267  8月 30 03:28 var

まとめ

自分自身のマウントする場合と異なり、他サーバへのマウントはvgimportcloneによるVGインポートとVGのアクティブ化のみでマウントできるようになる。そのため、手順としても比較的シンプルになった。

2020年9月20日日曜日

【RHEL】コピーしたディスクを自分自身にマウントする手順

最近のストレージは、ディスクボリュームのデータ静止点をスナップショットにて即座に取得する機能が備わっている。さらにそのスナップショットを使って別のボリュームをコピー (クローンともいう) することも簡単にできる。これらのスナップショットの機能は、個人向けのQNAPのNASやFreeNASでさえも使用できる機能となっている

ただし、スナップショットからコピーしたボリュームは原則ストレージ上でファイルの中身を確認することができないため、一度ファイルシステムを閲覧できるサーバにマウントする必要がある。

Windows Serverであれば深く考えずにコピーしたディスクを接続するだけで問題なくマウントできる。しかし、RHELの場合は、LVMやXFSを使用している関係から、ひと手間が必要となる。

今回は、RHELの環境において、コピーしたディスクを別のマウントポイントにマウントするための手順を記載する

なお、コピーしたディスクを別のサーバにマウントする手順は以下を参照すること。


環境

  • 仮想環境 : ESXi 6.7
  • OS : RHEL 7
  • ディスク : OSインストール領域 /dev/sda2 16GB
  • 複製ディスク : /dev/sdb2

なお、複製したディスクは、ESXiのvmkfstoolsを使用して作成した。参考までに実行コマンドを記載しておく。

# vmkfstools -i /vmfs/volumes/ssd_local_02/rhel7/rhel7.vmdk /vmfs/volumes/ssd_local_02/rhel7/rhel7-clone.vmdk
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/ssd_local_02/rhel7/rhel7.vmdk'...
Clone: 100% done.

コピーしたディスクは以下の通りUUIDが同じとなっている。

#  vmkfstools -J getuuid /vmfs/volumes/ssd_local_02/rhel7/rhel7.vmdk
UUID is 60 00 C2 97 d9 eb af 77-9a b3 ed 24 0e 90 3b 52
#  vmkfstools -J getuuid /vmfs/volumes/ssd_local_02/rhel7/rhel7-clone.vmdk
UUID is 60 00 C2 9c 45 ba 73 2a-f0 2e 18 ca 9b db 42 42

なお、今回はvmdkファイルのUUIDが重複していても仮想マシンに既存のディスクとして問題なく追加することができたが、もし失敗する場合は、以下コマンドでUUIDを変更してリトライするとよいだろう。

#  vmkfstools -J setuuid /vmfs/volumes/ssd_local_02/rhel7/rhel7-clone.vmdk

コピーしたディスクをマウントする手順

1. ディスクの状態確認

ディスクの状態確認として、PV、VG、LVの状態をそれぞれ確認してみる。PVの情報が重複していることにより、「duplicate PVs were found」のメッセージが表示されていることがわかる。

# pvs
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: Not using device /dev/sdb2 for PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey.
  WARNING: PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey prefers device /dev/sda2 because device is used by LV.
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  rhel lvm2 a--  <15.00g    0

# vgs
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: Not using device /dev/sdb2 for PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey.
  WARNING: PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey prefers device /dev/sda2 because device is used by LV.
  VG   #PV #LV #SN Attr   VSize   VFree
  rhel   1   2   0 wz--n- <15.00g    0

# lvs
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: Not using device /dev/sdb2 for PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey.
  WARNING: PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey prefers device /dev/sda2 because device is used by LV.
  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root rhel -wi-ao---- 13.39g
  swap rhel -wi-ao----  1.60g

2. vgimportcloneにて重複したVGをインポート

重複したLVM情報を修正し使用できるようにするコマンドとしてvgimportcloneがある。以下、man vgimportcloneの結果から引用となるが、「vgimportcloneは、ハードウェアスナップショットによって既存のPVから作成したことで重複しているPVから、VGをインポートする」と記載されており、完全に今回の用途のみに特化したコマンドとなる。

DESCRIPTION
vgimportclone imports a VG from duplicated PVs, e.g. created by a hardware snapshot of existing PVs.

A duplicated VG cannot used until it is made to coexist with the original VG. vgimportclone renames the VG associated with the specified PVs and changes the associated VG and PV UUIDs.

実際にvgimportcloneを実行してみよう。UUIDが変わることを確認するため、前後でblkidコマンドを実行している。

# blkid | grep UUID | grep sdb2
/dev/sdb2: UUID="FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey" TYPE="LVM2_member"

# vgimportclone /dev/sdb2
  WARNING: Not using device /dev/sdb2 for PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey.
  WARNING: PV FbbJX5-u5fM-JLHS-nV4k-2kEn-k1CO-d9fUey prefers device /dev/sda2 because device is used by LV.

# blkid | grep UUID | grep sdb2
/dev/sdb2: UUID="z6QKgZ-kaFi-egjF-0GBo-cLHd-fmKc-HNb6ZP" TYPE="LVM2_member"

vgimportcloneを実行したことによって重複していたPVのUUIDの変更とVG名が修正 (末尾に"1"が付与) されており、LVM情報を出力した際に表示されていた警告メッセージも解消されていることがわかる。

# pvs
  PV         VG    Fmt  Attr PSize   PFree
  /dev/sda2  rhel  lvm2 a--  <15.00g    0
  /dev/sdb2  rhel1 lvm2 a--  <15.00g    0

# vgs
  VG    #PV #LV #SN Attr   VSize   VFree
  rhel    1   2   0 wz--n- <15.00g    0
  rhel1   1   2   0 wz--n- <15.00g    0

# lvs
  LV   VG    Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root rhel  -wi-ao---- 13.39g
  swap rhel  -wi-ao----  1.60g
  root rhel1 -wi------- 13.39g
  swap rhel1 -wi-------  1.60g

3. VGのアクティブ化

vgimportcloneを実行後のVGは非アクティブとなっている。非アクティブとなっていることは、vgdisplay -A表示されないことで確認できる。

# vgdisplay -A
  --- Volume group ---
  VG Name               rhel
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
~(以下略)~

VGを使用できるようにするため、以下コマンドでアクティブにする。

# vgchange -ay rhel1
  2 logical volume(s) in volume group "rhel1" now active

再度vgdisplay -Aで確認すると、VGが表示される (アクティブ化されている) ことがわかる。

# vgdisplay -A
  --- Volume group ---
  VG Name               rhel1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
~(中略)~

  --- Volume group ---
  VG Name               rhel
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
~(以下略)~

4. xfsファイルシステムのUUID変更

RHEL 7以降は標準でXFSが使用されているが、XFSにもUUIDが存在しており、重複したままではマウントすることができない。XFSのUUID変更は、xfs_admin -U generate <ストレージデバイス>にて行う。

# xfs_admin -U generate /dev/mapper/rhel1-root
Clearing log and setting UUID
writing all SBs
new UUID = aea68ec1-63cc-445a-90d2-a37f2b0df0c9

上記コマンドを実行した際に、以下エラーで失敗する場合がある。

# xfs_admin -U generate /dev/mapper/rhel1-root
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_admin.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

いろいろメッセージが書いてあるが、記載されている通り、xfs_repair -Lを使うことで対処する。問題なく修復できたら、再度xfs_adminコマンドにてUUID変更を実施すればよい。

# xfs_repair -L /dev/mapper/rhel1-root
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
agi unlinked bucket 27 is 422747 in ag 1 (inode=4617051)
agi unlinked bucket 30 is 422750 in ag 1 (inode=4617054)
sb_fdblocks 1350116, counted 1358308
        - found root inode chunk

~(中略)~

Phase 7 - verify and correct link counts...
Maximum metadata LSN (7:9383) is ahead of log (1:2).
Format log to cycle 10.
done

5. マウントして確認

ここまで対処することで、ようやくファイルシステムをマウントすることができるので、実際にマウントしてファイルが閲覧できることを確認してみよう。

# mount /dev/mapper/rhel1-root /mnt/
# ls -l /mnt/
合計 12
lrwxrwxrwx.  1 root root    7  8月 30 16:25 bin -> usr/bin
drwxr-xr-x.  2 root root    6  8月 30 16:24 boot
drwxr-xr-x.  2 root root    6  8月 30 16:24 dev
drwxr-xr-x. 77 root root 8192  8月 30 16:31 etc
drwxr-xr-x.  2 root root    6 12月 15  2017 home
lrwxrwxrwx.  1 root root    7  8月 30 16:25 lib -> usr/lib
lrwxrwxrwx.  1 root root    9  8月 30 16:25 lib64 -> usr/lib64
drwxr-xr-x.  2 root root    6 12月 15  2017 media
drwxr-xr-x.  2 root root    6 12月 15  2017 mnt
drwxr-xr-x.  2 root root    6 12月 15  2017 opt
drwxr-xr-x.  2 root root    6  8月 30 16:24 proc
dr-xr-x---.  2 root root  135  8月 30 16:29 root
drwxr-xr-x.  2 root root    6  8月 30 16:24 run
lrwxrwxrwx.  1 root root    8  8月 30 16:25 sbin -> usr/sbin
drwxr-xr-x.  2 root root    6 12月 15  2017 srv
drwxr-xr-x.  2 root root    6  8月 30 16:24 sys
drwxrwxrwt.  9 root root  202  8月 30 16:31 tmp
drwxr-xr-x. 13 root root  155  8月 30 16:25 usr
drwxr-xr-x. 19 root root  267  8月 30 16:28 var

まとめ

以上で、RHELにおいてコピーしたディスクをマウントすることができた。しかし、実施しなければならない手順が多く、vgimportcloneのコマンドの存在を知らないとそもそもマウントさせることも難しいので、可能なら、コピーしたディスクは同じOSではなく別のOSなどにマウントする方が、手順としては簡単になると感じた。

2020年9月19日土曜日

QNAP NASのiSCSIボリュームをクローンして別のVMFSデータストアとしてマウントさせる手順

最近のストレージはスナップショット機能が充実しており、QNAPのNASのようなコンシューマー向けのNASですらスナップショット機能が使えるようになっている。

さらにスナップショットからクローンしたボリュームを作成する機能もあり、単純にスナップショットから元のボリュームをリストアするだけでなく、クローンしたボリュームから特定のファイル、あるいは仮想ハードディスク(vmdkファイル)だけをリストアするといった用途にも使用することができる。

vSphere環境でも、データストアとして利用しているボリュームをコピーし、別データストアとしてマウントすることで、特定の仮想マシンのvmdkファイルのみリストアするといった対応が可能であり、今回その手順を確認してみた。

なお、この手順はESXi単体では実施することができずvCenter Serverが必要となるため、注意すること。

QNAP NASでiSCSIボリュームをクローンする

1. スナップショットの作成

「ストレージ&スナップショット」を開き、「ストレージ」→「ストレージ/スナップショット」を選択する。


ボリュームの一覧が表示されるので、スナップショットを取得したいボリューム( 今回は「iscsi_qnap_01」)を右クリックし、「スナップショットを撮る」を選択する。


スナップショット取得時には、「読み取り/書き込み性能が永続的に低下する」旨のメッセージが表示される。これは、スナップショットを取得することで、ボリュームの差分ブロックの管理のオーバーヘッドが発生するため、影響が劣化することを示すメッセージとなる。


2. スナップショットタイプの選択

スナップショット取得時は、スナップショットタイプとして、以下2つが選択可能となる。
  • クラッシュコンシステント
  • アプリケーションコンシステント
アプリケーションコンシステントは、OSにエージェントの導入(vSphere連携の場合は、vCenter Serverとの連携設定)が必要となるため、今回は、「クラッシュコンシステント」を選択する。


3.  スナップショットのクローンを作成

スナップショット取得後、対象のボリュームのカメラマークをクリックすると、「スナップショットマネージャー」が起動する。


スナップショットマネージャーにて、クローンを行う対象のスナップショットを選択し、「クローン」ボタンを選択する。


クローン作成時に「クローンLUNのマッピング」にチェックすることで、マッピングも併せて実施することができる。今回は、iSCSIとしてマッピングが必要となるため、マッピングにチェックしてクローンを作成する。


4. クローンが作成されたことを確認

しばらく待つと、スナップショットからクローンが作成される。


コピーしたデータストアを別のデータストアとしてマウント

1. ESXiよりデバイスの確認

vCenter Serverにログインし、マウント対象の任意のESXiから「設定」→「ストレージデバイス」を選択し、クローンしたボリュームの認識状況を確認する。


私が検証した際は自動で認識していた。もし認識していないようであれば、ディスクの再スキャンをすること。

2. データストアのマウント

クローンしたボリュームをデータストアしてマウントするため、ストレージツリーを表示させ、右クリック→「ストレージ」→「新しいデータストア」を選択する。


新しいデータストアの設定ウィザードが開くので、以下を設定する。
  • タイプ:VMFS
  • データストア名:Datastore ※後で自動で設定されるためデフォルトのままでOK
  • LUN:クローンしたボリューム



    3. データストアの署名の変更

    マウントオプションで データストアの署名に関する設定を選択できる。
    署名 xxx を持つ未解決の VMFS ボリュームがこのディスク上で検出されました。
    
    検出された VMFS ボリュームを同じ署名でマウントするのか、新しい署名でマウントするのか、またはディスクをフォーマットするのかを指定してください。
    
    新しい署名を割り当て
    ディスク上のデータは保持されます。新しい署名がデータストアに割り当てられて、仮想マシン構成ファイルから既存の署名へのリファレンスが更新されます。 データストアは、元の名前を使用してマウントされます。
    
    既存の署名を保持
    ディスク上のデータは保持されます。データストアは同じ署名を使用してマウントされます。 データストアは、元の名前を使用してマウントされます。
    
    ディスクをフォーマット
    現在のディスク レイアウトが破棄され、すべてのデータが完全に削除されます。
    
    「既存の署名を保持」を選んでしまうと、同じ署名を持つデータストアが重複することにより、以下のメッセージが表示されマウントに失敗する。
    操作に失敗しました。
    ホストの設定中にエラーが発生しました
    操作に失敗しました。診断レポート: Unable to mount this VMFS volume due to the original volume is still online
    


    そのためクローンしたボリュームの場合は、「新しい署名を割り当て」を選択する


    4. ウィザードの終了

    残りのウィザードはデフォルトを選択し終了させる。



    ウィザードを終了させると、「未解決のVMFSボリュームの再署名」というタスクが実行させる。再署名タスク終了後、「VMFSの再スキャン」が自動で実行される。


    5. マウント状態の確認

    ここまで問題なくできれば、ストレージツリーに「snap-xxxxxxxx-<元のデータストア名>」といった名前でデータストアが作成される。データストアの中身を確認すると、きちんと仮想マシンのvmdkファイルを認識していることがわかる。


    まとめ

    以上でクローンしたボリュームを別のデータストアとしてESXiにマウントすることができた。さらにここから、vmdkファイルを仮想マシンに接続することで、スナップショット取得タイミングのファイルなどを確認することができる。

    ただし、RHELなどでは同じUUIDを持つディスクは単純にはマウントできないため、その手順はなかなか複雑なものになる。その手順については、改めて別の記事することにする。

    参考

    Pacemakerにて「リソース単位」でメンテナンスモードに変更する手順

    Pacmekaerのクラスタ環境にてクラスタリソースの監視を抑止する「メンテナンスモード」について、以前以下記事にて記載した。

    上記記事では、「クラスタ全体」及び「ノード単位」を対象としたメンテナンスモードへの変更方法を記載している。しかし、状況によっては個々の「リソース単位」でメンテナンスモードことが必要な場合もあるだろう。

    そのような場合を想定して、Pacmekaerでは特定リソースをメンテナンスモードにするコマンドが用意されている。今回は個々のリソース単位でのメンテナンスモードへの変更方法を記載する。

    特定リソースをメンテナンスモードにするコマンド

    特定のリソースをメンテナンスモードへ変更するには、pcs resource unmanageコマンドで実行可能となる。

    # pcs resource unmanage <リソース名>
    

    メンテナンスモードを解除するには、pcs resource manageコマンドとなる。

    # pcs resource manage <リソース名>
    

    実際にリソースをメンテナンスモードにしてみた

    実際に実行した結果を以下に記載する。★箇所の特定のリソースのみ「unmanaged」ステータスになっていることがわかる。

    # pcs resource unmanage rs-systemd-postfix
    # pcs status
    Cluster name: clst-01
    Cluster Summary:
      * Stack: corosync
      * Current DC: t3022cent (version 2.0.3-5.el8_2.1-4b1f869f0f) - partition with quorum
      * Last updated: Sat Aug 22 22:56:09 2020
      * Last change:  Sat Aug 22 22:56:06 2020 by root via cibadmin on t3021cent
      * 2 nodes configured
      * 9 resource instances configured
    
    Node List:
      * Online: [ t3021cent t3022cent ]
    
    Full List of Resources:
      * Resource Group: rg-01:
        * rs-vip-33 (ocf::heartbeat:IPaddr2):       Started t3021cent
        * rs-systemd-squid  (systemd:squid):        Started t3021cent
        * rs-systemd-postfix        (systemd:postfix):      Started t3021cent (unmanaged) ★
      * Clone Set: rs-systemd-unbound-clone [rs-systemd-unbound]:
        * Started: [ t3021cent t3022cent ]
      * Clone Set: rs-ping-33-clone [rs-ping-33]:
        * Started: [ t3021cent t3022cent ]
      * rs-stonith-01       (stonith:fence_ESXi):   Started t3021cent
      * rs-stonith-02       (stonith:fence_ESXi):   Started t3022cent
    
    Daemon Status:
      corosync: active/disabled
      pacemaker: active/disabled
      pcsd: active/enabled
    
    2020年9月18日金曜日

    FreeNAS 11.3をESXiにインストールしてiSCSIストレージを構築する

    3年前にFreeNAS 9.10を使ってiSCSIストレージをESXi上に構築する方法を記事にした。

    3年も経ったことによってFreeNASのバージョンは11.3と2つもメジャーバージョンアップしている。また、自宅のiSCSIストレージはQNAPのNASを利用しているが、管理GUIの動作が重く検証作業に影響が出ていることから、今回、FreeNAS 11.3にてiSCSIストレージを構築しなおすことにした。

    FreeNASのダウンロード

    FreeNASは以下から最新版をダウンロードできる。770MBほどの容量となる。

    ハードウェア要件は以下の通りとなる。メモリの最低8GBというところがハードルが高くて躊躇したが、8GB以下のメモリでもインストールすることは可能なので検証用途なので今回は4GBでインストールすることにした。

    • CPU : 64bitプロセッサ
    • メモリ : 最低8GB
    • インストールディスク容量 : 最低8GB

    FreeNASのインストール

    FreeNASをインストールするための仮想マシンは、以下の設定にて作成する。この設定は最小構成以下の設定であり、安定した稼働を求めるのであれば、メモリは8GB以上にする必要があるので注意すること。

    • ゲストOSファミリ : その他
    • ゲストOSのバージョン : FreeBSD 11 (64ビット)
    • CPU : 2コア
    • メモリ : 4096MB
    • ハードディスク : 8GB

    FreeNASの初期設定

    1. OSインストール

    FreeNASのISOからブートさせると、シンプルなインストール画面が表示されるので、「Install/Upgrade」を選択する。

    RAMが8GB以下だと以下の通り警告が表示されるが、そのまま「Yes」を選択してインストールを進めることができる。

    Boot Modeは「Boot via BIOS」を選択する。

    2. インストール完了後、再起動

    「Reboot System」を選択して再起動を行う。

    3. IPアドレス設定

    再起動を行うとConsole Setup画面が表示される。デフォルトではDHCPが有効になっているが、毎回IPアドレスが変わると扱いづらいので、固定IPアドレスとする設定を行う。

    「1」を選択し、以下の通り設定する。

    • Select an interface : 1
    • Remove the current settings of this interface? : n
    • Configure interface for DHCP? (y/n) : n
    • Configure IPv4? (y/n) : y
    • Interface name : 任意の名前
    • IPv4 Address : 192.168.11.14/24
    • Configure IPv6? (y/n) : n

    4. デフォルトゲートウェイ設定

    引き続きConsole Setup画面にて「4」を選択し、以下の通り設定する。

    • Configure IPv4 Default Route? (y/n) : y
    • IPv4 Default Route : 192.168.11.31
    • Configure IPv4 Default Route? (y/n) : n

    以上でConsole Setup画面は終了となる。引き続き、Webの管理GUIで作業を行う。

    5. 管理GUIログイン

    ブラウザにて以下のアドレスを入力する。

    • http://<設定したIPアドレス>/

    管理GUIでは以下のユーザでログインする。

    • ユーザ : root
    • パスワード : インストール時に設定したパスワード

    6. タイムゾーンの設定

    デフォルトではタイムゾーンが日本時間になっていない。「System / General」にて「Asia/Tokyo」に変更しておこう。

    7. NTPの設定

    「System / NTP Servers」にてNTPサーバを設定する。デフォルトでは0.freebsd.pool.ntp.orgなどが設定されているが、環境に応じて変更しておこう。

    8. ホスト名の変更

    「Network / Global Configuration」にてホスト名を変更する。ドメイン名は不要であったとしても空白で設定はできないので、何かしら設定をしておくこと。

    プールの作成

    この段階では、FreeNASのOSインストール領域しかなく、データ領域がないため、仮想マシンに仮想ディスクの追加を行ったのち、「プール」と呼ばれるデータ保存領域を作成する。

    1. 仮想マシンにディスクを追加

    これは通常の手順でVMware Host Clientなどから仮想マシンにハードディスクを追加すれば問題ない。今回は100GBのディスクを追加した。

    2. プールを作成

    「Storage / Pools」にてプールを新規作成する。先ほど追加したディスクが「da1」という名前で選択できるようになっているので、プールのディスクとして選択し、プールを作成する。

    なお、ディスク1本で作成することになるので、「Stripe (=RAID 0)」によるプールとなる。仮想環境なのでRAID 1などで冗長化する必要はないので、Stripeの設定で特に問題はない。

    FreeNASのiSCSI設定

    引き続き、FreeNASでiSCSIの設定を行う。

    1. ポータルを作成

    「Sharing / iSCSI / Portals」にて以下の通り、ポータルを作成する。

    設定項目 設定値
    Discriptsion portal-01
    IP Address 192.168.11.14

    2. 接続可能とするイニシエータグループを作成

    「Sharingi / SCSI / Initiators」にてターゲットに接続可能とするイニシエータグループを作成する。今回は特に接続制限を設けないため、「Allow All Initiators」とした。

    設定項目 設定値
    Allow All Initiators チェック

    3. ターゲットの作成

    「Sharingi / SCSI / Targets」にてターゲットを作成する。ターゲットには先ほど設定したポータルとイニシエータグループを設定する。

    設定項目 設定値
    Target Name target-01
    Portal Group ID 1 (potral-01)
    Initiator Group ID 1 (ALL Initiators Allowed)

    4. エクステント (提供するディスク) の作成

    「Sharingi / SCSI / Extents」にてエクステントを作成する。エクステントとは、iSCSIにて提供するディスク領域の設定となる。今回は、iSCSIのエクステントとして「/mnt/pool-01/extent-01」というファイルを作成する設定とした。

    (2020/11/28追記)
    「Disable Physical Block Size Reporting」の設定値をチェックしない場合、vCenter ServerやESXiにてボリュームをVMFSやRDMでマウントしようとした際に以下のようなメッセージで失敗するので注意すること。

    VMFS データストア データストア名 の作成に失敗しました: 操作に失敗しました。診断レポート: Unable to create Filesystem, please see VMkernel log for more details: Failed to create VMFS on device naa.6589cfc000000f7c96869c6c450b7a8f:1

    設定項目 設定値
    Extent name extent-01
    Extent type File
    Path to the extent /mnt/pool-01/extent-01
    Extent size 10 GiB
    Disable Physical Block Size Reporting チェック

    5. ターゲットとエクステントの紐づけを作成

    「Sharingi / SCSI / Associated Targets」にてターゲットとエクステントの紐づけを作成する。

    設定項目 設定値
    Target target-01
    LUN ID 1
    Extent extent-01

    6. iSCSIサービスの起動

    FreeNASはデフォルトではiSCSIのサービスが起動していないため、「Services」にて起動させる。再起動時にも自動でサービスが起動するよう、「Start Automatically」も有効にしておく。

    ESXiにてiSCSIターゲットに接続

    最後に動作確認として、ESXiにてiSCSIターゲットに接続し、LUNが問題なく認識するか確認してみよう。

    1. ESXiでソフトウェアiSCSIを設定

    ソフトウェアiSCSIの設定にて、以下を追加する。

    • 動的ターゲットの追加 : 192.168.11.14 (FreeNASのIPアドレス)

    2. FreeNASのLUN表示されることを確認

    ストレージデバイス一覧にて、FreeNASのLUNが表示されることを確認する。以下のように「FreeNAS iSCSI Disk」と表示されるLUNがあれば、問題なく認識されている。


    まとめ

    以上で、FreeNAS 11.3をiSCSIストレージとして構築することができた。メモリが4GBとなり推奨構成よりも少ない環境ではあるが、実際のメモリ使用率は2GB程度となっており、現時点では稼働に問題は発生していないので、検証環境のiSCSIストレージとしては十分に使えそうだ。

    2020年9月13日日曜日

    OVF Toolを使ってvCenter Serverを使わずに仮想マシンをクローンする

    先日OVF Toolを使ったOVFのエクスポート・インポート手順を紹介した。

    OVF Toolという名前なので、OVFのエクスポート・インポートしかできないように見えるが、実はESXiからESXiに直接コピーすることができる。つまり、仮想マシンをパワーオフ状態にするという制約はあるものの、vCenter ServerがなくてもESXi単体で仮想マシンのクローンを作ることができるということを意味する。

    以下、実施手順を記載する。

    ①別のESXiに直接コピー

    以下構文で実施する。

    .\ovftool --noImageFiles -ds=[コピー先データストア名] -dm=[ディスク形式 (thick,thin,eagerZeroedThick)] vi://[コピー元ESXiのユーザ名]:[コピー元ESXiのパスワード]@[コピー元ESXiのホスト名 or IPアドレス]/[仮想マシン名] vi://[コピー先ESXiのユーザ名]:[コピー先ESXiのパスワード]@[コピー先ESXiのホスト名 or IPアドレス]/
    
    • 仮想マシン名 : testvm
    • コピー元ESXiのユーザ名 : root
    • コピー元ESXiのIPアドレス : 192.168.33.10
    • コピー先ESXiのユーザ名 : root
    • コピー先ESXiのIPアドレス : 192.168.33.12
    • コピー先データストア名 : ssd_local_02
    • ディスク形式 : シンプロビジョニング

    実行結果は以下の通り。

    > cd 'C:\Program Files\VMware\VMware OVF Tool\'
    > .\ovftool --noImageFiles -ds=ssd_local_02 -dm=thin vi://root:PASSWORD@192.168.33.10/testvm vi://root:PASSWORD@192.168.33.12/
    Opening VI source: vi://root@192.168.33.10:443/testvm
    Opening VI target: vi://root@192.168.33.12:443/
    Deploying to VI: vi://root@192.168.33.12:443/
    Transfer Completed
    Completed successfully
    

    ②別のデータストアに直接コピー

    以下構文で実施する。データストアを変更するだけなので、コピー元とコピー先は同じESXiを指定する。なお、コピー元とコピー先データストアを同一にすることで、単純な仮想マシンのクローンも実行できる。

    .\ovftool --noImageFiles -ds=[コピー先データストア名] -dm=[ディスク形式 (thick,thin,eagerZeroedThick)] -n=[コピー後の仮想マシン名] vi://[ESXiのユーザ名]:[ESXiのパスワード]@[ESXiのホスト名 or IPアドレス]/[仮想マシン名] vi://[ESXiのユーザ名]:[ESXiのパスワード]@[ESXiのホスト名 or IPアドレス]/
    
    • 仮想マシン名 : testvm
    • コピー後の仮想マシン名 : testvm2
    • ESXiのユーザ名 : root
    • ESXiのIPアドレス : 192.168.33.10
    • コピー先データストア名 : nvme_t3010esxi_01
    • ディスク形式 : シンプロビジョニング

    実行結果は以下の通り。

    > cd 'C:\Program Files\VMware\VMware OVF Tool\'
    > .\ovftool --noImageFiles -ds=nvme_t3010esxi_01 -dm=thin -n=testvm2 vi://root:PASSWORD@192.168.33.10/testvm vi://root:PASSWORD@192.168.33.10/
    Opening VI source: vi://root@192.168.33.10:443/testvm
    Opening VI target: vi://root@192.168.33.10:443/
    Deploying to VI: vi://root@192.168.33.10:443/
    Transfer Completed
    Completed successfully
    
    2020年9月12日土曜日

    OVF Toolを使って仮想マシンをエクスポート・インポートする

    OVF (Open Virtualization Format) と呼ばれる仮想マシンをファイルとして記述する標準フォーマットが制定されている。VMwareのESXiでは、過去のバージョンからOVFのエクスポート・インポートに対応しており、仮想マシンを別のvSphere環境に移行する時やバックアップ目的で、エクスポート・インポートを実施することができる。

    OVFのエクスポート・インポート作業はESXiであればVMware Host Client、vCenter ServerであればvSphere Client (あるいは、まもなくサポート終了となるvSphere Web Client) で実施することができるが、Web管理画面での作業はブラウザの相性などでダウンロードが途中で止まってしまったり、予期せぬタイムアウトで中断してしまうことがよくある。

    そこで、VMwareからはコマンドラインで実施できるOVFのエクスポート・インポートツールが用意されており、その名もずばり「OVF Tool」である。今回、OVF Toolの使い方を調べて実際に使ってみた。

    ※本記事の使用方法の他にも、OVF Toolを使って仮想マシンのクローンを作ることもできる。その方法は以下記事を参照いただきたい。

    OVF Toolのインストール

    2020年8月現在のOVF Toolの最新版は4.4.0となる。WIndows版、Linux版、Mac OS版と複数のプラットフォームに対応している。今回はWindows 64bit版をダウンロードして使うことにする。

    Windows版はmsi形式のインストーラになっているので、実行してインストールすればよい。仮想マシンでインストールする場合、「Some files that need to be updated are currently in use.」といったVMware Tools関連のファイルに一部更新が発生する旨の警告メッセージが表示されるが、私の環境ではそのまま進めてもVMware Toolsの停止は発生せず、OS再起動も不要で問題なくOVF Toolは動作した。

    インストール後、PowerShell (あるいはコマンドプロンプト) を開き、以下「C:\Program Files\VMware\VMware OVF Tool\」に移動する。以降は、ここをカレントディレクトリとして作業を実施する。

    > cd 'C:\Program Files\VMware\VMware OVF Tool\'
    

    OVF Toolの基本的な使い方は、以下構文に集約されている。オプションが多数用意されているものの、本当に必要なオプションは多くない。必要に応じて、.\ovftool -hでヘルプを参照すればよいだろう。

    .\ovftool [options] <source> [<target>]
    

    注意事項

    ESXiの環境で作成した仮想マシンをOVFとしてエクスポートする。エクスポートの前提として、エクスポート対象の仮想マシンをパワーオフしておく必要があるので注意。パワーオン状態の場合、以下のように「Error: Fault cause: vim.fault.InvalidState」というエラーで失敗する。

    > .\ovftool.exe --noImageFiles vi://root:PASSWORD@192.168.33.10/testvm C:\work\vm
    Opening VI source: vi://root@192.168.33.10:443/testvm
    Error: Fault cause: vim.fault.InvalidState
    
    Completed with errors
    

    なお、仮想マシンのスナップショットが取得されていたとしても、最新の仮想マシンの状態がOVFとしてエクスポートされることは確認済みとなる。

    エクスポート

    ESXi上の仮想マシンをエクスポートするには、以下の構文で実施する。仮想マシンのCD/DVDドライブにISOがマウントされていると、そのISOファイルも一緒にエクスポートされてしまうので、ISOファイルのエクスポートを抑止するため--noImageFilesオプションを付与する。

    .\ovftool --noImageFiles vi://[ESXiのユーザ名]:[ESXiのパスワード]@[ESXiのホスト名 or IPアドレス]/[仮想マシン名] [OVF保存先のフルパス]
    

    例として、以下の仮想マシンをエクスポートしてみる。

    • 仮想マシン名 : testvm
    • コピー元ESXiのユーザ名 : root
    • コピー元ESXiのIPアドレス : 192.168.33.10
    • OVF保存先のフルパス : C:\work\vm

    実行結果は以下の通り。「Completed successfully」が表示されれば問題なく完了となる。

    > .\ovftool.exe --noImageFiles vi://root:PASSWORD@192.168.33.10/testvm C:\work\vm
    Accept SSL fingerprint (0D:E0:66:54:EE:34:EE:B7:88:1E:EC:32:C4:D5:9F:01:39:D4:E5:D7) for host 192.168.33.10 as source type.
    Fingerprint will be added to the known host file
    Write 'yes' or 'no'
    yes   ←★初回のみ確認があるため「yes」を入力
    Opening VI source: vi://root@192.168.33.10:443/testvm
    Opening OVF target: C:\work\vm
    Writing OVF package: C:\work\vm\testvm\testvm.ovf
    Disk progress: 1%   ←★進捗が表示されるものの突然終わったりするため役に立たない
    Transfer Completed
    Completed successfully
    

    実際に出力されたOVFを確認してみよう。それぞれのファイルは以下の意味を持つ。

    • .vmdk : 仮想マシンのディスクイメージ本体
    • .nvram : 仮想マシンのBIOS/UEFIの本体
    • .mf : マニフェストファイル。各ファイルのSHA256のハッシュ値が格納されている。OVFインポート時に各ファイルのハッシュ値を計算し、本ファイルに記載されている値と一致することで、ファイルの正当性を確認する
    • .ovf : 仮想マシンの構成情報が記載されたXMLファイル
    > dir C:\work\vm\testvm
    
        ディレクトリ: C:\work\vm\testvm
    
    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a----       2020/08/16     16:25      241957376 testvm-disk1.vmdk
    -a----       2020/08/16     16:25           8684 testvm-file2.nvram
    -a----       2020/08/16     16:25            361 testvm.mf
    -a----       2020/08/16     16:25           9718 testvm.ovf
    

    インポート

    ESXi上の仮想マシンをインポートするには、以下の構文で実施する。インポート時は保存先のデータストアの指定が必要となるので-dsオプションを付与する。また、ディスクの形式はデフォルトではシックプロビジョニングとなってしまうので、シックプロビジョニングに変更が必要な場合は-dm=thinを付与する。

    .\ovftool -ds=[コピー先データストア名] -dm=[ディスク形式 (thick,thin,eagerZeroedThick)] [OVFファイルのフルパス] vi://[ESXiのユーザ名]:[ESXiのパスワード]@[ESXiのホスト名 or IPアドレス]/
    

    例として、以下の仮想マシンをインポートしてみる。

    • 仮想マシン名 : testvm
    • OVFファイルのフルパス : C:\work\vm\testvm\testvm.ovf
    • コピー先ESXiのユーザ名 : root
    • コピー先ESXiのIPアドレス : 192.168.33.12
    • コピー先データストア名 : ssd_local_02
    • ディスク形式 : シンプロビジョニング

    実行結果は以下の通り。「Completed successfully」が表示されれば問題なく完了となる。

    > .\ovftool -ds=ssd_local_02 -dm=thin C:\work\vm\testvm\testvm.ovf vi://root:PASSWORD@192.168.33.12/
    Opening OVF source: C:\work\vm\testvm\testvm.ovf
    The manifest validates
    Accept SSL fingerprint (4B:D1:B2:D7:12:C0:BA:C5:62:07:9F:6A:87:79:2A:F8:EC:A7:67:82) for host 192.168.33.12 as target type.
    Fingerprint will be added to the known host file
    Write 'yes' or 'no'
    yes   ←★初回のみ確認があるため「yes」を入力
    Opening VI target: vi://root@192.168.33.12:443/
    Deploying to VI: vi://root@192.168.33.12:443/
    Disk progress: 9%   ←★これは0から100%まできっちり進捗する
    Transfer Completed
    Completed successfully
    
    2020年9月9日水曜日

    PowerCLIでSRMのリカバリプランを実行する

    vSphere環境の仮想マシンの操作をPowerShellベースのコマンドで操作することができる「PowerCLI」は広く使われているツールであるが、実はPowerCLIは、vRealize Operations Manager (vROps) やVMware Site Recovery Manager (以下SRM) といった他のVMware製品群の操作をすることができる

    今回、実際にSRMに対してPowerCLIを使って操作をしてみたのだが、当初はGet-XXXとかStart-XXXといったPowerShellの構文によるコマンド実行ができると予想していた。しかし、SRMの操作コマンドは通常のPowerCLIのコマンド体系と大きく異なっており、SRMのリカバリプラン実行にたどり着くまでかなりの苦労を要した

    今回は、その苦労の備忘を兼ねて、PowerCLIでSRMのリカバリプランを実行する手順を記載することにする。

    環境

    環境としては以下の通り。SRMはアプライアンス版を使用して確認を行った。

    • vCSA 6.7 Update 3
    • SRM 8.2.0、ビルド 14761908
    • VMware PowerCLI 12.0.0 build 15947286

    PowerCLIにSRMを操作するためのモジュールは含まれているので、個別にインストール等の作業は不要となる。PowerCLIのインストール手順は、以前記事にしているので参照いただきたい。

    PowerCLIでSRMに接続

    まずは、リカバリサイト側に配置されるvCenter ServerにPowerCLIで接続する。これはいつも通り、Connect-VIServerのコマンドレットを使えばよい。

    PS C:\> Connect-VIServer 192.168.11.170 -User administrator@vsphere.local -Password XXXXXXXX -Force
    

    繰り返しになるが、必ずリカバリサイト側のvCenter Serverに接続すること。保護サイト側に接続してSRMを操作しようとしても、以下メッセージが表示されてリカバリの実行で失敗するので注意。

    PS C:\> $rp.start($RPmode)
    "1" 個の引数を指定して "Start" を呼び出し中に例外が発生しました: "This operation is not allowed in the current state."
    発生場所 行:1 文字:1
    + $rp.start($RPmode)
    + ~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
        + FullyQualifiedErrorId : VimException
    

    次にSRMに接続する。SRMにはConnect-SrmServerコマンドレットを使う。ここで注意事項として、アプライアンス版のSRMの仮想マシンを使う場合は-Port 443オプションを付ける必要がある。これがわからずに、いつまでも接続ができず非常に時間を要した。

    PS C:\> Connect-SrmServer -Port 443
    ServiceUri    : https://t1174vsrm.intrat.local/vcdr/extapi/sdk
    SessionSecret : "b1063f9def0c841c25c2e74e5f9e68ffd68f14c9"
    User          : VSPHERE.LOCAL\Administrator
    IsConnected   : True
    Port          : 443
    Version       : 8.2.0
    Build         : 14761908
    ProductLine   : srm
    InstanceUuid  : a5bec4a1-3959-4324-9b82-f3317d24b262
    RefCount      : 1
    ExtensionData : VMware.VimAutomation.Srm.Views.SrmServiceInstance
    Uid           : /SrmServer=vsphere.local\administrator@t1174vsrm.intrat.local:443/
    Id            : /SrmServer=vsphere.local\administrator@t1174vsrm.intrat.local:443/
    Name          : t1174vsrm.intrat.local
    IsInUse       : True
    

    SRMの接続時のパラメータは$global:DefaultSrmServersという変数に代入される。長いので、短い変数に代入しておこう。

    PS C:\> $srm = $global:DefaultSrmServers
    

    なお、以下のように記述することで、接続と変数代入は同時に実施することもできる。

    PS C:\> $srm = Connect-SrmServer -Port 443
    

    リカバリプランの選択

    リカバリを実行する前に、実行対象とするリカバリプランを確認する。

    PS C:\> $srm.extensiondata.Recovery.ListPlans().GetInfo()
    
    Name  Description State ProtectionGroups
    ----  ----------- ----- ----------------
    RP-01             Ready {VMware.VimAutomation.Srm.Views.SrmProtectionGroup}
    

    今回のテスト環境では「RP-01」というリカバリプランのリカバリを実行する。コマンドが長いので、以下のように変数に代入しておこう。

    PS C:\> $rp = $srm.extensiondata.Recovery.ListPlans() | where { $_.getinfo().Name -eq "RP-01" }
    

    テストリカバリの実行

    それではテストリカバリを実行してみよう。テストリカバリの実行とテスト後の戻し (クリーンアップ) の2つの作業をPowerCLIを使って実行してみる。

    ①テストリカバリ

    先ほど変数に入れたリカバリプランのStartメソッドを使うことで実行できるのだが、メソッドの引数に実行するモードを指定する必要がある。引数は以下のオブジェクトを指定する必要があるので、Net-Objectで変数としてオブジェクトの作成を行っておく。

    PS C:\> $mode = New-Object VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode
    

    実行するモードは、先ほどのオブジェクトのValue__のプロパティの値に応じて以下の通り決定される。

    Value__の値 動作 説明
    0 Failover リカバリ (ディザスタリカバリ)
    1 Test テスト実行
    2 CleanupTest テスト実行のクリーンアップ
    3 Reprotect 再保護
    4 Revert
    5 Migrate リカバリ (計画移行)

    今回はテストリカバリの実行なので「1」を指定する。

    PS C:\> $mode.Value__ = 1 ; $mode
    Test
    

    それでは実行してみよう。Startメソッドは実行完了を待たずにプロンプトが返ってくるので、$rp.GetInfo().Stateにてリカバリプランのステータスを5秒おきに確認するようコマンドを作ってみた。

    PS C:\> $rp.Start($mode)
    PS C:\> do { sleep 5 ; echo $rp.GetInfo().State } while ($rp.GetInfo().State -eq "Running")
    Running
    Running
    Running
    ~(中略)~
    Running
    Running
    NeedsCleanup   ←★テスト完了のステータス
    

    ②クリーンアップ

    クリーンアップは「2」を指定する。

    PS C:\> $mode.Value__ = 2 ; $mode
    CleanupTest
    

    Startメソッドを実行すると、クリーンアップが実行された。

    PS C:\> $rp.Start($mode)
    PS C:\> do { sleep 5 ; echo $rp.GetInfo().State } while ($rp.GetInfo().State -eq "Running")
    Ready   ←★準備完了のステータス
    

    リカバリ (ディザスタリカバリ) の実行

    次にテストではないリカバリ (ディザスタリカバリ) を行う。リカバリの実行とリカバリ後の再保護の2つ作業をPowerCLIを使って実行してみる。

    ①リカバリ

    リカバリは「0」を指定する。

    PS C:\> $mode.Value__ = 0 ; $mode
    Failover
    PS C:\> $rp.Start($mode)
    PS C:\> do { sleep 5 ; echo $rp.GetInfo().State } while ($rp.GetInfo().State -eq "Running")
    Running
    Running
    Running
    ~(中略)~
    Running
    Running
    FailedOver   ←★リカバリ完了のステータス
    
    PS C:\> $mode.Value__ = 3 ; $mode
    Reprotect
    PS C:\> $rp.Start($mode)
    PS C:\> do { sleep 5 ; echo $rp.GetInfo().State } while ($rp.GetInfo().State -eq "Running")
    Protecting
    

    ②再保護

    リカバリ完了後の再保護は「3」を指定する。GUI上では「準備完了」のステータスだが、テストリカバリのクリーンアップ後とは異なり「Protecting」というステータスで表示される。

    PS C:\> $mode.Value__ = 3 ; $mode
    Reprotect
    PS C:\> $rp.Start($mode)
    PS C:\> do { sleep 5 ; echo $rp.GetInfo().State } while ($rp.GetInfo().State -eq "Running")
    Protecting   ←★再保護完了のステータス
    

    まとめ

    以上で、PowerCLIでSRMのリカバリプランを実行できることが確認できた。

    少しコマンドが分かりづらくなってしまったので、パラメータを変数にしたり必要コマンドを整理した。

    # 必要情報を変数に代入
    $vcip = "192.168.11.170"    # vCenter ServerのIPアドレスまたはホスト名
    $vcuser = "administrator@vsphere.local" # ログインユーザ
    $vcpass = "XXXXXXXX"        # ログインのパスワード
    $rpname = "RP-01"           # リカバリプラン名
    $rpmode = 1                 # リカバリモード (0:ディザスタリカバリ, 1:テストリカバリ, 2:クリーンアップ, 3:再保護, 5:計画移行)
    
    # vCenter Server及びSRMに接続
    Connect-VIServer $vcip -User $vcuser -Password $vcpass -Force
    $srm = Connect-SrmServer -Port 443
    
    # リカバリプランを選択
    $rp = $srm.extensiondata.Recovery.ListPlans() | where { $_.getinfo().Name -eq $rpname }
    
    # リカバリプランの実行モードを選択
    $mode = New-Object VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode
    $mode.Value__ = $rpmode ; $mode
    
    # リカバリを実行
    $rp.Start($mode)
    do { sleep 5 ; echo $rp.GetInfo().State } while ($rp.GetInfo().State -eq "Running")
    

    上記をスクリプト化などして使えば、SRMのGUIにログインせずともSRMのリカバリプランを実行することができる。

    参考

    人気の投稿