Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand

HP Serviceguard クラスター構築手順

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む

8. クラスターの構成

基本的な準備が整ったので、いよいよServiceguardクラスターの構築を行います。ここではまずアプリケーションを持たない空のクラスターを作成します。次章でアプリケーションをパッケージという形でクラスターに組み込みます。作業はノードfred上で行うものとします。
HP Serviceguard クラスター構築手順
はじめに
1.システム構成
2.OSのインストール
3.OSボリュームのミラー化
4.データディスクの設定
5.Serviceguard クラスターの構築
6.ネットワークタイムプロトコルの使用
7.共有ディスク上のファイルシステムの作成
8.クラスターの構成
9.パッケージの作成
10.クラスターの管理
11.リソースの場所

8.1. クラスター構成ファイルのテンプレートの作成

コマンド cmquerycl を使用してクラスター構成ファイルのテンプレートを作成します。

# cmquerycl -v -C /etc/cmcluster/cmclconfig.ascii -n fred -n ginger

-nオプションでクラスターを構成するノードを指定します。cmqueryclコマンドはハードウェア構成をチェックし、-Cオプションで指定されたクラスター構成ファイルのテンプレート/etc/cmcluster/cmclconfig.asciiを作成します。これはテキストファイルで、次のような内容が記述されています。

# **********************************************************************
# ********* HIGH AVAILABILITY CLUSTER CONFIGURATION FILE ***************
# ***** For complete details about cluster parameters and how to *******
# ***** set them, consult the Serviceguard manual. *********************
# **********************************************************************

# Enter a name for this cluster.  This name will be used to identify the
# cluster when viewing or manipulating it.

CLUSTER_NAME		cluster1


# Cluster Lock Parameters
# The cluster lock is used as a tie-breaker for situations
# in which a running cluster fails, and then two equal-sized
# sub-clusters are both trying to form a new cluster.  The
# cluster lock may be configured using only one of the
# following alternatives on a cluster: 
#          the LVM lock disk
#          the lock LUN
#          the quorom server
#
#
# Consider the following when configuring a cluster.
# For a two-node cluster, you must use a cluster lock.  For
# a cluster of three or four nodes, a cluster lock is strongly
# recommended.  For a cluster of more than four nodes, a
# cluster lock is recommended.  If you decide to configure
# a lock for a cluster of more than four nodes, it must be
# a quorum server.

# Lock Disk Parameters.  Use the FIRST_CLUSTER_LOCK_VG and
# FIRST_CLUSTER_LOCK_PV parameters to define a lock disk.
# The FIRST_CLUSTER_LOCK_VG is the LVM volume group that
# holds the cluster lock. This volume group should not be
# used by any other cluster as a cluster lock device.  

# LUN lock disk parameters. Use the  CLUSTER_LOCK_LUN parameter
# to define the device on a per node basis. The device may only
# be used for this purpose and by only a single cluster.
#
# Example for a FC storage array cluster disk
# CLUSTER_LOCK_LUN /dev/dsk/c1t2d3s1
# For 11.31 and later versions of HP-UX
# CLUSTER_LOCK_LUN /dev/disk/disk4_p2

