RedHat Cluster Suite を使った2node Oracle クラスタ

(この文書は未完成)

RHEL 標準のクラスタソフトである、RedHat Cluster Suite(RHCS)を使って、Active-StandbyなOracleクラスタサーバを構築する。
CentOSでもほとんど同じ手順でクラスタ構築が可能。

CentOSサーバー 価格：3,150円（税込、送料別）

KVM徹底入門 価格：3,444円（税込、送料別）

Table of Contents
=================
1 参考ドキュメント
2 作業の流れと進捗チェックリスト
3 事前準備
    3.1 IPアドレスの決定
    3.2 ストレージパラメータの決定
    3.3 Oracleパラメータの決定
4 RedHat Enterprise Linuxの設定
    4.1 OSインストール
    4.2 最新パッチの適用
    4.3 ネットワークの二重化
        4.3.1 /etc/modprobe.conf
        4.3.2 ifcfg-eth0
        4.3.3 ifcfg-eth1
        4.3.4 ifcfg-bond0
5 共有ストレージの設定
    5.1 RAID/LUNの作成
    5.2 ホストへのマッピング設定
        5.2.1 もし二つのノードからのデバイスの見え方が違ったら
            5.2.1.1 ストレージの場合
            5.2.1.2 ネットワークの場合
    5.3 ストレージの結線
    5.4 ストレージパスの二重化
    5.5 ファイルシステムの作成
        5.5.1 iSCSIをマウントする例
        5.5.2 認識確認
        5.5.3 ファイルシステムの作成
    5.6 両ノードからのマウント確認
        5.6.1 rhcs-oracle1から
        5.6.2 rhcs-oracle2から
6 RHCSの基本設定
    6.1 クラスタ化されるノードの設定
        6.1.1 yum が使えない場合。
    6.2 クラスタ管理サーバを設定
        6.2.1 yum が使えない場合
        6.2.2 管理画面へのアクセス
    6.3 クラスタノードを管理サーバへ参加
------------------------------------- ここで力尽きてる
    6.4 Fencingの設定
    6.5 Quorumディスクの設定
7 RHCSのリソースとグループの設定
    7.1 リソース 仮想IPの設定
    7.2 リソース 共有ディスクの設定
    7.3 グループ 依存関係の定義
    7.4 グループ 起動と停止の確認
8 単体SPFテスト
    8.1 OS起動・停止
    8.2 手動フェイルオーバー
    8.3 手動フェイルバック
    8.4 ネットワーク切断
    8.5 ストレージパス切断
9 Oracle設定
    9.1 インストール
    9.2 パッチ適用
    9.3 データベースの作成
    9.4 リスナーの作成
    9.5 起動・停止スクリプトの作成
    9.6 設定ファイルを両ノードのコピー
    9.7 両ノードでデータベースとリスナーが起動する事を確認
10 RHCSへのOracle組込み
    10.1 Oracleリソースの作成
    10.2 依存関係の定義
    10.3 起動・停止・フェイルオーバーテスト
11 結合SPFテスト
    11.1 ネットワーク障害
    11.2 ストレージ障害
    11.3 OS障害
    11.4 データベース障害
    11.5 リスナー障害

クラスタの安全設計まとめ

今までの投稿をまとめ。

通常の安全設計は今まで通り行い、その上でこれらの事に注意して、より安全性の高いシステムを構築できるように。

（ケース１）内蔵RAIDボードの障害
（ケース２）共有ストレージのコントローラ障害
（ケース３）ローリングアップグレードは計画的に

以下に代表的なクラスタソフトを列挙しておく。

Microsoft Cluster Service (MSCS)

Windowsでクラスタするならこれが一番手軽で安全。ただし細かい制御はできない。

Symantec VERITAS Cluster Server

Sun/Solarisではおなじみ。Linux版もあり。VxVM/VxFSと組み合わせた運用をしたい場合に適している。そこそこ細かいこともできる。

Life Keeper

安い。ただし柔軟性低い。

Cluster Pro

純国産。サポートが素早い。

MC/Service Guard

昔ながらのクラスタソフト。安定性は抜群で柔軟性も高い。ただし、クラスタソフト自体は非常にシンプルな機能しかないので、監視等の機構を自分で開発し組み込む必要がある。

Redhat Cluster Suite

RedHat標準クラスタソフト。柔軟性高い。HPはMC/SG for Linux を終了し、こちらへ移行した。

