Oracle RAC および AccelStor Shared-Nothing アーキテクチャに基づいたフォールト トレラント ソリューションの構築

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

すでに私たちの記事で議論したように、 物品ストレージ システム自体には、重複したコンポーネント (コントローラーを含む) が存在するにもかかわらず、主に単一のデータ セットの形式で障害点が存在します。 したがって、信頼性要件を高めた Oracle ソリューションを構築するには、「N 台のサーバー - XNUMX 台のストレージ システム」スキームを複雑にする必要があります。

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

これらのキャビネットには、「隣接」の状態に関係なく Oracle データベースの操作を可能にする必要な機器とソフトウェアのセットがすべて含まれている必要があります。 言い換えれば、クロスラック災害復旧ソリューションを使用すると、障害のリスクが排除されます。

• Oracle アプリケーション サーバー
• ストレージシステム
• スイッチングシステム
• キャビネット内のすべての機器の完全な故障:
  • 電源の拒否
  • 冷却システムの故障
  • 外部要因（人間、自然など）

Oracle サーバーの複製は Oracle RAC の動作原理そのものを意味し、アプリケーションを通じて実装されます。 交換設備の二重化も問題ありません。 しかし、ストレージ システムの二重化では、すべてがそれほど単純ではありません。

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

より複雑なオプションは、一貫性の問題や手動介入を排除するソフトウェアおよび/またはハードウェア ストレージの「バーチャライザー」です。 しかし、展開とその後の管理の複雑さ、そしてそのようなソリューションにかかる非常に法外なコストは、多くの人を怖がらせます。

AccelStor NeoSapphire™ オール フラッシュ アレイ ソリューションは、クロスラック災害復旧などのシナリオに最適です。 H710 シェアードナッシングアーキテクチャを使用します。 このモデルは、独自の FlexiRemap® テクノロジーを使用してフラッシュ ドライブと連携する XNUMX ノード ストレージ システムです。 おかげで フレキシリマップ® NeoSapphire™ H710 は、600K ランダム書き込みで最大 4K IOPS、1K ランダム読み取りで 4M+ IOPS のパフォーマンスを実現できますが、これは従来の RAID ベースのストレージ システムを使用した場合には達成できません。

しかし、NeoSapphire™ H710 の主な機能は、100 つのノードを別々のケースの形式で実行し、それぞれがデータの独自のコピーを持っていることです。 ノードの同期は、外部 InfiniBand インターフェイスを通じて実行されます。 このアーキテクチャのおかげで、最大 710m 離れた異なる場所にノードを分散させることができ、クロスラックの災害復旧ソリューションを提供できます。 両方のノードは完全に同期して動作します。 ホスト側から見ると、HXNUMX は通常のデュアル コントローラ ストレージ システムのように見えます。 したがって、追加のソフトウェアまたはハードウェア オプションや特に複雑な設定を実行する必要はありません。

上記のクロスラック災害復旧ソリューションをすべて比較すると、AccelStor のオプションが他のソリューションよりも際立っています。

AccelStor NeoSapphire™ シェアードナッシング アーキテクチャ
ソフトウェアまたはハードウェアの「バーチャライザー」ストレージ システム
レプリケーションベースのソリューション

可用性

サーバー障害
ダウンタイムなし
ダウンタイムなし
ダウンタイムなし

スイッチの故障
ダウンタイムなし
ダウンタイムなし
ダウンタイムなし

ストレージシステムの障害
ダウンタイムなし
ダウンタイムなし
ダウンタイム

キャビネット全体の故障
ダウンタイムなし
ダウンタイムなし
ダウンタイム

コストと複雑さ

ソリューションコスト
低い*
ハイ
ハイ

導入の複雑さ
低いです
ハイ
ハイ

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

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

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

ここでは、ファイバ チャネル経由の接続についてさらに説明します。 iSCSI を使用する場合は、使用するスイッチの種類と若干異なるアレイ設定を調整して、すべてが同じになります。

アレイの準備作業

使用した機器とソフトウェア

サーバーとスイッチの仕様

コンポーネント
説明

Oracle データベース 11g サーバー
2

