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.<\/p>\n
On 8\/18\/07 12:48 AM, “Wm.” wrote:<\/p>\n
>
\n> So what you are saying is the protocol definition makes provision for
\n> what the client is supposed to do in the attempt to hide server
\n> outages from the user?<\/p>\n
Yes. If that is what the protocol is designed to do.<\/p>\n
> Do the following protocols define the service
\n> reliability as a function of the client’s ability to find a working
\n> server? (HTTP, NTP,WebDAV, AFP, SMB, FTP, IKE, VNC, IPP, ARD, IMAP,
\n> POP, SMTP, LDAP, Kerberos)<\/p>\n
Not that I know of:
\nWebDAV, AFP, SMB, FTP, VNC, IPP, ARD, IMAP, POP<\/p>\n
Yes:
\nNTP<\/p>\n
Maybe:
\nLDAP, Kerberos<\/p>\n
I don’t know:
\nIKE<\/p>\n
Kind of:
\nHTTP, SMTP<\/p>\n
> AD is a summation of LDAP, Kerberos and some proprietary mechanisms
\n> that Microsoft stacks on top. The actual’service’ is either LDAP or
\n> Kerberos depending upon the request.<\/p>\n
ok. That’s more than I knew before having never looked at what AD is.<\/p>\n
> It is kinda like going to Avis and renting a car. They put 30 on the
\n> lot and it is the client’s job to find the car ‘service’ that works.
\n> This alleviates the Avis ‘server’ from responsibility for having
\n> working ‘services’. As long as one car starts, no problem. Half of
\n> them may not start but it is not a problem unless all of them don’t
\n> start?<\/p>\n
Not a very good analogy, or merely one that just fits to bolster your point.<\/p>\n
You are trying to take your particular definition of “service reliability”
\nand apply it in a one-size fits all manner.<\/p>\n
The true answer (like most things in life) is: It Depends<\/p>\n
Some protocols are merely information request oriented protocols, like DNS
\nor NTP. These protocols tend have methods for dealing with inaccessible
\nsources of data.<\/p>\n
Some are data access\/transaction oriented protocols (any file sharing
\nprotocol, mail). These protocols tend to not have “redundancy” as the
\nability to have a data exchange transaction be mirrored across physical
\nservers difficult due to it being harder to replicate data across those
\nphysical systems.<\/p>\n
Some protocols have a pseudo redundancy in them. HTTP can redirect a
\nrequestor to a different source to complete the data exchange. SMTP can give
\na temporary deferment for data exchange.<\/p>\n
As for AD: From what little I know of it, it is mostly a information request
\nsystem (where am I, can I get an auth token using these credentials, is this
\nsystem authorized to access me, etc) and that data can, for the most part,
\nbe replicated easily across systems, much like DNS is replicated across
\nservers to serve out the same answers for a single question.<\/p>\n
So a better analogy for the Avis world would be something like:<\/p>\n
Are there multiple sources for me to get an answer to the Ultimate Question
\nof Life, The Universe and Everything:<\/p>\n
“Dude, Where’s My Car?”<\/p>\n
If none of the agents can answer the question, then yeah, the service sucks.<\/p>\n
One thing I sent to Bill offline that I’ll include here for the benefit of
\nanyone else that is still reading:<\/p>\n
—<\/p>\n
If the protocol in question has to use BROADCAST traffic in order to
\ndiscover redundant systems to query then I consider that to be a poor design
\nchoice for redundancy.<\/p>\n
—<\/p>\n
> On Aug 6, 2007, at 3:08 PM, Brian Blood wrote:
\n>
\n>> On 8\/6\/07 12:20 PM, “Wm.” wrote:
\n>>
\n>>> Does anyone recall coming across a white paper relative to measuring
\n>>> service reliability and collecting metrics on such.
\n>>>
\n>>> I am in a discussion with Active Directory admins who insist that if
\n>>> an AD client can root around and find a working server, then their
\n>>> service reliability metric is 100%. My stance is that service
\n>>> reliability is measured not by the workaround that the client
\n>>> performs but the availability of the service at the server’s point of
\n>>> presence (aka domain name).
\n>>
\n>>
\n>> I think you are dealing in semantics here.
\n>>
\n>> Look at DNS for an example.
\n>>
\n>> With most systems, a domain name is handled by two dns servers.
\n>>
\n>> If one of these is down, then the other covers traffic that would
\n>> have been
\n>> down.
\n>>
\n>> This redundancy is part of the dns protocol.
\n>>
\n>> While the DNS Service as a whole would have 100% reliability,
\n>> because of how
\n>> the protocol is designed, the reliability of the specific server
\n>> would not
\n>> be 100%.
\n>>
\n>>
\n>> So, the answer, as usual, is: it depends on what system you are
\n>> analyzing.
\n>>
\n>> If an AD client as part of the AD protocol can look for multiple
\n>> servers to
\n>> auth against, then the reliability of the AD SERVICE on that
\n>> network will be
\n>> measured as a whole.
\n>>
\n>>
\n>> In short, I think you are wrong.
\n>> \ud83d\ude42
\n>>
\n>>
\n>> Brian<\/p>\n","protected":false},"excerpt":{"rendered":"
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…<\/p>\n