| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Technologies for MQ DR (HACMP/VCS/MI) |
« View previous topic :: View next topic » |
| Author |
Message
|
| jeevan |
 Posted: Mon Jul 26, 2010 1:42 pm Post subject: |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
What!? Analyze FIRST, then design? This will never catch on.  |
Bruce,
I am not talking about the technical analysis, but referring a CBA analysis. Because the DR is not driven by cost but by the very objectives of business continuation plan (BCP). We have to give business, if this is what you want, it cost such and such financial resources etc.
Without knowing business objectives of the DR, tech people can not choose the technologies, and until we choose the technologies, we can not present the cost. Yes, we can come up with cost for different technologies and present them to business but this will mislead the very objectives of the DR as business alweays tends to choose stuff with lower cost. In my experiences, quite often, business does not understand the essence of the business - spending and investing are two different things and they take every spending as an waste.
Last edited by jeevan on Mon Jul 26, 2010 2:33 pm; edited 1 time in total |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jul 26, 2010 2:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| What!? Analyze FIRST, then design? |
Did I not click the sarcasm emoticon?
_________________
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 |
|
|
| jeevan |
| Posted: Mon Jul 26, 2010 2:37 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
| Quote: |
| What!? Analyze FIRST, then design? |
Did I not click the sarcasm emoticon? |
probabaly I overlook it?  |
|
| Back to top |
|
|
| jeevan |
| Posted: Mon Jul 26, 2010 6:11 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| Vitor wrote: |
| zpat wrote: |
| So the delay on failover would be significant as well - manually updating DNS and waiting for propagation of the change. |
This is an important general point. Key differences between HA & DR:
HA tends to be a single application stack, DR tends to be most or all of an estate
HA required recovery times tend to be measured in seconds, DR measured in hours
HA tends to be heavily automated (due to the short recovery times), DR is more manual.
So the choice of technology is influenced by the recovery times required.
I'm also still waiting for an answer to my question "what counts as a distaster if the loss of a datacentre isn't?"  |
To me, yes, but I am waiting for my manager what he or top management he deals with thinks about disaster or define disaster just for the sake of planning purposes even if they cannot visualise at this time.
You may wonder again with the same quesiton, but there are two things to remember:
First read these lines from Alice in Wonderland.
Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to."
"I don't much care where –"
"Then it doesn't matter which way you go."
— Lewis Carroll (Alice in Wonderland)
Sedond, I would like to remind you with due respect and humbly that in this world, everything is relative. Quantum physics goes one step further and says what we are seing and think is a truth is just an observer effect. That means we are seeing what we would like to see.
Last edited by jeevan on Mon Jul 26, 2010 7:01 pm; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 26, 2010 7:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeevan wrote: |
| To me, yes, but I am waiting for my manager what he or top management he deals with thinks about disaster or define disaster just for the sake of planning purposes even if they cannot visualise at this time. |
I might have missed the sarcasm emoticon as well. The loss of a data centre is usually at the centre of a disaster plan.
| jeevan wrote: |
| That means we are seeing what we would like to see. |
That's not quantum physics, that's project planning.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 26, 2010 7:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeevan wrote: |
First read these lines from Alice in Wonderland.
Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to."
"I don't much care where –"
"Then it doesn't matter which way you go."
— Lewis Carroll (Alice in Wonderland)
|
With all respect to Mr Dodgson, one of the things that should be included is advice on the destination when the traveller is uncertain.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Aug 07, 2010 11:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
jeevan, search for previous posts on this topic when I was going thru this exercise the first time. Pay particular attention to the topic of asynchronous data replication, missing messages, duplicate messages.
When Godzilla stomps all over your primary data center, most people will be happy to have a fully functional MQ environment in the DR site. They are not going to care about every last message in every last queue the instant the primary data center crumbled. If there is data that can't be lost, that belongs in a database. Most of the time most of your queues are going to be empty anyway. True HA solutions, that rely on synchronous data replication, can guarantee that committed persistent messages will not be lost. If your DR site is close enough for synchronous replication, than you can use traditional H.A. solutions for your "DR" solution. If your DR site site is close enough for synchronous replication a lot of people will agree its not a true DR site.
Once you get them to agree to this concept, that is a real disaster all the apps will find all their (empty) queues and QMs and channels ready to go with no change required on their part, your design becomes simpler, more understandable and more robust. Back Up QMs, as Jeff mentioned, are an option, but rarely used as far as I know.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
