AlphaServer DS20s and SAN sorage connectivity

[John A. Beard]

We have two DS20s operating in two separate sub-nets running OpenVMS 7.2-1 (Oracle related restriction). One box is defined as production, while the other box is positioned for use in case of DR.

At present, these servers are booted off their respective local system disks (local shadowed). The application data, etc (more or less static) is also located on the same local disk.

We would like to have a configuration where the storage devices (incl. boot dev) are SAN based and shadowed across the network. If we were to loose the production DS20, then we would like to present the same set of disks to the backup DS20 and boot from there. We are not in a position to go with a true clustered solution, so our data integrity would revolve around a shadowed SAN solution.

Can anyone suggest what might best work under this proposed scheme, or point me to where I can best obtain the answers I need. Thnaks.

[Hein van den Heuvel]

Keep it simple. First and foremost split the same disk for system and application into two.
The system can stay local, or go to san.
The data must be created on a san device, and I would porbably opt for a san based mirroring, not host based, to keep that application data in sync.

IMHO you want cloned, but seperate system disks locally mirrored, not remotely
Yet you would want shared system day-to-day data. So point things like SYSUAF and RIGHTSLIST and so on to (remote mirrored) SAN through the appropriate logicals. The page & swap space would be local or on san, but locally mirrored only. The goal would be to never need a full backup the system disks, only to restore.

Having the seperate system disks will allow you top readily experiment with new (OS) versions and so on.

fwiw,
Hein.

[John A. Beard]

Thanks for the advice Hein.

The sysuaf and rightslist would indeed be the files that would be best suited for placement on the SAN (if we keep the systems disks local as per your suggestion), and also to split the application data off onto a separate SAN disk. At present we only have the one physical disk for the application and system stuff to reside on.

Would you know with the age of the hardware (DS20) and the version of the operating system, are there any restrictions as to the type of SANs available for this task (also remembering that we want to shadow the data across to SANs is possible)

[John Gillings · Accepted solution]

Johnn,

>Would you know with the age of the
>hardware (DS20) and the version of the
>operating system

The DS20 isn't an issue, but I don't think you'll get very far with V7.2-1! For anything connected to a SAN you should be at least V7.3-2, preferably V8.2

I'd take a hard look at your "Oracle related restriction". Considering V7.2-1 was superceeded many years ago (pre 2000), it's difficult to believe you are really stuck there.

[John Travell]

My concern is the comment
"We are not in a position to go with a true clustered solution".
How do you plan to do the replication of disk content between the storage devices ?

In a cluster this is easy, just make the disks members of shadow sets.

If the machines are NOT clustered, you cannot easily have VMS do the data replication.
You could create a psuedo driver that copies every write to a volume to a remote network object. That object would have to replicate the writes to the equivalent volume, and, to preserve integrity, reply with confirmation that it has completed each write. NOT easy, unless someone has already done this.

While the SAN could do the replicating for you, how does VMS on the standby machine cope with a disk on which the data is being modified in a manner that instance of VMS does not know what is going on ?
You would have to have the disk dismounted, and only mount it when you invoke your DR situation.

I suggest you carefully think through the circumstances in which you need to invoke DR for real. A power cut ? No problem, remove a disk from the down server and walk it to the DR machine. A fire, no way... How much downtime can you tolerate between live failure and DR online ? Seconds ? Hours ? Weeks ? The smaller the timescale, the harder it is to get it right outside of a correctly configured VMScluster.

JT:

[John A. Beard]

I apologize for the non-clarity of my original statement. Hopefully the following will give you a better idea what I am trying to achieve.

The first issue I will deal with is that of running with VMS version 7.2-1. I will not use this space to go into the whys and why nots, but suffice to tell you that we are NOT in a position to upgrade above this level. This is an Oracle forms issue, and goes beyond the scope of my enquiry here.

I am also aware of the benefits of going down the cluster route, but this present stand-alone configuration was created due cost constraints, etc. There is now some additional funding available to allow for a better failover scenario, hence why I was hoping to go the SAN route, with data replication occuring across two shadowed SANs.

The two DS20 servers are localted in two different sub-nets (100+ miles appart). The information on the production server is quite static (uaf changes mainly), and the DR server is a replica (application programs, etc) of the production box. Only one server is accessed at any given time, so if the information was SAN based, those disks would be only be seen by one server at a time. In the event of DR, we would have logical pointers referencing the tcpip files that would be needed for the "new" production server to operate in the DR machine's sub-net. Out network people would take take of the DNS issue.

