2018年11月25日日曜日

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する② (クラスター・リソース構成編)

前回はPacemakerとCorosyncを使用する準備まで実施したので、クラスターとしての設定を行っていく。


★前回の記事はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する① (準備・インストール編)
https://tech-mmmm.blogspot.com/2018/11/centos-7-pacemaker-corosyncmariadb.html

Pacemaker・Corosyncのクラスターを作成

1. クラスターを作成

スプリットブレイン発生を防止する観点から、クラスター間のハートビートをやり取りするネットワークは2本以上の冗長構成とするのが望ましい。

クラスター作成の際に、ノード名をIPアドレスごとにカンマ区切りで指定することで、複数のIPアドレスでクラスターに登録がされる。

※片方のノードで実施
# pcs cluster setup --start --name cluster2 t1113cent,t1113cent-55 t1114cent,t1114cent-55
------------------------------
Destroying cluster on nodes: t1113cent, t1114cent...
t1113cent: Stopping Cluster (pacemaker)...
t1114cent: Stopping Cluster (pacemaker)...
t1113cent: Successfully destroyed cluster
t1114cent: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to 't1113cent', 't1114cent'
t1113cent: successful distribution of the file 'pacemaker_remote authkey'
t1114cent: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
t1113cent: Succeeded
t1114cent: Succeeded

Starting cluster on nodes: t1113cent, t1114cent...
t1113cent: Starting Cluster...
t1114cent: Starting Cluster...

Synchronizing pcsd certificates on nodes t1113cent, t1114cent...
t1114cent: Success
t1113cent: Success
Restarting pcsd on the nodes in order to reload the certificates...
t1114cent: Success
t1113cent: Success
------------------------------

設定確認は以下コマンドで実施する。RING ID 0とRING ID 1で2つのIPアドレスが設定されていることがわかる。

# corosync-cfgtool -s
------------------------------
Printing ring status.
Local node ID 1
RING ID 0
        id      = 192.168.11.113
        status  = ring 0 active with no faults
RING ID 1
        id      = 192.168.55.113
        status  = ring 1 active with no faults
------------------------------

2. クラスターのプロパティを設定

クラスターの設定として、STONITHの無効化を行い、no-quorum-policyをignoreに設定する。今回はあくまで検証目的なのでSTONITHは無効化するが、本来はスプリットブレイン時の対策として、STONITHは有効化するべきである。

no-quorum-policyについて、通常クォーラムは多数決の原理でアクティブなノードを決定する仕組みとなるのだが、2台構成のクラスターの場合は多数決による決定ができないため、クォーラム設定は「ignore」に設定するのがセオリーのようだ。この場合スプリットブレインが発生したとしても、各ノードのリソースは特に何も制御されないという設定となるため、STONITHによって片方のノードを強制的に電源を落として対応することになる。

それでは設定をしていこう。まず、現状のプロパティを確認する。

※片方のノードで実施
# pcs property
------------------------------
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: cluster2
 dc-version: 1.1.18-11.el7_5.3-2b07d5c5a9
 have-watchdog: false
------------------------------

設定を変更する。

※片方のノードで実施
# pcs property set stonith-enabled=false
# pcs property set no-quorum-policy=ignore
# pcs property
------------------------------
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: cluster2
 dc-version: 1.1.18-11.el7_5.3-2b07d5c5a9
 have-watchdog: false
 no-quorum-policy: ignore   ←★クォーラムをignoreに設定
 stonith-enabled: false     ←★STONITHを無効化
------------------------------

リソースエージェントを使ってリソースを構成する

1. リソースを構成

リソースを制御するために、リソースエージェントを利用する。リソースエージェントとは、クラスターソフトで用意されているリソースの起動・監視・停止を制御するためのスクリプトとなる。

今回の構成では以下リソースエージェントを利用する。
  • ocf:heartbeat:IPaddr2 : 仮想IPアドレスを制御
  • ocf:heartbeat:Filesystem  : ファイルシステムのマウントを制御
  • systemd:mariadb : MariaDBを制御
各リソースエージェントの使用方法は、以下コマンドで確認できる。