# Quorum Server Parameters. Use the QS_HOST, QS_ADDR, QS_POLLING_INTERVAL,
# and QS_TIMEOUT_EXTENSION parameters to define a quorum server. The QS_HOST
# and QS_ADDR are either the host name or IP address of the system that is
# running the quorum server process. More than one IP address can be
# configured for the quorum server. When one subnet fails, Serviceguard
# uses the next available subnet to communicate with the quorum server.
# QS_HOST is used to specify the quorum server and QS_ADDR can be used to
# specify additional IP addresses for the quorum server. The QS_HOST entry
# must be specified (only once) before any other QS parameters. Only 
# one QS_ADDR entry is used to specify the additionalIP address.
# Both QS_HOST and QS_ADDR should not resolve to the same IP address.
# Otherwise cluster configuration will fail. All subnets must be up 
# when you use cmapplyconf and cmquerycl to configure the cluster.
# The QS_POLLING_INTERVAL is the interval (in microseconds) at which
# Serviceguard checks to sure the quorum server is running. You can use
# the optional QS_TIMEOUT_EXTENSION to increase the time interval (in
# microseconds) after which the quorum server is marked DOWN.
# 
# The default quorum server timeout is calculated from the
# Serviceguard cluster parameters, including NODE_TIMEOUT and
# HEARTBEAT_INTERVAL.  If you are experiencing quorum server
# timeouts, you can adjust these parameters, or you can include
# the QS_TIMEOUT_EXTENSION parameter.
#
# The value of QS_TIMEOUT_EXTENSION will directly effect the amount of
# time it takes for cluster reformation in the event of failure. For
# example, if QS_TIMEOUT_EXTENSION is set to 10 seconds, the cluster
# reformation will take 10 seconds longer than if the QS_TIMEOUT_EXTENSION
# was set to 0. This delay applies even if there is no delay in contacting
# the Quorum Server.  The recommended value for QS_TIMEOUT_EXTENSION is 0,
# which is used as the default and the maximum supported value is 30000000
# (5 minutes).
#
# For example, to configure a quorum server running on node "qs_host"
# with the additional IP address "qs_addr" and with 120 seconds for the
# QS_POLLING_INTERVAL and to add 2 seconds to the system assigned value
# for the quorum server timeout, enter
#
# QS_HOST qs_host
# QS_ADDR qs_addr
# QS_POLLING_INTERVAL 120000000
# QS_TIMEOUT_EXTENSION 2000000

FIRST_CLUSTER_LOCK_VG		/dev/vgdata


# Definition of nodes in the cluster.
# Repeat node definitions as necessary for additional nodes.
# NODE_NAME is the specified nodename in the cluster.
# It must match the hostname and both cannot contain full domain name.
# Each NETWORK_INTERFACE, if configured with IPv4 address,
# must have ONLY one IPv4 address entry with it which could 
# be either HEARTBEAT_IP or STATIONARY_IP.
# Each NETWORK_INTERFACE, if configured with IPv6 address(es)
# can have multiple IPv6 address entries(up to a maximum of 2,
# only one IPv6 address entry belonging to site-local scope
# and only one belonging to global scope) which must be all
# STATIONARY_IP. They cannot be HEARTBEAT_IP. 


NODE_NAME			fred
  NETWORK_INTERFACE	lan0
    HEARTBEAT_IP		192.39.51.91
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    STATIONARY_IP		192.168.0.10
  NETWORK_INTERFACE	lan8
    STATIONARY_IP		192.168.1.11
#  CLUSTER_LOCK_LUN	
  FIRST_CLUSTER_LOCK_PV	/dev/dsk/c4t0d0

# Possible standby Network Interfaces for lan0: lan4.
# Warning: There are no standby network interfaces for lan1,lan8.

NODE_NAME			ginger
  NETWORK_INTERFACE	lan0
    HEARTBEAT_IP		192.39.51.92
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    STATIONARY_IP		192.168.0.20
  NETWORK_INTERFACE	lan8
    STATIONARY_IP		192.168.1.21
#  CLUSTER_LOCK_LUN	
  FIRST_CLUSTER_LOCK_PV	/dev/dsk/c4t0d0

# Possible standby Network Interfaces for lan0: lan4.
# Warning: There are no standby network interfaces for lan1,lan8.


# Cluster Timing Parameters (microseconds).

# The NODE_TIMEOUT parameter defaults to 2000000 (2 seconds).
# This value is recommended for installations in which the highest
# priority is to reform the cluster as fast as possible in
# case of failure. But this value can sometimes lead to reformations
# caused by short-lived system hangs or network load spikes.  If your
# highest priority is to minimize reformations, consider using
# a higher setting. For a significant portion of installations,
# a setting of 5000000 to 8000000 (5 to 8 seconds) is appropriate.
# The maximum value recommended for NODE_TIMEOUT is 30000000
# (30 seconds).

HEARTBEAT_INTERVAL	1000000
NODE_TIMEOUT		2000000


# Configuration/Reconfiguration Timing Parameters (microseconds).

AUTO_START_TIMEOUT		600000000
NETWORK_POLLING_INTERVAL	2000000

# Network Monitor Configuration Parameters.
# The NETWORK_FAILURE_DETECTION parameter determines how LAN card failures are detected.
# If set to INONLY_OR_INOUT, a LAN card will be considered down when its inbound
# message count stops increasing or when both inbound and outbound
# message counts stop increasing.
# If set to INOUT, both the inbound and outbound message counts must
# stop increasing before the card is considered down.
NETWORK_FAILURE_DETECTION		INOUT

