Re: 20010223: LDM for two computers

Bunny Pfau wrote:
> 
> -> Date: Mon, 26 Feb 2001 17:04:07 -0700
> -> From: Anne Wilson <address@hidden>
> -> X-Accept-Language: en
> -> MIME-Version: 1.0
> -> To: Bunny Pfau <address@hidden>
> -> CC: address@hidden
> -> Subject: Re: 20010223: LDM for two computers
> -> Content-Transfer-Encoding: 7bit
> ->
> -> Unidata Support wrote:
> -> >
> -> > ------- Forwarded Message
> -> >
> -> > >To: address@hidden
> -> > >From: Bunny Pfau <address@hidden>
> -> > >Subject: LDM for two computers
> -> > >Organization: NCAR/HAO
> -> > >Keywords: 200102231648.f1NGmdL01689 LDM install ldmadmin
> -> >
> -> > Hello:
> -> >
> -> > I have a case where I would like to run an LDM server
> -> > on two different computers (Solaris 2.5.1/LDM 5.1.2)
> -> > and I would like to keep the binaries and so on on
> -> > an NFS shared file system...in other words, so that although
> -> > two computers are running independent LDM servers that I do not
> -> > have two absolute and redundant installations.
> -> >
> -> > Of course, I would need to have separate .conf files and
> -> > queues.   One thing that prevents this is that the ldmadmin
> -> > file has a place where the hostname is hardwired in.
> -> > Naturally, that could be modified to check which host its
> -> > running on and derive the hostname in that way.
> -> >
> -> > I didn't want to toy with this before first asking why things
> -> > are set up this way and if there are some inherent difficulties
> -> > in using a shared installation.
> -> >
> -> > Thanks,
> -> > Bunny
> -> >
> -> > ---
> -> >
> -> > Bunny Pfau                      National Center for Atmospheric Research
> -> > address@hidden                  High Altitude Observatory
> -> > tel: 303 497-1555               P.O. Box 3000
> -> > fax: 303 497-1589               Boulder, CO  80307-3000
> -> >
> -> > ------- End of Forwarded Message
> ->
> -> Hi Bunny,
> ->
> -> Although I don't know of any site that has done this, I think it would
> -> work.  You're right about needing separate conf files and queues.  I
> -> assume the path to LDMHOME would be the same for each host.  Regarding
> -> the hostname in ldmadmin, you could just rename ldmadmin something like
> -> ldmadmin.<host> then in your shell alias ldmadmin to be
> -> ldmadmin.<host>.  Then you wouldn't have to edit the script every time
> -> you upgrade.
> ->
> -> If you implement this and find out anything else about it, will you
> -> please let me know?  I'll add it to our support archives so others will
> -> know.
> ->
> -> Thanks!
> ->
> -> Anne
> -> --
> -> ***************************************************
> -> Anne Wilson                  UCAR Unidata Program
> -> address@hidden                       P.O. Box 3000
> ->                                        Boulder, CO  80307
> -> ----------------------------------------------------
> -> Unidata WWW server       http://www.unidata.ucar.edu/
> -> ****************************************************
> Anne:
> I appreciate your answer.
> 
> Since you say no one has ever done this, can you see anything
> inherently Dumb :-) in what I'm doing.  See, we want two LDM
> feeds coming in and feel safer if we're writing to local file
> systems instead of NFS mounted ones.  Therefore, we want to
> run two servers on two different computers.
> 
> IF you have any advice on this, I'm all ears.  Otherwise, I
> maybe will proceed on making both servers utilize the same
> installation from the server.
> 
> Thanks,
> Bunny

Hi Bunny,

I thought about it and also asked a coworker who is knowledgable about
the LDM, and we thought your plan sounded fine.  It certainly makes
sense to maintain only one set of binaries to run two LDMs.  The only
hard constraint is that the queue must be local, but it sounds like
you're going to make everything local but the binaries.  

For ease in upgrading, I would try to keep as close as possible to our
default directory structure:

   bin -> runtime/bin/          # for you, this will be remote
   data -> /var/data/ldm        # 'data' must local - the queue goes
here
                                # otherwise you can make 'data' point anywhere
   decoders/
   src -> runtime/src/          # needed for source installation
   etc/                         # your conf files go here
   include -> runtime/include/
   lib -> runtime/lib/
   logs -> data/logs/           
   man -> runtime/man/
   util/

The directories that will updated when you upgrade will be bin, src (if
you do a source installation), include, lib, and man.  The etc, logs,
decoders, and util directories are for things that are local to your
installation.  (Maybe you already know this.)

I guess my only question would be: what precisely is your concern
regarding remotely mounted file systems?  People write data to such file
systems all the time, although it's a little slower.  If reliability is
an issue, then you're going to face that same problem if your using
binaries that are remotely mounted.

Otherwise, I can't see any problems with your plan.  I'm interested in
seeing you do it just to see how it goes.  Will you keep me posted?

Anne

-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************