[master] b31835c Merge backend stuff into one chapter

Per Buer perbu at varnish-cache.org
Fri Sep 7 15:23:19 CEST 2012


commit b31835c437da5cb97b6c3a6f62010def7f4e8c90
Author: Per Buer <per.buer at gmail.com>
Date:   Fri Sep 7 15:22:23 2012 +0200

    Merge backend stuff into one chapter

diff --git a/doc/sphinx/users-guide/advanced_backend_servers.rst b/doc/sphinx/users-guide/advanced_backend_servers.rst
deleted file mode 100644
index 52af46e..0000000
--- a/doc/sphinx/users-guide/advanced_backend_servers.rst
+++ /dev/null
@@ -1,157 +0,0 @@
-Advanced Backend configuration
-------------------------------
-
-At some point you might need Varnish to cache content from several
-servers. You might want Varnish to map all the URL into one single
-host or not. There are lot of options.
-
-Lets say we need to introduce a Java application into out PHP web
-site. Lets say our Java application should handle URL beginning with
-/java/.
-
-We manage to get the thing up and running on port 8000. Now, lets have
-a look a default.vcl.::
-
-  backend default {
-      .host = "127.0.0.1";
-      .port = "8080";
-  }
-
-We add a new backend.::
-
-  backend java {
-      .host = "127.0.0.1";
-      .port = "8000";
-  }
-
-Now we need tell where to send the difference URL. Lets look at vcl_recv.::
-
-  sub vcl_recv {
-      if (req.url ~ "^/java/") {
-          set req.backend = java;
-      } else {
-          set req.backend = default.
-      }
-  }
-
-It's quite simple, really. Lets stop and think about this for a
-moment. As you can see you can define how you choose backends based on
-really arbitrary data. You want to send mobile devices to a different
-backend? No problem. if (req.User-agent ~ /mobile/) .... should do the
-trick. 
-
-.. _users-guide-advanced_backend_servers-directors:
-
-Directors
----------
-
-You can also group several backend into a group of backends. These
-groups are called directors. This will give you increased performance
-and resilience. You can define several backends and group them
-together in a director.::
-
-	 backend server1 {
-	     .host = "192.168.0.10";
-	 }
-	 backend server2{
-	     .host = "192.168.0.10";
-	 }
-
-Now we create the director.::
-
-       	director example_director round-robin {
-        {
-                .backend = server1;
-        }
-	# server2
-        {
-                .backend = server2;
-        }
-	# foo
-	}
-
-
-This director is a round-robin director. This means the director will
-distribute the incoming requests on a round-robin basis. There is
-also a *random* director which distributes requests in a, you guessed
-it, random fashion.
-
-But what if one of your servers goes down? Can Varnish direct all the
-requests to the healthy server? Sure it can. This is where the Health
-Checks come into play.
-
-.. _users-guide-advanced_backend_servers-health:
-
-Health checks
--------------
-
-Lets set up a director with two backends and health checks. First lets
-define the backends.::
-
-       backend server1 {
-         .host = "server1.example.com";
-	 .probe = {
-                .url = "/";
-                .interval = 5s;
-                .timeout = 1 s;
-                .window = 5;
-                .threshold = 3;
-	   }
-         }
-       backend server2 {
-  	  .host = "server2.example.com";
-  	  .probe = {
-                .url = "/";
-                .interval = 5s;
-                .timeout = 1 s;
-                .window = 5;
-                .threshold = 3;
-	  }
-        }
-
-Whats new here is the probe. Varnish will check the health of each
-backend with a probe. The options are
-
-url
- What URL should varnish request.
-
-interval
- How often should we poll
-
-timeout
- What is the timeout of the probe
-
-window
- Varnish will maintain a *sliding window* of the results. Here the
- window has five checks.
-
-threshold 
- How many of the .window last polls must be good for the backend to be declared healthy.
-
-initial 
- How many of the of the probes a good when Varnish starts - defaults
- to the same amount as the threshold.
-
-Now we define the director.::
-
-  director example_director round-robin {
-        {
-                .backend = server1;
-        }
-        # server2 
-        {
-                .backend = server2;
-        }
-	
-        }
-
-You use this director just as you would use any other director or
-backend. Varnish will not send traffic to hosts that are marked as
-unhealthy. Varnish can also serve stale content if all the backends are
-down. See :ref:`users-guide-handling_misbehaving_servers` for more
-information on how to enable this.
-
-Please note that Varnish will keep probes active for all loaded
-VCLs. Varnish will coalesce probes that seem identical - so be careful
-not to change the probe config if you do a lot of VCL
-loading. Unloading the VCL will discard the probes.
diff --git a/doc/sphinx/users-guide/backend_servers.rst b/doc/sphinx/users-guide/backend_servers.rst
index 695a21a..4f721aa 100644
--- a/doc/sphinx/users-guide/backend_servers.rst
+++ b/doc/sphinx/users-guide/backend_servers.rst
@@ -23,7 +23,7 @@ We comment in this bit of text making the text look like.::
 
           backend default {
                 .host = "127.0.0.1";
-    		.port = "80";
+    		.port = "8080";
 	  }
 
 Now, this piece of configuration defines a backend in Varnish called
