Oracle RACおよびAccelStor Shared-Nothingアーキテクチャに基づくフェイルオーバーソリューションの構築

かなりの数のエンタープライズアプリケーションと仮想化システムには、フォールトトレラントソリューションを構築するための独自のメカニズムがあります。 特に、Oracle RAC（Oracle Real Application Cluster）は、負荷のバランスを取り、サーバー/アプリケーションレベルでフォールトトレランスを提供するために連携して動作する2つ以上のOracleデータベースサーバーのクラスターです。 このモードで作業するには、一般的なストレージが必要であり、その役割は通常ストレージです。

既に記事の 1つで検討したように、ストレージシステム自体には、複製されたコンポーネント（コントローラーを含む）が存在するにもかかわらず、主に単一のデータセットという形で障害点が残っています。 したがって、信頼性要件を高めたOracleソリューションを構築するには、「Nサーバー-1つのストレージ」スキームを複雑にする必要があります。

もちろん、まず、どのようなリスクに対して保険をかけようとしているのかを判断する必要があります。 この記事では、met石が到着したなどの脅威に対する保護については考慮しません。 したがって、地理的に分散した災害復旧ソリューションを構築することは、以下のいずれかの記事のトピックとして残ります。 ここでは、サーバーキャビネットのレベルで保護が構築される、いわゆるクロスラックディザスタリカバリソリューションについて説明します。 キャビネット自体は、同じ部屋に配置することも、異なる部屋に配置することもできますが、通常は同じ建物内に配置します。

これらのキャビネットには、「隣接」の状態に関係なくOracleデータベースの動作を保証するために必要なすべての機器とソフトウェアのセットが含まれている必要があります。 つまり、Cross-Rackディザスタリカバリソリューションを使用して、障害のリスクを排除します。

• Oracle Application Server
• ストレージシステム
• スイッチングシステム
• キャビネット内のすべての機器の完全な故障：
  
  
  • 停電
  • 冷却システムの故障
  • 外部要因（人、自然など）

Oracleサーバーの複製は、Oracle RACの原則を暗示し、アプリケーションを介して実装されます。 切り替えツールの複製も問題ではありません。 しかし、ストレージシステムの複製により、すべてがそれほど単純ではありません。

最も簡単なオプションは、プライマリストレージからバックアップにデータを複製することです。 ストレージ機能に応じて、同期または非同期。 非同期レプリケーションでは、Oracleに関してデータの一貫性を確保するという問題がすぐに発生します。 ただし、アプリケーションとのソフトウェア統合がある場合でも、いずれにしても、メインストレージシステムで事故が発生した場合、クラスターをバックアップストレージに切り替えるには、管理者による手動の介入が必要になります。

より複雑なオプションは、ストレージシステムのソフトウェアおよび/またはハードウェア「バーチャライザー」です。これにより、一貫性と手動介入の問題が解消されます。 しかし、展開とその後の管理の複雑さ、およびそのようなソリューションの非常に下品なコストは、多くを驚かせます。

Cross-Rackディザスタリカバリのようなシナリオの場合、Shared-Nothingアーキテクチャを使用したAll Flash AccelStor NeoSapphire™ H710アレイは完璧です。 このモデルは、独自のFlexiRemap®テクノロジーを使用してフラッシュドライブを操作する2つのシングルストレージシステムです。 FlexiRemap®NeoSapphire™H710のおかげで、最大600K IOPS @ 4Kランダム書き込みおよび1M + IOPS @ 4Kランダム読み取りを実現できます。これは、従来のRAIDベースのストレージでは達成できません。

しかし、NeoSapphire™H710の主な機能は、2つのノードを個別のエンクロージャーとして実行することです。各エンクロージャーには、独自のデータコピーがあります。 ノードの同期は、外部InfiniBandインターフェイスを介して実行されます。 このアーキテクチャにより、ノードは最大100mの距離にわたってさまざまな場所に分散できるため、クロスラックディザスタリカバリソリューションが提供されます。 両方のノードは同期モードで完全に動作します。 ホスト側では、H710は通常のデュアルコントローラーストレージのように見えます。 したがって、追加のソフトウェアおよびハードウェアオプション、特に複雑な設定を実行する必要はありません。

上記のクロスラックディザスタリカバリソリューションをすべて比較すると、AccelStorバージョンは他の製品と比べて際立っています。

	AccelStor NeoSapphire™シェアードナッシングアーキテクチャ	ストレージのソフトウェアまたはハードウェア「バーチャライザー」	複製ソリューション
在庫状況
サーバー障害	ダウンタイムなし	ダウンタイムなし	ダウンタイムなし
スイッチ障害	ダウンタイムなし	ダウンタイムなし	ダウンタイムなし
ストレージ障害	ダウンタイムなし	ダウンタイムなし	ダウンタイム
キャビネット全体の故障	ダウンタイムなし	ダウンタイムなし	ダウンタイム
コストと複雑さ
ソリューション費用	低*	高い	高い
展開の難しさ	低い	高い	高い

* AccelStor NeoSapphire™は、オールフラッシュアレイであり、特に容量が2倍あるため、定義上3コペックはかかりません。 ただし、それに基づくソリューションの最終コストを他のベンダーの同様のソリューションと比較すると、コストは低いと考えることができます。

アプリケーションサーバーとオールフラッシュアレイノードを接続するためのトポロジは次のようになります。

トポロジを計画するときは、管理スイッチとサーバーの相互接続を複製することも強くお勧めします。

以下、ファイバチャネルを介した接続について説明します。 iSCSIを使用する場合、すべてが同じであり、使用するスイッチのタイプとわずかに異なるアレイ設定に合わせて調整されます。

アレイの準備作業

