[Freeipa-devel] Locations design v2: LDAP schema & user interface

Tue Feb 23 11:43:17 UTC 2016

On 23.2.2016 11:00, Jan Cholasta wrote:
> Hi,
> 
> On 19.2.2016 16:31, Simo Sorce wrote:
>> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote:
>>> On 4.2.2016 18:21, Petr Spacek wrote:
>>>> On 3.2.2016 18:41, Petr Spacek wrote:
>>>>> Hello,
>>>>>
>>>>> I've updated the design page
>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism
>>>>>
>>>>> Namely it now contains 'Version 2'.
>>>>
>>>> Okay, here is the idea how we can make it flexible:
>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation
>>>
>>> Hello,
>>>
>>> I'm thinking about LDAP schema for DNS locations.
>>>
>>> Purpose
>>> =======
>>> * Allow admins to define any number of locations.
>>> * 1 DNS server advertises at most 1 location.
>>> * 1 location generally contains set of services with different priorities and
>>> weights (in DNS SRV terms).
>>> * Express server & service priority for each defined location in a way which
>>> is granular and flexible and ad the same time easy to manage.
>>>
>>>
>>> Proposal
>>> ========
>>> a) Container for locations
>>> --------------------------
>>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>>
>>>
>>> b) 1 location
>>> -------------
>>> Attributes:
>>> 2.16.840.1.113730.3.8.5.32     idnsLocationMember
>>> Server/service assigned to a DNS Location. Usually used to define 'main'
>>> servers for that location. Should it point to service DNs to be sure we have
>>> smooth upgrade to containers?
> 
> Services always live on a host (call it server or not), so IMO it makes sense
> to point to servers.

Fine with me. We just need something which will be able to accommodate
containerization without upgrade headache.

Do I undestand correctly that 1 container is going to have 1 host object with
one service object inside it?

Like:
cn=container
- cn=DNS, cn=container
?

>>> 2.16.840.1.113730.3.8.5.33     idnsBackupLocation
>>> Pointer to another location. Sucks in all servers from that location as one
>>> group with the same priority. Easy to use with _default location where all
>>> 'other' servers are used as backup.
>>>
>>> These two attributes use sub-type priority<number> and relativeweight<number>.
>>> This is the only way I could express all the information without need for
>>> separate objects.
> 
> I don't see the benefit here. What is wrong with separate objects? Why is it
> necessary to reinvent the wheel and abuse attribute sub-types for this, losing
> schema integrity checks provided by DS and making the implementation more
> complex along the way?

AFAIK Simo did not like separate objects because we could not use referential
integrity plugin to prune references to removed servers.

This can surely be done in framework, I do not insist on subtypes.

Talk is cheap, show me your schema :-)

>>> Object classes:
>>> 2.16.840.1.113730.3.8.6.7      idnsLocation
>>> MAY ( idnsLocationMember $ idnsBackupLocation )
>>>
>>>
>>> 1st example:
>>> Location CZ:
>>> - servers czserver1, czserver2
>>> - priority=1
>>> - relative weight = 50 % each
>>> - if both CZ servers fail, use servers in location UK as backup (priority 2)
>>> - if all CZ and UK servers fail, use servers in location US as backup
>>> (priority 3) - servers on the other continent are used only as option of last
>>> resort
>>> DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>> objectClass: idnsLocation
>>> idnsLocationMember;priority1;relativeweight50:
>>> cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsLocationMember;priority1;relativeweight50:
>>> cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsBackupLocation;priority2:
>>> cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsBackupLocation;priority3:
>>> cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>>
>>> Location UK:
>>> - servers ukserver1, ukserver2
>>> - priority=1
>>> - server ukserver1 is a new beefy machine so it can handle 3 times more load
>>> than ukserver2, thus relative weights 75 % and 25 %
>>> - if both UK servers fail, use servers in location CZ as backup (priority 2)
>>> - if all CZ and UK servers fail, use servers in location US as backup
>>> (priority 3) - servers on the other continent are used only as option of last
>>> resort
>>> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>> objectClass: idnsLocation
>>> idnsLocationMember;priority1;relativeweight3:
>>> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsLocationMember;priority1;relativeweight1:
>>> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsBackupLocation;priority2:
>>> cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsBackupLocation;priority3:
>>> cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>>
>>> Location US:
>>> - servers usserver1, usserver2
>>> - priority=1
>>> - relative weight = 50 % each
>>> - if both US servers fail, use servers in location CZ and UK as backup
>>> (priority 2) - it is over ocean anyway, so US clients will not make any
>>> difference between CZ and UK locations
>>> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>> objectClass: idnsLocation
>>> idnsLocationMember;priority1;relativeweight50:
>>> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsLocationMember;priority1;relativeweight50:
>>> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsBackupLocation;priority2:
>>> cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsBackupLocation;priority2:
>>> cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>>
>>>
>>> Resulting DNS SRV records (generated by FreeIPA framework). Please note that
>>> only numbers in SRV records matter only relatively. Priorities work as group,
>>> weights are relative only inside the group. Absolute values above are used
>>> only in algorithm which generates SRV records:
>>> Location CZ:
>>> _kerberos._udp SRV 1 50 czserver1
>>> _kerberos._udp SRV 1 50 czserver2
>>> _kerberos._udp SRV 2 75 ukserver1
>>> _kerberos._udp SRV 2 25 ukserver1
>>> _kerberos._udp SRV 3 50 usserver1
>>> _kerberos._udp SRV 3 50 usserver2
>>>
>>> Location UK:
>>> _kerberos._udp SRV 1 75 ukserver1
>>> _kerberos._udp SRV 1 25 ukserver1
>>> _kerberos._udp SRV 2 50 czserver1
>>> _kerberos._udp SRV 2 50 czserver2
>>> _kerberos._udp SRV 3 50 usserver1
>>> _kerberos._udp SRV 3 50 usserver2
>>>
>>> Location US:
>>> _kerberos._udp SRV 1 50 usserver1
>>> _kerberos._udp SRV 1 50 usserver2
>>> _kerberos._udp SRV 2 250 czserver1
>>> _kerberos._udp SRV 2 250 czserver2
>>> _kerberos._udp SRV 2 375 ukserver1
>>> _kerberos._udp SRV 2 125 ukserver1
>>>
>>>
>>> 2nd example:
>>> - 10 locations with 4 servers each
>>> - we want to have use only 1 server from each location as backup so clients
>>> will not spend a lot of time while attempting to contact cut-off branch (e.g.
>>> when remote WAN link is down)
>>> -> use only idnsLocationMember attribute instead of idnsBackupLocation
>>> attribute
>>>
>>>
>>> Fancier combinations are possible with this schema. I assume that fancy things
>>> will be necessary later on if/when IPA supports large topologies.
>>>
>>>
>>>
>>> c) Assigning DNS servers to locations:
>>> Each DNS server can advertise at most 1 location as 'default' to its clients.
>>>
>>> Attributes:
>>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation
>>> Pointer to a idnsLocation object. On DNS service object / external server.
>>> Single-valued.
> 
> IMO this should be attribute of server rather than service,
> given that
> idnsLocationMember points to servers rather than services.

