- Community Home
- >
- HPE Community, Japan
- >
- HP-UX
- >
- Network
- >
- サービスガード
カテゴリ
Company
Local Language
フォーラム
ディスカッションボード
フォーラム
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
ディスカッションボード
ディスカッションボード
ディスカッションボード
フォーラム
ディスカッションボード
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
フォーラム
ブログ
- RSS フィードを購読する
- トピックを新着としてマーク
- トピックを既読としてマーク
- このトピックを現在のユーザーにフロートします
- ブックマーク
- 購読
- 印刷用ページ
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
07-27-2006 08:18 PM
07-27-2006 08:18 PM
サービスガード
(2重化の状態は変わりはありません)
サービスガードの設定によるものなのか。。。
少ない情報ですが、見解をお聞かせ願えないでしょうか?
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
07-27-2006 09:01 PM
07-27-2006 09:01 PM
サービスガード
サービスガード(MC/SG)は、常に実アドレスを
ソースIPアドレスにして送信します。
切断前から観察されていて、切断後に送信アドレスが
変わったのでしょうか?
多分、最初から実アドレスで送信しているはずです。
MC/SGの動作として、仮想アドレスで受けて、
実アドレスで送信します。 もちろん、実アドレスでも
受けられますが、その場合には、受信した実アドレスから
しか返しませんので、障害が発生した場合には待機系に
切り替わりません。
MC/SGの相手側がソースIPとデスティネーションIPが
一致していることを求めるようなつくりだと、工夫を
凝らす必要がありまつ。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
07-28-2006 07:54 AM
07-28-2006 07:54 AM
サービスガード
今一度現象を説明させて下さい。
●システム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のつくりは分かりません。
いままで仮想アドレスで行っていたものが実アドレスとなってしまうことは、ありえるのでしょうか?サービスガードの処理/設定によるものなのか。。。
よろしくお願いします。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
07-28-2006 10:51 AM
07-28-2006 10:51 AM
サービスガード
>実アドレスとなってしまうことは、ありえるのでしょうか?
いや、そんなことは無いはずだ、という少ない経験に
基づいた前提で、自信は少な目で、お返事させて
いただきます。
切断⇒復旧 という表現をされていますが、どのような
手順でしょうか、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確認時の
手順について、お教え下さい。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
07-28-2006 12:34 PM
07-28-2006 12:34 PM
サービスガード
>netstat で確認された際に使用されていた通信プログラ>ムは、どのようなものでしょうか。
⇒通信プログラムは、自作成アプリケーションによる通信です。アプリケーションでは、仮想アドレスを取得しbindしているのですが。。。
>ぴったりした回答ができず申し訳ないですが、他の
>方への参考情報として、切断⇒復旧の手順と、netstat>確認時の手順について、お教え下さい。
⇒切断・復旧手順は、おそらくシステムBの障害・復旧に伴うものだと思われます。物理的には接続されています。
netstat の確認手順ですが、切断の前にとったものと、復旧後にとったもので単純に比較しています。
情報としてあまり提供できず申し訳ないのですが、見解等ありましたらよろしくお願いします。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
07-29-2006 10:56 AM
07-29-2006 10:56 AM
サービスガード
>アプリケーションでは、仮想アドレスを取得し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 アドレスを受け取るため、クライアントソフトウェアに混乱を招き、正しく動作しなくなります。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
08-01-2006 07:30 AM
08-01-2006 07:30 AM
サービスガード
⇒gethostbynameにて/etc/hostsに登録してある仮想アドレスを取得しています。問題は無さそうに思えます。
>connect() の前に bind() を呼び出す
⇒その通りになっています。
●ただ、bind()に失敗した場合にもスルーして、connectする処理になっています。そうした場合はやはり、仮想IPでbindできていないので実IPでの送信になってしまうのかと、教えていただいたマニュアルを見る限り思います。
実際に確認したいところですが、事情により確認がきません。
回答遅くなりまして申し訳ありません。
対応ありがとうございました。