httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@apache.org
Subject svn commit: r1729702 - /httpd/httpd/trunk/docs/manual/howto/reverse_proxy.xml
Date Wed, 10 Feb 2016 19:45:02 GMT
Author: jim
Date: Wed Feb 10 19:45:02 2016
New Revision: 1729702

URL: http://svn.apache.org/viewvc?rev=1729702&view=rev
Log:
more info

Modified:
    httpd/httpd/trunk/docs/manual/howto/reverse_proxy.xml

Modified: httpd/httpd/trunk/docs/manual/howto/reverse_proxy.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/howto/reverse_proxy.xml?rev=1729702&r1=1729701&r2=1729702&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/howto/reverse_proxy.xml (original)
+++ httpd/httpd/trunk/docs/manual/howto/reverse_proxy.xml Wed Feb 10 19:45:02 2016
@@ -23,84 +23,197 @@
 <manualpage metafile="public_html.xml.meta">
 <parentdocument href="./">How-To / Tutorials</parentdocument>
 
-	<title>Reverse Proxy Guide</title>
+  <title>Reverse Proxy Guide</title>
 
-	<summary>
-	  <p>In addition to being a "basic" web server, and providing static and
-	  dynamic content to end-users, Apache httpd (as well as most other web
-	  servers) can also act as a reverse proxy server, also-known-as a
-	  "gateway" server.</p>
-
-	  <p>In such scenarios, httpd itself does not generate or host the data,
-	  but rather the content is obtained by one or several backend servers,
-	  which normally have no direct connection to the external network. As
-	  httpd receives a request from a client, the request itself is <em>proxied</em>
-	  to one of these backend servers, which then handles the request, generates
-	  the content and then sends this content back to httpd, which then
-	  generates the actual HTTP response back to the client.</p>
-
-	  <p>There are numerous reasons for such an implementation, but generally
-	  the typical rationales are due to security, high-availability, load-balancing
-	  and centralized authentication/authorization. It is critical in these
-	  implementations that the layout, design and architecture of the backend
-	  infrastructure (those servers which actually handle the requests) are
-	  insulated and protected from the outside; as far as the client is concerned,
-	  the reverse proxy server <em>is</em> the sole source of all content.</p>
-
-	  <p>A typical implementation is below:</p>
-	  <p><img src="../images/reverse-proxy-arch.png" alt="reverse-proxy-arch" /></p>
-	  
-	</summary>
-
-
-	<section id="related">
-	<title>Reverse Proxy</title>
-	<related>
-	  <modulelist>
-	    <module>mod_proxy</module>
-	    <module>mod_proxy_balancer</module>
-	    <module>mod_proxy_hcheck</module>
-	  </modulelist>
-	  <directivelist>
-	    <directive module="mod_proxy">ProxyPass</directive>
-	    <directive module="mod_proxy">BalancerMember</directive>
-	  </directivelist>
-	</related>
-	</section>
-
-    <section id="userdir">
-		<title>Simple reverse proxying</title>
-
-		<p>The <directive module="mod_proxy">ProxyPass</directive>
-		directive specifies the mapping of incoming requests to the backend
-		server (or a cluster of servers known as a <code>Balancer</code>
-		group). The simpliest example proxies all requests (<code>"/"</code>)
-		to a single backend:</p>
-
-		<highlight language="config">
-		ProxyPass "/"  "http://www.example.com"
-		</highlight>
-
-		<p>To ensure that and <code>Location:</code> headers generated from
-		the backend are modified to point to the reverse proxy, instead of
-		back to itself, the <directive module="mod_proxy">ProxyPassReverse</directive>
-		directive is most often required:</p>
-
-		<highlight language="config">
-		ProxyPass "/"  "http://www.example.com"
-		ProxyPassReverse "/"  "http://www.example.com"
-		</highlight>
-
-		<p>Only specific URIs can be proxied, as shown in this example:</p>
-
-		<highlight language="config">
-		ProxyPass "/images"  "http://www.example.com"
-		ProxyPassReverse "/images"  "http://www.example.com"
-		</highlight>
-
-		<p>In the above, any requests which start with the <code>/images</code>
-		path with be proxied to the specified backend, otherwise it will be handled
-		locally.</p>
-	</section>
+  <summary>
+    <p>In addition to being a "basic" web server, and providing static and
+    dynamic content to end-users, Apache httpd (as well as most other web
+    servers) can also act as a reverse proxy server, also-known-as a
+    "gateway" server.</p>
+
+    <p>In such scenarios, httpd itself does not generate or host the data,
+    but rather the content is obtained by one or several backend servers,
+    which normally have no direct connection to the external network. As
+    httpd receives a request from a client, the request itself is <em>proxied</em>
+    to one of these backend servers, which then handles the request, generates
+    the content and then sends this content back to httpd, which then
+    generates the actual HTTP response back to the client.</p>
+
+    <p>There are numerous reasons for such an implementation, but generally
+    the typical rationales are due to security, high-availability, load-balancing
+    and centralized authentication/authorization. It is critical in these
+    implementations that the layout, design and architecture of the backend
+    infrastructure (those servers which actually handle the requests) are
+    insulated and protected from the outside; as far as the client is concerned,
+    the reverse proxy server <em>is</em> the sole source of all content.</p>
+
+    <p>A typical implementation is below:</p>
+    <p><img src="../images/reverse-proxy-arch.png" alt="reverse-proxy-arch" /></p>
+
+  </summary>
+
+
+  <section id="related">
+  <title>Reverse Proxy</title>
+  <related>
+    <modulelist>
+      <module>mod_proxy</module>
+      <module>mod_proxy_balancer</module>
+      <module>mod_proxy_hcheck</module>
+    </modulelist>
+    <directivelist>
+      <directive module="mod_proxy">ProxyPass</directive>
+      <directive module="mod_proxy">BalancerMember</directive>
+    </directivelist>
+  </related>
+  </section>
+
+  <section id="simple">
+    <title>Simple reverse proxying</title>
+
+    <p>
+      The <directive module="mod_proxy">ProxyPass</directive>
+      directive specifies the mapping of incoming requests to the backend
+      server (or a cluster of servers known as a <code>Balancer</code>
+      group). The simpliest example proxies all requests (<code>"/"</code>)
+      to a single backend:
+    </p>
+
+    <highlight language="config">
+      ProxyPass "/"  "http://www.example.com"
+    </highlight>
+
+    <p>
+      To ensure that and <code>Location:</code> headers generated from
+      the backend are modified to point to the reverse proxy, instead of
+      back to itself, the <directive module="mod_proxy">ProxyPassReverse</directive>
+      directive is most often required:
+    </p>
+
+    <highlight language="config">
+      ProxyPass "/"  "http://www.example.com"
+      ProxyPassReverse "/"  "http://www.example.com"
+    </highlight>
+
+    <p>Only specific URIs can be proxied, as shown in this example:</p>
+
+    <highlight language="config">
+      ProxyPass "/images"  "http://www.example.com"
+      ProxyPassReverse "/images"  "http://www.example.com"
+    </highlight>
+
+    <p>In the above, any requests which start with the <code>/images</code>
+      path with be proxied to the specified backend, otherwise it will be handled
+      locally.
+    </p>
+  </section>
+
+  <section id="cluster">
+    <title>Clusters and Balancers</title>
+
+    <p>
+      As useful as the above is, it still has the deficiencies that should
+      the (single) backend node go down, or become heavily loaded, that proxying
+      those requests provides no real advantage. What is needed is the ability
+      to define a set or group of backend servers which can handle such
+      requests and for the reverse proxy to load balance and failover among
+      them. This group is sometimes called a <em>cluster</em> but Apache httpd's
+      term is a <em>balancer</em>. One defines a balancer by leveraging the
+      <directive module="mod_proxy">Proxy</directive> and
+      <directive module="mod_proxy">BalancerMember</directive> directives as
+      shown:
+    </p>
+
+    <highlight language="config">
+      &lt;Proxy balancer://myset&gt;
+        BalancerMember http://www2.example.com:8080
+        BalancerMember http://www3.example.com:8080
+        ProxySet lbmethod=bytraffic
+      &lt;/Proxy&gt;
+
+      ProxyPass "/images"  "balancer://myset"
+      ProxyPassReverse "/images"  "balancer://myset"
+    </highlight>
+
+    <p>
+      The <code>balancer://</code> scheme is what tells httpd that we are creating
+      a balancer set, with the name <em>myset</em>. It includes 2 backend servers,
+      which httpd calls <em>BalancerMembers</em>. In this case, any requests
for
+      <code>/images</code> will be proxied to <em>one</em> of the
2 backends.
+      The <directive module="mod_proxy">ProxySet</directive> directive
+      specifies that the <em>myset</em> Balancer use a load balancing algorithm
+      that balances based on I/O bytes.
+    </p>
+
+    <note type="hint"><title>Hint</title>
+      <p>
+      	<em>BalancerMembers</em> are also sometimes referred to as <em>workers</em>.
+      </p>
+   </note>
+
+  </section>
+
+  <section id="config">
+    <title>Balancer and BalancerMember configuration</title>
+
+    <p>
+      You can adjust numerous configuration details of the <em>balancers</em>
+      and the <em>workers</em> via the various parameters defined in
+      <directive module="mod_proxy">ProxyPass</directive>. For example,
+      assuming we would want <code>http://www3.example.com:8080</code> to
+      handle 3x the traffic with a timeout of 1 second, we would adjust the
+      configuration as follows:
+    </p>
+
+    <highlight language="config">
+      &lt;Proxy balancer://myset&gt;
+        BalancerMember http://www2.example.com:8080
+        BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+        ProxySet lbmethod=bytraffic
+      &lt;/Proxy&gt;
+
+      ProxyPass "/images"  "balancer://myset"
+      ProxyPassReverse "/images"  "balancer://myset"
+    </highlight>
+
+  </section>
+
+  <section id="failover">
+    <title>Failover</title>
+
+    <p>
+      You can also fine-tune various failover scenarios, detailing which
+      workers and even which balancers should accessed in such cases. For
+      example, the below setup implements 2 failover cases: In the first,
+      <code>http://hstandby.example.com:8080</code> is only sent traffic
+      if all other workers in the <em>myset</em> balancer are not available.
+      If that worker itself is not available, only then will the
+      <code>http://bkup1.example.com:8080</code> and <code>http://bkup2.example.com:8080</code>
+      workers be brought into rotation:
+    </p>
+
+    <highlight language="config">
+      &lt;Proxy balancer://myset&gt;
+        BalancerMember http://www2.example.com:8080
+        BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+        BalancerMember http://hstandby.example.com:8080 status=+H
+        BalancerMember http://bkup1.example.com:8080 lbset=1
+        BalancerMember http://bkup2.example.com:8080 lbset=1
+        ProxySet lbmethod=byrequests
+      &lt;/Proxy&gt;
+
+      ProxyPass "/images"  "balancer://myset"
+      ProxyPassReverse "/images"  "balancer://myset"
+    </highlight>
+
+    <p>
+      The magic of this failover setup is setting <code>http://hstandby.example.com:8080</code>
+      with the <code>+H</code> status flag, which puts it in <em>hot standby</em>
mode,
+      and making the 2 <code>bkup#</code> servers part of the #1 load balancer
set (the
+      default set is 0); for failover, hot standbys (if they exist) are used 1st, when all
regular
+      workers are unavailable; load balancer sets are always tried lowest number first.
+    </p>
+
+  </section>
 
 </manualpage>



Mime
View raw message