Ilja Coolen \ ICSS

Well,

It has been quite a while since my last post. I’ve been very busy working on a number of storage proposals. Which I guess is good in this time of financial crisis.

I’ve been working on IBM San Volume Controller for a number of years, and I even had a contract as a Storage Instructor for IBM San Volume Controller.  I have had many questions or remarks as to why the SVC still had no support for role based access and centralized account administration like LDAP or Active Directory. And honestly, it did surprise me how long it took IBM to incorporate it into the code.
Only recently, the SVC code 6.3 has been released sporting AD and LDAP user authentication. I have not yet have any change to test LDAP, but I did get Active Directory working. The IBM documentation isn’t all that detailed as to how to setup AD authentication. Neither has the AD support team on site been very helpful (accept maybe for one guy who seems to know what AD is all about).

There are a couple of things you should be aware of;

• The SVC is an appliance that is not trusted by AD, it is not part of a Active Directory domain. Therefore you might need to provide an AD account that has sufficient credentials to use AD to authenticate.
• The account you will use to query AD with (not the account a user uses to attempt a login) has to be configured with it’s complete AD location path.an example: you are provided an AD account that is privileged  to query AD that is called ‘ibm2145queryad’ and sits in the AD tree at “DOMAIN\Accounts\ReadOnly” (<-fictional).You will need to enter the ldapconfiguration in the SVC console as;

  chldap -username 'CN=ibm2145queryad,ou=ReadOnly,ou=Accounts,dc=DOMAIN,dc=corp' -password 'XXXXXX' -security none -userattribute sAMAccountName -groupattribute memberOf -auditlogattribute name -type ad

• Even if AD authentication fails because the query user is not authorized to query AD, the ‘testldapserver’ will result in a success. If you are testing authentication of a valid user login, this will result in a message that the user is not correct or the password is mismatched. This suggests the user trying to login is invalid, but actually, the account used to query AD is invalid. So this might throw you of a bit.
• Only supply AD servers or LDAP servers, do not mix AD and LDAP servers. This will not work as desired.

Your SVC administrators have to be members of a specific security group in AD, separating them from ordinary users that should not have SVC access. This group name has to be defined in the SVC as a remote group. Only users that are member of that specific security group in AD will have access to the SVC. The user group on the SVC has to be configured with specific access rights on the SVC, like “administrator” or something else that matches your company requirements. This role is also assigned to AD users that are part of that security group at the moment the successfully log in to the SVC.
When using LDAP or AD user authentication, local users still are usable. You will need a local account with the “Security Administrator” privilege to update LDAP/AD settings on the SVC. I guess you do not want to make all authenticated users have the highest privilege on SVC.

Once you know these quirks you will  be able to configure and use LDAP or AD services to authenticate your SVC administrators with. Two things I have to comment about are the fact you cannot enter LDAP or AD servers by their hostnames. You need to enter the IPv4 addresses. This also shows the second annoyance. There is no support for IPv6 yet. I guess it is on it’s way, but who knows how long this will take IBM.

The HDS Blogger Day or Geek Day 2011 was a blast. It was my first HDS Blogger day and when I entered the venue, I was kind of surprised by the number of HDS representatives in the room. At first it felt like a hearing committee. The HDS to blogger ration was about 2 to 1. After the introduction though, it already felt comfortable. HDS had assembled exactly the right sales and engineering staff, who were there clearly to listen to the feedback the bloggers were giving, and to respond thoroughly to whatever we could ask. HDS clearly knows how to handle a Bloggers event.

Corporate cultural change towards openness and feedback.

From the recent Hitachi Data Systems events a certain message can be distilled. If you know a bit about Japanese culture, than you will probably also know that in general Japanese people keep to themselves, as in they will not brag or tell you what they have or can do. This attitude has kept the rest of the world from knowing what is going on in Japan, and especially within Japanese IT land.

The earthquake and tsunami of early March would have been disasters that the rest of the world would have known little of, if they would have happened a few years back. This indicates that Japan is opening up a bit more to the rest of the world.

