2021年10月30日土曜日

TrueNAS (FreeNAS) で定期的なスナップショット取得を行う

TrueNAS (旧FreeNAS) はスナップショットによるボリュームのバックアップ取得を取得する機能がある。前回、以下記事にて手動によるスナップショット取得手順を記載した。

今回は自動ではなく、TrueNAS (FreeNAS) の機能を使ってスナップショットを定期的に取得する方法を記載する。なお、手順はFreeNAS 11.3で確認をしたものとなるが、TrueNASでも同一手順にて設定できることを確認している。

環境

FreeNAS 11.3-U4.1で確認したが、TrueNASでも同様に実施可能となる。

手順

1. 定期的なスナップショットタスクを作成

「Tasks / Periodic Snapshot Tasks」にて「ADD」を選択する。

すると、定期スナップショットの設定画面が表示されるので、以下を参考に設定する。

設定項目 設定例 説明
Dataset pool-01 スナップショット取得対象を指定する。
Recursive チェックを外す スナップショット取得対象配下のデータセットもスナップショット取得対象に含める場合はチェックする。
Snapshot Lifetime 3 Days スナップショット保持期間。
Schedule the Periodic Snapshot Task Custom (0 3 * * *) スナップショット取得スケジュール。設定値はcronの記載方式で表示されるが、GUIにてcronの記述を意識することなくスケジュール設定ができる (設定手順は次手順にて説明)。
Begin 00:00:00 スナップショット取得が有効となる開始時間。デフォルトのままでOK。
End 23:59:00 スナップショット取得が有効となる終了時間。デフォルトのままでOK。
Allow Taking Empty Snapshots チェック データセット内にデータがない場合もスナップショット取得を行う場合はチェック。
Enabled チェック 本スケジュールタスクを有効にする場合はチェック。

2. スナップショットの取得スケジュールを設定

スナップショット取得のスケジュールは、デフォルトで以下が定義されている。

設定値 説明
Hourly 1時間毎 毎時0分取得
Daily 1日毎 12:00AM取得
Weekly 1週間毎 12:00AM取得
Monthly 1か月毎 12:00AM取得
Custom 上記以外のタイミングで取得

「Custom」を選んだ場合はスケジュール設定画面が表示されるので、取得時間や頻度を選択する。取得間隔として、分、時間、日、月、曜日などを指定し選ぶことができる。今回は、毎日の3:00AM取得にて取得する設定を行った。

3. スナップショット取得結果確認

実際に、スナップショットが取得された結果は「Storage / Snapshots」から確認できる。スナップショットは毎日3:00に取得されており、3日間保持されていることがわかる。

まとめ

以上でTrueNAS (FreeNAS) で定期的なスナップショットを取得する手順は完了となる。FreeNASのGUIはシンプルかつ綺麗に作られており、初見であっても非常に簡単に設定できた。

2021年10月23日土曜日

WSFCでSQL Serverをクラスター化する手順

Windowsで標準で利用可能なWSFC (Windows Server Failover Clustering) では、SQL Serverもクラスター化することができる。SQL ServerをWSFCに組み込みは、SQL Serverのインストールウィザードにて実施できる。

今回は、SQL ServerをWSFCのクラスターに組み込み冗長化する手順を記載する。

環境

今回は以下の環境にてWSFCを構築し、SQL Serverの導入を行う。なお、WSFC構築のために別途Active Directoryが必要となるので、構築しておくことが前提となる。

  • OS : Windows Server 2019
  • SQL Server : SQL Server 2019

WSFC構成

WSFCのクラスターは構成済みであることを前提とする。クラスター化手順については、以下別記事に記載しているため、参照し対応すること。

1号機へSQL Serverインストール

1. SQL ServerのISOイメージ内のインストーラを起動

WSFCを構成する1号機のサーバにログインして作業を行う。

SQL ServerのISOイメージをマウントすると、直下に「setup.exe」があるため、こちらをダブルクリックして起動する。

2. 「SQL Serverフェイルオーバークラスターの新規インストール」を選択

SQL Serverのインストーラが起動するため、左メニュー→「インストール」→「SQL Serverフェイルオーバークラスターの新規インストール」を選択する。

3. インストールウィザードに従い設定①

