Return to planning.sgml CVS log

Up to [Development] / projects / failsafe / FailSafe-books / LnxFailSafe_AG

New documentation files for the Admin Guide.

<!-- Fragment document type declaration subset:
ArborText, Inc., 1988-1997, v.4001
<!DOCTYPE SET PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
<!ENTITY ha.cluster.messages SYSTEM "figures/ha.cluster.messages.eps" NDATA eps>
<!ENTITY machine.not.in.ha.cluster SYSTEM "figures/machine.not.in.ha.cluster.eps" NDATA eps>
<!ENTITY ha.cluster.config.info.flow SYSTEM "figures/ha.cluster.config.info.flow.eps" NDATA eps>
<!ENTITY software.layers SYSTEM "figures/software.layers.eps" NDATA eps>
<!ENTITY n1n4 SYSTEM "figures/n1n4.eps" NDATA eps>
<!ENTITY example.sgml SYSTEM "example.sgml">
<!ENTITY appupgrade.sgml SYSTEM "appupgrade.sgml">
<!ENTITY a1-1.failsafe.components SYSTEM "figures/a1-1.failsafe.components.eps" NDATA eps>
<!ENTITY a1-6.disk.storage.takeover SYSTEM "figures/a1-6.disk.storage.takeover.eps" NDATA eps>
<!ENTITY a2-3.non.shared.disk.config SYSTEM "figures/a2-3.non.shared.disk.config.eps" NDATA eps>
<!ENTITY a2-4.shared.disk.config SYSTEM "figures/a2-4.shared.disk.config.eps" NDATA eps>
<!ENTITY a2-5.shred.disk.2active.cnfig SYSTEM "figures/a2-5.shred.disk.2active.cnfig.eps" NDATA eps>
<!ENTITY a2-1.examp.interface.config SYSTEM "figures/a2-1.examp.interface.config.eps" NDATA eps>
<!ENTITY intro.sgml SYSTEM "intro.sgml">
<!ENTITY overview.sgml SYSTEM "overview.sgml">
<!ENTITY nodeconfig.sgml SYSTEM "nodeconfig.sgml">
<!ENTITY admintools.sgml SYSTEM "admintools.sgml">
<!ENTITY config.sgml SYSTEM "config.sgml">
<!ENTITY operate.sgml SYSTEM "operate.sgml">
<!ENTITY diag.sgml SYSTEM "diag.sgml">
<!ENTITY recover.sgml SYSTEM "recover.sgml">
<!ENTITY clustproc.sgml SYSTEM "clustproc.sgml">
<!ENTITY appfiles.sgml SYSTEM "appfiles.sgml">
<!ENTITY gloss.sgml SYSTEM "gloss.sgml">
<!ENTITY preface.sgml SYSTEM "preface.sgml">
<!ENTITY index.sgml SYSTEM "index.sgml">
]>
-->
<chapter id="LE88622-PARENT">
<title id="LE88622-TITLE">Planning Linux FailSafe Configuration</title>
<para>This chapter explains how to plan the configuration of highly available
services on your Linux FailSafe cluster. The major sections of this chapter
are as follows:</para>
<itemizedlist>
<listitem><para><xref linkend="LE57040-PARENT"></para>
</listitem>
<listitem><para><xref linkend="LE34382-PARENT"></para>
</listitem>
<listitem><para><xref linkend="LE96329-PARENT"></para>
</listitem>
<listitem><para><xref linkend="LE53947-PARENT"></para>
</listitem>
<listitem><para><xref linkend="LE84104-PARENT"></para>
</listitem>
</itemizedlist>
<sect1 id="LE57040-PARENT">
<title id="LE57040-TITLE">Introduction to Configuration Planning</title>
<para><indexterm id="ITplanning-0"><primary>configuration planning</primary>
<secondary>overview</secondary></indexterm>Configuration planning involves
making decisions about how you plan to use the Linux FailSafe cluster, and
based on that, how the disks and interfaces must be set up to meet the needs
of the highly available services you want the cluster to provide. Questions
you must answer during the planning process are:</para>
<itemizedlist>
<listitem><para>What do you plan to use the nodes for?</para>
<para>Your answers might include uses such as offering home directories for
users, running particular applications, supporting an Oracle database, providing
Netscape World Wide Web service, and providing file service.</para>
</listitem>
<listitem><para>Which of these uses will be provided as a highly available
service?</para>
<para> To offer applications as highly available services that are not currently
available as Linux Failsafe software options, a set of application monitoring
shell scripts needs to be developed that provides switch over and switch back
functionality. Developing these scripts is described in the <citetitle>Linux
FailSafe Programmer's Guide</citetitle>. If you need assistance in this regard,
contact SGI Global Services, which offers custom Linux FailSafe agent development
and HA integration services.</para>
</listitem>
<listitem><para>Which node will be the primary node for each highly available
service?</para>
<para>The primary node is the node that provides the service (exports the
filesystem, is a Netscape server, provides the database, and so on) when the
node is in an UP state.</para>
</listitem>
<listitem><para>For each highly available service, how will the software and
data be distributed on shared and non-shared disks?</para>
<para>Each application has requirements and choices for placing its software
on disks that are failed over (shared) or not failed over (non-shared).</para>
</listitem>
<listitem><para>Are the shared disks going to be part of a RAID storage system
or are they going to be disks in SCSI/Fibre channel disk storage that has
mirroring such as the Linux Raid Tools implemented on them?</para>
<para>For reliability, shared disks must be part of a RAID storage system
or in SCSI/Fibre channel disk storage with mirroring on them.</para>
</listitem>
<listitem><para>Will the shared disks be used as raw devices/volumes or as
volumes with filesystems on them?</para>
<para>Logical volumes, filesystems, and raw partitions are all supported by
Linux Failsafe.  The choice of volumes, filesystems, or raw devices depends
on the application that is going to use the disk space.</para>
</listitem>
<listitem><para>Which IP addresses will be used by clients of highly available
services?</para>
<para>Multiple interfaces may be required on each node because a node could
be connected to more than one network or because there could be more than
one interface to a single network.</para>
</listitem>
<listitem><para>Which resources will be part of a resource group?</para>
<para>All resources that are dependent on each other have to be in the resource
group.</para>
</listitem>
<listitem><para>What will be the failover domain of the resource group?</para>
<para>The failover domain determines the list of nodes in the cluster where
the resource group can reside. For example, a volume resource that is part
of a resource group can reside only in nodes from which the disks composing
the volume can be accessed.</para>
</listitem>
<listitem><para><indexterm id="ITplanning-1"><primary>IP address</primary>
<secondary>planning</secondary></indexterm>How many highly available IP addresses
on each network interface will be available to clients of the highly available
services?</para>
<para>At least one highly available IP address must be available for each
interface on each node that is used by clients of highly available services.
</para>
</listitem>
<listitem><para>Which IP addresses on primary nodes are going to be available
to clients of the highly available services?</para>
</listitem>
<listitem><para>For each highly available IP address that is available on
a primary node to clients of highly available services, which interface on
the other nodes will be assigned that IP address after a failover?</para>
<para>Every highly available IP address used by a highly available service
must be mapped to at least one interface in each node that can take over the
resource group service. The highly available IP addresses are failed over
from the interface in the primary node of the resource group to the interface
in the replacement node.</para>
</listitem>
</itemizedlist>
<para>As an example of the configuration planning process, say that you have
a two-node Linux FailSafe cluster that is a departmental server. You want
to make four XFS filesystems available for NFS mounting and have two Netscape
FastTrack servers, each serving a different set of documents. These applications
will be highly available services.</para>
<para>You decide to distribute the services across two nodes, so each node
will be the primary node for two filesystems and one Netscape server. The
filesystems and the document roots for the Netscape servers (on XFS filesystems)
are each on their own striped LVM logical volume. The logical volumes are
created from disks in a RAID storage system connected to both nodes.</para>
<para>There are four resource groups: NFSgroup1 and NFSgroup2 are the NFS
resource groups, and Webgroup1 and Webgroup2 are the Web resource groups.
NFSgroup1 and Webgroup1 will have one node as the primary node. NFSgroup2
and Webgroup2 will have the other node as the primary node.</para>
<para>Two networks are available on each node, eth0 and eth1. The eth0 interfaces
in each node are connected to each other to form a private network.</para>
<para>The following sections help you answer the configuration questions above,
make additional configuration decisions required by Linux FailSafe, and collect
the information you need to perform the configuration tasks described in <xref
linkend="LE32854-PARENT">, and <xref linkend="LE94219-PARENT">.</para>
</sect1>
<sect1 id="LE34382-PARENT">
<title id="LE34382-TITLE">Disk Configuration</title>
<para><indexterm id="ITplanning-2"><primary>configuration planning</primary>
<secondary>disk</secondary></indexterm> <indexterm id="ITplanning-3"><primary>
disk configuration planning</primary></indexterm>The first subsection below
describes the disk configuration issues that must be considered when planning
a Linux FailSafe system. It explains the basic configurations of shared and
non-shared disks and how they are reconfigured by Linux FailSafe after a failover.
 The second subsection explains how disk configurations are specified when