The same is true about the Hitachi philosophy. Hitachi Data Systems is now reaching out to the  IT crowd in the world to tell them what they are up to, and ask the customers/end-users what it is they want or need. This is a major change from what they have come from.

Hitachi now has to get that message and philosophy out into the world. Events like the Blogger Day and the Information Forums contribute a lot to that message, and I honestly have the impression Hitachi stands behind their message. So I would sincerely advise my readers to have a new and refreshing talk with your HDS representatives about this new approach.

Hitachi Servers

Lynn Mclean, Vice President Sales, gave an introduction to the server portfolio offered by HDS. Yes, servers. Hitachi is selling servers for some 50 years now. From mainframe type servers to blade chassis and servers today. The Hitachi Storage Division (HDS) is no longer limited to storage. As of 2009 Hitachi Ltd. has decided that it is up to the Hitachi Data Systems group to enter the server market in the US and EMEA region. If you consider that servers process data, that will make sense. Otherwise Hitachi should change the HDS acronym to “Hitachi Datacenter Systems”, to encapsulate all products they are covering in the datacenters. That would even work on their networking gear. Yes, HDS even has networking gear, but at this moment (Sean Moser gave away a small teaser here though), this is no fancy revolutionary stuff, and is not sold outside Japan. From my local HDS rep I also understood Hitachi even has a DBMS and Unix of their own.  I am completely flabbergasted. I would definitely love a peek into that stuff.

So in case you are now thinking whether or not you have been living under a rock for 50 years, because you didn’t know HDS is selling servers, the answer would be no, you’re probably fine. Hitachi actually did not sell outside Japan up until 2004, so they are fairly young in the US and EMEA server market, but not young enough to get away with existing completely unnoticed. Therein lies the actual problem . Hitachi has a huge marketing flaw that has allowed the Hitachi servers to go unnoticed for this long.

The gear we have been introduced to, actually seems nothing less to what other vendors have to offer. It’s decent and high-tech equipment of at least the same standard as all Hitachi equipment.

Blade failover, blade stacking are features supported by the majority of blade vendors. The one thing that does stand out is the fact the blade chassis has 8 internal PCIe busses available for expansion, along with the somewhat standard mezzazine slots.  If those PCI slots aren’t sufficient, you can externally expand with a 16 PCI slot expansion unit, which interconnects to the main chassis on two of the internal PCI slots using PCI-Express connections. This expands connectivity massively for a blade chassis, but the performance is not enhanced, as you are limited to the bandwidth of the PCI lanes of the two busses in the chassis.

Hitachi already recognized that this needs more work. Hitachi is able to deliver a completely filled 42u rack with 320 high density micro servers. The total rack would consume less than 12 Kilowatt. Whether or not this is a great accomplishment, actually depends on the total processing capacity this rack would have. I need to dig deeper into this to make a comparison. There are bloggers out there that know server stuff better than I do, so I will be collection a number of related posts later on. For now, you will have to do with some HDS documentation I could find that contains a reference to the Hitachi servers.

They have no other differentiators I know of, but that could also proof that they potentially could have been right up there with the server market leaders, if they would have done marketing right.

Should we worry about Hitachi trying to enter the server market to take on vendors currently ruling the datacenters? According to Lynn, the approach will not be to take on the other big dogs, but include the servers in a complete solution package, which I consider to be comparable in concept to UCS or VCE type solutions.

It is good that Hitachi is not arrogant enough to pick a fight.  I think they earn respect for that attitude. Searching the HDS website gave me no results on servers except some white papers, so I  think Stephen Foskett’s quote is spot on.

“HDS is smart enough not to wander into the blade server saloon and pick a fight with the big guys at the bar #HDSday “

More to come from this event on “Hitachi Content Platform” and “Storage Economics” when I get time to write….

In the mean time, make sure you read these related posts (updates will follow):

