- - PR -
回線冗長化について
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-01-14 12:01
公開サーバ専用の回線について、以下のようなネットワーク構成を考えております。
■パターン１ ISP1 ISP2 | | ONU1 ONU2 | | RT1 RT2 | × | ←ルータのVRRP機能で冗長化 HUB1 HUB2 | × | 外部公開用サーバ ■パターン２ ISP1 ISP2 | | ONU1 ONU2 | | HUB1 HUB2 | × | ←ルータのVRRP機能で冗長化？あるいはISPの状況に応じて自動切替？ RT1 RT2 | × | ←ルータのVRRP機能で冗長化 HUB3 HUB4 | × | 外部公開用サーバ 上記のNW構成について、通常時はRT1はISP1からのアクセスを受け付け、RT2はISP2からのアクセスを受け付けたいと思っています(RTはルータのことです)。 通常の冗長化はパターン１のほうだと思うのですが、パターン１の場合、ISP1に問題が無くともRT1に問題があるとISP1が使えなくなってしまいます。そのため、パターン２のようにして、RT1に問題が出た場合には、RT2でISP1とISP2の両方とやりとりができるようにしたいと思っております。 この件について、いくつか質問させてください(以下、LAN側とは公開用サーバ側、という意味です)。 （以下、パターン２についての質問です） 1.RT1に障害が発生した際、RT2がISP1ともISP2とも同時に通信を確立して動作する、ということは可能なものでしょうか？以下のURLの内容はLANからWANへのアクセスとその応答であり、今回実現したいのはWANからLANへのアクセスとその応答である、という違いがあるのですが、いかがでしょうか？ http://www.rtpro.yamaha.co.jp/RT/docs/multi-homing.html 2.もし1.が可能な場合、上記URLではLAN側をプライベートIPにする、とありますが、LAN側をグローバルIPにすることはできないのでしょうか。例えばYAMAHAのRXT3000などであればLANインタフェースが4つあるのでできるのでは、と思うのですが。 3.もし1.も2.も可能な場合、RT1のLAN1とRT2のLAN1をISP1向けのVRRP、RT1のLAN2とRT2のLAN2をISP2向けのVRRP、RT1のLAN3とRT2のLAN3をLAN側のVRRP、RT1のLAN4とRT2のLAN4をLAN側のVRRP、という4つのVRRPを設定することが可能、ということでしょうか。例えばUSENのようなLAN型ネットワークがISPより提供されているのであれば、WAN側のVRRPも可能かとは思いますが、BフレッツのようなPPPoEの場合、RT1のLAN1とRT2のLAN2が同時にPPPoE接続し、しかもVRRPにする、ということはできないように思います。この場合はVRRPではなく、RT1の故障をRT2が検知して自動的にISP1に対してPPPoE接続を確立するのでしょうか？そのような動作のこともVRRPと言うのでしょうか？（どこまでがVRRPなのか、いまいち理解できておりません） また、PPPoEがそのように動作するのであれば、USENのようなLAN型の場合にも、PPPoEと同じような動作をさせることで、グローバルIPを節約することは可能でしょうか？(通常はRT1のLAN1にのみグローバルIPを割り当て、RT2のLAN1には何も割り当てない。RT1に障害が発生したら、RT2のLAN1に、RT1のLAN1に割り当てられていたグローバルIPを割り当てる、ということが可能？) 4.もし1.が可能で2.が不可能な場合、LAN側からWAN側へ応答パケットを返す際に問題が発生する（ルータがどちらのISPに応答パケットを返せば良いか、サーバからのパケットでは判断がつかない）と思うのですが、その点はどのように解決するのでしょうか。 （以下、パターン１についての質問です） 5.RT1、RT2のLAN側について、IPアドレスはプライベートIPにしたほうが設定は容易だと思うのですが、ルータでNAT変換を行うことによるパフォーマンスの影響について、皆様何かご意見いただけないでしょうか。NATはFWで行うというのが基本、というのは、どの程度従ったほうが良いものなのでしょうか・・・。冗長化を考えると、ISP1からの通信とISP2からの通信の両方を別ネットワークで、というのはかなり複雑に思うのですが・・・。 | ||||||||||||
|
投稿日時: 2008-01-14 21:05
（おそらく）自己解決しました。
■1.～4.について 直接の質問への答えではないのですが、パターン２の構成できちんと冗長化するには以下のいずれかとする必要があるようです。 a)１台の公開サーバについてNICが4つ必要、更にHUB1とHUB2、HUB3とHUB4を直接接続する必要がある b)ルータのLAN側を4ポート使用し、HUB5とHUB6を新たに用意することが必要 そこまでの手間をかけるよりは、ルータの故障時も回線の不具合時も、VRRPを利用してもう片方の回線を使うようにしたほうが良さそうです(必要ならば予備のルータを用意しておく)。 ■5.について RT1のLAN側とRT2のLAN側は同じサブネットに属していないと、VRRPで不都合が生じるようです(違っていたらご指摘いただけるとありがたいです)。 [ メッセージ編集済み 編集者: pico 編集日時 2008-01-14 21:07 ] | ||||||||||||
|
投稿日時: 2008-01-15 18:01
ISPの冗長化は、VRRPだけでは対応できないと思います。
RT1,RT2は、何をキーにしてISPを選択するのでしょうか？？ ISP障害時にRTの外部インタフェースがダウンするとは限らない ですよねぇ。その場合、VRRPは動作しないです。 また、Inboundトラフィック（公開サーバ宛）トラフィックは どうやって冗長化するのでしょうか？ | ||||||||||||
|
投稿日時: 2008-01-15 19:16
ひさ様
お返事ありがとうございます。ご質問の内容は、パターン２についてということですよね？
確かに、ISPのダウンとルータのWAN側のダウンを連動させる仕組みが必要ですね・・・。 ISPのダウンを検知した際にLAN側のポートを無効にする機能を持つルータがあるようなので、同じようにWAN側のポートを無効にすることも可能なのかなと、勝手な推測をしてしまいました。後はLinuxをルータにして、ISPへの接続が切れたらNICを無効にするようなスクリプトを作成する、などでしょうか(あまり知識がないもので、そのようなものが作れるのかは知りませんが…)。
こちらについては、色々とIPを割り振ってみた結果、自己レスの
のいずれかでできるかと思ったのですが・・・(ちょっと煩雑過ぎるので具体例を記載するのは省略させてください)。 ただ、a)については完全な冗長化ではなく、例えばRT1とHUB3が同時に故障したら動作しなくなったりと、一部不完全になってしまうようです。完全に冗長化するには、b)のように、ルータのLAN側4ポートのうち2ポートずつをそれぞれbondingしてISP1用、ISP2用とし、HUB3とHUB4はISP1のネットワーク、HUB5とHUB6はISP2のネットワーク、という具合にすることになるかと思います。 結局どこかで２つのネットワークを１つに集約する必要があるわけですが、パターン１であればルータのLAN側で、パターン２であれば公開サーバ自体で集約される形になるのかな(公開サーバで集約する場合にはNICが4枚(2ポートずつbondingしてそれぞれISP1用とISP2用にする)必要)？ 実際は公開サーバの手前にFWが入ったりするので、そこでVRRPを使うなり、heartbeatで2台のFWサーバを1台に見せるなりすることになるのでしょうか。でも2台のサーバを1台に見せてしまうと、応答を返す際にどっちに返せば良いのかわからなくなってしまいますね。ということはVRRPを使うのかな？ 考えているとかなり混乱してきますが、このような感じでしょうか。 [ メッセージ編集済み 編集者: pico 編集日時 2008-01-15 19:20 ] | ||||||||||||
|
投稿日時: 2008-01-16 10:00
本題と微妙にずれますが・・・。
このスレではVRRPが前面に出ておりますが、業務要件はマルチホーミング に関する内容ですね。 要求仕様（業務要件）および投下可能な費用にも因りますが、私なら 真っ先にマルチホーミング機能を有したアプライアンス（専用機）の 評価・導入検討に動きます。 picoさんのように複数の機器とそれらの設定によっても実現可能だと 思いますが、その場合で問題が発生するとすべて環境設計したところ の責任問題になります。専用機を導入しメーカサポート契約まで行え ば、ある程度のリスク回避は可能になるというメリットがあります。 マルチホーミングに関しては、net上でざっと検索しただけでも相当量の情報が 入手可能です。
VRRPというよりはマルチホーミングによる障害発生時の回線切替の流れは このようなイメージです。 ひささんご指摘の通り、VRRPだけではこうした制御は不可能だと思います。 実際に環境設定まで出来る技術者なら様々な機器の組み合わせで実現できる かも知れませんが、私のような手配師だと既製品の選択が多いですｗｗｗ # ネットワークインフラの場合、アクセス回線ばかりでなく、Webサーバ、 # ルータ/SW類等、冗長化のための資金投入には限がありません。 # 個人的には自社だけで対応不能なアクセス回線部分に迂回路を持たせること # が最重要だと思いますが、障害時に確実に切り替わらないと意味がないと # 思ってます。 | ||||||||||||
|
投稿日時: 2008-01-16 12:53
Routerでマルチホーミングをする場合には、ISPからBGPで
経路情報を受け取って、障害時には切り替えることになる のでしょう。 設定例とか。。。 http://www.cisco.com/japanese/warp/public/3/jp/service/tac/459/27-j.shtml しかし、一般企業はBGPの経路情報なんか受信してないと 思いますので、BackDoorさんも書かれている通り、マルチ ホーミング機能をもったアプライアンスで行うのが多いで しょう。 製品としては、 ・BIG IP LinkController ・Radware Linkproof ・iSurfJanus-RX/BP とかになるのでしょうか。他にもあるんでしょうが、私は 知らないです。。。 あとは、最近はISPが必要な機器はレンタルする形のマル チホーミングサービスもあるようですね。 USENとか。。。 http://www.gate02.ne.jp/lecture/vol6/vol6_5.html [ メッセージ編集済み 編集者: ひさ 編集日時 2008-01-16 12:56 ] | ||||||||||||
|
投稿日時: 2008-01-16 13:15
BackDoor様、ひさ様
お返事ありがとうございます。ご指摘の通り、マルチホーミングが一番の目的です。製品の候補も挙げていただき、ありがとうございます、助かります。 ただ、マルチホーミングは最低限としても、できれば24時間365日稼働としたいので、以下のどれが可能なのかな、ということを模索しております。もう一度整理してみると、 ①ルータを１台にしてマルチホーミングを行う。ルータが故障した場合は人が復旧するまで通信不可。 ②ルータを２台にして、そのうちの１台でマルチホーミングにして、もう１台はホットスタンバイ状態にしておく。回線障害の場合、ルータの切替は行わない。ルータの障害の場合、ルータの切替を行い、スタンバイ側でマルチホーミングを行う。 ③ルータを２台にして、それぞれをISP1, ISP2に接続。ISP1に障害が出た場合、ISP1側のルータを無効にする。ISP1側のルータが故障した場合、ISP2側のルータからISP1へ接続しに行かない（相互ホットスタンバイその１）。 ④ルータを２台にして、それぞれをISP1, ISP2に接続。ISP1に障害が出た場合、ISP1側のルータを無効にする。ISP1側のルータが故障した場合、ISP2側のルータからISP1へ接続しに行く（相互ホットスタンバイその２）。 以上のうち、まず①についてですが、この場合、リンクしていただいたPDFからすると、ISPAとISPBを同時に使用することは可能、ということですよね。 ただ、これって実際にはDNSへの問い合わせが来た場合、1.1.1.1が返すwebサーバのアドレスと2.2.2.2が返すwebサーバのアドレスは異なりますよね？例えば1.1.1.2と2.2.2.3、といった具合で。 そして、クライアント(IPアドレスをa.b.c.dとします)がwebサーバにアクセスした際、ルータがNATで1.1.1.2宛(ISPA経由)でも2.2.2.3宛(ISPB経由)でも10.10.10.10宛に変える、ということになりますよね。 とすると、webサーバとしてはsrc:10.10.10.10、dst:a.b.c.dというパケットをルータに送るわけなので、ルータはsrc:a.b.c.dのパケットがどちらのISPから来たのかを覚えており、srcを10.10.10.10から1.1.1.2あるいは2.2.2.3の正しい方に書き換えてパケットを送る、ということですよね。そのようなことが可能なルータがある、ということですよね。SwiftDNS&Virtual Serverというのがその機能を表している、ということなのでしょうか。 マルチホーミングと言っても、アクティブ・スタンバイ型のマルチホーミング(通常はISPAのみ使ってISPBは使わない)であれば上記のような困ったことは起こらないと思いますが(WAN側をISPの状況に応じて動的に有効/無効にできる必要はあると思いますが。PPPoEであれば接続しない限り有効にはなりませんが、USENのように、ケーブルをつなぐだけで接続できてしまうタイプもありますし。メインをUSEN、バックアップをOCN、という構成であれば良いのかもしれませんが、それでもPPPoE接続を動的に制御する必要はあるということですよね。アプライアンス製品であればそのような機能はあるということですね)。 ただ、①だけですとルータ故障時の停止が問題になるので、なるべくなら②～④のいずれかを採用したいと思っております。不可能であれば①にして、故障時には駆けつけるしかないですね。まぁルータの故障って滅多に無いとは思いますが。でもISPの障害やメンテナンスによる停止も、せいぜい年に１回とか２回とかですよね。 以下、②～④を考えてみます。 ②の場合、実質的に①と同じ状態なので、以下の２点がクリアできれば良いということですね。でも、こんなことが可能なルータってあるのでしょうか？？？Linuxでやる？ 1.①が問題なく動作する 2.ルータが互いにWAN側2ポート、LAN側1ポートの全てを監視し合い、以下のことができる ・スタンバイルータのLAN側からアクティブルータLAN側へ定期的に接続し、その接続ができなくなったら、アクティブルータの電源をOFFにするかWAN側ポートを無効にして、スタンバイルータからISP1, ISP2に接続する ・アクティブルータのWAN側の両方がISPと接続できなくなったら、アクティブルータのLAN側からスタンバイルータのLAN側へそのことを通知して、スタンバイルータにISPへの接続をトライさせる(ISPの問題ではなくアクティブルータのWAN側ポートの問題かもしれないので)。それでもISPにつなげないのであれば両方のISPが落ちているということなのでお手上げ。 ③については、アクティブ・スタンバイで良いのであれば、 ・アクティブ側のISPに問題が出た際、アクティブルータが自分で電源をOFFにするか、あるいはアクティブルータのLAN側を無効にする ・スタンバイルータからアクティブルータのLAN側にアクセスできなくなったら、VRRP機能でスタンバイルータがアクティブルータのIPアドレスを引き継ぐ ということでOKですね。 両方の回線をアクティブにして運用することも、過去のスレッドからすると、Linuxであれこれやればできるということですね(アプライアンスでも可能なものなのでしょうか？)。どのようにしてやるのかはまだ理解できていませんが。(webサーバからどちらのルータに応答を返せば良いのか、webサーバはどうやって判断するのでしょう？まず、Linuxルータ2台それぞれのLAN側IPは分ける必要がありますよね。Linuxルータが外部からのアクセスをNAPTして、webサーバへはsrcをLinuxルータのIPとしてパケットを送る、とすれば、webサーバは正しいLinuxルータへパケットを返すことができるとは思いますが、全てのグローバルIPをNAPTするなんてことが可能なものなのでしょうか？あるいは①のように、LinuxルータがクライアントのIPアドレスを管理しており、webサーバから応答パケットを受信した際に一致するクライアントのIPアドレスがあるか確認、あればそのままISPにデータを送る、なければもう１台のLinuxルータに転送する？最後の方法としてはwebサーバに2つのIPアドレスを割り当てて、どちらのIPアドレス宛のパケットを受信したかに応じてルーティングを決定するか、ですね。iproute2について調べてみます。 最後に④については・・・、②と③の組み合わせということになるかと思いますが、③が実現できれば十分かなと思いますので、割愛。 長々と書きましたが、通常、「ルータなんてそんなに壊れないから、そこに労力をかけるよりはマルチホーミング可能なアプライアンス製品を使ったほうが簡単だしそれで十分だ」という感じなのでしょうか・・・。確かに、設定が複雑になる分、色々と苦労しそうな気がしますね。皆さん、ルータの障害って滅多に経験されないものでしょうか？ [ メッセージ編集済み 編集者: pico 編集日時 2008-01-16 13:28 ] | ||||||||||||
|
投稿日時: 2008-01-16 13:49
全ては書きませんが・・・。
通常に使用しているルータはCISCO製品中心ですが、故障・障害は殆どありません。 遠隔地の貸ビルの電源系の法廷点検の際に過電圧をかけられてconfigが消失した 程度の障害はありましたが、UPSをかませることで回避しました。 以降はこのスレッドを最初に見たときの感想というか独り言です。 # VRRP（Virtual Router Redundancy Protocol）は冗長化の技術だと思ってた。 # 接続先（ISP）が異なる状況で適用させようと考えることに無理があるのでは・・・。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。