
78
Novell Business Continuity Clustering 1.1 for NetWare Administration Guide
no
vd
ocx (
e
n)
1
1
Decemb
er
2
007
outbound interface’s IP address as the local socket end point address. In order for these legacy
applications to take advantage of the fault resilience provided by the virtual IP address feature, the
default source address selection behavior of TCP/IP has been enhanced to accommodate the use of a
virtual IP address as the source IP address. As a result, whenever a TCP or UDP application initiates
an outbound connection with a wildcard source IP address, TCP/IP will choose the first bound
virtual IP address as the source IP address for the connection.
This enhanced source address selection feature can be enabled or disabled globally as well as on a
per-interface basis. This feature is enabled by default on all interfaces.
5.4 Reducing the Consumption of Additional IP
Addresses
The only drawback in reaping the benefits of virtual IP addresses is the consumption of additional IP
addresses. This constraint stems from the requirement that virtual IP network addresses must be
different from all other real IP network addresses. Although this constraint is not particularly severe
in enterprises that use private addressing (where the IP address space is potentially large), it could
become limiting in organizations that do not use private addresses.
In enterprises that use fixed-length subnetting together with a dynamic routing protocol like RIP-1,
each virtual IP address could consume a large number of host IP addresses. One way to circumvent
this problem is to configure a virtual IP address with a host mask of all 1s (that is, FF.FF.FF.FF),
thereby consuming only one host IP address. Of course, the viability of this option depends on the
ability of the RIP-1 routers on the network to recognize and honor the advertised host routes.
In autonomous systems that use variable-length subnet masking (VLSM) together with routing
protocols like RIP-II or OSPF, the consumption of additional IP addresses is not a major problem.
You could simply configure a virtual IP address with as large an IP network mask as possible
(including a host mask of all 1s), thereby limiting the number of addresses consumed by the virtual
IP address space.
In any network environment, one of the first obstacles is how clients locate and connect to the
services. A business continuity cluster can exacerbate this problem because services can migrate to
nodes on a completely different network segment. While there are many potential solutions to this
problem, such as DNS and SLP, none of them offers the simplicity and elegance of virtual IP
addresses. With virtual IP addresses, the IP address of the service can follow the service from node
to node in a single cluster, as well as from node to node in separate, distinct clusters. This makes the
client reconnection problem trivial; the client just waits for the new route information to be
propagated to the routers on the network. No manual steps are required, such as modifying a DNS
server.
To use a virtual IP address in a business continuity cluster, we recommend using a host mask. To
understand why, consider the fact that each service in a clustered environment must have its own
unique IP address or, a unique virtual IP address. Furthermore, consider that each virtual IP address
belongs to a virtual IP network whose route is being advertised by a single node within a cluster.
Because Novell Cluster Services™ can migrate a service and its virtual IP address from one node to
another, the virtual IP network must migrate to the same node as the service. If multiple virtual IP
addresses belong to a given virtual IP network, one of two events must occur:
All services associated with the virtual IP addresses on a given virtual IP network must fail
over together.
Содержание BUSINESS CONTINUITY CLUSTERING FOR NETWARE 1.1 - ADMINISTRATION
Страница 4: ...novdocx en 11 December 2007...
Страница 10: ...10 Novell Business Continuity Clustering 1 1 for NetWare Administration Guide novdocx en 11 December 2007...
Страница 72: ...72 Novell Business Continuity Clustering 1 1 for NetWare Administration Guide novdocx en 11 December 2007...
Страница 86: ...86 Novell Business Continuity Clustering 1 1 for NetWare Administration Guide novdocx en 11 December 2007...