• Chris Evans :  Hitachi Bloggers Day 2011 – Part I (focus on VAAI)
• Hu Yoshida : An Amazing Week of Content and Context
• Bundled search result by HDS
• Juku IT : Hitachi’s new VMware strategy (focus on VMware)

Disclaimer:
HDS has invited me and a range of well known and respected bloggers to visit HDS EMEA Headquarters at Sefton Park UK for  the 2nd HDS Annual Blogger Day. Travel expenses and meals have been paid by HDS and there we are not obligated in any way to write about what we have seen or heard. My time has not by compensated, except for the good company I was in.

Tomorrow I will be attending the HDS 2011 Geek / Blogger Day. In light of this event and the recent Calvin Zito (@HPStorageGuy) post on the HP APEX features I had some thought on this.

We all know HP OEM’s the HDS VSP product, as they did (still do actually) for the XP (HDS USP) series. In the third quarter of last year, HDS announced the new VSP product line, instantaneously followed by HP and the P9500. HP is differentiating itself from HDS by having some additional features that are not available from HDS.

The HP Application Performance Extender (APEX) enables certain host operating systems (currently Linux, Windows and HP-UX) to prioritize their host I/O over other systems. This enables IT departments to set performance characteristics to their core applications to ensure the optimum services to their (internal) customers.

In the post by Calvin Zito I mentioned at the beginning, you can read the APEX software now also allows for LDEV ownership transfer to a less busy controller in the P9500. This way you can also optimize the array usage without depending on APEX host agents.

For this to work properly, you might want to make sure you do not set conflicting values for the APEX host agents and the settings for DLOM. My question, will the DLOM micro-processor ownership changes also change preferred LUN/ALUA settings in respect to the host, if they notice it at all? I believe not all native host MPIO drivers like this while being actively used.

Anyway, one of my questions for the HDS Geek Day will be whether HDS thinks an APEX type feature is not needed at all, or if they are working on a similar feature to be used by the VSP.

This post actually is more of a summary of notes I took during Tech Field Day in Seattle 2010.

• NEC is very environmentally aware and has some very strickt rules about every innovation has to be more environmentally friendly than the product it replaces.
• NEC is active in very many industries, from space engineering to construction.

Mini HYDRAstor

The Mini HYDRAstor is the same as a regular HYDRAstor, but the storage and accelerator nodes are both in one chassis.

• GA’d June 30th 2010
• Same code base as it’s bigger brother.

HYDRAstor

• Two tier approach
  • Accelerator nodes (XEON based arch)
  • Storage nodes
• Unrestricted expandability.
• Each tier is independently expandable, so we have scale-up and scale-out.
• Each node can be independently replaced by new equipment if available, without disruption. NEC calls this Adaptive Grid Storage.
• All the modern techniques are available, like Thin provisioning (not sure about zero-page-reclaims though.
• All nodes are interconnected through 1Gbs interfaces. The SN have 4 ports each.
• Global Inline De-Dupe
• Application aware De-Dupe (based on profiles selected during creation of the share). The SN knows what part of the incoming data is user data and what part is meta data. After separating this data, the dedupe only is done on the user data. This enables better De-Dupe ratios.
• HYDRAstor comes with 1 Storage Node for every 2 Accelerator Nodes.
• Filesystem size is 256PB by default.
• Shares can be on NFS or CIFS (SMB1 though).
• CIFS and NFS mountpoints can not be the same filesystem. They have to be separate filesystems.
• WORM FS (HYDRAlock)
• Licencing is based on the feature and the number of accelerator nodes it is configured on.
• RepliGrid – allows for data to be sent offsite for DR purposes (aSYNC).
• HYDRAstor architecture features: 1) support multiple generations of node hardware in one grid.
• HYDRAstor architecture features: 2) non-disruptively add multiple generations of nodes to existing grid.
• HYDRAstor architecture features: 3) capacity automatically discovered WITHOUT provisioning.
• HYDRAstor architecture features: 4) existing data auto load balanced across nodes.
• HYDRAstor architecture features: 5) data resiliency level automatically maintained via Distributed Resilient Data.
• There are no virus scanning features.
• Many-to-one and many-to-many replication (at this time, there is a 16:1 fan-in ration).
• In-flight encryption.
• HYDRAstor-Netbackup OpenStorage Integration.
  • Dynamic IO        (free of charge)
  • Optimized Copy