サーバーオペレーティングシステム
Oracle Linux

Oracle データベースのバージョン
11g (RAC)

サーバーあたりのプロセッサ数
16 つの 5 コア Intel® Xeon® CPU E2667-2 v3.30 @ XNUMXGHz

サーバーあたりの物理メモリ
128GB

FCネットワーク
マルチパス機能を備えた 16Gb/秒 FC

FC HBA
エムレックス Lpe-16002B

クラスター管理用の専用パブリック 1GbE ポート
インテル イーサネット アダプター RJ45

16Gb/秒 FC スイッチ
ブロケード 6505

データ同期用の専用プライベート 10GbE ポート
インテルX520

AccelStor NeoSapphire™ オール フラッシュ アレイの仕様

コンポーネント
説明

ストレージシステム
NeoSapphire™ 高可用性モデル: H710

イメージバージョン
4.0.1

ドライブの総数
48

ドライブサイズ
1.92TB

ドライブタイプ
SSD

FCターゲットポート
16x 16Gb ポート (ノードあたり 8 個)

管理ポート
イーサネット スイッチ経由でホストに接続する 1GbE イーサネット ケーブル

ハートビートポート
1 つのストレージ ノード間を接続する XNUMXGbE イーサネット ケーブル

データ同期ポート
56Gb/s InfiniBand ケーブル

配列を使用する前に、配列を初期化する必要があります。 デフォルトでは、両方のノードの制御アドレスは同じ (192.168.1.1) です。 それらに XNUMX つずつ接続し、新しい (すでに異なる) 管理アドレスを設定し、時刻同期を設定する必要があります。その後、管理ポートを単一のネットワークに接続できるようになります。 その後、インターリンク接続用のサブネットを割り当てることによって、ノードが HA ペアに結合されます。

初期化が完了すると、任意のノードからアレイを管理できるようになります。

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

Oracle ASM用に複数のボリュームを作成することを強くお勧めします。これにより、サーバーのターゲット数が増加し、最終的に全体的なパフォーマンスが向上します(別のキューのパフォーマンスが向上します)。 статье).

構成のテスト

ストレージボリューム名
ボリュームサイズ

Data01
200GB

Data02
200GB

Data03
200GB

Data04
200GB

Data05
200GB

Data06
200GB

Data07
200GB

Data08
200GB

Data09
200GB

Data10
200GB

Grid01
1GB

Grid02
1GB

Grid03
1GB

Grid04
1GB

Grid05
1GB

Grid06
1GB

やり直し01
100GB

やり直し02
100GB

やり直し03
100GB

やり直し04
100GB

やり直し05
100GB

やり直し06
100GB

やり直し07
100GB

やり直し08
100GB

やり直し09
100GB

やり直し10
100GB

アレイの動作モードと緊急時に発生するプロセスについての説明

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

• いずれかのノードのスケジュールされた再起動
• 突然のシャットダウン (電源供給、過熱など) によるノードの XNUMX つでの事故。
• InfiniBand 接続が失われて同期できない
• データ破損によるノードの XNUMX つでのクラッシュ。 ここでは、新しい HA グループを作成し、データ セットの同期を完了する必要があります。

いずれの場合も、ペアとの接続が復元された後、データ セットを同期するために、オンラインのままのノードはバージョン番号を XNUMX つ増やします。

Ethernet リンク上の接続が失われた場合、Heartbeat は一時的に InfiniBand に切り替わり、復元されると 10 秒以内に戻ります。

ホストのセットアップ

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

隠しテキストデバイス {
デバイス {
ベンダー「AStor」
path_grouping_policy "group_by_prio"
path_selector "キュー長 0"
パスチェッカー「トゥール」
特徴「0」
ハードウェアハンドラー "0"
プリオ「定数」
即時フェイルバック
fast_io_fail_tmo 5
開発損失tmo 60
user_friendly_namesはい
検出プリオはい
rr_min_io_rq 1
no_path_retry 0
}
}

次に、ASM が ASMLib 経由で MPIO と連携できるようにするには、/etc/sysconfig/oracleasm ファイルを変更して、/etc/init.d/oracleasm scandisks を実行する必要があります。