# Package Configuration Parameters.
# Enter the maximum number of packages which will be configured in the cluster.
# You can not add packages beyond this limit.
# This parameter is required.
MAX_CONFIGURED_PACKAGES		150


# Access Control Policy Parameters.
#
# Three entries set the access control policy for the cluster:
# First line must be USER_NAME, second USER_HOST, and third USER_ROLE.
# Enter a value after each. 
#
# 1. USER_NAME can either be ANY_USER, or a maximum of 
#    8 login names from the /etc/passwd file on user host.
#    The following special characters are NOT supported for USER_NAME
#    ' ', '/', '\', '*'
# 2. USER_HOST is where the user can issue Serviceguard commands. 
#    If using Serviceguard Manager, it is the COM server.
#    Choose one of these three values: ANY_SERVICEGUARD_NODE, or 
#    (any) CLUSTER_MEMBER_NODE, or a specific node. For node, 
#    use the official hostname from domain name server, and not 
#    an IP addresses or fully qualified name.
# 3. USER_ROLE must be one of these three values:
#    * MONITOR: read-only capabilities for the cluster and packages
#    * PACKAGE_ADMIN: MONITOR, plus administrative commands for packages
#      in the cluster
#    * FULL_ADMIN: MONITOR and PACKAGE_ADMIN plus the administrative
#      commands for the cluster.
#
# Access control policy does not set a role for configuration 
# capability. To configure, a user must log on to one of the
# cluster's nodes as root (UID=0). Access control 
# policy cannot limit root users' access.
# 
# MONITOR and FULL_ADMIN can only be set in the cluster configuration file, 
# and they apply to the entire cluster. PACKAGE_ADMIN can be set in the  
# cluster or a package configuration file. If set in the cluster 
# configuration file, PACKAGE_ADMIN applies to all configured packages. 
# If set in a package configuration file, PACKAGE_ADMIN applies to that
# package only.
# 
# Conflicting or redundant policies will cause an error while applying 
# the configuration, and stop the process. The maximum number of access
# policies that can be configured in the cluster is 200.
#
# Example: to configure a role for user john from node noir to
# administer a cluster and all its packages, enter:
# USER_NAME  john
# USER_HOST  noir
# USER_ROLE  FULL_ADMIN


# List of cluster aware LVM Volume Groups. These volume groups will
# be used by package applications via the vgchange -a e command.
# Neither CVM or VxVM Disk Groups should be used here.
# For example: 
# VOLUME_GROUP		/dev/vgdatabase
# VOLUME_GROUP		/dev/vg02

VOLUME_GROUP		/dev/vgdata

このテンプレートファイルを編集して、実際のクラスターの構成にあわせます。編集すべき項目として以下のものがあります。

  1. クラスターロックディスクの指定
  2. クォーラムサーバーの指定
  3. 使用するアプリケーションパッケージ数の指定
  4. その他のパラメータの指定

1.と2.はユーザがどちらか一方を選択するものです。つまり、クラスターのタイブレーカとしてクラスターロックディスクを使用するか、クォーラムサーバーを使用するかを決定し、クラスターロックディスクを使用する場合には1を、クォーラムサーバーを使用する場合には2の作業を行います。クラスターロックディスクとクォーラムサーバーを同時に使用することはできません。

8.2. クラスターロックディスクを使用する場合

クラスターロックディスクはクラスター内の全てのノードからアクセス可能なボリュームグループ上に設定します。2ノードクラスターでは必須、3ノードクラスターでは推奨、4ノードクラスターではオプショナル、5ノード以上のクラスターではサポートされません。ここではすでにクラスターのノードfredとgingerからアクセス可能な/dev/vgdataというボリュームグループが存在するのでこれをクラスターロックディスクにしてもよいのですが(クラスターロックディスクはボリュームグループのヘッダ情報のみを使用するため、実際にデータを置くボリュームグループをクラスターロックディスクとして指定してもかまいません)、ここではクラスターロックディスクのための専用のボリュームグループ/dev/vglockを作成することにします。作成方法は/dev/vgdataを作成したときとほぼ同様です。

ノードfred上で以下の作業を行います。

# mkdir /dev/vglock
# mknod /dev/vglock/group -c 64 0xhh0000

