You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Randy Terbush <ra...@covalent.net> on 1999/06/22 15:27:13 UTC

FW: Concept help

Not Acked

-----Original Message-----
From: Dan Winkless <"Daniel O Winkless, District Computer Specialist,
Albuquerque, NM " [mailto:wink@usgs.gov] 
Sent: Friday, June 18, 1999 4:21 PM
To: apache@apache.org
Subject: Concept help


Hello Apache group,

	I am always proud to say that I use Apache as my web server.  I
think you folks have a good product and are doing goos service to
the nation.  I am with the Water Resources Division of the US
Geological Survey.  Apache is serving near real time streamflow
information which is being used by emergency personnel to
determine need for evacuation -- lifesaving actions.  Apache is a
critical link in this process.  Thank you all for your
contributions.

	Meanwhile, I am part of a team that is designing redundant,
geographically dispersed, failure resistent web serving for the
entire Division.  I have an idea regarding implementation that I
would like your opinion on.  Let me describe the general layout.

	At this time, the Division has approximately 49 (official?)
individual sites serving the near real time data along with other
data of (possible) public interest.  We also have a HQ system
serving historical data (many megs) and zillions of other pages. 
See http://water.usgs.gov for the HQ pages.  See
http://nm.water.usgs.gov for my pages, an example of the near
real time data.

	Internally, we have a private network (DOINET or GEONET or
whatever).  It is nation-wide with nodes in all states, including
Alaska and Hawaii, T3, T1, maybe E3(?) legs, etc.  There are two
points of tangency between our private network and the "public"
internet.  The email message departs my network though either
Menlo Park, CA (probable route) or Reston, VA, even though it is
originating in Albuquerque, NM.  (An email to my house,
physically 5 miles away, travels mulitple thousand electronic
miles.)

	We NEED to leave control of content in all of those locations,
but we also need to provide redundant pathways and backup
computational service.  At the same time, we'd like to try to
limit internal network traffic.  

	Here come the part where I would like feedback.  I keep thinking
about the proxy server model w/caching.  We need it, but the
other way around.  Would that work?  I mean:

	a) I put a heavy server in Menlo Park, for example.
	b) I fill DNS with CNAME entries all pointing to that server.
	c) John and Jane Doe tell their browsers to go to
nm.water.usgs.gov and end up at Menlo Park, CA.
	d) The Menlo server looks in its virtual hosts configurations to
see what data to serve and checks the cache for ability to fulfil
the request.
	e) for an expired page, the Menlo server uses the internal
network to access my system (hst1dnmalb.cr.usgs.gov, the
canonical name for nm.water.usgs.gov) for a fresh copy.
	f) the new page is returned to the user and cached for the next
request.

	This is backward from the normal view of a proxy server.  All of
the servers are within "the company LAN" and all of the users are
on the WAN.  I can't tell "them" to configure their browsers for
proxy service.  I don't find this concept discussed or described
in my references, including my Laurie and Laurie Definitive
Guide.

	Other considerations: during an extreme event (hurricane or
flood, for example), we can be pounded by extreme numbers of
requests.  Some of our sites could be susceptable to the events
on which they are reporting -- floods or huricanes could kill
power or telecom or the site itself -- and we need to pick up the
computations and reporting elsewhere.  We could loose (a)
piece(s) of our internal network and need to continue
computations and reporting elsewhere.

	It is the web serving I am trying to deal with at this time. 
Can what I describe above be implemented with Apache?



	I can go on for a long time, but your time is precious.  I thank
you for a good solid product and I thank you for reading this
far.  I will appreciate any advice and guidance you can give me.

	Dan Winkless
	USGS/WRD
	wink@usgs.gov

-- 
If you try to fail, and succeed, which have you done?