| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster SSL Performance Overhead |
« View previous topic :: View next topic » |
| Author |
Message
|
| siivv |
 Posted: Fri Feb 06, 2009 11:43 am Post subject: Cluster SSL Performance Overhead |
 |
|
Newbie
Joined: 06 Feb 2009
Posts: 2
|
We have a requirement to implement encryption between two clusters. These clusters are joined by a gateway queue manager that is clustered with both. Therefore, we need to make sure the traffic between the gateway queue manager which is "physically" located with Cluster A is encrypted on its way to Cluster B. There is not a requirement for messages in queues on either side to be encrypted. It's purely a transport requirement.
For data moving from A to B, each of the queue managers in B will have a local copy of a clustered queue. Therefore the gateway queue manager which exists in A will need to have an encrypted channel to each queue manager in B.
Does anyone have thoughts around the increased server overhead that we'd see in this configuration? Some have suggested 30%, but I have not been able to turn up any documented experiences. I'm not sure if that's an i/o overhead or cpu or what it might be. It surprises me that it would be that significant.
Thanks in advance. |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Feb 06, 2009 3:01 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why the requirement to encrypt 'between' the clusters? You're going to have to put encryption on all the cluster channels in every queue manager in both clusters, and use something like peer name checking to ensure separation. You might want to look at the 10/2008 Challenge question for an illustration of how . 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Feb 07, 2009 3:23 am Post subject: Re: Cluster SSL Performance Overhead |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| siivv wrote: |
| I'm not sure if that's an i/o overhead or cpu or what it might be. It surprises me that it would be that significant. |
Don't forget the administrative overhead. Maintaining SSL certs in a sizeable cluster will keep you quiet for a while.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Feb 07, 2009 8:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
There is always a cost of doing business. I would think that encryption is a business requirement.
Overhead is the term we tend to use to describe invisible (to end-users) functions not directly related to accomplishing the end-user task - examples: managing disk space, backing up data, disaster recovery planning, securing channels, o/s and WMQ upgrades. To IT folks, these are requirements. But for the payroll dept., all they want is paychecks.
The actual processor overhead with encryption (SSL and other) will depend on whether or not you have an crypto processor, how often handshaking takes place. Your SLA's might need to be adjusted, or new hardware purchased, when you add encryption. As stated above, there is administrative overhead to manage certificates and the like.
A caution: having some channels secured while others are not is a worst practice and an invitation to data loss. It's like locking your front door, but leaving the back door open.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| siivv |
| Posted: Sun Feb 08, 2009 3:30 pm Post subject: |
|
|
Newbie
Joined: 06 Feb 2009
Posts: 2
|
Thanks for the replies. It is a rather annoying requirement especially due to the location of the shared clusters. They are both in the same data center and I'd wager no more than 2 hops away (haven't checked yet). Definitely not a fan of the need or desire to encrypt, but this was the means to an end for the business requirement. I envision the channel encryption overhead to be far less than the message by message encryption of nearly 10 million messages/day - especially if the transmit batch size is appropriately set.
I understand the management overhead, I was more so focused on any "known/experienced" processing overhead. We do have crypto processors to offload the ssl work, but I wasn't sure if there was something else I was missing.
I'm still waiting for the folks that suggested 30% overhead on the system to provide me their sources. I just don't see it being that significant. I expect more in the neighborhood of 5%. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
