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.
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