| Skip Navigation Links | |
| Exit Print View | |
|
Oracle® ZFS Storage Appliance Administration Guide |
Chapter 1 Oracle ZFS Storage Appliance Overview
Chapter 3 Initial Configuration
Chapter 4 Network Configuration
Chapter 5 Storage Configuration
Chapter 6 Storage Area Network Configuration
SAN Target and Initiator Groups
Associating a LUN with an FC Initiator Group
Associating a LUN with an FC initiator group
Scripting Aliases for Initiators and Initiator Groups
Configuring iSCSI Using the BUI
Creating an Analytics Worksheet
Configuring iSCSI Using the CLI
Adding an iSCSI Target with an Auto-generated IQN
Adding an iSCSI Target with a Specific IQN and RADIUS Authentication
Adding an iSCSI Initiator which uses CHAP Authentication
Adding an iSCSI Initiator Group
Configuring SRP Targets Using the BUI
Configuring SRP Targets Using the CLI
Chapter 8 Setting ZFSSA Preferences
Chapter 10 Cluster Configuration
Chapter 12 Shares, Projects, and Schema
By default, all FC ports are configured to be in target mode. If the appliance is used to connect to a tape SAN for backup, one or more ports must be configured in initiator mode. To configure a port for initiator mode, the appliance must be reset. Multiple ports can be configured for initiator mode simultaneously.
Each FC port is assigned a World Wide Name (WWN), and -- as with other block protocols -- FC targets may be grouped into SAN Target and Initiator Groups, allowing port bandwidth to be dedicated to specific LUNs or groups of LUNs. Once an FC port is configured as a target, the remotely discovered ports can be examined and verified.
Refer to the Implementing Fibre Channel SAN Boot with Oracle's Sun ZFS Storage Appliance whitepaper at http://www.oracle.com/technetwork/articles/servers-storage-admin/fbsanboot-365291.html for details on FC SAN boot solutions using the Oracle ZFS Storage Appliance.
In a cluster, initiators will have two paths (or sets of paths) to each LUN: one path (or set of paths) will be to the head that has imported the storage associated with the LUN; the other path (or set of paths) will be to that head's clustered peer. The first path (or set of paths) are active; the second path (or set of paths) are standby; in the event of a takeover, the active paths will become unavailable, and the standby paths will (after a short time) be transitioned to be active, after which I/O will continue. This approach to multipathing is known as asymmetric logical unit access (ALUA) and -- when coupled with an ALUA-aware initiator -- allows cluster takeover to be transparent to higher-level applications.
|