サーバクラスタ設計における盲点（３）

＊この記事は著者の経験則に基づく内容であり、一般的に公開されている内容とは異なる可能性があります＊


（ケース３）ローリングアップグレードは計画的に


前回
（ケース１）内蔵RAIDボードの障害
（ケース２）共有ストレージのコントローラ障害


想定する環境は前回同様共有ストレージタイプのActive－Standbyクラスタ。


クラスタの利点でよく取り上げられるのが可用性と、ローリングアップグレードによる停止時間を最小限にしたアップグレード。ローリングアップグレードとは、


Standby側へパッチを当てやメンテナンス
↓
手動フェイルオーバー
↓
元Active側へパッチ or メンテナンス
↓
再度フェイルオーバー（しなくてもよい）


という手順を踏み、メンテナンスによる停止時間を最小限に抑える手法になる。


しかしローリングアップグレードは使えるケースが限られているので注意が必要。
その原因を考えるため、クラスタのレイヤを下記のように想像してみる。

１．アプリケーション（ミドルウェア）
２．クラスタソフト
３．OS（ファイルシステム）
４．マルチパス
５．共有ストレージ


このうち、３，４は二つのノードで独立しているが、２，５は二つのノードで共有されている。
当然、１のデータは共有ストレージに入っているわけだからリソースは二つのノード間で共有されていることになる。


例としてOracleのActive-Standbyクラスタを考えてみる。


１．へパッチ適用（Oracleへのパッチ）を当てようとすると、
Oracleのパッチは アプリケーションへのパッチ適用 → DBFのアップグレード という手順になるため、実質ローリングアップグレードはできない。
パッチを当てるためには共有ディスクへアクセスできる必要があるため、Activeなノードで無ければパッチが適用できないためだ。


２．へのパッチ適用（クラスタソフトのアップグレード）も注意が必要だ。
クラスタソフトはノード間の整合性を取るためにハートビート通信で互いの状態を常時やり取りしている。
パッチでこの通信の仕様が変わってしまう場合がある。
そうなってしまうと、パッチを当てた後にクラスタソフトを再起動してもハートビートが復帰できず、互いに相手が障害を起こしていると誤認ししてしまう。
これはかなりよろしくない仕様だが、こういう動作をしてしまうクラスタソフトを存在する。
またパッチの種別により、ローリングアップグレード可能か不可能かという情報をくれるメーカもあるので、作業前に必ず確認しておこう。


３．４については独立しているので基本的にはローリングアップグレード可能だ。
ただし、Windows MSCSは OSとクラスタが一体化しているので、パッチ適用前にMSへローリングアップグレード可能かどうかを確認しておこう。


パッチを当てるというのは本番運用後に発生する作業で、当然本番環境での作業に失敗は許されない。
必ずメーカサポートに確認したうえで、検証環境でのテストを行った後に作業をするように心がけよう。

サーバクラスタ設計における盲点（２）

前回の続き。
http://aikotobaha.blogspot.com/2010/06/blog-post.html

＊この記事は著者の経験則に基づく内容であり、一般的に公開されている内容とは異なる可能性があります＊

（ケース２）共有ストレージのコントローラ障害

前回同様の共有ディスクタイプのクラスタを想定します。基本的にこの構成であればほぼ全ての対して対応する事が出来る。

しかし障害からのリカバリ時に問題が発生するケースがある。クラスタでは障害発生時の事はしっかり想定するが、そこからリカバリする時に盲点が発生しやすいので注意しよう。

それが共有ディスクのコントローラが壊れた場合だ。稼動部が無く壊れにくいパーツな上、いくつかの要素が重ならないと発生しないので遭遇した事がある人はあまり多くないかもしれない。
しかし発生すると非常に厄介な障害となる。

当然、共有ディスクのコントローラが壊れても、大抵のストレージではコントローラは冗長化されているので問題無いはずだ。
しかしこの問題は壊れたコントローラを交換した後に発生する。

ストレージの中にはコントローラを交換するとWWNが変わってしまうストレージがある。

WWNが変わってしまうとどんな問題が発生するするのか？

まずOSが変更されたWWNを新しいドライブと認識してしまう可能性。これは特にマルチパスを構成していない場合に発生しやすい(ストレージにサーバを直結している場合等)
こうなるとディスクがクラスタ制御下から外れてしまいフェイルオーバー時のマウント/アンマウントの処理が出来なくなってしまう。

