Browse Prior Art Database

Method to Accomplish Autonomic Storage Allocation for a Clustered Server Application with Multiple Instances Disclosure Number: IPCOM000125933D
Original Publication Date: 2005-Jun-23
Included in the Prior Art Database: 2005-Jun-23
Document File: 3 page(s) / 30K

Publishing Venue



Method to Accomplish Autonomic Storage Allocation for a Clustered Server Application with Multiple Instances

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 3

Method to Accomplish Autonomic Storage Allocation for a Clustered Server Application with Multiple Instances

In a system in which a server application runs on a two node cluster the common practice is that an administrator would manually perform the following to allocate storage to the application(s):

1. Decide on and then configure the external storage subsystem into RAID arrays and logical disks (scsi luns). This involves using the vendor specific interface to the external storage subsystem.
2. Decide on and then configure the scsi logical disks into volume groups and also decide on what high availability resource groups the volume groups will belong to.
3. Decide on and then configure the volume groups into logical volumes, optionally creating file systems on these logical volumes and then assigning these volumes (or files and file systems) to the application or application instances being sure to match the assignments to the correct high availability resource groups so that the application has access to the storage when failed over.

It is desirable to reduce the complexity of the above tasks and to automatically configure or pre configure the system such that an administrator does not have to perform the above manually. When only one instance of a server is used the problem of allocating storage space is easy since all external storage is simply configured and initially entirely given to the one instance of the application. When multiple instances of a server are required the problem is more difficult due to recognizing the need for possibly multiple instances of the server where those instances may have different primary nodes within the cluster. It is desirable to automatically handle the storage allocation and simplify the management task while taking in to account the following complicating factors:
* Multiple instances of the application may be needed due to database constraints. The number of server instances ultimately needed will not be known at initial install and configuration but only as the work load over time dictates.
* We are in a clustered environment where storage has a "node affinity". Space assigned to a volume group that belongs to a resource group indicating node A as the primary node cannot be used by an application belonging to a resource group that is using node B as its primary node.
* We want the ability to put the database(s) and log(s) of the application on storage mapping to one set of physical disks and the backup/mirrors of the database(s) and log(s) on storage mapping to a separate set of physical disks.
* Once a logical volume is "given" to the application it cannot be taken back.
* Allow space to be allocated over time as the workload dictates while taking into account all the above factors. (i.e. the number of application instances, what their preferred nodes in the cluster will be, and how much space to allocate to each instance will not be known when initially setup but only over time as the box...