SE RACのメリット、デメリットをしっかり把握する：Oracle SE RACで手軽に高可用性システム（1）（1/4 ページ）

　ご存じの方も多いかと思いますが、Oracle9iではEnterprise EditionのオプションであったReal Application Clusters（以下、RAC）が、Oracle 10gからStandard Editionでも使えるようになりました（以下、SE RAC）。これによってRACを導入する際の敷居は大幅に下がったといえるでしょう。ただし、SE RACにはいくつか制限があります。Oracle 10gの新機能であるAutomatic Storage Management（以下、ASM）の使用や、RAC環境に搭載可能な最大CPU数が限定されていることなどです。

　しかしRAC環境として普通に使用する範囲では問題ありませんし、SE RACの機能にも十分なメリットがあります。本連載では、SE RACを使用する際の制限をよく理解し、その特性を生かした環境構築を目標としています。

なぜRACなのか 〜Oracleの可用性と親和性〜

　可用性とは、あまり聞き慣れない言葉かもしれません。そもそも可用性とは「使える」ということであり、システムでいえば「稼働している（動いている）」ということです。どのようなシステムでも、「壊れないシステム」を作るのは大変です。さまざまな障害の可能性は常に付きまといますので、日々システムを監視する必要があります。

　そこで、通常は「壊れにくいシステム」や「壊れても、すぐに復旧できるシステム」を考えて設計します。この2つは、MTBF（平均故障間隔：Mean Time Between Failure）やMTTR（平均修復間隔：Mean Time To Repair）などといわれます。「壊れにくい」というのは、MTBFが長いということ。平均故障間隔というとイメージしにくいですが、「故障（するまでの）間隔」、転じて「稼働（している）時間」を指します。もう1つの「壊れても、すぐに復旧できる」というのは、MTTRが短いということ。システムが故障してから修復するまでの時間は、短ければ短いほど良いシステムといえます。つまり「MTBFが長く、MTTRが短い」システムが、可用性の高いシステムとなります（図1）。

図1　MTBFとMTTR

　Oracle Databaseで可用性の高い構成は主に、HA（High Availability）Cluster構成とRAC構成です。HA Cluster構成とRAC構成の違いは、大きく分けて2つあります。1つは、前述したMTTRです。HA Cluster構成もRAC構成も、複数のサーバが1つのデータベースに対して処理を行えることに違いはありません。しかし稼働しているサーバの台数は、HA Cluster構成が常に1台なのに対し、RAC構成では常時複数台（2台以上）が稼働しています（図2）。

図2　HA Cluster構成とRAC構成の違い

　そのため障害発生時、HA Cluster構成では待機中のサーバを起動してからクライアントを再接続させます。しかしRAC構成の場合、常時2台以上が稼働しているため、即座にクライアントを正常稼働中のサーバに再接続させられます。つまりHA Cluster構成と比べ、待機中のサーバを起動させなくて済む分、復旧時間を短縮できます。

　2つ目の違いは親和性です。親和性というのも、あまり聞き慣れない言葉かもしれません。いい換えると、ハードウェアやソフトウェアの相性です。システムに可用性を求めると、そこにはクラスタウェアを導入する必要が出てきます。クラスタウェアにはいくつもの製品があり、対応したアプリケーションも多数あります。そのため、いざシステムを構築するとマルチベンダ環境になることが多々あります。マルチベンダ環境は、各社製品のメリットを生かし、安価で効率的なシステムの構築が可能です。しかしその半面、各社製品間の相性を確認したり、障害発生時の切り分けを考慮する必要があります。

　その点オラクル社は、Oracle 10gから「Oracle Clusterware」注1というクラスタウェア製品をリリースしました。このOracle ClusterwareはRAC構成での使用を考えて作られているため、当然Oracle Databaseとの相性が良いです。そして、RAC構成に特化して作られているため、HA Cluster構成では使用できません。

　つまり、データベースにOracle、クラスタウェアにOracle Clusterwareを用いたRAC構成を組むことにより、可用性と親和性の両方を実現することが可能となります。