@@ -32,5 +32,166 @@ connect to port 8080 on localhost (127.0.0.1).
 
 Varnish can have several backends defined and can you can even join
 several backends together into clusters of backends for load balancing
-purposes.  XXX: ref
+purposes. 
+
+Multiple backends
+-----------------
+
+At some point you might need Varnish to cache content from several
+servers. You might want Varnish to map all the URL into one single
+host or not. There are lot of options.
+
+Lets say we need to introduce a Java application into out PHP web
+site. Lets say our Java application should handle URL beginning with
+/java/.
+
+We manage to get the thing up and running on port 8000. Now, lets have
+a look at the default.vcl.::
+
+  backend default {
+      .host = "127.0.0.1";
+      .port = "8080";
+  }
+
+We add a new backend.::
+
+  backend java {
+      .host = "127.0.0.1";
+      .port = "8000";
+  }
+
+Now we need tell where to send the difference URL. Lets look at vcl_recv.::
+
+  sub vcl_recv {
+      if (req.url ~ "^/java/") {
+          set req.backend = java;
+      } else {
+          set req.backend = default.
+      }
+  }
+
+It's quite simple, really. Lets stop and think about this for a
+moment. As you can see you can define how you choose backends based on
+really arbitrary data. You want to send mobile devices to a different
+backend? No problem. if (req.User-agent ~ /mobile/) .. should do the
+trick. 
+
+.. _users-guide-advanced_backend_servers-directors:
+
+Directors
+---------
+
+You can also group several backend into a group of backends. These
+groups are called directors. This will give you increased performance
+and resilience. You can define several backends and group them
+together in a director.::
+
+	 backend server1 {
+	     .host = "192.168.0.10";
+	 }
+	 backend server2{
+	     .host = "192.168.0.10";
+	 }
+
+Now we create the director.::
+
+       	director example_director round-robin {
+        {
+                .backend = server1;
+        }
+	# server2
+        {
+                .backend = server2;
+        }
+	# foo
+	}
+
+
+This director is a round-robin director. This means the director will
+distribute the incoming requests on a round-robin basis. There is
+also a *random* director which distributes requests in a, you guessed
+it, random fashion.
+
+But what if one of your servers goes down? Can Varnish direct all the
+requests to the healthy server? Sure it can. This is where the Health
+Checks come into play.
+
+.. _users-guide-advanced_backend_servers-health:
+
+Health checks
+-------------
+
+Lets set up a director with two backends and health checks. First lets
+define the backends.::
+
+       backend server1 {
+         .host = "server1.example.com";
+	 .probe = {
+                .url = "/";
+                .interval = 5s;
+                .timeout = 1 s;
+                .window = 5;
+                .threshold = 3;
+	   }
+         }
+       backend server2 {
+  	  .host = "server2.example.com";
+  	  .probe = {
+                .url = "/";
+                .interval = 5s;
+                .timeout = 1 s;
+                .window = 5;
+                .threshold = 3;
+	  }
+        }
+
+Whats new here is the probe. Varnish will check the health of each
+backend with a probe. The options are
+
+url
+ What URL should varnish request.
+
+interval
+ How often should we poll
+
+timeout
+ What is the timeout of the probe
+
+window
+ Varnish will maintain a *sliding window* of the results. Here the
+ window has five checks.
+
+threshold 
+ How many of the .window last polls must be good for the backend to be declared healthy.
+
+initial 
+ How many of the of the probes a good when Varnish starts - defaults
+ to the same amount as the threshold.
+
+Now we define the director.::
+
+  director example_director round-robin {
+        {
+                .backend = server1;
+        }
+        # server2 
+        {
+                .backend = server2;
+        }
+	
+        }
+
+You use this director just as you would use any other director or
+backend. Varnish will not send traffic to hosts that are marked as
+unhealthy. Varnish can also serve stale content if all the backends are
+down. See :ref:`users-guide-handling_misbehaving_servers` for more
+information on how to enable this.
+
+Please note that Varnish will keep probes active for all loaded
+VCLs. Varnish will coalesce probes that seem identical - so be careful
+not to change the probe config if you do a lot of VCL
+loading. Unloading the VCL will discard the probes.
+
+For more information on how to do this please see
+ref:`reference-vcl-director`.
 



More information about the varnish-commit mailing list