DR tools

[Wim Van den Wyngaert]

Not a VMS specific question but is anyone using/knowing a tool to manage disaster recovery procedures (and/or other procedures).

That is to not enter the same information in each procedure again and again.

Wim

[Heinz W Genhart]

Hi Wim

we have a so called source Node. On this source node we have a directory tree, with topdirectoies

[PRODUCTION] [TEST] [Integration] [development]

Then under this topdirectories we have a tree similar to a Systemdisk with common and node specific diretories. Under this we have further directories like sysmgr, sys$startup etc.

After we have setup a machine, we have a procedure which copies all the configuration files, ncl-files etc. to the right location in this source-tree.

If a machine fails and we have to rebuild it, we install the operating system, the layered products and then we have another procedure which copies the right configuration files to the rigth place on the target machine.

I tell you a small secret "we are just working on it", what menas this is only little bit more than a idea.

regards

Geni

[Wim Van den Wyngaert]

Geni,

Thanks but I meant some kind of package for managing the documentation of it. E.g. how to switch applications, exact sequence of operat0ions etc. So, If I have 4 GS160 nodes I don't want to specify the whole procedure 4 times but I want to say 'shut sybase' without specifying the instructions all the time. But I do want to be able to get lists of instruction without hopping thru documents.

Wim

[Jan van den Ende]

Wim,

>>>
I don't want to specify the whole procedure 4 times but I want to say 'shut sybase' without specifying the instructions all the time.
<<<

Wow, that comes real close to what we have done, but we "virtualised" (current buzzword!) it a bit more.

For _EVERY_ product (and we are VERY loose in defining something "a product") we have decided that there has to be an "instal_" and a "shutdow_"

If such procedure is not supplied, there is bound to be a sequence of actions that results in the desired effect. In which case we built a little (well, not always that little, but usually small) command procedure that contains that sequence.

Then, for anyone with system management functionality, we define logical names
INSTAL_xyz and
SHUTDOWN_xyz
that achieve the obvious.

Now, anyone that is authorized to do so (and THOROUGHLY aware of the consequences!) can do
$ @INSTAL_xyz
and
$ @SHUTDOWN_xyz

for any defined value of xyz.

Works for us.

YMMV

Proost.

Have one (I am now at another Duvel!) on me.

jpe

[MarkOfAus]

Wim,
We use mindmanager (www.mindjet.com/us/products/), which allows you to map your ideas. We also include in these activities, command files and other instructions.

It has a decent learning curve but once learnt is brilliant for just what you are proposing - we use it.

There is, I believe, an open source option, such as freemind, but I have not used it.

Thanks,
Mark.

[Colin Butcher]

Hi Wim,

Something that quite a few sites use to manage and automate their failover procedures is the HP DTCS offering. It's a combination of products and services that give a pretty good solution to this kind of problem. Sure, it'll cost money, but it works pretty well - and not just in a VMS only environment.

If you have trouble finding out about them then contact me privately and I'll put you in touch with them. I'm wary of publishing someone else's e-mail addresses and contact details in a forum. The DTCS group is based in HP in Bristol, UK.

Cheers, Colin (http://www.xdelta.co.uk).

[Wim Van den Wyngaert]

Jan,

We already have that in place. We say "execute start|stop decnet" and a dcl procedure is started under system. And the boot is doing the same. We even start decw and decnet ourselves during the boot.


Mark,

This seems excellent but difficult to implement for drp only.


Colin,

Ocverkill ? And it's for existing systems and should be suitable for all platforms (win/unisys/vms/ibm/sun).

Wim

[Colin Butcher]

Hi Wim,

I don't find DTCS to be overkill - it works well and is consistent and reliable. It also works on stuff other than VMS. Of course, it depends on your own experience and your own site requirements. Personally I think it's pretty good and saves you having to create a lot of stuff for yourself.

Cheers, Colin.

[Willem Grooters]

I have little experience in this area but what I learned from the few times I had to deal with DR as a system manager, (luckily just testing...) is that your procedures can be in place and no matter how good they are, your recovery will fail (drastically) if your documentation on how to use them (or nor) is non-existant, inaccessable, unclear, incorrect, incomplete or out-of-date.

So, whatever toolkit you use - homegrown or purchased product - you should know how and when to use the procedures.

Having said that, the following applies:

In case of an emergency (which DR is all about) I think it highly recommendable that:

* The documentation is accessable
* The documentation is adaquate, that is: complete, correct and comprehendable

The first issue is easily handled: don't keep it on one place (eg. the datacenter you just lost) but on a place where you can access it in al circumstances when needed. You can no doubt think of various alternatives...

The second is far more a challenge.
There is, AFAIK, no tool that will assure completeness, correctness and comprehension except for rigorous and repeated testing and review. What helps are well established methods and procedures - and a great deal of dicipline and awareness (I'm a developer...) - to keep it all up-to-date.
And, not unimportant, management that understands that real DR comes with an investment with no well calculatable ROI.

FME, this is the rarest....