Get Pool Members

Someone above alluded to the best answer for you right now - use DNS to look up names.

 

 

.Net and Java both have DNS interfaces, and everything else can use DNS through an exec call, so you can do it this way.

 

 

The only real concern I would have is performance to the DNS server - if it degrades, your app will degrade by a large amount.

 

 

Don.

Bottom line is that the BIG-IP will have to resolve a name to an address anyway to be able to create the physical connection to the backend server.

 

 

Your example about load balancing from BIG-IP to two web servers (LT-KM3456.us.f5.com, and LT-KM3478.us.f5.com) is very very common. Typically the way this is configured is to create a DNS name for your exposed Virtual Server address (VIP). Then, configure your backend servers to accept that domain name in the Host HTTP request header. All of the HTTP headers (including the Host, the URI, etc) will be passed on to the backend server as they were passed into the Virtual Server.

 

 

BIGIP (Virtual Server LT-KMCommon.us.f5.com - 20.20.20.20)

 

-> Member (LT-KM3456.us.f5.com - 10.10.10.10)

 

-> Member (LT-KM3478.us.f5.com - 10.10.10.20)

 

 

Where 20.20.20.20 is the external Virtual Server address and the 10.* network is internal to your BIG-IP. Just configure your web apps to take LT-KMCommon.us.f5.com as a Host Header, and you should be all set. The pool members are completely hidden from the user and are masked by the virtual server address.

 

 

I guess, I'm missing why you are tying how BIG-IP stores it's PoolMember configuration with how the client accesses your Virtual Server. Please let me know if I haven't explained it clearly enough.

 

 

-Joe

 

 

Joe,

 

 

Thanks for the detailed explanation. You were right in the sense that "BIG-IP will have to resolve a name to an address anyway to be able to create the physical connection to the backend server".

 

 

Finally, I have configured the Big-IP.

 

 

Virtual Server 20.20.20.20

 

- member = 10.10.10.10

 

- member = 10.10.10.20 (SAY) because though I saved typing LT-KM3478.us.f5.com, but it was saved as IP address).

 

 

Now, when I send a request to Virtual Server IP (say http://20.20.20.20:4343/ofr/index.jsp?app=om), typically it should forward it to http://10.10.10.10:4343/ofr/index.jsp?app=om. But client will see "http://20.20.20.20:4343/ofr/index.jsp?app=om" only.

 

 

Now problem is even if the request is forwarded to "http://10.10.10.10:4343/ofr/index.jsp?app=om" internally, "http://10.10.10.10:4343/ofr/index.jsp?app=om" does not work. because it has to be

 

"LT-KM3456.us.f5.com:4343/ofr/index.jsp?apps=om" this to work.

 

 

Thats the reason I was actually trying to save the pool members by their names rather than by IP.

 

 

Is there a way around it ? writing something like

 

 

if (request){

 

hostname = getHostName(getNextPoolMembersIP());

 

sendRequestToHostName and attach the browser session (hostName)

 

}

 

 

if (response){

 

convert hostName to IP of Virtual Server, and send back response to client.

 

Yea, we have to maintain the session so that every time that same client send request.

 

It should go to the same Pool Member.

 

}

 

---------------

 

I am not sure if that should be the approach, but this is what I am thinking. Let me know if you know the way around it.

 

 

Thanks,

 

 

 

 

I still think some things aren't clear. If your external VIP is 20.20.20.20 and a client requests http://20.20.20.20:4343/foo, the following will be sent back to the backend server

GET /foo HTTP/1.1
Host: 20.20.20.20:4343
...

I've never heard of a scenario where a user is trying to virtualize websites behind a virtual server yet maintain the separate host names for each independent server. The most common scenario is to have a DNS entry for the service (in your case www.foo.com resolves to 20.20.20.20). Then the configuration for each web server is setup to accept "www.foo.com" as it's host header (10.10.10.1, 10.10.10.2, ...). This way no configuration is needed (outside of the additional host header setting) and each server can be configured identically easing deployment for additional servers down the road. If you don't want to DNS'ify your VIP, you can still configure the backend servers to accept the Host header of the VIP (20.20.20.20) despite the fact that they are not listening on that address).

If you truly do need to virtualize multiple webservers while not configuring the servers in a virtualized manner, you can do some fun and games with tweaking the host headers. You'll have to build a mapping layer in an iRule with a list of hostnames for each of your servers along with their ip addresses. Then, you could determine which pool member address was selected and then modify the host header.

Keep in mind that most web applications will build embedded links in the pages with links to the supplied hostname. In your case, you will have links for "http://LT-KM23456.us.f5.com:4343/..." is certain client connections and "http://LT-KM2367.us.f5.com:4343/..." in others. Then the client will click on those links and they won't work unless you have them mapped to the VIP address as well. If you are using a DNS name or just the VIP address, the applications will return URLs in the form of "http://www.foo.com:4343/..." or "http://20.20.20.20:4343/..." that will correctly link back to the VIP.

If you really do need to virtualize non-virtualized applications, let me know and I'll get you an iRule that will do it. But beware of the side effects with embedded links as mentioned above.

-Joe

Stefan, the ip_to_hostname() performs a local DNS lookup on the specified address and returns either the DNS resolved name (if one exists), or the source ip address (if the DNS lookup didn't return a name).

 

 

The get_screen_name() method returns the internal configuration screen name alias stored in the BIG-IP's configuration.

 

 

Odds are if ip_to_hostname() isn't working, you don't have your BIG-IP's DNS settings setup correctly to the nameserver that handles your hostnames for your server farm. The get_screen_name() method will work as it is just pulling data from the internal configuration.

 

 

-Joe