ここからはインストールウィザードに従い設定する。今回は評価版としてインストールするため、以下の通り設定した。

設定 設定内容
プロダクトキー 「無償のエディションを指定する」を選択。
ライセンス条項 「同意します」にチェック。
Microsoft Update 「更新プログラムを確認する」のチェックを外す。
製品の更新プログラム 「SQL Server製品の更新プログラムを含める」のチェックを外す。

4. セットアップファイルのインストール

インストールウィザードの設定が完了すると、サーバ上にセットアップファイルがインストールされる。

5. インストールウィザードに従い設定②

再びインストールウィザードに戻るため、以下の通り設定する。

設定 設定内容
機能の選択 「データベースエンジンサービス」と「クライアントツール接続」をインストール。
インスタンスの構成 SQL Serverの仮想IPアドレスと紐づけられるネットワーク名 (ホスト名) やインスタンス名を設定する。デフォルトでは「既定のインスタンス」という設定となっているが、今回はあえて「名前付きインスタンス」とし「TEST」という名前とした。
クラスターリソースグループ そのまま「次へ」を選択する。
クラスターディスクの選択 SQL Serverのデータ領域とする共有ディスクを指定する。適切なディスクを選択して「次へ」を選択する。
クラスターネットワークの構成 仮想IPアドレスを設定する。
サーバーの構成 SQL Serverを起動させるサービスアカウントとパスワードを設定する。クラスターを構成したサーバ全台で同一アカウントとする必要があることから、ドメインユーザを指定したほうがよいだろう。
データベースエンジンの構成 認証モードやSQL Serverのデータディレクトリの指定ができる。認証モードに関しては「Windows認証モード」または「混合モード」が選択できる。混合モードの場合はSQL Server独自認証が利用できる。
インストールの準備完了 最後にインストール内容の確認画面が表示されるため、問題ないことを確認し「次へ」を選択する。

インストールは5分程度で完了する。

6. インストール後の確認

インストール完了後、「フェイルオーバークラスターマネージャー」を開き「役割」確認すると、SQL Serverの役割が追加できていることが確認できる。

ただし、現時点では1号機のみSQL Serverがインストールされた状態であるため、フェイルオーバーをさせることができない。そのため、引き続き2号機に対してSQL Serverのインストールを行う。

2号機へSQL Serverインストール

1. SQL ServerのISOイメージ内のインストーラを起動

WSFCを構成する2号機のサーバにログインして作業を行う。

SQL ServerのISOイメージをマウントすると、直下に「setup.exe」があるため、こちらをダブルクリックして起動する。

2. 「SQL Serverフェイルオーバークラスターにノードを追加」を選択

SQL Serverのインストーラが起動するため、左メニュー→「インストール」→「SQL Serverフェイルオーバークラスターにノードを追加」を選択する。

3. インストールウィザードに従い設定①

ここからはインストールウィザードに従い設定する。今回は評価版としてインストールするため、以下の通り設定した。

設定 設定内容
プロダクトキー 「無償のエディションを指定する」を選択。
ライセンス条項 「同意します」にチェック。
Microsoft Update 「更新プログラムを確認する」のチェックを外す。
製品の更新プログラム 「SQL Server製品の更新プログラムを含める」のチェックを外す。

4. セットアップファイルのインストール

インストールウィザードの設定が完了すると、サーバ上にセットアップファイルがインストールされる。

5. インストールウィザードに従い設定②

再びインストールウィザードに戻るため、以下の通り設定する。

設定 設定内容
クラスターノードの構成 1号機で設定したインスタンス名などが表示される。問題なければ、そのまま「次へ」を選択する。
クラスターネットワークの構成 1号機で設定した仮想IPアドレスなどが表示される。問題なければ、そのまま「次へ」を選択する。
サービスアカウント 1号機で設定したサービスアカウントなどが表示される。サービスアカウントのパスワードを入力し、「次へ」を選択する。
インストールの準備完了 最後にインストール内容の確認画面が表示されるため、問題ないことを確認し「次へ」を選択する。

インストールは5分程度で完了する。

6. インストール後の確認

インストール完了後、「フェイルオーバークラスターマネージャー」を開きSQL Serverの役割を右クリックし、「移動」→「ノードの選択」を選択する。

フェイルオーバーが開始される。

