IBM System storage DS6000 Series, Redbooks

Page: 70 / 406

46
DS6000 Series: Concepts and Architecture
3.1 Controller RAS
The DS6800 design is built upon IBM’s highly redundant storage architecture. It has the
benefit of more than five years of ESS 2105 development. The DS6800, therefore, employs
similar methodology to the ESS to provide data integrity when performing fast write
operations and controller failover.
3.1.1 Failover and failback
To understand the process of controller failover and failback, we have to understand the
logical construction of the DS6800. To better understand the contents of this section you may
want to refer to Chapter 10, “DS CLI” on page 195. In short, to create logical volumes on the
DS6000, we start with DDMs that are installed into pre-defined array sites. These array sites
are used to form RAID-5 or RAID-10 arrays. These RAID arrays then become members of a
rank. Each rank then becomes a member of an extent pool. Each extent pool has an affinity to
either controller 0 or controller 1.
Within each extent pool we create logical volumes (which for open systems are called LUNs
and for zSeries, 3390s). These logical volumes belong to a logical subsystem (LSS). For
open systems the LSS membership is not that important (unless you are using Copy
Services), but for zSeries, the LSS is the logical control unit (LCU) which equates to a 3990 (a
z/Series disk control unit which the DS6800 emulates). What is important, is that LSSs that
have an even identifying number have an affinity with controller 0, while LSSs that have an
odd identifying number have an affinity with controller 1.
When a host operating system issues a write to a logical volume, it is preferable that it is
issued to the controller that
owns
the LSS of which that logical volume is a member.
Understanding this controller affinity is important for achieving the best performance and it is
also very important when we look at host pathing. More details are in 3.2, “Host connection
availability” on page 49.
Data flow
When a write is issued to a volume, the write normally gets issued to the controller that owns
this volume. The data flow is that the write is placed into the cache memory of the preferred
controller. The write data is also placed into the NVS memory of the alternate controller.