On Mon, Jul 28, 2014 at 12:31:57PM +0200, [email protected] wrote:
> 1. realm => volume location service
...
> Currently step 1 is implemented via DNS but it does not seem to
> provide for any data expiration/renewal (?) besides by manually
> running cfs check<something> on a client (?)
We iterate through the servers and redo the SRV lookup when we fail to
connect to all of them.
> DNS provides sufficient means to handle the task.
> I suggest moving the step 2.3 to the client, to address the limitation
> of the current design. The mapping in this step is not security-critical
> and hence can be delegated to DNS.
>
> Jan's intention was to split 2.3 into
>
> 2.3.1 server-numeric-id => (f.q.d.n,numeric-port)
> inside the VLS
>
> 2.3.2 f.q.d.n => numeric-ip
> on the clent, via DNS
That is deceptive because currently all of step 2 is a single
GetVolumeInfo RPC2 call. So you cannot really split out just 2.3, and
then make my approach look more complicated by splitting your step
2.3 into 2 additional steps. Both approaches are really pretty similar
in what is looked up.
I only added a pair of (per-replica) lookups to the normal
ViceGetVolumeInfo call, one of which is already implemented.
- volume name -> replica volume ids (implemented, ViceGetVolumeInfo)
- replica volume id -> FQDN:port (implemented, ViceGetVolumeLocation)
- FQDN -> one or more valid IP addresses, on the client using DNS
(not yet implemented)
> Which for my eyes keeps a burden on VLS which can/should be delegated to
> DNS as well, for reduced complexity and better clarity.
The volume location service has to track which replicas belong to a
volume anyway, and the server has to know where replicas are located.
> ========================================
>
> The issues to address:
>
> - is it actually correct to let server-id be public information?
Not really an issue, it is more, is the namespace you want to use to
talk about servers based on numbers that have somewhat odd properties
like be 8-bit and avoid 0,127 and 255. Or use regular old DNS name
resolution which can handle ipv4/ipv6, multi-homed hosts, internal vs.
public addresses etc.
> Is there a better approach?
Devils advocate here, get rid of the volume location service completly
and put everything into DNS with volumename.<realm> DNS records.
Jan
