ネットワーク
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

サービスガード

skppp1574
時折のアドバイザー

サービスガード

現在サービスガードを使用し2重化のシステムを扱っています。相手装置との通信において、2重化の仮想アドレスにて送受信しております。そこで、相手装置との通信が切断されてその後復旧した後、通信が仮想アドレスではなく、運用系の実アドレスから送信されてしまいます。

(2重化の状態は変わりはありません)

サービスガードの設定によるものなのか。。。

少ない情報ですが、見解をお聞かせ願えないでしょうか?
6 件の返信
cf
レギュラーアドバイザー

サービスガード

こんにちは

サービスガード(MC/SG)は、常に実アドレスを

ソースIPアドレスにして送信します。

切断前から観察されていて、切断後に送信アドレスが

変わったのでしょうか?

多分、最初から実アドレスで送信しているはずです。

MC/SGの動作として、仮想アドレスで受けて、

実アドレスで送信します。 もちろん、実アドレスでも

受けられますが、その場合には、受信した実アドレスから

しか返しませんので、障害が発生した場合には待機系に

切り替わりません。

MC/SGの相手側がソースIPとデスティネーションIPが

一致していることを求めるようなつくりだと、工夫を

凝らす必要がありまつ。
skppp1574
時折のアドバイザー

サービスガード

cfさん早速の回答ありがとうございます。

今一度現象を説明させて下さい。

●システムA:2重化システム

2重化仮想アドレス:192.XX.XX.1

0系(運用系アドレス):192.XX.XX.2

1系(待機系アドレス):192.XX.XX.3

●システムB:相手システム(2重化かどうかは不明)

切断前のnetstatでみるとA側の仮想アドレスとB側がESTABLISHED状態でしたが、切断⇒復旧後にnetstatにて確認すると、A側の0系アドレスとB側がESTABLISHED状態になっておりました。2重化状態は正常のままでした。

接続手順としては、A側から接続します。

システムBのつくりは分かりません。

いままで仮想アドレスで行っていたものが実アドレスとなってしまうことは、ありえるのでしょうか?サービスガードの処理/設定によるものなのか。。。

よろしくお願いします。

cf
レギュラーアドバイザー

サービスガード

>いままで仮想アドレスで行っていたものが

>実アドレスとなってしまうことは、ありえるのでしょうか?

いや、そんなことは無いはずだ、という少ない経験に

基づいた前提で、自信は少な目で、お返事させて

いただきます。

切断⇒復旧 という表現をされていますが、どのような

手順でしょうか、0系のLANケーブル1本の抜き差し

などでしょうか。

MC/SG構成の場合、多くはAPAというLANの2重化も

設定されることが多いのですが、これが正しく構成

されていれば、LANケーブル1本の抜き差しでは、

ネットワーク系への影響はほとんど無いので、

切断⇒復旧で状態が変わるのとは関係ないと思います。

また、MC/SG自身の機能として、ローカルスイッチの

機能がありますので、APAを構成されていなくても、

2本のLANケーブルの内の1本の切断であれば、

MACアドレスの変更も無く、セッションの切断も無く、

通信が継続されます。

netstat で確認された際に使用されていた通信プログラムは、

どのようなものでしょうか。

ftpだと、コネクションを張りなおすので、システムA

からftpを実行しても、データ転送時には、システムBから

コネクションが張られますので、どの時点でnetstatを

実行したかで、バインドしているIPアドレスが変わる

可能性は有ると思います。(すみません、確信ないです)

ぴったりした回答ができず申し訳ないですが、他の

方への参考情報として、切断⇒復旧の手順と、netstat確認時の

手順について、お教え下さい。
skppp1574
時折のアドバイザー

サービスガード

見解ありがとうございます。

>netstat で確認された際に使用されていた通信プログラ>ムは、どのようなものでしょうか。

⇒通信プログラムは、自作成アプリケーションによる通信です。アプリケーションでは、仮想アドレスを取得しbindしているのですが。。。

 

>ぴったりした回答ができず申し訳ないですが、他の

>方への参考情報として、切断⇒復旧の手順と、netstat>確認時の手順について、お教え下さい。

⇒切断・復旧手順は、おそらくシステムBの障害・復旧に伴うものだと思われます。物理的には接続されています。

netstat の確認手順ですが、切断の前にとったものと、復旧後にとったもので単純に比較しています。

情報としてあまり提供できず申し訳ないのですが、見解等ありましたらよろしくお願いします。





cf
レギュラーアドバイザー

サービスガード

>⇒通信プログラムは、自作成アプリケーションによる通信です。

>アプリケーションでは、仮想アドレスを取得しbindしているのですが。。。

だとすると、仮想アドレスでのセッションしか確立されないはずです。

ソケットがINADDR_ANYでなくて、仮想アドレスでbind

されているわけですから、実アドレスが出てくるはずが

ありません。

作成されたプログラムが、仮想アドレスを取得するところで、

何か起きていないでしょうか?

たとえば、nsswitch.confでDNSとhostsが指定されていて

DNSのエントリとhostsのエントリが異なって設定されていて、

DNSにアクセスした場合と、hostsにアクセスした場合で

結果が異なる、といったことです。

後は、マニュアルからですが、作成されたプログラムの

connectとbindの順番についてです。ただ、この場合

常に実アドレスで通信することになると思うので、

状況を説明できないのですが。

http://docs.hp.com/ja/B3936-90080/apcs03.html

connect() の前に bind() を呼び出す

アプリケーションが接続を開始するとき、まず、アプリケーション IP アドレスを指定してbind(2) を呼び出した後、connect(2) を呼び出します。そうしなければ、接続要求は、希望する再配置可能なアプリケーション IP アドレスではなく、システムの送信 LAN インタフェースの定常 IP アドレスを使って送信されます。この場合クライアントは、accept(2) 呼び出しからこの IP アドレスを受け取るため、クライアントソフトウェアに混乱を招き、正しく動作しなくなります。

skppp1574
時折のアドバイザー

サービスガード

>作成されたプログラムが、仮想アドレスを取得するところで、何か起きていないでしょうか?

⇒gethostbynameにて/etc/hostsに登録してある仮想アドレスを取得しています。問題は無さそうに思えます。

>connect() の前に bind() を呼び出す

⇒その通りになっています。

●ただ、bind()に失敗した場合にもスルーして、connectする処理になっています。そうした場合はやはり、仮想IPでbindできていないので実IPでの送信になってしまうのかと、教えていただいたマニュアルを見る限り思います。

実際に確認したいところですが、事情により確認がきません。

回答遅くなりまして申し訳ありません。

対応ありがとうございました。