資料 Linux女子部 HA Add On v1 0

(1)

第 3 回 Linux 女子部勉強会

60 分で

RHEL6 High Availability アドオンを

徹底的に理解しよう！

V1.0 2012.4.21

中井悦司 / Etsuji Nakai

Senior Solution Architect

and Cloud Evangelist

Red Hat K.K.

(2)

Red Hat K.K. All rights reserved. ₂

自己紹介

第三弾鋭意制作中



中井悦司（なかいえつじ）

●

Twitter @enakai00



_{日々の仕事}

●

Senior Solution Architect and

Cloud Evangelist at Red Hat K.K.

企業システムでオープンソースの活用を希望される

お客様を全力でご支援させていただきます。



_{昔とった杵柄}

●

素粒子論の研究（超弦理論とか）

●

予備校講師（物理担当）

●

インフラエンジニア（ Unix/Linux 専門）

現在 Mountain View に出張中

(3)

自己紹介（本日の講師代打）



平　初（たいら　はじめ）

●

Twitter @htaira



_{日々の仕事}

●

Solution Architect and

Cloud Evangelist at Red Hat K.K.

ご提案の中でオープンソースの活用を希望される

認定パートナー企業を全力でご支援させていただきます。



_{昔とった杵柄}

●

ヘルプデスクコールスタッフ（ PPP 接続設定担当）

●

インフラエンジニア（ Unix/Linux/VMware の火消し専門）

●

ハーフノードサーバーの設計（専用マザーボード設計とか）

●

Microsoft Tech-Ed 講演（ IIS も AD も得意です。ｷﾘ）

(4)

Red Hat K.K. All rights reserved. ₄

_基本情報



_{アーキテクチャ}



_{運用上の注意点}



HA クラスタ設計・構築支援サービスのご紹介



_参考情報

(5)

基本情報

(6)

Red Hat K.K. All rights reserved. ₆

RHEL6 のクラスタ関連アドオン一覧

