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.

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.

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?