于 2008年10月28日 01:10, James Carlson 写道: > yifan xu writes: >> The VRRP project team invites you to review our current design. The document >> could >> be found at: >> >> http://www.opensolaris.org/os/project/vrrp/vrrp_design.pdf > > I'll skip over most of the SMF instance discussion now happening on > [EMAIL PROTECTED], but I think that thread needs to be redirected > here, so that the networking community can comment on it. The open > review isn't complete without it. (You have my permission to resend > any of my messages on that topic to the list if you need.)
Thanks Jim. I'm moving the discussion here. I'm quoting your comments below with my responses. 于 2008年10月27日 21:40, James Carlson 写道: > Those two issues are: > > 1. Whether and how to factor out VRRP into SMF > > 2. Storing parameters in SCF > > It is not necessary to solve (2) in order to solve (1). In fact, if > you go back and read the original Greenline case, you'll see that they > didn't expect "all" system configuration information to end up inside > SCF. > > Things that appear as simple properties for a service are expected to > end up in SCF. Those that have structure to them or are otherwise > complex are expected to live in configuration files. > > The issue that I wanted to raise (and that I think Darren was > previously discussing) was actually just (1). That is: is it useful > to factor VRRP as a service into SMF, regardless of where the > configuration parameters live? > > 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. > > - It allows administrators to trigger a fail-over intentionally for > maintenance or testing. I can do "svcadm -st disable > vrrp:apache2" first to cause the network to fail over to my > backup. After failing over, I then do maintenance on the local > system. When I'm done, I bring it back up. I agree that issue (1) is the real issue, and issue (2) is actually implementation details. We should focus on (1) in the design review. It looks natural to map a VRRP instance/group to a SMF instance. Note, a VRRP group as a whole should also map to a SMF instance in this way. And the two advantages Jim listed are valid. But the biggest problem, I think, is the inconsistence of the admin interface presented to the users. In the current design, there's only one VRRP SMF service instance, and it uses a single configuration file, whose location is the only SMF property of the VRRP SMF service. All VRRP related operations are done by using the "vrrpadm" tool. If each VRRP instance/group is mapped to a SMF instance, how to do the operations? 1. To create a VRRP instance/group. First need to create a new SMF instance using "svccfg -s network/vrrp <vinst_name>". Then the user needs to use "svccfg -s network/vrrp:<vinst_name> setprop ..." to set all properties of the VRRP instance. Then "svcadm refresh". Finally the user issue "svcadm enable ...", which calls "vrrpadm create ..." to create the VRRP instance. 2. To destroy a VRRP instance ==> "svcadm disable" (which calls "vrrpadm remove"), then "svccfg ... delete". 3. To modify some VRRP parameters ==> "svccfg setprop" then "svcadm refresh" (which calls "vrrpadm modify"). 4. To register/unregister external executables ==> "svccfg setprop" then "svcadm refresh" (which calls "vrrpadm register"). Note, "svccfg setprop" can modify all SMF properties, which map to VRRP properties, but will lead to different VRRP operations. Changes to VRRP priority, adv interval, accept mode, etc, will trigger "vrrpadm modify"; changes to external executables will trigger "vrrpadm register"; changes to "fatal" properties such as VRID, ifname, primary IP address will require a restart of this VRRP instance. 5. To show the run time attributes of VRRP instances/groups, "vrrpadm show" is needed; no corresponding SMF commands to do this. (And we can expect more operations in the future which cannot be handled directly by SMF commands.) So we can see three different types of admin interfaces for different operations: (1) Some (show) must use vrrpadm(1M) directly; (2) some (destroy) can use SMF command; (3) some (create, register, etc) should use a wrapper to encapsulate multiple SMF commands (take "create" as an example: a wrapper should contain "svccfg add", multiple "svccfg setprop", "svcadm refresh" and finally "svcadm enable"). Jim had some comments under item 5 above: > Actually, I'd encourage such an implementation to call libscf from > vrrpadm (perhaps indirectly via libvrrp), and include commands to > manipulate instances and properties in addition to just getting > status. > > Just because something is factored into SMF doesn't mean that users > need to be forced into using the svccfg command. I think the key idea is to use libscf to read some properties from SMF configuration repository, and use vrrpadm/libvrrp to get the others. Since Jim also mentioned "to manipulate instance and properties in additon to just getting status", I guess it's not just for "show", but also for other operations such as "create", where vrrpadm (via libvrrp) calls libscf to write the properties into the repository. (Is my understanding right, Jim?) This looks to me like that part of the SMF features (storing properties into SMF configuration repository) becomes part of the service that it manages, so that the service itself is unable to run by itself (i.e., not from the SMF infrastructure). I'm not quite comfortable with this. Thoughts? -- Huafeng _______________________________________________ networking-discuss mailing list [email protected]
