Hi, smf experts, I am seeking advice here on SMF interaction solutions for the VRRP project. Because of an unusual circumstance we met in the design, we end up with an unconventional solutions of the SMF configuration. We can't find any similar use in existing smf services. To ensure we are heading the right direction, I'd like to summarize the requirements and our proposal to get comments and advices from SMF expertise.
An smf service "network/vrrp:default" will be introduced to manage the vrrp daemon called vrrpd. Smf instances will be dynamically created through libscf upon each creation of vrrp instances, the fmri of which looks like "network/vrrp:inst1". The creations are achieved through a administrative tool called vrrpadm which interacts with vrrpd to manipulate vrrp instances. One desired feature of vrrp is to monitor health of network services and trigger fail-over when failures are detected. The design is that a vrrp smf instance could have dependency on a network service, say network/http:apache2, which wants to be protected, so that when it somehow fails, the vrrp smf instance turns to offline state which is expected to trigger vrrp fail-over. So far so good. The problem comes from the following facts. The VRRP provides redundancy service by dynamically assigning associated network addresses on different hosts, to guarantee that there is always a host(the Master) having the network addresses applied that can be reached by network clients. When we use a vrrp smf instance to protect a network service, the vrrp smf instance should specify the public IP address on which the network service listens as the associated IP address. If the network application needs to explicitly bind to that IP address, then it means the vrrp smf instance needs to be started first to get the associated IP addresses present before the network application gets started. It turns out to be a circular dependency between the vrrp smf instance and the network smf service. network/vrrp:inst1 <--> network/http:apache2 Our solution for this issue is to have network/vrrp:default (vrrp daemon) take the responsibility of applying all associated IP addresses for all created vrrp instances. Then the network service to be protected can have dependency on network/vrrp:default instead. network/vrrp:inst1 --> network/http:apache2 --> network/vrrp:default So the configuration sequence would be: 1) start "vrrp:default" 2) create "vrrp:inst1" with dependency on "http:apache2". Thus it will be in offline state 3) the vrrp daemon configure the associated IP address on the NIC. 4) start "http:apache2". Since the public IP is present, it gets started successfully. 5) "vrrp:inst1" will be brought to online state. The odd part is in #3. In this stage the vrrp smf instance is still in offline state, but the associated IP address belonging to it gets configured on the system. It is doable in implementation because we don't use smf properties to store the associated IP addresses but put them in a global configuration file. We are just not sure whether this is a conventional scheme for SMF interaction, and whether there are potential issues. Please point it out if you feel I am not stating the requirements and the problems clearly and I would elaborate. Here's a brief introduction for the background of the VRRP standard. VRRP (Virtual Router Redundancy Protocol) as defined in RFC3768, specifies an election protocol that dynamiclly assigns responsibility for a virtual router to one of the hosts in a LAN. A host working as a VRRP Master has some virtual IP/MAC addresses applied on the interface, and sends multicast advertisements periodly. A host working as a VRRP backup monitors the advertisements and when it finds the absence of the advertisements for an interval it takes over the responsibility of the virtual IP/MAC addresses and starts running as a Master. Comments and advices are much appreciated. Yifan
