Translated message

A translation of this page exists in English.

Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

Red Hat Enterprise Linux のクラスター、高可用性、および GFS デプロイメントのベストプラクティス

更新 -

概要

High Availability アドオンと Red Hat Global File System (GFS/GFS2) を使用して、Red Hat Enterprise Linux クラスターをデプロイおよびアップグレードするためのベストプラクティスをこのドキュメントで説明します。

サポート対象のシナリオでも対象外のシナリオでも、それぞれのビジネスニーズを満たすために広範囲にわたってクラスターは使用されるため、クラスターをサポート可能かどうかを判断するために Red Hat によるレビューが必要な例外や条件を説明します。必ずしも例外が Red Hat によってサポート不可能というわけではありません。一部の例外はサポート不可能なシナリオをもたらしますが、それ以外では進める前に詳細なレビューと解析が必要です。

アーキテクチャレビューを得るために、What information is required for a Architecture Review of Red Hat Enterprise Linux High Availability and Resilient Storage? で提供されている指示に従ってください。

システム構成

  • Red Hat Enterprise Linux 5 以上 (High Availability または Resilient Storage アドオン)
  • Red Hat Enterprise Linux 6 以上 (High Availability または Resilient Storage アドオン)

追加のサポートリンク

以下の追加の記事では、いくつかの概念をより詳細に説明しています。必要に応じて参照してください。

アーキテクチャレビュープロセスの詳細:

一般的なアーキテクチャのサポート記事:

ハードウェアサポート情報:

サードパーティのハードウェア/ソフトウェアのインテグレーション:

デプロイメントのベストプラクティス

Red Hat High Availability および Resilient Storage アドオンを使用したクラスターのデプロイメントに対するベストプラクティスについて、このセクションで説明します。

クラスターアーキテクチャの選択

LAN のような遅延 (2 ミリ秒未満) が期待される単一物理サイトで実行するために、Red Hat Clustering は 設計されています。これは、Red Hat High Availability および Resilient Storage アドオンを実行するために最も推奨され厳密にテストされた設定として残り続けます。

しかし、Red Hat によるアーキテクチャーレビューを必要するさまざま方法でクラスターは使用されます。例えばマルチサイトクラスターおよびストレッチクラスターがあります。このいずれかをデプロイする場合は、デプロイを行う前に Red Hat へ連絡して、サポートの承認を得る必要があります。

マルチサイトクラスター

マルチサイトまたは耐災害クラスターは、異なる物理サイトで実行する離れたクラスターで、データを複製するために通常は SAN ベースのストレージレプリケーションを使用します。アクティブクラスターからパッシブクラスターへ手動フェイルオーバーで災害復旧するために、マルチサイトクラスターは通常アクティブ/パッシブ方式で用いられます。

ストレッチクラスター

ストレッチクラスターは、複数の物理サイトに広がるシングルクラスター設定です。

マルチサイトおよびストレッチクラスターのサポートに関する詳細は、Support for Red Hat Enterprise Linux Cluster and High Availability Stretch Architectures を参照してください。すべてのストレッチクラスターはアーキテクチャーレビューが必要ですので、ご注意ください。

クラスターノードのハードウェアの選択

High Availability アドオンによってサポートされているクラスターノードの最大数は 16 で、GFS2 および CLVM を含む Resilient Storage アドオンも同様です。詳細はこちらを参照してください。ただし、Red Hat のクラスターを使用しているお客様の多くは、最大数よりもはるかに少ないノード数を使用しています。一般的には、クラスターが 8 より多いノードを必要とする場合、サポート可能であることを確認するために、デプロイメントする前に Red Hat とクラスターアーキテクチャーを確認する事が推奨されます。Red Hat のクラスターリューションは、主に高可用性とコールドアプリケーションフェイルオーバーを提供するために設計されており、 高パフォーマンスや負荷分散クラスターのために使用されるというわけではではありません。

同種のハードウェア構成 (同様の条件の CPU ソケット、コア、メモリなどを使用したノード) が推奨されます。さまざまなハードウェア構成のノードで構成される不均一なクラスターが必要な場合 (たとえば、Node1 に 8 GB の RAM を持つ 4 つのプロセッサーがあり、Node2 には 2 GB の RAM を持つ 2 つのプロセッサーがある場合)、運用中に予期しない問題が発生しない事を確認するために、初期の概念実証クラスターを作成する事を Red Hat は推奨します。Red Hat によるレビューのために、デプロイ前にクラスターアーキテクチャーを提出する事もできます。

注意: 特定の商用ハードウェアの亜種 (サーバーおよびネットワークスイッチ) にはマルチキャストに関する既知の問題があり、大容量の POSIX ロック (fcntl) の動作を伴う GFS2 の使用がパフォーマンスと安定性の問題を引き起こします。

クラスターストレージの選択および設定

クラスターストレージハードウェアの選択に関する推奨されるベストプラクティスはありません。

