Yes, works like a champ.
On weekends, we also append the dups.
Two Dup tapes come out Monday morning, one for each LPAR.
Each contain a dup of Friday, Saturday, and Sunday nights save.
5 control groups on Production.
Our weekly and ME save actually use the same control group as the daily save, except with overrides for longer retention.
Simple, Easy and less to maintain.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Friday, January 27, 2017 2:57 PM
To: Midrange Systems Technical Discussion
Subject: RE: What Was Discussed At the Big LUG Meeting
How do you fill up the tape? Append save?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 01/27/2017 02:52 PM
Subject: RE: What Was Discussed At the Big LUG Meeting
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
I'm on LTO7.
We do fill up our tapes.
Every save remains in the library.
Never have to load a tape for a restore.
BRMS autodup goes offsite daily.
And LTO7 may actually out perform the VTL.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Friday, January 27, 2017 2:45 PM
To: Midrange Systems Technical Discussion
Subject: RE: What Was Discussed At the Big LUG Meeting
If you're seriously looking at upgrading tape also I have to say that VTL
is the only way to fly.
To test that BRMS restore on an earlier thread did not require me to call
Iron Mountain, wait for delivery, load multiple tapes, or even get out of
my seat. And ran in mere seconds.
Some people may argue that the cost per byte of tape is significantly
less. It may be. However, whoever fills up all their tapes? So you've
got this $150 tape holding some small amount of archive data that you're
going to retain forever. That, and the VTL's have some awesome deduping
which significantly reduces physical space consumed.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 01/27/2017 02:29 PM
Subject: RE: What Was Discussed At the Big LUG Meeting
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
HA is not part of the equation.
It's been brought up many times, some demos, some quotes, but never moved
forward.
Our future storage will 100% internal SSD or direct connect SAN with 100%
SSD.
Maybe it will be "FLAPE" which is flash for primary storage, and for true
archive and stuff that hasn't been accessed in 24 months , it will be
tape.
Let's see what the 3rd quarter P9 announcement includes.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Oberholtzer
Sent: Friday, January 27, 2017 2:15 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: What Was Discussed At the Big LUG Meeting
You could, but in that type of environment you'd be giving up quite a bit
of
the flexibility the SAN provides. Remember one point, a virtualized
environment cannot virtualize underneath it so the SAN in this case would
need to be direct attach.
If you're going to do SAN you might just as well bite the bullet and get
the whole package, there's only a negligible difference in cost once the
SAN is
there. The one selling point that's huge is flashcopy. I can flashcopy
one of my customers database (about 14TB) is seconds, then use that to
back up with and do non update reporting. Production just keeps on
rolling with only a slight interruption that almost no one notices.
As Larry pointed out there are quite a few updates that need to be done,
but assuming dual VIOS and dual SAN switches, it's almost always
non-disruptive.
Might slow things down for a few minutes here and there but for the most
part most folks won't know the update is taking place.
This also brings into play Partition Mobility too. You'd be shocked at
how easy that is once it's set up.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Friday, January 27, 2017 1:00 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: What Was Discussed At the Big LUG Meeting
If you only have a few LPARs, i5/OS only, why not have one LPAR be
dedicated and connect to the SAN, and the others could be hosted NWS.
No need for VIOS.
No need for SAN switches.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
DrFranken
Sent: Friday, January 27, 2017 12:47 PM
To: Midrange Systems Technical Discussion
Subject: Re: What Was Discussed At the Big LUG Meeting
So here's my take on SAN Disk for i.
1) SAN is useful if you want to do remote replication. SANs (with
PowerHA) do that much better than does PowerHA using IBM i internals.
Both work, but above a threshold of perhaps 1T SAN is the only way to go.
2) SAN is useful if you want to do flash copies. There is no flash copy
outside the SAN. Once you flash copy you won't go back. :-) :-)
3) SAN is useful for mixing spinny and SSD storage. The SAN watches all
I/O recognizing most used data and moving that to SSD and clearly the
inverse as well. Note that it has NO FRIGGIN CLUE about objects only
blocks of data. So if you beat the dickens out of 1% of some key files it
will put that on SSD but not the rest of those files. If you 'tag' a file
*SSD on IBM i it moves (if it can) the entire file to SSD not just the hot
bits. This could be good or bad in your environment.
Internal IBM i SSDs are awesome if you have ONLY those, or enough of them
to hold your most important data. However daily management of what goes on
them is a chore on IBM i if you don't have 'enough.'
4) SAN is great for expansion as you can add drawers, add drives, and
create more storage for your partitions or for new partitions with no
outage.
5) Price wise do not be scared by SAN list prices. Discounts are, um,
'significant' and they better be because the list price for a 600G 15K
2.5"
SAS disk for Storewize V5000 family is 2.3 times the list price for IBM i.
No I don't get that either. In the end above about 10T 'or so'
SAN disk is cheaper than internal disk in addition to the above functions.
Above that SAN disk gets and stays significantly cheaper than internal
disk.
So you should use SAN disk. . . . but . . . (and you heard that coming!)
A) Be prepared to update the code in your SAN switches. This is not a hard
thing to do if you do as many as I do. But it's fantabulously different
than GO PTF, 8. And it will scare the crap out of an IBM i only admin. And
the switch will cold reboot so you lose your connections. This is why you
have two switches isn't it.
B) Be prepared to update the code in your SAN. This is even easier to do
than is the switch but you need to do it. And you need to KNOW to do it.
Good news is you don't lose connection as it updates one node at a time
though you may get messages about lost disk connections during the update.
C) Be prepared to update the code on the drives in your SAN. This is less
simple than the SAN itself and believe it or not most drive firmware
updates can be done with the drive in use (really!) This will be needed
almost every time IBM replaces a dead guy.
D) Be prepared to update the code in VIOS. And frankly to manage VIOS
itself. This isn't anything LIKE updating IBM i. Not even close and you
need to divine out whether the errors mean anything during the update.
(I love that part.) But again you have two VIO Servers correct? Or you'll
have an outage. Outage is bad.
E) Be prepared to maintain hardware and software maintenance on these
things. Or else. The prices won't kill you but honestly it's more
contracts to maintain and easy enough to mess up and find yourself
unsupported.
We are selling SAN disk about 1/2 the time except for the bottom end guys
with one 'partition' servers.
As I said to one of the people likely reading this: "Great revenue
opportunity for Larry." :-) :-) (and I sell disk!)
- Larry "DrFranken" Bolhuis
www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.
On 1/27/2017 11:39 AM, Rob Berendt wrote:
I'm waiting on whether or not SAN disk will really take off in the SMB
IBM i environment.
Even in those shops with SAN storage already in use for their Windows
servers.
Rob Berendt
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link:
http://amzn.to/2dEadiD
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link:
http://amzn.to/2dEadiD
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link:
http://amzn.to/2dEadiD
midrange.com