you configure the Linux FailSafe system.</para>
<sect2>
<title>Planning Disk Configuration</title>
<para>For each disk in a Linux FailSafe cluster, you must choose whether to
make it a shared disk, which enables it to be failed over, or a non-shared
disk. Non-shared disks are not failed over.</para>
<para>The nodes in a Linux FailSafe cluster must follow these requirements:
</para>
<itemizedlist>
<listitem><para>The system disk must be a non-shared disk.</para>
</listitem>
<listitem><para>The Linux FailSafe software, in particular the directories <?Pub _nolinebreak><filename>
/var/run/failsafe</filename><?Pub /_nolinebreak> and <?Pub _nolinebreak><filename>
/var/lib/failsafe</filename><?Pub /_nolinebreak>, must be on a non-shared
disk.</para>
</listitem>
</itemizedlist>
<para>Choosing to make a disk shared or non-shared depends on the needs of
the highly available services that use the disk. Each highly available service
has requirements about the location of data associated with the service:</para>
<itemizedlist>
<listitem><para>Some data must be placed on non-shared disks</para>
</listitem>
<listitem><para>Some data must be placed on shared disks</para>
</listitem>
<listitem><para>Some data can be on shared or non-shared disks</para>
</listitem>
</itemizedlist>
<para>The figures in the remainder of this section show the basic disk configurations
on Linux FailSafe clusters before failover. Each figure also shows the configuration
after failover. The basic disk configurations are these:</para>
<itemizedlist>
<listitem><para>A non-shared disk on each node</para>
</listitem>
<listitem><para>Multiple shared disks contained Web server and NFS file server
documents</para>
</listitem>
</itemizedlist>
<para>In each of the before and after failover diagrams, just one or two disks
are shown. In fact, many disks could be connected in the same way as each
disk shown. Thus each disk shown can represent a set of disks.</para>
<para>A Linux cluster can contain a combination of the basic disk configurations
listed above.</para>
<para><xref linkend="LE22456-PARENT"> shows two nodes in a Linux FailSafe
cluster, each of which has a non-shared disk with two resource groups. When
non-shared disks are used by highly available applications, the data required
by those applications must be duplicated on non-shared disks on both nodes.
When a failover occurs, IP aliases fail over. The data that was originally
available on the failed node is still available from the replacement node
by using the IP alias to access it.</para>
<para>The configuration in <xref linkend="LE22456-PARENT"> contains two resource
groups, <literal>Group1</literal> and <literal>Group2</literal>. <literal>
Group1</literal> contains resource <literal>192.26.50.1</literal> of <literal>
IP_address</literal> resource type. <literal>Group2</literal> contains resource <literal>
192.26.50.2</literal> of <literal>IP_address</literal> resource type.</para>
<para><figure id="LE22456-PARENT">
<title id="LE22456-TITLE">Non-Shared Disk Configuration and Failover</title>
<graphic entityref="a2-3.non.shared.disk.config"></graphic>
</figure></para>
<para><xref linkend="LE83029-PARENT"> shows a two-node configuration with
one resource group, <literal>Group1</literal>. Resource group Group1 has a
failover domain of (<?Pub _nolinebreak><literal>xfs-ha1</literal><?Pub /_nolinebreak>, <?Pub _nolinebreak><literal>
xfs-ha2</literal><?Pub /_nolinebreak>). Resource group Group1 contains three
resources: resource <?Pub _nolinebreak><literal>192.26.50.1</literal><?Pub /_nolinebreak><?Pub Caret> of
resource type <literal>IP_address</literal>, resource <literal>/shared</literal>
of resource type <literal>filesystem</literal>, and resource <literal>shared_vol
</literal> of resource type <literal>volume</literal>.</para>
<para>In this configuration, the resource group <literal>Group1</literal>
has a <firstterm>primary node</firstterm>, which is the node that accesses
the disk prior to a failover. It is shown by a solid line connection. The
backup node, which accesses the disk after a failover, is shown by a dotted
line. Thus, the disk is shared between the nodes. In an active/backup configuration,
all resource groups have the same primary node. The backup node does not run
any highly available resource groups until a failover occurs.</para>
<para><figure id="LE83029-PARENT">
<title id="LE83029-TITLE">Shared Disk Configuration for Active/Backup Use
</title>
<graphic entityref="a2-4.shared.disk.config"></graphic>
</figure></para>
<para><xref linkend="LE83152-PARENT">, shows two shared disks in a two-node
cluster with two resource groups, <literal>Group1</literal> and <literal>
Group2</literal>. Resource group <literal>Group1</literal> contains the following
resources:</para>
<itemizedlist>
<listitem><para>Resource <literal>192.26.50.1</literal> of type <literal>
IP_address</literal></para>
</listitem>
<listitem><para>Resource <literal>shared1_vol</literal> of type <literal>
volume</literal></para>
</listitem>
<listitem><para>Resource <literal>/shared1</literal> of type <literal>filesystem
</literal></para>
</listitem>
</itemizedlist>
<para>Resource group <literal>Group1</literal> has a failover domain of (<literal>
xfs-ha1</literal>, <literal>xfs-ha2</literal>).</para>
<para>Resource group <literal>Group2</literal> contains the following resources:
</para>
<itemizedlist>
<listitem><para>Resource <literal>192.26.50.2</literal> of type <literal>
IP_address</literal></para>
</listitem>
<listitem><para>Resource <literal>shared2_vol</literal> of type <literal>
volume</literal></para>
</listitem>
<listitem><para>Resource <literal>/shared2</literal> of type <literal>filesystem
</literal></para>
</listitem>
</itemizedlist>
<para>Resource group <literal>Group2</literal> has a failover domain of (<literal>
xfs-ha2</literal>, <literal>xfs-ha1</literal>).</para>
<para>In this configuration, each node serves as a primary node for one resource
group. The solid line connections show the connection to the primary node
prior to failover. The dotted lines show the connections to the backup nodes.
After a failover, the surviving node has all the resource groups.</para>
<para><figure id="LE83152-PARENT">
<title id="LE83152-TITLE">Shared Disk Configuration For Dual-Active Use</title>
<graphic entityref="a2-5.shred.disk.2active.cnfig"></graphic>
</figure></para>
<para>Other sections in this chapter provide more specific information about
choosing between shared and non-shared disks for various types of data associated
with each highly available service.</para>
</sect2>
<sect2 id="le10802-parent">
<title>Configuration Parameters for Disks</title>
<para>There are no configuration parameters associated with non-shared disks.
They are not specified when you configure a Linux FailSafe system. Only shared
disks (actually, the logical volumes/partitions on shared disks) are specified
at configuration. See the <xref linkend="LE13082-PARENT"> for details.</para>
</sect2>
</sect1>
<sect1 id="LE96329-PARENT">
<title id="LE96329-TITLE">Logical Volume Configuration</title>
<para><indexterm id="ITplanning-4"><primary>configuration planning</primary>
<secondary>logical volume</secondary></indexterm> <indexterm id="ITplanning-5">
<primary>logical volume</primary><secondary>configuration planning</secondary>
</indexterm>The first subsection below describes logical volume issues that
must be considered when planning a Linux FailSafe system.  The second subsection
explains the aspects of the configuration that must be specified for a Linux
FailSafe system.</para>
<sect2 id="LE13082-PARENT">
<title id="LE13082-TITLE">Configuration Parameters for Logical Volumes</title>
<para><indexterm id="ITplanning-6"><primary>logical volume</primary><secondary>
parameters</secondary></indexterm> <indexterm id="ITplanning-7"><primary>
configuration parameters</primary><secondary>logical volumes</secondary></indexterm>Configuration
parameters for logical volumes list</para>
<itemizedlist>
<listitem><para>Owner of device filename (default value: <literal>root</literal>)
</para>
</listitem>
<listitem><para>Group of device filename (default value: <literal>sys</literal>)
</para>
</listitem>
<listitem><para>Mode of device filename (default value: <literal>600</literal>)
</para>
</listitem>
</itemizedlist>
<para><xref linkend="LE33754-PARENT">, lists a label and parameters for individual
logical volumes.</para>
<table frame="topbot" id="LE33754-PARENT">
<title id="LE33754-TITLE">Logical Volume Configuration Parameters</title>
<tgroup cols="5" colsep="0" rowsep="0">
<colspec colwidth="116*">
<colspec colwidth="58*">
<colspec colwidth="61*">
<colspec colwidth="52*">
<colspec colwidth="180*">
<thead>
<row rowsep="1"><entry align="left" valign="bottom"><para>Resource Attribute
</para></entry><entry align="left" valign="bottom"><para><literal>volA</literal></para></entry>
<entry align="left" valign="bottom"><para><literal>volB</literal></para></entry>
<entry align="left" valign="bottom"><para><literal>volC</literal></para></entry>
<entry align="left" valign="bottom"><para>Comments</para></entry></row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><para><literal>devname-owner</literal></para></entry>
<entry align="left" valign="top"><para><literal>root</literal></para></entry>
<entry align="left" valign="top"><para><literal>root</literal></para></entry>
<entry align="left" valign="top"><para><literal>root</literal></para></entry>
<entry align="left" valign="top"><para>The owner of the device name.</para></entry>
</row>
<row>
<entry align="left" valign="top"><para><literal>devname-group</literal></para></entry>
<entry align="left" valign="top"><para><literal>sys</literal></para></entry>
<entry align="left" valign="top"><para><literal>sys</literal></para></entry>
<entry align="left" valign="top"><para><literal>root</literal></para></entry>
<entry align="left" valign="top"><para>The group of the device name.</para></entry>
</row>
<row>
<entry align="left" valign="top"><para><literal>devname-mode</literal></para></entry>
<entry align="left" valign="top"><para><literal>0600</literal></para></entry>
<entry align="left" valign="top"><para><literal>0600</literal></para></entry>
<entry align="left" valign="top"><para><literal>0600</literal></para></entry>
<entry align="left" valign="top"><para>The mode of the device name.</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
</sect1>
<sect1 id="LE53947-PARENT">
<title id="LE53947-TITLE">Filesystem Configuration</title>
<para><indexterm id="ITplanning-8"><primary>configuration planning</primary>
<secondary>filesystem</secondary></indexterm> <indexterm id="ITplanning-9">
<primary>filesystem</primary><secondary>configuration planning</secondary>
</indexterm>The first subsection below describes filesystem issues that must
be considered when planning a Linux FailSafe system. The second subsection
gives an example of an XFS filesystem configuration on a Linux FailSafe system.
The third subsection explains the aspects of the configuration that must be
specified for a Linux FailSafe system.</para>
<sect2 id="LE24179-PARENT">
<title id="LE24179-TITLE">Planning Filesystems</title>
<para>The Linux FailSafe software supports the automatic failover of filesystem
including XFS, ext2fs, and reiserfs on shared disks. Shared disks must be
either mirrored or RAID storage systems that are shared between the nodes
in the two-node Linux FailSafe cluster.</para>
<para>The following are special issues that you need to be aware of when you
are working with filesystems on shared disks in a Linux FailSafe cluster:
</para>
<itemizedlist>
<listitem><para>All filesystems to be failed over must be supported by Failsafe.
</para>
</listitem>
<listitem><para>For availability, filesystems to be failed over in a Linux
FailSafe cluster should be created either on mirrored disks or using a system
that supports hardware mirroring of the data such as a RAID storage system.
</para>
</listitem>
<listitem><para>Create the mount points for the filesystems on all nodes in
the failover domain.</para>
</listitem>
<listitem><para>When you set up the various highly available filesystems on
each node, make sure that each filesystem uses a different mount point.</para>
</listitem>
<listitem><para>Do not simultaneously mount filesystems on shared disks on
more than one node. Doing so causes data corruption. Normally, Linux FailSafe
performs all mounts of filesystems on shared disks. If you manually mount
a filesystem on a shared disk, make sure that it is not being used by another
node.</para>
</listitem>
<listitem><para>Do not place filesystems on shared disks in the <filename>
/etc/fstab</filename> file. Linux FailSafe mounts these filesystems only after
making sure that another node does not have these filesystems mounted.</para>
</listitem>
</itemizedlist>
<para>The resource name of a resource of the <literal>filesystem</literal>
resource type is the mount point of the filesystem.</para>
<note>
<para>When clients are actively writing to a Linux FailSafe NFS filesystem
during failover of filesystems, data corruption can occur unless filesystems
are exported with the mode <literal>sync</literal>. This mode requires that
local mounts of the filesystems use the <literal>sync</literal> mount mode
as well. Using <literal>sync</literal> affects performance considerably.</para>
</note>
</sect2>
<sect2>
<title>Example Filesystem Configuration</title>
<para>Continuing with the example configuration from the <xref linkend="LE10802-PARENT">,
say that volumes A and B have XFS filesystems on them:</para>
<itemizedlist>
<listitem><para>The filesystem on volume A is mounted at <filename>/sharedA
</filename> with modes <literal>rw</literal> and <literal>noauto</literal>.
Call it filesystem A.</para>
</listitem>
<listitem><para>The filesystem on volume B is mounted at <filename>/sharedB
</filename> with modes <literal>rw</literal>, <literal>noauto</literal>, and <literal>
wsync</literal>.  Call it filesystem B.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Configuration Parameters for Filesystems</title>
<para><indexterm id="ITplanning-10"><primary>filesystem</primary><secondary>
configuration parameters</secondary></indexterm> <indexterm id="ITplanning-11">
<primary>configuration parameters</primary><secondary>filesystem</secondary>
</indexterm><xref linkend="LE31422-PARENT">, lists a label and configuration
parameters for each filesystem.</para>
<table frame="topbot" pgwide="1" id="LE31422-PARENT">
<title id="LE31422-TITLE">Filesystem Configuration Parameters</title>
<tgroup cols="4" colsep="0" rowsep="0">
<colspec colwidth="102*">
<colspec colwidth="77*">
<colspec colwidth="109*">
<colspec colwidth="188*">
<thead>
<row rowsep="1"><entry align="left" valign="bottom"><para>Resource Attribute
</para></entry><entry align="left" valign="bottom"><para><literal>/sharedA
</literal></para></entry><entry align="left" valign="bottom"><para><literal>
/sharedB</literal></para></entry><entry align="left" valign="bottom"><para>
Comments</para></entry></row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><para><literal>monitoring-level</literal></para></entry>
<entry align="left" valign="top"><para><literal>2</literal></para></entry>
<entry align="left" valign="top"><para><literal>2</literal></para></entry>
<entry align="left" valign="top"><para>There are two types of monitoring:
</para><para>1 &ndash; checks<literal> /etc/mtab</literal> file</para><para>
2 &ndash; checks if the filesystem is mounted using <command>stat</command>
command</para></entry>
</row>
<row>
<entry align="left" valign="top"><para><literal>volume-name</literal></para></entry>
<entry align="left" valign="top"><para><literal>volA</literal></para></entry>
<entry align="left" valign="top"><para><literal>volB</literal></para></entry>
<entry align="left" valign="top"><para>The label of the logical volume on
which the filesystem was created.</para></entry>
</row>
<row>
<entry align="left" valign="top"><para><literal>mode</literal></para></entry>
<entry align="left" valign="top"><para><literal>rw,noauto</literal></para></entry>
<entry align="left" valign="top"><para><literal>rw,noauto,wsync</literal></para></entry>
<entry align="left" valign="top"><para>The mount options used to mount the
filesystem. This is specified the same as the options for the mount command
or other filesystems listed in <filename>/etc/fstab</filename>. </para></entry>
</row>
</tbody>
</tgroup>
</table>
<para>See <xref linkend="LE39637-PARENT">, for information about creating
XFS filesystems.</para>
</sect2>
</sect1>
<sect1 id="LE84104-PARENT">
<title id="LE84104-TITLE">IP Address Configuration</title>
<para><indexterm id="ITplanning-12"><primary>IP address</primary><secondary>
planning</secondary></indexterm> <indexterm id="ITplanning-13"><primary>configuration
planning</primary><secondary>IP address</secondary></indexterm> <indexterm
id="ITplanning-14"><primary>IP address</primary><secondary>configuration planning
</secondary></indexterm>The first subsection below describes network interface
and IP address issues that must be considered when planning a Linux FailSafe
system. The second subsection gives an example of the configuration of network
interfaces and IP addresses on a Linux FailSafe system. The third subsection
explains the aspects of the configuration that must be specified for a Linux
FailSafe configuration.</para>
<sect2 id="LE93615-PARENT">
<title id="LE93615-TITLE">Planning Network Interface and IP Address Configuration
</title>
<para>Follow these guidelines when planning the configuration of the interfaces
to the private network between nodes in a cluster that can be used as a control
network between nodes (this information is used when you define the nodes):
</para>
<itemizedlist>
<listitem><para>Each interface has one IP address.</para>
</listitem>
<listitem><para>The IP addresses used on each node for the interfaces to the
private network are on a different subnet from the IP addresses used for public
networks.</para>
</listitem>
<listitem><para><indexterm id="ITplanning-15"><primary>/etc/hosts file</primary>
</indexterm>An IP name can be specified for each IP address in <filename>
/etc/hosts</filename>.</para>
</listitem>
<listitem><para>Choosing a naming convention for these IP addresses that identifies
them with the private network can be helpful. For example, precede the hostname
with <literal>priv-</literal> (for <firstterm>private</firstterm>), as in <literal>
priv-xfs-ha1</literal> and <literal>priv-xfs-ha2</literal>.</para>
</listitem>
</itemizedlist>
<para>Follow these guidelines when planning the configuration of the node
interfaces in a cluster to one or more public networks:</para>
<itemizedlist>
<listitem><para><indexterm id="ITplanning-16"><primary>re-MACing</primary>
<secondary>dedicated backup interfaces required</secondary></indexterm>If
re-MACing is required, each interface to be failed over requires a dedicated
backup interface on the other node (an interface that does not have a highly
available IP address). Thus, for each IP address on an interface that requires
re-MACing, there should be one interface in each node in the failover domain
dedicated for the interface.</para>
</listitem>
<listitem><para>Each interface has a primary IP address. The primary IP address
does not fail over.</para>
</listitem>
<listitem><para>The hostname of a node cannot be a highly available IP address.
</para>
</listitem>
<listitem><para>All IP addresses used by clients to access highly available
services must be part of the resource group to which the HA service belongs.
</para>
</listitem>
<listitem><para>If re-MACing is required, all of the highly available IP addresses
must have the same backup interface.</para>
</listitem>
<listitem><para>Making good choices for highly available IP addresses is important;
these are the &ldquo;hostnames&rdquo; that will be used by users of the highly
available services, not the true hostnames of the nodes.</para>
</listitem>
<listitem><para>Make a plan for publicizing the highly available IP addresses
to the user community, since users of highly available services must use highly
available IP addresses instead of the output of the <command>hostname</command>
command.</para>
</listitem>
<listitem><para>Do not configure highly available IP addresses in static Linux
configuration files.</para>
</listitem>
</itemizedlist>
<para><indexterm id="ITplanning-17"><primary>re-MACing</primary><secondary>
determining if required</secondary></indexterm>Follow the procedure below
to determine whether re-MACing is required (see  <xref linkend="LE80214-PARENT">,
for information about re-MACing). It requires the use of three nodes: <replaceable>
node1</replaceable>, <replaceable>node2</replaceable>, and <replaceable>node3
</replaceable>. <replaceable>node1</replaceable> and <replaceable>node2</replaceable>
can be nodes of a Linux FailSafe cluster, but they need not be. They must
be on the same subnet. <replaceable>node3</replaceable> is a third node. If
you need to verify that a router accepts gratuitous ARP packets (which means
that re-MACing is not required), <replaceable>node3</replaceable> must be
on the other side of the router from <replaceable>node1</replaceable> and <replaceable>
node2</replaceable>.</para>
<orderedlist>
<listitem><para>Configure an IP address on one of the interfaces of <replaceable>
node1</replaceable>:</para>
<programlisting># <userinput>/sbin/ifconfig </userinput><replaceable>interface
</replaceable><userinput>&ensp;inet </userinput><replaceable>ip_address</replaceable><userinput>
&ensp;netmask </userinput><replaceable>netmask</replaceable><userinput>&ensp;up
</userinput></programlisting>
<para><replaceable>interface</replaceable> is the interface to be used access
the node. <replaceable>ip_address</replaceable> is an IP address for <replaceable>
node1</replaceable>. This IP address is used throughout this procedure. <replaceable>
netmask</replaceable> is the netmask of the IP address.</para>
</listitem>
<listitem><para>From <replaceable>node3</replaceable>, <command>ping</command>
the IP address used in Step&nbsp;1                 
<!-- This hardcoded numeric reference should be updated. -->
:</para>
<programlisting># <userinput>ping -c 2 </userinput><replaceable>ip_address
</replaceable>
PING 190.0.2.1 (190.0.2.1): 56 data bytes
64 bytes from 190.0.2.1: icmp_seq=0 ttl=255 time=29 ms
64 bytes from 190.0.2.1: icmp_seq=1 ttl=255 time=1 ms