問題なく2号機にフェイルオーバーすることを確認する。

以上でWSFCでSQL Serverをクラスター化する作業は完了となる。

2021年10月16日土曜日

BINDを使ってDNS権威サーバを構築する

LinuxでDNSサーバとしてデファクトスタンダードとなっている「BIND」は、キャッシュサーバと権威サーバの両方の機能を持つ。多機能であるがゆえ、脆弱性も多く見つかることから、本番環境で利用する際にはかなり気を使って構築する必要がある。

とはいえ、テスト用途として内部でDNSサーバが欲しい場合には、簡単にレコード設定ができるため重宝する。

今回は、BINDに対して必要最低限の設定を行い、DNS権威サーバとして動作させるまでの設定手順を記載する。

環境

以下の環境にてBINDを構築する。

  • OS : RHEL 7.6
  • Bind : BIND 9.9.4-RedHat-9.9.4-72.el7
  • DNSサーバのIPアドレス : 192.168.11.191
  • ドメイン : example.comexample2.com

BINDインストール手順

1. yumを使ってインストール

まずはyumを使ってBINDをインストールする。

# yum install bind bind-utils -y
読み込んだプラグイン:product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
リポジトリー 'dvd' は構成中に名前がありませんので ID を使います
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ bind.x86_64 32:9.9.4-72.el7 を インストール

~(中略)~

インストール:
  bind.x86_64 32:9.9.4-72.el7         bind-utils.x86_64 32:9.9.4-72.el7

依存性関連をインストールしました:
  audit-libs-python.x86_64 0:2.8.4-4.el7
  bind-libs.x86_64 32:9.9.4-72.el7
  checkpolicy.x86_64 0:2.5-8.el7
  libcgroup.x86_64 0:0.41-20.el7
  libsemanage-python.x86_64 0:2.5-14.el7
  policycoreutils-python.x86_64 0:2.5-29.el7
  python-IPy.noarch 0:0.75-6.el7
  python-ply.noarch 0:3.4-11.el7
  setools-libs.x86_64 0:3.3.8-4.el7

完了しました!

2. 初期設定

BINDの設定ファイルは/etc/named.confとなる。最低限動作させるために以下設定を行う。

設定値 説明
listen-on port 53 { any; }; デフォルトでは127.0.0.1のみ許可されており、外部からの名前解決を受付できないようになっているため、anyに変更する。
allow-query { any; }; フォルトではlocalhostのみ許可されており、外部からの名前解決を受付できないようになっているため、anyに変更する。
recursion no; 再帰的問い合わせは不要となるため、noとする。
zone "[ドメイン名]." IN { ~(省略)~ }; ゾーンの設定を記載する。fileにはゾーン情報を記載したゾーンファイルのファイル名を記載し、それ以外は定型文として後述する設定例のように記載すればよい。

以下が実際に設定した/etc/named.confの記載例となる。

options {
        listen-on port 53 { any; };
        ~(中略)~
        allow-query     { any; };
        ~(中略)~
        recursion no;
        ~(中略)~
};

~(中略)~

zone "example.com." IN {
        type master;
        file "example.com.zone";
        allow-update { none; };
};

zone "example2.com." IN {
        type master;
        file "example2.com.zone";
        allow-update { none; };
};

3. DNSゾーンファイルを作成

/var/named/配下にDNSレコードを記載したゾーンファイルを配置する。ファイル名はnamed.confにてfileにて記載したファイル名で配置する。たとえば、example2.comのドメインであれば、/var/named/example2.com.zoneにゾーンファイルを作成すればよい。

以下、ゾーンファイルexample2.com.zoneの記載例となる。NSレコード、MXレコード、SPFレコード (TXTレコード) 、Aレコードを一通り設定している。

# cat /var/named/example2.com.zone
$TTL	3600
@		IN	SOA	ns.example2.com.	root.example2.com.(
		2020082801	; Serial
		10800		; Refresh
		3600		; Retry
		604800		; Expire
		10800 )		; Minimum
;
		IN	NS		ns.example2.com.
		IN	MX	10	mail.example2.com.
		IN	TXT		"v=spf1 +ip4:192.168.11.191 +ip4:192.168.11.192 -all"
;
ns		IN	A		192.168.11.191
mail	IN	A		192.168.11.192

