Quote:
Originally Posted by
mrmurdock
However the term "Boot IP" for some reason is messing with my head. Have not done HACMP since the 4.1.2.X days.
I understand the Persistent IP and the service IP just fine.
"Persistent IP" and "boot IP" means (nowadays) the same. Back then, in the times before HACMP 5.x, there were three types of addresses one of which was called "boot", but nowadays - that is, from HACMP 5.x onwards - there are only (in HACMP-speak) "service" and "non-service" (persistent) addresses.
Every adapter has a "non-service" IP which it comes up with at boot time. It will always retain this IP address as long as it is up.
For every "service" (or "resource group", which effectively means the same) there might be a "service IP", under which the service (i.e. a database) can be reached over the network.
Each resource group consists of:
1) one or more VGs, which are brought online (and their filesystems mounted) when the RG starts
2) an "application controller": this is a collection of a "start" script and a "stop" script, one of which is executed at RG going online, one when the RG goes offline
3) an optional "application monitor": a script which is executed regularly and may check (and maybe take some corrective action) for the running application
4) an optional service IP, which is added as an IP-alias when the RG has started.
For HACMP the process of starting a RG is:
- varyon VGs, ount FSes
- execute start-script of App-controller
- add service IP as IP-Alias to certain interface
- as long as RG is online: execute app-monitor regularly (if there is one)
The takeover of the RG means:
- on Node1 remove IP-Alias
- on Node1 execute stop-script of App-controller
- on Node1 umount FSes and varyoff VGs
- on Node2 execute start-procedure as described above
It is possible to configure service-IPs to be activated before (instead of the default after) mounting FSes and define certain dependency rules for RGs (like "active this RG only after the other RG is activated", etc.).
I hope this helps.
bakunin
