Feature Recommendations

Based on Molina’s requirements and Cisco’s best practices the following features have been recommended for deployment at the production site where MDS directors and switches are planned for deployment.

Table 4 Feature Recommendations

Feature

Recommendations

Scope of Use

VSANs Provide logical isolation between open systems disk and Backup tape access.

Enhanced Device-alias Provides ability to use of human readable names to be associated with the PWWN of the end devices and the ability to manipulate then easily if the PWWN changes due to device replacement.

Enhanced Zoning To ensure zones and zonesets are safely deployed with minimal chance for human risk.

Port Bandwidth

Reservation To leverage the port density of the deployed hardware without sacrificing performance.

RBAC Role based Access control allows Molina to control the access and management of various physical and logical entities in the SAN infrastructure being deployed.

CFS Cisco Fabric Servers is used to replicate information between connected switches. Some of the applications supported by CFS are device-alias, ntp, AAA, roles to name a few.

Callhome The ability of provide notification through email on the events and incidents happening on the switch in real time. Can be configured to send automatic notification of critical events to Cisco to generate a Case and automatically open a support call to resolve the incident.

Port Channels Provides larger aggregate bandwidth and enhances High Availability

FCIP Extend the SAN over IP. Connect Fabrics (Switches)

The design allows having multiple storage environments within the same fabric. The use of VSANs will be deployed to support these technologies. This logical isolation will enable environments to be isolated from each other. Changes to the development environment zoning will not affect the production environment.

As per Molina’s requirement for supporting shared storage, backup environment, and dedicated storage environment within a single fabric; VSANs will be deployed to support these environments. This logical isolation; for example, will enable environments that do not require daily zoning such as tape, to be isolated from those that require daily zoning activities, such as the shared disk and dedicated storage environments.

• Limit the granularity of VSANs. Typically a production, backup, dev-test.

 Production for all business critical devices. Highest change management requirements. Do not create separate Production VSANs for different applications. This will unnecessarily complicate the design and maintenance of the SAN

 Backup VSAN. Typically, backup devices require high maintenance. Media server reloads, tape drive replacements. High activity of backup devices is normally opposite the production high activity windows. Maintenance can be done during the day time. Change management windows are normally not as stringent as Production environments. Having a dedicated backup VSAN allows for making changes without affecting business critical functions.

 Dev/Test VSAN. A physically dedicated test environment would be the ideal.

There is the ability to test different versions of switch software, and features without any impact to the by the Production environment.

However, this is quite costly to have separate equipment. Using some ports in a separate dev/test VSAN is the next best thing. Host HBAs and drivers can be tested in a SAN environment. The only requirement is the availability of dedicated array ports for the dev/test environment.

• Making VSANs more granular by dedicating a Windows VSAN, AIX VSAN, SAP VSAN, HR VSAN, Domino VSAN does reduce the potential for inadvertent operator error from causing wide spread damage. However, it does require a large number of available array ports. As each VSAN requires a minimum of two dedicated array ports to satisfy the A and B fabrics.

In general, we do not recommend this approach. Some VSANs may grossly underutilize an array port’s bandwidth, while other VSANs may experience bottle necks due to the inability to assign additional array ports to that VSAN. Common industry practice is what we have proposed.Having a smaller number of large VSANs does require some housekeeping to ease management.

For each Fabric the numbering scheme consists of using an offset of 500 between the A and B fabric. The VSAN ranges for the two Data Centers are show in

6.

Table 5 VSAN Ranges for Various Data Centers

Data Centers Fabric A VSAN range Fabric B VSAN

range

NM 100-200 (sample)???? 500-600

HW 400-500 700-800

• For each Fabric the numbering scheme will consist of using an offset of 1 between the A and B fabric. Fabric A will start at VSAN 101 while Fabric B will start at VSAN 102. VSAN 1 will not be used on either fabric for any fibre channel fabric.

• VSANs in the different Data Centres are not assumed to share resources. Except in the case of the replication VSAN. Only the replication VSAN shares a common VSAN number.

• By providing the non-replication VSANs unique VSAN numbers, there is no possibility of an unintentional VSAN merge.

• The Domain ID numbering scheme will be the domainIDs will make use of odd/even scheme to further differentiate which fabric (A or B) it is on.

• The Domain ID numbering scheme specified in the Low Level Design document.

• The number of VSAN will be determining in the Low Level Design document as well. It will consists are least two, production host/disk SAN and tape backup

• SAN.All VSANs will have the following features enabled:

○ Static port based VSANs.

○ Load balancing scheme: src/dst/oxid

○ Static Domain IDs

○ VSANs defined on all the directors and switches.

○ VSAN-1 utilized only for administrative use and for non-host to storage access.

○ FCID Persistency configured for all VSAN.

6.1.2 Devices Aliases

Aliasing of pWWN information is recommended for human readability. The actual device connectivity is always controlled by the underlying pWWN information. Device aliases databases are maintained on the switches and synced up to all switches via CFS. FM Server allows for a GUI interface to update/change device alias information on the switches. FMS does not maintain device alias information.

Enhanced Device aliases will be deployed instead of focalises as they are independent of the zoning database and can provide name resolution to applications beyond the zoneserver. The enhanced device alias also provides for easy fix if an end device is replaced. It automatically updates all the application with the new PWWN when the new PWWN is updated in enhanced device aliases.

6.1.3 Zoning and Zonesets

The proposed SAN design includes the following Zoning characteristics based on Molina’s requirements and Cisco’s best practices.

Enhanced Zoning is to be deployed for the VSANs which requires a minimal learning curve to the Molina’s SAN team. It provides automatic full zoneset distribution and synchronization as well as preventing multiple administrators from modifying a VSAN’s zoneset at the same time.