4. configチェックとBIND起動

BINDのconfigチェック用にnamed-checkconfというコマンドが用意されているので、実行しておこう。特にメッセージが表示されなければOKとなる。

# named-checkconf
# echo $?
0

configに問題がなければ、BINDを起動させる。

# systemctl start named
# systemctl enable named
# systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
   Active: active (running) since 土 2021-08-28 11:27:30 JST; 10s ago
 Main PID: 12922 (named)
   CGroup: /system.slice/named.service
           mq12922 /usr/sbin/named -u named -c /etc/named.conf

 8月 28 11:27:37 RHEL7 named[12922]: network unreachable resolving './DNSK...53
 8月 28 11:27:37 RHEL7 named[12922]: network unreachable resolving './DNSK...53
 8月 28 11:27:37 RHEL7 named[12922]: network unreachable resolving './NS/I...53
 8月 28 11:27:37 RHEL7 named[12922]: network unreachable resolving './NS/I...53
 8月 28 11:27:37 RHEL7 named[12922]: network unreachable resolving './NS/I...53
 8月 28 11:27:38 RHEL7 named[12922]: network unreachable resolving './DNSK...53
 8月 28 11:27:38 RHEL7 named[12922]: network unreachable resolving './NS/I...53
 8月 28 11:27:39 RHEL7 named[12922]: network unreachable resolving './DNSK...53
 8月 28 11:27:39 RHEL7 named[12922]: network unreachable resolving './NS/I...53
 8月 28 11:27:40 RHEL7 named[12922]: managed-keys-zone: Unable to fetch DN...ut
Hint: Some lines were ellipsized, use -l to show in full.

5. 動作確認

実際にBINDに対して名前解決ができることを確認しておこう。他サーバからdigコマンドを使ってレコードの確認を行うと、以下の通りゾーンファイルで設定したレコード情報を取得することができた。

# dig @192.168.11.191 -t any example2.com

; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> @192.168.11.191 -t any example2.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29678
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example2.com.                  IN      ANY

;; ANSWER SECTION:
example2.com.           3600    IN      SOA     ns.example2.com. root.example2.com. 2020082801 10800 3600 604800 10800
example2.com.           3600    IN      NS      ns.example2.com.
example2.com.           3600    IN      MX      10 mail.example2.com.
example2.com.           3600    IN      TXT     "v=spf1 +ip4:192.168.11.191 +ip4:192.168.11.192 -all"

;; ADDITIONAL SECTION:
ns.example2.com.        3600    IN      A       192.168.11.191
mail.example2.com.      3600    IN      A       192.168.11.192

;; Query time: 2 msec
;; SERVER: 192.168.11.191#53(192.168.11.191)
;; WHEN: 日  9月 19 15:27:56 JST 2021
;; MSG SIZE  rcvd: 216

以上でBINDの設定は完了となる。

2021年10月9日土曜日

Splunkのライセンスを評価版からFreeライセンスに変更する手順

Splunkはインストール後60日間は、Splunk Enterpriseの評価版として動作し、すべての機能を制限なく使用することができる。60日経過するとEnterpriseトライアルライセンスの期限切れにより、ログのサーチを含むすべての操作ができなくなるが、Freeライセンスに変更することで、機能制限が加わるもののログのサーチ等の基本的な機能は継続して使用することができる。

EnterpriseライセンスとFreeライセンスの機能差異は、以下URLにて確認いただきたい。

本記事では、インストール後60日が経過したSplunkに対して、Freeライセンスへ変更する手順を記載する。

環境

  • OS : CentOS 7
  • Splunk : 8.1.2

手順

1. 管理Web画面にログイン

評価版のライセンスの期限が切れると、ログイン画面に以下のように「ライセンスが失効しています。管理者としてログインし、ライセンスを更新してください。」のメッセージが表示される。

ログイン自体はできるので、管理者アカウントであるadminユーザでログインを行う。

2. ライセンス画面を表示

管理Web画面上部の[設定]→[ライセンス]を選択し、ライセンス画面を表示させる。

「Trialライセンスグループ」となっていることを確認する。

3. ライセンスグループの変更画面を表示

[ライセンスグループの変更]ボタンを選択する。

4. ライセンスグループを変更