The main reason is why idnsAdvertisedLocation is tied to DNS service is that a
IPA server without a DNS server cannot advertise anything, so the attribute
does not make sense on all server objects.

Also, the attribute can be (in future) used on external DNS server. The
external server is not going to be an IPA server, it will be just
representation of a DNS endpoint. Likely this external DNS server is not going
to reside in cn=masters at all. It might be in cn=dns so somewhere else.

So it seemed to me that it would be good to tie this to 'DNS endpoint' object
instead of IPA server object.

Anyway, I do not insist on this. It can be on the IPA server if you want, but
we will need additional checks to make sure that DNS service is always present
on the IPA server in question. Negotiate with Simo :-)

An alternative is to add idnsAdvertisedLocation to location object but then we
need extra search to find out which location is advertised by particular
server (or use yet another instance of memberOf plugin ...).

> Or, if there is an actual use case for different DNS services (internal or
> external) on the same server to reside in different locations, change
> idnsLocationMember to point to services rather than servers.
> 
>>>
>>> Example:
>>> DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>>> idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>>
>>> When we start integrating with external DNS we will need a special object to
>>> represent external DNS servers. We can deal with that later on.
>>>
>>>
>>> d) User interface
>>> This is the hardest thing.
>>>
>>> First rough idea can be seen on
>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI
>>>
>>> I would think about CLI when we agree on WebUI, IMHO it will be easier.
>>>
>>>
>>> What do you think? I'm waiting for your comments ;-)
>>
>> I am thinking about it, on the surface it all looks quite reasonable.
>> I think the UI is alittle messy, I wonder if we want to expose lower
>> level concepts as priority and groups, or if we just want to allow users
>> to set an order in the UI and then let the framework come up with weight
>> an priority numbers to assign.
> 
> +1, it seems to me that locations are a rather standalone concept, so why tie
> them to DNS like this?

I do not see the tie to DNS in the user interface except the terminology I used.

Priority (grouping) and weights (load distribution inside one group) are not
DNS things, these are fail-over and load balancing concepts.

Look at manual for load balancers from F5 [1]:
* term 'pool' = same thing as our 'priority groups', i.e. group of services
with equal priority
* term 'weight' (sometimes also 'ratio weight') = the exactly same sense

I'm certainly open to terminological changes to make it more accessible, it
would make sense to use the same terms as load balancer vendors.

[1]
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html

>> Maybe have a way in the CLI to override the decisions of the framework
>> and set explicit weights ?

I was thinking about this as well.

Speaking of weights, we can easily default to the same weight for all servers
by default so admins do not need to bother unless they want/need.

Priority groups are harder because they express metric based on:
* communication costs,
* fail-over requirements,
* other political requirements in given deployment.
These are hard things to see from layer 7.

Theoretically we can provide ipa-advise plugin to generate some initial set of
groups but this is going to be complicated and error prone.

E.g. we can use ICMP ping or LDAP base DN search timings and use some
clustering algorithm to create priority groups using measured values.
This could work if we use some smart-enough clustering algorithm (= AI
library). And of course, we would have to do measurements from at least one
server in each location to properly define groups for each location ...

It is not that easy as it might seem and I do not see an easy solution.

Maybe we should take evolutional approach:
Implement this 'expert' UI which exposes groups & weights to the user first.
(It will be necessary for special cases anyway.) When this is done, we can
play with it, do some usability testing (we can ask RH IT to see if it makes
sense to them, for example.)

Later we can extend this with a 'simple' variant of UI based on feedback or
add the generator). This does not even need to happen in the same release.

IMHO it would be better to start with something and refine it later on because
right now we are just hand-waving and have no idea what users actually do and
want.

-- 
Petr^2 Spacek