ここで hh が他の group ファイルのものと重複しないようにします。

# pvcreate /dev/rdsk/c4t0d1
# vgcreate /dev/vglock /dev/dsk/c4t0d1
# vgchange -a n /dev/vglock
# vgexport -p -s -m /tmp/vglock.map /dev/vglock
# rcp /tmp/vglock.map ginger:/tmp/vglock.map

/dev/vglockに対しては、PV-linkの指定を行っていないことに注意してください。Serviceguardクラスターはクラスターロックディスクにアクセスする際、上で定義した物理ボリューム/dev/dsk/c4t0d1に直接アクセスします。代替パス/dev/dsk/c6t0d1は使用しません。そのためPV-linkの設定は必要ありません。

マップファイル/tmp/vglock.mapをgingerにコピーしたので、今度はノードgingerで以下の作業を行います。

# mkdir /dev/vglock
# mknod /dev/vglock/group -c 64 0xhh0000

ここでもhhが他のgroupファイルのものと重複しないようにします。

# vgimport -s -m /tmp/vglock.map /dev/vglock

これでクラスターロックディスク用のボリュームグループ/dev/vglockの設定は終了しました。

この情報をクラスター構成ファイルのテンプレートに書き込みます。太字で示した行がクラスターロックディスクの指定です。

# Cluster Lock Parameters
# The cluster lock is used as a tie-breaker for situations
# in which a running cluster fails, and then two equal-sized
# sub-clusters are both trying to form a new cluster.  The
# cluster lock may be configured using only one of the
# following alternatives on a cluster: 
#          the LVM lock disk
#          the lock LUN
#          the quorom server
#
#
# Consider the following when configuring a cluster.
# For a two-node cluster, you must use a cluster lock.  For
# a cluster of three or four nodes, a cluster lock is strongly
# recommended.  For a cluster of more than four nodes, a
# cluster lock is recommended.  If you decide to configure
# a lock for a cluster of more than four nodes, it must be
# a quorum server.

# Lock Disk Parameters.  Use the FIRST_CLUSTER_LOCK_VG and
# FIRST_CLUSTER_LOCK_PV parameters to define a lock disk.
# The FIRST_CLUSTER_LOCK_VG is the LVM volume group that
# holds the cluster lock. This volume group should not be
# used by any other cluster as a cluster lock device.  

# LUN lock disk parameters. Use the  CLUSTER_LOCK_LUN parameter
# to define the device on a per node basis. The device may only
# be used for this purpose and by only a single cluster.
#
# Example for a FC storage array cluster disk
# CLUSTER_LOCK_LUN /dev/dsk/c1t2d3s1
# For 11.31 and later versions of HP-UX
# CLUSTER_LOCK_LUN /dev/disk/disk4_p2

# Quorum Server Parameters. Use the QS_HOST, QS_ADDR, QS_POLLING_INTERVAL,
# and QS_TIMEOUT_EXTENSION parameters to define a quorum server. The QS_HOST
# and QS_ADDR are either the host name or IP address of the system that is
# running the quorum server process. More than one IP address can be
# configured for the quorum server. When one subnet fails, Serviceguard
# uses the next available subnet to communicate with the quorum server.
# QS_HOST is used to specify the quorum server and QS_ADDR can be used to
# specify additional IP addresses for the quorum server. The QS_HOST entry
# must be specified (only once) before any other QS parameters. Only 
# one QS_ADDR entry is used to specify the additionalIP address.
# Both QS_HOST and QS_ADDR should not resolve to the same IP address.
# Otherwise cluster configuration will fail. All subnets must be up 
# when you use cmapplyconf and cmquerycl to configure the cluster.
# The QS_POLLING_INTERVAL is the interval (in microseconds) at which
# Serviceguard checks to sure the quorum server is running. You can use
# the optional QS_TIMEOUT_EXTENSION to increase the time interval (in
# microseconds) after which the quorum server is marked DOWN.
# 
# The default quorum server timeout is calculated from the
# Serviceguard cluster parameters, including NODE_TIMEOUT and
# HEARTBEAT_INTERVAL.  If you are experiencing quorum server
# timeouts, you can adjust these parameters, or you can include
# the QS_TIMEOUT_EXTENSION parameter.
#
# The value of QS_TIMEOUT_EXTENSION will directly effect the amount of
# time it takes for cluster reformation in the event of failure. For
# example, if QS_TIMEOUT_EXTENSION is set to 10 seconds, the cluster
# reformation will take 10 seconds longer than if the QS_TIMEOUT_EXTENSION
# was set to 0. This delay applies even if there is no delay in contacting
# the Quorum Server.  The recommended value for QS_TIMEOUT_EXTENSION is 0,
# which is used as the default and the maximum supported value is 30000000
# (5 minutes).
#
# For example, to configure a quorum server running on node "qs_host"
# with the additional IP address "qs_addr" and with 120 seconds for the
# QS_POLLING_INTERVAL and to add 2 seconds to the system assigned value
# for the quorum server timeout, enter
#
# QS_HOST qs_host
# QS_ADDR qs_addr
# QS_POLLING_INTERVAL 120000000
# QS_TIMEOUT_EXTENSION 2000000

