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
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.
46DS6000 Series: Concepts and Architecture
