于 2008年10月28日 13:10, Huafeng Lu 写道: > I think it is. SMF potentially solves some interesting issues, > including: > > - It allows administrators to specify what applications are the > dependencies for VRRP's control of an address. As a user, I can > add a dependency in my http:apache2 instance saying that > vrrp:apache2 should not come on-line unless Apache is running. If > the server fails, the system takes vrrp:apache2 off-line, and we > get the expected fail-over.
Hi, Jim, The dependency can be considered some kind of "health check" mechanism when VRRP is used to protect a service. I think it's the biggest advantage of factoring VRRP into SMF. When VRRP is used to handle host failure (the "standard" goal of VRRP, as specified in the RFC), no dependency is needed. But there's a problem. Take the http service as an example. As you pointed out, vrrp:apache2 depends on http:apache2, so VRRP should run after the web server is started. On the other hand, VRRP is used to protect the the VRIP that is shared by the master and backup hosts. Before VRRP is running, the VRIP may not appear on the host, so the web server application may not be able to run. (Some application may bind to INADDR_ANY, but we cannot assume how the applications are designed.) Note, in most cases, people will use a real IP address that is on the master host as the VRIP, so the application may run on the master. But it's also possible that the VRIP is not actually on either host. Further, the application should run normally on both hosts (whether backup or master), and when the backup becomes master, the new-master can take the role naturally. But the VRIP can be on only one of the hosts at a given time. So even VRRP runs before the application starts, it won't work. A possible solution is to register external scripts to start the application when VRRP enters the MASTER state, and to stop the application when it leaves. But this looks too cumbersome. So it looks like VRRP is not suitable to protect such local services. Thoughts? Thanks. -- Huafeng _______________________________________________ networking-discuss mailing list [email protected]
