高信頼性DB構築サービス

高信頼性DB構築サービス

セキュアな高信頼性ストレージ・DBサーバ構築サービス on AWS

AWS

AWS上で、セキュアな、ミッションクリティカルなストレージ、DBサーバを実現いたします。また、 マルチAZ(データセンタを跨いだ冗長化)も対応可能です。

  • AWS上でHA構成をとる場合、既存のVIPを利用する方法が使用できません。
  • 従来のクラスタウェアではインターネット経由でAWS APIを実行して擬似VIPを操作する必要がありストレージやDBサーバがインターネットとの通信必須、という非常識な(非セキュアな)要件が存在していました。
  • 弊社が提供するHA構成では、ELBを活用することで、インターネット接続不要なセキュアなストレージ、DBサーバをご提供いたします。

PDF資料もございます。AWS+HA構成資料をご覧下さい。

高信頼性DB構築サービス on IBM SoftLayer

高信頼性DB構築サービス on IBM SoftLayer

ミッションクリティカルなDBサーバをSoftLayerを使用して、データロスの少ない事業継続性/DR対策を実現いたします。大容量なファイルサーバのHA(高可用性)構成も実現します。

  • 最強のI/O性能を発揮するデータベースHA構成(シェアード・ナッシング型
  • 共有ストレージiSCSI Target(HA)構成(ネットワーク越しのミラーリング)
  • VCSによるOracleHA構成(ローカルディスクへのバックアップ)
  • 遠隔地データ保管(Disaster Recovery)を実現するデータ保全のための構成

PDF資料もございます。SoftLayer+データベースHA, iSCSI Target HA構成資料をご覧下さい。

BLOG メシの種

松尾商店では
経験豊富な弊社のエンジニアが
お客様のニーズに合わせた
様々なご提案をいたします。

データベースの典型的なHA構成

データベースの典型的なHA構成

データベース・インスタンスはサーバ1でのみ稼働しています。クライアントは、サーバ1が保持しているVIPに向けてアクセスします。サーバ1に障害が発生した場合、サーバ2にてVIPとデータベースインスタンスを起動します。

  • 豊富な実績があり、ノウハウの蓄積も多く、理解しやすい構成。
  • 共有ディスクが単一障害点(SPOF、Single Point Of Failure)となっている。必然的に、信頼性の高い(=高価な)共有ディスクを用意する必要が出てくる。共有ディスクへのマルチパスも必須と考えると、益々コスト高となる。
  • サーバ1がActiveの状態であるにもかかわらず、何らかの事情でサーバ2も同時にActiveとなった場合、スプリット・ブレイン状態となる。この場合、共有ディスク上のデータはほぼ確実にクラッシュするので、信頼性の高いクラスタウェア・ソフトを使用する必要がある。
  • Stand-by機がActive機に昇格した直後は、データベース・アクセスの高速化に寄与しているデータキャッシュが空となっている。データキャッシュが安定するまでには、数時間かかると言われている。

データベースのレプリケーションによるクラスタ構成

データベースの典型的なHA構成
  • 高価な共有ディスクが不要となる。
  • サーバ1がActiveの状態であるにもかかわらず、何らかの事情でサーバ2も同時にActiveとなった場合、スプリット・ブレイン状態となる。この場合、1号機と2号機でデータの一貫性が失われている。手動で一貫性を回復させる必要がある。ただし、スプリット・ブレインの発生状況は少なく、それよりもレプリケーション遅延の問題を考慮すべき場面が増える。
  • Slave機がMaster機に昇格した直後でも、データベース・アクセスの高速化に寄与しているデータキャッシュが効果を発揮できる。PostgreSQL9.1以降とPacemakerによる構成を推奨する。データベースが必要となった場合、まず最初にこの構成が取れないかを検討したい。
データベースの典型的なHA構成

データベースの参照に関して負荷分散を行うためには、アプリケーションが対応している必要があります。発行するSQLに合わせて接続先を変更したり、レプリケーションの遅延についても設計に織り込む必要があります。MySQLには、オンライン・バックアップの取得が保障されていないという問題があり、レプリケーションの構成が必須となる場面が多いです。レプリケーションのスレーブは読み取り専用として一般クライアントに公開可能となっています。障害発生時の回復操作を考えた場合、最低3台のSlaveを用意することを推奨します。

負荷分散を実現するためにロードバランサを用意する必要があります。keepalivedをActive、Stand-byで構成することを推奨します。各クライアントにHAProxyというソフトを導入するという構成もあります。レプリケーションの監視には、MHAの使用を推奨します。

DRBDによるHA構成

DRBDによるHA構成

共有ディスクが不要な構成であり、ネットワーク越しのRAID1を実現しています。 データベース・インスタンスはサーバ1でのみ稼働しています。 クライアントは、サーバ1が保持しているVIPに向けてアクセスします。DRBDは両機で稼働し、データの書き込みをブロック単位でPrimaryからSecondaryへレプリケートしています。

サーバ1に障害が発生した場合、サーバ2にてDRBDをPrimaryへ昇格させVIPとデータベースインスタンスを起動します。

  • 高価な共有ディスクが不要となる。データベース以外にも利用できる。
  • サーバ1がActiveの状態であるにもかかわらず、何らかの事情でサーバ2も同時にActiveとなった場合、スプリット・ブレイン状態となる。この場合、1号機と2号機でデータの一貫性が失われている。手動で一貫性を回復させる必要がある。
  • Stand-by機がActive機に昇格した直後は、データベース・アクセスの高速化に寄与しているデータキャッシュが空となっている。データキャッシュが安定するまでには、数時間かかると言われている。

サーバ内のローカル・ストレージ活用によるデータ持続性の向上(Oracle編)

サーバ内のローカル・ストレージ活用によるデータ持続性の向上(Oracle編)

データベースにデータを保存する理由の1つは、失われたら困るデータの耐久性、持続性(Durability)を期待しているからです。

トランザクションが完了したら、その結果が記録され、システム障害などによって失われることがないように、できるだけ担保する必要があります。

Oracleのデータベースは、データファイル、制御ファイル、REDOログによって構成されています。データファイルはバックアップを取得することができます。

REDOログは、アーカイブ・ログというバックアップが自動的に取得できるようになっています。

REDOログは、同時に複数個所に書き込むことが可能となっているので、最新のものが複数存在します。これらが揃うと、データベース本体が損傷しても、最新状態までリカバリすることが可能となります。これらの保存場所をFlash Recovery Areaと呼び、最近はFast Recovery Areaと呼びます。

共有ディスクが1つしか用意できない場合、どこをFlash Recovery Areaとするかという問題があります。データベース本体がある場所と同じところにFlash Recovery Areaを設定しているシステムも見かけますが、あまり意味がないように思われます。通常は、バックアップサーバを別途設け、そちらに保存することになります。

最近では、テープ装置を使うことが減り、D2D2T(ディスクからディスクへ、ディスクからテープへバックアップ)ではなく、D2D2D(ディスクからディスクへ、ディスクからディスクへバックアップ)という手法がとられるようになりました。最初のDが共有ディスクを指し、次のDがバックアップサーバのディスクを指し、最後のDが別のバックアップサーバのディスクを指します。バックアップサーバが2台登場しますが、この役割をデータベースサーバのローカル・ストレージに持たせる構成をここでは考えます。

サーバ1にてデータベース・インスタンスを起動する直前に、共有ディスク上のREDOログおよび制御ファイルをサーバ1のFlash Recovery Areaにコピーするように構成します。アーカイブログは随時サーバ1からサーバ2にコピーします。

バックアップ時には、サーバ1のFlash Recovery Areaへのバックアップをサーバ2のFlash Recovery Areaへコピーします。

サーバ1からサーバ2へのフェールオーバ時には、共有ディスク上のREDOログおよび制御ファイルをサーバ2のFlash Recovery Areaにコピーしてからデータベース・インスタンスを起動します。これらの制御にSymantec社のVeritas Cluster Server(VCS、Veritas Storage Foundation HAに含まれる)を推奨します。

この構成のメリットは、登場するノードが少なくて済むという点と、共有ディスク全損時であっても最新データが失われることがなく、緊急避難的にサーバ1のみでデータベースを起動させてしまうこともできる点にあります。

サーバ内のローカル・ストレージ活用によるデータ持続性の向上(Oracle編)

Oracle ASM は、もともとはOracleデータベースのストレージの効率的な利用を目的に開発されたが、最近は汎用的な利用も可能となっています。DRBDはいわばネットワーク越しのRAID1を単純に実現していますが、Oracle ASMは、ストレージのスケールアウトを実現するものであります。

容量が足りなくなれば、共有ストレージを増やしていけばよいです。ストレージの速度指標の1つであるIOPSを上げたい場合には、HDDの球数を単純に増やせばよく、データを書き込む先を二重化もしくは三重化することもできます。共有ディスクはどれも高価なものとなりがちですが、Oracle ASMを利用すると安価な共有ディスクを選びソフトウェアで多重化することで安全性を確保するという設計が可能になります。利用するためのライセンスは、以下の場合は無料となります。

  • Oracle Linuxを使用し、そのサポートに入っている。
  • Oracle Databaseに利用する(無償版のExpress Edition含む)。

Oracle LinuxはCentOSと同じような位置づけのもので、セキュリティ対応更新パッケージも無償で利用可能です。プレミア・サポートに加入する場合は、Red Hat Enterprise Linuxの半額程度になります。その場合、サーバ再起動なしでカーネル・モジュールへパッチ適用するという選択肢も利用可能となります。

  • 【納品物:標準メニュー】
    仕様書、パタメータシート、試験項目兼結果報告書
  • 【納品物:オプションメニュー】
    運用手順書、個別の手順書など
お問い合わせ
03-4405-5091
受付時間
10:00~19:00

PAGE TOP