# pcs resource describe <リソースエージェント>

まずは仮想IPアドレスの設定を行う。付与するipアドレス・サブネットマスク・NICを指定している。また、interval=30sとして監視間隔を30秒に変更している。

※片方のノードで実施
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.11.115 cidr_netmask=24 nic=ens192 op monitor interval=30s

次に共有ディスクとして作成したファイルシステム「/dev/sharevg/lv001」のマウントの設定を行う。マウントするデバイス・マウントポイント・ファイルシステムタイプを指定している。

※片方のノードで実施
# pcs resource create ShareDir ocf:heartbeat:Filesystem device=/dev/sharevg/lv001 directory=/share fstype=xfs

最後にMariaDBの設定となる。こちらはシンプルに以下コマンドで設定するだけでよい。

※片方のノードで実施
# pcs resource create MariaDB systemd:mariadb

上記3つのリソースは起動・停止の順番を考慮する必要がある。
  • 起動:「仮想IPアドレス」→「ファイルシステム」→「MariaDB」
  • 停止:「MariaDB」→「ファイルシステム」→「仮想IPアドレス」
この順序を制御するために、リソースの順序を付けてグループ化した「リソースグループ」を作成する。

※片方のノードで実施
# pcs resource group add rg01 VirtualIP ShareDir MariaDB

以上でリソース設定が完了となるので、クラスターの設定を確認してみる。

※片方のノードで実施
# pcs status
------------------------------
Cluster name: cluster2
WARNING: no stonith devices and stonith-enabled is not false
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Thu Aug 30 23:36:40 2018
Last change: Thu Aug 30 23:36:39 2018 by root via cibadmin on t1113cent

2 nodes configured
3 resources configured

Online: [ t1113cent t1114cent ]

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       Stopped
     ShareDir   (ocf::heartbeat:Filesystem):    Stopped
     MariaDB    (systemd:mariadb):      Stopped

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

2. クラスター起動

設定が完了したので、クラスターの起動を行う。各リソースが「Started」となっていれば問題ない。

※片方のノードで実施
# pcs cluster start --all
------------------------------
t1114cent: Starting Cluster...
t1113cent: Starting Cluster...
------------------------------

起動後のステータスを確認。

※片方のノードで実施
# pcs status
------------------------------
Cluster name: cluster2
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Thu Aug 30 23:40:06 2018
Last change: Thu Aug 30 23:38:42 2018 by root via cibadmin on t1113cent

2 nodes configured
3 resources configured

Online: [ t1113cent t1114cent ]

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1113cent
     ShareDir   (ocf::heartbeat:Filesystem):    Started t1113cent
     MariaDB    (systemd:mariadb):      Started t1113cent

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

クラスターのハートビートが二重化されていることも確認しておこう。今回の場合、192.168.11.113と192.168.55.113の2つのIPアドレスが登録されており、「no faults (エラーなし)」となっていることが確認できる。

※片方のノードで実施
# corosync-cfgtool -s
------------------------------
Printing ring status.
Local node ID 1
RING ID 0
        id      = 192.168.11.113
        status  = ring 0 active with no faults
RING ID 1
        id      = 192.168.55.113
        status  = ring 1 active with no faults
------------------------------

次回予告

これでクラスターの作成が完了した。次回は実際に疑似障害を発生させてクラスターのフェイルオーバーの動きを確認することにする。

★次回はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する③ (障害試験編)
https://tech-mmmm.blogspot.com/2018/12/centos-7-pacemaker-corosyncmariadb.html

2018年11月19日月曜日

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する① (準備・インストール編)

RHEL 7やCentOS 7では、サーバークラスターを実装するソフトウェアとして、Pacemaker + Corosyncによる実装が標準となっている。これらの機能は、CentOSでは当然無償で利用することができるが、RHELでは「High Availability Add-On」のサブスクリプション購入が必要となる。

Red Hat Enterprise Linux 7 向け High Availability Add-On のリファレンスドキュメント

Linux環境でクラスターを組んだことがなかったので、勉強がてらCentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化してみた。