隠しテキスト

# ORACLEASM_SCANORDER: ディスク スキャンを命令するためのパターンの一致
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: スキャンからディスクを除外するためのパターンの一致
ORACLEASM_SCANEXCLUDE="sd"

注意

ASMLib を使用したくない場合は、ASMLib の基礎となる UDEV ルールを使用できます。

Oracle Databaseのバージョン12.1.0.2以降、このオプションはASMFDソフトウェアの一部としてインストールできるようになりました。

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

parted /dev/mapper/device-name mklabel gpt mkpart プライマリ 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

Data10
200GB

Grid01
1GB
冗長性: 通常
名前: DGGRID1
目的:グリッド: CRS と投票

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
冗長性: 通常
名前: DGGRID2
目的:グリッド: CRS と投票

4MB

Grid05
1GB

Grid06
1GB

やり直し01
100GB
冗長性: 通常
名前: DGREDO1
目的: スレッド 1 の REDO ログ

4MB

やり直し02
100GB

やり直し03
100GB

やり直し04
100GB

やり直し05
100GB

やり直し06
100GB
冗長性: 通常
名前: DGREDO2
目的: スレッド 2 の REDO ログ

4MB

やり直し07
100GB

やり直し08
100GB

やり直し09
100GB

やり直し10
100GB

データベース設定

• ブロックサイズ = 8K
• スワップスペース = 16GB
• AMM (自動メモリ管理) を無効にする
• 透明なヒュージ ページを無効にする

その他の設定

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ カーネル.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # Linux x86 を使用している場合はこれを設定しないでください
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ グリッドソフト nproc 2047
✓ グリッドハード nproc 16384
✓ グリッド ソフト nofile 1024
✓ グリッドハードノーファイル 65536
✓ グリッドソフトスタック 10240
✓ グリッドハードスタック 32768
✓ Oracle ソフト nproc 2047
✓ オラクルハード nproc 16384
✓ Oracle ソフト nofile 1024
✓ オラクル ハード nofile 65536
✓ オラクルソフトスタック 10240
✓ オラクルハードスタック 32768
✓ ソフト メモリロック 120795954
✓ ハード メモリロック 120795954

sqlplus “/as sysdba”
システムを変更してプロセス = 2000 スコープ = spfile;
システムセット open_cursors=2000 スコープ=spfile を変更します。
システム設定を変更します session_cached_cursors=300 スコープ=spfile;
システムセットを変更 db_files=8192 スコープ=spfile;

故障テスト

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

倉庫数
256

ユーザーごとの合計トランザクション数
1000000000000

仮想ユーザー
256

結果は 2.1 万 TPM でしたが、これはアレイのパフォーマンス限界には程遠いものでした。 H710ですが、これはサーバーの現在のハードウェア構成 (主にプロセッサによる) とその数の「上限」です。 このテストの目的は、依然としてソリューション全体の耐障害性を実証することであり、最大のパフォーマンスを達成することではありません。 したがって、この図に基づいて説明します。

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

ホストはストレージへのパスの一部を失い、XNUMX 番目のノードで残りのパスを使用して作業を続けました。 パスが再構築されるため、パフォーマンスが数秒間低下しましたが、その後通常に戻りました。 サービスの中断はありませんでした。

すべての機器を使用したキャビネットの故障テスト

この場合も、パスの再構築によりパフォーマンスが数秒間低下しましたが、その後、元の値の半分に戻りました。 アプリケーションサーバーがXNUMX台稼働しなくなったため、結果は当初の半分となりました。 サービスの中断もありませんでした。

Oracle 用のフォールトトレラントなクロスラック災害復旧ソリューションを合理的なコストで導入/管理の労力をほとんどかけずに実装する必要がある場合は、Oracle RAC とアーキテクチャが連携して機能します。 AccelStor シェアードナッシング 最良の選択肢の一つとなるだろう。 Oracle RAC の代わりに、クラスタリングを提供する他のソフトウェア、たとえば同じ DBMS や仮想化システムを使用することもできます。 ソリューションを構築する原則は変わりません。 そして、最終的な RTO と RPO はゼロになります。

出所： habr.com