Friday, October 17, 2008
Configuring A Basic HACMP Cluster On AIX Unix
Hey there,
Today we're going to go back to the AIX well (which we haven't visited since our fairly-old post on working with AIX LVM . That post links back to a bunch of other posts in the series, but it "has" been about 3 months since we've touched on the AIX OS, which is grossly disproportionate to the amount of attention Solaris, Linux and Open Source Software get. Perhaps, someday, I'll work on it enough that I'll feel more comfortable digging into its guts. ...figuratively, of course ;)
This little how-to post isn't meant to cover all the angles of cluster setup and configuration that there are to cover. If it were, that would be (aside from slightly-more-than-presumptuous) a long long long post. Your children would have children while you tried to remain interested ;) This is a simple little "get started" guide and only meant for a simple 2 node cluster. If you want to get fancier, visit IBM's HACMP Knowledge Base where they've got more documentation than you could ever wish for. Check the bottom of the post for some other good resource sites.
First things first (before we get to step one), as with any other sort of cluster setup (VCS, SunCluster , etc) you'll need to determine what you want from your cluster. That's beyond the scope of this post (or the other ones we just referenced), but you should have a clear plan of attack. Know what you want and everything you can think of that it might take to get there (in this case 2 nodes for redundancy and uptime - On the flipside, what we're looking to do here, which is also very important, is to just set up the basics of our cluster and disk heartbeats. The network is up and running, cabled and doing well. This is one "huge" assumption, but it just means less for us to have to soak up in one sitting :) It's always a good idea to write a list. ...unless you're in the habit of losing your lists, in which case you should keep everything in your head where you'll retain most everything until you lose "it." (And you can take that either way ;)
NOTE: We're going to be running through this using an AIX CLI utility called "smit." Of course, it's more of a TUI (Terminal Based User Interface) than real CLI, but, while you're using it, you can make it show you the underlying commands it's running with judicious use of the F6 key. Copy and paste all that stuff into a script and amaze your friends :)
1. Choose one node from which to do your configuration. It can be either of the two we're going to use (host1 or host2). It's important that you stick with your choice, though.
2. Check for any possible HACMP configuration already on the host (just in case) by using smit (called as smitty):
NOTE: For this how-to, we'll represent menu choices (drill-down) using tabs for each level down, and set them in boldface type. Oh, yes, and step two will fail if there are no cluster components to remove. It'll make you feel all warm and cozy inside, though ;)host1 # smitty hacmp
Extended Configuration
Extended Topology Configuration
Configure an HACMP Cluster
Remove an HACMP Cluster
3. Then, proceed to configure the topology of your cluster (For us, this simply means two nodes sharing a heartbeat address)host1 # smitty hacmp
Extended Configuration
Extended Topology Configuration
4. Here you have a few different things to do (under Extended Topology Configuration):
<-- You'll need at least two hosts to create a cluster and you can't have more than one cluster per pair of hosts (Only 1 for 2). Configure an HACMP Cluster
<-- Be sure to use your boot IP address in the "communication path" field. We haven't gotten to the virtual IP yet Configure HACMP Nodes
5. Now, on each node of your cluster (host1 and host2), be sure to start the clcomdES service if it isn't running already (might be on host1 since we're configuring the cluster on it, but shouldn't be on host2)
To check for it, type:
host1 # lssrc -s clcomdES
To start it , type:
host1 # startsrc -s clcomdES
6. Now go back up one level (to Extended Configuration) and run through these options (You can just ignore the ones we don't mention):
<-- Add your public, or virtual Ethernet network information here. Be sure to configure the subnet mask appropriately and set "Enable IP Address Takeover via IP Aliases" equal to "yes." Also, unset (leave or make blank) the "IP Address Offset for Heartbeating over IP Aliases" setting. Configure HACMP Network
<-- if you find any old, or strange, node names in here, delete them. They're probably from a previous setup. You can keep them, but they might cause you headache later on. Note that you'll generally only see this type of behaviour if the machine has been cloned. You can also manually define interfaces here (if you choose), but you should have already done that under "Configure HACMP Network" above. If you need to add any interfaces here, just choose "Add Pre-defined interface" and go to town :) Configure HACMP Interfaces and Devices
<-- This should be the address associated with your host's DNS name (not the cluster's DNS name!). Configure HACMP Persistent Node IP Label/Address
7. Now add service addresses for all of the service types you want to host on your cluster (Services are generally disk, network, etc - resources you want to share within your cluster and keep highly available) Add Service addresses for each of the services you want to host - we're only dealing with disk and IP here.host1 # smitty hacmp
Extended Configuration
Extended Resource
Configuration HACMP Extended Resources Configuration
Configure HACMP Service IP Labels/Addresses
Here, add a volume group solely dedicated to providing disk-based heartbeat! Name it whatever you want, like "host1-diskhb" and make sure it's type is set to "Enhanced-Capable Concurrent Volume Group." You won't ever actually need this volume group for anything (disk storage, etc, I mean), but making it this type of volume prevents it from being discovered. You "Do Not" want to share your host's disk heartbeat device!
8. Now, proceed to configure your disk heartbeat network (this part practically does the work for you. Just keep stabbing at those keys ;)host1 # smitty hacmp
Extended Configuration
Extended Topology Configuration
Configure HACMP Networks
Add a Network
Discovered
host1-diskhb
9. Next, add devices to our disk heartbeat network:host1 # smitty hacmp
Extended Configuration
Extended Topology Configuration
Configure HACMP Communication Interfaces/Devices
Add Communication Interfaces/Devices
Add Pre-defined Communication Interfaces and Devices
Communication Devices
Choose the (hopefully, at this point) only heartbeat network available :) Name the device whatever you want (again, we'll go with host1-diskhb), supply the logical path to the device (if necessary) and supply the name of one of your nodes when required to. Note that this will trigger an error the first time you run it (This is perfectly normal!). It will state the obvious in a slightly different manner, but your error message will basically say that you can't have only one device defined, since two are required). The simple fix: Run step 9 again exactly, except pick your other node's name when required to. Now you have two members in your disk heartbeat network.
10. Now, set up your basic networking:host1 # smitty hacmp
tcpip
Further Configuration
Static routes
Add a Static Route
Make sure to set your "Destination Type" to "net," your "Destination Address" to "default" and set the "Default Gateway" to the IP address of your default router (Same as when you set up your persistent host address in step 4 - Note that it's not shown in the documentation here, but will be there if you follow the smitty-steps down to the correct menu level :)
11. And you're set. Just for caution's sake, you should do some simple testing by running:host1 # smitty hacmp
Extended Configuration
Extended Verify and Synchronization
Accept the defaults here and your changes and setup will be verified and synchronized with every node in your cluster (In our case today, the "other one" ;)
And you're good to go :)
Remember, our little experiment here was a very quick and dirty how-to with very limited scope. If you want an equally expedient, but more comprehensive and wide-ranging, look at setting up HACMP fast, check out TriParadigm's HACMP Configuration Page . It's a lot better than this one, but may be too much if you're just getting started (?) :)
Cheers,
Mike
Please note that this blog accepts comments via email only . See our Mission And Policy Statement for further details.
Friday, December 7, 2007
The Shebang Line: An Introduction to Porting Shell to Perl
This is actually going to be, over time, a series of posts because it would be impossible (especially with my writing style) to cover every aspect of porting shell script to Perl in one posting (There may be some unusual or vague aspects that won't be covered at all, but, by that point, you will understand enough to be able to find the answers through trial and error, or judicious use of various search engines ;)
In this post we're going to cover one of the very basics. By "very basic," I mean a brief discourse on the "shebang" line. There's so much to mine in that seemingly obvious topic that it'll take far too long for me to crank out anything more today. After this, in a future post, we'll follow up with how to properly format a standard line of code, the three common variable types and how they are created and accessed in either language.
The beginning is complicated enough, when you really look at it. The "shebang" line (It's referred to as this because the exclamation point is referred as a "bang," for reasons which I don't completely understand, and the pound symbol is... I honestly can't come up with any intelligent reason for the other part of the name ;). I still call it the "pound bang" line.
In shell and in Perl, the "shebang" lines serve the same purpose. In fact, the "shebang" line is an entity unto itself. Its use extends beyond shell and/or Perl scripting and is a construct used for many purposes. The main thing the "shebang" line does is instruct the shell that you're using (you can be logged into csh, tcsh, ksh, sh, zsh or whatever shell you like to work in) to invoke a specific "command" to initiate the script with. It is customary to make this the full path to the shell in which you are writing your script, or the full path to the Perl binary, but it doesn't have to be (although, what you are asking the "shebang" to execute should be directly connected to it. No space between "#!" and "/bin/sh." Lots of shells nowadays will consume this blank space for you. Some older versions of shells are far less forgiving). For instance, our two basic examples are these:
#!/bin/sh <--- Tells the shell's interpreter to invoke "/bin/sh" in a subshell and run all the commands in the script in that subshell.
#!/usr/bin/perl <--- Tells the shell's interpreter to invoke "/usr/bin/perl" in a subshell and run all the commands in the script in that subshell.
This doesn't mean you can only use one shell or even one version of Perl within the same script, but that's outside the scope of today's post. So, to illustrate what I mean when I say the "shebang" line instructs the shell to invoke a specific "command," I mean just that. If you wrote a script, in the editor of your choice, and made the first line:
#!/bin/rm
the default action of the shell would be to delete the file and then run all the following commands (reading the script - in both shell and Perl - left to right, from top to bottom) until the script ended. If this seems counterintuitive, which it did to me at one point, that's normal. This is a good example of what goes on "under the covers" when you execute a script in your Unix or Linux shell. In the above example (as in the previous two, and all others), the entire script is read into memory before the "shebang" line is executed. That way, when your script with "#!/bin/rm" at the top is executed, the following happens:
1. The script is read into memory.
2. The script is executed.
3. The first line ("shebang") instructs the script to delete itself.
4. The rest of the script is run out from memory.
5. When the script is done, everything you instructed the script to do has been completed (provided it's at all possible in the shell you're executing it from (since the default subshell will be a subshell of the shell you're in when you execute the script) and the script is no longer there! In actuality, the script disappears before the code is executed from memory, so your script is gone, sometimes, long before your script finishes! For example, let's look at the following script:
#!/bin/rm
# /export/home/user/MyScript.sh c) 2007 MT - xyz.com
#
# Pounds are considered comment lines in both shell and Perl
# You can include interesting notes or whatever you like behind
# the pound sign and the script won't execute it. Even the "bang"
# ! has no special significance after the first line of the script
# except in special situations where you're invoking another
# subshell or another "shebang."
# Blank lines are also not acted upon in either shell or Perl.
sleep 500000000000000000
Now, if we were to run that script at the command line (after doing a chmod to 700 so that we, the user, have full read, write and execute permissions on it) we would end up sitting at a hung prompt, waiting for the sleep command to finish for a very long time. In this case that's good, because it gives us ample opportunity to login to the same machine again, on a different terminal, and have a look at what's going on:
This is an example of what our first terminal session would look like:
user# cd /export/home/user
user# ls -a
. .. .profile MyScript.sh
user# /bin/bash ./MyScript.sh
user#
Now, if we log on to the machine again, using a different terminal (or another connection, window; however you want to put it) we'd see this:
user# cd /export/home/user
user# ls -a
. .. .profile
user#
Yet - we can check that the script is still running, which it is:
user# ps -ef|grep "[M]yScript.sh
user# user 6523 6521 0 15:12:03 ? 0:14 ./MyScript.sh
And thus is all that explained. You can use the "shebang" line to run any command you want. Try it out. Be careful, because you can do some incredibly awful things if you're not careful. Luckily, the shell will protect you against doing something like this (but the way it reacts is specific to the command invoked, so some programs, like Perl, can accept a switch after the command line, like - #!/usr/bin/perl -w):
#!/bin/rm -rf /export/home/user
as it only executes the full qualified "rm" command directly attached to the "shebang." If you quote the entire command to try and get around it that way, it will try to interpret the entire line as one command and shoot you an error like:
ksh ./MyScript.sh: not found
Hopefully, this has been a somewhat informative and easy to understand introduction to the relationship between the shell and Perl. I understand that this bedrock we've discussed today isn't really specific to either of them, although it applies to both. But, as an old saying goes: It's usually best to start with the first floor (or the basement) when you're putting up a building ;)
Best Wishes,
, Mike
Thanks to Michael Pelletier, Merrimack NH for this perfect explanation of what that pound symbol means!
It's a "sharp" symbol in music notation:
http://en.wikipedia.org/wiki/Sharp_(music)
That's why the "C#" language is pronounced "C sharp," not "C plus plus plus plus:"
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)
Enjoy this little tidbit of mostly useless knowledge. I pronounced it "pound bang" for maybe 20 years.
linux unix internet technology
affiliate program