>What is a V2X2?
V2X2 is StorageTek (now Sun-Storagetek) disk array.
General reference name is SVA (Shared Virtual Array) and the various models
over the years have been:
IceBerg
9393
9500
V960
V2X
V2X2
V2X4 (and V2X4f for FICON attached)
We've gone through every model except the V960 at some point over the last
seven years.
>I think STK calls it: Log Structured Array.
>To me, its description sounded like 'virtual DASD'.
I believe they (the WinTel world folks) call it thin provisioning these
days. Works great.
I have only 2.8TB of physical raw disk in my V2X4f, yet I present 23.1 TB
of usable space.
Split three ways, I've got 7.7 TB presented to my production LPAR, another
7.7 TB for BCP snapshot copies, and another 7.7TB that is snapshot copied
daily and used as a sandbox LPAR.
If I was to go and buy disk from some other vendors and duplicate the
functionality I have today, I would have to be asking for that 23.1 TB of
actual physical disk.
>It's very important to keep the
>time window when the volumes are
>actually copied as small as possible.
I snap 926 volumes (almost all 3390-9) in about 1.4 minutes. We
dynamically create the snap JCL each morning right before our syncpoint
with a rexx routine wrapped around a dcollect report. This way name and
allocation changes are automatically picked up (one less possible human
error potential). With the automated IMS/DB2/TSO/etc down and up
processes, the whole syncpoint runs about 2.5 minutes.
> PPRC or XRC are not options due to cost
> PPRC need not to be expensive. Obviously it
> requires two dasd boxes and link, but gives
> you much better RTO and RPO.
We just replaced our tape based backups (which were taking about 3.5-4.5
hours with 9840's, HSDM, and ExHPDM) with a PPRC solution. HUGE reduction
in RTO as the 1-2 days it was going to take to ship the tapes to the hot
site was simply eliminated. The 4-5 hour restore from tape time was also
eliminated as the data is sitting on another V2X4f at the hotsite ready to
go. Last DR test we were IPL'ed in under an hour after arriving at the
local recovery center.
The RPO only lost a few hours (the difference between the time it took to
create the tapes verses push the data across the PPRC link) and is still
about 24 hours since we only take one syncpoint a day (after batch), but we
are looking at adding another in the pre-batch lull time. We'll probably
take a hard look (I'm hoping) at a GDPS solution as well since it would be
the next logical step.. but I fear the costs may simply be too high for
management to bear - even with the promise of zero down time.
Most expensive ongoing cost of the PPRC solution was the link cost. But we
manage to do it with a tiny DS3 by snapping the BCP sets throughout the day
and sending changes across the link. That way, when it comes to syncpoint
time, the amount of change data is very small and the DR set at the remote
site is set and stable and ready for recovery just 10-15 minutes after the
snaps (keeping the RPO close to that 24 hours)
Jeffrey Deaver, Engineer
Systems Engineering
[EMAIL PROTECTED]
651-665-4231(v)
651-610-7670(p)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