FIRST_CLUSTER_LOCK_VG		/dev/vglock


# Definition of nodes in the cluster.
# Repeat node definitions as necessary for additional nodes.
# NODE_NAME is the specified nodename in the cluster.
# It must match the hostname and both cannot contain full domain name.
# Each NETWORK_INTERFACE, if configured with IPv4 address,
# must have ONLY one IPv4 address entry with it which could 
# be either HEARTBEAT_IP or STATIONARY_IP.
# Each NETWORK_INTERFACE, if configured with IPv6 address(es)
# can have multiple IPv6 address entries(up to a maximum of 2,
# only one IPv6 address entry belonging to site-local scope
# and only one belonging to global scope) which must be all
# STATIONARY_IP. They cannot be HEARTBEAT_IP. 


NODE_NAME			fred
  NETWORK_INTERFACE	lan0
    HEARTBEAT_IP		192.39.51.91
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    STATIONARY_IP		192.168.0.10
  NETWORK_INTERFACE	lan8
    STATIONARY_IP		192.168.1.11
#  CLUSTER_LOCK_LUN	
  FIRST_CLUSTER_LOCK_PV	/dev/dsk/c4t0d1

# Possible standby Network Interfaces for lan0: lan4.
# Warning: There are no standby network interfaces for lan1,lan8.

NODE_NAME			ginger
  NETWORK_INTERFACE	lan0
    HEARTBEAT_IP		192.39.51.92
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    STATIONARY_IP		192.168.0.20
  NETWORK_INTERFACE	lan8
    STATIONARY_IP		192.168.1.21
#  CLUSTER_LOCK_LUN	
  FIRST_CLUSTER_LOCK_PV	/dev/dsk/c4t0d1

# Possible standby Network Interfaces for lan0: lan4.
# Warning: There are no standby network interfaces for lan1,lan8.


パラメータFIRST_CLUSTER_LOCK_PVの指定は、ノードfredとgingerの両側から行います。ノードが異なるとディスクの物理ボリューム名が異なることがあるので注意してください。

8.3. クォーラムサーバーを使用する場合

クォーラムサーバーは、役割としてはクラスターロックディスクと全く同様のタイブレーカです。ただし、以下の特徴を持っています。
  1. クォーラムサーバーは、クラスターの外のノードである(クラスターには属さない)。
  2. 1つのクラスターに対して1つのIPアドレスを割り当てる。クラスターはこのIPアドレスを使用してクォーラムサーバーにアクセスする。
  3. クォーラムサーバー上ではクォーラムサーバーのデーモンプロセスがリアルタイムプロセスとして動作する。
  4. クォーラムサーバーを使用する場合、2ノードクラスターでは必須、3ノードクラスターでは推奨、4ノードクラスター以上(5ノード以上のクラスターも含む)ではオプショナルとされている。
  5. クォーラムサーバーのためのハードウェアとしてはHP Integrityサーバー(Itanium ®)、HP 9000サーバー(PA-RISC)、Linuxサーバーがサポートされている。
  6. 1台のクォーラムサーバーで50クラスター、100ノードまでをサポートできる。
  7. クォーラムサーバーはクラスターと同一サブネット上に存在する必要はないが、クラスターがクォーラムサーバーをすばやく獲得するためには同一サブネット上に置いた方がよい。
クォーラムサーバー名をqsとした場合、クラスター構成ファイルのテンプレートを以下のように書き換えます。太字で示した箇所が編集した部分です。なお、qsというノード名のかわりにそれに対応するIPアドレスを記述してもかまいません。