• Snapshot and replication are not charged extra.

Storage Nodes

• Automated aggregations of scattered fragments.
• storage nodes scale from 10TB to 20PB with all storage managed as 1 logical pool of capacity.

Accelerator Nodes

• 20 AN’s achieve 10GB/s
• 500MB/s per NEC Accelerator Node
• 36TB/Hour on a 4 rack system (20 AN / 40 SN config)
• An 11-rack HYDRAstor delivers over 25 GB per second or 90 TB per hour of throughput.
• Takes care of the chunk based De-Duped replication, based on a filesystem level.

Erasure Coding

• User determines the level of resiliency. You can enable protection to up to 6 disk failures.
• Data chunks are variable in size.
• No RAID, therefore no penalty in RAID rebuilds after failing disks.
• Chunk is broken down in fragments, this technique is called Distributed Resilient Data (DRD).
• Recovery of failed disks is always performed on the remaining storage, and is not postponed until the failed disk is replaced.
• Minimum of 9 chunks are required to reconstruct the fragments into user data. The first 9 received chunks are used, therefore not being impacted by busy SN having a high latency/delay.

Availability

• Europe / EMEA region is not yet on the roadmap.
• Just Japan and Northern US.

Pricing

• Smallest config :
  • $40,000.- Starting at 4TB (listprice)
  • $25,000.- per additional 4TB (max 12TB raw cap)
• Largest config :
  • Minimum $120,000.-

What’s missing

• Cloud-> add REST interface to enable cloud services.
• SMB2.0 or higher would greatly enhance performance for CIFS enabled backup applications or end-users storing files on it directly.
• Virus Scanning (for customers that would like to store files on it directly)
• For long term archiving a MAID implementation would be the GREEN option.
• EMEA availability.

References

• Reference customers get support costs discount.
• Case Studies

The TechFieldDay success must be huge, when a company decides to use TFD as a platform to announce it’s launch. The delegates are all witnessing this launch. It is a great experience to be able to be part of an event like TFD, especially when you also get to be part of a new companies launch.

The introduction

The new company is called NimbleStorage, was founded in 2008 and is based in San Jose.  Nimble Storage offers a hybrid of flash and SATA storage array. The 3U high box services iSCSI storage and has a fixed size, no scale-up. Nimble Storage claims to achieve 60% cost reduction than existing solutions. Nimble’s storage architecture is “log-structured file system” which was created by Mendel Rosenblum (VMware founder).

• Varun Mentha (CEO & Co-Founder) kicks off by introducing his crew.
• Umesh Maheshwari (CTO & Co-Founder and filesystem expert)
• Dan Leary (VP Marketing)
• Ajay (Former Netapp)

Nimble Storage will be selling through VAR channels exclusively. At first they will be selling in the US only, but expansion to Europe will be in the works for 2011.

The technology

• (MLC) Flash and Low-cost High-capacity SATA disks iSCSI based storage targeted at the mid-sized enterprises.
• Point in time snapshot primary Replication based DR
• Capacity optimized snapshots in stead of traditional backup to eliminate backup windows.
• Listpricing < $3/GB
• Cache Accelerated Sequential Layout (CASL Highlists)
  • LZ-ish based inline compression reduces data 2-4x (no dedupe)
  • Flash caters to high-performance for all active data
  • SATA disk cost-effectively stores all primary data and 90 days worth of snapshots
  • WAN efficient offsite replication
