高可用性HAクラスタ・クラウド構成とWeb3層アーキテクチャ【202試験 主題2.13】



LinuCレベル2（202試験）の技術分野における最終主題である 主題2.13「高可用システムと典型的なアーキテクチャ」では、障害発生時にもサービスを継続稼働させる 高可用性（HA）クラスタ（Pacemaker / Corosync / STONITH） に加え、システムの成長を支える キャパシティプランニング（2.13.2）、クラウドサービス上のシステム構成（2.13.3）、および 典型的なシステムアーキテクチャ（Web3層モデル・非同期キュー）（2.13.4） が出題範囲に指定されています。あわせて本記事では、共有ストレージを持たずに内蔵ディスクだけでデータ冗長化を実現する手法として、DRBD（Distributed Replicated Block Device） によるリアルタイムブロック同期も実務拡張として解説します。

単一障害点（SPOF）を排除したアクティブ/スタンバイクラスタの構築から、スプリットブレインを防ぐクォーラム過半数判定、スケールアップとスケールアウトの設計判断、クラウドIaaSにおける永続化ストレージとエフェメラルの使い分け、そしてWeb3層モデルによる負荷分離まで、エンタープライズインフラを支える全体アーキテクチャの視点が問われます。本記事では、AlmaLinux 9.8の実機環境での Pacemaker 2.1 / Corosync 3.1 操作ログとともに、主題2.13の全出題範囲を体系的に解説します。

1. 高可用性（HA）クラスタの基礎概念と構成モデル#

エンタープライズインフラにおいて、システム停止は直接的なビジネス損失をもたらします。高可用性（HA: High Availability）クラスタとは、冗長化された複数のノード（サーバー）がハートビート通信によって互いの健全性を監視し合い、障害発生時に自動的にサービスを引き継ぐ（フェイルオーバーする）分散システム技術です。

図1: HAクラスタの階層アーキテクチャとクォーラム合意

1.1 可用性の指標（SPOFの排除と稼働率99.999%）#

高可用性を定量的に評価する指標として、以下の概念がLinuC試験および実務設計で頻出します。

HAクラスタの構成方式には、主に以下の2種類が存在します。

1.2 HAクラスタのソフトウェアスタック#

モダンなLinux HAクラスタは、役割ごとに責任が分離された多層アーキテクチャで構成されています。Linux-HAプロジェクトおよびクラスタスタックの階層構造は下表の通りです。

2. クォーラム（Quorum: 定足数）とスプリットブレインの恐怖#

クラスタ運用において最も避けるべき事態は「データの破損」です。サービスが一時的に停止することよりも、共有ディスクの内容が不整合を起こして破壊されることの方が致命的です。

2.1 クォーラムの計算ルールと過半数合意メカニズム#

クォーラム（Quorum: 定足数） とは、分散ノード間で合意を形成し、クラスタとして健全に意思決定を行える「過半数（Majority）」の票数のことです。

ノード総数を N としたとき、クォーラムが成立するために必要な生存ノード数 Q は以下の計算式で定義されます。

ノード数が奇数の場合、ネットワークがどこで分断されても、必ずどちらか一方のグループだけが過半数を獲得できます。過半数を獲得した側（Quorate側）だけがサービスを継続し、過半数を失った側（Inquorate側）は自らサービスを停止（または凍結）することで、安全性を担保します。

しかし、小規模システムで一般的な 2ノードクラスタ（2-node cluster） の場合、クォーラム必要数は floor(2/2) + 1 = 2票 となります。つまり、相手ノードと通信できなくなった瞬間、残された1台は「1票しか持たないためクォーラムを喪失」し、デフォルトの挙動ではサービスを即座に停止してしまいます。これを解決するため、以下の手法が採用されます。

2.2 スプリットブレイン（Split-Brain）の発生原因とデータ破壊#

スプリットブレイン（Split-Brain） とは、ノード間のインターコネクトネットワークが切断された際、互いのハートビートが届かなくなり、双方が「相手ノードがダウンした」と誤認して同時にプライマリへ昇格してしまう現象です。

もし双方が同時に同じ仮想IPアドレス（VIP）を名乗り、同一の共有ディスク（共有ストレージやDRBDボリューム）に対して同時に書き込みを実行した場合、ファイルシステムのメタデータは瞬時に破綻し、復旧不可能なデータ破損が発生します。

2.3 フェンシング機構（STONITH）の絶対的役割#

スプリットブレインによるデータ破損を物理的に阻止する最終防衛線が STONITH（Shoot The Other Node In The Head） です。直訳すると「相手ノードの頭を撃ち抜け」という過激な名称の通り、応答が途絶えた相手ノードに対して、ハードウェア管理機構を介して 強制的な電源断（Power Off）またはハードウェアリセット（Reboot） を実行します。

STONITHを実現するデバイス（フェンスエージェント）には以下のような種別が存在します。

3. PacemakerとCorosyncの基本設定と実機リソース制御#

クラスタの実際の構築と運用では、ネットワーク通信を司る Corosync の構成ファイルと、クラスタリソースを統合制御する pcs コマンドの操作手順を把握する必要があります。

