| Oracle® Database Storage Administrator's Guide 11g Release 1 (11.1) Part Number B31107-01 |
|
|
View PDF |
| Oracle® Database Storage Administrator's Guide 11g Release 1 (11.1) Part Number B31107-01 |
|
|
View PDF |
This chapter describes how to prepare your storage sub-system before you configure Automatic Storage Management (ASM). When preparing your storage to use ASM, first determine the storage option for your system and then prepare the disk storage for the specific operating system environment as described in this chapter. This chapter contains the following topics:
You can create an ASM disk group using one of the following storage resources:
Raw disk partition—A raw partition can be the entire disk drive or a section of a disk drive. However, the ASM disk cannot be in a partition that includes the partition table because the partition table can be overwritten.
Logical unit numbers (LUNs)—Using hardware RAID functionality to create LUNs is a recommended approach. Storage hardware RAID 0+1 or RAID5, and other RAID configurations, can be provided to ASM as ASM disks.
Raw logical volumes (LVM)—LVMs are supported in less complicated configurations where an LVM is mapped to a LUN, or an LVM uses disks or raw partitions. LVM configurations are not recommended by Oracle because they create a duplication of functionality. Oracle also does not recommended using LVMs for mirroring because ASM already provides mirroring.
NFS files—NFS files are suitable for testing, but are not a recommended configuration for production environments. Using NFS files with ASM duplicates ASM functionality.
The procedures for preparing storage resources for ASM are:
Identify or create the storage devices for ASM by identifying all of the storage resource device names that you can use to create an ASM disk group. For example, on Linux systems, device names are typically presented from the /dev directory with the /dev/device_name_identifier name syntax.
Change the ownership and the permissions on storage device resources. For example, the following steps are required on Linux systems:
Change the user and group ownership of devices to oracle:dba
Change the device permissions to read/write
On older Linux versions, you must configure raw device binding
After you have configured ASM, ensure that disk discovery has been configured correctly by setting the ASM_DISKSTRING initialization parameter.
Note:
Setting the ownership to
oracle:dba is just one example that corresponds to the default settings. A non-default installation may require different settings. In general, the owner of the disk devices should be the same as the owner of the Oracle binary. The group ownership should be OSDBA of the ASM instance, which is defined at installation.For detailed information about preparing disks for an ASM installation, refer to your platform-specific installation guide for Oracle Database, Oracle Clusterware, and Oracle Real Application Clusters (Oracle RAC).
Multipathing solutions provide failover by using redundant physical path components. These components include adapters, cables, and switches that reside between the server and the storage sub-system. If one or more of these components fails, then applications can still access their data, eliminating a single point of failure with the Storage Area Network (SAN), Host Bus Adapter, interface cable, or host port on a multiported storage array.
Multipathing is a software technology implemented at the operating system device driver level. Multipathing creates a pseudo device to facilitate the sharing and balancing of I/O operations across all of the available I/O paths. Multipathing also improves system performance by distributing the I/O load across all available paths. This provides a higher level of data availability through automatic failover and failback.
Although ASM is not designed with multipathing functionality, ASM does operate with multipathing technologies. Multipathing technologies are available from many sources. Storage vendors offer multipathing products to support their specific storage products, while software vendors usually develop multipathing products to support several server platforms and storage products.
See Also:
Your storage or software vendor multipathing documentation for more information about multipathing options for specific platforms and storage productsASM produces an error if ASM discovers multiple disk device paths. Because a single disk can appear multiple times in a multipath configuration, you must configure ASM to discover only the multipath disk.
With ASM, you can ensure the discovery of a multipath disk by setting the value of the initialization parameter ASM_DISKSTRING equal to the name of the pseudo device that represents the multipath disk. For example, if you are using EMC PowerPath multipathing software, you might set ASM_DISKSTRING to '/dev/rdsk/emcpower*'. When I/O is sent to the pseudo device, the multipath driver intercepts it and provides load balancing to the underlying subpaths. When using ASMLIB with ASM on Linux, you can ensure the discovery of the multipath disk by configuring ASM to scan the multipath disk first or to exclude the single path disks when scanning.
See Also:
"ASM Disk Discovery" for information about disk discovery
Note 294869.1 at http://metalink.oracle.com for information about ASM and Multipathing, refer to Metalink
http://www.oracle.com/technology/tech/linux/asmlib/multipath.html for information about configuring Oracle ASMLIB with multipath disks
Your platform-specific installation guide for information about configuring multipathing for your system
The following are guidelines for preparing storage for use with ASM:
Configure two disk groups, one for the datafile and the other for the Flash Recovery Area. For availability purposes, one is used as a backup for the other.
Ensure that LUNs, which are disk drives of partitions, that ASM disk groups use have similar storage performance and availability characteristics. In storage configurations with mixed speed drives, such as 10K and 15K RPM, I/O distribution is constrained by the slowest speed drive.
Be aware that ASM data distribution policy is capacity-based. LUNs provided to ASM have the same capacity for each disk group to avoid an imbalance.
Use the storage array hardware RAID 1 mirroring protection when possible to reduce the mirroring overhead on the server. Use ASM mirroring redundancy in the absence of a hardware RAID, or when you need host-based volume management functionality, such as mirroring across storage systems. You can use ASM mirroring in configurations when mirroring between geographically-separated sites over a storage interface.
Hardware RAID 1 in some lower-cost storage products is inefficient and degrades the performance of the array. ASM redundancy delivers improved performance in lower-cost storage products.
See Also:
http://www.oracle.com/technology/deploy/availability/pdf/lcs_OW.doc.pdf for additional informationMaximize the number of disks in a disk group for maximum data distribution and higher I/O bandwidth.
Create LUNs using the outside half of disk drives for higher performance. If possible, use small disks with the highest RPM.
Create large LUNs to reduce LUN management overhead.
Minimize I/O contention between ASM disks and other applications by dedicating disks to ASM disk groups for those disks that are not shared with other applications.
Choose a hardware RAID stripe size that is a power of 2 and less than or equal to the size of the ASM allocation unit.
Avoid using a Logical Volume Manager (LVM) because an LVM would be redundant. However, there are situations where certain multipathing or third party cluster solutions require an LVM. In these situations, use the LVM to represent a single LUN without striping or mirroring to minimize the performance impact.
For Linux, when possible, use the Oracle ASMLIB feature to address device naming and permission persistency.
ASMLIB provides an alternative interface for the ASM-enabled kernel to discover and access block devices. ASMLIB provides storage and operating system vendors the opportunity to supply extended storage-related features. These features provide benefits such as improved performance and greater data integrity.
See Also:
The ASM page on the Oracle Technology Network Web site at http://www.oracle.com/technology/products/database/asm for more information about ASMLIB,
http://www.oracle.com/technology/tech/linux/asmlib
to download ASMLIB from the Oracle Technology Network Web site
If you are a database administrator who is responsible for configuring your system's storage, then you need to consider not only the initial capacity of your system, but also your plans for future growth. ASM simplifies the task of accommodating growth. However, your growth plans can affect choices such as the size of the LUNs that are presented as ASM disks.
You need to also consider that I/O performance depends your host bus adapter (HBA) and your storage fabric, not just the storage disks. As you scale up the number of nodes in a cluster, you also need to scale up the storage subsystem.
For high availability, storage is only one component. Within storage, Oracle recommends that you configure the database work area to be separate from the recovery area. You also need a method to protect against disk failures by using hardware mirroring or host-based mirroring from a normal or high redundancy disk group. Furthermore, you also need to consider multipathing for HBAs and the fabric when considering storage availability. With ASM mirroring, the failure group configuration also affects high availability.
