OLD | NEW |
(Empty) | |
| 1 .. _elb_tut: |
| 2 |
| 3 ========================================================== |
| 4 An Introduction to boto's Elastic Load Balancing interface |
| 5 ========================================================== |
| 6 |
| 7 This tutorial focuses on the boto interface for `Elastic Load Balancing`_ |
| 8 from Amazon Web Services. This tutorial assumes that you have already |
| 9 downloaded and installed boto, and are familiar with the boto ec2 interface. |
| 10 |
| 11 .. _Elastic Load Balancing: http://aws.amazon.com/elasticloadbalancing/ |
| 12 |
| 13 Elastic Load Balancing Concepts |
| 14 ------------------------------- |
| 15 `Elastic Load Balancing`_ (ELB) is intimately connected with Amazon's `Elastic |
| 16 Compute Cloud`_ (EC2) service. Using the ELB service allows you to create a load |
| 17 balancer - a DNS endpoint and set of ports that distributes incoming requests |
| 18 to a set of EC2 instances. The advantages of using a load balancer is that it |
| 19 allows you to truly scale up or down a set of backend instances without |
| 20 disrupting service. Before the ELB service, you had to do this manually by |
| 21 launching an EC2 instance and installing load balancer software on it (nginx, |
| 22 haproxy, perlbal, etc.) to distribute traffic to other EC2 instances. |
| 23 |
| 24 Recall that the EC2 service is split into Regions, which are further |
| 25 divided into Availability Zones (AZ). |
| 26 For example, the US-East region is divided into us-east-1a, us-east-1b, |
| 27 us-east-1c, us-east-1d, and us-east-1e. You can think of AZs as data centers - |
| 28 each runs off a different set of ISP backbones and power providers. |
| 29 ELB load balancers can span multiple AZs but cannot span multiple regions. |
| 30 That means that if you'd like to create a set of instances spanning both the |
| 31 US and Europe Regions you'd have to create two load balancers and have some |
| 32 sort of other means of distributing requests between the two load balancers. |
| 33 An example of this could be using GeoIP techniques to choose the correct load |
| 34 balancer, or perhaps DNS round robin. Keep in mind also that traffic is |
| 35 distributed equally over all AZs the ELB balancer spans. This means you should |
| 36 have an equal number of instances in each AZ if you want to equally distribute |
| 37 load amongst all your instances. |
| 38 |
| 39 .. _Elastic Compute Cloud: http://aws.amazon.com/ec2/ |
| 40 |
| 41 Creating a Connection |
| 42 --------------------- |
| 43 |
| 44 The first step in accessing ELB is to create a connection to the service. |
| 45 |
| 46 >>> import boto |
| 47 >>> conn = boto.connect_elb( |
| 48 aws_access_key_id='YOUR-KEY-ID-HERE', |
| 49 aws_secret_access_key='YOUR-SECRET-HERE' |
| 50 ) |
| 51 |
| 52 |
| 53 A Note About Regions and Endpoints |
| 54 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 55 |
| 56 Like EC2, the ELB service has a different endpoint for each region. By default |
| 57 the US East endpoint is used. To choose a specific region, instantiate the |
| 58 ELBConnection object with that region's information. |
| 59 |
| 60 >>> from boto.regioninfo import RegionInfo |
| 61 >>> reg = RegionInfo( |
| 62 name='eu-west-1', |
| 63 endpoint='elasticloadbalancing.eu-west-1.amazonaws.com' |
| 64 ) |
| 65 >>> conn = boto.connect_elb( |
| 66 aws_access_key_id='YOUR-KEY-ID-HERE', |
| 67 aws_secret_access_key='YOUR-SECRET-HERE', |
| 68 region=reg |
| 69 ) |
| 70 |
| 71 Another way to connect to an alternative region is like this: |
| 72 |
| 73 >>> import boto.ec2.elb |
| 74 >>> elb = boto.ec2.elb.connect_to_region('eu-west-1') |
| 75 |
| 76 Here's yet another way to discover what regions are available and then |
| 77 connect to one: |
| 78 |
| 79 >>> import boto.ec2.elb |
| 80 >>> regions = boto.ec2.elb.regions() |
| 81 >>> regions |
| 82 [RegionInfo:us-east-1, |
| 83 RegionInfo:ap-northeast-1, |
| 84 RegionInfo:us-west-1, |
| 85 RegionInfo:ap-southeast-1, |
| 86 RegionInfo:eu-west-1] |
| 87 >>> elb = regions[-1].connect() |
| 88 |
| 89 Alternatively, edit your boto.cfg with the default ELB endpoint to use:: |
| 90 |
| 91 [Boto] |
| 92 elb_region_name = eu-west-1 |
| 93 elb_region_endpoint = elasticloadbalancing.eu-west-1.amazonaws.com |
| 94 |
| 95 Getting Existing Load Balancers |
| 96 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 97 |
| 98 To retrieve any exiting load balancers: |
| 99 |
| 100 >>> conn.get_all_load_balancers() |
| 101 [LoadBalancer:load-balancer-prod, LoadBalancer:load-balancer-staging] |
| 102 |
| 103 You can also filter by name |
| 104 |
| 105 >>> conn.get_all_load_balancers(load_balancer_names=['load-balancer-prod']) |
| 106 [LoadBalancer:load-balancer-prod] |
| 107 |
| 108 :py:meth:`get_all_load_balancers <boto.ec2.elb.ELBConnection.get_all_load_balanc
ers>` |
| 109 returns a :py:class:`boto.resultset.ResultSet` that contains instances |
| 110 of :class:`boto.ec2.elb.loadbalancer.LoadBalancer`, each of which abstracts |
| 111 access to a load balancer. :py:class:`ResultSet <boto.resultset.ResultSet>` |
| 112 works very much like a list. |
| 113 |
| 114 >>> balancers = conn.get_all_load_balancers() |
| 115 >>> balancers[0] |
| 116 [LoadBalancer:load-balancer-prod] |
| 117 |
| 118 Creating a Load Balancer |
| 119 ------------------------ |
| 120 To create a load balancer you need the following: |
| 121 #. The specific **ports and protocols** you want to load balancer over, and wha
t port |
| 122 you want to connect to all instances. |
| 123 #. A **health check** - the ELB concept of a *heart beat* or *ping*. ELB will u
se this health |
| 124 check to see whether your instances are up or down. If they go down, the loa
d balancer |
| 125 will no longer send requests to them. |
| 126 #. A **list of Availability Zones** you'd like to create your load balancer ove
r. |
| 127 |
| 128 Ports and Protocols |
| 129 ^^^^^^^^^^^^^^^^^^^ |
| 130 An incoming connection to your load balancer will come on one or more ports - |
| 131 for example 80 (HTTP) and 443 (HTTPS). Each can be using a protocol - |
| 132 currently, the supported protocols are TCP and HTTP. We also need to tell the |
| 133 load balancer which port to route connects *to* on each instance. For example, |
| 134 to create a load balancer for a website that accepts connections on 80 and 443, |
| 135 and that routes connections to port 8080 and 8443 on each instance, you would |
| 136 specify that the load balancer ports and protocols are: |
| 137 |
| 138 * 80, 8080, HTTP |
| 139 * 443, 8443, TCP |
| 140 |
| 141 This says that the load balancer will listen on two ports - 80 and 443. |
| 142 Connections on 80 will use an HTTP load balancer to forward connections to port |
| 143 8080 on instances. Likewise, the load balancer will listen on 443 to forward |
| 144 connections to 8443 on each instance using the TCP balancer. We need to |
| 145 use TCP for the HTTPS port because it is encrypted at the application |
| 146 layer. Of course, we could specify the load balancer use TCP for port 80, |
| 147 however specifying HTTP allows you to let ELB handle some work for you - |
| 148 for example HTTP header parsing. |
| 149 |
| 150 .. _elb-configuring-a-health-check: |
| 151 |
| 152 Configuring a Health Check |
| 153 ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 154 A health check allows ELB to determine which instances are alive and able to |
| 155 respond to requests. A health check is essentially a tuple consisting of: |
| 156 |
| 157 * *Target*: What to check on an instance. For a TCP check this is comprised of:
: |
| 158 |
| 159 TCP:PORT_TO_CHECK |
| 160 |
| 161 Which attempts to open a connection on PORT_TO_CHECK. If the connection opens |
| 162 successfully, that specific instance is deemed healthy, otherwise it is marke
d |
| 163 temporarily as unhealthy. For HTTP, the situation is slightly different:: |
| 164 |
| 165 HTTP:PORT_TO_CHECK/RESOURCE |
| 166 |
| 167 This means that the health check will connect to the resource /RESOURCE on |
| 168 PORT_TO_CHECK. If an HTTP 200 status is returned the instance is deemed healt
hy. |
| 169 * *Interval*: How often the check is made. This is given in seconds and default
s |
| 170 to 30. The valid range of intervals goes from 5 seconds to 600 seconds. |
| 171 * *Timeout*: The number of seconds the load balancer will wait for a check to |
| 172 return a result. |
| 173 * *Unhealthy threshold*: The number of consecutive failed checks to deem the |
| 174 instance as being dead. The default is 5, and the range of valid values lies |
| 175 from 2 to 10. |
| 176 |
| 177 The following example creates a health check called *instance_health* that |
| 178 simply checks instances every 20 seconds on port 80 over HTTP at the |
| 179 resource /health for 200 successes. |
| 180 |
| 181 >>> from boto.ec2.elb import HealthCheck |
| 182 >>> hc = HealthCheck( |
| 183 interval=20, |
| 184 healthy_threshold=3, |
| 185 unhealthy_threshold=5, |
| 186 target='HTTP:8080/health' |
| 187 ) |
| 188 |
| 189 Putting It All Together |
| 190 ^^^^^^^^^^^^^^^^^^^^^^^ |
| 191 |
| 192 Finally, let's create a load balancer in the US region that listens on ports |
| 193 80 and 443 and distributes requests to instances on 8080 and 8443 over HTTP |
| 194 and TCP. We want the load balancer to span the availability zones |
| 195 *us-east-1a* and *us-east-1b*: |
| 196 |
| 197 >>> regions = ['us-east-1a', 'us-east-1b'] |
| 198 >>> ports = [(80, 8080, 'http'), (443, 8443, 'tcp')] |
| 199 >>> lb = conn.create_load_balancer('my-lb', regions, ports) |
| 200 >>> # This is from the previous section. |
| 201 >>> lb.configure_health_check(hc) |
| 202 |
| 203 The load balancer has been created. To see where you can actually connect to |
| 204 it, do: |
| 205 |
| 206 >>> print lb.dns_name |
| 207 my_elb-123456789.us-east-1.elb.amazonaws.com |
| 208 |
| 209 You can then CNAME map a better name, i.e. www.MYWEBSITE.com to the |
| 210 above address. |
| 211 |
| 212 Adding Instances To a Load Balancer |
| 213 ----------------------------------- |
| 214 |
| 215 Now that the load balancer has been created, there are two ways to add |
| 216 instances to it: |
| 217 |
| 218 #. Manually, adding each instance in turn. |
| 219 #. Mapping an autoscale group to the load balancer. Please see the |
| 220 :doc:`Autoscale tutorial <autoscale_tut>` for information on how to do this. |
| 221 |
| 222 Manually Adding and Removing Instances |
| 223 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 224 |
| 225 Assuming you have a list of instance ids, you can add them to the load balancer |
| 226 |
| 227 >>> instance_ids = ['i-4f8cf126', 'i-0bb7ca62'] |
| 228 >>> lb.register_instances(instance_ids) |
| 229 |
| 230 Keep in mind that these instances should be in Security Groups that match the |
| 231 internal ports of the load balancer you just created (for this example, they |
| 232 should allow incoming connections on 8080 and 8443). |
| 233 |
| 234 To remove instances: |
| 235 |
| 236 >>> lb.deregister_instances(instance_ids) |
| 237 |
| 238 Modifying Availability Zones for a Load Balancer |
| 239 ------------------------------------------------ |
| 240 |
| 241 If you wanted to disable one or more zones from an existing load balancer: |
| 242 |
| 243 >>> lb.disable_zones(['us-east-1a']) |
| 244 |
| 245 You can then terminate each instance in the disabled zone and then deregister th
en from your load |
| 246 balancer. |
| 247 |
| 248 To enable zones: |
| 249 |
| 250 >>> lb.enable_zones(['us-east-1c']) |
| 251 |
| 252 Deleting a Load Balancer |
| 253 ------------------------ |
| 254 |
| 255 >>> lb.delete() |
| 256 |
| 257 |
OLD | NEW |