• Application aware snapshots/backups (Microsoft VSS and VMware integration)
• Nimble Storage says they are 35x time more space efficient than leading vendors in this market (eg:Dell/Equalogic)
• Different retentions periods for local and remote data
• Bi-directional replication
  • System many-to-one replication.
  • Volume is one-to-one replication. This means many systems can replicate to one, but a single volume only has a single replication relationship.
• Rapid fail-over between sites (including flexible iqn identities)
• Version 1.0 is not cascaded replication, but it will be there in future releases
• Application templates
  • Predifined application aware storage and data protection configuration
  • LUN Blocksizes are matched to the application
  • LUN Caching is matched to the application
• Zero-copy hypervisor integrated cloning (included in the package)
• Web based GUI, and SSH based full featured CLI interface
• Full autosupport feature built-in (Real-Time Phone Home Support)
• MPIO is used for fail-over, no network based LACP

The flash storage is used as an intelligent cache that holds all the active data. What is active data is determined by the use frequency (and more). The cache is indexed. All data is written to SATA disks, so the flash disks are really only used as cache. All incoming data is compressed inline. Due to compression, the actual blocksize of the written data can vary. Because all the data is written sequentially to the SATA disks, the various blocksizes pose no real issue, and they are all supported. This also enables an application specific blocksize. By using templates in the definition for volumes, you can match the blocksize to match the blocksize to for example an Microsoft Exchange database volume, and another volume for it’s logs where both have different blocksizes.

All volumes can have their own snapshot schedules, or they can be grouped together in Protection Sets, which can be considered consistency groups (volume groups, not hosts groups).

You might be affraid that the SATA disk would provide bad performance, but the sequential reads and writes are actually something SATA disks can do pretty well. So this performance risk is mitigated by the compression-sequential-write (full blocks) part of the array’s code.

The flash cache is made up out of SSD’s, and are hot-replaceable and are shared between the controllers. All data is already on disk and therefore there is no need for any means of protection for these cache disks.

Products

• 3RU Units, large flash layer, multicore Intel Xeon processors
• Comes with 2 x quad GbE NICs
• Everything is redundant (controllers are active/passive)
• All drives are hot swapable
• peer-to-peer clustering
  • CS220: 9TB primary + 108TB backup
  • CS240: 18TB primary + 216TB backup ($99.900.-)
    • 1.3TB flash capacity based on 2x compression
    • 12 x 2TB disks (1x hot-spare/2x parity)
• Annual maintenance between $4000 and $6000 .

Roadmap

Although NimbleStorage wasn’t going to give us any formal roadmap intel at the moment, the following features are surely being introduced in upcoming upgrades/updates.

• Cascaded replication                        
• VMware SRM integration
• 10GbE NICs
• V1.1 Scale out, LUN’s can be striped across arrays.
• Role based access.
• QoS for replication sessions (including time of day based policies)
• SNMP alerting
• FCoE

Overall impression

Curtis W. Preston asked (and I was pondering on it) “why not NAS?”. The midsize customer segment doesn’t use a lot of NFS and for CIFS, the tend to use a regular Windows file server with (iSCSI) block storage from the SAN. The context to me was actually that it was not a need-to-have feature for the product launch. There might be a different view on the file services option in the future.

I am very impressed by these guys. They bring a ton of experience into the company which is transfered into their products. It is clear the products are functional and quite complete, but a couple of relevant features are still missing. The relevance is dependent on the size and level of operations of the client looking into this product. Smaller customer might not be depending on SNMP alerting or 10GbE interfaces. These features and the aforementioned features are sure to be introduced shortly after this launch.

The Nimble Storage guys presenting at Tech Field Day are brave in my book. They come in to present a new company and new products to a group of tech guys that could give them a really hard time, but they stood tall, and gave us a very great presentation. They definitely believe in their product, and at the same time respect their competition.

I will be watching them closely.

Resources

• Nimble Storage
• In The News (Gestalt IT)
• Twitter @NimbleStorage
• Facebook

