HP StorageWorks 8000 NAS 8000 Unix - Oracle User's Guide - Page 5

storage management and definition guide, defining NAS 8000 storage for Oracle databases

Page 5 highlights

database. Until recently, conventional wisdom had the database administrator placing different tablespaces/data files on different disk controllers/RAID arrays in an attempt to improve performance through the concurrency allowed by multiple disk interfaces. Multiple hard drives/controllers allowed multiple data pathways for 'simultaneous' access to data, as well as allowing multiple copies of critical files to be stored on separate hard drives to protect against some media failures. Although this software mirroring of critical data files offers some protection in the case of a media failure, it also uses precious CPU cycles and I/O bandwidth from the Oracle server to accomplish the mirroring. As well, the use of multiple disk controllers/RAID arrays creates administration overhead and can make the environment very complex and requires server CPU cycles to manage and maintain. The NAS 8000 and its storage subsystem provide a high level of concurrency for fast and efficient data access, and utilize RAID 0/1 or HP AutoRAIDtm technology to protect the data on the storage subsystem's hard drives. AutoRAIDtm combines RAID levels 0/1 and 5DP, controlled and configured in "real time" by the VA 7xxx firmware, to provide total protection/recoverability in the event of single hard disk failures and almost all two (2) hard disk failures (per redundancy group). The VA 7xxx also can reserve up to the two largest hard drives worth of space (distributed across all hard drives in a redundancy group) for use as "active hot spares" to allow quick recovery of failed drive(s). Please note that utilizing RAID levels and hot spares will reduce the total amount of storage available. The specific settings for controlling the VA 7xxx RAID level, hot spares and other configuration parameters are accessible from the Command View NAS / Command View VA GUIs. Use of the NAS 8000 also means that Oracle server CPU cycles once needed to manage/maintain a complex storage environment can be utilized for better performance of the database engine while the NAS 8000 provides data protection, availability and reliability. storage management and definition guide defining NAS 8000 storage for Oracle databases The reader is directed to the HP NAS 8000 User's Guide for specific instructions/details on each of the steps listed below, and to the glossary for term definitions. Before defining the storage, it is imperative to plan out the storage use model, including such things as snapshot space for backups, use of redundancy groups for increasing fault tolerance, active/"hot" spares if needed, RAID settings, etc. Failure to plan may lead to the need for redefining/changing storage definitions later on. If the NAS 8000 is in a direct-attach configuration, the first step in defining storage is the definition of LUNs. If the NAS 8000 is in a SANattach configuration, the SAN Management station defines LUNs, so the first step would be to define volume groups. LUNs combine the physical storage from a redundancy group in the VA 7xxx array into a pool of logical storage. Each redundancy group is assigned a different controller as its "primary" controller. The other controller provides a redundant data pathway. The general guidelines for defining LUNs are to make as few LUNs as possible and make the LUNs as large as possible. There is currently a 1 Terabyte limit on LUN size. A NAS 8000 equipped with the VA 7100 array will have only one redundancy group. In this case, unless the NAS 8000 is to be upgraded to a cluster system, or unless there are administrative reasons to do so, no benefit will be realized by creating multiple LUNs. LUNs cannot span redundancy groups, so for a NAS 8000 with a VA 7400, a minimum of two LUNs must be created. The storage pools of both LUNs can be combined into one volume group without a performance penalty. The optimized operating system of the NAS 8000 will always use the most efficient data pathway when accessing the VA 7xxx array - even when all of the storage is combined in a single volume group. There is a slight fault tolerance benefit to implementing the storage of a NAS 8000 with a VA 7400 such that storage is defined along redundancy group boundaries. By not allowing any volume group to include LUNs from both redundancy groups, the number of hard drive failures that can occur before the entire VA 7400 array goes down is essentially doubled. The use of "hot spares" and AutoRAIDtm is functionally independent to each redundancy group. This means that if three drives in one redundancy group were to crash (causing the entire redundancy group to be unavailable), the other redundancy group would still be active with its data available. If any volume group contains LUNs from both redundancy groups, then if one redundancy group goes down, of necessity, the entire array is down. For more information about fault tolerance and other VA 7xxx topics, please refer to the HP Virtual Array User and Service Guide (located off of either the VA 7100 or VA 7400 home page). The next step in defining storage (or first step if in SAN-attach configuration) is to create the volume group(s). A volume group is comprised of one or more LUNs. A LUN is always fully contained inside a 5

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19

