\na Load Balancer. You\u2019ll see a new top level tab in the Rancher UI
\ncalled \u201cBalancing\u201d from which you can create and access your load
\nbalancers.
![\"Screen](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2015\/04\/21135821\/Screen-Shot-2015-04-12-at-8.24.47-PM.png\")
<\/a>\nTo create a new load balancer click on + Add Load Balancer<\/em>. You\u2019ll
\nbe given a configuration screen to provide details on how you want the
\nload balancer to function.
<\/a>\nThere are a number of different options for configuration, and I\u2019ve
\ncreated a video demonstration to walk through the process.<\/p>\n
Updating an active Load Balancer<\/h3>\n
In some cases after your Load Balancer has been created, you might want ###<\/p>\n Health checks can be incredibly helpful when running a production Some applications require that a user continues to connect to the same The Load Balancer service is primarily used to help scale up This new load balancing support has plenty of independent value, but it
\nto change its settings – for example to add or remove listener ports,
\nconfigure a health check, or simply add more target containers. Rancher
\nperforms all the updates without any downtime for your application. To
\nupdate the Load Balancer, bring up the Load Balancer \u201cDetails\u201d view by
\nclicking on its name in the UI:
\n<\/a>
\nThen navigate to the toolbar of the setting you want to change, and
\nmake the update:
\n<\/a><\/p>\nUnderstanding Health Checks<\/h3>\n
\napplication. Health checks monitor the availability of target
\ncontainers, so that if one of the load balanced containers in your app
\nbecomes unresponsive, it can be excluded from the list of balanced
\nhosts, until its functioning again. You can delegate this task to the
\nRancher Load Balancer by configuring the health check on it from the UI.
\nJust provide a monitoring URL for the target container, as well as
\ncheck intervals and healthy and unhealthy response thresholds. You can
\nsee the UI for this in the image below.
\n<\/a><\/p>\nStickiness Policies<\/h3>\n
\nbackend server within the same login session. This persistence is
\nachieved by configuring Stickiness policy on the Load Balancer. With
\nstickiness, you can control whether the session cookie is provided by
\nthe application, or directly from the load balancer.<\/p>\nScaling your application<\/h3>\n
\napplications as you add additional targets to the load balancer.
\nHowever, to provide an additional layer of scaling, the load balancer
\nitself can also scale across multiple hosts, creating a clustered load
\nbalancing service. With the Load Balancer deployed on multiple hosts,
\nyou can use a Global Load Balancing service, such as Amazon Web
\nServices, Route 53, to distribute incoming traffic across load
\nbalancers. This can be especially useful when running load balancers in
\ndifferent physical locations. The diagram below explains how this can be
\ndone. <\/a><\/p>\nLoad Balancing and Service Discovery<\/h3>\n
\nwill also be an important part of the work we\u2019re doing on service
\ndiscovery, and support for Docker Compose. We\u2019re still working on this
\nand testing it, but you should start to see this functionality in
\nRancher over the next four to six weeks. If you\u2019d like to learn about
\nload balancing, Docker Compose, service discovery and running
\nmicroservices with Rancher, please join our next online meetup where
\nwe\u2019ll be covering all of these topics by clicking the button
\nbelow.\u00a0 Alena Prokharchyk @lemonjet https:\/\/github.com\/alena1108<\/a><\/p>\n