Each zone is to be configured as a “single initiator” zone. This method specifies that one initiator and all of its associated targets to be in a single zone.

Zonesets:

ZS_PROD_A_100

ZS_REPLICATION_A_200 ZS_PROD_B_101

ZS_REPLICATION_B_201 Zones:

Z_SERVERNAME-HBA0X_ARRAY-PORT Device-alias

SERVERNAME-HBA0X ARRAY-PORT

6.1.4 Security

This High Level SAN design describes the necessary security features based on Molina’s requirements and Cisco’s best practices.

The Following Security features are listed by “Security Type” of access such as Management, Fabric or Data. The features selected might include multiple items from each Security Type or just from one or two Security Types are based again on Molina’s requirements and Cisco’s best practices.

Management Access (Security Type)

• Password protected Console

• Secure Shell (SSH)

• Secure File Transfer Protocol (SFTP)

• Role Based Access Control (RBAC)

 Each user to have their own unique username and password with roles providing them the minimal privileges or rules required to perform their job.

• SNMPv3 (FMServer)/SNMPv1 (for SRM support)

• TACACS+ to be used for authentication to the MDS infrastructure.

Data Access (Security Type)

• VSANs

• Enhanced Zoning

• Only fiber channel attached devices (HBAs, Storage, Tape, analyzers) can access the fiber channel network.

• In order for end devices to communicate, administratively controlled access must be granted.

• End device access security is controlled by allowing specific parameters of those devices (Port World Wide Numbers (pWWN), or specific ports).

• End devices must be in the correct VSAN, zone and zoneset. All require administrator authorization.

• The MDS has a port security feature to defeat port spoofing that can be enabled to prevent a duplicate pWWN to logon to the fabric. In general this is not deployed as Data Center physical access is tightly controlled.

• Current tape backup environment has encryption built-in on the tape devices.

As noted: Cisco also has the capability to encrypt tape. This is a licensed feature. It can make use of the 18/4 line cards currently deployed in the Molina network. Actual quantities of 18/4’s would require an analysis of the backup environment.

• IPsec can be enabled on FCIP links to provide data encryption over a wide area network. This is normally deployed when running over public networks.

6.1.5 Role Based Access Control (RBAC)

The proposed SAN design includes Role Based Access Control based on Molina’s requirements and Cisco’s best practices.

The following Roles are recommended for the Molina’s SAN deployment in the four data centers.

Table 6 Role Based Access Control

RBAC Description RBAC Scope of Responsibility

Network-admin For those members of the SAN team

that require complete write access to the MDS.

Network-Operator For those personnel that do not require write access to the MDS.

Operations For those personnel that perform day

to day operations such as port enabling and zoning.

6.1.6 Logging

This High Level SAN design describes the external logging to be implemented based on Molina’s requirements and Cisco’s best practices.

Logging to be done to the FM Server’s syslog service or to a standalone syslog server.

6.1.7 Monitoring

Monitoring of the fabric to be configured using Cisco Fabric Manager Server.

Additional flows need to be configured to monitor the ISLs and critical servers to enable Molina to be able to do performance trending and capacity planning. Custom reports can be configured using the FMS web interface to monitor the fabric health as well as inventory.

Fabric Manager will allow you to manage multiple fabric (FMS license required). Tabs within FM will allow you to quickly toggle between physical fabrics. If the switches do not have a FMS license, only one physical fabric may be opened at one time.

6.1.8 Call Home

The proposed SAN design includes the Call Home feature based on Molina’s requirements and Cisco’s best practices.

The MDS infrastructure will be configured to “call home” or send email notification to Cisco TAC a predefined email alias to include members of the Molina’s staff.

Call home is a mechanism to alter the storage administrators about potential issues on the switches as and when they occur. This needs to be properly configured so that the switch is able to send out the required logs and incident report to both Cisco and EMC to help open a trouble ticket and help resolve the problem quickly. Callhome is also used to send information on an occurred problem to the local storage/SAN administrators through email. To configure callhome a valid SMTP server is require.

Also it is helpful to provide contact information /support contract details in the configuration so that based on the severity of the issue EMC /Cisco can contact the appropriate personal to remediation. The Call home details required need to be filled out in the low level data spread sheet. The data provided will be used to configure the switch.

6.1.9 Port-Channel

When there are multiple ISL between any two MDS switches it is recommended that they are configured as a port-channel. This is the recommended practice. It is also recommended that while configuring the port-channel to turn on port-channel protocol. The load balancing algorithm on the port-channel is preferable to be set to exchange id based load balancing.

6.1.10 N Port Identifier Virtualization

N port identifier virtualization (NPIV) provides a means to assign multiple FC IDs to a single N port. This feature allows multiple applications on the N port to use different identifiers and allows access control, zoning, and port security to be implemented at the application level.

Enabling NPIV on the MDS switch is the only configuration requirement for the switch.

This is a global setting and applies to all VSANs.NPV enabled end devices are required to connect to a NPIV enabled switch. NPIV is enabled for all core directors.

6.1.11 N Port Virtualizer

N port virtualization (NPV) reduces domain ID usage. On a large scale deployment with 40 edge switches, the number of domain IDs will be more then 40. NPV

addressed this challenge by treating each fiber channel edge switch as an HBA, so it does not use the domain ID. In this design with NPV, a single fabric uses only two domain IDs.

6.1.12 Licences

The proposed High Level Design includes various features which will require the following Product License to be installed:

Table 7 Feature License

Switch Feature Product License Required

Core Switches FM Server, Enterprise, FCIP,

SANTap FM_SERVER_PKG,

Enterprise_PKG, SAN_EXTN_OVER_IP, STORAGE_SERVICES_184