配列の使用を開始する前に、配列を初期化する必要があります。 デフォルトでは、両方のノードの管理アドレスは同じです（192.168.1.1）。 それらに一度に1つずつ接続し、新しい（すでに異なる）管理アドレスを設定し、時刻同期を構成する必要があります。その後、管理ポートを単一のネットワークに接続できます。 その後、ノードをInterlink接続にサブネットを割り当てることにより、HAペアに結合します。

初期化が完了すると、任意のノードから配列を制御できます。

次に、必要なボリュームを作成し、アプリケーションサーバー用に公開します。

Oracle ASM用に複数のボリュームを作成することを強くお薦めします。これにより、サーバーのターゲット数が増加し、最終的に全体的なパフォーマンスが向上します（別の記事のキューの詳細を参照 ）。

アレイの動作モードと緊急事態で発生するプロセスに関するいくつかの説明

各ノードデータセットには「バージョン番号」パラメーターがあります。 初期初期化後、それは同じで1に等しくなります。何らかの理由でバージョン番号が異なる場合は、常に古いバージョンから新しいバージョンへのデータの同期が行われます。その後、新しいバージョンに対して番号が調整されます。 これは、コピーが同一であることを意味します。 バージョンが異なる理由：

• いずれかのノードのスケジュールされた再起動
• 突然のシャットダウン（電源、過熱など）によるノードの1つでの事故。
• 同期できないInfiniBand接続の破損
• データ破損によるノードの1つでのクラッシュ。 新しいHAグループの作成とデータセットの完全な同期が既に必要です。

いずれの場合でも、オンラインのままのノードはバージョン番号を1つ増やし、ペアと再接続した後、データセットを同期します。

イーサネットリンク経由で接続が失われた場合、Heartbeatは一時的にInfiniBandに切り替わり、復元されてから10秒以内に戻ります。

ホスト構成

フォールトトレランスを確保してパフォーマンスを向上させるには、アレイのMPIOサポートを有効にする必要があります。 これを行うには、/ etc / multipath.confファイルに行を追加し、マルチパスサービスを再起動します

さらに、ASMがASMLibを介してMPIOと連携するには、/ etc / sysconfig / oracleasmファイルを変更してから/etc/init.d/oracleasm scandisksを実行する必要があります。

Oracle ASM用に作成されたディスクが、アレイが物理的に動作しているブロックのサイズ（4K）と一致していることを確認してください。 そうしないと、パフォーマンスの問題が発生する可能性があります。 したがって、適切なパラメーターを使用してボリュームを作成する必要があります。

parted / dev / mapper / device-name mklabel gpt mkpart primary 2048s 100％align-check最適1

テスト構成用に作成されたボリューム上のデータベースの配布

ストレージボリューム名	ボリュームサイズ	ボリュームLUNマッピング	ASMボリュームデバイスの詳細	割り当てユニットサイズ
Data01	200GB	すべてのストレージボリュームをストレージシステムのすべてのデータポートにマッピングする	冗長性：通常 名前：DGDATA 目的：データファイル	4MB
Data02	200GB
Data03	200GB
Data04	200GB
Data05	200GB
Data06	200GB
Data07	200GB
Data08	200GB
Data09	200GB
データ10	200GB
Grid01	1GB		冗長性：通常 名前：DGGRID1 目的：グリッド：CRSおよび投票	4MB
Grid02	1GB
Grid03	1GB
Grid04	1GB		冗長性：通常 名前：DGGRID2 目的：グリッド：CRSおよび投票	4MB
Grid05	1GB
Grid06	1GB
Redo01	100GB		冗長性：通常 名前：DGREDO1 目的：スレッド1のREDOログ	4MB
Redo02	100GB
Redo03	100GB
Redo04	100GB
Redo05	100GB
Redo06	100GB		冗長性：通常 名前：DGREDO2 目的：スレッド2のREDOログ	4MB
Redo07	100GB
Redo08	100GB
Redo09	100GB
Redo10	100GB

耐障害性テスト

デモンストレーションの目的で、HammerDBを使用してOLTPロードをエミュレートしました。 HammerDB設定：

倉庫の数	256
ユーザーごとの合計トランザクション	1000000000000
仮想ユーザー	256

その結果、2.1M TPMインジケーターが取得されました。これは、 H710アレイのパフォーマンス制限からはほど遠いものですが、サーバーの現在のハードウェア構成（主にプロセッサーによる）とその数の「天井」です。 このテストの目的は、ソリューション全体のフォールトトレランスを実証することであり、最大のパフォーマンスを達成することではありません。 したがって、この図を単純に構築します。

いずれかのノードの障害をテストします

ホストはストアへのパスの一部を失い、2番目のノードで残りのパスを処理し続けました。 パスの再構築によりパフォーマンスが数秒間低下し、その後正常に戻りました。 サービスの中断は発生しませんでした。

すべての機器でのキャビネット故障テスト

この場合、パスの再構築によりパフォーマンスも数秒間低下し、その後元のインジケーターの値の半分に戻りました。 1つのアプリケーションサーバーの操作から除外されたため、結果は元の半分になりました。 サービスの中断も発生しませんでした。

フォールトトレラントなCross-Rackディザスタリカバリソリューションを合理的なコストで導入/管理の労力をほとんどかけずにOracleに実装する必要がある場合、Oracle RACおよびAccelStor Shared-Nothingアーキテクチャとの連携は最適なオプションの1つです。 Oracle RACの代わりに、クラスタリングを提供する他のソフトウェア、たとえば、同じDBMSまたは仮想化システムを使用できます。 ソリューションを構築する原理は変わりません。 また、RTOおよびRPOの最終スコアはゼロです。