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

[Jon Pinkley]

>>So a 2MB SAN can be a limiting factor if 1TB/hour is your goal

I can make those errors too. I meant 2Gbs SAN.

Jon

[Edmundo T Rodriguez]

Ok here is more for the good, the bad and whatever understanding â ¦

The backup procedure, after checking the overall standing of the application
environment and setting an immediate time for cutoff transactions, freezes the databases and generate a journal. This phase takes in average around 7 min. and should not take more than 5. Why? Because the application is constantly processing transactions in order to generate data transfers via communications and they can not wait longer.

We are expecting that more and more users are going to be interacting with system so more of these transactions are going to be occurring during the backup period.

Then the backup procedure after analyzing the status of the disk-volumes proceeds to dismount the secondary member of all shadow-sets and only then proceeds to backup/image each one. As they are finishing there is a
Background process checking that the member is free and mounts it back into the pertinent shadow-set using minicopy.

As all this is going on the operator console is actively receiving messages of whatever is going on. If the first tape is used then a second tape is mounted and the process proceeds.

Even all these seems simple, is a very complicated procedure taking in consideration multiple variants and possibilities, but it is straight forward. Nothing in the procedure cause a road block to slow down the backup process.

Is the actual backup process, which depends in the system tune and hardware capabilities, the one that could cause a detriment or improve in the results.

[Graham Burley]

You haven't really explained why the 5.5 hour backup time is too long - does this impact application performance or are you worried about the time that the shadowsets are reduced?

[John Gillings]

Edmundo,

There seems to be an assumption that you need to backup the whole data bases every night.

I don't believe all that data changes every day, so why spend so much time shoveling the same bits again and again?

Think backwards. What needs to be restored, under what circumstances. What strategies can you use to achieve that restored state, without using the big hammer of moving all your bits every day. Maybe a full backup on the weekend with incrementals during the week?

It's all very well buying bigger and faster devices, but the brute force approach will eventually get too expensive.

[Robert Gezelter]

Jon,

Mea culpa. I did skip one step. The problem remains; while 2Gb SAN would be a problem for achieving the one hour goal, it is far less of an issue over a longer period.

I have seen many occasions where optimization can backfire. What works for one configuration can backfire in a subtle fashion on a different configuration. In this particular case, one aspect that comes to mind are the activities of the storage array.

I would question whether the SAN is achieving its maximum capability. What is the performance profile of the IBM SAN/controller? Individual volumes are not the only potential bottleneck, the volumes also all share an array controller, and that may very well be the bottleneck.

Yes, understanding a 3,300 line procedure with multiple threads can be a challenge, but there has been nothing mentioned that excludes some issue relating to task sequencing. Such issues are always perfectly obvious retrospectively; up front they always seem unreasonable. I will not lengthen this post with examples, however I will mention that even as simple a thing as BACKUP has had challenges with performance (outside of quotas).

More performance data illuminates, but tuning metrics does not correct problems with the underlying code.

- Bob Gezelter, http://www.rlgsc.com

[Bill Hall]

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

[Bob Blunt]

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]

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]

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]

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