Forum Discussion
NimbostratusiRule to switch hostnames to www.
Hi all, this is my first post and I'm not an F5 legend so please bare with me if this is obvious.
Our customer facing websites are published with a full www URL - i.e. www.mycompany.com. This DNS record is a CNAME which points to an A record of live.mydomain.com.
[The idea is that if the web servers behind that VS need to be taken down, we can very quickly change that CNAME to instead point to backup.mydomain.com in another cluster (but behind the same LB). CNAME changes propagate a lot quicker than A record changes so this is effectively a manual GTM.]
Anyway, our problem is that because live.mydomain.com and backup.mydomain.com are public facing, people who know these hostnames can access the site effectively on the wrong URL - this is bad for our internet stats as sites like google can see our content on 2-3 urls and therefore mark us down in search.
I've created an iRule to 301-redirect either live. or backup. to www.mydomain.com but would like to ask if this logic is correct, or indeed whether it could be more efficient for my needs, the last thing I want is to get stuck in a loop!:
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::host]] {
"live.mydomain.com" {
HTTP::respond 301 Location "http://www.mydomain.com[HTTP::uri]"
}
"backup.mydomiain.com" {
HTTP::respond 301 Location "http://www.mydomain.com[HTTP::uri]"
}
}
}
Here's hoping.
Cheers, Steve.
5 Replies
Michael_YatesIf both of your URL's are mapped to Virtual Servers on the same BigIP then each should point to a different pool of servers behind the same device.
If you need to take a set of servers / cluster of servers down for upgrades, maintenance, or patching you should just be able to change the destination pool for the traffic.
Virtual Server 1 - www.website.com - uses pool.www.website.com
Virtual Server 2 - backup.website.com - uses pool.backup.website.com
You could either change the destination pool for the first website from pool.www.website.com to pool.backup.website.com or you could use some other methods like Priority Activation Groups or Maintenance Page iRules.
Would any of these be possible for you?
Steve_87971Hi Michael, thank you for responding to me.
Our VSs exist on the same LB and each have their own pool exactly as you suggest so changing the destination pool would absolutely work for us in a maintenance scenario, and using an iRule to check healthy servers >= 1 or send traffic to a backup pool are both brilliant for resilience and reliability.
That said, the backup pool will shortly be moved onto seperate F5s, and then into a totally separate datacentre (we don't yet have an F5 GTM to take care of this). We've used the DNS / CNAME trick to give us this ability to flick traffic to another group of machines quickly, but we suffer with Google ranking because our content appears under two URLs.
The rule must inspect the full URL and re-write to the www version if required, basically:
IF hostname = (live.mydomain.com OR backup.mydomain.com) REDIRECT to www.mydomain.com ELSE carry on as normal.
The rule I've written does seem to do this - I've applied it to both the live and backup VS and tested - but I'm wondering whether it could be simplified with an OR statement...- Michael_YatesI think I understand.
Unfortunately I personally can’t offer any suggestions other than putting a Web Crawler Bot Blocker on your secondary / backup website to prevent the double contact detection.
http://www.robotstxt.org/robotstxt.html
Perhaps one of the others can offer a better solution. 
hoolioCirrostratus
The rule I've written does seem to do this - I've applied it to both the live and backup VS and tested - but I'm wondering whether it could be simplified with an OR statement...
Your switch statement should be about as efficient as that logic could get.
Aaron- Steve_87971Michael, thank you for that suggestion - it hadn't occurred to me to look at it as a robot problem so I'll put some investigation into that. Wood for the tree's and all that...
Aaron, thanks for the confirmation, we'll go for it.
Thanks again.
Cheers, Steve