実施内容がそこそこ多いので、今回含めて、全3回で記載することにする。
  1. 準備・インストール編
    Pacemaker・CorosyncおよびMariaDBをインストールし初期設定を行う。
  2. クラスター・リソース構成編
    クラスターを作成し、リソースの構成を行う。
  3. 障害試験編
    疑似障害を発生させて、フェイルオーバーの動作確認を行う。
それでは、まずは今回構成する環境からみていこう。

環境および用語

今回はESXi上に仮想マシンを2台作成し、クラスター構成にする。

  • ノード#1 ホスト名:t1113cent
  • ノード#2 ホスト名:t1114cent



PacemakerとCorosyncがクラスターの機能を提供する。それぞれの役割については、以下に他の用語と合わせて記載をする。
  • Pacemaker (ペースメーカー):クラスターのリソース制御(リソースの起動・監視・停止、フェイルオーバー等)を行う
  • Corosync (コロシンク):クラスターノード間の死活監視を行う。後述するSTONITHもCorosyncの機能
  • STONITH (ストニス):Shoot The Other Node In The Headの略。スプリットブレイン時に、複数ノードがActiveになることを防止する機能
  • スプリットブレイン:ネットワーク断によりクラスター間で相互に監視ができなくなり、どのノードがActiveで動作しているか不明となっている状況
  • リソース:クラスターが起動・監視・停止を制御する対象。たとえば、仮想IPアドレス、ディスクマウント、DBサービスなど多岐にわたる
  • リソースエージェント:起動・監視・停止を制御するためのスクリプト。クラスター管理ソフトウェアで用意されている
  • リソースグループ:複数のリソースエージェントをグループ化し、同一ノードで複数のリソースの起動・監視・停止を制御するためのもの
クラスター監視用のネットワークは、すべて切断されるとスプリットブレインとなってしまうため、2本の冗長構成とする。

共有ディスクはSCSIバスの共有を行い、同一のvmdkファイルを2台の仮想マシンからマウントできるように構成し、本ディスクにMariaDBのデータベースを配置する構成とする。

ESXi環境でSCSIバスの共有を行い、共有ディスクを作成

1. ノード#1側にSCSIコントローラーを追加

ESXiにてノード#1の仮想マシンの「設定の編集」を開き、「SCSIコントローラー」を追加する。


「SCSIバスの共有」で仮想または物理を選ぶ。同一のESXiに存在する仮想マシン間でディスクを共有したい場合は「仮想」を選び、複数のESXiをまたいでディスクを共有したい場合は「物理」を選べばよい。今回は、同一ESXiだったので「仮想」で設定した。


2. ノード#1側にディスクを追加

SCSIコントローラーを追加したら、続けて新規ハードディスクを作成する。ディスクを共有する場合は「シック プロビジョニング (Eager Zerod)」を選択する必要がある。「コントローラーの場所」は、先ほど作成した「SCSI コントローラ 1」を選択する。


3. ノード#2側にSCSIコントローラーを追加

もう一台のノード#2側に対しても、同様にSCSIコントローラーを追加する。「SCSIバスの共有」はノード#1と同様「仮想」を選択する。


4. ノード#2側にディスクを追加

新規ではなく「既存のハードディスク」にてディスクを追加する。


ディスク選択画面が表示されるので、ノード#1に作成した共有ディスクとして利用するvmdkファイルを選択する。


最後に、SCSIコントローラーを「SCSI コントローラ 1」に設定すれば完了。


以上で、共有ディスクの作成が完了となる。OS側でも確認すると、以下の通り両ノードでディスクのデバイスが見えていることがわかる。

※ノード#1で実施
# fdisk -l /dev/sdb
------------------------------
Disk /dev/sdb: 5368 MB, 5368709120 bytes, 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
------------------------------

※ノード#2で実施
# fdisk -l /dev/sdb
------------------------------
Disk /dev/sdb: 5368 MB, 5368709120 bytes, 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
------------------------------

今回は本題から外れるので詳細な手順は割愛するが、上記領域に適当にファイルシステムを作成し、ノード#1の/shareにマウントしておこう。

MariaDBのインストール・初期設定

