oles@ovh.net
11-03-2011, 19:06
Hello,
We had a few attacks today on one of the shared hosting clusters and we had to accelerate the migration to a dual load balancing.
The idea is to have 2 stages of load balancing to better manage hardware failures of different cards or just the updates. In contrast to the Active / passive configuration set-up we wanted an active/active set-up that can go into active/active/active or 4 x active or higher. And then add resources to cope with the growth.
So, it was established on 2 clusters: the 007 (xxlplan) and 010 (60gp). We will look at the stability of it the whole weekend, knowing that we are still waiting software updates for certain infrastructure elements on the bugs that we reported.
The current configuration is running with 2x AX 5100, connected through 10Gbps to 2 different routers. These boxes balance the traffic on 2 parallel ACE's which are in 2 other routers and are always different. Plus the 2 ACE's are balanced over thousands of web servers. It remains there with cookie on the ACE's and IP source on the AX's. The SSL in the hardware and in a little while a hardware compression.
The final configuration will run with 3 ACE's in 3 different routers:
http://weathermap.ovh.net/p19-mutu
As you can see we already have these 3 routers with 5 ACE / router cards. 5 routers, 2 AX, 15 ACE in all ... there are a lot of things needed in order for everything to work well together It is expected that more software updates are needed on the AX to fix the bug blockers.
This needs to happen from one day to another.
The purpose of all these manoeuvres? Avoid failure for our customers, have failure tolerances at a hardware level, not only to manage the emergency response to the hardware problems, but also to update the infrastructure without causing any downtime, protect infrastructure against attacks of all kinds, and have the potential to increase the capacity of infrastructure by simply adding the hard parallel that happens simply and quickly. And why not be able to sleep at night
The AX housings are particularly strategic in our case to handle attacks. We have tested them for several months with much success on a lot of different attacks that we have not even reported to you. We remember such a site, not very politically correct (nameless ...) that we have been able to push across the infrastructure and customise the filter parameters and drop all "useless" packets ... and there were useless packages ! ... Now all of this is available to our shared hosting customers ... Cool
All the best
Octave
We had a few attacks today on one of the shared hosting clusters and we had to accelerate the migration to a dual load balancing.
The idea is to have 2 stages of load balancing to better manage hardware failures of different cards or just the updates. In contrast to the Active / passive configuration set-up we wanted an active/active set-up that can go into active/active/active or 4 x active or higher. And then add resources to cope with the growth.
So, it was established on 2 clusters: the 007 (xxlplan) and 010 (60gp). We will look at the stability of it the whole weekend, knowing that we are still waiting software updates for certain infrastructure elements on the bugs that we reported.
The current configuration is running with 2x AX 5100, connected through 10Gbps to 2 different routers. These boxes balance the traffic on 2 parallel ACE's which are in 2 other routers and are always different. Plus the 2 ACE's are balanced over thousands of web servers. It remains there with cookie on the ACE's and IP source on the AX's. The SSL in the hardware and in a little while a hardware compression.
The final configuration will run with 3 ACE's in 3 different routers:
http://weathermap.ovh.net/p19-mutu
As you can see we already have these 3 routers with 5 ACE / router cards. 5 routers, 2 AX, 15 ACE in all ... there are a lot of things needed in order for everything to work well together It is expected that more software updates are needed on the AX to fix the bug blockers.
This needs to happen from one day to another.
The purpose of all these manoeuvres? Avoid failure for our customers, have failure tolerances at a hardware level, not only to manage the emergency response to the hardware problems, but also to update the infrastructure without causing any downtime, protect infrastructure against attacks of all kinds, and have the potential to increase the capacity of infrastructure by simply adding the hard parallel that happens simply and quickly. And why not be able to sleep at night
The AX housings are particularly strategic in our case to handle attacks. We have tested them for several months with much success on a lot of different attacks that we have not even reported to you. We remember such a site, not very politically correct (nameless ...) that we have been able to push across the infrastructure and customise the filter parameters and drop all "useless" packets ... and there were useless packages ! ... Now all of this is available to our shared hosting customers ... Cool
All the best
Octave