After a couple of months of negotiation’s and specification checking, we finally were able to place a new storage order for replacing our current IBM Sharks and DS4300 (fiber) disk systems. We decided to go for 1 kind of box, even though we could save money on some midrange storage systems. We have had our share of nasty experiences with the mid-range boxes, so we decided never to make any concessions on reliability again.

For the next few years, we will be running our centralized data on IBM’s DS8300 boxes. Two to be precise. One in each of the two locations, serving 90TB net capacity each. We will be mixing z/OS and OpenSystems, like we currently do on the Sharks.In front of the DS8300 we will keep our San Volume Controllers active for OpenSystems servers, even though one could questions the necessity for this.  We are very pleased with the SVC’s due to it’s flexibility and possibilities.

We are now preparing the migration to the new environment.
We would normally have no work on this, because the SVC does all that in the background. We have those old nasty AIX4 servers biting us in the butt though. The AIX admins are forcing upgrading to AIX5 to our customers, but this still isn’t going as fast as we’d like. The AIX admins are not working with me on upgrading their fixlevels and drivers for SVC, so we cannot upgrade the SVC to it’s current level 4.1. We need the current level though for the new hardware on which the SVC software runs. We cannot stay behind, just because of some unsupported operating systems, so we decided to put them in a death-bed on the current older SVC storage. We will be migrating all supported platforms to the new SVC hardware running the new code, using the somewhat traditional methods.  AIX supports the migration using the migratepv commands, and Windows will be done using the TOPIO software. So we have some nice tasks ahead of us.

Our IBM mainframe will have the least amount of work, using FDRPASS for the migration. We’ve done this a couple of times before, and this works perfectly. As it seems, AS400 systems can also do online migration by telling the OS to start removing volumes from its memory pool. We are investigating this. Otherwise, it will be a traditional backup/restore migration.

After the migration, we will be implementing full synchronous replication between both sites for all data based upon IBM’s Metro-Mirror. This will include Windows, AIX, Solaris, and VMware ESX data.

While going through all necessary preparations, it seems that everyone (not involved in storage) knows best, and is trying to force us into using their insights when designing the replication. When we would give into this, we would be replicating tons of applications using all application specific methods. What a nightmare that would be.
I preemptively agree on comments you will probably post, stating that several situations would be best solved by using application specific solutions. As the setup progresses, we are sure to encounter some situations where this applies. But sometimes you have to choose the lesser option, in order not to make stuff to complex or not to have consistancy issues.

The storage deal on disk replacement is over. A decision has been made.
Are we happy? Sure, why not. Did we get what we want? Well, technically we had a better option, but financially, we couldn’t refuse this final offer. The financial gap between the winner and the runner up, was just to big. The technological differences aren’t enough to justify the extra investments.
So we didn’t get the best money could buy, but we did get a good deal, and we do get good storage for these euros. Besides, the big-iron players’ high-end range storage subsystems are all good stuff and they do not differ too much in capabilities.
Another plus for my company is, that we do not need to go through a massive migration, don’t have to rewrite tons of scripts, don’t have to change multipath drivers on hundreds of servers. That’s worth something too, right? We were willing to go through all this changes, but in the end, like Meja said in track 2, it’s all ’bout the money.
My company is happy, because we made sure that the next four years, we have a good price per gig. Which in turn will make our customers happy as well. And this is why we have the job.

A downside to this is, that we don’t get experience with new equipment, new vendors, new methods, and more. Well, better luck in about 4 years.
Later.

PS: Merry Christmas to you all.

It has been a while, but here’s something I am trying to figure out for some time now.

We’ve bought a Diligent VTF with ProtecTIER (data deduplication on virtual tapes) in the first quarter this year. The main reason was that nice feature where we could store up to 25 times the amount of actual disk space we had available for virtual tape.
Since then, almost all virtual tape vendors have some form of data deduplication. I guess this is a flaming hot feature. The big-irons are lagging behind a bit, but no doubt they will soon step up, and try to dominate this field too.

