Getting Started with NodeBalancers
Nearly all applications that are built using Linodes can benefit from load balancing, and load balancing itself is the key to expanding an application to larger numbers of users. Linode now provides NodeBalancers, which can ease the deployment and administration of a load balancer.
NodeBalancers are built for high availability and designed to be "set and forgotten". The most difficult part of transitioning to a NodeBalancer, in fact, is simply making sure your application works well with the new environment. In this guide, we will examine a common use case: using a NodeBalancer to load balance a Web site and prepare it for scaling to thousands of users.
This guide attempts to give a high-level overview of transitioning to a NodeBalancer, but makes no attempt to document or explain the underlying parts of the application NodeBalancer will be balancing; for more information on various applications that might be useful behind NodeBalancer review the rest of the Linode Library.
Table of Contents
A NodeBalancer listens on a public IP address for incoming connections, then uses configurable rules to select a backend node (out of one or more) to which to send the connection. In HTTP mode, NodeBalancers can reach into the incoming Web request and make decisions based on it.
Put together, a NodeBalancer allows the incoming load to your application to be spread over any number of Linodes. This, however, comes with new challenges; many Web applications have sessions that do not exist outside of the backend node. For this reason, NodeBalancers allow you to specify that the same client should land on the same backend Linode.
For example purposes, this guide will start with a typical, simple Web application.
There are a few drawbacks to making this application scale, namely that any modifications require updating DNS (which takes time) or inflicting downtime upon users. NodeBalancer can step in and bring administrative ease to this application by becoming its front face.
Now, backend Linodes can be added or removed to the work load seamlessly, without end users noticing any downtime.
Additionally, NodeBalancer will watch each backend for failure, rerouting users to working backends transparently and without any manual intervention.
First, the backend Linode currently powering the Web site must have a private IP address. If it does not, add one now and configure the Linode for static networking -- this will then be a good opportunity to do the same for the database server, since private network traffic is unbilled. Reboot if necessary, and configure your Web application to respond on the private IP address, if it is not already.
Visit the NodeBalancers tab in the Linode Manager.
For the example Web application, only one NodeBalancer is needed. Add one, and choose the same datacenter that your backend Linodes are located in. Once purchased, you will be able to see the public IP address that has been assigned to your NodeBalancer.
A NodeBalancer is configured using ports, and the example Web application uses only one: port 80 for regular HTTP traffic.
For the traditional Web application, these settings are a good start. HTTP cookie stickiness is preferred so that the same client will always land on the same backend -- for a simple Web application that keeps sessions in memory, this is necessary to avoid session errors on clients.
Note
If you select the HTTPS protocol, two new fields will appear where you can add your SSL certificate (and chained certificates) and passphraseless private key.
Every ten seconds, NodeBalancer will request the root of the Web application and look for a valid response code. With the current setup, there is only one backend node (which we will add shortly); if the backend goes down, NodeBalancer will serve a plain 503 Service Unavailable error page. This is more desirable than refusing connections or making browsers wait for a timeout.
Now add the single backend node to the NodeBalancer's configuration. Point this at the private IP address of your Web server Linode.
The configuration changes that you just made will take a few moments to be reflected by your NodeBalancer. Once the changes have gone through, Status will update from Unknown to, if everything is configured on your backend correctly, UP.
If the backend remains DOWN, check to make sure that your Web application is configured to respond on the Linode's private IP address. There might be a virtual host mismatch as well -- check the notes in the next section.
Now that the backend is up, go directly to your NodeBalancer's IP address in a browser; you should see your Web application as the NodeBalancer proxies the traffic through.
That is enough to configure the NodeBalancer. For HTTPS/SSL configurations, use the HTTPS protocol and provide a key and certificate.
You might not see the web application that you expect when you go directly to the NodeBalancer's IP address. This is due to virtual hosts, and is not an issue unique to NodeBalancers. In the default configurations of many Web servers, an application might only be configured to respond for certain hostnames. This can impact testing NodeBalancers as well as the behavior of their health checks.
It is important to configure the "default" virtual host in your Web server to point at something useful. NodeBalancer will pass the Host header from a browser untouched, so virtual hosts will work entirely normally once you are pointing a domain at the NodeBalancer. It is only mentioned here because testing NodeBalancers can demonstrate quirks in the Web server's configuration, particularly when browsing by the NodeBalancer's IP address.
Note
Health checks are transmitted with a Host header (in HTTP/1.0 mode).
Your NodeBalancer is now working and is able to pass traffic to your Web application. It is important to note at this point that configuring the NodeBalancer has not impacted your application's normal operations at all -- you can test NodeBalancer without your users ever knowing. The only exception to this would be to add a private IP address, if it was necessary to do so.
Once you are satisfied that NodeBalancer is working normally, you can switch your Web application's traffic over to it through DNS. On the NodeBalancer's overview, you can see its IP address as well as a hostname that resolves to that IP address. For nearly all cases, we recommend using the hostname as a CNAME; if for any unforeseen reason it becomes necessary to change your IP address, the change will happen automatically and without intervention from you.
Remove any record for www.example.org, then add a CNAME for www.example.org to your NodeBalancer's hostname.
"Root" domains, such as example.org as opposed to www.example.org, cannot use a CNAME. An A and AAAA record must be used instead. Your NodeBalancer comes with an IPv6 address; including an AAAA record is strongly recommended in addition to the A record to terminate IPv6 for your visitors.
Remove any A and AAAA record for example.org, then add your NodeBalancer's IPv4 address as an A record for the root domain.
Also add an AAAA record for the IPv6 address.
Once the DNS changes propagate, traffic will begin flowing through the NodeBalancer. At this point, you will want to wait at least 24 hours for all caches to catch up to the NodeBalancer before proceeding.
Congratulations! You have now configured a NodeBalancer and transitioned traffic over to it. All of the benefits of NodeBalancer are now available to you, such as adding backends to accommodate load.
On another Linode, make an exact copy of your current Web server. The Linode backups service can be instrumental for doing so, as a snapshot can be restored to any other Linode. Once you have another backend ready, simply repeat the earlier process to add it to the NodeBalancer configuration.
Once the configuration is sent to the backend, users will be transparently balanced over the two Linodes and each will be monitored for health. This configuration is very easy to work with, as upgrades can be rolled out to each backend without disrupting service and backends can be taken in and out of rotation at will.
This is just the beginning; NodeBalancers are extremely flexible and cater to a lot of needs. From here, the API can be used to add many backends. Multiple ports on one backend can be balanced for speciality setups. Additionally, new tools like memcached can be introduced to the application to allow session stickiness to become irrelevant.
NodeBalancers are built for high availability and designed to be "set and forgotten". The most difficult part of transitioning to a NodeBalancer, in fact, is simply making sure your application works well with the new environment. In this guide, we will examine a common use case: using a NodeBalancer to load balance a Web site and prepare it for scaling to thousands of users.
This guide attempts to give a high-level overview of transitioning to a NodeBalancer, but makes no attempt to document or explain the underlying parts of the application NodeBalancer will be balancing; for more information on various applications that might be useful behind NodeBalancer review the rest of the Linode Library.
Table of Contents
Overview
A NodeBalancer listens on a public IP address for incoming connections, then uses configurable rules to select a backend node (out of one or more) to which to send the connection. In HTTP mode, NodeBalancers can reach into the incoming Web request and make decisions based on it.
Put together, a NodeBalancer allows the incoming load to your application to be spread over any number of Linodes. This, however, comes with new challenges; many Web applications have sessions that do not exist outside of the backend node. For this reason, NodeBalancers allow you to specify that the same client should land on the same backend Linode.
For example purposes, this guide will start with a typical, simple Web application.
There are a few drawbacks to making this application scale, namely that any modifications require updating DNS (which takes time) or inflicting downtime upon users. NodeBalancer can step in and bring administrative ease to this application by becoming its front face.Now, backend Linodes can be added or removed to the work load seamlessly, without end users noticing any downtime.Additionally, NodeBalancer will watch each backend for failure, rerouting users to working backends transparently and without any manual intervention.Configuring a NodeBalancer
First, the backend Linode currently powering the Web site must have a private IP address. If it does not, add one now and configure the Linode for static networking -- this will then be a good opportunity to do the same for the database server, since private network traffic is unbilled. Reboot if necessary, and configure your Web application to respond on the private IP address, if it is not already.
Visit the NodeBalancers tab in the Linode Manager.
For the example Web application, only one NodeBalancer is needed. Add one, and choose the same datacenter that your backend Linodes are located in. Once purchased, you will be able to see the public IP address that has been assigned to your NodeBalancer.
A NodeBalancer is configured using ports, and the example Web application uses only one: port 80 for regular HTTP traffic.
For the traditional Web application, these settings are a good start. HTTP cookie stickiness is preferred so that the same client will always land on the same backend -- for a simple Web application that keeps sessions in memory, this is necessary to avoid session errors on clients.Note
If you select the HTTPS protocol, two new fields will appear where you can add your SSL certificate (and chained certificates) and passphraseless private key.
Every ten seconds, NodeBalancer will request the root of the Web application and look for a valid response code. With the current setup, there is only one backend node (which we will add shortly); if the backend goes down, NodeBalancer will serve a plain 503 Service Unavailable error page. This is more desirable than refusing connections or making browsers wait for a timeout.
Now add the single backend node to the NodeBalancer's configuration. Point this at the private IP address of your Web server Linode.The configuration changes that you just made will take a few moments to be reflected by your NodeBalancer. Once the changes have gone through, Status will update from Unknown to, if everything is configured on your backend correctly, UP.
If the backend remains DOWN, check to make sure that your Web application is configured to respond on the Linode's private IP address. There might be a virtual host mismatch as well -- check the notes in the next section.Now that the backend is up, go directly to your NodeBalancer's IP address in a browser; you should see your Web application as the NodeBalancer proxies the traffic through.
That is enough to configure the NodeBalancer. For HTTPS/SSL configurations, use the HTTPS protocol and provide a key and certificate.A Note about Virtual Hosts
You might not see the web application that you expect when you go directly to the NodeBalancer's IP address. This is due to virtual hosts, and is not an issue unique to NodeBalancers. In the default configurations of many Web servers, an application might only be configured to respond for certain hostnames. This can impact testing NodeBalancers as well as the behavior of their health checks.
It is important to configure the "default" virtual host in your Web server to point at something useful. NodeBalancer will pass the Host header from a browser untouched, so virtual hosts will work entirely normally once you are pointing a domain at the NodeBalancer. It is only mentioned here because testing NodeBalancers can demonstrate quirks in the Web server's configuration, particularly when browsing by the NodeBalancer's IP address.
Note
Health checks are transmitted with a Host header (in HTTP/1.0 mode).
Putting the NodeBalancer in Charge
Your NodeBalancer is now working and is able to pass traffic to your Web application. It is important to note at this point that configuring the NodeBalancer has not impacted your application's normal operations at all -- you can test NodeBalancer without your users ever knowing. The only exception to this would be to add a private IP address, if it was necessary to do so.
Once you are satisfied that NodeBalancer is working normally, you can switch your Web application's traffic over to it through DNS. On the NodeBalancer's overview, you can see its IP address as well as a hostname that resolves to that IP address. For nearly all cases, we recommend using the hostname as a CNAME; if for any unforeseen reason it becomes necessary to change your IP address, the change will happen automatically and without intervention from you.
Remove any record for www.example.org, then add a CNAME for www.example.org to your NodeBalancer's hostname.
"Root" domains, such as example.org as opposed to www.example.org, cannot use a CNAME. An A and AAAA record must be used instead. Your NodeBalancer comes with an IPv6 address; including an AAAA record is strongly recommended in addition to the A record to terminate IPv6 for your visitors.
Remove any A and AAAA record for example.org, then add your NodeBalancer's IPv4 address as an A record for the root domain.
Also add an AAAA record for the IPv6 address.
Once the DNS changes propagate, traffic will begin flowing through the NodeBalancer. At this point, you will want to wait at least 24 hours for all caches to catch up to the NodeBalancer before proceeding.
Congratulations! You have now configured a NodeBalancer and transitioned traffic over to it. All of the benefits of NodeBalancer are now available to you, such as adding backends to accommodate load.
On another Linode, make an exact copy of your current Web server. The Linode backups service can be instrumental for doing so, as a snapshot can be restored to any other Linode. Once you have another backend ready, simply repeat the earlier process to add it to the NodeBalancer configuration.
Once the configuration is sent to the backend, users will be transparently balanced over the two Linodes and each will be monitored for health. This configuration is very easy to work with, as upgrades can be rolled out to each backend without disrupting service and backends can be taken in and out of rotation at will.
This is just the beginning; NodeBalancers are extremely flexible and cater to a lot of needs. From here, the API can be used to add many backends. Multiple ports on one backend can be balanced for speciality setups. Additionally, new tools like memcached can be introduced to the application to allow session stickiness to become irrelevant.
Nhận xét
Đăng nhận xét