Two Clustered 220s slower than a single 220?

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!

Yes, Thomas, after my experience that started this thread, I would recommend that one save the expense of Web and Email Security Subscriptions for the second unit, and use the two 220s in Hot Standby mode.  If you aren't using Web/Email Security, then the cost is the same for clustering or standby.

(Note: when speaking of cost comparisons, I'm considering five-year net cost.)  Thomas' comments have caused me to form some new opinions...

I don't think it EVER makes sense to cluster 220s.  If you need the security of a hot spare, then get a second 220.  If you need more power than a 220, get a 320; the megabit ports are a bonus.  If you need more power than a 320, the next step could be a cluster of two or more 320s.

Here's the rub with a cluster; you need to have one more unit in the cluster than is necessary to handle your load, otherwise, the failure of one unit brings you down.  At present, clustering is not something I would recommend.  For example, A cluster of two 320s is less-powerful yet more-expensive than a 425.  If you want some redundancy, a cluster of three 320s is much more expensive than a 425+Hot Spare.

Until it's possible to add a hot standby unit to a cluster, I won't recommend clusters any more.

Cheers - Bob

Thanks, Angelo, we were writing at the same time.  I think you meant, "a Gigabit interface on all 320 and up models."

I didn't say that I don't like clusters, just that I don't think they offer a cost-savings or redundancy.  It's a good feature and will be great when it's possible to add a hot-standby to a cluster.

Cheers - Bob

I lost a bet with Angelo.  In fact, the 220 has some gigabit interfaces, but the marketing literature hasn't kept up with reality.  That's gotta be the first time that marketing didn't overstate reality! [;)]

Cheers - Bob

I lost a bet with Angelo.  In fact, the 220 has some gigabit interfaces, but the marketing literature hasn't kept up with reality.  That's gotta be the first time that marketing didn't overstate reality! [;)]

Cheers - Bob

In our case we had a 220 v1 as stand alone box for a few years.
Things changed and traffic grew.....

We tried the "low-cost-way": HA with an inexpensive v1-to-v3 upgrade (new box) and a second new ASG 220 v3. 

For our needs, this cluster works great. Sometimes the master begins to swap (after a week or so), but after a takeover everything runs fine again.

The speed related to a single 220 (tested with a 220v3, since you can´t compare it to the old v1...) has really improved.

But this is our environment, with our specific network traffic. In most cases and new installations I would prefer a 320 active-passive solution, too.

Regards,
Thomas