3.1 corosync.conf のネットワークインターコネクト定義#

Corosyncの設定は /etc/corosync/corosync.conf に集約されています。このファイルは全クラスタノード間で完全に同一の内容で保持される必要があります。主要な設定ブロックとディレクティブの意味は下表の通りです。

totem {
    version: 2
    cluster_name: my_ha_cluster
    transport: knet
    crypto_cipher: aes256
    crypto_hash: sha256
}

nodelist {
    node {
        ring0_addr: 192.168.2.138
        name: linuc-node01
        nodeid: 1
    }
    node {
        ring0_addr: 192.168.2.139
        name: linuc-node02
        nodeid: 2
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
}

logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    timestamp: on
}

設定ファイル内の各ディレクティブには以下の役割があります。

3.2 pcs コマンドによるクラスタ操作実機ログ#

Red Hat系ディストリビューションでは、クラスタ設定を手動でXML編集するのではなく、ラッパーCLIツールである pcs（Pacemaker/Corosync Configuration System） を介して操作します。

実機環境（AlmaLinux 9.8）におけるインストール済みパッケージと利用可能なリソース規格を確認した結果が以下です。

[user01@linuc-node01 ~]$ pcs --version; pacemakerd --version; corosync -v
0.11.11
Pacemaker 2.1.10-3.el9_8
Written by Andrew Beekhof and the Pacemaker project contributors
Corosync Cluster Engine, version '3.1.10'
Copyright (c) 2006-2021 Red Hat, Inc.

Built-in features: dbus systemd xmlconf vqsim nozzle snmp pie relro bindnow
Available crypto models: nss openssl
Available compression models: zlib lz4 lz4hc lzo2 lzma bzip2 zstd

[user01@linuc-node01 ~]$ pcs resource standards
lsb
ocf
service
systemd

[user01@linuc-node01 ~]$ pcs resource providers
heartbeat
openstack
pacemaker

[user01@linuc-node01 ~]$ pcs resource agents ocf:heartbeat | grep -E 'IPaddr|apache'
apache
IPaddr2

新規にクラスタを立ち上げる際の一連の標準コマンドフローは以下のステップで実行されます。

3.3 リソースエージェント（RA）の規格（OCF, systemd, service）#

Pacemakerが各種サービスを制御する際、仲介役となるスクリプト群を リソースエージェント（RA: Resource Agent） と呼びます。RAは以下の命名規則で指定します。

代表的な規格には以下のものがあります。

試験で最も頻出する 仮想IPアドレス（VIP: Virtual IP） およびWebサービスのリソース追加コマンド例は以下の通りです。

# 仮想IPアドレス（192.168.2.200/24）を10秒間隔で監視するリソースとして作成
[user01@linuc-node01 ~]$ sudo pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \
    ip=192.168.2.200 cidr_netmask=24 op monitor interval=10s

# 第11回で構築したApache Webサーバーを15秒間隔で監視するリソースとして作成
[user01@linuc-node01 ~]$ sudo pcs resource create WebServer systemd:httpd \
    op monitor interval=15s

3.4 3大制約（location, colocation, order）の設計#

Pacemakerにリソースを登録しただけでは、各ノードのCPU負荷やネットワーク構成に応じた配置ルールが定まりません。クラスタの動作ポリシーを厳密に定義するため、Pacemakerでは以下の 3大制約（Constraints） を設定します。

上記の設定例では、colocation ... INFINITY によって「WebServerは必ずVirtualIPが稼働しているノードと同じノードで動く」ように束縛され、order ... then によって「VirtualIPが正常に割り当てられた後でWebServerが起動する（停止時は逆順）」という厳密な依存関係が確立されます。

4. 共有ストレージ同期とデータ整合性（実務拡張：DRBD）#

HAクラスタでステートフルなWebアプリケーションやデータベースをフェイルオーバーさせる場合、系切り替え先ノードでも最新のデータが参照できなければなりません。外部の共有ストレージ（SAN/NAS）を導入せずにサーバー内蔵ディスクだけでデータ冗長化を実現する代表的なソフトウェアが DRBD（Distributed Replicated Block Device） です。主題2.13の公式明記範囲外ですが、現場のLinuxクラスタ運用ではPacemakerと組み合わせて極めて頻出の実務必須技術です。

図2: DRBDのブロックレプリケーションと同期プロトコルA/B/C

4.1 DRBD（Distributed Replicated Block Device）の動作原理#

DRBDはLinuxカーネルモジュールとして動作し、TCP/IPネットワークを介して2台のホスト間でブロックデバイスをリアルタイムに二重化します。物理的には各ノードの内蔵ディスク（例: /dev/sdb1）を使用しながら、上位のファイルシステムやアプリケーションに対しては仮想的な単一のブロックデバイス（例: /dev/drbd0）として透過的に見せかけます。いわば 「ネットワーク経由のソフトウェアRAID 1」 です。

DRBDノードは通常、以下の役割分担で運用されます。

