WebSphere Edge Server - MAC based routing - advisors don't work.

This is Interesting: Free IT Magazines  
Home > Archive > WebSphere Edge Server > April 2004 > MAC based routing - advisors don't work.





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author MAC based routing - advisors don't work.
Patrick Finnegan

2004-03-25, 10:33 pm

Running IBM Network Dispatcher V4 on Windows 2000.

Configured ND to load balance across two Apache web servers using MAC
forwarding method. Load balancing feature works.

Configured ND HTTP Advisors to poll web servers.

"ndcontrol advisor start http 192.0.8.45:80"

However advisors don't load and show a status of -1. There is no
failover. If I stop Apache on one web server requests are still
directed to that web server.

I can only get advisors to load when I configure ND for content based
routing. However we don't wish to use cbr as the applications on the
webservers are mirror imaged.

Please clarify whether failover is available with MAC-level routing.
Ben_

2004-03-26, 1:42 pm

Status of -1 is when the Advisor couldn't connect, the connection timed out,
the response timed out or the response doesn't contain the expected Advisor
Response.

To diagnose this, you may want to:
* double check the Advisor request/respons you defined
* increase the log level of the Advisor
* sniff the network traffic to see what happens actually


Patrick Finnegan

2004-03-29, 1:34 am

"Ben_" <reply@newsgroup.com> wrote in message news:<c41nvj$9foo$2@news.boulder.ibm.com>...
> Status of -1 is when the Advisor couldn't connect, the connection timed out,
> the response timed out or the response doesn't contain the expected Advisor
> Response.
>
> To diagnose this, you may want to:
> * double check the Advisor request/respons you defined
> * increase the log level of the Advisor
> * sniff the network traffic to see what happens actually


Increased manager Log level.

Lots of information in there but nothing useful. Much of it refers to
metrics available from metric server running on the load balanced
machine. We don't have this component installed as the doco indicates
that it's only required for "site selector" which we don't need.

If I enable Dispatcher cbr by setting "clientgateway", then enable cbr
on the port the advisors start.

For example setting

< ndcontrol port add 192.1.2.3:80 method cbr
< ndcontrol port set 192.1.2.3:80 porttype tcp

activates advisors on port 80 for the cluster.

Setting

ndcontrol port add 192..2.3:443
ndcontrol port set 192.1.2.3:443 stickytime 1800

does not activate advisors.

I have decided to go Dispatcher cbr to get advisors working.
Ben_

2004-03-29, 2:36 am

> Increased manager Log level.
I meant the Advisor log, which is produced in <advisorname>_<port>.log.


Patrick Finnegan

2004-03-29, 6:35 am

"Ben_" <reply@newsgroup.com> wrote in message news:<c48ge6$4rlc$1@news.boulder.ibm.com>...
> I meant the Advisor log, which is produced in <advisorname>_<port>.log.


All logs have been set to verbose.

When Dispatcher cbr is configured the apache log files show the
advisor HTTP requests and advisor detects server outags as expected.
Are we sure that advisors work with MAC routing?
Ben_

2004-03-29, 12:35 pm

> Are we sure that advisors work with MAC routing?
I've not been using MAC routing for a while. I'd expect Advisors are used
what ever the forwarding method (or it would be quite of a surprise to me,
but never knows :-).

I can't recall having read about a possible limitation and, rapidly looking
at Chapter 14 > topic Advisors of the Network Dispatcher Administration
Guide (ndguide.pdf), I don't such a limitation mentionned.

BTW, what exact version are you running ?


JLee

2004-03-29, 6:37 pm

The advisors should work just fine with MAC based forwarding, provided
that the server will respond to cluster IP traffic. Is the loopback
aliased on the server machines and are they Windows as well? If
Windows, is the extra route deleted after the loopback is aliased? Do
client browsers work when contacting the cluster?

The common problem is that the server is not aliased or the route is not
deleted such that it cannot respond to the cluster traffic, or the
server instances bind to non-cluster IPs, etc. CBR often works then
because the server is configured to respond to it's own address (which
is what CBR proxies to).

I'll add more comments in a response to your "Network Dispatcher issues"
note to cover the other issues.

Jeff

Patrick Finnegan

2004-04-07, 1:34 am

JLee <leeja@NOSPAMus.ibm.com> wrote in message news:<4068AB57.4030405@NOSPAMus.ibm.com>...
> The advisors should work just fine with MAC based forwarding, provided
> that the server will respond to cluster IP traffic. Is the loopback
> aliased on the server machines and are they Windows as well? If
> Windows, is the extra route deleted after the loopback is aliased? Do
> client browsers work when contacting the cluster?
>
> The common problem is that the server is not aliased or the route is not
> deleted such that it cannot respond to the cluster traffic, or the
> server instances bind to non-cluster IPs, etc. CBR often works then
> because the server is configured to respond to it's own address (which
> is what CBR proxies to).
>
> I'll add more comments in a response to your "Network Dispatcher issues"
> note to cover the other issues.
>
> Jeff