# Cluster Lock Parameters
# The cluster lock is used as a tie-breaker for situations
# in which a running cluster fails, and then two equal-sized
# sub-clusters are both trying to form a new cluster.  The
# cluster lock may be configured using only one of the
# following alternatives on a cluster: 
#          the LVM lock disk
#          the lock LUN
#          the quorom server
#
#
# Consider the following when configuring a cluster.
# For a two-node cluster, you must use a cluster lock.  For
# a cluster of three or four nodes, a cluster lock is strongly
# recommended.  For a cluster of more than four nodes, a
# cluster lock is recommended.  If you decide to configure
# a lock for a cluster of more than four nodes, it must be
# a quorum server.

# Lock Disk Parameters.  Use the FIRST_CLUSTER_LOCK_VG and
# FIRST_CLUSTER_LOCK_PV parameters to define a lock disk.
# The FIRST_CLUSTER_LOCK_VG is the LVM volume group that
# holds the cluster lock. This volume group should not be
# used by any other cluster as a cluster lock device.  

# LUN lock disk parameters. Use the  CLUSTER_LOCK_LUN parameter
# to define the device on a per node basis. The device may only
# be used for this purpose and by only a single cluster.
#
# Example for a FC storage array cluster disk
# CLUSTER_LOCK_LUN /dev/dsk/c1t2d3s1
# For 11.31 and later versions of HP-UX
# CLUSTER_LOCK_LUN /dev/disk/disk4_p2

# Quorum Server Parameters. Use the QS_HOST, QS_ADDR, QS_POLLING_INTERVAL,
# and QS_TIMEOUT_EXTENSION parameters to define a quorum server. The QS_HOST
# and QS_ADDR are either the host name or IP address of the system that is
# running the quorum server process. More than one IP address can be
# configured for the quorum server. When one subnet fails, Serviceguard
# uses the next available subnet to communicate with the quorum server.
# QS_HOST is used to specify the quorum server and QS_ADDR can be used to
# specify additional IP addresses for the quorum server. The QS_HOST entry
# must be specified (only once) before any other QS parameters. Only 
# one QS_ADDR entry is used to specify the additionalIP address.
# Both QS_HOST and QS_ADDR should not resolve to the same IP address.
# Otherwise cluster configuration will fail. All subnets must be up 
# when you use cmapplyconf and cmquerycl to configure the cluster.
# The QS_POLLING_INTERVAL is the interval (in microseconds) at which
# Serviceguard checks to sure the quorum server is running. You can use
# the optional QS_TIMEOUT_EXTENSION to increase the time interval (in
# microseconds) after which the quorum server is marked DOWN.
# 
# The default quorum server timeout is calculated from the
# Serviceguard cluster parameters, including NODE_TIMEOUT and
# HEARTBEAT_INTERVAL.  If you are experiencing quorum server
# timeouts, you can adjust these parameters, or you can include
# the QS_TIMEOUT_EXTENSION parameter.
#
# The value of QS_TIMEOUT_EXTENSION will directly effect the amount of
# time it takes for cluster reformation in the event of failure. For
# example, if QS_TIMEOUT_EXTENSION is set to 10 seconds, the cluster
# reformation will take 10 seconds longer than if the QS_TIMEOUT_EXTENSION
# was set to 0. This delay applies even if there is no delay in contacting
# the Quorum Server.  The recommended value for QS_TIMEOUT_EXTENSION is 0,
# which is used as the default and the maximum supported value is 30000000
# (5 minutes).
#
# For example, to configure a quorum server running on node "qs_host"
# with the additional IP address "qs_addr" and with 120 seconds for the
# QS_POLLING_INTERVAL and to add 2 seconds to the system assigned value
# for the quorum server timeout, enter
#
QS_HOST				qs
# QS_ADDR qs_addr
QS_POLLING_INTERVAL		12000000
QQS_TIMEOUT_EXTENSION		200000
QS_POLLING_INTERVAL		12000000
QS_TIMEOUT_EXTENSION		2000000

# FIRST_CLUSTER_LOCK_VG