1. MariaDBをインストール

yumでインストールするのが手っ取り早い。

※両ノードで実施
# yum install mariadb
# yum install mariadb-server

インストール後、状態を確認する。最終的にクラスターで起動・停止が制御されるため、現時点ではinactive / disabledになっていればよい。

※両ノードで実施
# systemctl status mariadb
------------------------------
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
------------------------------

2. 初期設定

MariaDBのデータベース保存先を/share/mysqlに変更するため、/etc/my.cnfに変更と追記を行う。

※両ノードで実施
# vi /etc/my.cnf
------------------------------
[mysqld]
#datadir=/var/lib/mysql           ←★コメントアウト
datadir=/share/mysql              ←★追加
#socket=/var/lib/mysql/mysql.sock ←★コメントアウト
socket=/share/mysql/mysql.sock    ←★追加

[client]                          ←★追加
socket=/share/mysql/mysql.sock    ←★追加
------------------------------

3. MariaDBを起動

設定完了後MariaDBを起動すると、以下の通りエラーとなった。

※ノード#1で実施
# systemctl start mariadb
------------------------------
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.
------------------------------

SELinuxが悪さするようなので止めておく。

※両ノードで実施
# setenforce 0

再度起動させると、今度は成功するはず。

※ノード#1で実施
# systemctl start mariadb

4. データベース・テーブル作成

MariaDBの動作確認ができるようにデータベースとテーブルを作っておく。mysqlコマンドを用いて、rootユーザーでMariaDBにログインする。

※ノード#1で実施
# mysql -u root

データベースを作成する。

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.00 sec)

MariaDB [(none)]> create database cluster_test;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| cluster_test       | ←★作成された
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

続けてテーブルを作成する。

MariaDB [(none)]> use cluster_test;
Database changed

MariaDB [cluster_test]> show tables;
Empty set (0.00 sec)

MariaDB [cluster_test]> create table test_table(name varchar(20));
Query OK, 0 rows affected (0.00 sec)

MariaDB [cluster_test]> show tables;
+------------------------+
| Tables_in_cluster_test |
+------------------------+
| test_table             | ←★作成された
+------------------------+
1 row in set (0.00 sec)

作成したテーブルに1行追加してみる。

MariaDB [cluster_test]> insert into test_table value('hoge');
Query OK, 1 row affected (0.00 sec)

MariaDB [cluster_test]> select * from test_table;
+------+
| name |
+------+
| hoge | ←★追加された
+------+
1 row in set (0.00 sec)

以上でMariaDBの準備が整った。

Pacemaker・Corosyncのインストール・初期設定

1. Pacemaker・Corosyncをインストール

yumでインストールする。

※両ノードで実施
# yum install pacemaker
# yum install pcs
# yum install fence-agents-all


2. 初期設定

クラスター用ユーザーを設定する。yumでインストールすると、「hacluster」ユーザーが作成されているはずなので確認する。

※両ノードで実施
# cat /etc/passwd | tail
------------------------------
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
chrony:x:998:996::/var/lib/chrony:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
hacluster:x:189:189:cluster user:/home/hacluster:/sbin/nologin ←★クラスター用ユーザー
unbound:x:997:993:Unbound DNS resolver:/etc/unbound:/sbin/nologin
------------------------------

パスワードを設定しておく。当然、両ノードで同一のパスワードで設定しておくこと。

※両ノードで実施
# passwd hacluster
------------------------------
ユーザー hacluster のパスワードを変更。
新しいパスワード:
新しいパスワードを再入力してください:
passwd: すべての認証トークンが正しく更新できました。
------------------------------

ここで、Pacemakerのサービスを起動させる。

※両ノードで実施
# systemctl start pcsd.service
# systemctl enable pcsd.service

起動後の状態を確認し、エラーなくacitive / enabledとなっていればOK。

