The identifying features of a type 1 configuration (as shown in Figure 1) are:
Figure 1. Type 1 configuration Single port, single server
Single Controller
Dual Controller
The type 2 configuration is shown in Figure 2
Figure 2. Type 2 configuration – Full redundancy
The identifying features of a type 2 configuration are:
If a QLA4010 HBA is being used, the diagnostic tool available is the SANsurfer Control application. This application provides configuration management as well as diagnostic PING and read/write buffer test. If a generic NIC is being used, the management and diagnostics are specific to that card. In this case you can still use the PING command from a operating system prompt. On the controller side, you can use the PING command to verify the path from the controller to the host. If you intend to diagnose a failed path while using the alternate path for production, be sure that you are familiar with the tools so that the correct portion is being exercised and you do not unplug anything in the active path.
You can also use the features of the switches to isolate resources from the bad or marginal path before beginning debug activities. Switches allow a view of log information that shows what problems have been occurring, as well as diagnostics that can be initiated from these managed elements. Also, a type 2 configuration has the capability to have more than one RAID controller unit behind a switch.
Note: Switches are sometimes referred to generically as concentrators.
Figure 4 shows a type 2 configuration with two dual controller DS300 enclosures.
Figure 4.
Type 2 configuration with two DS300 enclosures
The following example for debugging a type-2 configuration is shown in the following sequence of figures. In order to simplify the isolation of the problem, break the larger configuration into its smaller sub-elements and work with each piece separately. In this way you can remove the good path and leave only the bad path, as shown in the following sequence
Figure 5. Off line controller B
Figure 6. All I/O flowing through controller A
Controller A is processing I/Os and is unavailable for diagnostics
The elements of the paths shown in Figure 7 are as follows:
When a controller iSCSI port detects a link down condition the controller maps the IP address of that port to the other ports according to the IP failover mode active at the time. The DS300 supports 4 ipfailover modes.
Local
Remote (remote is the default and is the only supported failover mode at this time)
Both (local-remote)
None
The policy for the failover of iSCSI interfaces can be set using the CLI with these options:
local: The failover occurs on a port basis - that is if a link down is detected by one of the controller ports then the ip address of that port is mapped to the remaining port on the same controller (ETH2àETH3 or ETH3àETH2).
remote: If a link down is detected on any interface port of a controller, the controller is failed over to the other controller (ETH2àETH2 and ETH3àETH3). The host is now able to access all storage through the online controller.
both: The failover occurs on a port basis - that is if a link down is detected by one of the controller ports then the ip address of that port is mapped to the remaining port (ETH2àETH3 or ETH3àETH2). If that remaining port subsequently goes offline, the controller is failed over to the remaining controller. All offline port IP addresses are mapped to the corresponding ports of the remaining controller (ETH2àETH2 and ETH3àETH3).
none: Failover is disabled – that is no failover occurs from the local controller ports or from controller to controller ports.