The user authorization related files are backed up on a daily basis, and would be available for restoring to the DR box if and when required.

The tolerance levels for downtime run in the region of two hours, so booting the alternate machine and changing DNS values sould not present a problem.

John G. ... here is the basic DS20 information you were inquiring about.

System Configuration:
---------------------
System Information:
System Type COMPAQ AlphaServer DS20E 833 MHz Primary CPU ID 00
Cycle Time 1.2 nsec (833 MHz)Pagesize 8192 Byte

Memory Configuration:
Cluster PFN Start PFN Count Range (MByte) Usage
#00 0 256 0.0 MB - 2.0 MB Console
#01 256 130720 2.0 MB - 1023.2 MB System
#02 130976 96 1023.2 MB - 1024.0 MB Console
#03 131072 393210 1024.0 MB - 4095.9 MB System
#04 524282 6 4095.9 MB - 4096.0 MB Console

Per-CPU Slot Processor Information:
CPU ID 00
CPU State rc,pa,pp,cv,pv,pmv,pl
CPU Type Unknown Halt Request "Default, No Action"
PAL Code 1.98-79 Halt PC 00000000.20000000
CPU Revision .... Halt PS 00000000.00001F00
Serial Number .......... Halt Code "Bootstrap or Powerfail"
Console Vers V7.0-2

[Wim Van den Wyngaert]

We have a SAN and use 7.3. OK, not all advanced features but it works well.

If you use shadowing, 1 SAN may have problems without you going down. We recently had the case were the PC/Sun SAN went completely down for a long time. So, nothing up.

Wim

[John Travell]

Are you talking about the LIVE node mounting one shadow set member on each of two SAN farms, 100+ miles apart ?
OR... are you talking about the two SANs doing their own 'shadowing' without VMS being aware of the data replication.
If the latter, you need to find out how well SAN replication and VMS work together.

If you are planning SAN 'shadowing' AND if VMS has full and unrestricted access to a volume that is the source of a SAN replication process, then your DR box could be sitting live but without the data volume mounted.
To invoke DR all you have to do is to ensure the live system is down, mount the data volume and do the network switch over.
OTOH, if SAN replication activity interferes with VMS activity on a volume such that the two cannot coexist at the same time, in the event of a DR situation you would need to resume from the most recent backup.

Whose SAN have you got/plan to get, and which variant of that SAN is involved.

JT:

[John A. Beard]

We have other Alphas ( a combination of 8 ES47's spread equally between two sites) that are set up in the same manner as to what we are trying to achieve here. The difference is that the other boxes are all running 7.3-2. I was not here when this was originally built (and typically, those that did have all left the company).

I believe that these two DS20s could not form part of the main ES47 SAN because of restrictions associated with the operating system version (???). I know next to nothing about SANs, so this is why I started the original thread seeking people's oppinions as to what I might be able to do with these two boxes. I was hoping to get some ideas before speaking with HP or our clients's VAR.
To follow site norms, I am pretty assured that whatever SAN solution might be appropriate, that it would be an ofering from HP. The existing environment revolves around EVA400s

You asked how VMS sees volumes in our existing SAN. Below is sectional output from the startup script... $1$DGA1040 exits in one san, and $1$DGA1041 exists in the other SAN.

MOUNT/NOREB/NOAS/SYS DSA13 -
/SHADOW=($1$DGA1040,$1$DGA1041) ORADATA2 ORADATA2

%MOUNT-I-SHDWMEMSUCC, _$1$DGA1040: (MTOV42) is now a valid member of the shadow set
%MOUNT-I-SHDWMEMSUCC, _$1$DGA1041: (MTOV42) is now a valid member of the shadow set

[John Travell]

This clarifies things enormously. You are mounting a shadow set where one member is on the local SAN, and the other on the remote SAN. Proper VMS shadowing, not SAN replication. Good.
You are of course fully aware that unless they are clustered, attempting to mount these devices on two different machines at the same time is the fastest way to a corrupted disk...

While VMS V7.2-1 does support SAN devices, I have not checked if it supports the EVA model you have there. Also, remember that there are many fixes between then and V7.3-2...
You will need to ensure that you have all of the latest ecos for V7.2-1, with possibly the most important being VMS721_FIBRE_SCSI-V0600 and VMS721_SHADOWING-V0700.

JT: