On 03/12/09 12:13, James Carlson wrote:
> michael schuster writes:
>
>> James Carlson wrote:
>>
>>> Michael Schuster writes:
>>>
>>>> * import/export: the initial requirement was to have a means to take the
>>>> current configuration of the load balancer ("ilbadm export <file>"),
>>>> transport it to another machine by whatever means and re-apply ("ilbadm
>>>> import <file>") it there.
>>>>
>>>> Q1: Would people agree that this requirement makes sense?
>>>>
>>> It's a little surprising to me. It sounds a bit like you're
>>> reinventing "svccfg export" and "svccfg import," and I'm not sure why
>>> or how far down that path you really want to go.
>>>
>> that would imply that we're storing the information you're referring to
>> within the SMF framework ... which is not the case. As of now, all SMF does
>> is start and stop ilbd, maybe store the location of the persistent config
>> (file).
>>
As far as I understand, svccfg import /export, is used to import/export
a SMF manifest file. So I think in asking the above question, you are
assuming that configuration details of ILB ( VIP address, lb algorithm,
server group details including server IP addresses, health check details
) are all part of the SMF manifest. Is that correct?
If yes, what would be the benefit of such a model over our current
design( in our model the configuration details are not kept in SMF, but
in a persistent config file which ilbd/or ilbadm reads in when the ILB
service is invoked). SMF does not provide any means to display the
statistics of a service. For that the admin has to use ilbadm. Given
that, it would easier for a user to use one interface to view, modify
ILB features than have two things to learn ( ilbadm and svccfg)
> t now),
> I expect you'll get similar questions about your configuration
> mechanism.
>
> The more you replicate SMF functionality into the design, the more
> likely it is that someone will ask why that's necessary.
>
>
>>> Should ilbadm have its own profile mechanism?
>>>
>> what exactly do you mean by that?
>>
>
> SMF has 'profiles' for basic service configuration. They're being
> enhanced now to provide a lot more control over services through the
> profile mechanism, and this will be used (in turn) by NWAM to set up
> services on systems, and to switch between sets of services when
> changing "location."
>
> In addition, I believe the enhanced profile mechanism will be a part
> of how we intend to provide install-time configuration for enterprise
> types of deployments.
>
For ILB phase 1 project we will not be providing any basic service
configuration. The admin will be required to build his config from
scratch. User experience and feedback from ILB Phase 1 , may result in
a basic service configuration down the road, but there are not plans to
have this in Phase 1
> If ilbadm is being designed with its own configuration management
> repository, and if we end up with more uses for the enhanced profiles,
> then it may end up needing to support something like this.
>
>
>>> What about
>>> customization at install time (as with jumpstart scripts)? Snapshot
>>> and rollback?
>>>
>> has not been considered.
>>
>
> OK.
>
There are no customization at install time (as with jumpstart scripts,
snapshot, and rollback for ILB Phase 1. Although these were considered,
they were not considered to be P1 features and has deliberately been
left out of Phase 1, because customers did not list them as P1 features.
ILB phase 1 goal is to deliver basic features for a loadbalancer in DSR
and NAT mode with decent price/performance ratio that would make it a
attractive solution for a mid-range loadbalancer.
One could argue that in Solaris one would use SMF to do import/export a
service, but IMO we need to design the ILB similar to something that
admins who use other commercial and opensource load balances are used
to. If SMF had provided a ways to display virtual service stats, then it
would have made sense to abandon abandon ilbadm and simply have admin
use SMF interface to configurr, modify and display various statistics of
each LB serveice of ILB. But that is not the case.
>>> Ordinarily, protocols like this (and a file transported between
>>> machines sounds like a "protocol" to me) are made at least Committed
>>> Private, meaning that we don't document it, but we guarantee backward
>>> compatibility between versions. Is that what's intended?
>>>
>> We're trying to find out whether that's desired ... your questions seem to
>> indicate "yes" to me.
>>
>
> I don't really know what the fundamental project requirements are.
> I'm just asking the question to see if the versioning issues were
> considered.
>
>
>>> Another issue would be parameterization: if you transfer configuration
>>> data from one system to another, how much needs to be the same? What
>>> if the interfaces have different names or a different subnet is in
>>> some part of the configuration? Are users expected to edit this file
>>> in transit?
>>>
>> not initially, but again your questions indicate that that would be
>> desired, which in turn points to a well-documented format.
>>
>
> Again; I don't have a clue what the deployments of this feature look
> like, and thus I don't know the project requirements. You'll have to
> be the expert on that.
>
The contents of the config file will contain the following per virtual
service ( one config file will have hold the info for all services) :
VIP of the service
server group name
servers in a group
health checks for the service
lb algo for the service.
Note that user will have to manually configure the interfaces of the
load balancer and also configure the VIP ( via vni or Arp proxy) before
starting the service. The config file would not contain any system
specific details of a loadbalancer.
> The question I'm asking is about the detailed contents of the
> configuration data stream: is it really something that can just be
> copied from one system to another, or does it require customization
> during that process? If it's not modified in transit, what
> constraints (if any) does the user have to live with?
>
>
I can think of one case where someone wants to simply save the ILB
configuration via ilbadm export, upgrade the machine from a x4200 to a
Huron set up all the ip addresseson the system and then simply ilbadm
import and in such a scenario, no tweaking of the config content will
be needed.
Another case would be VRRP failover cases that is listed in Appendix
C of http://npt.sfbay/export/ilb/docs/ILB-design.txt. Here that primary
and backup would have the same exact config files( correct?)
Sangeeta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ilb-dev/attachments/20090316/4605a986/attachment.html>
