人々がOracleRACアーキテクチャを設計しているとき、実装計画でN+1冗長性について考えないことがよくあります。 Oracle RACを実装する理由は、可用性とスケーラビリティの2つです。この説明では、可用性の側面のみに焦点を当てています。 RACの展開がスケーラビリティの理由のみである場合、このトピックは当てはまらない可能性があります。
では、N + 1冗長性とは何ですか？簡単に言えば、何かのNユニットが必要な場合、冗長性の目的で、そのアイテムのN+1が必要です。データベースサーバーを見てみましょう。電源が必要です。それが要件です。電源が機能していないと、サーバーはまったく機能しません。電源装置の最小数は1です。このサーバーの可用性を高くしたい場合は、N + 1電源装置、この場合はデュアル電源装置があることを確認します。電源装置が1つしかなく、障害が発生した場合は、サーバーを使用します。追加の電源装置、予備のユニットがある場合、1つの電源装置を失っても、サーバーがダウンすることはありません。冗長性は持つべき素晴らしいものであり、高可用性インフラストラクチャに不可欠なコンポーネントです。
Oracle RACシステムを設計する場合、DBAは、エンドユーザーの要求をサポートするために必要なノードの数を決定する必要があります。 DBAが4つのノードが必要であると判断し、このRACクラスターが高可用性特性を示す必要がある場合、DBAが5ノードのクラスター（4 + 1）を作成することが不可欠です。 4つのノードをビジー状態に保つのに十分なリソース要求があり、1つのノードが失われた場合、残りの3つはワークロードに対応できなくなります。 DBAがN+1機能を念頭に置いてRACシステムを構築する場合、エンドユーザーは1つのノードの損失に気付くことはありません。 DBAがN+1冗長性なしでRACクラスターを構築する場合、1つのノードの損失はエンドユーザーのパフォーマンスにとって非常にひどいため、クラスター全体がダウンする可能性があります。 RACの実装を設計するときは、N+1の冗長性を追求してください。
2年前、ノードを失ったRACクラスターがあったことを覚えています。問題ありません。まだ2つのノードが利用可能でした。残りの2つのノードのパフォーマンスを見ると、かなり圧倒されているように見えました。私たちのコールセンターは苦情を受け始めました。私はITチームの他の管理者と協力して、そのノードをできるだけ早く復旧して実行できるようにしましたが、停止の理由がハードウェア関連であり、部品を交換する必要がある場合は、必ずしもそうとは限りません。ノードがサービスを再開した後、数週間後にクラスターのパフォーマンスを監視しました。このシステムが最初に設計されて以来、私たちの使用法は成長しました。最初はN+1冗長性を念頭に置いてこのシステムを設計しましたが、使用量が増え、Nが2から3になりました。現在の3ノードクラスターはN+1冗長ではなくなりました。そこで私は経営陣と協力して、新しいノードを調達し、Oracleがそのノードでライセンスを取得していることを確認するのに十分な資金を来年の予算に投入しました。 N + 1冗長性に戻ったことを知っているので、夜はずっとよく眠れます。
他の多くの実装と同様に、インフラストラクチャに組み込まれている高可用性機能は、私のRACシステムだけではありません。このRACデータベースは、OracleのDataGuardを備えたフィジカルスタンバイデータベースのプライマリです。 RACスタンバイデータベースについて他のOracleDBAと話し合ったとき、彼らの多くがスタンバイのN+1機能について考えていないことに驚いています。フィジカルスタンバイデータベースは、プライマリデータセンターが何らかの理由で利用できない場合のセーフティネットです。非常に多くのOracleDBAが、マルチノードRACプライマリのシングルインスタンススタンバイを実装しているのを見てきました。痛い！彼らがフェイルオーバーする必要がないことを願っています。マルチノードRACクラスター全体のワークロードは、そのシングルインスタンススタンバイで非常に苦労します。したがって、プライマリとスタンバイの両方のRAC実装を設計するときは、アーキテクチャ設計に対するN+1冗長性の影響を考慮してください。
私が多くの人とおそらく異なるのは、私のフィジカルスタンバイの実装がN + 1に対応しておらず、むしろNであるということです。フィジカルスタンバイ用の冗長な追加ノードをスキップします。何故ですか？純粋にコストの観点から。私の物理的なスタンバイは単なるセーフティネットです。必要な日にそれが機能するようにしたいと思います。しかし、私はそれを必要としないことを願っています。リスクが現実になった場合に備えて、フィジカルスタンバイは私の保険です。私にとって、スタンバイサイトでのその余分な「+1」は過剰保険です。物理ハードウェアとOracleライセンスを節約できます。
それで、その日が来て、私がスタンバイにフェイルオーバーしたとしましょう。 N+1の冗長性を失いました。しかし、プライマリデータセンターを失い、スタンバイクラスター内のノードの1つを失う可能性はどのくらいありますか？かなりスリムなチャンス。 2つのサイトで同時に障害が発生する可能性は非常に低いです。この時点で、ITチームは、プライマリデータセンターが失われた理由と、その施設に業務を戻すことができる可能性が最も高い時期を評価しています。プライマリデータセンターの電源がすべて失われ、公益事業会社が明日までにサービスを復旧すると言った場合、RACデータベース用のノードがN個しかない場合でも、スタンバイデータセンターで実行するだけです。ただし、プライマリデータセンターが火事で一掃された場合、稼働するまでに何ヶ月もかかるでしょう。この時点で、そのスタンバイをプライマリとして使用する時間がはるかに長くなるため、物理スタンバイをN+1冗長性まで取得することを計画する必要があります。そのため、別のサーバーを急いで注文し、できるだけ早くクラスターに追加します。そのため、スタンバイRACデータベースをN + 1ではなくNとして設計し、スタンバイを長期間実際に使用すると判断した場合は、短い順序でN+1に増やすことを検討しています。
それで、私が議論したいもう一つの特別なケースがあります。ここで、DBAはN=1と判断します。現在のワークロード要件では、1つのノードで十分です。ただし、高可用性が必要なため、プライマリデータベース用に2ノードのRACクラスターを設計します。これで、プライマリにN+1冗長性が組み込まれました。最後の段落に続いて、スタンバイデータベースに必要なノードは1つだけです。一部の人が犯している間違いは、スタンバイを単一インスタンスのデータベースとして作成することです。これまでのところ、それらのロジックは理にかなっています。プライマリはN+1で、スタンバイはNです。これまでのところ良好です。私が異なるのは、スタンバイを純粋な単一インスタンスの実装ではなく、1ノードのRACクラスターにすることです。その理由は将来の成長のためです。ある時点で、DBAは、プライマリでNが1に等しくなくなったことを検出する場合があります。使用量は増えており、Nは2にする必要があります。 DBAは、プライマリを3ノード（2 + 1）に拡張したいと考えています。これは、ダウンタイムがゼロで簡単にダウンして、クラスターに新しいノードを追加し、RACデータベースをその新しいノードに拡張します。ただし、存在する1つのノードがRACに対応していない場合、スタンバイでスタンバイを2ノードクラスターにするのはそれほど簡単ではありません。純粋な単一インスタンスのスタンバイが存在するすべてである場合、DBAはそれを廃棄し、2ノードのクラスターに移動する必要があります。 DBAが先見性を持ち、物理スタンバイが単一ノードクラスタであるかのようにグリッドインフラストラクチャをインストールした場合、DBAが行う必要があるのは、プライマリ側で行ったのと同じように、新しいノードを追加することだけです。
RAC実装を設計するときは、プライマリにN + 1の機能があり、スタンバイに少なくともNがあることを確認することを検討してください。スタンバイが非常に重要であると企業が判断した場合は、スタンバイにもN+1を実装することをお勧めします。 DBAがN=1と判断した場合は、スタンバイを少なくとも1つのノードのRACクラスターにすることを検討してください。