クラスターで LVM を使用している場合:

  • HA-LVM を使用していて同期が必要な場合 (たとえばミラーにレッグを追加したあとや、失敗したミラーレッグをリストアしたあと)、ミラーを使用しているサービスを無効にすることが推奨されます。これが可能でない場合は、ミラー構築中のフェイルオーバーを避けるために、サービスをフリーズ (clusvcadm -Z) できます。ミラーの同期が完了したら、サービスをアンフリーズ (clusvcadm -U) する必要があります。
    • ミラーレッグの同期中にサービスのリロケートが発生した場合の既知の問題があります(特に bug #692186)。
    • アプリケーションがミラーを使用中に LVM ミラーリングの使用とミラーの同期が必要になる場合は、実際のアプリケーションの負荷を用いて非プロダクションクラスター上でこのプロセスをテストし、ミラーの同期による I/O パフォーマンスの低下がアプリケーションに悪影響を与えないことを確認することがベストプラクティスです。

クラスターに以下のいずれかのストレージ要素/機能が存在するか使用すると、お客様が計画されているクラスターデプロイメントのレビューが必要です。

  • 各ノードに 50以上のファイルシステムや論理ボリュームがマウントされている
  • GFS または GFS2 の使用
    • GFS および GFS2 はフルサポートですが、特定の環境やワークロードにのみ適しています。したがって、進める前にアーキテクチャーと GFS ファイルシステムの使用方法について Red Hat へ相談することが最も適切です。
  • ロックが集中的なワークロード

  • 費用効果のためにエンタープライズクラスの NFS ファイラー製品の置き換えとして GFS/GFS2 を使用

  • マルチパスストレージ

    • タイムアウト値の見直し
    • マルチパスとともに qdiskd を使用 (RHEL 6.3 以前)
  • 同一の物理ネットワークでストレージとネットワークトラフィックの混合 (たとえば、iSCSI リモートストレージと同一ネットワーク上にクラスターインフラストラクチャー/ハートビート/ロッキング)

  • 商用ハードウェア上のストレージレプリケーション

  • クラスターミラーリング (cmirror)

クラスターネットワークの設定

アプリケーションネットワークとクラスターハートビートのためのプライベートネットワークを分離することが強く推奨されます。これは可能な限り分離しなければなりません。

Red Hat Clustering は RHEL 6.4 上及びそれ以降でのみ、クラスターハートビートネットワークが失敗した時に追加的な回復力を提供する冗長リングの使用をサポートします。

Red Hat Clustering は、ネットワーク障害への対処として NIC ボンディングが用いられる事を推奨します。主にクラスターハードビートの高可用性を確保するためにボンディングは使用されますが、しかし通常はさらに複雑さももたらします。そのような場合、Red Hat はクラスターのネットワーク設定のレビューを推奨します。RHEL バージョン 4、5 および 6.0 から 6.3 では、サポートされるボンディングモードは mode=1 だけです。このモードは別名 active/passive モードです。6.4 以降では、ボンディングモード 0、1 および 2 がサポートされます。詳細は What are the supported bonding modes for Red Hat Clustering? を参照してください。

クラスターハートビートネットワークに使用されるネットワークインフラストラクチャーは切り換えられなければならず、スプリットブレインの状況へ導く恐れがある単一障害点をなくすために設定されなければなりません。たとえば、スイッチ A とスイッチ B 間の接続が 1つだけで、スイッチ A に 4 ノードそしてスイッチ B に 4 ノードの構成は推奨されません。さらに Red Hat は、2 ノードクラスターでノード間のクラスターハートビートネットワークにクロスオーバーケーブルの使用はサポートしません。

Red Hat Enterprise Linux 5 の Red Hat Clustering と、Red Hat Enterprise Linux 6 の High Availability アドオンは、クラスターメンバーシップにマルチキャストを使用します。プロダクションネットワークでマルチキャストを有効にできない場合、RHEL 5.6 以降では代替としてブロードキャストを検討できます。RHEL 6 では、代替のネットワークオプションを検討するために、デプロイメントへ進める前に Red Hat へ問い合わせる必要があります。

クォーラムディスクの使用と、クラスターメンバーシップタイマーの調整

ほとんどの場合、Red Hat Clustering で qdiskd の使用は任意です。クラスターハートビートネットワークから分離したネットワーク上にフェンスデバイスがある 2 ノードクラスターの設定はその例外で、フェンスの競合を引き起こすスプリットブレインの状況を避けるために、クォーラムディスクが必要です。この設定は Red Hat によるレビューが必須です。

4 ノードより多いクラスターでの qdiskd の使用はほとんど恩恵がなく、余計な複雑さが加わるため推奨されません。なぜなら、4 ノードより多いクラスターで同時に過半数のノードで障害が生じる事は全くありそうもなく、このような状況では qdiskd を使用しないことが推奨されます。4 ノードより多いクラスターで絶対に qdiskd を使用する必要がある場合は、Red Hat がクォーラムディスクの使用を確認して承認できるように、クラスターアーキテクチャーがレビューされる必要があります。

qdiskd を使用していて、カスタムのクォーラムディスクヒューリスティック (ストックヒューリスティックではない) を使用する必要がある場合は、 Red Hat によるレビューのためにアーキテクチャーを提出する必要があります。
クラスターメンバーシップに関連するデフォルトのタイマー値を変更することを Red Hat は推奨しません。これらの変更は他のタイマーやクラスター全体の動作に連鎖的に影響を与える可能性があります。クラスターメンバーシップのタイマー値のいずれか (たとえばトークンやコンセンサスタイムアウト) を調整する必要がある場合は、プロダクションとしてクラスターをデプロイする前に、Red Hat の承認を得る必要があります。

高可用性リソースの使用

現在のアクティブなアプリケーションインスタンスが失敗した場合に、コールドフェイルオーバーまたは再起動が必要となるアクティブ/パッシブモードのリソースが、Red Hat Clustering では最も効果的です。アクティブ/アクティブな負荷分散モードでのアプリケーションに対しては、Red Hat Clustering または Red Hat High Availability アドオンの使用は推奨されません。

サポートされいるファイルシステムのリソースは以下の通りです。

  • Red Hat Enterprise Linux 5: ext3、XFS (RHEL 5.7 以降)、GFS および GFS2
  • Red Hat Enterprise Linux 6: ext3、ext4、XFS (RHEL 6.2 以降)、GFS2

お使いのクラスターに以下のリソースタイプが必要な場合は、承認を得るために Red Hat へご連絡ください。

  • GFS/GFS2 上の NFS
  • アクティブ/アクティブ (負荷分散) のリソース設定
  • Red Hat Enterprise Linux に同梱されるサードパーティソフトウェアのリソースエージェント (SAP、Sybase ASE、Oracle 10g/11g) の使用
  • DRBD の使用 (Does RHEL-6 support DRBD? を参照)
  • Red Hat Enterprise Linux に同梱されていない、カスタムリソースエージェント
    • 注意: カスタムのリソースエージェントは認められていますが、Red Hat Enterprise Linux に同梱されているリソースエージェントだけが Red Hat によって完全にサポートされます。LSB 準拠 init スクリプトでの script リソースエージェントの使用は、追加レビューは必要ありません。

GFS および GFS2 の使用

GFS および GFS2 ベストプラクティスの詳細については、How do I debug a GFS/GFS2 performance problem? を参照してください。

その他

以下の機能/シナリオも Red Hat によるお客様のクラスター設定のレビューを必要とします。

  • Red Hat Enterprise Linux 5 上で Oracle RAC + GFS のデプロイ

  • Xen 上の仮想マシン内で Red Hat High Availability アドオンソフトウェアを実行 (Red Hat Enterprise Linux 5 ホストおよびゲストでのみサポートされます)

  • 1 ノードまたは 2 ノード障害が残りのマシン上の RAM や CPU のオーバーコミットを引き起こす恐れがある、ベアメタルクラスターが管理する高可用性仮想マシン。

サポート対象外の項目

以下の機能/シナリオはサポートされない構成をもたらします。

テクノロジプレビューとしてマークされてる項目は現在サポートされておらず、Red Hat Enterprise Linux の将来のリリースで完全にサポートするために Red Hat が取り組んでいることを示しています。

特に明記されていない限り、これらのアイテムは Red Hat Enterprise Linux 5 および Red Hat Enterprise Linux 6 のデプロイメントそれぞれへ適用します。

  • アーキテクチャー全体

    • GFS2 上の Oracle RAC はサポートされていません。
    • メジャーリリース間での段階的/ローリングアップグレードはサポートされていません。たとえば、Red Hat Enterprise Linux 5 から Red Hat Enterprise Linux 6 へのローリングアップグレードです。

  • ハードウェア

    • 16 より多いクラスターノード数はサポートされません。
  • ストレージ
    • クラスターストレージに MD RAID の使用はサポートされてません。
    • ボリュームが 1 つのノードで排他的にアクティベートされていない限り、クラスター化された論理ボリュームのスナップショットはサポートされません (RHEL 5.7 の lvm2-2.02.84-1.el5 リリースまたは RHEL 6.1 の lvm2-2.02.83-3.el6 リリース)。
    • GFS/GFS2 をミラーするために複数の SAN デバイスの使用、またはクラスターノードの異なるサブセット間でクラスター化された論理ボリュームはサポートされません。
  • ネットワーク
  • 高可用性リソース
    • GFS または GFS2 上のいずれかでアクティブ/アクティブ設定の NFS の使用はサポートされません。
    • 同一の GFS/GFS2 インスタンス上で NFS および Samba の使用はサポートされません。
  • 仮想化ゲスト上での Red Hat High Availability アドオンまたはクラスターの実行は限定されたサポートです。詳細は、Virtualization Support for High Availability in Red Hat Enterprise Linux 5 and 6 を参照してください。

Comments