20050317: Fail over scheme for met_research3.nchmf.gov.vn

>From: Mai Nguyen <address@hidden>

Hi Mai,

re: failover plan
>Thanks for your helps. It took me a while to "digest"
>your idea.

OK.

>After you've split the line in the ldm.conf, we
>couldn't get the UKMET and ECMWF model data. So Tien,
>my colleage, changed back to its previous version
>(i.e. a long line specifying all models data) but with
>idd.unidata.ucar.edu as the primary host. So, it works
>now. But maybe we should try again the shorter lines
>as you suggested if there will be large latency again.

I logged in this morning and see that I had a typo:

request HDS     "(ECMWF|EGRR))"          idd.unidata.ucar.edu    PRIMARY 

should have been:

request HDS     "(ECMWF|EGRR)"          idd.unidata.ucar.edu    PRIMARY 

I made the correction; commented out the long, single request line,
and restarted your LDM.

>Also, the QuickCat data is coming nicely. Thanks.

Very good.

>Now, I would like to have the ATCF data as well (TC
>track forecasts). Could you please help me on this
>too!

I will check into the ATCF data later this morning.

re: ldmfail
>It's clever to have the system working that way. So
>now, do I need another machine with another IP and DNS
>to do that?

Yes.  The method I sketched out for redundancy called
for an additional machine with a separate IP address
and DNS service.  There are many ways that one could
implement a failover scheme, however.  For instance, one
could have a machine acting as a hot spare: it would 
ingest from met_research3 and monitor met_research3
to see if it was still alive.  If it died, the hot
spare could assume the identity of met_research3 and
then start ingesting from met_research3's upstream
feed site(s).  This is  alittle more complicated than
the ldmfail idea I sent you, but it is certainly workable.
The one thing that must be done in a situation like this
is to make sure that met_research3 is _really_ dead before
assuming its personality.  By personality, I mean 
IP address and name.  If the secondary does not make
sure that the primary is dead AND will not come back
to life, you would end up with two machines with the
same name/IP on the same network.  This would cause
bad problems.

>Let's call it the Secondary, the
>met_research3 to be the Primary. Does it mean that we
>have to notify the upstream host (e.g
>idd.unidata.ucar.edu) about the Secondary IP and name?

I would simply let the upstream host know that you will
have a second machine that you would want fed if/when
met_research3 fails.  Since I am one of the people
that manage idd.unidata.ucar.edu, this is as simple
as letting me know the name/IP of the new machine.

>Now, in the case that the Primary machine is working
>nice, I would like the secondary to be fed from the
>Primary by the internal IP. Is that possible?

Yes, this is possible.

>If so,
>should we have an internal DNS server to specify the
>internal IP and names? Is that correct?

You could do that.  A simpler way, however, is to simply
'allow' the secondary machine to feed from the primary
(met_research3) by IP.  ~ldm/etc/ldmd.conf 'allow' lines
can use a host name (typical) or IP address (less typical).

>Thank you for your big helps as always.

No worries.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

>From address@hidden  Tue Mar 22 17:59:01 2005

Hi Tom,

Thank you for fixing it up.

I will go for the 2 machines with different IP and
name. 

> I would simply let the upstream host know that you
> will
> have a second machine that you would want fed
> if/when
> met_research3 fails.  Since I am one of the people
> that manage idd.unidata.ucar.edu, this is as simple
> as letting me know the name/IP of the new machine.

I'll get another machine's IP and name and will notify
you then. Thanks

Best regards, Mai