hi Yifan comments inline below...
yifan wrote: > 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. > > Sounds okay - my personal preference would be to have a slightly different FMRI for the daemon than for the objects it controls, but I've no idea if that's a view others might share. So what I'm thinking is something like svc:/network/vrrp-management:default ...for the daemon, and svc:/network/vrrp:inst0 ... ...for the objects the daemon manages. One reason for such a separation is that different instances implicitly share service-level properties (including dependencies). If two instances are fundamentally different things - like a daemon and a configuration object - I'd argue having them live under the same service is a bit confusing, since such sharing of configuration doesn't make sense for two different types of thing. Just my opinion though. > 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. > > This almost sounds like the SMF monitor project which has been discussed a few times here in the past (try searching the smf-discuss archives for more details). The idea of that project - which I don't believe has been started yet - is to provide more fine-grained monitoring of service state. I _think_ the idea is that an additional method - a "monitor" method - can be supplied with a given service to check its health. Maybe I'm out of date on these details though... > 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. > > I wonder - what else do these dynamic instances you're creating do? Are they just a mechanism to catch restarts of other services? If so, I wonder if it'd make more sense to catch such notifications in the vrrp daemon instead? (Having said that, I don't think there's a good way to get such notifications unless you're the delegated restarter for the service, but maybe that's changed recently though, I'm not sure). So I think the first thing I'd like to understand in a bit more details is what else these dynamic instances (such as the one handling apache you describe above) need to do, i.e. what do their start/stop methods do if anything? If these instances are just a mechanism to catch restarts of the services that VRRP monitors, I'm not so sure that introducing them is the right way to go. Thanks! Alan > Yifan > > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
