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

[CONDUIT #QWD-621691]: GFS upgrade

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: [CONDUIT #QWD-621691]: GFS upgrade
  • Date: Wed, 05 Aug 2015 23:08:16 -0600
Hi David,

re:
> I'm ready to go with the new beefy LDM host to replace the existing
> flood.atmos.uiuc.edu.

Excellent!

re:
> I'll keep the hostname, but I will have to change IP addresses because 
> getting it access
> to a 10G link involved putting it a different building on a different subnet.

OK, this makes sense.

re:
> I've swapped one server for another multiple times before, but the IP has 
> stayed the
> same.   This time it will change.  What's the best way to transition this 
> with the least
> disruption?

I think that an email announcement of the impending change to downstream sites
being serviced is called for.  If you can't generate the list of who should be
contacted, we can help out.

Hopefully, those REQUESTing data from your current IDD relay machine are
doing so by name, not by IP.  If this is the case, then the amount of time
that downstream REQUESTs will fail will be governed by how fast the DNS
information is propagated.  It is our experience that this can take anywhere
from a few minutes to a couple of hours, but there is, of course, no guarantee.

re:
> I can update DNS (currently set with a short TTL)  to point 
> flood.atmos.uiuc.edu to the
> new IP address (128.174.76.239), which will be the new machine.     Assuming 
> upstream
> hosts have the name in their allow file, will they start allowing feeds 
> requests from
> the new IP as soon as the DNS changes propagate?

Exactly.  I should have read further down in your email before trying to say the
exact same thing in my reply! :-)

re:
> Or do they need to be kicked somehow to recognize the change?

The only ways that they would need to be "kicked" are:

- they are REQUESTing using flood's IP address 

- they created an entry in their /etc/hosts file that "hardwires"
  a name for flood's IP

re:
> Will turn off upstream requests on old host, and have it feed from the new 
> host while
> temporarily still servicing any downstream clients that continue to connect 
> to the old
> host.

Sounds like a good plan!

re:
> Other thoughts?

Not off of the top of my head.  If anything comes to me, I will be sure and let 
you
know.

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: QWD-621691
Department: Support CONDUIT
Priority: Normal
Status: Closed