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
midrange.com
