Enterprise Watch
バックナンバー

日本オラクルに聞くデータベース向けストレージ技術 [前編]


 Oracle Databaseは、世界で幅広く使われているデータベースソフトウェアのひとつだ。“ストレージの連載なのに、なぜOracleが登場するのか?”といぶかしがる読者もいるかもしれないが、データベースの格納される場所が“ストレージ”である点に注目していただきたい。データベースは、データ容量面からもトランザクション面からもストレージを酷使するアプリケーションの代表であり、少々荒っぽい言い方をすればデータベースを生かすも殺すもストレージ次第なのだ。

 そこで今回は、日本オラクル株式会社 マーケティング本部 システム製品マーケティンググループ 担当マネージャの山本哲也氏に、データベースという切り口から見た最新のストレージ技術についてお聞きした。前編では、Oracle Database向けに開発されたストレージ管理ソフトウェア「ASM(Automatic Storage Management)」の仕組みを取り上げていく。


日本オラクル株式会社 マーケティング本部 システム製品マーケティンググループ 担当マネージャの山本哲也氏

ストレージと密接に関係するOracle Database

 インタビュー開始早々、山本氏は「Oracleはストレージに深い関心があります。ご承知の通り、データは最終的にはストレージに格納されますので、データの保全性やパフォーマンスの観点からストレージを無視することはできません。そのため、新しいホストインターフェイスが出たらそれに対応しなければなりませんし、新たに発売されたストレージ機器がOracleできちんと使えることも確認しなければなりません。こうした取り組みに向けて、ストレージベンダとは以前より密に協業しています。また、Oracle Databaseを格納するストレージが、Oracleの視点から見て効率よく使えるようにする必要もあります。つまり、こうした数々の課題をクリアするためにも、Oracle自身がストレージに対して何らかのメスを入れる必要があったのです」と話す。

 データベースは、蓄積されるデータが大きくなればなるほど、そのサイズも拡大されていく。しかし、ストレージ側の制約によって、あるところで必ず限界に達してしまう。例えば、ディスク1本あたりの物理的な容量が10GBしかない場合、データベースはこの10GBまでしかサイズを拡大できない。新たにディスクを追加すれば、データベースを拡大することはできるものの、データベースを構成するファイルが増加し、管理コストが高いものとなってしまう。高価な大型ディスクアレイならば、RAIDに関してかなり柔軟な設定が用意されており、基本的にこうした心配は不要なのだが、Oracleは大型製品が持つこのような高い柔軟性を「低価格ストレージでも容易に実現し、システムのトータルコストを最小限に抑えられるようにしたい(山本氏)」のだという。

 そこで、Oracleが投入した新しいストレージ技術がASM(Automatic Storage Management)だ。ASMは、Oracle Database専用に開発されたストレージ管理ソフトウェアで、Oracleのストレージレイヤでストレージ仮想化を行ったり、仮想化されたストレージ間でデータの再配置を行ったりする役割を果たす。


 ストレージ仮想化とは、ストレージネットワーク上にある複数のストレージを束ねて仮想的なストレージプールを作成し、サーバー(システム管理者)からストレージの物理構成を隠ぺいする技術である。ストレージ仮想化を導入すれば、物理的なストレージの種類、配置、容量などに関わらず、ユーザーは必要に応じて必要な容量のストレージを利用できるようになる。ストレージ仮想化は一般にストレージ側に実装されるが、なぜデータベース側に実装する必要があったのか。山本氏は、次のように回答する。

 「Oracleを含め、データベースアプリケーションから見えるストレージの姿は、NFSでマウントされていれば何らかのディレクトリとして、WindowsのファイルシステムであればCドライブやDドライブといったドライブレターとして見えることになります。つまり、最終的にはファイルというものを意識しなければなりません」。

 「一般に、ストレージの柔軟性を高める手法としてストレージ仮想化が導入されていますが、ストレージ側にストレージ仮想化を実装しても、データベースアプリケーションから見るとストレージの姿に変わりはありません。そこで、Oracleは、データベースアプリケーション側にストレージ仮想化を実装する手法を採用しました。こうすれば、ストレージやOSから制約を受けることなくストレージ仮想化による恩恵を最大限に享受できます。例えば、従来では表領域を作成する際に、物理的なデータファイルを指定していましたが、ASMを使用した場合、仮想化された領域を指定するだけで済み、そのサイズや物理的な配置を意識する必要はありません」。


Oracle Database側でストレージ仮想化を行うことにより、ストレージやOSから制約を受けることなくストレージ仮想化による恩恵を享受できる(出典:Gyota Kondo - Engineer, Core Technology, Oracle Corporation Japan, Oracle Database 10g - Automatic Storage Management, OracleWorld Tokyo, カンファレンス F-7、以下同様)。
Oracle Databaseのストレージレイヤでストレージ仮想化を行うため、ボリュームマネージャ、ファイルシステム、データファイルにあたる部分はASMに吸収される形となる。

全ディスクでストライピングとミラーリングを行うSAME

 ASMは、SAME(Stripe And Mirror Everything)と呼ばれる手法に基づいて複数の物理ディスクを束ね、論理的なディスクグループを作成する。そして、制御ファイル、データファイル、一時ファイル、REDOログ、アーカイブログといった各種データベースファイルは、このディスクグループ上に作成されることになる。

 ASMを利用するには、通常のデータベースのインスタンス(DBインスタンス)に加え、ASMインスタンスを必要とする。ASMインスタンスは、物理ディスクに対するメタデータ管理を行うもので、DBインスタンスに対してデータの配置情報(マップ)やミラー情報を提供する役割を果たす。DBインスタンスは、ASMインスタンスからディスクグループ内の各種情報を取得することにより、物理ディスクとのデータアクセスが可能になる。

 SAMEは、ディスクグループを構成するすべてのディスク間でストライピングとミラーリングを行う手法だ。すべてのディスクに対してストライピングを行うため、ディスク全体に対してアクセスが均一になり、ディスクの特定個所にアクセスが集中するホットスポットが発生しない。ストライピング領域は割当てユニット(AU)単位で割り当てられる。ただし、データの特性に合わせてパフォーマンスを最適化できるように、各種ファイルごとにストライピング粒度を設定できる。ASMでサポートされているストライピング粒度は、AU単位でのストライピングを行うCOARSEと、より細かい単位でストライピングを行うFINEの2つである。


