一个十分详尽的两节点aix cluster 4.3 配置过程
[table][tr][td=5,1][img=614,54]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/masthead.gif[/img][/td][/tr][tr][td][url=http://www-1.ibm.com/support/tcp/index.html][img=119,22]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navhome.gif[/img][/url][/td][td][url=http://www-1.ibm.com/support/tcp/links.html][img=121,22]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navhotlinks.gif[/img][/url][/td][td][url=http://www-1.ibm.com/support/tcp/issues.html][img=121,22]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navbackissues.gif[/img][/url][/td][td][url=http://www-1.ibm.com/support/tcp/contact.html][img=121,22]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navsubscribe.gif[/img][/url][/td][td][url=http://www-1.ibm.com/support/tcp/whitepapers.html][img=121,22]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navwhitepapers.gif[/img][/url][/td][/tr][/table][table=98%][tr][td][font=Arial Narrow]IBM Redpaper: Setting Up a Two-Node HACMP 4.3 Cluster[/font][i]This redpaper documents steps to set up a simple two-node HACMP cluster while demonstrating the solution’s benefits. The cluster can demonstrate IP address swapping or IP address takeover (IPAT), but this paper describes only IP address swapping. In this simple configuration, we do not have shared disks; this is not a problem. (Not all applications we need to make highly available use shared data.) Some companies may implement HACMP in this way just to achieve high availability on their nodes’ network interfaces. The article assumes that whoever will construct the cluster has some knowledge of AIX but not necessarily of HACMP.[/i] HACMP (high availability cluster multi-processing) is a complex product. One factor that can keep IT professionals from getting down to using HACMP may be the lack of a simple step-by-step document that would allow them to actually start working with the product. This redpaper’s purpose is to document the main steps for setting up a simple two-node HACMP cluster while demonstrating the solution’s benefits. The cluster can demonstrate IP address swapping on a single node if an adapter fails or IP address takeover (IPAT) where an entire node is lost and the other node’s standby adapter acquires the failed node’s service address; this paper, however, describes only testing the IP address swapping capability. (NOTE: Page 18 contains information about high availability concepts, documentation, and training.) Overview of Hardware and Software RequirementsHardware requirements for building the demonstration HACMP cluster are modest. Our configuration does not use shared external disk; thus, we can demonstrate only the network adapter swapping and IPAT characteristics of HACMP failover. HardwareTo construct the HACMP cluster, we employed the following: [table=98%,#cccfff][tr][td][size=2][b]Part[/b][/size] [size=1]RS/6000 desktop 350 workstationToken-Ring 16/4 busmaster adapter Type 2-2
Token-Ring Multistation Access Unit (MAU)
Token-Ring cable, d-shell to Universal Data Connector
IBM 3.7 meter serial null modem cable
[/size][/td][td][size=2][b]P/N or F/C [/b][/size] [size=1]7012-350
G2652
8228
N/A
3124[/size][/td][td][size=2][b]Quantity[/b][/size][size=1]2
4
1
4
1[/size][/td][/tr][/table]SoftwareWe used AIX 4.3.2 and HACMP 4.3 -- the latest software versions available at the time of writing -- for this experiment. ConfigurationThe cluster, which resembles the diagram in Figure 1, is sufficient to demonstrate IP address swapping on a single node if an adapter fails or IP address takeover (IPAT) where an entire node is lost and the other node’s standby adapter acquires the failed node’s service address. Since there is no shared disk in this simple configuration, more complex failover behavior ([i]e.g.[/i], of an application belonging to a resource group residing on a shared volume group) cannot be demonstrated. [img=614,531]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/hacmp1.gif[/img] In a two-node configuration such as this, the most common movement of the resource group is a cascading scenario -- resources move to the second "hot standby" node if the primary node fails. The term [i]hot standby[/i] is more appropriate than [i]idle standby[/i], as the latter implies that the secondary node is doing nothing but simply waiting for the primary node to fail -- which is incorrect. The hot standby node is often used for development. In case of a failure, the developers can be automatically logged off and put to work fixing the failed system. When the failed node recovers, it is reintegrated into the cluster, and the resources can move back to the recovered node (unless the resource group is "rotating," in which case the resources will remain on the secondary node). Not shown in the configuration diagram is a third system that could represent a client system connected to the isolated token-ring (T-R) network. This may be another RS/6000; however, any system that could telnet into one or both nodes through the service IP connection could demonstrate the effect of an adapter swap or IPAT. Building the HACMP ClusterTake the following steps to construct your two-node cluster: [list=1][*][b]Install token-ring adapters in the nodes[/b], two per node. For this setup, we added the adapters in slots 3 and 4 of each desktop 350 server.[*][b]Connect the token-ring cabling to the Multistation Access Unit (MAU)[/b]. To more easily demonstrate adapter failure (by disconnecting the cable from the MAU), label the cables according to the adapter they connect to, for example, the slot that represents tr0 (the service adapter) and tr1 (the standby adapter). Do this for each node.[*][b]Interconnect the workstations[/b] with the null modem cable between the two nodes’ serial 1 ports. This serial network will carry the keep alive (KA) packets between the nodes separately from the IP network.[*][b]Install AIX 4.3.2 on each node[/b]. Although not required, we also installed the server bundle for this experiment. You must also install the following filesets (not included in the base installation) from the AIX 4.3.2 media:[list][*]X11.vsm.rte 4.1.3.0[*]bos.adt.libm 4.3.0.0[*]bos.adt.syscalls 4.3.0.0[*]bos.data 4.3.0.0[*]bos.compat[/list][*][b]Ensure that the T-R adapter interfaces are available on each server[/b]. Issue an lsdev -Cc adapter command and verify that tr0 and tr1 are available.[*][b]Install the HACMP product[/b] via smit install_latest and select:[list][*]cluster.adt[*]cluster.base[*]cluster.cspoc[*]cluster.man.en_US[*]cluster.vsm (optional for use if you have a graphics display)[/list][*][b]Ensure that you [i]do[/i] not install these packages:[/b][list][*]cluster.hc[*]cluster.clvm[*]cluster.haview[*]cluster.man.en_US.haview[*]prpq.clvm[/list][*][b]Reboot the nodes[/b] after installing HACMP.[*][b]Check that HACMP has been installed correctly[/b] using lslpp and lppchk.[*][b]First define the standby adapter on each node[/b] with SMIT mktcpip.[list][*]On one node select tr1 and give it an IP label of arcega_tr1. The IP address should be 10.10.11.10.[*]On the second node, select tr1 and give it an IP label of europa_tr1. The IP address should be 10.10.11.20.[*]The subnet mask is 255.255.255.0. The names and IP addresses selected are arbitrary but should be descriptive. The standby IP addresses must reside in a separate logical subnet from the service IP addresses. This allows HACMP to send heartbeats across both adapters and distinguish between adapter and network failures.[/list][*][b]Then define the service adapter on each node[/b] with SMIT mktcpip.[list][*]Select tr0 on the first node; give it an IP label of arcega_tr0. The IP address should be 10.10.1.10.[*]On the other node, select tr0 and give it an IP label of europa_tr0. The IP address should be 10.10.1.20.[*]The subnet mask is 255.255.255.0.The reason for configuring the service adapter second is that the IP label associated with this interface will be considered the host name of the node. By default, AIX considers the last defined IP interface label to be the host name unless a separate host name is defined. It might be advantageous to choose an IP label that is not related to the server host name, since this name can exist on other cluster nodes during a failover.[/list]In fact, the server host name and the IP label of the primary network interface have nothing to do with each other in HACMP parlance. The fact that we customarily associate the IP label with the host name is simply because most servers are not multihomed (i.e., have only one network adapter). NOTE: For a detailed (and lively) treatment of host names, see "Brushing Up on Your TCP/IP Basics: IPv4 Addressing" in the Fall ’97 TCdigest ([url]www.ibm.com/support/tcp/fall97/brushup.html[/url])
[*][b]Create /etc/hosts and .rhosts files[/b]. Copy them to each cluster node and client in the network.[list][*]Use vi to create the files shown in Figure 2 (using your own IP labels and IP addresses as required).[/list][table=98%,#cccfff][tr][td=3,1][u][b][size=2]/etc/hosts[/size][/b][/u][/td][/tr][tr][td][size=1]10.10.11.10
10.10.1.10
10.10.11.20
10.10.1.20
10.10.1.74
10.10.1.84
10.10.1.30[/size][/td][td][size=1]arcega_tr1
arcega_tr0
europa_tr1
europa_tr0
arcega_boot
europa_boot
jupiter[/size][/td][td][size=1]#standby adapter: left node
#service adapter: left node
#standby adapter: right node
#service adapter: right node
#boot address: left node/IPAT
#boot address: right node/IPAT
#client system (on same subnet as service adapters)[/size][/td][/tr][tr][td][table=98%,#ffffff][tr][td][size=1][b].rhosts[/b] arcega_tr1
arcega_tr0
europa_tr1
europa_tr0
arcega_boot
europa_boot
jupiter[/size][size=3] [/size]
[/td][/tr][/table][/td][td=2,1][size=2](NOTE: This configuration is for mutual takeover. For hot standby, we have only a service and standby interface on the hot standby node.)[/size][/td][/tr][tr][td=3,1][b][size=2]Figure 2. The /etc/hosts and .rhosts Files Created with vi[/size][/b][/td][/tr][/table]
[*][b]Configure the RS232 network on each node. [/b][list][*]You must add a tty on /dev/tty0 (serial port 1) for each system.[*]Disable logon on the port and leave all other settings at the default.[*]After creating the tty, run the chdev -l tty0 -a ttyprog_action=off command to prevent the getty process from being spawned on the port.[/list][*][b]Test the RS232 network [/b]by issuing the stty </dev/tty0 command on one system (which should hang), then issue the same command on the other system. If the serial connection is valid, the stty attributes will be displayed on both systems simultaneously. You cannot do this test when HACMP is operational on either node because HACMP uses the tty ports.[*][b]Define the cluster topology to HACMP[/b]. This can be done on one node of the cluster, then the definition is synchronized to the other node(s). Instructions are in steps 15a through 15d.[list]15a. [b]Define the cluster name and cluster id[/b] by typing this command: smit cm_config_cluster.add[/list][list][list][*]Give the cluster a name like "cluster1" and a numerical id. We used the numerical id 1 because we defined only one cluster. Cluster names are arbitrary, used mainly to distinguish one cluster from another in more complex environments.[/list][/list][list]15b. [b]Add the node names to the cluster[/b] with the smit cm_config_nodes.add command. [/list][list][list][*]The names of our cluster nodes have been chosen to correlate with the service IP network interfaces (also the host names in this example): arcega_tr0 and europa_tr0.[*]Enter the node names in any order with a single space between the names.[/list][/list][list]15c. [b]To add adapter information to the cluster, use the[/b] smit cm_config_adapters.add [b]command[/b]. A two-node clus-ter with one TCP/IP network and one serial network will employ eight adapter definitions, so you must invoke this SMIT menu eight times, for: [/list][list][list]-two service adapters[/list][/list][list][list]-two standby adapters and two boot adapters (for mutual takeover) or one boot adapter for hot standby[/list][/list][list][list]-two serial adapters[/list][/list][list][list][*]The adapter IP label must match with an entry in /etc/hosts on each node.[*]Fill in the [i]Add an Adapter[/i] SMIT window for the service adapter, as Figure 3 shows.[/list][table=98%,#cccfff][tr][td=3,1][size=2][b][u][i]Add an Adapter[/i] Window[/u][/b][/size] [/td][/tr][tr][td][size=1]Adapter IP Label
Network Type
Network Name
Network Attribute
Adapter Function
Adapter Identifier
Adapter Hardware Address
Node Name[/size][/td][td][size=1][arcega_tr0]
[token]
[token1]
[public]
[service]
[]
[]
[arcega_tr0][/size][/td][td][size=1]<--- node’s service IP address
<--- select from list
<--- arbitrary
<--- select from list
<--- select from list
<--- defines LAA for hardware address takeover [/size][/td][/tr][tr][td=3,1][b][size=2]
Figure 3.Information for Service Adapters[/size][/b]
[/td][/tr][/table][list][*]Add the same information for the second node’s service adapter (europa_tr0).[*]Next, add each node’s standby adapter information. Change the [i]Adapter Function[/i] to standby. Use smit cm_config_adapter.add again to fill in the [i]Add an Adapter[/i] window as shown in Figure 4.[/list][table=98%,#cccfff][tr][td=2,1][u][b][size=2][i]Add an Adapter[/i] Window[/size][/b][/u][/td][/tr][tr][td][size=1]Adapter IP Label
Network Type
Network Name
Network Attribute
Adapter Function
Adapter Identifier
Adapter H/W Address
Node Name[/size][/td][td][size=1][arcega_tr1]
[token]
[token1]
[public]
[standby]
[]
[]
[arcega_tr0][/size][/td][/tr][tr][td=2,1]
[b][size=2]Figure 4. Information for Standby Adapters[/size][/b]
[/td][/tr][/table][list][*]Add the same information for the standby adapter (europa_tr1) for node europa_tr0.[*]Finally, add each node’s adapter information.[/list][/list][list][list]- Change the [i]Network Attribute[/i] to serial. [/list][/list][list][list]- Network type is rs232. The adapter IP label does not need to be present in /etc/hosts. [/list][/list][list][list]- arcega_tr0’s [i]Add an Adapter[/i] window will look like Figure 5.[/list][/list][list][table=98%,#cccfff][tr][td=2,1][u][b][size=2]arcega_tr0’s [i]Add an Adapter[/i] Window[/size][/b][/u][/td][/tr][tr][td][size=1]Adapter IP Label
Network Type
Network Name
Network Attribute
Adapter Function
Adapter Identifier
Adapter Hardware Address
Node Name[/size][/td][td][size=1]
[rs232]
[serial1]
[serial]
[service]
[/dev/tty0]
[]
[arcega_tr0][/size][/td][/tr][tr][td=2,1][b][size=2]Figure 5. arcega_tr0’s Add an Adapter Window [/size][/b][/td][/tr][/table][/list][list]15d. [b]Now synchronize the cluster topology to the other node[/b]. Do this via the smit configchk.dialog fastpath. To be able to synchronize, each workstation needs rsh (remote shell) access to the other.[/list][list][list][*]In this window, ensure that the [i]Emulate or Actual[/i]? field is set to Actual, or synchronization cannot take place.[*]NOTE that if you have not created the .rhosts file, you can create it now with the /usr/sbin/cluster/utilities cllsif -x >/.rhosts command.[/list][/list][*][b]To view the cluster topology[/b], type the smit cm_show_menu command. You can now check the topology on either node. The output displayed by each menu item is formatted in a manner similar to the cluster planning worksheets in "Appendix A" of the HACMP for AIX Planning Guide.[list][*]You can get the same information from the command line with the cllsif command, which is available once the cluster has been started.[/list][/list]Graphical UtilitiesWith clinfo running on both nodes, if you want to display a graphical representation of your current HA cluster, do the following: [list=1][*][b]On one node, start up an X window system session[/b] with the startx command.[*][b]Start the cluster information daemon[/b] on the system with the usr/sbin/cluster/clinfo -a command.[*][b]Start the cluster status monitor[/b] with the /usr/sbin/cluster/clstat command. A graphical representation of the current HA cluster is displayed.[/list]You can click on the cluster node boxes to get more information about the network interfaces defined. Basic Failover TestingNormally, there would be further configuration involved with shared volume group(s) on the cluster’s shared disks. In this simple configuration, however, we do not have any shared disks. This is not a problem, since not all applications that we may need to make highly available use shared data (for example, on a firewall). In fact, some customers may want to implement HACMP in this manner just to achieve high availability on their nodes’ network interfaces. The next section describes how to do some basic failover testing when one node’s service adapter becomes unavailable. [list=1][*][b]Using # tail of /tmp/hacmp.out, monitor the /tmp/hacmp.out file on one of your nodes.[/b][*][b]On that same node, make note of the IP addresses of the service and standby adapters and which devices they map to[/b] ([i]e.g.[/i], tr0=10.10.1.10 and tr1=10.10.11.1).[*][b]Establish a telnet session to one of your nodes (e.g., telnet arcega_tr0) from the client system.[/b] This will establish a telnet session to the service IP address on the adapter you will unplug to simulate a failure.[*][b]Disconnect the network cable from the service adapter on arcega_tr0 and watch the /tmp/hacmp.out file[/b]. After a while, HACMP should perform an adapter swap and transpose the IP addresses of your service adapter and standby interfaces.[*][b]The client system’s telnet session should have hung briefly[/b] while the IP address swap was being carried out on the node, but it should have reconnected after about 30 seconds. It may sometimes be necessary to log on again if the connection to the node hangs after the adapter swap has occurred. For IPAT, a new login session will need to be established on the failover server.[*][b]Reconnect the failed service adapter cable[/b]. The adapter should rejoin as a standby adapter. The devices will now be mapped differently (e.g., tr0=10.10.11.10 [standby] and tr1=10.10.1.10 [service]).[*][b]To get the IP addresses to revert to the adapters on which they started, repeat the above test[/b] by unplugging the new service adapter cable (the "old" cable that you may have labeled as "standby"). When this is plugged back in and reintegrated, the tr0 interface will again map to the service adapter, and the tr1 interface will again map to the standby interface. You can also cause the IP addresses to revert to their old interfaces by simply stopping HACMP on the node that had the failure and rebooting it.[*][b]Failover testing should include a node failure test.[/b][/list]HACMP can be stopped or started using the smit clstop or smit clstart fastpaths on each node. You Are on Your Way...This simple environment is sufficient to demonstrate one of the HACMP product’s most basic capabilities: the ability to make an IP address highly available. HACMP supports many other options that make volume groups on shared disk available in a similar manner, and with appropriate start and stop scripts, it is possible to make applications associated with these IP addresses highly available as well. These topics are beyond the scope of this article; however, we hope you have discovered a suitable base to begin investigating the more complex capabilities of this powerful product. For More Information[list][*][b]HACMP for AIX 4.3 Highlights:[/b] [url=http://www.rs6000.ibm.com/software/Apps/hacmp/][color=#0000ff]www.rs6000.ibm.com/software/Apps/hacmp/[/color][/url][*][b]HACMP for AIX 4.3 Documentation:[/b] [url=http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixgen/hacmp_index.html][color=#0000ff]www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixgen/hacmp_index.html[/color][/url][*][b]AIX V4.3 Base Documentation: [/b][url=http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixgen/topnav/topnav.htm][color=#0000ff]www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixgen/topnav/topnav.htm[/color][/url][*][b]AIX and RS/6000 Training: [/b][url=http://www-3.ibm.com/services/learning/global/rs6000-aix.htm][color=#0000ff]www-3.ibm.com/services/learning/global/rs6000-aix.htm[/color][/url][*][b]RS/6000 High Availability Home Page:[/b] [url=http://www.rs6000.ibm.com/solutions/ha/][color=#0000ff]www.rs6000.ibm.com/solutions/ha/[/color][/url][*][b]RS/6000 Support:[/b] [url=http://www.rs6000.ibm.com/support/][color=#0000ff]www.rs6000.ibm.com/support/[/color][/url][*][b]RS/6000 SP Product Documentation Library:[/b] [url=http://www.rs6000.ibm.com/resource/aix_resource/sp_books/][color=#0000ff]www.rs6000.ibm.com/resource/aix_resource/sp_books/[/color][/url][/list][b][i]By Scott A. Johnston
AIX - RS/6000 Specialist
IBM Canada Technical Sales/Support[/i][/b]
[/td][/tr][/table][table][tr][td][url=http://www.ibm.com/Privacy][img]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navpriv22.gif[/img][/url][/td][td][url=http://www.ibm.com/legal][img]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navlegal2.gif[/img][/url][/td][td][url=http://www.ibm.com/Search][img]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navsearch.gif[/img][/url][/td][td][url=http://www.ibm.com/Assist/][img]file:///E:/学习资料/主机/aix/ha_doc/IBM%20Redpaper%20Setting%20Up%20a%20Two-Node%20HACMP%204_3%20Cluster_files/navconibm.gif[/img][/url][/td][/tr][/table] 呵呵。。我听说一个不错的培训CCNA的是武汉清华万博。
学习CCNA只需98元。。。
[url]www.aifer.com.cn[/url]
bbs.aifer.com.cn
群：73956146
可以去看一下了解了解。。还不错哦。。
页:
[1]