The one thing I wonder about is, since storage is this hot, why the disk vendors aren’t incorperating data deduplication in their subsystems?

• Is it  the fact that they will loose revenue on the disk sales? (my best guess).
• Is it because it is to hard to write the code? I don’t think this is a problem though.

Computer room cooling, energy costs, floor space should all be factors to take into consideration. These factors would justify data deduplication on disk storage from an end-user point of view. Vendors always find ways to increase their profits, even though the hardware prices are dropping constantly. I see no obstacle here.

Up untill 2003 we were using IBM’s RVA (StorageTek OEM)  on mainframe systems. The logstructured volumes were perfect. Compression was done in de RVA, without the host knowing it. We were able to store about three times the amount of data than was actually present in the box. Need more volumes. No problem. We’d carve out another model 9 volume (9GB), and no actual physical disk space was consumed, untill some data was stored on it.
When StorageTek came out with the successor of the RVA, called the V2X, we were eager to use it because it also supported Open systems lun’s.

Unfortunately the design of the V2X had some flaws. Especially in the microcode. The V2X wasn’t stable enough for us to run open systems volumes on it. The compression and snapshot mechanisms worked fine, but paths from the host to the V2X kept on dropping connections. We decided to send it back to STK, and we continued our storage services on the IBM Sharks.

So doing compression and deduplication in the storage box is just a heartbeat away. Now we just need to wait for the first vendor to pick up the gauntlet and start shipping the storage box including dedupe code. The rest will soon follow.

Need someone to test for you? Just give me a call

It’s Friday afternoon where i live, and i took the afternoon off, to be with my wife. Surprise i said when i got home. I surprised only my dog. The kids are in school, and the wife is obviously gone somewhere. So i sit here, with my Senseo coffee, thinking about the discussion i had earlier this morning at work.

I wanted to design some flash-copy scripts against our IBM San Volume Controller, in order to perform some flash-copy tasks for the Windows servers. In the forum i already started a new topic about this. So i talked to my partner about how i intended to do it, and what my obstacles were. I wanted to know how the disk (read volume) was mounted on the Windows host. But i had no method in matching the unique ID’s i got from the SVC tot the disks in the host. Windows doesn’t keep track of the LUN’s serial numbers without installing third-party tools. How could I possibly know where to put the target disks. I want them to be easily recognized by the path they are mounted in.

An example.
The source host (called HOST01) has 2 disks, one is mounted as E: and the other is mounted as F:\Subdir\Mountpoint. Let’s not make it to complex, and have both volumes comprised out of only one disk, so no spanning here. My target host is another server called HOST02.
I want the targets to be recognized by the path on HOST02. All FC targets will be mounted somewhere under the drive letter F: which tells me it are FC volumes. Something psychological i guess. That would then look something like this:
HOST02 -> F: \ HOST01 \ E
HOST02 -> F: \ HOST01 \ F \ Subdir \ Mountpoint

All the information on the paths and drive letters have to be dynamically gathered. Quite the task i tell you. But given my know how, i should be able to pull it off. By doing this, i tried to solve my flash-copy problems on Windows, and simultaneously make a completely new backup design. My partner nods his head. Don’t make it this complex he said. Just try to pull off the flash-copy first, without considering all the variables. We are in the middle of redesigning our infrastructure anyway. We want to ban the current methods of doing our DR backups, and recoveries. So we are planning on doing a full flash-copy to a remote location of all our data anyway. So, just have the SVC do it to all the LUNs it knows about. Hmm, i think. But i want to make the file level backups easier as well i say.
Even though it’s hard to admit, he’s got a point there. Why change the complete file level backup methods, when you can have all the data flash-copied with minimal amount of effort? After having accomplished the easy part, you still start on working on the way we process file level backups he said, but there’s no pressure there. And you know what? He’s right. So i will probably propose the new insights to my management.
Guess those mainframe storage admins have an advantage on the OpenSystems guys when it comes to simplicity. Why do the OpenSystems admins tend to choose to do stuff the hard way?