# Definition of nodes in the cluster.
# Repeat node definitions as necessary for additional nodes.
# NODE_NAME is the specified nodename in the cluster.
# It must match the hostname and both cannot contain full domain name.
# Each NETWORK_INTERFACE, if configured with IPv4 address,
# must have ONLY one IPv4 address entry with it which could 
# be either HEARTBEAT_IP or STATIONARY_IP.
# Each NETWORK_INTERFACE, if configured with IPv6 address(es)
# can have multiple IPv6 address entries(up to a maximum of 2,
# only one IPv6 address entry belonging to site-local scope
# and only one belonging to global scope) which must be all
# STATIONARY_IP. They cannot be HEARTBEAT_IP. 


NODE_NAME			fred
  NETWORK_INTERFACE	lan0
    HEARTBEAT_IP		192.39.51.91
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    STATIONARY_IP		192.168.0.10
  NETWORK_INTERFACE	lan8
    STATIONARY_IP		192.168.1.11
#  CLUSTER_LOCK_LUN	
#  FIRST_CLUSTER_LOCK_PV

# Possible standby Network Interfaces for lan0: lan4.
# Warning: There are no standby network interfaces for lan1,lan8.

NODE_NAME			ginger
  NETWORK_INTERFACE	lan0
    HEARTBEAT_IP		192.39.51.92
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    STATIONARY_IP		192.168.0.20
  NETWORK_INTERFACE	lan8
    STATIONARY_IP		192.168.1.21
#  CLUSTER_LOCK_LUN	
#  FIRST_CLUSTER_LOCK_PV

# Possible standby Network Interfaces for lan0: lan4.
# Warning: There are no standby network interfaces for lan1,lan8.


ここではクォーラムサーバー名の指定パラメータQS_HOSTのみを書き換え、クラスターがクォーラムサーバーが正常に動作しているかどうかポーリングをかける間隔を指定するパラメータQS_POLLING_INTERVALはデフォルトの120秒に、ポーリングをかけてクォーラムサーバーからの応答がなく、クラスターがクォーラムサーバーがダウンしたと判断するまでの時間を指定するパラメータQS_TIMEOUT_EXTENSIONもデフォルトの2秒のままとしてあります。また、クラスターロックディスク関連のパラメータFIRST_CLUSTER_LOCK_VG、FIRST_CLUSTER_LOCK_PVはコメントアウトしてあります。

8.4. 使用するパッケージ数の指定

クラスター構成ファイルのテンプレートでは、定義可能なアプリケーションパッケージの個数を指定するパラメータMAX_CONFIGURED_PACKAGESが150になっています。このままデフォルトの設定を使用しても構わないのですが、ここではこのパラメータを5と設定します。

# Package Configuration Parameters.
# Enter the maximum number of packages which will be configured in the cluster.
# You can not add packages beyond this limit.
# This parameter is required.
MAX_CONFIGURED_PACKAGES         5

8.5. その他のパラメータの編集

まず、heartbeatメッセージを流すネットワークと流さないネットワークの指定を行います。第1章の「システム構成」で、
  • データ LAN (lan0 と lan4 のプライマリ、スタンバイ構成) には heartbeat メッセージを流さない。
  • lan1 と lan8 は heartbeat 専用 LAN とする。
と定めました。その設定は、クラスター構成ファイルのNODE_NAMEの箇所で太字で示したように指定します。

# Definition of nodes in the cluster.
# Repeat node definitions as necessary for additional nodes.
# NODE_NAME is the specified nodename in the cluster.
# It must match the hostname and both cannot contain full domain name.
# Each NETWORK_INTERFACE, if configured with IPv4 address,
# must have ONLY one IPv4 address entry with it which could
# be either HEARTBEAT_IP or STATIONARY_IP.
# Each NETWORK_INTERFACE, if configured with IPv6 address(es)
# can have multiple IPv6 address entries(up to a maximum of 2,
# only one IPv6 address entry belonging to site-local scope
# and only one belonging to global scope) which must be all
# STATIONARY_IP. They cannot be HEARTBEAT_IP.


NODE_NAME		fred
  NETWORK_INTERFACE	lan0
    STATIONARY_IP		192.39.51.91
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    HEARTBEAT_IP		192.168.0.10
  NETWORK_INTERFACE	lan8
    HEARTBEAT_IP		192.168.1.11

<中略>


