 |
||||||||||||||||||||||
|
||||||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||||||
|
||||||||||||||||||||||
| はじめに | ||||||||||||||||||||||
|
「情報化社会」とは言い換えればデータ依存の社会です。今日ではデータがなければビジネスは成立しないといっても過言ではありません。日増しに増加していくデータにどう対処していけばよいのか、その重要なデータを保持するデータベースシステムの構成は各企業においても頭を悩ますところでしょう。 「万が一データベースがダウンしてしまったら？」 考えれば考えるほど頭が痛いというのが本音ではないでしょうか。 これまで一般的だった単体形式では拡張性、可用性の部分で大きな問題があります。拡張しようにも、できることはせいぜいCPU／メモリ／ハードディスクの増設程度と、ハードウェアレベルでの拡張には限界がつきまといます。 可用性についていえば、1度サーバがダウンしてしまったら復旧するまで手出しができません。大切なデータを保持するシステムを任せるにはスタンドアロンではあまりに心許ないでしょう。 この悩みを解消するのがクラスタリングシステムです。サーバ複数台で1つのシステムとして構成できれば拡張性・可用性は飛躍的に向上します。リソースが足りなくなったらノードを追加すればよいのです。残りのサーバがバックアップすることで、業務を継続できます。 万が一に1つのノードがダウンしてしまっても他のノードで処理が継続できます。このクラスタテクノロジーをデータベースレベルで実現するのがOracle Real Application Clusters（Oracle RAC）です。 |
||||||||||||||||||||||
| 他社データベースクラスタ技術との比較 | ||||||||||||||||||||||
|
データベースのクラスタ化を実現する方式として代表的なものには「シェアードナッシング」方式と「シェアードディスク」方式があげられます。データベースのクラスタ化はオラクル以外の各社でも積極的に取り組んでいますが、その多くは「シェアードナッシング」方式で実現されています（図1）。  図1：シェアードナッシングの概念図 この方式ではクラスタシステム内の各ノードがそれぞれ独自のディスクリソースを使用しています。そして該当クラスタシステム上のデータは物理的に切り分けられて保管され、各ノードがそれぞれで固有のデータを管理します。そのため、ノード間の負荷分散はデータベース設計段階でのデータ分割度に依存します。 クラスタシステム内のノードに障害が発生した場合、システムは障害発生ノードで実行中だった処理を1度キャンセルします。そして障害発生ノードで保持していたディスクを他の生存ノードに切り替えるなどの対処を実施した後、処理の再実行することで対応します。そのため、可用性の確保にはクライアントアプリケーション側の設計においても相応のロジックを意識する必要があります。 一方、特殊なハードウェアを必要としないことや並列度を上げる（ノード数を増やす）ことがI/O分散に直結するため、スケーラビリティ（拡張性）の面では非常に高い能力を持つ方式といえます。 |
||||||||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
-
-
連載
