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

[IDD #NLC-477499]: Re: [ldm-users] FNMOC-NOGAPS LDM/IDD Feed

Hi Art,

re: Are you concerned about the duplication of traffic when the secondary
> > ingester is feeding from a remote (i.e., non-PSU) site?
> 
> Yes... I would prefer that the secondary only collect from our primary
> ingester in normal operation since it's unnecessary to go to external
> networks.  Only if the primary fails would I want the secondary then to
> use the failover (remote) sites.

You could setup a "heartbeat" monitor such that the secondary machine
checks up on the primary one.  In the case that the primary one becomes
unavailable, the secondary could restart the LDM changing the REQUEST
line(s) from the primary to the upstream host.  This would require a
mirrored setup on the primary, of course:  it would need to know that
it was no longer the primary and change its ingest to the secondary
machine.  Also, the upstream feed site(s) would need to ALLOW both
machines... OR the secondary machine could assume the identity of
the primary when the primary fails.  We know of some sites that are
running this kind of configuration; we are not doing this yet, but we
have been thinking about it.

> Since our primary is on a local LAN, I
> would have thought that this would have been the case most of the time,
> but I think the secondary flip-flops between local and remote frequently,
> although I have not examined this carefully.

I would have thought also.

re: our two accumulator approach
> What is the result of the two primary requests for the equivalent data?
> Does the machine actually get two feeds and throw one away, or does it
> somehow have the effect of preventing the flip-flops?

The machine gets full feeds from both/all upstreams.  The receiving LDM
discards products that are already in its queue, so there is no redundant
products.  The bandwidth used is, of course, the product of the number
of upstream feed sites times the volume for the feed(s) in question.

re: I would have your secondary ingester point at a non-NCEP machine like
idd.cise-nsf.gov.

> Okay... that makes sense.

The latency to idd.cise-nsf.gov should be enough (albeit small) to insure
that the products received on the primary arrive first.  There will be
some ping ponging, but it should be small.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: NLC-477499
Department: Support IDD
Priority: Normal
Status: Closed