NODE_NAME		ginger
  NETWORK_INTERFACE	lan0
    STATIONARY_IP		192.39.51.92
  NETWORK_INTERFACE	lan4
  NETWORK_INTERFACE	lan1
    HEARTBEAT_IP		192.168.0.20
  NETWORK_INTERFACE	lan8
    HEARTBEAT_IP		192.168.1.21

ここで、lan0とlan4の行の間の、

STATIONARY_IP		192.39.51.*

という行は、このネットワークにheartbeatメッセージを流さないようにする指定です。一方、lan1の行の次の、

HEARTBEAT_IP		192.168.0.*

という行と、lan8の行の次の、

HEARTBEAT_IP		192.168.1.*

という行は、これらのネットワークにheartbeatメッセージを流すという指定です。

次にクラスターが使用するボリュームグループの設定を行います。

# List of cluster aware LVM Volume Groups. These volume groups will
# be used by package applications via the vgchange -a e command.
# Neither CVM or VxVM Disk Groups should be used here.
# For example: 
VOLUME_GROUP		/dev/vgdata
VOLUME_GROUP		/dev/vglock

また、必要に応じてheartbeatメッセージの送信間隔を指定するパラメータNODE_TIMEOUT(デフォルト:1秒)、heartbeatメッセージに対する応答がない場合に何秒間たったら、その応答がなかったノードがダウンしたとみなすかを指定するパラメータNODE_TIMEOUT(デフォルト:2秒。このパラメータはHEARTBEAT_INTERVALの2倍以上でなければなりません)ネットワークインターフェースが正常かどうかのポーリングをかける間隔を指定するパラメータNETWORK_POLLING_INTERVAL(デフォルト:2秒)などをカスタマイズしてください。

特に注意すべきパラメータとしてはNODE_TIMEOUTがあります。Serviceguardのマニュアルでは、このパラメータは5〜8秒に設定することを推奨しています。ところが、このパラメータはServiceguardクラスターのフェイルオーバーの際のクラスター再構成時間の決定に関係していて、大きくすればするほど再構成時間が長くなる、つまりフェイルオーバーにかかる時間が長くなり、結果としてサービスの停止時間が長くなってしまうという特徴を持っています。一方短くしすぎると(NODE_TIMEOUTは0.1秒単位で指定可能です)ネットワークに高負荷がかかって、heartbeatの応答がとどかず、誤ったフェイルオーバーが発生してしまう可能性があります。いち早いサービスの切り替えを要求するシステムでは、実際にこのパラメータの値を変更して検証作業を行って適切な値を設定することをお薦めします。

8.6. クラスター構成ファイルの検証

ここまでで実際の構成に合わせたクラスター構成ファイル/etc/cmcluster/cmclconfig.asciiが作成されたことになります。このクラスター構成ファイルを元に、実際にクラスターが使用するバイナリクラスター構成ファイルを作成するわけですが、その前に編集したクラスター構成ファイルの内容に誤りや不整合がないかどうかをcmcheckconfコマンドにより検証します。

# cmcheckconf -v -C /etc/cmcluster/cmclconfig.ascii

これでエラーが出なければ、バイナリクラスター構成ファイルの作成と配布のステップに進みます。

8.7. バイナリクラスター構成ファイルの作成と配布

次の手順でバイナリクラスター構成ファイルの作成と配布を行います。

# vgchange -a y /dev/vglock	(クラスターロックディスク使用の場合のみ)
# cmapplyconf -v -C /etc/cmcluster/cmclconfig.ascii

するとcmapplyconfを実行したノードfred上にバイナリクラスター構成ファイル/etc/cmcluster/cmclconfigが作成され、これがクラスターの他のノードgingerに/etc/cmcluster/cmclconfigとして自動的に配布されます。

クラスターロックディスクを使用している場合には上でアクティブにしたボリュームグループ/dev/vglockを非アクティブ化してください。

# vgchange -a n /dev/vglock

クラスターが正常に起動するかどうかをcmrunclコマンドで確認してください。クラスターが正常に起動しない場合、画面に出力されるメッセージと/var/adm/syslog/syslog.log内のメッセージを参照すると多くの場合、正常起動しない原因がわかります。

# cmruncl -v

クラスターの状態はcmviewclコマンドにより確認できます。

# cmviewcl -v

クラスターの停止はcmhaltclコマンドにより行います。

# cmhaltcl -v

トップへ戻る 前のページへ 次のページへ

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

HPEサポートセンター
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項