When the cluster ports are configured for MAC address routing the
advisors attempt to send http requests to port 80 on the cluster IP of
the Dispatcher machine instead of sending the request to port 80 on
the load balanced Apache server. The request fails because Dispatcher
does not listen on port 80.

Example.

Dispatcher Cluster IP 192.xx.xx.45.
Apache Server IP. 192.xx.xx.41

#####################
Extract from Advisor log.
#####################

Ports configured for MAC based routing.
****************************************
*******

Apr07 11:59:32.421 GMT+08:00 THD (172.25.10.45:80:172.25.10.188):
isSocketOpen() checking thread status:
CMN_OpenSocketThread:
Target(Cluster/Server) .. 192.xx.xx.45 ********
Socket .................. 460
Port .................... 80
SleepTimeMs ............. 20
Status .................. Success
Initialized ............. true
KillMeNow ............... false
Object Counts ........... 18/3/18

Packet analysis shows no advisor http traffic between Dispatcher
machine and Apache server.

Ports configured for Dispatcher cbr based routing.
****************************************
*******

CMN_OpenSocketThread:
Target(Cluster/Server) .. 192.xx.xx.41 ******
Socket .................. 184
Port .................... 80
SleepTimeMs ............. 320
Status .................. Fail
Initialized ............. true
KillMeNow ............... false
Object Counts ........... 5/3/5

Packet analysis shows advisor http requests/replies between Dispatcher
machine and Apache server.
Patrick Finnegan

2004-04-19, 10:34 pm

chppxf1@yahoo.com.au (Patrick Finnegan) wrote in message news:<a1538a71.0404062059.29ab43ba@posting.google.com>...
> JLee <leeja@NOSPAMus.ibm.com> wrote in message news:<4068AB57.4030405@NOSPAMus.ibm.com>...
>
> When the cluster ports are configured for MAC address routing the
> advisors attempt to send http requests to port 80 on the cluster IP of
> the Dispatcher machine instead of sending the request to port 80 on
> the load balanced Apache server. The request fails because Dispatcher
> does not listen on port 80.
>
> Example.
>
> Dispatcher Cluster IP 192.xx.xx.45.
> Apache Server IP. 192.xx.xx.41
>
> #####################
> Extract from Advisor log.
> #####################
>
> Ports configured for MAC based routing.
> ****************************************
*******
>
> Apr07 11:59:32.421 GMT+08:00 THD (172.25.10.45:80:172.25.10.188):
> isSocketOpen() checking thread status:
> CMN_OpenSocketThread:
> Target(Cluster/Server) .. 192.xx.xx.45 ********
> Socket .................. 460
> Port .................... 80
> SleepTimeMs ............. 20
> Status .................. Success
> Initialized ............. true
> KillMeNow ............... false
> Object Counts ........... 18/3/18
>
> Packet analysis shows no advisor http traffic between Dispatcher
> machine and Apache server.
>
> Ports configured for Dispatcher cbr based routing.
> ****************************************
*******
>
> CMN_OpenSocketThread:
> Target(Cluster/Server) .. 192.xx.xx.41 ******
> Socket .................. 184
> Port .................... 80
> SleepTimeMs ............. 320
> Status .................. Fail
> Initialized ............. true
> KillMeNow ............... false
> Object Counts ........... 5/3/5
>
> Packet analysis shows advisor http requests/replies between Dispatcher
> machine and Apache server.


The issue with the Dispatcher Advisors was solved by making a change
to the network adapter on the Dispatcher box. The card is Broadcom
Nettreme Gigabit Ethernet. Checksum Offload needed to be set to
"none". A bit obscure!

Action Taken: If the advisor is showing all servers at -1 then it will
round robin and you will have the problem of not knowing if a server
is really down. For MAC forwarding with Windows make sure that
the dispatcher machine does not have the adapter setting with
Task Offload enabled. Also if any of the adapter setting have
checksum's the disable these as well (Offload Transmit IP Checksum,
Offload Transmit TCP Checksum, etc). The checksum calculation
by the adapter can cause problems with the cluster address. This
is a common problem with -1 on advisors.
Network Connections --> Local Area Connection -->Properties-->
Config
The above path will get you to the Adapter settings.
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2009 webservertalk.com