[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20051005: host aliasing and LDM best practices

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20051005: host aliasing and LDM best practices
  • Date: Thu, 06 Oct 2005 15:17:59 -0600
Michael,

>Date: Thu, 06 Oct 2005 15:46:23 -0500
>From: Michael McEniry <address@hidden>
>Organization: UAH / ITSC
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20051005: host aliasing and LDM best practices

The above message contained the following:

> Steve Emmerson wrote:
> > I'm afraid that questions is outside my area of expertise, so I've
> > forwarded your question to our systems and network administrator.
> 
> I didn't find any planning guidelines for LDM that seemed to 
> discuss host aliasing (ie, a role-based name, like "ldm" or 
> "idd", vs the host's actual name), although a lot of places seem 
> to use it anyway. The DNS side would be a minor technical detail.
> 
> The documentation seems to be mostly targeting folks who want to 
> join in an existing LDM-based network (like IDD) in a strictly 
> downstream sense, as opposed to folks (like Unidata) who run 
> upstream LDM nodes as a service to other sites, where redundancy 
> and managed failover are important. Unless I missed some?

You're correct.  The problem is that redundancy at an upstream site can
be done in many ways and, strictly speaking, that issue lies outside the
purview of the LDM.

Be that as it may, we've implemented a highly-reliable, virtual LDM 
host called idd.unidata.ucar.edu using a virtual cluster approach.  Tom
Yoksas knows more about it and will receive this email.

> >>By the way, I tried the UCAR ultraseek search 
> >><http://www.unidata.ucar.edu/support/help/ultraseek.html>, but it 
> >>seems to be broken.
> > 
> > It worked for me.  In what sense was it broken?
> 
> Submitting a search query resulted in a connection timeout. I 
> guess it was just a problem yesterday, since it works fine today.

Interesting.  Must be gremlins.  :-)

> Michael McEniry
> University of Alabama in Huntsville
> Information Technology & Systems Center
> <address@hidden> +1.256.824.5158

Regards,
Steve Emmerson