Operating System - OpenVMS
1832831 Members
3046 Online
110047 Solutions
New Discussion

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

 
Bill Hall
Honored Contributor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

Edmundo,

You stated the tape library you are using is a MSL5026, but not the exact model. The Quickspecs list the following features depending on the specific model:

1 or 2 40/80-GB DLT drives, with a throughput of 6 MB/sec (native) per drive for a backup performance of up to 43.2 GB/hour for a single unit.

or

1 or 2 SDLT 110/220 drives, with a throughput of 11 MB/s (native) per drive for a backup performance of up to 79.2 GB/hr for a single unit

And in both cases:
Ultra II LVD SCSI Interface.

The tape drive and SCSI bus seems to be your limiting factor.

Bill
Bill Hall
Bob Blunt
Respected Contributor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

I've read and re-read the whole thread and I think I see what Edmundo is trying to accomplish and why. The way I see it? He's trying to take the databases down for the shortest amount of time, that five minute goal he mentioned, just to stall the D/Bs (which appear to be MUMPS-based) and bring them back online as soon as possible for transactions to continue processing while catching up the journaled activities. Splitting off a shadowset member allows him to "only" access a fixed and static copy of the database because, otherwise, he'd have to bring it up as a separate instance to use the MUMPS tools for saving either in it's entirety or incrementally. My guess is that this process is necessary because trying to save the databases while active may cause more contention and delay than they can afford.

So what to do with the limitations that are in place? Sorry, Edmundo, but the core question here is going to simply be one of "how much money do you have to spend to fix the problem?" One solution I can envision would be to max out memory on your ES47 and use the OpenVMS RAM disk product and setup a disk large enough to hold your nightly backups, then save them to tape either using Save Set Manager or BACKUP. The main goal being to keep the I/O off your SAN as much as possible. After all, we ARE talking about V7.3-2 and it's limitations... Which begs the question: Why are you stuck at V7.3-2 and are you cutting-edge current on patches?

I'm also curious about your SAN environment. Are your VMS systems the only consumers of your storage on the SAN? Are the disks configured with an optimal cluster factor? Is zoning correctly setup if you're sharing?

For a real hardware solution, which is going to be as elusive as the "OpenVMS FAST switch" some think exists in SYSMAN/SYSGEN, you may have to consider a larger, much more complex system or clustering with more I/O capability, multiple fabrics, dedicated I/O channels for your tape... The unfortunate part is that the solution isn't as simple as buying a set of racing slicks or a bigger engine to shoehorn into your car. Any solution has to consider all your environment, all your requirements and your expected goals. More data would be crucial to providing a solution and the solution has to meet your needs for data recovery. If that isn't the important result then we're doing little more than working our brains for no reason.

Personally, since any solution is going to require purchasing, I'd enlist someone in sales that knows OpenVMS and this sort of complicated problem solving. Where are you located and, in general, in what area of business does your employer address (healthcare, financial, etc)? Then we might have some suggestions about who to ask to do the hard work...

bob
Hoff
Honored Contributor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

For comparison, current-generation PCIe storage provides 5.7 TB device capacity, operates with sustained transfer rates of 6.2 GBps, and I/O transfer rates of around a million I/Os per second. That's about three minutes for a terabyte disk storage shelf. Well, not that a typical disk shelf can sequential-read the data off anywhere near that fast.
GuentherF
Trusted Contributor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

Using 1-2TB "PC" hard drives:

OpenVMS V7.3-2 has a disk volume size limit of 1TB and there is no support for a SATA controller.

Also if the final target of the backup is to tape then I don't see what is gained by first moving the backup to a disk drive.

/Guenther
Toine_1
Regular Advisor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

Hi,

I have the same problem. Backup databases and files on EVA storage to MSL5026 tape library. This takes a lot of time.

I have tested once the ABC solution. And this was the best I have ever seen.
Of course you need a TSM Backup Server in your network for this.

http://www.storserver.com/BackupAgent.aspx

Archive Backup Client for OpenVMS

STORServer's Archive Backup Client (ABC) for OpenVMS systems allows you to include your OpenVMS servers in your heterogeneous IBM TSM backup solution.

/Toine
Chris Scheers
Advisor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

Call Kevin St. Cyr at Tributary Systems (817.786.3067) and tell them you are a VMS house interested in their tape virtualization product.

They have a FC product that lets you do "tape" backups to hard drives. Then, if you want to, you can roll the data off to physical tapes at your leisure.

From your description, I think this may be exactly what you are looking for.

Tell them I sent you.

Good luck!
Shriniketan Bhagwat
Trusted Contributor

Re: AlphaServer ES47 7/1000 - Need a SUPER fast (big) io device!

Hi,

You can make use of the features provided by the VLS (also know as VTL) to fasten your BACKUPs. VLS is used typically for backup and recovery purposes. VLS represents storage(hard disk storage) as tape libraries and tape drives for BACKUP applications. VLS emulates the drives of a physical tape library. More information can be found in the net.

http://h10010.www1.hp.com/wwpc/us/en/sm/WF04a/12169-304616-1153414-1153414-1153414.html

Regards,
Ketan