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