※両ノードで実施
# systemctl status pcsd.service
------------------------------
● pcsd.service - PCS GUI and remote configuration interface
   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
   Active: active (running) since 木 2018-08-30 10:28:07 JST; 2min 13s ago
     Docs: man:pcsd(8)
           man:pcs(8)
 Main PID: 2004 (pcsd)
   CGroup: /system.slice/pcsd.service
           mq2004 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null &

 8月 30 10:28:01 t1113cent systemd[1]: Starting PCS GUI and remote configur....
 8月 30 10:28:07 t1113cent systemd[1]: Started PCS GUI and remote configura....
Hint: Some lines were ellipsized, use -l to show in full.
------------------------------

クラスターを組む際に名前解決できるように、hostsにお互いのIPアドレスを登録しておく。

※両ノードで実施
# vi /etc/hosts
------------------------------
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.11.113  t1113cent    ←★追加
192.168.55.113  t1113cent-55 ←★追加
192.168.11.114  t1114cent    ←★追加
192.168.55.114  t1114cent-55 ←★追加
------------------------------

クラスターに参加するノードの認証を行う。。。が、失敗してしまった。

※片方のノードで実施
# pcs cluster auth t1113cent t1114cent
------------------------------
Username: hacluster
Password:
Error: Unable to communicate with t1114cent ←★失敗。。。
t1113cent: Authorized
------------------------------

どうやらfirewalldが原因のようなので止めておく。

※両ノードで実施
# systemctl stop firewalld
# systemctl disable firewalld

再度ノードの認証を行うと成功した。

※片方のノードで実施
# pcs cluster auth t1113cent t1114cent
------------------------------
Username: hacluster
Password:
t1114cent: Authorized
t1113cent: Authorized
------------------------------

次回予告

これで準備がようやく終わり、次から本題のクラスター構成作業に進むのだが、長くなってしまったので続きは次回とする。

★次回はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する② (クラスター・リソース構成編)

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する③ (障害試験編)
https://tech-mmmm.blogspot.com/2018/12/centos-7-pacemaker-corosyncmariadb.html

2018年11月6日火曜日

vCenter Server Appliance 6.7にupdate1を適用する手順

vCenter Server 6.7のupdate1が2018/10/16にリリースされたようだ。

VMware vCenter Server 6.7 Update 1 リリース ノート
https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vsphere-vcenter-server-671-release-notes.html

上記update1をvCSA6.7に適用してみたので、手順を簡単に記載する。

事前確認

バージョンアップの前に、必ず「VMware Product Interoperability Matrices」を使って、アップデート対象のvCenter Serverが管理できるESXiのバージョンを確認しておこう

VMware Product Interoperability Matrices - チェック結果
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&2=2862,2736&1=

チェック結果は以下の通りとなり、ESXi 6.0以降であればvCSA 6.7 update1で問題なく管理できるようだ。

------------------------------
VMware vCenter Server 6.7 U1 6.7.0
VMware vSphere Hypervisor (ESXi)
6.7 U1 Y Y
6.7.0 Y Y
6.5 U2 Y Y
6.5 U1 Y Y
6.5.0 Y Y
6.0 U3 Y Y
6.0.0 U2 Y Y
6.0.0 U1 Y Y
6.0.0 Y Y
------------------------------

手順

1. ISOイメージをダウンロード

以下サイトからvCSAのupdate1のISOイメージをダウンロードする。

My VMware  - 製品パッチ
https://my.vmware.com/group/vmware/patch#search

製品を「VC」、バージョンを「6.7」で検索すると、「VC-6.7.0-update01-Appliance-Patch」が表示されるので、「ダウンロード」ボタンを押してダウンロードする。1.8GB程度の「VMware-vCenter-Server-Appliance-6.7.0.20000-10244745-patch-FP.iso」というファイルがダウンロードされる。



2. vCSAにupdate1のISOをマウント

ダウンロードしたISOイメージをvCSAの仮想CD/DVDドライブにマウントする。この辺りは一般的なvSphere環境の手順で実施すればよいので、詳細な手順は割愛する。

3. SSHでvCSAにログイン

vCSAに対してSSHを使ってrootログインする。なお、インストール時にSSHを有効にしていない場合は、https://<vCSAのIPアドレス>:5480/にアクセスし、「アクセス設定」を変更しておこう。
※SSHを使わなくても直接コンソールを使ってアップデート作業はできると思うが、操作性の観点から今回はSSHで作業する。