----190.0.2.1 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1/1/1 ms</programlisting>
</listitem>
<listitem><para>Enter this command on <replaceable>node1</replaceable> to
shut down the interface you configured in Step1                 
<!-- This hardcoded numeric reference should be updated. -->
:</para>
<programlisting># <userinput>/sbin/ifconfig </userinput><replaceable>interface
</replaceable><userinput>&ensp;down</userinput></programlisting>
</listitem>
<listitem><para>On <replaceable>node2</replaceable>, enter this command to
move the IP address to <replaceable>node2</replaceable>:</para>
<programlisting># <userinput>/sbin/ifconfig </userinput><replaceable>interface
</replaceable><userinput>&ensp;inet </userinput><replaceable>ip_address</replaceable><userinput>
&ensp;netmask </userinput><replaceable>netmask</replaceable><userinput>&ensp;up
</userinput></programlisting>
</listitem>
<listitem><para>From <replaceable>node3</replaceable>, <command>ping</command>
the IP address:</para>
<programlisting># <userinput>ping -c 2 </userinput><replaceable>ip_address
</replaceable></programlisting>
<para>If the <command>ping</command> command fails, gratuitous ARP packets
are not being accepted and re-MACing is needed to fail over the IP address.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2 id="LE15769-PARENT">
<title id="LE15769-TITLE">Example IP Address Configuration</title>
<para>For this example, you are configuring an IP address of 192.26.50.1.
This address has a network mask of 255.255.255.0, a broadcast address of 192.26.50.255,
and it is configured on interface eth0.</para>
<para>In this example, you are also configuring an IP address of 192.26.50.2.
This address also has a network mask of 255.255.255.0, a broadcast address
of 192.26.50.255, and it is configured on interface eth1.</para>
<para><indexterm id="ITplanning-18"><primary>configuration parameters</primary>
<secondary>IP address</secondary></indexterm> <xref linkend="LE73415-PARENT">,
shows the Linux FailSafe configuration parameters you specify for these IP
addresses. </para>
<table frame="topbot" id="LE73415-PARENT">
<title id="LE73415-TITLE">IP Address Configuration Parameters</title>
<tgroup cols="3" colsep="0" rowsep="0">
<colspec colwidth="181*">
<colspec colwidth="153*">
<colspec colwidth="152*">
<thead>
<row rowsep="1"><entry align="left" valign="bottom"><para>Resource Attribute
</para></entry><entry align="left" valign="bottom"><para>Resource Name: 192.26.50.1
</para></entry><entry align="left" valign="bottom"><para>Resource Name: 192.26.50.2
</para></entry></row>
</thead>
<tbody>
<row>
<entry align="left" valign="top"><para>network mask</para></entry>
<entry align="left" valign="top"><para>255.255.255.0</para></entry>
<entry align="left" valign="top"><para>255.255.255.0</para></entry>
</row>
<row>
<entry align="left" valign="top"><para>broadcast address</para></entry>
<entry align="left" valign="top"><para>192.26.50.255</para></entry>
<entry align="left" valign="top"><para>192.26.50.255</para></entry>
</row>
<row>
<entry align="left" valign="top"><para>interface</para></entry>
<entry align="left" valign="top"><para>eth0</para></entry>
<entry align="left" valign="top"><para>eth1</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
<sect2>
<title>Local Failover of IP Addresses</title>
<para>You can configure your system so that an IP address will fail over to
a second interface within the same host, for example from eth0 to eth1 on
a single node. A configuration example that shows the steps you must follow
for this configuration is provided in <xref linkend="localfailover-of-ip"></para>
</sect2>
</sect1>
</chapter>
<?Pub *0000035588>