ライセンスグループを「Enterpriseトライアルライセンス」から「フリーライセンス」に変更し、[保存]ボタンを選択する。

5. Splunk再起動

ライセンスグループの変更を有効にする場合は、Splunkの再起動が必要な旨表示されるので、[今すぐ再起動]ボタンを選択する。

6. ライセンスの変更を確認

ログイン画面に戻るので、再度adminユーザにてログインする。

管理Web画面上部の[設定]→[ライセンス]を選択し、ライセンス画面を表示させ、「Freeライセンスグループ」に変更されていることを確認する。

以上で、SplunkのFreeライセンスへの変更作業は完了となる。

2021年10月2日土曜日

vCenter ServerのSTS証明書を更新する

vCenter ServerにはSecurity Token Service (STS)と呼ばれる、vCenter Single Sign-Onによる認証を行う際に、セキュリティ トークンの発行、検証、更新を行う サービスとなる。

このサービスは「STS証明書」と呼ばれる証明書を持っているが、vSphere 7.0以降では有効期限が2年間と短くなっている (以前のバージョンのSTS証明書の有効期限は10年)。これはセキュリティの観点から意図的に短くされており、有効期限切れの前に、手動による更新作業が必要となる。なお、更新した場合のSTS証明書の有効期限は同じく2年となる。

本記事では、vCenter ServerのSTS証明書を手動で更新する手順を記載する。

環境

今回はvSphere 7.0 Update 1の環境で確認を行った。vSphere 7.0となるため、vCenter Server Applianceに関する手順となる。もし、vSphere 6.7以前のWindows版のvCenter Serverの場合は本記事の手順では対応できないため注意すること。

  • vCenter Server 7.0 Update 1d
  • ESXi 7.0 Update 1

STS証明書更新手順

1. STS証明書の確認・更新用スクリプトの入手

STS証明書の更新はvCenter ServerにSSHでログインし、CLIによる更新作業を行う。

ある程度簡略化できるよう、証明書の更新期限の確認と更新をするためのスクリプトがVMwareから入手できるため、それを利用する。

checksts.py

証明書の確認用スクリプトであるchecksts.pyは、以下KBの「Attachments」から入手する。

fixsts.sh

証明書の更新用スクリプトであるfixsts.shは、以下KBの「Attachments」から入手する。

2. 入手したスクリプトをvCenter Serverに配置

入手したスクリプトをvCSAに対して配置する。

vCenter ServerにSSHログインすると、以下のようなプロンプトが表示される。通常のLinuxと同様のコマンド実行が必要となるため、shellを実行する。

Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Launch BASH: "shell"

Command> shell
Shell access is granted to root
root@vcsa [ ~ ]#

vCenter ServerはSSHによる接続はできるものの、scpsftpによる接続が簡単にはできないようなので、viを開きターミナルソフトから、スクリプトのテキストをすべてコピー&ペーストしてしまう方法が手っ取り早い。

今回は/tmpにスクリプトを配置する。

3. STS証明書の期限を確認

checksts.pyを実行し、証明書の期限を確認する。構築後1週間ほど経過しているため、722 days (2 years)と、2年 (730日) より少し少なくなっている。

# cd /tmp/
# ./checksts.py

2 VALID CERTS
================

        LEAF CERTS:

        [] Certificate AD:5B:3A:72:4A:AB:75:E5:57:64:47:04:A2:FC:91:5D:E5:D9:76:44 will expire in 722 days (2 years).

        ROOT CERTS:

        [] Certificate B3:07:5B:30:81:0A:C1:85:AD:1B:E9:F1:88:8D:34:3C:00:B1:C0:C7 will expire in 3638 days (10 years).

0 EXPIRED CERTS
================

        LEAF CERTS:

        None

        ROOT CERTS:

        None

4. STS証明書を更新

./fixsts.shを実行し、STS証明書を更新する。途中、administrator@vsphere.localのパスワードが求められるが、処理自体はすぐに完了する。

# cd /tmp/
# ./fixsts.sh
NOTE: This works on external and embedded PSCs
This script will do the following
1: Regenerate STS certificate
What is needed?
1: Offline snapshots of VCs/PSCs
2: SSO Admin Password
IMPORTANT: This script should only be run on a single PSC per SSO domain
==================================
Resetting STS certificate for vcsa.intrat.local started on Fri Aug  6 22:29:13 UTC 2021