(*1 ） Resilient Storage のサブスクリプションを購入する場合は、 High Availability アドオンのサブスクリプションは

HA クラスタクラスタ LVM ^{共有ファイル}

システム ^{ロードバランサ}

High Availability

アドオン _○ _× _× _×

Resilient Storage

アドオン

^(*1)

_○ _○ _○ _×

Load Balancer

アドオン _× _× _× _○

各アドオンに含まれる機能

いわゆる HA クラスタが必要な方は、

HA アドオンを選択

(7)

サブスクリプション体系



レッドハット直販価格： http://red.ht/y7GJaD



クラスタの 1 ノードにつき 1 サブスクリプションご購入ください。

●

ソケット数によって価格が異なります。

●

RHEL 本体のサブスクリプションは別途必要です。



監視スクリプトの別販売はありません。

●

標準で含まれないものについては、スクリプトを自作して対応します。

→ /etc/init.d/ 以下に置くサービススクリプト (start/stop/status オプ

ションを受け付けるもの）を作成します。

●

OCF (Open Cluster Framework) 形式のリソーススクリプトも利用可能で

す。

(8)

Red Hat K.K. All rights reserved.

アーキテクチャ

(9)

フェイルオーバクラスタの基礎



アクティブノードで障害が発生して、アプリケーションの稼働が継続できなくなると、同じアプ

リケーションをスタンバイノードで起動しなおして、サービスを継続します。

●

サービス IP アドレスの付与、共有ストレージ上のファイルシステムのマウント、アプリケーションの起

動などの処理を自動的に行います。



HA アドオンでは、 2 種類のサービスが障害監視を行います。

フェイルオーバ

障害発生

アクティブノードスタンバイノード

クライアント

共有ストレージ装置

●

_cman _サービス _→ サーバ全体の停止状態を検知する「ノー

ド監視」

●

_rgmanager _サービス _→ ファイルシステムやアプリケー

ションなどの稼働状況を確認する「リソース監視」

(10)

Red Hat K.K. All rights reserved. ₁₀

鉄板構成



特別な要件がない限りは、シンプルな 2 ノードのアクティブ・スタンバイ構成をお勧めします。



2 ノード構成に特有の「相撃ち問題」を回避する際は Quorum Disk が必要です。（後で説明）

管理ネットワーク

サービスネットワーク

ハートビート・

ネットワーク

Quorum Disk

(100MB 程度 ) ^{アプリケーション} _{データ領域}

アクティブノードスタンバイノード

FC または SAS 接続

の共有ストレージ

NIC NIC NIC IPMI

HBA HBA

NIC NIC

NIC NIC NIC NIC IPMI

HBA HBA

NIC NIC

NIC

(11)

High Availability アドオンを構成するサービス



Cluster Manager (cman サービス）

●

ハートビートでノードの死活監視

●

反応がないノードは、 Fence デーモンがネットワーク経由で強制再起動

●

ハートビート・ネットワーク障害時は、 Quorum 計算、もしくは Quorum Disk

で生き残るノードを決定する。（後ほど詳しく説明）



Resource Group Manager (rgmanager サービス )

●

事前定義されたサービスリソースの起動・停止と稼働監視

●

ノード障害 or リソース障害の際は、新たなノードでサービスを再起動

qdisk デーモン

fence デーモン

cman サービス

内部的には corosync を

使用しています。

corosync

rgmanager サービス

(12)

Red Hat K.K. All rights reserved. ₁₂

設定ファイル

<?xml version="1.0"?>

</fence>

</clusternode>

</fence>

</clusternode> </clusternodes>

</fencedevices>

<rm>

</failoverdomains>

</fs> </service> </rm>

</cluster>



/etc/cluster/cluster.conf に全てを記載します。

(13)

管理ネットワーク

強制再起動

（参考） Quorum 計算とは？



cman サービスは、ハードビートが切れたノードを発見すると管理ネットワーク経由で

強制再起動します。



ネットワーク障害でハートビートが切れた場合は、お互いに殺し合わないように「過半

数ルール」で生き残る島を決定します。

●

1 ノードが 1Vote （投票数）を持ち、島全体の投票数が Quorum （過半数）に達すると生き

残る権利が得られます。

node01

node02

node03

ハートビート・ネットワーク管理ネットワーク

強制再起動

node01

node02

node03

Votes=2

Votes=1

ハートビート・ネットワーク

ノード障害でハートビートが切れると、

障害ノードを強制再起動

ネットワーク障害でハートビートが切れると、

ノード数が過半数の島が生き残る

(14)

Red Hat K.K. All rights reserved. ₁₄

2 ノードクラスタの「相撃ち問題」



2 ノード構成では、ハートビート・ネットワークが切れるとどちらの

ノードも過半数にならないので、 Quorum の仕組みが利用できません。



（ Quorum Disk を使わない場合は） Quorum を無視して稼働を継続す

るオプションを指定します。

●

1 ノードだけでもサービスの継続が許可されます。

●

ハートビート・ネットワークが切れると、お互いに相手ノードの強制再起動を試み

ます。「早い者勝ち」で生き残ったノードがサービスを継続します。

<cman expected_votes="1" two_node="1"/>



_問題点

●

タイミングによっては、両方のノードが再起動して

サービスが停止する可能性があります。

●

( 推奨される構成ではありませんが ) サービスネッ

トワークとハートビート・ネットワークを兼用して

いる場合、 NIC 障害でハートビートが切れた際

に、 NIC 障害ノードが生き残る可能性があります。

ハートビート・ネットワーク管理ネットワーク

node01

node02

相互に強制再起動

（どちらが生き残るかは不定）

(15)

Quorum Disk による「相撃ち問題」の回避



Quorum Disk に 1Vote を与えて、クラスタ全

体の Vote 合計を 3 にします。

●

Quorum Disk の Vote が追加されるので、 1

ノードでも Quorum が満たされます。

●

ハートビート・ネットワーク切断時に生き残る

ノードを決める方法は 2 種類から選択します。

●



master_wins オプションを使用する場合

<cman expected_votes="3" two_node="0"/>

管理ネットワーク

node01

node02

master_wins もしくは Heuristic

で自発的に再起動

Quorum

Disk

Votes=2

ハートビート・ネットワーク

<quorumd interval="1" label="qdisk01" master_wins="1" tko="10" votes="1"/>

<quorumd interval="1" label="qdisk01" tko="10" votes="1">

<heuristic interval="2" program="/usr/local/bin/pingcheck.sh" score="1" tko="3"/>

</quorumd>

●

Quorum Disk を通して内部的に決定されるマスタノードが生き残ります。



Heuristic を使用する場合

●

ユーザが作成したシェルでヘルスチェックを行って、チェックに失敗したノードが自爆しま

す。（サービスネットワークとハートビート・ネットワークを兼用する構成で、ゲートウェイ

への ping 疎通を確認するなど。）

(16)

Red Hat K.K. All rights reserved. ₁₆

Resource Group Manager の設定方法



サービスの引き継ぎ範囲を示す「フェイルオーバ・ドメイン」を定義します。

●

2 : 1 の引き継ぎ構成などは、複数のフェイルオーバ・ドメインを定義します。

(*1) 事前に用意されたリソースについては下記の URL を参照 http://docs.redhat.com/docs/en-

US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/ap-ha-resource-params-CA.html

フェイルオーバ・ドメイン

node02 node03

node01

クラスタ

IP Address

File System

PostgreSQL 8

リソース起動順序

サービス

割り当て



任意のリソースを含む「サービス」を定義します。

●

リソースの種類には、事前準備された「 IP Address 」

「 File System 」「 PostgreSQL 8 」などがあります

(*1)

。

●

リソースの親子関係を設定すると、親から先に起動しま

す。



サービスをフェイスオーバ・ドメインに割り当てま

す。

リソースの定義は /usr/share/cluster/ 以下の OCF スクリプト

各リソースの詳細は、 meta-data オプションで確認できます

(17)

運用上の注意点

(18)

Red Hat K.K. All rights reserved. ₁₈

クラスタの起動手順について (1)



クラスタを起動する際は、 cman 、 clvmd 、 gfs2 、 rgmanager の各サービ

ス ( クラスタサービス ) をこの順番に起動します。

●

基本的には、クラスタに参加するノードで一斉にこれらのサービスを起動しま

す。 SSH などを利用して、同時に自動起動するスクリプトを用意することをおすす

めします。



rgmanager サービスが起動した段階で、クラスタ上で提供する「サービス」の操作が

可能になります。

#!/bin/sh

service cman start

service clvmd start

service gfs2 start

service rgmanager start

#!/bin/sh

service rgmanager stop

service gfs2 stop

service clvmd stop

service cman stop

/usr/local/bin/clstart

/usr/local/bin/clstop

#!/bin/sh

ssh node01 /usr/local/bin/clstart &

ssh node02 /usr/local/bin/clstart &

ssh node03 /usr/local/bin/clstart &

wait

#!/bin/sh

ssh node01 /usr/local/bin/clstop &

ssh node02 /usr/local/bin/clstop &

ssh node03 /usr/local/bin/clstop &

wait

/usr/local/bin/clstart_all

/usr/local/bin/clstop_all

自ノードのサービスを

起動・停止するスクリプトの例

全ノードのサービスを

起動・停止するスクリプトの例

CLVM/GFS2 を使用する

場合のみ必要

CLVM/GFS2 を使用する

場合のみ必要

(19)

クラスタの起動手順について (2)



各ノードのクラスタサービスを１ノードずつ起動すると Quorum の機能に関連して次のような問題

が発生します。（ここでは 3 ノードの例で説明します。）

●

1 つ目のノードでサービスが起動した際に、 Quorum が満たされない場合、 cman サービスの起動

が完了せず、他のノードのサービスの起動待ちになります。

●

2 つ目のノードのサービスが起動した段階で Quorum が満たされると、 2 ノードでクラスタの起動

が完了します。

●

ただし、 3 つ目のノードのサービスが起動していないため、起動済みのノードはスプリットブレイ

ンと判断して、 3 つ目のノードを強制再起動します。

●

例えば、 3 つ目のノードでサービスが起動しているにも関わらず一時的に応答不能で、その後、回復

して共有リソースへのアクセスを行ってしまうなどの可能性があるため、これはクラスタの挙動とし

ては正しい動作です。

●

3 つ目のノードが強制再起動された後に、 3 つ目のノードでサービスを起動すると、正常にクラスタ

に参加します。



この問題を避けるには、次のどちらかの運用方法が必要です。

●

すべてのノードで必ず同時にクラスタサービスを起動する。

●

Quorum に達する最低数のノードのみ OS を起動した状態で、クラスタサービスを順次起動して、そ

の後、残りのノードについて OS の起動とクラスタサービスの起動を 1 ノードずつ繰り返す。

(20)

Red Hat K.K. All rights reserved. ₂₀

サービスの操作について



サービスの稼働状態は、 clustat コマンドで確認します。サービスの開始、停止、禁止、手動での

引き継ぎなどは clusvcadm コマンドを使用します。



サービスの状態 (State) には次のような種類があります。

状態 _説明

started サービスは開始しています。

stopped サービスは停止しています。フェイルオーバ・ドメイン内のノードで

rgmanager サービスが再起動すると、再開します。

disabled サービスは禁止されており、自動的に開始することはありません。

recoverable サービスは異常停止しており、引き継ぎ処理が開始する予定です。

failed サービスは異常停止しており、引き継ぎ処理もできない状態です。問題の原

因を取り除いて、一旦、手動で disabled 状態に変更する必要があります。

# clustat

Cluster Status for cluster01 @ Tue Aug 2 19:10:44 2011

Member Status: Quorate

Member Name ID Status

--- ---- ---- ---

node01 1 Online, Local, rgmanager

node02 2 Online, rgmanager

node03 3 Online, rgmanager

Service Name Owner (Last) State

--- ---- --- --- ---

service:service01 node01 started

(21)

サービスの操作と問題判別に使用するコマンド



サービスの操作に使用する主なコマンドです

コマンド説明

# clusvcadm -e <service> -m <node> サービスを指定ノードで開始 (enable) します。

（ノード指定省略時はコマンドを実行したノード）

# clusvcadm -r <service> -m <node> サービスを指定ノードに引き継ぎ (relocate) します。

（ノード指定省略時は自動的に決定）

# clusvcadm -d <service> サービスを停止 (disable) します。

コマンド説明

# ccs_config_validate /etc/cluster/cluster.conf の内容に問題がない

かチェックします。

# ccs_config_dump 起動中のノードが認識している設定ファイルの内

容を出力します。

# rg_test test /etc/cluster/cluster.conf サービスリソースの設定の解釈を表示します。

# rg_test noop /etc/cluster/cluster.conf

start service <service> サービスリソースの起動順序を表示します。

# rg_test noop /etc/cluster/cluster.conf

stop service <service> サービスリソースの停止順序を表示します。

# cman_tool kill -n <node> 指定ノードを強制停止して、 Fence デーモンの



設定ファイルの問題判別に使用する主なコマンドです。

(22)

Red Hat K.K. All rights reserved. ₂₂

サービス起動ノードの優先順位



ordered="1" は、「自動引き戻し」を有効にする指定です。

●

priority が高い（値が小さい）ノードが停止・再起動するとサービスが移動します。

●

autostart="1" で自動起動する際は、 priority が高いノードで起動します。



ordered="0" の場合は、 priority の値は無視されます。

●

autostart="1" で自動起動する際にサービスが起動するノードは不定です。



clusvcadm コマンドでサービスを手動起動する場合は、 ordered の指定に関係なく、コマンドを

実行したノード、もしくは明示的に指定したノードでサービスが起動します。

●

ordered="0", autostart="0" で、ノード指定でのサービスの手動起動がお勧め。

<rm>

</failoverdomains>

</fs> </service> </rm>

(23)

障害発生時の引き継ぎフロー



図は稼動系で障害が発生した場合の引継ぎ処理のフローです。主な障害のパターンに対

する処理の流れは次のようになります。

●

ノード障害、ネットワーク障害

●

Cluster Manager が通信不能となるため、 Fence デーモンによる強制再起動の後に、待機系で

サービスが開始します。

No

Yes

稼動系の障害発生

Fence デーモンが強制再起動を実

施

待機系でサービス開始稼動系でサービス停止

サービス回復成功？

稼動系でサービス回復を実

施

サービス停止成功？

failed 状

態

started 状態

サービス開始成功？

Cluster Manager は通信可

能？

Yes

No

●

_{アプリケーション障害}

●

稼動系でアプリケーションの再起動

が試みられた後、失敗した場合は、

稼動系でサービスを停止した後に、

待機系でサービスが開始します。

●

_{ディスク障害}

●

ディスク使用リソースのアプリケー

ション障害として動作

^(*1)

。

●

Quorum Disk を使用している場合

は、稼働系が自発的に再起動して、

待機系でサービスが開始します。

(*1) ファイルシステムリソース（ fs タグ）では、オプション self_fence="1" を指定することをお勧めします。ファイルシステム

(24)

クラスタの停止手順について



クラスタ全体を停止する際は、クラスタ上のサービスを停止（もしくは禁止）

した後に、各ノードのクラスタサービスを停止します。

●

クラスタ上のサービスが開始した状態でクラスタサービスを停止すると、意図しな

いサービスの引き継ぎが発生する可能性がありますので、安全のためにサービスは

停止しておきます。



メンテナンスなどの目的でスタンバイノードだけを停止する際は、 1 ノードだ

けで停止してもスプリットブレインと判断されることはありません。

●

cman サービスが停止する際に、他のノードに停止情報を通知します。

●

3 ノード以上の構成の場合は、残りのノードが Quorum を満たすように注意して停

止してください。

(25)

HA クラスタ設計・構築支援サービスのご紹介

(26)

High Availability アドオン関連のサービス一覧

要件定義 ^{クラスタ設計} クラスタ構築運用引き継ぎ

HA クラスタ

構築支援サービス

HA クラスタ

設計支援サービス

監視スクリプト

作成支援サービス

運用資料作成

支援サービス

高度な専門知識を有するレッドハットのエンジニアが

各フェーズの作業の技術支援をご提供いたします



安定した HA クラスタの実現には、設計段階での問題を排除することが最重要ポイン

トになります。まずは、要件定義・クラスタ設計段階での「 HA クラスタ設計支援

サービス」のご利用をお勧めいたします。



お客様のご希望に応じて、後続のフェーズにおける 3 種類の支援サービスを追加で

ご提供させていただきます。

(27)

HA クラスタ構築ビジネス・スタートアップサービス



High Availability アドオンを利用した HA クラスタ構築サービスの提供に不可欠な

技術スキルとノウハウを実案件を想定した形式でお伝えします。



本サービスのトレーニングを受講して、一定の要件をクリアされた SI 事業者様には

トレーニング修了の認定証を発行いたします。



トレーニング期間とお見積もりについては、ご相談ください。

要件定義クラスタ設計クラスタ構築運用引き継ぎ

すべてのフェーズのノウハウを伝授

HA クラスタ構築サービスの提供を検討される

SI 事業者様に、レッドハットのエキスパートエンジニアが

さまざまなノウハウをお伝えいたします

(28)

参考情報

(29)

設計時に注意が必要な場合



特に次のような環境で使用する際は、環境に応じたパラメータのチューニング

が必要な場合があります

^(*1)

。

●

サービスネットワークとハートビート・ネットワークを兼用している環境で、ネッ

トワークの高負荷が予想される場合

●

ハートビートパケットの遅延により、障害の誤検知が発生する可能性があります。

●

ディスク I/O の高負荷が予想される環境で Quorum Disk を使用する場合

●

Quorum Disk へのアクセスの遅延により、障害の誤検知が発生する可能性がありま

す。 I/O スケジューラを deadline スケジューラに変更するなどで回避します。

●

特に iSCSI ディスクは高負荷時に遅延が発生しやすいので注意が必要です。

●

DMMP などのマルチパス構成ストレージに Quorum Disk を配置する場合

●

I/O パスの切替時間、 Quorum Disk による障害検知時間、ハートビートによる障害検知

時間の依存関係を適切に設定する必要があります。

●

I/O パス切替時間＜ qdisk 障害検知時間＜ハートビート検知時間（ qdisk 障害検知時間の

2 倍以上）が原則

(*1) このようなプロダクション環境で High Availability アドオンを利用する際は、レッドハットのコンサル

(30)

HA クラスタ設計時の心構え



シンプルなアクティブ・スタンバイ構成がベストです。

●

HA クラスタは障害発生中の環境下で機能するため、障害の副作用を受けないように、できる

かぎり構成をシンプルにします。

●

特別な要件がない限りは、 2 ノード + Quorum Disk によるアクティブ・スタンバイ構成をお

すすめします。



対応するべき障害の範囲を明確にします。

●

HA クラスタはあらゆる障害に対応する魔法のソフトウェアではありません。特に、 2 重障害

の発生には対応できない場合が多数あります。

●

HA クラスタで保護したい障害内容を洗い出しておき、各障害パターンに対する動作検証を確

実に実施してください。



運用を意識した設計を行います。

●

HA クラスタは複数のノードが密に連携するため、常にそれぞれのノードの状況をみながら操

作を行う必要があります。

●

運用手順が複雑になる設計は避けた上で、運用手順書の整備を怠らないようにしてください。

(31)

参考資料



High Availability アドオンの製品マニュアル

●

「 High Availability Add-On Overview 」および「 Cluster Administration 」を参照

http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/index.html



High Availability Add-On 非公式技術情報

●

http://sites.google.com/site/haaddon/



High Availability Add-On 設計・運用入門

●

http://www.slideshare.net/enakai/rhel6-rhcs-guidepreview-8758112



KVM で HA クラスタの機能検証環境を構築

●

http://d.hatena.ne.jp/enakai00/20110804/1312437111

まずはこの 2 つがお勧め

(32)

資料 Linux女子部 HA Add On v1 0

第 3 回 Linux 女子部勉強会

60 分で

RHEL6 High Availability アドオンを

徹底的に理解しよう！

V1.0 2012.4.21

中井悦司 / Etsuji Nakai

Senior Solution Architect

and Cloud Evangelist

Red Hat K.K.

Red Hat K.K. All rights reserved. 2

自己紹介

第三弾鋭意制作中

中井悦司（なかいえつじ）

Twitter @enakai00

日々の仕事

Senior Solution Architect and

Cloud Evangelist at Red Hat K.K.

企業システムでオープンソースの活用を希望される

お客様を全力でご支援させていただきます。

昔とった杵柄

素粒子論の研究（超弦理論とか）

予備校講師（物理担当）

インフラエンジニア（ Unix/Linux 専門）

現在 Mountain View に出張中

自己紹介（本日の講師代打）

平 初（たいら はじめ）

Twitter @htaira

日々の仕事

Solution Architect and

Cloud Evangelist at Red Hat K.K.

ご提案の中でオープンソースの活用を希望される

認定パートナー企業を全力でご支援させていただきます。

昔とった杵柄

ヘルプデスクコールスタッフ（ PPP 接続設定担当）

インフラエンジニア（ Unix/Linux/VMware の火消し専門）

ハーフノードサーバーの設計（専用マザーボード設計とか）

Microsoft Tech-Ed 講演（ IIS も AD も得意です。ｷﾘ）

Red Hat K.K. All rights reserved. 4

目次

基本情報

アーキテクチャ

運用上の注意点

HA クラスタ設計・構築支援サービスのご紹介

参考情報

基本情報

Red Hat K.K. All rights reserved. 6

RHEL6 のクラスタ関連アドオン一覧

(*1 ） Resilient Storage のサブスクリプションを購入する場合は、 High Availability アドオンのサブスクリプションは

HA クラスタ クラスタ LVM 共有ファイル

システム ロードバランサ

High Availability

アドオン ○ × × ×

Resilient Storage

アドオン

○ ○ ○ ×

Load Balancer

アドオン × × × ○

各アドオンに含まれる機能

いわゆる HA クラスタが必要な方は、

HA アドオンを選択

サブスクリプション体系

レッドハット直販価格： http://red.ht/y7GJaD

クラスタの 1 ノードにつき 1 サブスクリプションご購入ください。

ソケット数によって価格が異なります。

RHEL 本体のサブスクリプションは別途必要です。

監視スクリプトの別販売はありません。

標準で含まれないものについては、スクリプトを自作して対応します。

→ /etc/init.d/ 以下に置くサービススクリプト (start/stop/status オプ

ションを受け付けるもの）を作成します。

OCF (Open Cluster Framework) 形式のリソーススクリプトも利用可能で

す。

Red Hat K.K. All rights reserved.

アーキテクチャ

フェイルオーバクラスタの基礎

アクティブノードで障害が発生して、アプリケーションの稼働が継続できなくなると、同じアプ

リケーションをスタンバイノードで起動しなおして、サービスを継続します。

サービス IP アドレスの付与、共有ストレージ上のファイルシステムのマウント、アプリケーションの起

動などの処理を自動的に行います。

HA アドオンでは、 2 種類のサービスが障害監視を行います。

Red Hat K.K. All rights reserved. ₂

_{日々の仕事}

_{昔とった杵柄}

平　初（たいら　はじめ）

_{日々の仕事}

_{昔とった杵柄}

Red Hat K.K. All rights reserved. ₄

_基本情報

_{アーキテクチャ}

_{運用上の注意点}

_参考情報

Red Hat K.K. All rights reserved. ₆

HA クラスタクラスタ LVM ^{共有ファイル}

システム ^{ロードバランサ}

アドオン _○ _× _× _×

_○ _○ _○ _×

アドオン _× _× _× _○

アクティブノードスタンバイノード

_cman _サービス _→ サーバ全体の停止状態を検知する「ノー

_rgmanager _サービス _→ ファイルシステムやアプリケー

Red Hat K.K. All rights reserved. ₁₀

(100MB 程度 ) ^{アプリケーション} _{データ領域}

アクティブノードスタンバイノード

Red Hat K.K. All rights reserved. ₁₂

管理ネットワーク

ハートビート・ネットワーク管理ネットワーク

ハートビート・ネットワーク