Re: Service Reliability

An email exchange I had with a very smart colleague regarding how one defines “Reliability”, specifically in relation to Active Directory, of which I admit to knowing very little, so the discussion mostly centers on philosophical perspectives.

On 8/18/07 12:48 AM, “Wm.” wrote:

>
> So what you are saying is the protocol definition makes provision for
> what the client is supposed to do in the attempt to hide server
> outages from the user?

Yes. If that is what the protocol is designed to do.

> Do the following protocols define the service
> reliability as a function of the client’s ability to find a working
> server? (HTTP, NTP,WebDAV, AFP, SMB, FTP, IKE, VNC, IPP, ARD, IMAP,
> POP, SMTP, LDAP, Kerberos)

Not that I know of:
WebDAV, AFP, SMB, FTP, VNC, IPP, ARD, IMAP, POP

Yes:
NTP

Maybe:
LDAP, Kerberos

I don’t know:
IKE

Kind of:
HTTP, SMTP

> AD is a summation of LDAP, Kerberos and some proprietary mechanisms
> that Microsoft stacks on top. The actual’service’ is either LDAP or
> Kerberos depending upon the request.

ok. That’s more than I knew before having never looked at what AD is.

> It is kinda like going to Avis and renting a car. They put 30 on the
> lot and it is the client’s job to find the car ‘service’ that works.
> This alleviates the Avis ‘server’ from responsibility for having
> working ‘services’. As long as one car starts, no problem. Half of
> them may not start but it is not a problem unless all of them don’t
> start?

Not a very good analogy, or merely one that just fits to bolster your point.

You are trying to take your particular definition of “service reliability”
and apply it in a one-size fits all manner.

The true answer (like most things in life) is: It Depends

Some protocols are merely information request oriented protocols, like DNS
or NTP. These protocols tend have methods for dealing with inaccessible
sources of data.

Some are data access/transaction oriented protocols (any file sharing
protocol, mail). These protocols tend to not have “redundancy” as the
ability to have a data exchange transaction be mirrored across physical
servers difficult due to it being harder to replicate data across those
physical systems.

Some protocols have a pseudo redundancy in them. HTTP can redirect a
requestor to a different source to complete the data exchange. SMTP can give
a temporary deferment for data exchange.

As for AD: From what little I know of it, it is mostly a information request
system (where am I, can I get an auth token using these credentials, is this
system authorized to access me, etc) and that data can, for the most part,
be replicated easily across systems, much like DNS is replicated across
servers to serve out the same answers for a single question.

So a better analogy for the Avis world would be something like:

Are there multiple sources for me to get an answer to the Ultimate Question
of Life, The Universe and Everything:

“Dude, Where’s My Car?”

If none of the agents can answer the question, then yeah, the service sucks.

One thing I sent to Bill offline that I’ll include here for the benefit of
anyone else that is still reading:

—

If the protocol in question has to use BROADCAST traffic in order to
discover redundant systems to query then I consider that to be a poor design
choice for redundancy.

—

> On Aug 6, 2007, at 3:08 PM, Brian Blood wrote:
>
>> On 8/6/07 12:20 PM, “Wm.” wrote:
>>
>>> Does anyone recall coming across a white paper relative to measuring
>>> service reliability and collecting metrics on such.
>>>
>>> I am in a discussion with Active Directory admins who insist that if
>>> an AD client can root around and find a working server, then their
>>> service reliability metric is 100%. My stance is that service
>>> reliability is measured not by the workaround that the client
>>> performs but the availability of the service at the server’s point of
>>> presence (aka domain name).
>>
>>
>> I think you are dealing in semantics here.
>>
>> Look at DNS for an example.
>>
>> With most systems, a domain name is handled by two dns servers.
>>
>> If one of these is down, then the other covers traffic that would
>> have been
>> down.
>>
>> This redundancy is part of the dns protocol.
>>
>> While the DNS Service as a whole would have 100% reliability,
>> because of how
>> the protocol is designed, the reliability of the specific server
>> would not
>> be 100%.
>>
>>
>> So, the answer, as usual, is: it depends on what system you are
>> analyzing.
>>
>> If an AD client as part of the AD protocol can look for multiple
>> servers to
>> auth against, then the reliability of the AD SERVICE on that
>> network will be
>> measured as a whole.
>>
>>
>> In short, I think you are wrong.
>> 🙂
>>
>>
>> Brian