4. マウント&ライセンス条項に同意

以下コマンドにて、ISOイメージをマウントし、ライセンス条項に同意する。ライセンス条項は非常に長いのだが、最後に「yes」を入力するところまでスクロールさせる必要がある。面倒だが頑張ろう。

Command> software-packages stage --iso
------------------------------
 [2018-10-23T03:57:10.296] : ISO mounted successfully

VMWARE END USER LICENSE AGREEMENT

PLEASE NOTE THAT THE TERMS OF THIS END USER LICENSE AGREEMENT SHALL GOVERN YOUR
USE OF THE SOFTWARE, REGARDLESS OF ANY TERMS THAT MAY APPEAR DURING THE
INSTALLATION OF THE SOFTWARE.

~(中略)~

12.11  Contact Information.  Please direct legal notices or other
correspondence to VMware, Inc., 3401 Hillview Avenue, Palo Alto, California
94304, United States of America, Attention: Legal Department.
Do you accept the terms and conditions?  [yes/no] yes ←★「yes」を入力
 [2018-10-23T03:58:58.296] : Evaluating packages to stage...
 [2018-10-23T03:58:58.296] : Verifying staging area
 [2018-10-23T03:58:58.296] : ISO unmounted successfully
 [2018-10-23T03:58:58.296] : Staging process completed successfully
------------------------------

5. インストール前の内容確認

インストール前に、インストール内容を確認することができる。nameが「VC-6.7.0U1-Appliance-FP」になっていれば問題ない。

Command> software-packages list --staged
------------------------------
 [2018-10-23T03:59:33.296] :
        productname: VMware vCenter Server Appliance
        name: VC-6.7.0U1-Appliance-FP
        leaf_services: ['vmware-pod']
        rebootrequired: True
        tags: []
        thirdPartyInstallation: False
        eulaAcceptTime: 2018-10-23 03:58:49 UTC
        summary: Update for VMware vCenter Server Appliance 6.7.0
        releasedate: October 16, 2018
        buildnumber: 10244745
        version: 6.7.0.20000
        size in MB: 1829
        updateversion: True
        TPP_ISO: False
        vendor: VMware, Inc.
        severity: Critical
        category: Bugfix
        kb: https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-vcenter-server-671-release-notes.html#full_patch
        version_supported: ['6.7.0.10000', '6.7.0.11000', '6.7.0.12000']
------------------------------

6. インストール

以下コマンドでインストールを開始する。なお、「Running pre-install script」の処理が始まるころからWeb Client接続不可となるので注意すること。

Command> software-packages install --staged
------------------------------
 [2018-10-23T04:00:08.296] : Validating software update payload
 [2018-10-23T04:00:08.296] : Validation successful
 [2018-10-23 04:00:08,914] : Copying software packages  [2018-10-23T04:00:08.296] : ISO mounted successfully
133/133
 [2018-10-23T04:00:54.296] : ISO unmounted successfully
 [2018-10-23 04:00:54,103] : Running test transaction ....
 [2018-10-23 04:00:56,135] : Running pre-install script.....
 [2018-10-23 04:03:53,470] : Upgrading software packages ....
 [2018-10-23T04:05:51.296] : Setting appliance version to 6.7.0.20000 build 10244745
 [2018-10-23 04:05:51,899] : Running pre-patch script.....
 [2018-10-23 04:05:52,905] : Running post-patch script.....
 [2018-10-23T04:06:00.296] : Packages upgraded successfully, Reboot is required to complete the installation.
------------------------------

7. 再起動

最後に再起動を行う。-rオプションの後のメッセージは適当な再起動理由を記載しておけばよい。

Command> shutdown reboot -r "Install update1"

8. インストール後のビルド番号を確認

正常にインストールされたことを確認するため、https://<vCSAのIPアドレス>:5480/にアクセスし、ビルド番号を確認してみよう。

【バージョンアップ前】


【バージョンアップ後】


以上のように、正常にアップデートが完了していることを確認できた。

人気の投稿