Re: Thoughts on VTL solutions

On Sun, May 10, 2020 at 3:23 AM DrFranken <midrange@xxxxxxxxxxxx> wrote:

SAS, SATA, so close. :-)

To be sure :-)

2. The other vendor mentioned DUPTAP also with their VTL solution
connected to the ProtecTier. So would you connect the second VTL over FC,
and then go into BRMS and run the DUPTAP command to copy the entire
ProtecTier library to the other VTL? I should add the migration of the

BRMS

backups would be a one-off exercise. Once completed production would move
to the other site and there would be no need to connect back to

ProtectTier.

Correct. Effectively the transfer of the data to the new system
thus
reties the ProtecTier.

With BRMS the command is DUPMEDBRM which under the covers likely
uses
DUPTAP but the key is that not only does the data get moved to the new
device but BRMS is fully aware and that's important too.

That's good to know. We need to get metadata imported also

3. The SAN seemed like a good option since it meant we could use the SAN
replication feature to replicate the VTL backups to the DR site

Ahh yes. I see this and I understand why this sounds like a great
idea.
Another Yes is that it DOES work. :-) However what devices like the
Cybernetics do for logical dedup means the amount of data that needs to
be transferred is fabulously lower! They understand the stream of data
coming from the system at least enough to compare it to a master
(typically a SAVE 21) and then transmit only what was different. So that
big history library that didn't change doesn't get sent every day even
though it appears on the nightly backup tape. LOVE THAT!!

Once you watch a full nightly backup tape sync between SANS you'll
go:
"Ooooh, that took a long time and laid a big hurt on bandwidth!!"

Well that might be complicated by the fact we might need to ship the target
VTL to another site. And our security folks are nervous of that because of
the confidentiality of the data on it. So if the BRMS backup is not
encrypted they are doing to want the data written to the new VTL encrypted.
That might impact deduping - I don't know.

4. Another VTL we were looking at LaserVault (
https://www.laservault.com/vitl-2/vitl/ ). I looked at their demo and it
looks like it's BRMS so the users would be used to that. Plus there is a
web interface. Plus thei provide software only as an option so you can

run

on your own kit or even on a VM in your virtual machine farm

This sounds like a good idea and done right I think it could be. However
it will take proper design so that there is *ZERO chance that the backup
data written by the VTL is NOT on the same storage as IBM i itself. Also
be sure that multiple servers aren't pouring data into this same storage
thus causing performance issues.

The server storage will be on on-board flash drives. The SAN will only
contain VTL data

Additionally one needs to understand a full recovery such as when your
data center burns or floods. How hard will it be to get to a point where
your VTL is available to use for recovering IBM i? If that requires a
SAN rebuild and then a VMWare rebuild and then a VTL install and then
data recovery to thee SAN and finally you can recover IBM i that might
not work well in your recover time line!

No we will have the same VTL at the DR site connected to a DR server that
is replicating data in real-time using Mimix across a 10Gb fibre link. In
retrospect. the VTL itself could do the replication, rather than the SAN.
But we want the SAN one day to potentially used for the server but on
different drives of course. So in a DR event we cut over to the DR site
where there will be another Power server current copy of data, VTL and
completely duplicated network.

In short this type of solution requires many more parts than a

standalone VTL solution. Personaly I want a very clear and comfortable
understanding of the reliability of my IBM i backup solution.

Agree with that

I am presuming that nobody really minds that the VTL vendor they are

using

is not "approved" by IBM?

Mostly true. THE key question we ask is "Can I do a "D" Mode IPL from
your device." If they hesitate even for a second, Walk Away. Then of
course assure that they properly emulate a popular IBM library such as
the 3584 or TS3x00. All the ones mentioned in this thread by me and
others at this point answer these questions correctly.

Yes the LaserVault we are looking at supports "D" Mode IPL

That said support is important. IBM generally does not hang up the phone
when you say SPHiNX or Cybernetics. They know of and hear of these
things regularly. They WILL at least work with you to help with what
they see not working.

Our thinking is, we buy the Power 9 and SANs from IBM as well as all the
software of course. The VTL is provided by another vendor. If it dies then
we go to the VTL vendor to fix. About the only time I can think that IBM
might point finger is if there is a software issue where suddenly BRMS
cannot talk to the VTL. The VTL is supposed to emulate a tape device and
hypothetically speaking perhaps one day some APAR that is applied to IBMi
one day breaks that integration. Then it is likely to break all VTL
solutions.

An example: One of the vendors when we moved their VTL from POWER7 to
POWER8 and importantly from a FC #5901 card to a FC #EJ10 card would
randomly disconnect from IBM i. (EJ10 was brand new at that time) IBM
pointed out what they were seeing on the IBM i side and the VTL vendor
responded by sending a tech with a special SAS logging device. With data
from that device the vendor was quickly able to correct their software
to work with the FC #EJ10 card. They also quickly added a FC #EJ10 card
to their lab.

I think we we were advised that the VTL solutions certifieds QNAP FC cards.
They seem to be reasonably standard. And since this is a new installation
we just need to make sure the FC card can talk to the Power 8 and 9 on on
one side, and to the IBM SAN on the other.

Thanks again. That's really helpful.