リソース・グループの構成

Linux on Power Systems
Tivoli System Automation for Multiplatforms 4.1
構築ガイド
for RHEL 7.1
日本アイ・ビー・エム株式会社
Power Systems テクニカルセールス
日本アイ・ビー・エムシステムズ・
エンジニアリング株式会社
Server Technology & Mainframe Server
2016年 1月15日
rev 1.2
更新履歴
2

2015年12月27日
rev. 1.0
初版発行

2016年1月5日
rev. 1.1
誤字などを修正

2016年1月15日
rev. 1.2
クラスターの操作(6)を追加
© 2015 IBM Corporation
はじめに
￭このドキュメントでは、Red Hat Enterprise Linux 7.1 に Tivoli System
Automation (TSA) for Multiplatforms 4.1 をインストールし、HA クラスター
環境を構成する手順を紹介します。
•
•
•
RHEL 7.1 は Little Endian (LE) 版を使用しますが、手順は Big Endian (BE) 版でも違いはありま
せん。
このドキュメントでは 2 ノード構成で、HTTP デーモンをアプリケーションリソースとする HA 構
成の Web サーバーを構成します。
VIOS の使用を想定して記載していますが、non-VIOS でも構築手順に違いはありません。
￭このドキュメントの内容に関して正式な IBM のテストを受けていません。
こちらの情報を参考とした作業の実施に関しては、使用者の責任において行われ
るべきものであり、それらの評価に関しては使用者の判断に依存しています。
￭このドキュメントを参考資料として利用し、運用を計画、実施される場合には
必ず製品のマニュアルにて最新の情報をご参照ください。また、本番使用に際し
ましては充分な動作テストを行っていただくようお願いいたします。
￭このドキュメントの記述内容は次ページの環境にて検証していますが、全ての
環境で同一の結果を保証するものではありません。
3
© 2015 IBM Corporation
目次
￭ TSA クラスターの基本概念
￭検証環境
￭ TSA のインストールとクラスターの作成
￭リソース・グループの構成
￭クラスターの操作
￭ TSA の動作確認確認
￭スプリットブレインについて
￭ Linux on Power でのタイブレーカー
￭参考情報
4
© 2015 IBM Corporation
TSA クラスターの基本概念
5
© 2015 IBM Corporation
TSA クラスターの基本概念（1）
￭ TSA クラスターを構成する際は、次のような情報を定義します。
1. クラスター全体を定義するための情報（クラスター情報）
▶ ドメイン
– クラスターを構成する全てのノードを含むドメインを
作成します。
▶ コミュニケーショングループ
– ドメインに属するノード間のハートビート経路を
指定します。（TSA では IP 経由のハートビート
経路は自動的に検出、設定されます。）
▶ タイブレーカー (IBM.TieBreaker) ※
– スプリットブレインが発生した際にアクセスする
ことでサービスを継続するノードを決定します。
▶ インターフェース監視用 IP アドレス (netmon.cf)
– ping が到達するかによってネットワーク・アダプター
の障害を検知するための IP アドレスを指定します。
アダプター監視 IP
コミュニケーション
グループ
ノード1
ノード2
タイブレーカー
ドメイン
※ TieBreaker はディスク・タイブレーカー、ネットワーク・タイブレーカーなどから選択できます。
6
© 2015 IBM Corporation
TSA クラスターの基本概念（2）
2. 引き継ぎ対象とするリソースを定義するための情報（引き継ぎリソース情報）
▶ リソース・グループ (IBM.ResourceGroup)
– ノード間で引継ぎ対象とするリソースをまとめたリソース・グループを構成します。
– リソース・グループに含まれる一連のリソースをまとめて起動、停止することが可能です。
▶ IP リソース (IBM.ServiceIP)
– IP リソースでサービス IP アドレスを指定します。
▶ ファイルシステムリソース (IBM.AgFileSystem)
– 共有ディスクのファイルシステムを指定します。
– StorageRM (Storage Resource Manager) によって管理されます。(※)
▶ アプリケーションリソース (IBM.Application)
– アプリケーションを起動/停止/監視するコマンド/スクリプトを指定します。
▶ 依存関係
– リソースの起動順序を制御するためにリソース間の依存関係を指定します。
▶ 同値 (IBM.Equivalency)
− 各ノードに存在するリソースをグループ化します。
− サービス IP アドレスをアサインするインターフェースを指定するために使用します。
※ StorageRM は自動的にファイルシステムの情報を取得します。
7
© 2015 IBM Corporation
TSA クラスターの基本概念（3）
ターゲット
依存関係
￭リソースの依存関係と同値
•
サービス IP アドレス、共有ディスク、HTTP デーモンの依存関係
−
ソース
次章からの手順では以下の DependsOn の依存関係を構成します。
– ソースリソースの起動には同一ノードでのターゲットリソースの起動が必要となります。
– ターゲットリソースの障害時にはソースリソースも停止します。
ノード2
ノード1
eth0
コミュニケーショングループ
eth0
IBM.Equivalency:InternalNW＿IF
コミュニケーショングループ1 の
インターフェースにサービス IP を構成
IBM.ServiceIP:service_ip1
リソース・グループ
8
IBM.AgFileSystem:fs_share
IBM.Application:httpd
サービス IP、共有ディスクが
オンライン後に
httpd デーモンを起動
© 2015 IBM Corporation
検証環境
9
© 2015 IBM Corporation
検証環境クラスター構成
￭ TSA の検証環境
•
•
•
•
•
•
•
2 ノードクラスター ( ドメイン名：sa_domain) を構成
IP 経由のハートビート経路は 192.168.1/24 と 172.16.0/24 の２経路
ディスク・ハートビートを構成
ネットワーク・タイブレーカーを構成
サービス IP アドレスは 192.168.1/24 にのみ構成
共有ディスク上にファイルシステム /share を構成
アプリケーションは http サーバーを構成
172.16.0.1
192.168.1.1
eth0
サービス IP アドレス
192.168.1.101
ネットワークタイブレーカー
172.16.0.2
192.168.1.2
eth1
eth0
ノード1
eth1
ノード2
http サーバー
共有ファイルシステム
/share
共有データ領域
mpatha
ハートビート領域
mpathc
10
© 2015 IBM Corporation
検証環境ハードウェア/ソフトウェア構成
￭サーバー
•
IBM Power S824
−
−
−
•
NIC
FC
内蔵ディスク
：4-port 1Gb Ethernet Adapter, 4-port 10Gb SR-IOV Ethernet Adapter
：4-port 8Gb FC Adapter
：VIOS の rootvg に使用
IBM Power S814
−
−
−
NIC
FC
内蔵ディスク
：4-port 1Gb Ethernet Adapter, 4-port 10Gb SR-IOV Ethernet Adapter
：4-port 8Gb FC Adapter
：VIOS の rootvg に使用
￭ストレージ
−
IBM Storwise V7000
￭ソフトウェア
•
•
•
11
OS
Cluster
VIOS
：Redhat Enterprise Linux 7.1 Little Endian (ppc64-le)
：Tivoli System Automation for Multiplatforms v4.1.0.2
：Virtual I/O Server v2.2.4.0
© 2015 IBM Corporation
検証環境ストレージ構成
￭ RHEL 7.1 のシステム領域は V7000 上に構成します
￭ RHEL 7.1 のマルチパスドライバは Device Mapper Multipath を使用します
￭ VIOS のマルチパスドライバは SDDPCM を使用します
Power System サーバー
VIOS1-1
RHEL 7.1 LE
node1
内蔵ディスク
(vios rootvg)
vSCSI
Power System サーバー
システム領域
mpatha
共有データ領域
mpathb (/share)
VIOS1-2
VIOS2-1
内蔵ディスク
(vios rootvg)
内蔵ディスク
(vios rootvg)
vSCSI
vSCSI
ハートビート領域
mpathc
FC
FC
FC
12
node2
システム領域
システム領域
mpatha
共有データ領域
mpathb (/share)
VIOS2-2
内蔵ディスク
(vios rootvg)
vSCSI
ハートビート領域
mpathc
FC
ノード・キャニスターA
node1
システム領域
RHEL 7.1 LE
node2
FC
FC
FC
FC
ノード・キャニスターB
共有データ領域
ハートビート領域
IBM Storwise ©V7000
2015 IBM Corporation
検証環境ネットワーク構成
￭ネットワーク冗長化は VIOS で SEA Failover 構成とします
￭ RHEL 7.1 はネットワーク・インターフェースとして仮想イーサネット (VE) を使用します
￭仮想イーサネットのネットワーク検知用に外部に障害検知用のアドレスを持つサーバーを用意します
Power System サーバー
VIOS1-1
RHEL 7.1 LE
node1
Power System サーバー
VIOS1-2
VIOS2-1
サービス用LAN
VIOS2-2
サービス用LAN
SEA
VE
SEA
SEA
VE
SEA
SEA
VE
SEA
SEA
VE
SEA
管理用LAN
NIC
RHEL 7.1 LE
node2
NIC
管理用LAN
NIC
NIC
NIC
NIC
NIC
NIC
管理用LAN – 172.16.0.0
サービス用LAN – 192.168.1.0
13
ネットワーク障害検知用アドレス
© 2015 IBM Corporation
TSA のインストールとクラスターの構成
14
© 2015 IBM Corporation
TSA のインストール
￭ TSA のインストール手順
各ノードで実施
▶ /root/.bashrc に環境変数を定義
–
–
# echo "export CT_MANAGEMENT_SCOPE=2" >> /root/.bashrc
# . /root/.bashrc
▶ 導入メディアに含まれる前提条件確認コマンドを実行
–
–
–
※1
# tar –xvf 4.1.0-TIV-SAMP-Linux64-FP0002.tar.gz
# cd SAM4102MPLinux64
# ./prereqSAM
▶ 導入メディアに含まれるインストールコマンドを実行
–
–
# cd SAM4102MPLinux64
# ./installSAM --noliccheck
▶ FixPack を入手してインストールコマンドを実行
▶ ライセンスをインストール ※3
–
–
–
15
※2
# tar –xvf SA_MP_v4.1_Lnx.tar
# cd SAM4100MPLinux/license
# samlicm –i sam41.lic
※1 今回使用する RHEL 7.1 LE は TSA 4.1.0.2 からサポートされるため、FP2 のメディアを使用
※2 今回は最新の FixPack がインストールで使用した FP2 のため省略
※3 ライセンスファイルはベースメディアに存在するためベースメディアも必要となる
© 2015 IBM Corporation
クラスターの作成
￭ TSA クラスターの作成手順
▶ クラスターへの参加準備
各ノードで実施
# preprpnode node1 node2
▶ クラスター（ドメイン）を作成
以後 1ノードで実施
# mkrpdomain sa_domain node1 node2
# lsrpdomain
Name
OpState RSCTActiveVersion MixedVersions TSPort GSPort
sa_domain Offline 3.2.0.9
No
12347 12348
▶ クラスターの起動
# startrpdomain sa_domain
# lsrpdomain
Name
OpState RSCTActiveVersion MixedVersions TSPort GSPort
sa_domain Online 3.2.0.9
No
12347 12348
16
© 2015 IBM Corporation
クラスターの設定（1）
￭ TSA クラスター全体の設定手順
▶ インターフェース監視用 IP アドレスを設定
各ノードで実施
# vi /var/ct/cfg/netmon.cf
!REQD eth0 192.168.1.254
▶ デッドマン・スイッチの構成※
# chrsrc
# lsrsrc
Resource
resource
以後 1ノードで実施
-c IBM.PeerNode CritRsrcProtMethod=3
-c IBM.PeerNode CritRsrcProtMethod
Class Persistent Attributes for IBM.PeerNode
1:
CritRsrcProtMethod = 3
▶ タイブレーカーの設定
# mkrsrc IBM.TieBreaker Type="EXEC" Name="mynetworktb" \
DeviceInfo='PATHNAME=/usr/sbin/rsct/bin/samtb_net Address=192.168.1.254 Log=1' \
PostReserveWaitTime=30
# chrsrc -c IBM.PeerNode OpQuorumTieBreaker="mynetworktb"
※ CritRsrcProtMethod の詳細については「スプリットブレインについて」の章を参照してください
17
© 2015 IBM Corporation
クラスターの設定（2）
▶ ディスク・ハートビートの構成
1ノードで実施
※
# mkrsrc IBM.HeartbeatInterface Name=mydiskhb DeviceInfo="/dev/dm-0" CommGroup=DHB1 \
NodeNameList={'node1','node2'} MediaType=2 Force=1
▶ ディスク・ハートビートの稼働検証
node1
18
node2
# /usr/sbin/rsct/bin/dhb_read -p /dev/dm-0 -r
DHB CLASSIC MODE
First node byte offset: 61440
Second node byte offset: 62976
Handshaking byte offset: 65024
Test byte offset: 64512
# /usr/sbin/rsct/bin/dhb_read -p /dev/dm-0 -t
DHB CLASSIC MODE
First node byte offset: 61440
Second node byte offset: 62976
Handshaking byte offset: 65024
Test byte offset: 64512
Receive Mode:
Waiting for response . . .
Magic number = 0x87654321
Magic number = 0x87654321
Magic number = 0x87654321
Magic number = 0x87654321
Link operating normally
Transmit Mode:
Magic number = 0x87654321
Detected remote utility in receive mode.
Waiting for response . . .
Magic number = 0x87654321
Link operating normally
※ ディスク・ハートビートで使用するデバイスは環境によって異なるため、各ノードでデバイス名を必ず確認してください
ノードによってデバイス名が異なる場合は NodeNameList にて個々のノードを指定してリソースを構成してください
© 2015 IBM Corporation
クラスター構成
￭ここまでで下図の構成が完了しました
•
コミュニケーショングループは自動的に構成されています
ネットワークタイブレーカー
/ ネットワーク障害検知用 IP
192.168.1.254
コミュニケーショングループ2
コミュニケーショングループ1
172.16.0.1
192.168.1.1
eth0
eth1
node1
ハートビート・
インターフェース
/dev/dm-0
19
172.16.0.2
192.168.1.2
eth0
ドメイン：sa_domain
共有データ領域
mpatha
ハートビート領域
mpathc
eth1
node2
ハートビート・
インターフェース
/dev/dm-0
© 2015 IBM Corporation
リソース・グループの構成
20
© 2015 IBM Corporation
リソース・グループの構成（1）
￭共有リソースの作成手順
1ノードで実施
▶ サービス IP リソースの作成
# mkrsrc IBM.ServiceIP Name="service_ip1" NodeNameList="{'node1','node2'}" \
IPAddress=192.168.1.101 NetMask=255.255.255.0
▶ ファイルシステムリソースの設定
#
#
#
#
#
※
mkfs.xfs -f /dev/mappar/mpathb -L share_fs
mkdir -p /share
mount /share
mkdir -p /share/www/html
umount /share
各ノードで実施
▶ マウントポイントの設定
# vi /etc/fstab
…中略…
LABEL=share_fs
21
/share
xfs
noauto
0 0
※ 共有ディスク・リソースはファイルシステム作成後にStorageRM により自動的に作成され、明示的にリソースを
作成する必要はありませんが、即剤に反映させる場合は refrsrc IBM.Disk を実行してください
© 2015 IBM Corporation
リソース名を指定するために mkfs 実行時に –L にてラベルを指定してください
リソース・グループの構成（2）
▶ ファイルシステムリソースの確認
1ノードで実施
# lsrsrc -s "Name=='share_fs'" IBM.AgFileSystem Name DeviceName NodeNameList \
SysMountPoint Label
Resource Persistent Attributes for IBM.AgFileSystem
resource 1:
Name
= "share_fs"
DeviceName
= ""
NodeNameList = {"node1", "node2"}
SysMountPoint = "/share"
Label
= "share_fs"
resource 2:
Name
= "share_fs"
DeviceName
= "/dev/mapper/mpathb"
NodeNameList = {"node1"}
SysMountPoint = "/share"
Label
= "share_fs"
resource 3:
Name
= "share_fs"
DeviceName
= "/dev/mapper/mapthb"
NodeNameList = {"node2"}
SysMountPoint = "/share"
Label
= "share_fs"
22
© 2015 IBM Corporation
リソース・グループの構成（3）
▶ アプリケーションリソースの作成
※
1ノードで実施
# mkrsrc IBM.Application \
Name=httpd \
StartCommand="/usr/bin/systemctl start httpd" \
StopCommand="/usr/bin/systemctl stop httpd" \
MonitorCommand="/usr/sbin/rsct/bin/pidmon '/usr/sbin/httpd'" \
UserName=root \
NodeNameList="{'node1','node2'}" \
MonitorCommandPeriod=10 \
MonitorCommandTimeout=6 \
StartCommandTimeout=10 \
StopCommandTimeout=10
※1 httpd (Apache) は事前に構成済みの想定です
ここでは /share/www/html をドキュメント・ルートとして Apache を構成しています
23
© 2015 IBM Corporation
リソース・グループの構成（4）
–
アプリケーションリソースの設定項目
※
属性
説明
Name
任意のリソース名
StartCommand
アプリケーションを起動するコマンドのフルパス
StopCommand
アプリケーションを停止するコマンドのフルパス
MonitorCommand
アプリケーションを監視するコマンドのフルパス
コマンドの返り値によりリソースの状態が判定されます
UserName
コマンドを実行するユーザー
MonitorCommandPeriod,
MonitorCommandTimeout
監視の間隔とタイムアウト時間
StartCommandTimeout,
StopCommandTimeout
アプリケーションの起動 / 停止のタイムアウト
※ アプリケーションリソースの属性値の詳細についてはマニュアルをご確認ください
ここに記載した設定項目は lsrsrcdev –i IBM.Application により表示される値のサブセットになります
24
© 2015 IBM Corporation
リソース・グループの構成（5）
￭リソース・グループの作成/設定手順
▶ リソース・グループの作成
1ノードで実施
# mkrg rg1
▶ リソース・グループのロック※
# rgreq –o lock rg1
▶ リソース・グループにリソースを追加
# addrgmbr -g rg1 IBM.ServiceIP:service_ip1 IBM.Application:httpd \
IBM.AgFileSystem:share_fs
▶ アプリケーションなどが正しくオフラインと認識されていることを確認
# lssam
▶ リソース・グループのアンロック
# rgreq –o unlock rg1
※ リソース・グループにリソースを追加しても、この時点で TSA がアプリケーションの起動、停止、引継ぎなどの制御を開始しないように
一旦リソース・グループをロックしてからリソースを追加を行うことをお勧めします
25
© 2015 IBM Corporation
リソース・グループがロックされている場合、TSA はモニターは行いますが制御は行いません
リソース・グループの構成（6）
￭リソースの依存関係の作成
▶ コミュニケーショングループの同値を作成
1ノードで実施
# lscomg -x
CG1 4
1
1
Yes
Yes
-1 (Default) 1 (IP)
CG2 4
1
1
Yes
Yes
-1 (Default) 1 (IP)
DHB1 4
2
1
Yes
Yes
-1 (Default) 2 (Disk)
# lscomg -i CG1
Name NodeName IPAddress
Subnet
SubnetMask
eth1 node1
172.16.0.1
172.16.0.0 255.255.255.0
eth1 node2
172.16.0.2
172.16.0.0 255.255.255.0
# lscomg -i CG2
Name NodeName IPAddress
Subnet
SubnetMask
eth0 node1
192.168.1.1
192.168.1.0 255.255.255.0
eth0 node2
192.168.1.2
192.168.1.0 255.255.255.0
#
# mkequ -S 'CommGroup="CG2"' InternalNW_IF IBM.NetworkInterface
1
1
1
▶ リソース間の依存関係を作成
# mkrel -p DependsOn -S IBM.Application:httpd -G IBM.ServiceIP:service_ip1
# mkrel -p DependsOn -S IBM.Application:httpd -G IBM.AgFileSystem:share_fs
# mkrel –p DependsOn –S IBM.ServiceIP:service_ip1 –G IBM.Equivalency:InternalNW_IF
26
© 2015 IBM Corporation
リソース・グループ構成
￭ここまでで下図の構成が完了しました
•
•
httpd が起動する前にサービス IP アドレスと共有ファイルシステムが構成されます
サービス IP アドレスはコミュニケーショングループ2 のインターフェース上に構成されます
ノード2
ノード1
eth0
コミュニケーショングループ2
eth0
IBM.Equivalency:InternalNW＿IF
IBM.ServiceIP:service_ip1
192.168.1.101
IBM.AgFileSystem:fs_share
/share
IBM.Application:httpd
リソース・グループ：rg1
27
© 2015 IBM Corporation
クラスターの操作
28
© 2015 IBM Corporation
クラスターの操作（1）
￭クラスターの操作コマンド
▶ クラスターの状態確認
–
lsrpdomain
: クラスター全体（ドメイン）の状態を表示します
クラスター起動時
# lsrpdomain
Name
OpState RSCTActiveVersion MixedVersions TSPort GSPort
sa_domain Online 3.2.0.9
No
12347 12348
クラスター停止時
# lsrpdomain
Name
OpState RSCTActiveVersion MixedVersions TSPort GSPort
sa_domain Offline 3.2.0.9
No
12347 12348
–
lsrpnode
: クラスター内のノードの状態を表示します
# lsrpnode
Name
OpState RSCTVersion
node1
Online 3.2.0.9
node2
Offline 3.2.0.9
29
node1 が起動
node2 が停止
© 2015 IBM Corporation
クラスターの操作（2）
▶ リソース・グループの状態確認
–
lssam
: リソース・グループ / リソースと各ノードの状態を表示します※
リソース・グループ・オフライン時
# lssam
Offline IBM.ResourceGroup:rg1 Nominal=Offline
|- Offline IBM.AgFileSystem:share_fs
|- Offline IBM.AgFileSystem:share_fs:node1
'- Offline IBM.AgFileSystem:share_fs:node2
|- Offline IBM.Application:httpd
|- Offline IBM.Application:httpd:node1
'- Offline IBM.Application:httpd:node2
'- Offline IBM.ServiceIP:service_ip1
|- Offline IBM.ServiceIP:service_ip1:node1
'- Offline IBM.ServiceIP:service_ip1:node2
Online IBM.Equivalency:InternalNW_IF
|- Online IBM.NetworkInterface:eth0:node1
'- Online IBM.NetworkInterface:eth0:node2
30
※ lssam は以下のプションも指定できます
-top
：リアルタイムに表示
-V
：依存関係を表示
-nocolor
：色の制御コード無し
© 2015 IBM Corporation
クラスターの操作（3）
–
lssam
: リソース・グループ / リソースと各ノードの状態を表示します
リソース・グループ・オフライン&ロック時
# rgreq -o lock rg1
# lssam -nocolor
Offline IBM.ResourceGroup:rg1 Request=Lock Nominal=Offline
|- Offline IBM.AgFileSystem:share_fs Control=SuspendedPropageted
|- Offline IBM.AgFileSystem:share_fs:node1
'- Offline IBM.AgFileSystem:share_fs:node2
|- Offline IBM.Application:httpd Control=SuspendedPropageted
|- Offline IBM.Application:httpd:node1
'- Offline IBM.Application:httpd:node2
'- Offline IBM.ServiceIP:service_ip1 Control=SuspendedPropageted
|- Offline IBM.ServiceIP:service_ip1:node1
'- Offline IBM.ServiceIP:service_ip1:node2
Online IBM.Equivalency:InternalNW_IF
|- Online IBM.NetworkInterface:eth0:node1
'- Online IBM.NetworkInterface:eth0:node2
31
© 2015 IBM Corporation
クラスターの操作（4）
–
lssam
: リソース・グループ / リソースと各ノードの状態を表示します
リソース・グループ・オンライン時
# rgreq -o unlock rg1
# chrg -o online rg1
# lssam
Online IBM.ResourceGroup:rg1 Nominal=Online
|- Online IBM.AgFileSystem:share_fs
|- Online IBM.AgFileSystem:share_fs:node1
'- Offline IBM.AgFileSystem:share_fs:node2
|- Online IBM.Application:httpd
|- Online IBM.Application:httpd:node1
'- Offline IBM.Application:httpd:node2
'- Online IBM.ServiceIP:service_ip1
|- Online IBM.ServiceIP:service_ip1:node1
'- Offline IBM.ServiceIP:service_ip1:node2
Online IBM.Equivalency:InternalNW_IF
|- Online IBM.NetworkInterface:eth0:node1
'- Online IBM.NetworkInterface:eth0:node2
32
© 2015 IBM Corporation
クラスターの操作（5）
▶ クラスターの起動、停止
–
–
startrpdomain <ドメイン名> : クラスターを起動します
stoprpdomain <ドメイン名> : クラスターを停止します
▶ ノードの起動、停止
–
–
–
–
startrpnode <ノード名>
stoprpnode <ノード名>
samctlr –u a <ノード名>
samctrl –u d <ノード名>
:
:
:
:
ノードを起動します
ノードを停止します
ノードをリソース引継ぎ対象から除外します
ノードをリソース引継ぎ対象に戻します
▶ リソース・グループの起動、停止、引継ぎ
–
–
–
–
–
33
chrg –o online <リソース・グループ名>
chrg –o offline <リソース・グループ名>
rgreq –o move <リソース・グループ名>
rgreq –o lock <リソース・グループ名>
rgreq –o unlock <リソース・グループ名>
:
:
:
:
:
リソース・グループを起動します
リソース・グループを停止します
リソース・グループを他ノードに引継ぎます
リソース・グループをロックします
リソース・グループをアンロックします
© 2015 IBM Corporation
クラスターの操作（6）
▶ リソースのリセット
–
resetrsrc –s “selection_string” resource_class
: リソースをリセットします
httpd を node1 において手動で障害状態回復させたが
TSA 上では FailedOffline 状態と認識されたままの場合にリセットが可能
# resetrsrc -s 'Name="httpd" and NodeNameList={"node1"}' IBM.Application
▶ TSA 関連ログの出力
–
samlog
: 稼働中のドメインの TSA 関連ログを収集、フォーマット設定、
マージ、および表示します
▶ 情報収集
–
34
getsadata -all
: 関連するすべてのトレース・データおよびデバッグ・データを
収集します
© 2015 IBM Corporation
クラスターの設定確認（1）
￭クラスターの設定確認コマンド
▶ クラスター全体の設定確認
–
lsrcrc –c IBM.PeerNode
▶ リソースの設定確認
–
35
lsrsrc <リソースクラス>
# lsrsrc -c IBM.PeerNode
Resource Class Persistent Attributes
resource 1:
CommittedRSCTVersion
=
ActiveVersionChanging
=
OpQuorumOverride
=
CritRsrcProtMethod
=
OpQuorumTieBreaker
=
QuorumType
=
QuorumGroupName
=
Fanout
=
OpFenceGroup
=
NodeCleanupCommand
=
NodeCleanupCriteria
=
QuorumLessStartupTimeout
=
CriticalMode
=
NotifyQuorumChangedCommand =
NamePolicy
=
for IBM.PeerNode
""
0
0
3
"mynetworktb"
0
""
32
""
""
""
120
1
""
0
: リソースの設定を表示します
リソースクラス
説明
IBM.ServiceIP
サービス IP アドレスの定義
IBM.AgFileSystem
ファイルシステムの定義
IBM.Application
アプリケーションの定義
IBM.TieBreaker
タイブレーカーの定義
IBM.HeartbeatInterface
ディスク・ハートビートの定義
© 2015 IBM Corporation
クラスターの設定確認（2）
▶ リソース・グループ (RG) の設定確認
–
–
lsrg -Ab
lsrg –mg <RG名>
: リソース・グループの設定を表示します
: リソース・グループのリソース設定を表示します
▶ 依存関係の設定確認
–
lsrel –Ab
: 依存関係の設定を表示します
▶ 同値の設定確認
–
lsequ–Ab
: 同値の設定を表示します
▶ コミュニケーショングループ (CG) の設定確認
–
–
–
36
lscomg
lscomg –i <CG名>
lscomg –l
: CG をリスト表示します
: CG のネットワーク情報を表示します
: CG の設定を表示します
© 2015 IBM Corporation
TSA の動作確認テスト
37
© 2015 IBM Corporation
テスト項目（1）
￭正常操作確認テスト
38
項番
テストケース
操作
補足
1-1
クラスターの起動 / 停止
sartrpdomain sa_domain
stoprpdomain sa_domain
クラスターが Online /
Offline になる
1-2
リソース・グループの起動 / 停止
chrg –o online rg1
chrg –o offline rg1
リソース・グループの起
動 / 停止時にリソースが
獲得 / 開放される
1-3
手動でのテークオーバー
rgreq –o move rg1
移動先ノードでリソース
が獲得される
© 2015 IBM Corporation
テスト項目（2）
￭障害時の挙動確認テスト（1/2）
39
項番
テストケース
操作
補足
2-1
VIOS1-1 FC片パス障害
FCケーブル 1本抜線
VIOS 上でマルチパスデ
バイスドライバがパスを
切り替える
2-2
VIOS1-1 FC全パス障害
FCケーブル 2本抜線
ノード上でマルチパスデ
バイスドライバがパスを
切り替える
2-3
VIOS1-1, 1-2 FC全パス障害
FCケーブル 4本抜線
障害 VIOS 上のノードが
停止してリソース・グ
ループがテークオーバー
する
2-4
VIOS1-1 NWポート障害
Ethernetケーブル 1本抜線
SEA Failover により
VIOS1-2 に経路が切り替
わる
2-5
VIOS1-1, 1-2 NWポート障害
Ethernetケーブル 2本抜線
障害 VIOS 上のノードが
NW 障害を検知してリ
ソース・グループがテー
クオーバーする
© 2015 IBM Corporation
テスト項目（3）
￭障害時の挙動確認テスト（2/2）
40
項番
テストケース
操作
補足
2-6
アプリケーション・プロセス障害
httpd プロセス Kill
自ノード上でプロセスが
再起動される
2-7
ノード障害
HMC からノード強制停止
スタンバイノードが障害
を検知してリソース・グ
ループがテークオーバー
する
2-8
VIOS1-1 障害
HMC から VIOS 強制停止
ノード上でマルチパスデ
バイスドライバがパスを
切り替える
SEA Failover により
VIOS1-2 に経路が切り替
わる
2-9
VIOS1-1, 1-2 両系障害
HMC から VIOS 強制停止
スタンバイノードが障害
を検知してリソース・グ
ループがテークオーバー
する
© 2015 IBM Corporation
テスト結果 1-1 - クラスターの起動/停止
￭テストケース：
▶ ノード1 からクラスターを起動
– # startrpdomain sa_domain を実行
▶ ノード1 からクラスターを停止
– # stoprpdomain sa_domain を実行
￭初期状態
▶ ドメインが停止された状態
￭期待される結果：
▶ 起動後に lsrpdomain の出力の OpState が Online になること
▶ 停止後に lsrpdomain の出力の OpState が Offline になること
￭テスト後のステータス：
▶ 起動後に OpState が Online になることを確認
▶ 停止後に OpState が Offline になることを確認
41
© 2015 IBM Corporation
テスト結果 1-2 – リソース・グループの起動/停止
￭テストケース：
▶ ノード1 からリソース・グループを起動
– # chrg –o online rg1 を実行
▶ ノード1 からリソース・グループを停止
– # chrg –o offline rg1 を実行
￭初期状態
▶ ドメインが起動されたがリソース・グループへの要求（Nominal State）は Offline の状態
￭期待される結果：
▶ 起動後に lssam の出力で全てのリソースが1つのノードで Online になること
▶ 停止後に lssam の出力で全てのリソースが Offline になること
￭テスト後のステータス：
▶ 起動後に全てのリソースが Online になることを確認
▶ 停止後に全てのリソースが Offline になることを確認
42
© 2015 IBM Corporation
テスト結果 1-3 – 手動でのテークオーバー
￭テストケース：
▶ ノード1 からリソース・グループの移動を実行
– # rgreq –o move rg1 を実行
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭期待される結果：
▶ 移動後に lssam の出力で全てのリソースがもう一方のノードで Online になること
￭テスト後のステータス：
▶ 移動前に node1 で Online だったリソースがコマンド実行後に node 2 で Online になるこ
とを確認
43
© 2015 IBM Corporation
テスト結果 2-1 – VIOS1-1 FC 片パス障害
￭テストケース：
▶ VIOS1-1 にて FCケーブルを 1本抜線
▶ 期待される結果：VIOS 上でパスフェールオーバーが発生し、TSA クラスターではエラーは検知さ
れない
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、VIOS の SDDPCM にて片バスへの切り替わりが発生し、TSA クラスター
上ではエラーは検知されないことを確認
$ lspath -dev hdisk21
status name
parent connection
Failed
Failed
Enabled
Enabled
hdisk21
hdisk21
hdisk21
hdisk21
fscsi0
fscsi0
fscsi1
fscsi1
該当ディスクのパスが
Failed になる
5005076802105424,f000000000000
5005076802105425,f000000000000
5005076802205424,f000000000000
5005076802205425,f000000000000
￭障害復旧手順：
▶ VIOS1-1 の FC ケーブルを復旧することで VIOS の SDDPCM がパス復旧を検知して障害から回復
することを確認
44
© 2015 IBM Corporation
テスト結果 2-2 – VIOS1-1 FC 全パス障害
￭テストケース：
▶ VIOS1-1 にて FCケーブルを 2本抜線
▶ 期待される結果：RHEL 上でパスフェールオーバーが発生し、TSA クラスターではエラーは検知されない
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、RHEL 上の Device Mapper Multipath にて片バスへの切り替わりが発生し、TSA
クラスター上ではエラーは検知されないことを確認
# multipath -ll
…中略…
mpatha (36005076802808189b4000000000001ec) dm-1 AIX
,VDASD
size=50G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
|- 0:0:2:0 sdb 8:16 failed faulty running
`- 1:0:2:0 sde 8:64 active ready running
該当ディスクのパスが
Failed になる
￭障害復旧手順：
▶ VIOS1-1 の FC ケーブルを復旧することで RHEL がパス復旧を検知して障害から回復することを確認
45
© 2015 IBM Corporation
テスト結果 2-3 – VIOS1-1,1-2 FC 全パス障害
￭テストケース：
▶ VIOS1-1, 1-2 にて FCケーブルを 2本抜線
▶ 期待される結果：TSA クラスターが share_fs リソースの障害を検知し、node1 から node2 にテークオー
バーが発生
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、TSA が障害を検知し、node2 へのテークオーバーが発生したことを lssam コマン
ドにて確認
# lssam
Online IBM.ResourceGroup:rg1 Control=MemberInProblemState Nominal=Online
|- Online IBM.AgFileSystem:share_fs Control=MemberInProblemState
|- Online IBM.AgFileSystem:share_fs:node2
'- Failed offline IBM.AgFileSystem:share_fs:node1 Node=Offline
…以下略…
MemberInProblemStateになり
リソースが node1 で Offline なる
￭障害復旧手順：
▶ VIOS1-1, 1-2 の FC ケーブルを復旧し、node1 を再起動することで node1 が Online になることを確認
▶ リソース・グループの手動でのテークオーバーにより node1 でリソース・グループが Online になること
を確認
46
© 2015 IBM Corporation
テスト結果 2-4 – VIOS1-1 NW ポート障害
￭テストケース：
▶ VIOS1-1 にて 192.168.1/24 の NW ケーブルを抜線
▶ 期待される結果：VIOS にて SEA の Failover が発生し、VIOS1-2 経由の通信となり、TSA
クラスターではエラーは検知されない
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、 SEA Failover により VIOS1-2 へのテークオーバーが発生したこ
とを確認
VIOS1-2 $ errlog
…中略…
E48A73A4
1216162215 I H ent5
SEA の切り替わりが
発生
BECOME PRIMARY
￭障害復旧手順：
▶ VIOS1-1 の NW ケーブルを復旧することで VIOS1-1 へ Failback が発生し、障害から回復
することを確認
47
© 2015 IBM Corporation
テスト結果 2-5 – VIOS1-1,1-2 NW ポート障害
￭テストケース：
▶ VIOS1-1, 1-2 にて 192.168.1/24 の NW ケーブルを抜線
▶ 期待される結果： TSA クラスターが node1 で 192.168.1/24 の障害を検知し、サービス
IP 引継ぎのために node1 から node2 に全リソースのテークオーバーが発生
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、 TSA が障害を検知し、node2 へのテークオーバーが発生したこと
を lssam コマンドにて確認
￭障害復旧手順：
▶ VIOS1-1, 1-2 の NW ケーブルを復旧し、node1 を再起動することで node1 が Online に
なることを確認
▶ リソース・グループの手動でのテークオーバーにより node1 でリソース・グループが
Online になることを確認
48
© 2015 IBM Corporation
テスト結果 2-6 – アプリケーション・プロセス障害
￭テストケース：
▶ node1 にて httpd プロセスを全て Kill
▶ 期待される結果： TSA クラスターが httpd リソースの障害を検知し、node1 上でプロセスの再起
動が発生
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、 TSA が障害を検知し、node1 上でプロセスの再起動が発生したことを ps
コマンドにて確認
# tail -f /var/log/messages
Dec
Dec
Dec
Dec
Dec
Dec
16
16
16
16
16
16
17:48:11
17:48:11
17:48:11
17:48:11
17:48:27
17:48:27
node1
node1
node1
node1
node1
node1
httpd の障害を
検知し再起動
systemd: httpd.service: main process exited, code=killed, status=9/KILL
kill: kill: cannot find process ""
systemd: httpd.service: control process exited, code=exited status=1
systemd: Unit httpd.service entered failed state.
systemd: Starting The Apache HTTP Server...
systemd: Started The Apache HTTP Server.
￭障害復旧手順：
▶ 復旧手順は不要
49
© 2015 IBM Corporation
テスト結果 2-7 – ノード障害
￭テストケース：
▶ HMC から node1 を強制停止
▶ 期待される結果：TSA クラスターが node1 の障害を検知し、node1 から node2 にテークオーバーが発生
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、TSA が障害を検知し、node2 へのテークオーバーが発生したことを lssam コマン
ドにて確認
# lssam
Online IBM.ResourceGroup:rg1 Control=MemberInProblemState Nominal=Online
|- Online IBM.AgFileSystem:share_fs Control=MemberInProblemState
|- Online IBM.AgFileSystem:share_fs:node2
'- Failed offline IBM.AgFileSystem:share_fs:node1 Node=Offline
…以下略…
MemberInProblemStateになり
リソースが node1 で Offline なる
￭障害復旧手順：
▶ node1 を再起動することで node1 が Online になることを確認
▶ リソース・グループの手動でのテークオーバーにより node1 でリソース・グループが Online になること
を確認
50
© 2015 IBM Corporation
テスト結果 2-8 – VIOS1-1 障害
￭テストケース：
▶ HMC から VIOS1-1 を強制停止
▶ 期待される結果：ネットワークは SEA Failover により VIOS1-2 へ切り替わり、ストレー
ジは RHEL 上でパス障害を検知し、TSA クラスターではエラーは検知されない
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、SEA Failover によりネットワークは VIOS1-2 へ切り替わり、スト
レージは RHEL 上でパスの切り替わりが発生し、TSA クラスター上ではエラーは検知され
ないことを確認
￭障害復旧手順：
▶ VIOS1-1 の NW ケーブルを復旧することで VIOS1-1 へ Failback が発生し、障害から回復
することを確認
▶ VIOS1-1 の FC ケーブルを復旧することで RHEL がパス復旧を検知して障害から回復する
ことを確認
51
© 2015 IBM Corporation
テスト結果 2-9 – VIOS1-1, 1-2 障害
￭テストケース：
▶ HMC から VIOS1-1, 1-2 を強制停止
▶ 期待される結果：TSA クラスターが node1 の障害を検知し、 node1 から node2 にテー
クオーバーが発生
￭初期状態
▶ 正常稼働状態（ドメインは起動、リソース・グループは node1 にて Online）
￭障害発生後のステータス：
▶ 期待される結果どおり、TSA が障害を検知し、node2 へのテークオーバーが発生したこと
を lssam コマンドにて確認
￭障害復旧手順：
▶ VIOS1-1, 1-2 を再起動し、その後 node1 を再起動することで node1 が Online になるこ
とを確認
▶ リソース・グループの手動でのテークオーバーにより node1 でリソース・グループが
Online になることを確認
52
© 2015 IBM Corporation
スプリットブレインについて
53
© 2015 IBM Corporation
スプリットブレインと Quorum について
￭スプリットブレインとは、ネットワーク障害などにより、クラスターを構成する
ノードが複数の孤立した島に分かれる状況のことを言います。
▶ この状態で、異なる島のノードがそれぞれにサービスを起動しようとすると、共有リソース
が破壊される恐れが生じます。
￭ Quorum （ノード定足数）とは、スプリットブレインが発生した際に、特定の島だけ
がサービスを継続する仕組みです。
▶ TSA の場合は、原則的には、ノード数が全体の過半数を超える島がサービスを継続します。
▶ ただし、2 ノード構成で 1 対 1 に分かれた場合や、偶数ノード構成でちょうど半分に
分かれた場合は、タイブレーカーを利用して、サービスを継続するノードを決定します。
Ethernet
node01
ノード数 2
node02
共有ディスク
node03
ノード数 1
ノード数が過半数を超える左の島
がサービスを継続する。
54
© 2015 IBM Corporation
2ノード構成の場合の動作
￭ 2ノード構成の場合はタイブレーカーが必須となります
￭ 2ノード構成でスプリットブレインが発生した場合、各ノードは図の動作を行います
▶ 一方のノードのみがタイブレーカーへのアクセスに成功するため、どちらかのノードでサー
ビスが継続されます
▶ タイブレーカーへのアクセスの成功/失敗はタイブレーカーの種類により判定基準が異なり
ます
▶ (*) Online のノードがタイブレーカーへのアクセスに失敗した際の動作は、
CritRsrcProtMethod パラメーターで変更可能です。
–
–
# lsrsrc -c IBM.PeerNode CritRsrcProtMethod
# chrsrc -c IBM.PeerNode CritRsrcProtMethod=3
: 設定値の確認
: 設定値の変更
CirtRsrcProtMethod の設定値
Hard reset and reboot operating system (default)
1
Halt operating system
2
Hard reset and reboot operating system with Sync
3
Halt with Sync
4
No protection. System continues operating
5
Exit and restart RSCT subsystems
6
リソースが Online のノード
一定間隔で繰り返し
No
ノードを強制再起動して(*)
リソースを Offline に変更
55
リソースが Offline のノード
タイブレーカーへアクセスに
成功したか？
Yes
リソースは Online のままで
サービスを継続
タイブレーカーへのアクセスに
成功したか？
Yes
リソースを Online に変更して
サービスを提供開始
© 2015 IBM Corporation
No
Linux on Power でのタイブレーカー
56
© 2015 IBM Corporation
Linux on Power上でのタイブレーカー
￭ TSA でのディスク・タイブレーカー
▶ TSA でのディスク・タイブレーカーのデバイスとしては ECKD, SCSI, AIX hdisk,
SCSI 永続予約を使用できます
▶ Linux 上でマルチパスデバイスをディスク・タイブレーカーとするためには SCSI 永続予約
を使用する必要があります
▶ しかしながら、Linux on Power では SCSI 永続予約の使用がサポートされません
Linux on Power ではマルチパスデバイスをタイブレーカーに指定できないため
ネットワーク・タイブレーカーを使用することをお勧めします
57
© 2015 IBM Corporation
参考情報
58
© 2015 IBM Corporation
参考文献
￭ Tivoli System Automation for Multiplatoforms 4.1 製品マニュアル
•
http://www.ibm.com/support/knowledgecenter/SSRM2X_4.1.0.2/com.ibm.samp.doc_4.1.0.2/welcome_samp.html
￭ FixPack ダウンロード・リンク
•
https://www.ibm.com/support/entry/portal/all_download_links/tivoli/tivoli_system_automation_for_multiplatforms
￭ Tivoli System Automation for Multiplatoforms 4.1 前提 OS レベル
•
59
http://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/osForProduct?deliverableId=1334234372419
© 2015 IBM Corporation
Open innovation to put data to work
60
© 2014 International Business Machines Corporation
© 2015 IBM Corporation

Download Report