Two Clustered 220s slower than a single 220?

Bob,

 We currently have 3 clients running in this way. We have noticed that using 2 220's will definitely give us trouble if the client has even has average email traffic and uses IDS or HTTP proxy. One thing that I have to keep reminding my engs. is that in a cluster setup the first two appliances really don't share load it is the third "worker" device that really start that process. So if you have 2 appliances (220's) that each have the standard 512 of memory you may indeed notice that your master node is pegged @ 100% quite often. [:(] 
Before we ever look at installing a cluster we always do a load analysis to determine the sizing of the devices. I will say this, that once the 3rd device comes on line we see a huge difference in performance.


Hope this helps.


Mike

Thanks, it appears that two-unit clustering is not advised for the original 220s, and that the overhead for clustering is higher than was known 18 months ago.  Apparently, 320s and above do fine in two-unit clusters.

Has anyone tried ASG220 v2 or v3 with Active/Active?

Has anyone tried ASG220 v2 or v3 with Active/Active?

Hi, we passive HA and ASG 220 HA active / acvtive in customer enviroments. For my opinion is the ASG 220 V1 and V2  as Cluster solution to to slow. We run in big trubble by updating the active / passiv and the active / active cluster. I have read the recommondation from G. Hansen (Astro) and follow up them, but i run huge problems. To solve the update problem, i destroy in both cases the cluster and configure the cluster function new at the end of the update process. After destroying the cluster, i am updating the single bos from 7.306 to 7.402. For updating the other single box, i use the ASI - Stick from Astaro. This stick is verry helpfull an the installtion of the image runs fast. 

I recommend highly to sell / by ASG 320 and higher for any HA Solution.

Even with ASG220-V2, the active/active cluster of two units is at our client's site is slower and less-powerful than was a single unit when we had a hardware failure on the other.  At least the cluster runs well enough that it doesn't have the problems I described in the first post above.

Knowing what I know now, I would never sell a cluster of 220s.  Two of them are impractical, and, over the first three years, it's cheaper to have two 320s in active/passive than three 220s in active/active/active.  If you need more that one active 320, then two 320s are undoubtedly faster than three 220s and less-expensive than four active 220s.  Add to that the fact that the 220s have no gigabit ports, and the choice is clear.

Cheers - Bob

Even with ASG220-V2, the active/active cluster of two units is at our client's site is slower and less-powerful than was a single unit when we had a hardware failure on the other.  At least the cluster runs well enough that it doesn't have the problems I described in the first post above.

Knowing what I know now, I would never sell a cluster of 220s.  Two of them are impractical, and, over the first three years, it's cheaper to have two 320s in active/passive than three 220s in active/active/active.  If you need more that one active 320, then two 320s are undoubtedly faster than three 220s and less-expensive than four active 220s.  Add to that the fact that the 220s have no gigabit ports, and the choice is clear.

Cheers - Bob

Hi Bob,

both ASG 220 installations are based on customers wishes. My Company recommend ASG 320 and faster maschines

I am new to Astaro, and for financial reasons had a customer buy two ASG120's to use in a cluster.  They are using the ASG's for firewall, IPS, content filtering.  They generate a lot of web traffic so the ASG's stay very busy.  With one in place, the CPU would stay about 70-80%.  Once the cluster was in place the CPU on both boxes stay about 20-30%.  I believe it is working well.

We have had however, two complete failures of the cluster that had something to do with the database becoming corrupt.  Astaro has made a change in the database that has stabilized the issue and I was told should be permanent in the 7.403 release.

The issue I have is that I still don't feel I have a good understanding of how the cluster works with 2 nodes.  I had this solution blessed by Astaro and told the 2 ASG's would work well together and share the load - and they appear to be doing so.  After the solution was sold I read about using 2 units vs 3 and that the advantage seems to be when 3 units are used, that the 2nd unit doesn't contribute much with the work load.

Is there any good documentation that explains exactly how the cluster works?  Thanks.

This sounds interesting. We have a possibility to run 3x ASG220 v1, which sounds like a good idea. Will most likely try this one day.

But is there anyone with realistic experience of ASG220 v1 with 7.4xx? Because I have found that a basic non-active conf runs on lower usage compared to 7.3xx. So is the upgrade to 1G really needed?

And what about virtual confs - is it reasonable to have a virtual HA/cluster, or just rely on the pure HA/clustering power and features of the virtual platform?

hi,

IMHO i found no significant performance differences between a single 220 and a 220 cluster.

We´re using a 2 x 220 cluster for over one year now with no bigger problems. Only the firmware changes made some troubles. But if you follow the cookbooks here in the forum, this won´t be a problem anymore.

Trusting the logs, the load of the systems is well shared.

Even the most recommendations from several Astaro Partners were to use the 320s as an cluster for our over 250 users, we´ve decided due to the exceptional more expensive costs (hw, licenses, subscriptions) to use the 220s.

Frequently we shut down one of the 220s for testing the HA and performance.
Thats working fine, but at last we see that the cluster solution is not really faster, but even not slower and in the end more reliable. 


CU
Thomas

Hi everyone, as clustering is a feature I really enjoy, allow me to give you a bit of information. 

First, the ability to cluster adds a small amount of resource overhead, due to the calculations required for the units to synchronized, hand out work, and otherwise keep the world in balance. For this reason, 512MB ram installations could find themselves in a worse-off state when clustering was added, hence clustering the 120/220 units didnt really make viable sense until they were upgraded to 1GB of RAM, but depending on features used on the units many customers had great success even on the earlier models.

As to how clustering works, a couple of key things should be understood. First, since in a cluster all communication "in" and "out" is done by the acting Master, he maintains a connection table for all communications, as well as any work which has been "farmed" out to other nodes in the cluster.

The other important thing is that the master box will treat all connected nodes as the same power/equivalent as him, so for this reason we require matched boxes or else the slave node(s) will either be underused, or overtasked depending on the masters specs.

Now, in a 2 box cluster, you get the advantage of having the second box "share" the load, whereby the master will allocate supported tasks such as IPS, Antivirus Scanning, Content Filtering etc...to the slave based on the current requests made, on a relatively round-robin style approach. Since however the master has to do a bit extra work in keeping the map of what's going on and who is talking to who, he will actually do less work when possible to ensure he can stay a capable manager. However in order to ensure that if the master dies, he must also keep a backup copy of the connections current to the slave, (which is some of the magic behind why our failovers are so fast). Which means that the slave itself isnt actually donating all his resources to scanning, but is in a 2 box cluster acting more as a working HA setup. Regardless, you will get a nice performance boost and load sharing using 2 boxes in most situations, while seeing the overall load on the machines even out nicely.

However, if you have ever setup or worked with a 3+ cluster, this is where the performance really starts to shine. In this type of setup, you have a master and a slave performing as above, and all additional boxes act simply as "drones", donating their CPU and Memory to crunching tasks. The master will actually load more work on a drone than a slave, due to his having more freedom to work without needing to keep track of the cluster world connections. So yes, the slave still gets work, but the drone will get "more" since he has more free resources due to the reasons outlined above. What happens in any cluster is the master recieves packets, farms out tasks as his intelligence deems based on a lot of logic factors, then receives the completed work nodes back and transmits them to their destination. 

We do use a jumbo-frame style communication for the cluster community network, hence on the 120's the transfer network can pin 100Mb with 4-5 boxes or large traffic pipes, which severely hampers performance once that happens. For this reason eth3 is reserved for the cluster by default at the factory, since it is a Gigabit interface on all 220 and up models.

Lastly, while you can "HA" virtual machines, depending on the factors like if they are running on the same metal (making it moot if you have a hardware failure), it may or may not be worth it to you. We've tested it and it does work fine, but you need a good setup (think ESX with a cluster and proper networking) to get good reliability and heartbeat responses.

Oh, and in 7.500 you can now use link aggregation for the cluster (binding the interfaces together for the cluster community for both throughput and reliability bonuses), in addition to the other failsafe options like using the lan nics for a backup heartbeat check. We also have changed some clustering "status" information, added a new cluster laylout look to the the dash board along with displaying serial numbers for all connected units, And anything using clustering in 7.400+ should be performing very well indeed...

Any questions or experiences, please let me know!