[OpenAFS] GSoC Server priorities

Thu, 15 Oct 2009 18:46:34 -0500

--000e0cd51566e4a493047601e48a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 15, 2009 at 2:19 AM, Lars Schimmer <l.schimmer@cgv.tugraz.at>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> I've seen the code for server priorities made in a GSoC is in the
> private windows test builds.
>
> As it could solve one smaller design problem for us, one question is open:
> On which base does it rate server "near" and "far"?
> AFAIK based on RTT time.
>

Current private builds use RTT as taken from the rx statiscs that are
gathered on a per-client basis, and use a log (base-e) scale to provide a
rank based on the RTT.

> Our setup is expanded with a fileserver with only RO on a different
> subnet some miles away, attached to us via a static VPN.
> In one of our private subnets we drive our CAVE and this subnet is not
> routed accross the VPN - if we put the CAVE ROs on the fileserver on the
> far away fileserver, the clients does not reach them.
> For now, the ROs are not there (kinda bad in kind of backup reasons).
> Could this new feature solve this (in a bad way, I know) with just rate
> the "bad" fileserver horrible bad?
>

If I understand what your end goals are, you're trying to minimize the
amount of traffic to the file server on the other side of the VPN. If this
is the case, then there is functionality available currently, using "fs
serverprefs". The administrator can set the server rank much higher than the
ranks the other servers are being given, and this server will only be
interacted with if all the other servers with lower ranks are down.

The RTT based ranking only gets taken into account when there are rx
statistics collected by the client, so if the client has never interacted
with the file server on the other side of the VPN, there will be no rx
statistics gathered, and the rank will default to the current scheme (based
on which machine, subnet, network the server is on compared to the client).

I hope this helps, please clarify if I misunderstood your goals. If you do
try it, I would appreciate feedback you have.

-- 
Jacob Thebault-Spieker
Cell: (320) 288-6412
http://summatusmentis.com

--000e0cd51566e4a493047601e48a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Oct 15, 2009 at 2:19 AM, Lars Sc=
himmer <span dir=3D"ltr">&lt;<a href=3D"mailto:l.schimmer@cgv.tugraz.at">l.=
schimmer@cgv.tugraz.at</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt =
0pt 0.8ex; padding-left: 1ex;">

-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi!<br>
<br>
I&#39;ve seen the code for server priorities made in a GSoC is in the<br>
private windows test builds.<br>
<br>
As it could solve one smaller design problem for us, one question is open:<=
br>
On which base does it rate server &quot;near&quot; and &quot;far&quot;?<br>
AFAIK based on RTT time.<br></blockquote><div><br>Current private builds us=
e RTT as taken from the rx statiscs that are gathered on a per-client basis=
, and use a log (base-e) scale to provide a rank based on the RTT.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px so=
lid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Our setup is expanded with a fileserver with only RO on a different<br>
subnet some miles away, attached to us via a static VPN.<br>
In one of our private subnets we drive our CAVE and this subnet is not<br>
routed accross the VPN - if we put the CAVE ROs on the fileserver on the<br=
>
far away fileserver, the clients does not reach them.<br>
For now, the ROs are not there (kinda bad in kind of backup reasons).<br>
Could this new feature solve this (in a bad way, I know) with just rate<br>
the &quot;bad&quot; fileserver horrible bad?<br></blockquote><div><br>If I =
understand what your end goals are, you&#39;re trying to minimize the amoun=
t of traffic to the file server on the other side of the VPN. If this is th=
e case, then there is functionality available currently, using &quot;fs ser=
verprefs&quot;. The administrator can set the server rank much higher than =
the ranks the other servers are being given, and this server will only be i=
nteracted with if all the other servers with lower ranks are down.<br>

<br>The RTT based ranking only gets taken into account when there are rx st=
atistics collected by the client, so if the client has never interacted wit=
h the file server on the other side of the VPN, there will be no rx statist=
ics gathered, and the rank will default to the current scheme (based on whi=
ch machine, subnet, network the server is on compared to the client).<br>

I hope this helps, please clarify if I misunderstood your goals. If you=
 do try it, I would appreciate feedback you have. </div></=
div> -- Jacob Thebault-Spieker Cell: (320) 288-6412 <a href=3D=
"http://summatusmentis.com">http://summatusmentis.com</a>

--000e0cd51566e4a493047601e48a--