100ノードのクラスタをサポートする最新版Oracle　（2/4）

日本オラクル
一志 達也
2005/11/10

■Part 2　可用性の進化

　Part 1でも触れたように、いまや24時間運用は必然の要求です。そうなれば、やはりSingle Point of Failure（単一点障害）をなくすべく、クラスタを導入しようということになるでしょう。そうはいっても、少し前までのクラスタ導入といえば、技術的にもコスト的にも敷居の高いものでした。

　それが、ブレードサーバや安価なストレージ装置が登場したことで、クラスタ導入へのコスト面での敷居は一気に下がったのです。また技術的にも、インストーラや管理ツールの進化によって、数年前とは比べものにならないほど敷居が下がっています。その証拠に、国内でも1800に及ぶサイトでRACが稼働しており（日本オラクルの調査データ）、RACを扱うことのできる技術者も急増しています。

　シングルノードでのデータベース構築は、単に可用性が低いというだけでなく、リソースの無駄が多いというデメリットもあります。複数のシステム間でノードのリソースを共有できないため、どうしてもリソースの余裕を見込んでハードウェアを購入し、足りなくなったらハードウェア全体のリプレイスが必要になるためです。しかし、Oracle Database 10gで導入された「サービス」（ワークロードの自動管理機能）を利用すれば、複数のノード間でリソースの配分を動的に変更できます。

　つまり、これまで複数のノードでばらばらに運用していたデータベースを統合し、リソースが不足したら安価なブレードを追加して対処できるのです（図1）。これならば、リソースの利用効率も高く、可用性も高いデータベース環境が構築できます。しかし、多数のブレードやネットワークの管理、ノードの追加にかかる手間が問題となるのは否めません。

図1　複数のノード間でリソースの配分を動的に変更

　ちなみに、Oracle Database 10g Release 1では64ノードまで、Oracle Database 10g Release 2では100ノードまでのクラスタを構築可能です。これだけ多くのノードでクラスタを構築でき、リソースの動的な配分を可能にする機能はOracle Database 10g Release 2の大きな特徴です。

　このほかにも、Oracle Database 10g Release 2では、「FAN（Fast Application Notification）」や「FCF（Fast Connection Failover）」などの新機能が備わっています。これらについても紹介したいのはやまやまですが、ここではノードの追加を容易にする「プロビジョニング機能」について紹介することにしましょう。

時間をかけずにノードを追加

　これまで、RACへのノードの追加といえば、およそ1日かかってしまう作業でした。OSをインストールして設定を行い、パッチを適用してからOracleのソフトウェアをインストールし、データベースとしての設定やパッチの適用を行う。これは面倒以外の何物でもありません。仮に4台を一気に追加するとなれば、面倒を通り越して嫌になってしまいそうです。Oracle Database 10g Release 2のプロビジョニング機能を用いれば、こうしたインストールの手間をなくし、ノードの追加を短時間に終わらせます。

　プロビジョニングをひとことでいうと、データベース環境のコピーを行う機能です。管理者はあらかじめノードの追加に備えて、データベースのイメージを準備しておきます。これはOracleのソフトウェアと、その環境独特の設定が保存されたもの、と考えていいでしょう。いざノードを追加する際には、このコピーをサーバへと配布し、必要なパラメータの変更を自動的に行います。これによって、パッチを適用する必要はなくなり、面倒な設定作業からも解放されるのです。

　さらにLinux版では、「ベアメタル・プロビジョニング」と呼ばれる機能が提供されます。普通のプロビジョニングと異なるのは、OSのインストールさえも不要にしてしまう点です。ベアメタル・プロビジョニングでは、OSのインストールイメージも準備しておくことで、OSそのものをサーバに配布するところから自動で行われます。Linuxのインストールと設定、さらにパッチの適用にどれくらいの時間がかかるのか考えれば、その利便性を理解できるでしょう。

　この機能は、「Oracle Enterprise Manager 10g Release 2」を通して、利用可能です。データベースの機能追加に併せて、管理ツールも機能が強化されています。Oracle Enterprise Manager 10g Release 2による運用管理はこれまでのデータベース管理負荷を軽減しますので、ぜひ使いこなしてみてください。

もうメンテナンスのために停止しない

　RACであろうと何であろうと、データベースは絶対に停止するときがやってくる。それはこれまでの常識でした。データベースのバージョンアップやパッチ適用時には、RACでクラスタを構成していようとも、データベースを停止しなければならなかったのです。これは、データファイルの内部や、ディクショナリの内容が変更される以上仕方がありません。

　とはいえ、いくらメンテナンスのためでも、データベースを停止したくないと考えるのは当然です。そこで、Oracle Database 10g Release 2では、Data Guardを活用することで無停止でのメンテナンスを実現します。

　Data Guardは、アクティブ側とスタンバイ側の2つのデータベースをネットワークで結び、データを同期する機能です（図2）。

図2　アクティブ／スタンバイのデータベースをネットワークで結ぶData Guard サイト、ホスト、ストレージ、ネットワークなどの障害が発生すると、スタンバイ側に自動フェイルオーバーする。アクティブ側のデータベースは、リカバリ終了後に自動的に再構成される。

　本来は遠隔地にスタンバイのデータベースを設置して、災害対策に用いるための機能ですが、Oracle Database 10g Release 2からは異なるバージョン間でのデータ同期が可能になりました注2。これによって、片方をメンテナンスしてからデータを同期し、もう片方をメンテナンスして再度同期できるようになりました。

注2：ロジカル・スタンバイの場合に限られます。

　このように、順番にアップデート作業を行うことから、この機能は「ローリング・アップグレード」と呼ばれます。これを行う方法は以下のとおりです。

1. スタンバイ側と本番側の同期接続を切断する
2. スタンバイ側のデータベースをアップグレードする
3. スタンバイ側と本番側の接続を再開してデータを同期する
4. スタンバイ側を本番に切り替える（本番側の作業を行うため）
5. スタンバイ側と本番側の同期接続を切断する
6. 本番側のデータベースをアップグレードする
7. スタンバイ側と本番側の接続を再開してデータを同期する
8. 再度切り替えを行って本番側へ戻す

　ローリング・アップグレード機能（Data Guard）は、RACを構築しない環境でも利用できますが、両方を組み合わせることで現在最良の可用性を発揮する環境を構築できます。これまでもOracleデータベースといえば、高い可用性が評価されてきましたが、Oracle Database 10g Release 2になって、さらに高い可用性を実現できるようになったといえるでしょう。（次ページに続く）

2/4

Index
Oracle Database 10g Release 2 レビュー   100ノードのクラスタをサポートする最新版Oracle
	Part 1 ・Oracle Database 10g Release 2の進化とは
	Part 2 ・可用性の進化
	Part 3 ・安全性の進化
	Part 4 ・開発生産性の進化 ・まとめ

Oracle Database 10g Release 2 レビュー

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）