This article can also be found in the Premium Editorial Download "Storage magazine: Top 15 Storage hardware and software Products of the Year 2006."
Download it now to read this article plus other related content.
Upgrading servers and arrays
Due to rapid advances in server and storage technology, IT organizations usually upgrade their critical SAN components every three to five years. Combined with the need to patch operating systems and upgrade storage array microcode, this can result in significant planned downtime for critical ERP applications. In a nonclustered environment, IT organizations agonize over every operating system patch or server hardware upgrade because the ERP application has to be stopped during the maintenance upgrade. If the patch or upgrade doesn't work, the changes have to be backed out before the ERP application can be restarted.
Companies that have operated an ERP environment for 10-plus years have typically had to change their database server three or four times to reduce cost, increase performance and maintain a vendor-supported environment. In a clustered environment, the ERP application can be moved from one database server to another (from the active to passive node) fairly easily. Once moved, the patches to the database server can be installed and tested while users' requests are still being serviced. The application might be down during the migration, but that controlled migration is much less risky because all of the maintenance work can be done outside the critical data path.
Companies spend time and money to cluster their ERP database server, but most still operate their ERP application in a single storage array. While storage
Array-based replication software (e.g., EMC SRDF/A or HP StorageWorks Continuous Access) can be used to replicate every change from one array to another. The replication between storage arrays has no impact on the ERP app. Once the data is fully migrated and synchronized, the second array is made available to the database servers in the cluster and the first array is then extracted from the SAN and data center.
Companies replicate data from one array to another to increase the availability of the ERP application, but the second array is usually in a remote location except during an array replacement. Most corporations that implement ERP today have a single storage array that supports the database cluster in their primary location. The data is always protected within the array through mirroring, RAID, dual controllers and other array-based techniques. Duplicate arrays can be leveraged in ERP environments, but they're typically put in separate, remote locations; they also require the development of remote replication and remote failover capabilities.
Clustering is about increasing the availability of the application. It's important to remember that clustering techniques are used to reduce, but not eliminate, downtime for an ERP application. While there's some complexity associated with the techniques, the ability to work on the database server and the database server's operating system while the application is running outweighs management complexity. Storage managers who have mastered an ERP cluster can sleep easy at night and work on other pressing tasks during the day.
This was first published in February 2007