Detected DN: cn=vcsa.intrat.local,ou=Domain Controllers,dc=vsphere,dc=local
Detected PNID: vcsa.intrat.local
Detected PSC: vcsa.intrat.local
Detected SSO domain name: vsphere.local
Detected Machine ID: a5fa8cc6-bbe5-4a00-8ac2-71a4c56097d8
Detected IP Address: 192.168.11.160
Domain CN: dc=vsphere,dc=local
==================================
==================================

Detected Root's certificate expiration date: 2031 Jul 23
Detected today's date: 2021 Aug 6
==================================

Exporting and generating STS certificate

Status : Success
Using config file : /tmp/vmware-fixsts/certool.cfg
Status : Success


Enter password for administrator@vsphere.local: ←★パスワードを入力
Amount of tenant credentials: 1
Exporting tenant 1 to /tmp/vmware-fixsts

Deleting tenant 1

Amount of trustedcertchains: 1
Exporting trustedcertchain 1 to /tmp/vmware-fixsts

Deleting trustedcertchain 1


Applying newly generated STS certificate to SSO domain
adding new entry "cn=TenantCredential-1,cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local"

adding new entry "cn=TrustedCertChain-1,cn=TrustedCertificateChains,cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local"


Replacement finished - Please restart services on all vCenters and PSCs in your SSO domain
==================================
IMPORTANT: In case you're using HLM (Hybrid Linked Mode) without a gateway, you would need to re-sync the certs from Cloud to On-Prem after following this procedure
==================================
==================================

5. STS証明書の期限が更新されていることを確認

再度、checksts.pyを使って証明書の期限を確認する。730 days (2 years)となっており期限が更新されていることがわかる。

# cd /tmp/
# ./checksts.py

2 VALID CERTS
================

        LEAF CERTS:

        [] Certificate 4C:CE:BF:F2:CC:17:2E:71:5B:0C:74:E1:AB:88:EC:88:11:66:9C:79 will expire in 730 days (2 years).

        ROOT CERTS:

        [] Certificate B3:07:5B:30:81:0A:C1:85:AD:1B:E9:F1:88:8D:34:3C:00:B1:C0:C7 will expire in 3638 days (10 years).

0 EXPIRED CERTS
================

        LEAF CERTS:

        None

        ROOT CERTS:

        None

6. vCenter Serverのサービスを再起動

証明書反映のため、vCenter Serverのサービス再起動を行う。再起動はservice-controlコマンドを利用する。環境にもよるが、10~15分程要するので気長に待とう。

# service-control --stop --all && service-control --start --all
Operation not cancellable. Please wait for it to finish...
Performing stop operation on service observability...
Successfully stopped service observability
Performing stop operation on service vmware-pod...
Successfully stopped service vmware-pod

~(中略)~

Performing start operation on service vmware-pod...
Successfully started service vmware-pod

vCenter Server連携製品との再連携の実施

証明書が更新されたことにより、vCenter Server連携製品に対して、登録情報を更新及び再登録が必要となる。

vCenter Server連携製品とは、例えばVASAを利用するストレージ製品や、vROpsやSRMなどのVMware関連製品となる。今回はSRMを例に更新手順を記載する。

1. SRMのアプライアンス管理画面にログイン

vSphere Clientにログインし、SRMの接続状況を確認すると以下のように「Site Recovery Manager - ユーザー インターフェイス エラー: PSC サービスに接続できません」のエラーとなっている。

同じ画面の「構成」を選択し、SRMアプライアンスの管理画面にadminユーザでログインする。通常、SRMは保護サイトとリカバリサイトで2つ存在するので、移行は両方に対して処理が必要となる。

2. vCenter Serverの登録情報を更新

「再構成」を選択すると、vCenter Serverの登録ウィザードが表示される。最初にadministrator@vsphere.localとパスワードを入力した後はひたすら「次へ」を選択するだけで、vCenter Serverの再登録が実行される。

再登録後、再度vCenter ServerにてSRMの接続状況を確認すると以下のようにエラーが解消されているはずだ。

以上で、vCenter ServerのSTS証明書の更新作業は完了となる。

人気の投稿