This chapter provides an overview of the Nexsan iSeries.
iSCSI transmits native SCSI commands and data over the TCP/IP protocol stack. iSCSI transfers and stores SCSI commands and data at any iSCSI enabled storage location with access to a LAN, MAN, WAN or the Internet. iSCSI enables the creation of high performance IP-SANs.
iSCSI has many benefits including:
|
Can use existing Ethernet cabling and existing network elements. |
|
Uses common TCP/IP for global connectivity. |
|
Leverages the existing expertise of network administrators, integrators and support services. |
iSCSI Initiator and Targets
iSCSI initiators establish TCP connections with iSCSI targets. Data can be transferred via iSCSI when an iSCSI initiator establishes a TCP connection with an iSCSI target.
|
The iSCSI initiator resides in the host computer. |
|
The iSCSI target resides in the Nexsan iSeries. |
|
iSCSI initiators and targets have a World Wide Unique Identifier (WWUI) of up to 223 free form characters, e.g. www.brocade.switch1.target1. |
To enable iSCSI communications over TCP, the system administrator must configure portals during the initial Nexsan iSeries configuration. A portal is comprised of both an IP address and its assigned TCP port. Each configured portal automatically becomes an iSCSI access point to each target that exists in the Nexsan iSeries. Typically, there are few portals and many targets.
An iSCSI initiator can access, read and write to a disk only after the disk is “exposed”. An exposed disk is a disk that has been attached to a target and assigned a LUN (
Logical Unit Number). An exposed disk can be accessed by any iSCSI initiator unless
ACL restrictions are configured.
When creating iSCSI targets, the user administrator assigns an alias and name for each one. The alias is an internal identifier for the system administrator. The name is the WWUI used to connect initiators to the target.
When creating targets, keep in mind that:
• |
Each target can have multiple LUNs. |
• |
Each target should be exposed by only one Nexsan iSeries in a cluster. |
• |
Each target can be accessed by multiple hosts. |
|
There are two ways to expose a disk:
In Figure 1-1 Vol 1 is exposed via Target 1 and is accessible to any iSCSI initiator via either portal (IP1, 3260) or (IP2, 3260). Likewise, Vol 2 is exposed via Target 2, Vol 3 and Vol 4 are exposed via Target 3. Figure 1-1. iSCSI Target Access |
The Nexsan iSeries supports three types of discovery: iSCSI Discovery, SLP and iSNS.
In an iSCSI discovery session the user administrator configures an IP and port of the iSCSI target in the initiator. The initiator discovers all applicable targets and LUNs.
SLP (Service Location Protocol) is a common broadcast-based discovery mechanism that uses agents. The Nexsan iSeries acts as an SLP Service Agent (SA) and advertises its iSCSI service. The initiator identifies the Nexsan iSeries and discovers the Nexsan iSeries targets.
iSNS is a client/server protocol designed for compatibility with FC’s Simple Name Server (SNS). Once an iSNS server is located (either through DHCP or SLP), discovery can take place without the need for broadcasts. iSNS enables iSCSI initiators in the IP-SAN to locate the Nexsan iSeries targets automatically.
No matter what discovery method is used, ACL (Access Control List) allows only those targets that are defined as available to be accessed. To allow selective iSCSI initiator access to iSCSI target disks, the Nexsan iSeries uses
identities to define pools of initiators. An identity is a user-defined list of iSCSI initiators. Attaching an identity to a target restricts its access to the list of initiators defined by that identity.
When planning and creating identities, keep in mind that:
|
Each identity can contain one or more iSCSI initiators. |
|
Each identity can be assigned one or both login authentication methods (CHAP, SRP). |
|
Each identity can be attached to more than one target. |
|
Each target is first automatically coupled to a default read-write un-authenticated access identity and therefore can be accessed by everyone. |
|
Each target can have more than one identity. The order of the identities is important. The first match is used, not the best match. |
|
If you are working with an iSNS server, all hosts are able to see all targets but only those hosts with access rights are able to connect to the authorized targets. |
In Figure 1-2 identities are coupled with iSCSI targets to limit iSCSI initiator access to a target’s underlying disks. An identity can be used with more than one target and each target can have more than one identity.
|
Identity A is coupled with both Targets 1 and 2. |
|
Identity B is coupled with Target 3. |
|
Identity C is coupled with Target 4. |
As a result, each iSCSI initiator has access to the following disks: Figure 1-2. Identities Coupled with Targets |
When you assign an identity to a target, you give the identity a
position. A position is an identity’s rank in the Nexsan iSeries scan for an “
iSCSI initiator – identity match”. When the Nexsan iSeries scans the list of identities coupled with a target, it starts with the highest position and stops with the first match. After matching, the initiator is granted the identity’s access rights.
An identity can be connected to more than one target to provide the same pre-defined list of initiators for each target.
In Figure 1-3, the default identities for Target 1 and Target 2 have been modified to not accessible (NA) for all initiators.
|
Target 1 is coupled with Identity A with read-write (RW) access to Identity A’s list of iSCSI initiators (WWUI1). |
|
Target 2 is coupled with Identity B with read-write (RW) access to Identity B’s list of iSCSI initiators (WWUI2). |
When iSCSI initiator WWUI1 logs in to Target 1, the Nexsan iSeries first scans Identity A and finds the initiator listed there. The scan stops and the initiator is granted read-write access to Target 1’s underlying disk, Disk 1. If iSCSI initiator WWUI1 tries to login to Target 2, the Nexsan iSeries first scans Identity B. It does not find the initiator listed so it continues to scan the next identity, the default identity. The default identity implicitly lists all iSCSI initiators, including WWUI1. However, the scan stops and the initiator is denied access to Target 2’s underlying disks (Vol 2 and Vol 3), since the default identity is configured as not accessible. Figure 1-3. Default Identities |
When you couple an identity and a target, you assign access rights: read-write (RW), read-only (RO) or not accessible (NA). The access rights are per identity-target pair.
|
An identity can be coupled with multiple targets, each time with different access rights. |
|
A target can have multiple identities, each with different access rights. |
If you add or modify Identities on a target after its disks have been exposed, the access rights will take effect only at the next login for each iSCSI initiator. |
In Figure 1-4 Identity A is coupled with both Target 1 and Target 2.
|
The pair Identity A – Target 1 is assigned iSCSI initiator read-write access to Target 1 disks. |
|
However, the pair Identity A – Target 2, is assigned iSCSI initiator read-only access to Target 2 disks. |
Figure 1-4. Access Rights per Identity-Target Pair |
Target and Initiator Authentication
The Nexsan iSeries supports the authentication methods CHAP and SRP for the iSCSI initiator. The credentials for CHAP and SRP are the combination of user name + password.
CHAP is a protocol that is used to authenticate the peer of a connection and is based upon the peers sharing a secret (a security key that is similar to a password). The target and the initiator authenticate each other.
The Nexsan iSeries supports two way CHAP authentication. The target authenticates the initiator and the initiator can authenticate the target (it is up to the initiator to request target authentication). A separate secret can be set for each target and for each initiator in the storage area network (SAN).
An authentication method is assigned per identity and not per iSCSI initiator.
• |
An identity can be assigned an additional authentication method. |
• |
If no authentication method is assigned, all listed iSCSI initiators in an identity will have un-authenticated login access rights. |
|
When an iSCSI initiator logs in to a target, its WWUI is checked against the identity initiator list. After the iSCSI initiator passes the identity stage, if credentials are configured, the iSCSI initiator must authenticate itself. The credentials list is checked for the iSCSI initiator’s user name + password. The list can contain:
|
A separate user name + password for each initiator. |
There is no strict link between an initiator from the initiator names in the identity and a specific username + password from the credentials of the identity. |
|
A few user name + password pairs common to a few initiators |
|
A single user name + password for all initiators in the identity. |
|
Six iSCSI initiators in Identity B |
|
Only four user name + password credentials. Certain initiators have the same user name + password configured on them. |
Figure 1-5. Identity with iSCSI Initiators and Credentials |
Configuring a RADIUS Server
When a RADIUS Server exists in the network, you can use it to manage the Nexsan iSeries. When CHAP user names and passwords are configured on the network in a RADIUS server, the RADIUS server can be configured on the Nexsan iSeries to direct a CHAP challenge to the RADIUS server and eliminate the need to configure all user name + password pairs on the Nexsan iSeries. This decreases configuration time and increase overall network security.
In Figure 1-6, a CHAP authentication challenge is sent to the Nexsan iSeries. The Nexsan iSeries first checks if the user name is set for RADIUS authentication.
|
If it is, the CHAP challenge is passed on to the RADIUS server. |
|
If it is not, the user name and password are compared against the pairs configured in the Nexsan iSeries. |
Figure 1-6. Sending a CHAP Authentication Challenge |
A cluster is made from two Nexsan iSeries that are attached to the same storage element(s). In a cluster, the Nexsan iSeries interact in a peer-to-peer fashion with the other
neighbor Nexsan iSeries. In this active-active configuration, neither Nexsan iSeries is configured to act as the master Nexsan iSeries. All disks are accessible to each Nexsan iSeries and can be exposed on either Nexsan iSeries. This allows you to split the load between the two Nexsan iSeries. Clusters provide high availability in the event of Nexsan iSeries failover.
Each network port on the Nexsan iSeries is configured with its own:
|
active , or functioning, IP addresses |
|
inactive, or dormant, neighbor IP addresses. |
When one Nexsan iSeries goes off-line, the remaining Nexsan iSeries activates its neighbor’s IP addresses. The hosts continue to access disk targets through the same IP address without sensing that their ‘regular’ Nexsan iSeries has gone offline or noticing any impact on storage performance.
All LUNs in a RAID controller must be simultaneously exposed through all ports connected to both Nexsan iSeries. |
In Figure 1-7, two Nexsan iSeries are connected to one FC JBOD. From the four physical disks, two virtual disks have been created, both equally accessible to both Nexsan iSeries. Nexsan iSeries are both fully operational in a cluster. No Nexsan iSeries must sit in stand-by mode. Both Nexsan iSeries are also connected to two hosts via the IP SAN. The disk exposure of the two virtual disks is balanced equally between the two Nexsan iSeries for best resource utilization. Vol 1 is exposed via Nexsan iSeries 1 to Host 1, represented by the orange dashed line. Vol 2 is exposed via Nexsan iSeries 2 to Host 2, represented by the purple dotted line. Figure 1-7. Nexsan iSeries Cluster Configuration |
In Figure 1-8, Nexsan iSeries 1 has gone off-line. Nexsan iSeries 2 activates Nexsan iSeries 1’s IP address and takes over exposure of Disk 1 to Host 1, represented by the orange dashed line. Host 1 continues to access Disk 1 through the same IP address as it did before its Nexsan iSeries went off-line. Host 1 has no way of knowing that its regular Nexsan iSeries is off-line. Figure 1-8. Re-Routing Storage Access with Off-line Nexsan iSeries |
Maintaining Cluster Communications
Once a Nexsan iSeries is configured as a cluster, it begins sending out a regular
keep alive signal to its neighbor. The Nexsan iSeries also begins listening for the keep alive signal from its neighbor. The keep alive signal is transmitted through all connecting paths between each neighbor. Thus, if one path fails, the remaining path(s) will still carry the keep alive signal.
If a specified time period passes without a keep alive signal from the neighbor, a
suspicious interval, measured in seconds, is entered. The Nexsan iSeries suspects that its neighbor has gone off-line and begins preparing to activate the neighbor IP addresses to take over disk exposure.
If a keep alive signal is received during the suspicious interval, the timer is reset and the Nexsan iSeries continues to function as usual. If a keep alive signal is not received by the end of the suspicious interval, a
faulty interval is entered. At the end of the faulty interval, the neighboring Nexsan iSeries is considered off-line, the failover process is initiated and the on-line Nexsan iSeries actives the neighbor IP addresses and takes over disk exposure.
If disks or targets are created on one Nexsan iSeries operating alone, when another Nexsan iSeries is added, its database must be synchronized to the first Nexsan iSeries database. This can happen in three situations:
1. |
A new Nexsan iSeries is added to a configured and functioning Nexsan iSeries to form a cluster. |
2. |
An offline Nexsan iSeries in a cluster comes back online. |
3. |
CLI is used to make an isolated configuration change in one Nexsan iSeries. |
When an element is not synchronized, a yellow exclamation mark appears to the left of it instead of a green check mark and the alarm
Object not redundant is displayed. Synchronization is possible at every level of Nexsan iSeries Manager: Cluster, Nexsan iSeries, Target and Disk.
Synchronization is carried out from the selected level down. Synchronization at the cluster level will synchronize the Nexsan iSeries and their disks. You cannot synchronize IP addresses or IP routes as well as CHAP/SRP passwords.
The Nexsan iSeries allows you to perform volume virtualization. The Nexsan iSeries “
sees” a collection of storage devices. Each device can be either a physical disk (part of a JBOD) or a LUN (part of RAID).
With the Nexsan iSeries, you can:
|
Take a resource and attach it via the iSCSI network to the host. |
|
Build virtual volumes at the network layer. |
Nexsan iSeries Manager enables you to configure physical volumes into the following types of virtual volumes:
|
Mirrored over Concatenated |
|
Mirrored over Striped (RAID 0 +1) |
|
Striped over Mirrored (RAID 10) |
There are several ways to create volumes:
1. |
Take a full disk and expose it as one volume. |
2. |
Create volumes by partitioning disk into subdisks. |
3. |
Create a volume by spanning multiple physical disks or subdisks (e.g. take two disks/subdisks and create mirror). |
The primary use for transparent volumes is for attaching tape devices directly to the Nexsan iSeries. You can take a physical disk/tape and convert it to a transparent volume ready for direct host exposure. For more information, see
Transparent Volumes in Chapter 4.
Transparent volumes cannot be used in further volume hierarchies. |
You can partition a disk to create a subdisk that can be accessed as a separate virtual volume. You can create one or more subdisks on a physical disk. The subdisks can be used for creating concatenated, striped and mirrored virtual volumes. A subdisk has a start block and end block address within the disk in hexadecimal form. For more information see
Creating Subdisks (LUN Carving) in Chapter 4.
Figure 1-9. Concatenated Volume Block Distribution |
To accommodate large volumes of data or to best utilize small volumes spread over several disks, you can concatenate physical volumes or subdisks across storage devices to create a larger virtual volume. Concatenated volumes can also be created on virtual volumes as part of a volume hierarchy. For more information see
Concatenated Volumes in Chapter 4.
In Figure 1-10, the volume is divided into two equitable chunks to be mapped across two disks. Data blocks 1 – 4 are mapped to Disk 1, sectors 13 – 16. Data blocks 5 – 8 are mapped to Disk 2, sectors 13 – 16. Figure 1-10. Concatenated Volume Block Distribution |
A striped volume has data written equitably across two or more identical size disks, subdisks or virtual volumes to provide higher read/write rates. For more information see
Striped Volumes in Chapter 4.
Subdisks within a striped volume need to be on different disks to realize the benefits of striping. |
In Figure 1-11, data block 1 is mapped to sector 1 of Disk 1; data block 2 is mapped to sector 1 of Disk 2. Each subsequent data block is then written alternately between sectors on Disks 1 and 2. The striped unit size in this example is one block. Figure 1-11. Striped Volume Block Distribution |
A mirrored volume is synchronously written into multiple identical size volumes. The read load is balanced between each copy. Mirrored volumes can be created from two to four disks, subdisks or virtual volumes of equal block size. The size of the mirror is determined by its smallest child volume. For more information see
Mirrored Volumes in Chapter 4.
|
Mirrored volumes must be located on different physical disks. |
|
To achieve higher availability, Nexsan recommends configuring mirrored volumes onto different storage systems. |
|
In Figure 1-12, data block 1 is mapped to both sector 5 on Disk 1 and sector 9 on Disk 2. Data block 2 is mapped to both sectors 6 on Disk 1 and sectors 10 on Disk 2. Figure 1-12. Mirrored Volume Block Distribution |
You can combine different volume types to create hierarchies. Combining stripe and mirror volumes gives the advantage of both high performance and data redundancy.
In Figure 1-13, in the first mirrored volume, data block 1 is mapped to both block 1 on Disk 1 and block 1 on Disk 2. Data blocks 3, 5 and 7 are mapped to blocks 2, 3 and 4 on both Disks 1 and 2. In the second mirrored volume, data block 2 is mapped to both block 1 on Disk 3 and block 1 on Disk 4. Data blocks 4, 6 and 8 are mapped to blocks 2, 3 and 4 on Disks 3 and 4. Data blocks 1 and 2 are then compiled in a striped pattern, along with blocks 3 – 8. Figure 1-13. RAID 10 Volume Block Distribution |
Advanced Volume Configurations
The Nexsan iSeries supports several advanced volume operations. Each has its own advantages so it is important to understand their differences to best choose the function most appropriate for your SAN.
Data can be replicated both offline and online. Offline replication is faster than online replication but both the source and destination volumes must be taken off-line which can create an interruption of service to the volume host(s).
Offline copy is used to copy any source volume to any destination volume. This is done offline while both the source and destination volumes are unexposed. For more information see
Offline Copy in Chapter 4.Online Copy or Volume Migration
Online data replication allows the source volume to remain online with no interruption of service to the volume host(s). Online copy is performed by adding a child to a mirror and breaking it:
1. |
Adding a Child to a Mirror |
You can perform online data copy, either by increasing the number of children in a mirrored volume (
Figure 1-14) or creating a mirrored copy of any other type of volume (
Figure 1-15).
Since this is online data copy, the source volume does not need to be taken offline and write operations to the source volume can continue while the mirror is being created. Any data written to the volume will be included in the added child(ren). For more information see
Migrating Volumes or
Online Copy in Chapter 4.
The added child can be any type of volume, except transparent or snapshot, and it must be the same size or greater than the accessible capacity of the source volume. |
In Figure 1-14, a mirrored volume with two children has another child added. The mirrored volume stays at the head of the hierarchy. Figure 1-14. Adding Another Child to a Mirror |
In Figure 1-15, a concatenated volume becomes one child of a new mirrored volume. This adds a level to the hierarchy. The new mirrored volume becomes the head of the volume hierarchy. The new mirrored volume automatically assumes the LUN from the concatenated volume. Figure 1-15. Creating a Mirror to Add Data Redundancy |
Breaking a child from a mirror enables the volume to be used independently. The removed child is a fully functional volume and can be exposed to any host (
Figure 1-16). For more information see
Breaking a Mirror in Chapter 4.
The mirror volume cannot be broken while it is in the process of synchronization. |
In Figure 1-16, a child is removed from a mirrored volume with two children. This breaks the mirror. If the mirrored volume is exposed or attached to a LUN, the source volume retains the LUN. There is no need to reassign a LUN to the remaining source volume. All read-write operations will be executed without a break in service. Figure 1-16. Breaking a Mirror |
Snapshots can be used for serverless backup, reducing the load on the application server. The backup copy from a snapshot is a full copy of the source volume at the time of the snapshot and adequate size must be allocated for the backup volume.
You can create a
snapshot, a point-in-time copy, of any volume. A snapshot does not create a full copy of its source volume. It is a dynamic and dependent volume that records only changes to the source volume from the time of the snapshot’s creation. For more information see
Snapshot Operations in Chapter 4.Online Copy versus Snapshot
A mirrored volume copy is a full, complete volume copy. A snapshot is only a record of changes to a volume. Because of this, its capacity can be smaller than a mirrored volume copy. Both a mirrored volume copy and a snapshot can be exposed to a host like any other volume. However, unlike a mirrored copy, a snapshot is nonfunctional if its source volume goes off-line.
A snapshot volume cannot be used to build virtual volumes. |
Figure 1-17, shows a source volume with its snapshot when the snapshot is first created. Initially, a snapshot is empty because there has not yet been a change in its source volume. Only when a write operation is performed on the source volume will the snapshot begin to fill up.
Figure 1-17. 1 st Snapshot Created |
Figure 1-18 shows the same source and snapshot volume after a write operation to sector 1. The snapshot recorded the original data from sector 1 and then the new data is written to the source volume.
Figure 1-18. 1 st Write to Source and Update to 1 st Snapshot |
Figure 1-19, shows the creation of a second snapshot and a second write operation to the source volume.
Figure 1-19. 2 nd Snapshot Created, Write to Source & Update to 1 st Snapshot |
Figure 1-20, shows the creation of a third snapshot and a third write operation to the source volume. Both Snapshot 1 and Snapshot 2 are updated with the changes to the source volume.
The more active the write operations are to a source volume, the larger its snapshots will need to be. Nexsan requires a beginning snapshot volume of at least one percent of the size of its source volume. A snapshot volume can be resized to accommodate a growing capacity need. When a snapshot volume’s predefined load threshold is exceeded, an alert is set to resize the volume. When exposed, a snapshot must be exposed on the same Nexsan iSeries as its source volume. Figure 1-20. 3 rd Snapshot Created, Write to Source & Update to 1 st & 2 nd Snapshot |
You can expand any virtual volume by expanding its child volumes.
In Figure 1-21, Mir is a mirrored volume with an allocated capacity of one terabyte (1T). We want to ‘ Resize’ the mirror to two terabytes. This is done as follows: A: A simple volume of 1 terabyte is added to CH2 and the two volumes are concatenated (XSim2).
B: A simple volume of 1 terabyte is added to CH1 and the two volumes are concatenated (XSim1).
C: The original mirror volume is resized to 2 terabytes.
Note:
Until the original mirror volume Mir is ‘resized’ to two terabytes, the accessible volume remains unchanged (as shown in B).
Figure 1-21. Resizing a Volume |
Nexsan iSeries Manager Overview
Nexsan iSeries Manager is a network management system for the Nexsan iSeries.
|
Nexsan iSeries Manager centrally manages multiple Nexsan iSeries. |
|
Automatically synchronizes parameters in both devices when they are part of a cluster. |
|
Nexsan iSeries Manager manages virtualization processes (e.g. creating, expanding, exposing volumes). |
|
Nexsan iSeries Manager manages advanced volume operations (e.g. copying, snapshots, replicating volumes). |
|
Nexsan iSeries Manager provides performance monitoring for advanced diagnostics. |
|
Nexsan iSeries Manager provides detailed alarm reporting including email notification and alarm propagation. |
Managing the Nexsan iSeries
After powering up the Nexsan iSeries, the first thing you must do is to configure its management parameters. This can be done via telnet, SSH, using the Nexsan iSeries LCD panel (for Nexsan iSeries 3000 only) or via a console or dumb terminal to open a direct connection with the Nexsan iSeries RS232 console port.
The Nexsan iSeries can be managed in one of three different ways. Each way requires a different configuration.
|
In-bandThe management terminal (Telnet, SSH, SP server) connects to the Nexsan iSeries Eth1 port. The Eth1 port is used by the Nexsan iSeries for management as well as by the hosts for accessing data accessing storage data (refer to B, Figure 1-22). |
|
RS232The console connects to the Nexsan iSeries RS232 port in a direct connection (refer to C, Figure 1-22). The RS232 port is used mainly for initial configuration: setting up the management IP, Mask and Nexsan iSeries name. For more information on RS232 Serial Connection refer to RS232 Serial Connection in Chapter 3. |
|
Out-of-band (certain versions only )The management terminal (Telnet, SSH, SP server) connects to the Nexsan iSeries dedicated 10/100 management port via a fast Ethernet network (refer to A, Figure 1-22). The Nexsan iSeries default IP (10.11.12.123) can be used to connect to the Nexsan iSeries from remote (via telnet). For more information on Telnet/SSH connection refer to Telnet/SSH Connection in Chapter 3. |
Figure 1-22. Nexsan iSeries Management Options
