Sun Cluster 3.2

動作環境：SPARC Enterprise, S series

| 概要 | 機能説明 | システム構成 | 商標について | 他のソフトウェア |

概要

Sun Cluster 3.2は多重化したハードウェア/ソフトウェアのコンポーネントを制御することにより、ハード障害/ソフト障害に対応し、高可用性(HA:High Availability)を目的としたクラスタシステムを実現するSun Cluster 3.1 の後継ソフトウェアです。Sun Cluster 3.2はSun Cluster 3.1に比べ、Service Management Facilityとの連携強化により、Solaris 10 OS (*)との融和が進化し可用性がより向上しています。

* Solaris™ Operating SystemはSolaris OSと表記します。

【セールスポイント】

• VERITAS Storage Foundation Standard 5.0(VERITAS Volume Manager/VERITAS File System)をサポートします。
• 共有ディスクへのパスに障害が検出された場合に、ノードを自動的に再起動をするための設定ができます。
• SMF（Solaris Service Management Facility）サービスとの統合により、Solaris 10 OSのSMFによって管理されるアプリケーションの可用性を容易に高めることができます。

機能説明

【機能詳細】

1. takeover

• takeoverとは主系ノードの障害時などに従系ノードにIPアドレス、データサービス、必要に応じてデータ(共有ディスク)の引継ぎを行い運用を継続させる機能です。
• takeoverを行う方法は2種類存在します。
  • failover
    ノードを相互監視し、従系ノードが主系ノードの障害を検知した場合は自ノードへ運用を自動的に引継ぎます。また、自ノードの監視も行っており、障害によっては自ら運用継続を放棄して従系ノードへ引継ぐ場合もあります。
  • switchover
    ハードウェアの交換など、オンラインでメンテナンスを行う場合は手動で運用の引継ぎを行います。

2. Resource Group/Device Group

• Resource Group
  各ノードの物理IPアドレスに対して、論理ホストには各ノード間で引継ぎ可能な論理IPアドレスを設定します。Sun Cluster 3.2ではこの論理IPアドレスとデータサービスをグループ化(Resource Group)して使用します。Resource Groupをノード間で移動させることにより運用するノードを切り替えることができます。またクライアントから論理IPアドレスに対してアクセスさせることにより、フェイルオーバが発生してResource Groupがノード間を移動した場合でもノードを意識せず継続使用が可能となり、クライアントからの透過性を実現します。
  
  
• Device Group
  VERITAS Volume Managerにより共有ディスクをグループ化(ディスクグループ)し、ディスクグループをさらにDevice Groupに登録することで使用可能となります。Device Group(ディスクグループ)へのアクセスは1ノードのみ可能であり、他ノードと排他的にアクセスすることとなります。障害発生時はDevice Group(ディスクグループ)のアクセス権が移動することにより他のノードでも共有ディスクに対してアクセス可能となります。
  
  

障害発生時、Resource Groupのフェイルオーバのみで運用が継続可能な場合、"1.フェイルオーバ"で示す共有ディスクの引継ぎは行われず、フェイルオーバの時間を短縮します。

3. Global Device

• Global Deviceを使用して、クラスタ内のあるノードに接続されているデバイス(ディスク、テープ、CD-ROM装置など)を、物理的に接続されている／いないに関わらず、クラスタ内の全てのノードから、あたかもローカルに接続されているデバイスのように同じデバイス名でアクセス可能にします。
  

4. Cluster File System(Global File System)

• Global Deviceをファイルシステムで使用すると、同一ファイルシステムをクラスタ内の全てのノードにマウントさせることができ、全てのノードから同じパス名でファイルにアクセスできるようになります。これをCluster File System(もしくは Global File System)と呼びます。
  
  
  

5. クラスタ構成

• 2から16ノードにおいて多様な運用形態をサポートします。以下に2ノード形態時、3ノード以上の形態時の各々の代表的な運用形態例を示します。ここで示すのは動作内容です。接続形態はシステム構成を参照してください。

• HAシステム(2ノード構成)
  2ノード構成時のHAシステムには非対称系(運用待機系)と対称系(相互待機系)が存在します。
  
  • 非対称系(運用待機系)
    主系サーバで全業務を実行し、主系サーバが障害でダウンした場合、従系サーバで全業務を継続します。対称系と比べて設計が容易です。
    
  
  • 対称系(相互待機系)
    各サーバで異なる業務を実行し、片サーバが障害でダウンした場合、残りのサーバで全業務を継続します。フェイルオーバ時に片系で両方の業務を行う必要があるため、業務負荷を考慮した設計が必要となります。
    
  
• HAシステム(3ノード以上)
  3から16ノードのHAシステム構成は N+1トポロジ、Clustered PairsトポロジとPair + Nトポロジをサポートします。 以下に4ノード構成時の例を示します。
  • N+1トポロジ
    この構成は運用ノードN個に対して、バックアップノード1個で運用を行う構成です。運用ノード(主系ノードX)のいずれかに障害が生じた時はバックアップノードに引継ぎを行い運用を継続します。よって、複数の主系ノードに障害が生じた場合のことを想定してバックアップノードの資源を設計する必要があります。
  
  • Clustered Pairsトポロジ
    この構成は2ノード構成を複数併せたようなイメージです。2ノードクラスタが対となった形で互いのノードでフェイルオーバが可能となります。ただし、クラスタ内に含まれる全てのノードがクラスタインターコネクト(プライベートネットワーク)により相互監視が行なわれます。
  
  • Pair + Nトポロジ
    この構成は共有ディスクを物理的に接続しないノードを含む構成です。共有ディスクを接続しないノードから共有ディスクへのアクセスはGlobal Device(Cluster File System)を使用します。また、データ(共有ディスク)は使用せず、起動、停止のみのアプリケーションにおいても使用可能です。
  