二つ目としてクラスタソフトやマルチパスソフトがリソースの制御に直接WWNを使っている場合、パーツを交換したのにいつまでも古いパスをチェックしてしまい、障害状態のままになってしまい。フェイルバック出来なくなってしまう。

この現象が発生してしまうと、状態を元に戻すの様々なオペレーションが必要になる上、構築テスト段階でこんなテストはやらない(できない)ので、復旧には時間がかかってしまう事が容易に想像できると思う（未経験のオペレーションなため）
また復旧するために変更を行えば当然ながら、簡易的なテストが必要になり、クラスタ環境なのにある程度の時間、システムが停止してしまう可能性もある。

こういったクラスタを組むという事はそれなりに重要度が高いシステムの可能性が高く、顧客への説明も一苦労となってしまう。

この現象は事前にいくつかの確認を行っておく事で回避出来るので事前チェックを怠らない様にしよう。

1. コントローラ交換時にWWNは変わるか？
これは完全にストレージの仕様になる。ある程度高価なストレージはWWNを自由に設定でき、保守員が交換後に元のWWNに設定してくれたり、このWWN設定を対向のコントローラが保持しており交換すると自動で元に設定されるモノもある。
こういったストレージあれば何も心配する必要は無い。
しかし世の中にはコントローラがを交換すればWWNが変わってしまうストレージも残念ながら存在する。その場合はに備えて2番目の確認。

2.クラスタ配下のディスクのWWNが変わってしまった場合の対処
これはOS/クラスタソフトによって状況が変わるので、つど必ずソフト提供元に確認をとっておこう。

　代表的な例を示すと、

ストレージを Veritas Storage Foundation（旧VxVM） や、dm-multipath配下に置いている場合はWWNの変更はほとんど影響しない。
この場合、VxVMやdm-multipathがデバイスを抽象化（/dev/vx/xxxxx, /dev/mpath/mpathXX）し、その配下のパスコントロールはWWNの変更を自動で検知し、動的にパスを組み替えてくれる。
そして上位のクラスタはこの抽象化されたデバイスに対して操作を行うため問題が発生しない。


しかし、マルチパスソフト無しでクラスタが直接 /dev/sdb 等を制御している場合はや、Windows で マルチパスソフトを使っていない環境でWWNが変わると、別のドライブとして認識してしまうので、対処が必要となる。
またマルチパスソフトの制御の仕方によってはNGなものも存在する。HP-UXのPV-LinkはWWNの変更には対処できない。これはOSが認識したデバイスファイル名を直接使って、マルチパスを指定するためだ（デバイスは抽象化されているのでクラスタの動作には問題は無いが、そのままだとマルチパスが復旧しない）

1番簡単なのは１の対処だ。これが一番安心で、夜間に障害が起きてもオペレーションのために呼び出される心配もない。
2の場合は、回復にオペレーションを必要とする場合が多く、大抵の場合はオペレータレベルでは対処できないことが多い。

可能な限り１で対処し、安眠できるシステムを構築しよう。

　またこのWWN変更問題はMACアドレスの変更（マザーを交換した場合にオンボードNICが影響を受ける）でも同じような現象が起きる可能性があるので注意しておこう。

サーバクラスタ設計における盲点（１）

＊この記事は著者の経験則に基づく内容であり、一般的に公開されている内容とは異なる可能性があります＊

僕はインフラSEとしてさまざまな機器・ソフトを使って１００台近くのサーバクラスタの設計～構築～運用サポートを行ってきた。

これだけのシステムを数年間運用サポートすると、実に様々な障害に遭遇し、その中にはクラスタが有効に働かないケースも多々発生した。

もともと障害を想定してクラスタ構成を組むわけなので、クラスタが有効に働かないケースというのは、考慮不足による設計の不備である。

ここではその考慮不足を招きやすい事象と対策についてまとめておく。

ここで想定するサーバクラスタとは下図のような一般的なActive-Standby型のサーバクラスタになります。

（ケース１）内蔵RAIDボードの障害

一般的にクラスタを構成する各サーバに内蔵されたディスクにOSとアプリケーションをインストールし、共有ディスクにデータを格納するケースがほとんどだと思う。

このようなケースでActive側の内蔵RAIDボードが壊れてしまう状態を想像してほしい。突然内蔵ディスクに全くアクセスできなくなる状態だ。

