On 02/19/2016 04:31 PM, 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?

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.


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.

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.
Maybe have a way in the CLI to override the decisions of the framework
and set explicit weights ?

Simo.


The UI seems OK to me.

Let's say that we would let user define only the order. How would the server come up with weights and priorities? Or how would it know that some servers are equal (same prio and weight).

Then if server would compute the priorities it would be nice to see if some are the same(forms a group).

I would continue with drafting CLI. It may help us with Web UI.

Then focus on LDAP structure. Right now I'm not very fond of usage of multiple subtypes. It looks like a workaround of subentries to me.
--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to