ASMインスタンスとDBインスタンスの関係を示したもの。ASMの機能を利用するには、ASMインスタンスを必要とする。
データベースに格納するデータ内容やアクセスの特性に合わせて、ストライピング粒度を設定できる。

ストレージ筐体の障害にも対応できる強固なミラーリング機能

 ただし、ストライピングによってストレージ容量とパフォーマンスを高められたとしても、ディスク障害によってデータが失われてしまっては本末転倒だ。そこで、SAMEではミラーリングも同時に行っている。一般にいうところのミラーリングは、オリジナルのディスクのデータ内容を別の保護用ディスクにもそのまま格納する操作を指すが、SAMEの場合、ディスク全体にデータを分散している関係で、それぞれのディスクがオリジナルディスクにもなり、保護用ディスクにもなる。

 そこでSAMEでは、AU単位でミラーリングを行っている。例えば、4台のディスクがあり、ディスク1にデータ1、ディスク2にデータ2、ディスク3にデータ3、ディスク4にデータ4が書き込まれている場合、データ1のミラーをディスク2、データ2のミラーをディスク3、データ3のミラーをディスク4、データ4のミラーをディスク1といったように、ミラーデータを分散してオリジナルとは別のディスクに書き込んでいく。こうすることで、すべてのディスクにまたがったデータ冗長化を行えるわけだ。

 ただし、ストレージ筐体内のディスクコントローラや電源などが故障すれば、同一の筐体内にある複数のディスクが同時にアクセス不能となる可能性もある。オリジナルデータとミラーデータがこれらのディスクに格納されていれば、当然ミラーリングの意味がなくなってしまう。そこでASMでは、ディスクコントローラや電源などのリソースを共有するディスクグループを障害グループと定義し、異なる障害グループに属するディスク間でミラーリングを行うように工夫されている。

 例えば、障害グループ1にディスク1とディスク2が、障害グループ2にディスク3とディスク4が属しているとする。ここで、ディスク1にデータ1、ディスク2にデータ3、ディスク3にデータ2、ディスク4にデータ4を格納した場合、データ1とデータ3のミラーはディスク3とディスク4に、データ2とデータ4のミラーはディスク1とディスク2に格納する。こうすることで、ある障害グループに含まれる全ディスクにアクセスできなくなっても、オリジナルデータとミラーデータが同時に失われることは回避できる。

 ASMでは、ファイルの種類に応じて二重化と三重化という2種類のミラーリングを選択可能だ。ミラーリングの多重度は、ディスクグループを作成する際にストライピングの粒度とともにテンプレート上で設定できる。ファイルの種類別にデフォルトのテンプレートも用意されているので、こちらを利用すればより簡単に設定を進められる。


SAMEのミラーリングは、一般的なRAIDミラーリング(RAID 1)と異なり、全ディスクにまたがった形で行われる。
リソース(ディスクコントローラや電源)を共有しているディスクグループは、リソースに障害が発生すると内部のディスクがすべてアクセス不能になる。そこでASMでは、異なる障害グループに属するディスク間でミラーリングを行うように工夫されている。
データファイルごとに標準で用意されているテンプレート。ディスクグループを簡単に作成したいときには、これらのテンプレートを利用すればよい。

ディスクグループの構成変更に合わせてデータを再配置

ASMは、ディスクグループの構成が変わったときにデータを自動的に再配置(リバランシング)する。
 ASMで秀逸なのは、ディスクの追加、削除、ディスク障害発生時など、ディスクグループの構成が変わったときに、データが自動的に再配置(リバランシング)されることだ。すべてのディスク間で均等にデータを再配置するため、特定個所にアクセスが集中することなく、常に最適なパフォーマンスと耐障害性が実現される。従来は、運用管理者がデータベースファイルの配置を最適化するために試行錯誤を繰り返す必要があったが、これが完全に自動化されるわけだ。

 例えば、最初は10GBのディスク1台からOracle Databaseの運用を開始した場合、これに10GBのディスクを2台追加し、ASMでストレージ仮想化を行うと、これらの3本のディスクにデータを再配置してくれる。データ量が9GBであるときには、3GBずつ均等にデータが配分される。もし、データベースを拡張していき、データ量が30GBに達しそうなときには、もう1台のディスクを物理的に追加し、ASMインスタンスでディスク追加のコマンドを実行すればよい。事実上、ストレージ容量を無制限に拡大していけることから(理論上の上限は8EB(EB=エクサバイト、GBの10億倍))、従来のストレージにはない高い柔軟性が生まれる。


 後編では、ディスクとしてNASを利用することの是非、Oracleとストレージハードウェアベンダ間の協業体制、Disk to Diskバックアップを容易にするフラッシュバック機能などについて取り上げる。



URL
  日本オラクル株式会社
  http://www.oracle.co.jp/


( 伊勢 雅英 )
2004/08/23 00:00

Enterprise Watch ホームページ
Copyright (c) 2004 Impress Corporation All rights reserved.