Simple Load Balancing with DNS on Linux
When you have server back ends built of multiple servers, such as clustered or mirrowed web or file servers, a load balancer provides a single point of entry. Large busy shops spend big money on high-end load balancers that perform a wide range of tasks: proxy, caching, health checks, SSL processing, configurable prioritization, traffic shaping, and lots more.
But you don’t want all that. You need a simple method for distributing workloads across all of your servers and providing a bit of failover and don’t care whether it is perfectly efficient. DNS round-robin and subdomain delegation with round-robin provide two simple methods to achieve this.
DNS round-robin is mapping multiple servers to the same hostname, so that when users visit foo.example.com multiple servers are available to handle their requests.
Subdomain delegation with round-robin is useful when you have multiple subdomains or when your servers are geographically dispersed. You have a primary nameserver, and then your subdomains have their own nameservers. Your primary nameserver refers all subdomain requests to their own nameservers. This usually improves response times, as the DNS protocol will automatically look for the fastest links.
Round-Robin DNS
Round-robin has nothing to do with robins. According to my favorite librarian, it was originally a French phrase, ruban rond, or round ribbon. Way back in olden times, French government officials signed grievance petitions in non-hierarchical circular, wavy, or spoke patterns to conceal whoever originated the petition.
Round-robin DNS is also non-hierarchical, a simple configuration that takes a list of servers and sends requests to each server in turn. It does not perform true load-balancing as it does not measure loads, and does no health checks, so if one of the servers is down, requests are still sent to that server. Its virtue lies in simplicity. If you have a little cluster of file or web servers and want to spread the load between them in the simplest way, then round-robin DNS is for you.
All you do is create multiple A or AAAA records, mapping multiple servers to a single host name. This BIND example uses both IPv4 and IPv6 private address classes:
fileserv.example.com. IN A 172.16.10.10 fileserv.example.com. IN A 172.16.10.11 fileserv.example.com. IN A 172.16.10.12 fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::10 fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::11 fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::12
Dnsmasq uses /etc/hosts for A and AAAA records:
172.16.1.10 fileserv fileserv.example.com 172.16.1.11 fileserv fileserv.example.com 172.16.1.12 fileserv fileserv.example.com fd02:faea:f561:8fa0:1::10 fileserv fileserv.example.com fd02:faea:f561:8fa0:1::11 fileserv fileserv.example.com fd02:faea:f561:8fa0:1::12 fileserv fileserv.example.com
Note that these examples are simplified, and there are multiple ways to resolve fully-qualified domain names, so please study up on configuring DNS.
Use the dig command to check your work. Replace ns.example.com with your name server:
$ dig @ns.example.com fileserv A fileserv AAA
That should display both IPv4 and IPv6 round-robin records.
Subdomain Delegation and Round-Robin
Subdomain delegation combined with round-robin is more work to set up, but it has some advantages. Use this when you have multiple subdomains or geographically-dispersed servers. Response times are often quicker, and a down server will not respond, so clients will not get hung up waiting for a reply. A short TTL, such as 60 seconds, helps this.
This approach requires multiple name servers. In the simplest scenario, you have a primary name server and two subdomains, each with its own name server. Configure your round-robin entries on the subdomain servers, then configure the delegations on your primary server.
In BIND on your primary name server, you’ll need at least two additional configurations, a zone statement, and A/AAAA records in your zone data file. The delegation looks something like this on your primary name server:
ns1.sub.example.com. IN A 172.16.1.20 ns1.sub.example.com. IN AAAA fd02:faea:f561:8fa0:1::20 ns2.sub.example.com. IN A 172.16.1.21 ns2.sub.example.com. IN AAA fd02:faea:f561:8fa0:1::21 sub.example.com. IN NS ns1.sub.example.com. sub.example.com. IN NS ns2.sub.example.com.
Then each of the subdomain servers have their own zone files. The trick here is for each server to return its own IP address. The zone statement in named.conf is the same on both servers:
Then the data files are the same, except that the A/AAAA records use the server’s own IP address. The SOA (start of authority) refers to the primary name server:
; first subdomain name server $ORIGIN sub.example.com. $TTL 60 sub.example.com IN SOA ns1.example.com. admin.example.com. ( 2018123456 ; serial 3H ; refresh 15 ; retry 3600000 ; expire ) sub.example.com. IN NS ns1.sub.example.com. sub.example.com. IN A 172.16.1.20 ns1.sub.example.com. IN AAAA fd02:faea:f561:8fa0:1::20
; second subdomain name server $ORIGIN sub.example.com. $TTL 60 sub.example.com IN SOA ns1.example.com. admin.example.com. ( 2018234567 ; serial 3H ; refresh 15 ; retry 3600000 ; expire ) sub.example.com. IN NS ns1.sub.example.com. sub.example.com. IN A 172.16.1.21 ns2.sub.example.com. IN AAAA fd02:faea:f561:8fa0:1::21
Next, make your round-robin entries on the subdomain name servers, and you’re done. Now you have multiple name servers handling requests for your subdomains. Again, BIND is complex and has multiple ways to do the same thing, so your homework is to ensure that your configuration fits with the way you use it.
Subdomain delegations are easier in Dnsmasq. On your primary server, add lines like this in dnsmasq.conf to point to the name servers for the subdomains:
server=/sub.example.com/172.16.1.20 server=/sub.example.com/172.16.1.21 server=/sub.example.com/fd02:faea:f561:8fa0:1::20 server=/sub.example.com/fd02:faea:f561:8fa0:1::21
Then configure round-robin on the subdomain name servers in /etc/hosts .
For way more details and help, refer to these resources:
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
Балансировка нагрузки с помощью round robin DNS
Управление ответами DNS (т. е. списком возвращенных IP-адресов) – хороший, хотя и очень противоречивый метод распространения приложения. Если вы хотите сократить расходы на оборудование и инфраструктуру, DNS может обеспечить высокую доступность.
Данное руководство поможет создать географически распределенное, высокодоступное приложение с минимальным простоем с помощью DNS.
Высокая доступность
Если от приложения зависит ваш бизнес, вы должны поддерживать его работу 24 часа в сутки 7 дней в неделю, без сбоев и простоя. К сожалению, горизонтальное масштабирование не всегда помогает избежать простоя (особенно если сбой произошел в центре обработки данных).
Разместив виртуальные серверы в разных центрах обработки в разных регионах, вы можете обеспечить более стабильную работу приложения.
Высокая доступность – это качество, присущее структурам, в которых нет единой точки отказа.
Примечание: Вы можете подключить плавающие IP-адреса. Плавающий IP-адрес – это общедоступный статический IP-адрес, который можно мгновенно присвоить другому серверу. Подробнее об этой функции читайте в статье Использование плавающих IP-адресов.
Структура развертывания высокодоступного приложения
Структура развертывания высокодоступного приложения зависит от обслуживания запросов из разных центров обработки данных.
Существует много способов реализации такой структуры, но проще всего, пожалуй, просто воспользоваться преимуществами DNS.
Базовая структура выглядит так:
________________
| |
| CLIENT |
| WEB BROWSER |
|________________|
||
||
_______\/_______
| |
| DNS SERVER |
|________________|
||
||
_______/ \_______
/ \
/ \
____________________ ____________________
| | | |
| SAN FRANCISCO | | SAN FRANCISCO |
|____________________| |____________________|
| ______________ | | ______________ |
| | | | | | | |
| | WEB SERVER | | | | WEB SERVER | |
| | LOAD BALANCE | | | | LOAD BALANCE | |
| | PROXY | | | | PROXY | |
| |_____ _____| | | |_____ _____| |
|________| |________| |________| |________|
|| __ __ ||
||<=====||==================||=====>||
\/ \/ \/ \/
____________________ ____________________
| | | |
| SAN FRANCISCO | | NEW YORK |
|____________________| |____________________|
| ______________ | | ______________ |
| | | | | | | |
| | APP SERVER | | | | APP SERVER | |
| |______ ______| | | |______ ______| |
| ______||______ | | ______||______ |
| | | | | | | |
| | DATABASE || DATABASE | |
| |______________| | | |______________| |
|____________________| |____________________|
Высокая доступность с помощью DNS
Когда пользователь вводит доменное имя веб-сайта, с помощью набора определенных правил (то есть протокола), веб-браузер подключается к серверам имен и запрашивает адреса машин, на которых размещен указанный веб-сайт. Получив IP-адрес, он отправляет запрос с некоторыми дополнительными данными на этот компьютер и отображает ответ.
DNS позволяет поддерживать несколько записей (даже одного вида), благодаря чему становится возможным перечислить несколько хостов.
Представьте ситуацию (как показано на приведенной выше схеме): вы указываете IP-адрес двух балансировщиков нагрузки или обратных прокси-серверов, расположенных в двух разных ЦОД, каждый из которых настроен для балансировки нагрузки между серверами приложений, которые также расположены в разных местах. Если один из центров обработки данных становится недоступным, веб-браузер клиента попытается использовать следующие записи IP-адресов, возвращаемые DNS-сервером, и повторить процесс для получения доступа к сайту.
Такая технология балансировки нагрузки называется round robin DNS.
На первый взгляд такая технология может показаться сложной. Попробуем подвести итоги:
- DNS может содержать несколько записей для одного и того же домена.
- DNS может возвращать список IP-адресов для одного и того же домена.
- Когда веб-браузер запрашивает сайт, он будет пробовать эти IP-адреса один за другим, пока не получит ответ.
- Эти IP-адреса должны указывать на не серверы приложений, а на балансировщики нагрузки или обратные прокси-серверы.
- Обратные прокси должны распределять нагрузку между несколькими серверами в разных ЦОД.
- Если центр обработки данных не работает и веб-браузер не может получить ответ от IP-адреса (то есть от балансировщика нагрузки), он попытается подключиться к другому адресу.
- Скорее всего, второй балансировщик нагрузки вернет ответ на запрос клиента (вероятность того, что в разных ЦОД одновременно случится сбой, очень мала).
- Серверы баз данных должны поддерживать репликацию.
Развертывание высокодоступного приложения
Примечание: Описанная ниже процедура не зависит от языка программирования или типа веб-сервера. Следуя этим инструкциям, вы можете достичь высокой доступности вне зависимости от фреймворка, веб-сервера или HTTP-сервера.
Настройка балансировки нагрузки или обратного прокси-сервера
Сначала нужно обеспечить балансировку нагрузки. Для этого подготовьте два (или больше) балансировщика нагрузки, которые смогут взаимодействовать с серверами приложений.
Создайте два сервера в двух разных ЦОД.
Чтобы обеспечить распределение нагрузки, установите Nginx, Apache или HAProxy.
Читайте также:
Узнайте IP-адрес балансировщиков.
Запись A преобразовывает домен (например www.example.com) в понятный машине IP-адрес.
Настроив два балансировщика, создайте две записи А.
Обычно это можно сделать с помощью панели управления во вкладке DNS.
После этого настройте серверы приложений. Вам понадобится два сервера в разных ЦОД.
Затем нужно настроить балансировщики нагрузки для распределения и проксирования запросов между серверами приложения. Это можно сделать с помощью этих руководств:
Затем нужно настроить базу данных.
В зависимости от выбранного вами сервера базы данных выполните одно из предложенных руководств на сервере БД и настройте репликацию.