Chapter 9. NAS / N series solution design 133
The configuration entries of the /etc/rc file of both controllers are identical as described in the
previous section “Active/passive path, RTCA product HA, EtherChannel/LACP bonds” on
page 128 and shown in Example 9-3 on page 129. Similarly, the vif configuration is described
in the previous section “Active/passive path, RTCA product HA, EtherChannel/LACP bonds”
on page 128 and shown in Example 9-4 on page 130.
9.4 N series MetroCluster solutions
IBM N series MetroCluster is a synchronous replication solution for combined high availability
(HA) and disaster recovery (DR), protecting against site disasters within a campus or
metropolitan area with distances up to 100 km. Usually due to cabling and installation
requirements it is not possible to connect every N series controller of the HA pair with both
RTCA products at each site to provide the best redundancy and availability.
Generally you can configure the RTCA product in N series MetroCluster environments in a
different manner:
򐂰 One RTCA product at each site to connect one RTCA product with only one N series
controller in Figure 9-8
򐂰 Two RTCA products at each site to connect one N series controller redundant to two
RTCA products in Figure 9-9
In the first option it is absolute necessary to configure the N series to failover to the partner
site in case of an RTCA product failure. Additionally it is preferable to connect each RTCA
product to more than one switch, otherwise a network switch failure will also require an
N series controller failover.
Figure 9-8 Single RTCA product design for MetroCluster
Tip: To enable an automatic takeover if the N series controller detect failures in the network
interfaces, set the option “cf.takeover.on_network_interface_failure” to “on”.
134 Introduction to IBM Real-time Compression Appliances
With the RTCA product unsynchronized, MetroCluster site failover is problematic and
therefore an HA RTCA product setup at each site with active/passive configuration is
preferable, as illustrated in Figure 9-9.
Figure 9-9 Dual RTCA product design for MetroCluster
In that architecture, STN1 and STN2 cannot see any shares of NAS1b, the remote cluster
partner of the local controller NAS1a. However it is necessary to create both storage server
objects (for NAS1a and NAS1b) in all RTCA products at both sites. In such a configuration it
is best to build a star topology for the configuration of HA Auto Sync, as you can see in
Figure 9-10.
STN1 is configured as an HA pair with STN2, STN3, and STN4. The configuration of
compression filters is performed only on one RTCA product, in this example STN1, to avoid
synchronization issues. In other words: STN1 acts as a master and is paired with STN2,
STN3, and STN4. Now, you can modify the compression filter configuration and your
modification will be replicated to all other RTCA products immediately after you apply the
changes.
If a compression filter is not defined as compressed in the compression filter list of all RTCA
products in the same manner, data will not be accessible or corrupt after a cluster failover
occurs and clients access the data through a logical bypass.
Chapter 9. NAS / N series solution design 135
Figure 9-10 RTCA star topology
Depending on the architecture of a MetroCluster, a dual inter-site link failure can theoretically
occur. The Error message looks like the one shown in Figure 9-11.
Figure 9-11 Inter-site link failure, no route to partner
Important: It is not desirable to disable HA auto sync temporarily to modify a compression
filter configuration after an inter-site link failure occurs. If you have a link problem, resolve it
first, then add or remove compression filters.

Get Introduction to IBM Real-time Compression Appliances now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.