4.2 DRBDの3大同期プロトコル（Protocol A, B, C）#

DRBDを実務で設計・運用するうえで最も重要なポイントとなるのが、更新書き込み完了通知（ACK）のタイミングを定義する 3つのレプリケーションプロトコル（Protocol A, B, C） の差異です。

DRBDの設定ファイル（/etc/drbd.conf または /etc/drbd.d/*.res）内では、リソース定義の net ブロックにおいて protocol C; のように指定します。

4.3 クラスタファイルシステム（GFS2, OCFS2）の概要#

DRBDをアクティブ/アクティブ構成（Dual-Primaryモード）で使用し、両ノードから同一のブロックデバイスを同時にマウントして読み書きする場合、ext4やXFSなどの通常ファイルシステムを使用するとメタデータ競合によってディスクが破損します。

そのため、複数ノードからの同時並行アクセスを調停できる クラスタファイルシステム の採用が必須となります。

5. キャパシティプランニングとクラウド上のシステム構成#

高可用性システムを長期にわたり安定運用するためには、トラフィック増加に耐えうるキャパシティ設計と、クラウド基盤の特性を活かした柔軟なリソース配置が不可欠です。

5.1 スケールアップ vs スケールアウトの設計判断#

システムの処理能力を拡張するアプローチには、大きく分けて以下の2通りが存在します。LinuC試験では両者の特徴とトレードオフが頻出します。

5.2 ステートレス設計とセッション情報の外出し#

Webサーバーを安全にスケールアウトするための絶対条件が ステートレス化（Stateless） です。各Webサーバーがユーザーのログインセッション情報をローカルメモリに保持している場合、ロードバランサーが別サーバーへリクエストを振り分けるとセッションが途切れてしまいます。

5.3 クラウドサービス（IaaS）上のシステム設計#

AWSやAzure、GCPなどのクラウド環境におけるLinux運用では、オンプレミスと異なる以下のクラウド固有概念が出題されます。

6. 典型的なシステムアーキテクチャ（Web3層モデルと非同期処理）#

LinuC 202試験の主題2.13.4では、企業向けシステムで最も広く採用されている基本アーキテクチャの構造が出題されます。

6.1 Web3層アーキテクチャの役割分担#

システムを機能ごとに独立した3つの論理層に分離し、保守性とスケーラビリティを高めたモデルが Web3層モデル です。

6.2 非同期処理とメッセージキュー（疎結合化）#

大量のリクエストが集中した際、メール送信や画像変換、PDF出力などの重い処理を同期的に実行するとWeb層全体がハングアップします。これを防ぐため、メッセージキュー（RabbitMQ, Apache Kafka等） を介して処理要求をキューイングし、バックグラウンドのワーカープロセスが非同期に順次処理を行う 「疎結合（Loosely Coupled）アーキテクチャ」 が採用されます。

7. LinuC 202試験（主題2.13）重要ポイント総整理#

LinuC 202試験の主題2.13「高可用性（HA）クラスタ」において、合否を分ける重要コマンド・設定ファイル・プロトコルの要点を総整理します。

7.1 記述式（コマ問）頻出コマンド・設定ディレクティブ一覧#

記述式問題では、コマンドの正確なスペルや設定ファイルのフルパス、パラメータ名の入力が求められます。下表の項目は確実に記憶しておく必要があります。

7.2 STONITH無効化（stonith-enabled=false）の試験的意味#

Pacemakerのデフォルト設定では、データ安全性を最優先するため STONITHが有効（stonith-enabled=true） になっています。そのため、フェンスデバイス（IPMI等）が登録されていない場合、Pacemakerはクラスタが危険な状態にあると判断し、いかなるリソースも起動しません。

LinuCのラボ試験や検証環境において、フェンスデバイスが存在しない状況で暫定的にリソースを動作させるために実行する必須コマンドが以下です。

[user01@linuc-node01 ~]$ sudo pcs property set stonith-enabled=false

試験では「検証環境でリソースが起動しない原因」や「フェンスデバイスなしでリソースを起動するためのクラスタプロパティ名」として stonith-enabled が頻出します。ただし、前述の通り本番環境でこの設定を行うとスプリットブレイン発生時にデータ破損を防止できないため、商用環境では設定禁止です。

7.3 DRBD同期プロトコルA/B/Cの判定盲点（実務拡張）#

DRBDの同期プロトコル選定では、インフラ要件（ネットワーク遅延とデータ整合性の優先度）から最適なプロトコルを判断することが重要です。以下の判断基準を押さえておきましょう。

8. 202試験総括：ネットワークサービスと堅牢インフラ運用の体系的完了#

第9回から開始したLinuC 202試験対策は、本第16回をもって出題技術範囲のすべてを完了しました。

これらの技術要素は独立して存在するのではなく、例えば「DRBDとPacemakerで同期された冗長ストレージ上にSambaやNFSを展開し、OpenLDAPとPAMで集中認証を行い、外縁部をnftablesとVPNで防護する」といったように、実務の大規模エンタープライズインフラにおいて緊密に連携して稼働しています。

リンク