No, a package will not be started automatically after a system reboot because the default setting for the AUTOSTART_CMCLD parameter is 0. This means the node will not join the cluster automatically. Without being part of the cluster, a package cannot be started.
A2:
The cmcld daemon does not need the actual clock time to maintain timing information. As such, the cmcld daemon does not need or use an NTP -configured time source. It is a good idea to configure all nodes in the cluster to synchronize their clocks with a reliable time source because entries in syslog.log and application logfiles will be time stamped. If all nodes are using the same time source, it makes it easier to decipher the sequence of events when analyzing entries from different logfiles from different nodes.
A3:
The actual application control file is not compiled into the application binary configuration file; only the name of the file is compiled into the binary file. Consequently, we can update to the application control file without the need to subsequently run cmapplyconf . The only additional step we need to undertake is to ensure that the updated application control file is copied to all nodes in the cluster.
A4:
When using an application monitoring script, we normally do not list any application processes as Service Processes. The reason is that the application monitoring script is normally responsible for monitoring all application processes. If any application process fails, the monitoring script should detect this and take the appropriate action (normally, it will fail, causing the application to be moved to an adoptive node). The application startup routines are normally executed from the customer_defined_run_cmds function in the application control script. These routines are started up before the Service Processes in order to have the application up and running before the Service Processes commence. If this did not happen in this order, we could be in a situation where an application monitoring script was executing before the application was started!
A5:
The client software may need to be restarted. Most client software will have the intelligence built in to retry a connection for a configurable number of attempts before failing. Once the application is moved to an adoptive node, an ARP packet is sent out on the network to inform everyone on the network to flush his or her ARP cache for the IP/MAC address of the original node. When the client software tries to reconnect to the application IP address, the ARP cache will now not contain an entry for the application IP address. The IP software on the client machine will send out an ARP request to resolve the IP address to the MAC address of the new adoptive node.
