There has long been a desire to support Apple servers and work stations with IBM DS series
storage, and now we have that capability. But due to confusion in the past, we will be
approving a very specific set of known, quality configurations. There are two basic aspects of
these solutions: One is basic hardware connectivity, the second is the support for file sharing.
It‟s important not to confuse the two. Basic hardware connectivity to Apple is supported via
RPQ. File sharing is also supported, but because of the added complexity requires very
specific configuration and a more restrictive RPQ process.
File Sharing Environments
Apple installations typically use a shared file system called Xsan. Xsan is in reality a lite
version of Quantum‟s StorNext File System. StorNext is very popular in the media market
because it allows shared block-level file system access while offering integrated archive
management. However, Apple offers very limited support outside very specific configurations.
A 100% apple configuration must be used.
There are three components to the StorNext solution: Clients, Meta Data Controller (MDCs),
and the storage. There are also ancillary components such as the SAN, the TCP/IP network,
and archive storage such as tape libraries. However, for selling and support purposes the
components are software, support, and implementations services.
The announced support for the IBM Digital Media Storage Solution is the result of efforts
between ATTO (HBA‟s), Quantum (StorNext), LSI (Storage Subsystems), and IBM. We have
identified a set of hardware, firmware, and configuration parameters that will be supported. The
set of configurations will be expanded in a logical manner over the next few months as
additional choices are available and tested.
Apple Xsan Clients, Linux StorNext Clients, Windows Clients (June) and Linux MDC
COMPONENT DESCRIPTIONS
Apple Clients
• Apple connection without StorNext/Xsan support, or
• May use Apple Xsan Client software
o If you use the Xsan clients and Xsan Meta Data Controller (MDC), then your
support comes from Apple. However, if you use the StorNext MDC from
Quantum, then Quantum will support the entire solution including the Xsan
clients loaded on the Mac‟s. As you can see, this is a much more flexible
solution.
There are very specific capabilities that are being added and they are tied to specific hardware,
software, and driver availability. Support will be added in this order:
Apple Homogenous
Apple Xsan Clients with Linux MDC (Meta Data Controller)
(Apple can also be connected without Xsan/StorNext support)
1. Single Host Client connected to DS3000/DS4000/DS5000 Storage (NOW)
a. Apple Leopard and Snow Leopard
i. Using ATTO HBA‟s and multipathing driver
b. Without StorNext or Xsan support
c. This is basic host connectivity support.
2. Multiple Apple Host Client connected to DS3000/DS4000/DS5000 Storage (NOW)
a. Apple Leopard and Snow Leopard using Xsan Client software
i. Using ATTO HBA‟s and multipathing driver
b. With StorNext MDC‟s running on RHEL/SLES
i. Using previously supported QLogic and/or Emulex HBA‟s
All ports see Controller A and Controller B on
DSxxxx
MDC - Limit number of defined paths to optimize initialization time. There are few MDC‟s in
comparison to clients, so this choice should not be as restrictive as below. This is not a hard
requirement, but is recommended.
Most configurations consist of two MDC‟s for high availability. Both MDC‟s must have the
same configuration; OS, HBA‟s, Driver Levels, etc
Client
Single (typical)
or multiple
Up to two
All ports see Controller A and Controller B on
DSxxxx
Client – Limit number of defined paths to four to optimize initialization time. This is not a hard
requirement, but is recommended.
Storage
Controller A
Up to 8
All ports see all MDC and client ports
Controller B
Up to 8
All ports see all MDC and client ports
There are several important aspects to the configuring of the SAN that must be understood.
The first is that the SAN design is architected to avoid logical drive failover in the storage
subsystem. This is accomplished by employing a meshed fabric where each HBA on the
server can see both controllers on the storage subsystem. The second aspect has to deal with
access to the shared logical drives. There are three types of shared logical drives; Metadata,
Journal, and Data. All systems (MDC‟s and Clients) must be able to see the Data LUNs. The
MDC‟s must also be able to both see the Metadata and Journal LUNs. It is important that the
clients do not have access to the Metadata or Journal LUNs.
When configuring the storage partitioning within the storage subsystem, the methodology is as
follows:
All HBA‟s in the MDC‟s will be defined within a single host definition (called MDCs?). This
host definition will have the Metadata and Journal LUNs directly mapped to this host
definition.
All Clients have their own host definitions. If desired, all clients that have the same OS can
have their HBA‟s combined within a single host definition.
All Clients and the MDC‟s will be assigned to a single host group (called StorNext?). All of
the Data LUNs will be assigned to that host group.