Oracle Database Applianceのネットワーク設計に関する考慮事項
Oracle Engineered Systemsの導入により、DBAはインフラストラクチャの設計決定にいくらか近づき、少なくともデータベースのネットワーク設計要件についていくらか意見を持つことが期待されています。少なくともそれは私が自分自身を見つける状況です:)
ODAをテスト用にデプロイした後、現在のセットアップで自分自身を見つけます。
システムコントローラー0には、典型的なエッジスイッチであるCatalyst 2960シリーズに接続されたパブリックボンディングインターフェイス（bond0）があります。管理インターフェイス（bond1）は、同じタイプの2番目のエッジスイッチに接続されています。
システムコントローラー1も同様に、2番目のスイッチに接続されているパブリックインターフェイスを備えていますが、管理インターフェイスは最初のスイッチに接続されています。
このようにして、スイッチの1つがダウンした場合、オペレーターは、パブリックインターフェイスまたは管理インターフェイスを介して各システムコントローラーにアクセスして、診断を容易にすることができます。
シスコ側では、ODAの4つの結合インターフェース用にEtherChannelグループが構成されています。 2つのスイッチは、残りのネットワークに個別に配線され、2つのスイッチ間の直接リンクはありません。
一見、これは合理的な設計のように見えますが、さまざまな障害シナリオについて考えるほど、考えられる質問が増えます。
これらのEdgeタイプのスイッチ自体は冗長ではないことを考慮すると、電源障害が原因で1つのスイッチが使用不可になった場合、または1つのスイッチがパッケージの転送に失敗した場合に、クラスターが対処できることがかなり重要と思われます。
データベースクライアント（この場合は、zendサーバーアプリケーションサーバー）はそれぞれ、2つのスイッチの1つだけにのみボンディングインターフェイスで接続されています。これにより、ロードバランシングに関するいくつかの質問が表示されます。11gR2RACを理解する方法では、SCANアドレスに接続するだけで、クライアントがメインネットワークに到達し、他のスイッチを経由して戻る可能性が非常に高いため、ほとんど考慮できません。非常に効率的です。
スイッチに障害が発生したり、パケットの転送が停止した場合はどうなりますか？接続は、SCANを介してアクセス可能なVIPリスナーを見つけますか？RACは何らかの方法でネットワーク障害を検出し、SCANおよびVIPを動作可能でアクセス可能なシステムコントローラーに移動します公開インターフェース？正直なところ、どうなるかわかりません。
フェールオーバーシナリオでは、クライアントがコアネットワークを経由して戻ってくるまでは問題ありませんが、通常の運用ではそれを避けるのがいいでしょう。
オラクルはこれがどのように連携するかについて非常に明確な考えを持っていると確信していますが、私はそれをすべてはっきりとは見ていません。
エッジクラス/非冗長スイッチで完全な冗長性を実現することは可能ですか？実稼働およびフェイルオーバーの状況で、クライアント接続がルーティングされる場所に何らかの制御を追加できますか？おそらく、2つのスイッチを相互接続して、1つのスイッチ上のクライアントともう1つのスイッチ上のデータベースリスナーの間のトラフィックを直接許可する良い方法はありますか？
この時点で、一般的な高可用性ODA実装に適用する必要があるベストプラクティスと基本的なネットワーク設計の考慮事項を探しています。
うまくいけば、これは、ODAのネットワーク設計の決定に直面しているすべてのDBAに役立つでしょう:)
更新：
ODAは、アクティブバックアップ構成のボンドで構成されています。これにより、スイッチ側の構成なしで、ボンドの各インターフェースが異なるスイッチに接続される設定が可能になると思います。
これが事実であるか誰でも知っていますか？
[root@oma1 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth2
結局のところ、ODAはアクティブバックアップボンドで工場構成されています。私はこれをテストして、スイッチ側のLACP/EtherChannel構成がなくてもうまく機能することを確認しました。各結合接続は、2つのスイッチ間で分割される場合があります。私のテストでは、シミュレートされた障害やネットワークの再構成によって数百ミリ秒以上のネットワーク停止が発生することはありませんでした。
つまり、本質的に冗長ではない任意のレイヤー2スイッチを使用して、Webアプリケーション用に分離された冗長フロントネットワークをセットアップできます。
クライアント接続が会社のネットワークに長い道のりを行き、他のスイッチを介して戻ることを回避するため（したがって、その機器に生産を依存させること）、プライベートVLANエッジスイッチおよびそれらの間のEtherChannelトランク。
そのため、その仮想ネットワークセグメントには、アプリケーションサーバーとデータベースアプライアンスのみが存在します。
アプリケーションサーバーからデータベースリスナーへの接続に使用するパスを制御する方法がわからないため、2つのスイッチ間のリンクは冗長である必要があり、このリンクが単一障害点になることは少なくなります。これは、VLANおよびLACPまたはSTPのいずれもサポートしていない非管理スイッチの使用を除外します。
Cisco Catalyst 2960シリーズスイッチを使用する場合、EtherChannelとPort Fastの組み合わせが、2つの間の堅固な独立した接続に適していると思います。また、ODAおよびアプリケーションサーバーへのすべての結合接続のポートでPort Fastを使用します。
本番ネットワークは分離されているため、管理、バックアップ、および企業ネットワークの他の部分への接続のために、個別のネットワーク接続が必要になります。
当然、このフロントプロダクションネットワークが完全に自己完結型であるためには、DNSや認証サービスなどの外部リソースへの依存関係も解決する必要があります。理想的には、データセンターや企業ネットワーク内の他の場所での障害、進行中のメンテナンス、ネットワークの停止に関係なく、本番環境が独立して継続できるようになります。
