The Basics of SAN Implementation, Part I Page 2


Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

SAN Implementation Team Creation

One of the most common questions asked during a SAN implementation is: What kind of organizational structure do you need to support this SAN? This section of the article briefly deals with potential organizational arrangements — structures relative to any SAN plan or pooled storage architecture. There are several dimensions that need to be considered, namely:

  • The SAN team organizational reporting structures.
  • Alignment of SAN architectural and organizational plans to the appropriate type of operating business model of the enterprise.
  • Bi-directional impact of the SAN topology and the resulting management team.

SAN Implementation Team Organizational Reporting Structure

The organizational alignment of a new storage team is one of the early concerns. Most medium-to-large enterprises are organized along platform lines, and thus (up until now) have had responsibility for storage and tape operations that relate to a specific operating system or server platform. The functions of servers and storage/tape can be separated with advanced storage architectures. And, these groups may go through a fundamental change in providing service, accountability, span, and control of enterprise storage resources.

Alignment of SAN Architectural Implementation and Organizational Plans

The basic roles of the storage team are to architect, design, plan, implement, administer, control, and generally provide 'care and feeding' for the elements of the SAN and pooled storage systems. In cooperation with other teams and functions within the IT department, the exact span and control of the environment will have to be sorted by each individual team. A checklist of items within the SAN and pooled storage framework that need to be owned is shown next. Ideally, all elements would come under administrative control of the SAN team:

  1. Backup, recovery, and disaster recovery (DR) schemes, schedules, and test plans.
  2. Backup servers, backup managers, APIs resident on slave servers.
  3. Enterprise storage arrays, Gigabit Interface Controller (GBIC), software.
  4. Enterprise tape drives, libraries, Active Template Library (ATL), etc.; Vtape, optical libraries.
  5. External, SAN management software (Logical Unit Number (LUN) mapping, management) for both in-band and out-of-band implementations.
  6. FC extenders, dense wavelength division multiplexing (DWDM), and other native FC multiplexing or amplification devices used for long-distance extension.
  7. FC hubs, FC switches, FC directors
  8. Fibre Channel-asynchronous transfer mode (FC-ATM) or other gateway devices that use the wide area network (WAN) to tunnel FC or otherwise extend FC through WAN access.
  9. Fibre Channel (FC) cables, plant management, patch panels.
  10. Fibre Channel/Internet Protocol (FC/IP) or Internet Small Computer Systems Interface (iSCSI) gateway device.
  11. Fibre Channel-Small Computer Systems Interface (FC-SCSI) bridges.
  12. HBA utilities and software.
  13. Host or storage data replication, snapshot, redundant arrays of independent disks (RAID), or data mover software.
  14. Host volume management software.
  15. Just A Bunch Of Disks (JBOD) connected to pooled fabric architecture.
  16. NAS appliance, NAS filer, or other general-purpose server used for Common Internet File System (CIFS) or Network File System (NFS) file serving.
  17. SAN management software imbedded within switches or directors.
  18. Server Host Bust Adapters (HBAs).
  19. Storage virtualization software.
  20. Switch and director OS, software.

Page 3: Bi-Directional Impact Of The SAN Implementation Topology

Submit a Comment


People are discussing this article with 0 comment(s)