166 lines
12 KiB
HTML
166 lines
12 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Prepare for disk failures" />
|
||
|
|
<meta name="abstract" content="Because your data is spread across your disks, it is important that you consider how to protect your data in the event that one of those disks fails. Disk protection provides a means to ensure availability of data stored on disks." />
|
||
|
|
<meta name="description" content="Because your data is spread across your disks, it is important that you consider how to protect your data in the event that one of those disks fails. Disk protection provides a means to ensure availability of data stored on disks." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzalwprevent_unplanned.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzalwdasd" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Prepare for disk failures</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzalwdasd"><a name="rzalwdasd"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Prepare for disk failures</h1>
|
||
|
|
<div><p>Because your data is spread across your disks, it is important
|
||
|
|
that you consider how to protect your data in the event that one of those
|
||
|
|
disks fails. Disk protection provides a means to ensure availability of data
|
||
|
|
stored on disks.</p>
|
||
|
|
<p>Disk storage is the storage that is either internal to your iSeries™ server
|
||
|
|
or is attached to it. This disk space, together with your server's main memory,
|
||
|
|
is regarded by your system as one large storage area. When you save a file,
|
||
|
|
you do not assign it to a storage location; instead, the system places the
|
||
|
|
file in the location that ensures the best performance. It may spread the
|
||
|
|
data in the file across multiple disk units, if that is the best option. When
|
||
|
|
you add more records to the file, the system assigns additional space on one
|
||
|
|
or more disk units. This way of addressing storage is known as <dfn class="term">single-level
|
||
|
|
storage</dfn>.</p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />In addition to internal disk storage, you can also use IBM<sup>®</sup> TotalStorage<sup>®</sup> Enterprise
|
||
|
|
Storage Server<sup>®</sup> (ESS) to attach a large volume of external disk units.
|
||
|
|
ESS provides enhanced disk protection, the ability to copy data quickly and
|
||
|
|
efficiently to other ESS servers, and the capability of assigning multiple
|
||
|
|
paths to the same data to eliminate connection failures. For additional information
|
||
|
|
on IBM TotalStorage Enterprise Storage Server (ESS) and its features and to
|
||
|
|
determine if this solution is right for you, see <a href="http://www-1.ibm.com/servers/storage/disk/enterprise/index.html" target="_blank">Enterprise disk storage</a>.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<div class="section"><img src="./delta.gif" alt="Start of change" /><h4 class="sectiontitle">Device parity protection</h4><p>Device parity
|
||
|
|
protection allows your system to continue to operate when a disk fails or
|
||
|
|
is damaged. When you use device parity protection, the disk input/output adapter
|
||
|
|
(IOA) calculates and saves a parity value for each bit of data. The IOA computes
|
||
|
|
the parity value from the data at the same location on each of the other disk
|
||
|
|
units in the device parity set. When a disk failure occurs, the data can be
|
||
|
|
reconstructed by using the parity value and the values of the bits in the
|
||
|
|
same locations on the other disks. Your system continues to run while the
|
||
|
|
data is being reconstructed. </p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />For an overview of device parity
|
||
|
|
protection, see <a href="../rzaly/rzalydpp.htm">Device parity
|
||
|
|
protection</a>.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p>i5/OS supports two types of device parity protection: </p>
|
||
|
|
<p><strong>RAID
|
||
|
|
5</strong></p>
|
||
|
|
<p>With RAID 5, the system can continue to operate if one disk fails
|
||
|
|
in a parity set. If more than one disk fails, data will be lost and you must
|
||
|
|
restore the data for the entire system (or only the affected disk pool) from
|
||
|
|
the backup media. Logically, the capacity of one disk unit is dedicated to
|
||
|
|
storing parity data in a parity set consisting of 3 to 18 disk units</p>
|
||
|
|
<p><strong>RAID
|
||
|
|
6</strong></p>
|
||
|
|
<p>With RAID 6, the system can continue to operate if one or two
|
||
|
|
disks fail in a parity set. If more than two disk units fail, you must restore
|
||
|
|
the data for the entire system (or only the affected disk pool) from the backup
|
||
|
|
media. Logically, the capacity of two disk units is dedicated to storing parity
|
||
|
|
data in a parity set consisting of 4 to 18 disk units. </p>
|
||
|
|
<p>See <a href="../rzaly/rzalyelmdasdpp.htm">Elements of device parity
|
||
|
|
protection</a> for detailed comparison of RAID 5 and RAID 6.</p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" /><strong>Write
|
||
|
|
cache and auxiliary write cache IOA</strong><img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />When
|
||
|
|
the system sends a write operation, the data is first written to the write
|
||
|
|
cache on the disk IOA and then later written to the disk. If the IOA experiences
|
||
|
|
a failure, the data in the cache may be lost and cause an extended outage
|
||
|
|
to recover the system.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />The auxiliary write cache is an additional
|
||
|
|
IOA that has a one-to-one relationship with a disk IOA. The auxiliary write
|
||
|
|
cache protects against extended outages due to the failure of a disk IOA or
|
||
|
|
its cache by providing a copy of the write cache which can be recovered following
|
||
|
|
the repair of the disk IOA. This avoids a potential system reload and gets
|
||
|
|
the system back on line as soon as the disk IOA is replaced and the recovery
|
||
|
|
procedure completes. However, the auxiliary write cache is not a failover
|
||
|
|
device and cannot keep the system operational if the disk IOA, or its cache,
|
||
|
|
fails.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p>See <a href="../rzaly/rzalyauxiliary.htm">Write
|
||
|
|
cache and auxiliary write cache IOA</a> in Disk management for detailed
|
||
|
|
information on write cache and auxiliary write cache IOA.</p>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Mirrored protection</h4><p>Disk mirroring is recommended
|
||
|
|
to provide the best system availability and the maximum protection against
|
||
|
|
against disk-related component failures. Data is protected because the system
|
||
|
|
keeps two copies of the data on two separate disk units. When a disk-related
|
||
|
|
component fails, the system may continue to operate without interruption by
|
||
|
|
using the mirrored copy of the data until the failed component is repaired.</p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />Different levels of mirrored protection are possible, depending
|
||
|
|
on what hardware is duplicated. The level of mirrored protection determines
|
||
|
|
whether the system keeps running when different levels of hardware fail. To
|
||
|
|
understand these different levels of protection, see <a href="../rzaly/rzalymirror3.htm">Determine
|
||
|
|
the level of protection</a>.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<p><img src="./delta.gif" alt="Start of change" />You can duplicate the following
|
||
|
|
disk-related hardware:<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<ul><li>Disk unit</li>
|
||
|
|
<li>Disk controllers </li>
|
||
|
|
<li>I/O bus unit</li>
|
||
|
|
<li>I/O adapter</li>
|
||
|
|
<li>I/O processors</li>
|
||
|
|
<li>A bus</li>
|
||
|
|
<li><img src="./delta.gif" alt="Start of change" />Expansion towers<img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
<li><img src="./delta.gif" alt="Start of change" />HSL ring<img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
</ul>
|
||
|
|
<p>For details on mirrored protection, including how it works and how
|
||
|
|
to plan for it, see <a href="../rzaly/rzalymirror.htm">Mirrored
|
||
|
|
protection</a>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Independent disk pools</h4><p><img src="./delta.gif" alt="Start of change" />Independent disk
|
||
|
|
pools (also called independent auxiliary storage pools) enable you to prevent
|
||
|
|
certain unplanned outages because the data on them is isolated from the rest
|
||
|
|
of your server. If an independent disk pool fails, your system can continue
|
||
|
|
to operate on data in other disk pools. Combined with different levels of
|
||
|
|
disk protection, independent disk pools provide more control in isolating
|
||
|
|
the effect of a disk-related failure as well as better prevention and recovery
|
||
|
|
techniques. For detailed information on how to use independent disk pools,
|
||
|
|
see <a href="../rzaly/rzalyoverview.htm">Independent
|
||
|
|
disk pools</a>.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Geographic mirroring</h4><p>Geographic mirroring is a function
|
||
|
|
that keeps two identical copies of an independent disk pool at two sites to
|
||
|
|
provide high availability and disaster recovery. The copy owned by the primary
|
||
|
|
node is the production copy and the copy owned by a backup node at the other
|
||
|
|
site is the mirror copy. User operations and applications access the independent
|
||
|
|
disk pool on the primary node, the node that owns the production copy. Geographic
|
||
|
|
mirroring is a sub-function of cross-site mirroring (XSM), which is part of
|
||
|
|
i5/OS Option 41, High Available Switchable Resources. </p>
|
||
|
|
<p>For details on
|
||
|
|
geographic mirroring, including how it works and how to plan for it, see <a href="../rzaly/rzalygeographicmirror.htm">Geographic mirroring</a>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><img src="./delta.gif" alt="Start of change" /><h4 class="sectiontitle">Multipath disk units</h4><p>You can define up
|
||
|
|
to eight connections from each LUN (Logical Unit) created on the IBM TotalStorage
|
||
|
|
Enterprise Storage Server (ESS) to the IOPs on an iSeries server. If you are
|
||
|
|
using an ESS solution, assigning multiple paths to the same data allows the
|
||
|
|
data to be accessed even though some failures may occur in other connections
|
||
|
|
to the data. Each connection for a multipath disk unit functions independently.
|
||
|
|
Several connections provide availability by allowing disk storage to be used
|
||
|
|
even if a single path fails. </p>
|
||
|
|
<p>For details on multipath disk units, including
|
||
|
|
its requirements, see <a href="../rzaly/rzalymultipath.htm">Considerations for multipath disk units</a>.</p>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalwprevent_unplanned.htm" title="One way to approach availability is to try to prevent unplanned outages. You can use these different methods to ensure that your system experiences as little unplanned downtime as possible.">Prevent unplanned outages</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|