6. ディスク管理

• ディスク管理ツールとしてHAシステムではVERITAS Volume Managerをサポートし以下の機能を実現します。
  • システムディスクのミラーリング
  • サポートされるソフトRAIDは、1、0+1、1+0構成です。
  • ディスクアレイ装置あるいはマルチパック装置の筐体間でRAID 1(ミラーリング)します。また、異なるコントローラー間でのミラーリングによりコントローラー障害時でも処理が継続できる冗長性を持たせることもできます。
  • RAID構成時にスペア用のディスクを用意することによって、ディスク障害時に自動的にディスクを置き換えることができます。
  • ディスクアレイ装置もしくはマルチパック装置内のディスクは全て複数のディスクグループにグループ化して使用します。RAID構成は同一グループ内で行います。

7. パブリックネットワーク／クラスタインターコネクト(プライベートネットワーク)

• パブリックネットワーク
  • クライアントがデータサービスに接続するために使用されるネットワークでGigabit Ethernet/Fast Ethernetが利用できます。
  • Solaris OSの機能であるIPMPにより、パブリックネットワークに冗長性を持たせることができます。
• クラスタインターコネクト(プライベートネットワーク)
  • クラスタノード間のクラスタ制御通信およびデータサービス通信に使用されるネットワークでGigabit Ethernet/Fast Ethernetが利用できます。
  • 2～6本のクラスタインターコネクト(プライベートネットワーク)をサポートします。

8. 障害検知

以下の障害検知の機能を備えています。

• ネットワーク監視
  マルチパッシングデーモン(in.mpathd)にてパブリックネットワークの状態を監視します。バックアップインターフェースが設定されていれば異常検出時にネットワークインターフェースが切り替わります(IPMP)。切り替わるネットワークインターフェースが存在しなければtakeoverします。
• ハートビート監視
  パブリックネットワーク(LAN)とは別にノード間をローカルな専用ネットワークで接続します。それをクラスタインターコネクト(プライベートネットワーク)と呼びます。クラスタインターコネクト(プライベートネットワーク)を使用して定期的にメッセージを送受信し、各ノードが互いに監視しています。相手ノードのメッセージが一定時間内に受信できないと、相手ノードがダウンしたと判断し、takeoverなどの処理を行います。
• データサービス監視
  データサービス異常を検知したら、restart、もしくはtakeoverなどを行います(restartとは、takeoverを行わず自ノードでデータサービスを再起動すること)。データサービスの監視はデータサービスごとに設定されるフォールトモニタが行います。よって複数のデータサービスを運用する際にはデータサービスの異常により別々にtakeoverできます。
• 共有ディスクパス障害監視
  全ての共有ディスクへのパスに障害が検出された場合に、ノードを自動的に再起動をするための設定が可能です。これによりディスクパスの障害発生時の対応が即座に実行され、サービスの可用性を向上させることができます。

9. Resource Management API

• Resource Management APIを用いることによりユーザアプリケーションをクラスタシステム管理下のデータサービスとして扱えるようになります。
  • Data Service API
    ユーザアプリケーションをクラスタシステム管理下にデータサービスとして登録できます。HA化されたユーザアプリケーションは障害時、自動的にリスタートしたり他ノードにフェイルオーバしてクライアントにサービスを提供し続けます。
  • Fault Monitor API
    APIでフォールトモニタプログラムを作成することにより、ユーザアプリケーションをデータサービスとして監視することができます。これによりユーザアプリケーションで異常が発生すると自動的にフェイルオーバさせることができます。
  • Sun Clusterエージェントビルダー
    データサービス用のエージェントを作成する開発ツールキットです。ウィザード機能にてGUIベースでエージェントを作成することができます。

10. SMFサービスとの統合

• Sun ClusterがSMF(Solaris Service Management Facility)と緊密に統合されたことで、SMFによって管理されるアプリケーションをSun Clusterリソース管理モデルの中にカプセル化することができます。これによりSolaris 10のSMFによって管理されるアプリケーションを新たにCluster対応に書き直すことなく、容易にSun Cluster上で可用性を高めることができます。

【利用による効果】

• より高い可用性を持つシステムを構築できます。
• ダウンタイムを大幅に削減できます。

【新規機能】

版数	新規機能
3.2	Sun Cluster 3.1 8/05からの新規機能 VERITAS Storage Foundation Standard 5.0(VERITAS Volume Manager/VERITAS File System)をサポート 共有ディスクへのパス障害の監視をサポート SMFサービスとの統合

システム構成

本製品ではノード数、ディスクアレイ装置の種類、台数によって構成が異なります。

• 2ノード構成時

• 3から16ノード構成

ノードとディスクアレイ装置の接続形態によりN+1,Clustered Pair,Pair + Nが可能です。ターミナルコンセントレータおよびパブリックネットワーク(業務LAN)への接続は2ノード構成と同様です。以下の図中では省略していますが管理ワークステーションおよびターミナルコンセントレータは2ノード構成時と同じ接続形態にて必要となります。

• N+1

• Clustered Pair

• Pair + N