We got us some new storage
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.