database.
Until recently, conventional wisdom had the database administrator placing different
tablespaces/data files on different disk controllers/RAID arrays in an attempt to improve performance
through the concurrency allowed by multiple disk interfaces.
Multiple hard drives/controllers allowed
multiple data pathways for ‘simultaneous’ access to data, as well as allowing multiple copies of critical files
to be stored on separate hard drives to protect against some media failures. Although this software
mirroring of critical data files offers some protection in the case of a media failure, it also uses precious
CPU cycles and I/O bandwidth from the Oracle server to accomplish the mirroring.
As well, the use of
multiple disk controllers/RAID arrays creates administration overhead and can make the environment very
complex and requires server CPU cycles to manage and maintain.
The NAS 8000 and its storage
subsystem provide a high level of concurrency for fast and efficient data access, and utilize RAID 0/1 or HP
AutoRAID
tm
technology to protect the data on the storage subsystem’s hard drives.
AutoRAID
tm
combines
RAID levels 0/1 and 5DP, controlled and configured in “real time” by the VA 7xxx firmware, to provide
total protection/recoverability in the event of single hard disk failures and almost all two (2) hard disk
failures (per redundancy group). The VA 7xxx also can reserve up to the two largest hard drives worth of
space (distributed across all hard drives in a redundancy group) for use as “active hot spares” to allow
quick recovery of failed drive(s). Please note that utilizing RAID levels and hot spares will reduce the total
amount of storage available.
The specific settings for controlling the VA 7xxx RAID level, hot spares and
other configuration parameters are accessible from the Command View NAS / Command View VA GUIs.
Use of the NAS 8000 also means that Oracle server CPU cycles once needed to manage/maintain a
complex storage environment can be utilized for better performance of the database engine while the NAS
8000 provides data protection, availability and reliability.
storage management and definition guide
defining NAS 8000 storage for Oracle databases
The reader is directed to the HP NAS 8000 User’s Guide for specific instructions/details on each of the
steps listed below, and to the glossary for term definitions.
Before defining the storage, it is imperative to
plan out the storage use model, including such things as snapshot space for backups, use of redundancy
groups for increasing fault tolerance, active/”hot” spares if needed, RAID settings, etc.
Failure to plan may
lead to the need for redefining/changing storage definitions later on
.
If the NAS 8000 is in a direct-attach
configuration, the first step in defining storage is the definition of LUNs.
If the NAS 8000 is in a SAN-
attach configuration, the SAN Management station defines LUNs, so the first step would be to define
volume groups.
LUNs combine the physical storage from a redundancy group in the VA 7xxx array into a
pool of logical storage.
Each redundancy group is assigned a different controller as its “primary”
controller.
The other controller provides a redundant data pathway.
The general guidelines for defining
LUNs are to make as few LUNs as possible and make the LUNs as large as possible.
There is currently a 1
Terabyte limit on LUN size.
A NAS 8000 equipped with the VA 7100 array will have only one
redundancy group.
In this case, unless the NAS 8000 is to be upgraded to a cluster system, or unless there
are administrative reasons to do so, no benefit will be realized by creating multiple LUNs. LUNs cannot
span redundancy groups, so for a NAS 8000 with a VA 7400, a minimum of two LUNs must be created.
The storage pools of both LUNs can be combined into one volume group without a performance penalty.
The optimized operating system of the NAS 8000 will always use the most efficient data pathway when
accessing the VA 7xxx array – even when all of the storage is combined in a single volume group.
There is
a slight fault tolerance benefit to implementing the storage of a NAS 8000 with a VA 7400 such that
storage is defined along redundancy group boundaries.
By not allowing any volume group to include
LUNs from both redundancy groups, the number of hard drive failures that can occur before the entire VA
7400 array goes down is essentially doubled.
The use of “hot spares” and AutoRAID
tm
is functionally
independent to each redundancy group.
This means that if three drives in one redundancy group were to
crash (causing the entire redundancy group to be unavailable), the other redundancy group would still be
active with its data available.
If any volume group contains LUNs from both redundancy groups, then if
one redundancy group goes down, of necessity, the entire array is down.
For more information about fault
tolerance and other VA 7xxx topics, please refer to the HP Virtual Array User and Service Guide (located
off of either the VA 7100 or VA 7400 home page).
The next step in defining storage (or first step if in SAN-attach configuration) is to create the volume
group(s).
A volume group is comprised of one or more LUNs.
A LUN is always fully contained inside a
5