実はこの状態、ほとんどのサーバクラスタ環境でフェイルオーバーが発生しない（厳密には対処できるように設定されていない）

各ノードで発生する事象は以下を見てほしい。

■Activeノードで起こる現象

アプリケーションは外部からのリクエストを処理をするために内蔵ディスクのコマンドやライブラリを呼び出したり、OSはログを格納しようと内蔵ディスクにアクセスするタイミングで、この異常を検知することになる。

当然アプリケーションは動かなくなってしてしまう（停止するわけではない）。クラスタも異常を検知して、あらかじめ定義された動作に従いアプリの再起動を試みるが、当然呼び出すべきコマンド群（プロセスの停止や、アプリケーションを停止するコマンド）が入っている内蔵ディスクが参照できないので、何もできなくなってしまう。

最終的に全てのクラスタ配下のリソースを強制解放するコマンドも内蔵ディスクなため、アプリケーションの強制終了すらできなくなってしまい、リソース（仮想IP、プロセス、共有ディスク）を中途半端に保有したままになってしまう。

■Standbyノードで起こる現象

Active側で異常が発生していることは検知できる。しかしStandby側でアプリを強制起動しようにも、Active側では停止不能なアプリが中途半端な状態で動いている。

仮に強制起動をかけて、共有ディスクの所有権を強制的に確保しアプリの起動を試みても、仮想IPをActiveノードが保持しているので、クラスタは依存関係に従いリソースを起動するプロセスで、仮想IPの割り当てがエラーを起こし、アプリケーションを起動することができなくなってしまう。

この状態は非常に危険で、アプリケーションによってはメモリ上だけで一部のデータを処理できてしまう場合がある（しかも共有ディスクへの書き込みは行える）。最終的にはデータ不整合が発生する可能性が高く、復旧に多大な労力を払うことになる（最悪、顧客から賠償という話にも）

この状態は人手のオペレーションがなければ復旧することができないが、普及するのは簡単。Activeノードを電源ボタン長押しで強制OFFし、Standbyノードでクラスタリソースの再起動を実行してやればよい。

この現象は今までで４回経験した。原因はRAIDボードファームのバグ、497日問題によるRAIDボード再起動、RAIDボードの故障、マザーの不具合によるバスエラー。

問題点は２つ

１．内蔵ディスクが参照できなくなるという事態に対して、OSやクラスタソフトが対処できていない。

２．内蔵RAIDボードが単一障害点（SPOF）になっている。

１への対処

このような状態になった時にOSがパニックを起こして停止すればいいので、このような設定をOSかクラスタソフトへ予め行っておく（設定方法は環境によって異なるので、提供元に確認してほしい）

２への対処

最も簡単なのが、SANブート構成にしてしまう事。２つのFCボードからストレージへアクセスするようにすれば簡単に経路を冗長化できる。

もう一つはサーバ内に複数のSCSIボードを取り付け、それぞれのボードにディスクを接続し、この二つをOSからソフトミラーしてやること（昔の商用UNIXマシンはほとんどこの構造になっていた）

１、２どちらかへ対処することで、ほとんど対応できるのでサーバクラスタを行う場合は必ず対処しておこう。

参考
RAID５構成の内蔵ディスクのディスク障害時の動作について

（続く予定）

100年間デジタルデータを保持するためのガイドライン

ストレージネットワーキング・インダストリ・アソシエーション(Storage Networking Industry Association　略称=SNIA ) が公開しているデータ長期保存のためのガイドライン。

http://www.snia-j.org/tech/save/hb.html

情報を記録する媒体は遥か古代から進化し、記録密度は飛躍的な発展を遂げてきた。

石版 →羊皮紙→紙→アナログ磁気メディア→デジタル磁気メディア

しかし記録密度が上がるにつれ、記憶可能な時間は短くなっている。特に現代のデジタル磁気メディアは複数の要因により長期保存にはあまり向いていない。

「データを保存する」とは、SNIAの定義から引用すると、

1．物理的にアクセス可能

2．論理的に利用可能

3．利用したデータに破損がない

この3つの条件を満たした状態を「データを保存する」と定義している。

数年単位で考えるならば、それほど難しいハードルではないが、50年、100年という単位で考えると実に難しい。

紹介したドキュメントにはデータの長期保存について、考慮すべき要因が網羅的に記載されているので、興味があればご一読を。