Неважно, ведете ли вы небольшой блог, большое приложение или API; Вы никогда не хотите, чтобы он был в автономном режиме.
Единственная точка отказа - это любая часть вашей инфраструктуры, которая в случае сбоя приведет к простою. Примером может быть использование одного сервера для размещения как вашего веб-сервера, так и вашей базы данных. Отключения часто вызваны этими единичными точками отказа, и мы хотим спроектировать нашу инфраструктуру, чтобы избежать таких ситуаций.
Инфраструктура высокой доступности не имеет единой точки отказа. Обычно это означает, что ваша инфраструктура разделена на службы и работает с каждой службой на нескольких серверах. Если происходит сбой одного сервера, есть другие серверы, доступные для обработки запросов. Конфигурация с высокой доступностью важна не только для избыточности, она также будет быстрее и экономичнее при масштабировании вашей инфраструктуры.
Представьте себе веб-сервис, содержащий ваши файлы. Теперь представьте, что он работает на трех независимых серверах. У нас есть несколько неотложных проблем. Как пользователи будут иметь доступ к этим серверам? Мы могли бы добавить записи DNS для каждого из независимых серверов. К сожалению, пользователи будут перенаправлены на серверы случайным образом и могут быть отправлены на сервер, который находится в автономном режиме.
Мы можем избежать этих ловушек, добавив балансировщик нагрузки в нашу инфраструктуру. Балансировщик нагрузки будет выполнять проверки работоспособности на каждом из серверов, которые он имеет в своей конфигурации. Если сервер находится в автономном режиме, балансировщик нагрузки не будет отправлять на него запросы пользователей. Балансировщик нагрузки повышает производительность за счет более эффективной маршрутизации пользователей на лучший доступный сервер.
Еще одно беспокойство, которое у нас возникнет при выполнении этого добавления, - убедиться, что сам балансировщик нагрузки не является единственной точкой отказа. Мы подумали об этом и имеем два полных решения, которые в высшей степени доступны на уровне балансировки нагрузки и на внутренних серверах.
Наша установка
В этой главе мы рассмотрим два способа развертывания решения с балансировкой нагрузки на нескольких веб-серверах. К концу этого раздела (главы 4–6) у нас будет несколько балансировщиков нагрузки, настроенных перед веб-службами и службами баз данных, что гарантирует отсутствие единой точки отказа.
Существует несколько способов настройки балансировки нагрузки. Мы рассмотрим два примера настройки, каждая из которых обслуживает веб-сервис Nginx на сервере.
Первое решение использует DigitalOcean Load Balancers, которые являются высокодоступной службой, которая автоматически обрабатывает восстановление после отказа. Они также включают возможность направлять трафик на капли на основе tags вместо списка вручную, что упрощает масштабирование.
Второе решение - это более настраиваемое решение для балансировки нагрузки с использованием HAProxy и DigitalOcean плавающих IP-адресов, которые представляют собой статические IP-адреса, которые можно назначать и переназначать в пределах регион автоматически с помощью панели управления или API. Вы можете использовать их для перенаправления трафика на резервный балансировщик нагрузки в случае сбоя основного.
Поскольку мы впервые используем Terraform и Ansible в этой книге, мы несколько раз пройдемся по этому разделу вручную, чтобы дать вам опыт создания собственных проектов вручную. По мере продвижения к более сложным настройкам в следующей главе мы автоматизируем большую часть конфигурации.
Использование балансировщиков нагрузки DigitalOcean
Настройка балансировщика нагрузки DigitalOcean
На контроллере Droplet перейдите в the каталог для этой главы в нашем репозитории.
cd /root/navigators-guide/example-code/02-scale/ch04/digitalocean_loadbalancerВ этом каталоге есть a `+ terraform.tfvars.sample + `файл. Этот образец файла содержит комментарии и заметки, которые помогут вам найти необходимую информацию. Без комментариев файл выглядит так:
do_token = ""
project = "DO-LB"
region = "sfo2"
image_slug = "debian-9-x64"
keys = ""
private_key_path = ""
ssh_fingerprint = ""
public_key = ""Это создаст балансировщик нагрузки DigitalOcean вместе с несколькими каплями, работающими под управлением Nginx. Каждый веб-сервер будет отображать простое приветственное сообщение с именем хоста отдельного Droplet.
Заполните переменные в соответствии с инструкциями в комментариях, затем переименуйте файл в + terraform.tfvars +.
mv terraform.tfvars.sample terraform.tfvarsЭта конфигурация не требует сертификата TLS, но его можно добавить в балансировщик нагрузки DigitalOcean. Функция балансировки нагрузки DigitalOcean также имеет интеграцию с Let Encrypt, которая предоставляет сертификаты бесплатно. Для Lets Encrypt требуется доменное имя, зарегистрированное и добавленное в вашу учетную запись DigitalOcean.
Затем подготовьте и выполните развертывание Terraform. Сначала проанализируйте файлы плана и модули с помощью + terraform init +. При желании вы можете запустить + terraform plan +, чтобы увидеть, что произойдет, когда вы запустите реальный скрипт. Когда вы будете готовы, запустите + terraform apply +, чтобы выполнить запросы на создание через API DigitalOcean.
terraform init
terraform applyВам нужно подтвердить выполнение, введя + yes +, и вы получите уведомление, когда заявка будет завершена.
На этом этапе вы можете посетить публичный IP-адрес своего балансировщика нагрузки (который вы можете получить с помощью + terraform show +) в своем браузере, чтобы увидеть пример содержимого с ваших веб-серверов.
Terraform также может автоматически удалить ваш кластер с помощью опции + destroy +. Вы можете использовать этот рабочий процесс для быстрого тестирования, но знайте, что любые данные, сохраненные в кластере, будут удалены. * Опция + destroy + удалит ваш кластер. * Это самый быстрый способ очиститься от работы, которую мы делаем в этой главе. Вы можете повторно запустить + apply + для генерации нового кластера.
Прежде чем разбирать этот пример кластера, давайте проверим, что он действительно высокодоступен, как мы и ожидали.
Тестирование доступности кластера
Чтобы проверить доступность внутренних веб-серверов, мы можем отключить один сервер, постоянно запрашивая подключения от балансировщика нагрузки. Если соединения будут продолжаться, мы узнаем, что служба осталась в сети, несмотря на сбой сервера. (Мы не можем проверить отказоустойчивость самого Load Balancer, потому что он работает как служба, то есть у вас нет или вам не нужен прямой доступ к его отдельным компонентам.)
Выполните следующую команду в терминале, который будет подключаться к балансировщику нагрузки один раз в секунду.
while true; do curl -k load_balancer_ip; sleep 1; doneВы увидите непрерывный вывод, как это:
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!Попробуйте отключить одну из внутренних капель. Когда Droplet находится в автономном режиме, вы все равно должны увидеть тест, возвращающий действительные ответы от других ваших бэкэндов балансировщика нагрузки. Вы заметите, что выключенная капелька больше не отвечает. Если вы включите его снова, вы увидите, что он автоматически добавляется в ротацию после прохождения настроенных проверок балансировщика нагрузки.
_ (Если вам нужна помощь в остановке текущего теста, вы можете выйти из цикла с помощью команды клавиатуры + CTRL-C +) _
Масштабирование кластера
Первоначальная настройка кластера использует 3 внутренних капли. Настройка количества внутренних капель находится в объявлении переменной по умолчанию в файле variables.tf. Мы можем переопределить, добавив строку в + terraform.tfvars + с переменной + node_count +, установленной в 5. Как только линия будет добавлена, вам нужно будет повторно применить план Terraform.
terraform applyТерраформ действительно сияет здесь. Он обрабатывает логику для изменения количества капель на основе этой переменной, поэтому он автоматически создает или уничтожает капли при увеличении или уменьшении переменной + node_count +.
В терминале с + curl + к вашему балансировщику нагрузки посмотрите на результат. Как только новые капли будут подготовлены, вы увидите, что они автоматически начинают отвечать.
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-04!
Welcome to DO-LB-backend-05!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-04!
Welcome to DO-LB-backend-05!
Welcome to DO-LB-backend-01!Прежде чем двигаться дальше, вы захотите уничтожить этот тестовый проект. Terraform сохраняет текущее состояние плана в текущем рабочем каталоге. Когда вы уничтожаете ресурсы через Terraform, он автоматически очищает состояние.
terraform destroyИспользование HAProxy и плавающего IP-адреса DigitalOcean
Развертывание пользовательского решения для балансировки нагрузки может быть правильным выбором. Есть некоторые параметры, которые DigitalOcean Load Balancer не поддерживает в настоящее время. Примерами этого могут быть размещение нескольких сайтов или приложений в качестве бэкэндов, несколько сертификатов TLS, поддержка протокола прокси или настройка определенных параметров TCP.
В этом примере используются балансировщики нагрузки HAProxy v1.8, кластеризованные вместе с использованием плавающего IP-адреса DigitalOcean для отработки отказа.
Настройка HAProxy
На контроллере Droplet перейдите в the каталог для этой главы в нашем репозитории.
cd /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancerВ этом каталоге есть a `+ terraform.tfvars.sample + `файл. Этот образец файла содержит комментарии и заметки, которые помогут вам найти необходимую информацию. Без комментариев файл выглядит так:
do_token = ""
project = "HAPROXY-LB"
region = "sfo2"
image_slug = "debian-9-x64"
keys = ""
private_key_path = ""
ssh_fingerprint = ""
public_key = ""Заполните переменные в соответствии с инструкциями в комментариях, затем переименуйте файл в + terraform.tfvars +.
mv terraform.tfvars.sample terraform.tfvarsЗатем подготовьте и выполните развертывание Terraform. Сначала проанализируйте файлы плана и модули с помощью + terraform init +. При желании вы можете запустить + terraform plan +, чтобы увидеть, что произойдет, когда вы запустите реальный скрипт. Когда вы будете готовы, запустите + terraform apply +, чтобы выполнить запросы на создание через API DigitalOcean.
terraform init
terraform applyВам нужно подтвердить выполнение, введя + yes +, и вы получите уведомление, когда заявка будет завершена.
Если вы запустите + terraform show + сейчас, вы сможете увидеть развернутые ресурсы. Каждый набор ресурсов (т.е. Капли) помещается в имя группы в соответствии с именем ресурса в файле конфигурации Terraform. В этом примере the + haproxy.tf + file ресурс Декларация определяет эти группы.
Три группы: + load_balancer + для HAProxy, + web_node + для Nginx и + fip + для плавающего IP. Вы можете посмотреть с помощью + terraform-inventory -inventory +, чтобы получить Ansible инвентаризацию в формате INI, или вывести JSON с опцией + -list.
На этом этапе необходимые вам капли созданы и работают, но их все еще необходимо настроить.
Конфигурирование капель с помощью Ansible
Мы собираемся автоматизировать настройку капель с помощью Ansible. У нас есть базовая книга воспроизведения Ansible, предварительно настроенная для загрузки нескольких ролей Ansible. Вы найдете эти Ansible роли, перечисленные в файле the файл + needs.yml + . Вам не нужно устанавливать их один за другим; Вы можете скачать необходимые роли с Ansible Galaxy.
Эта команда помещает роли в каталог + role +.
ansible-galaxy install -r requirements.ymlДля этой роли нам нужно установить еще несколько переменных. Мы собираемся вернуться в каталог _ / root / navigators-guide / example-code / 02-scale / ch04 / haproxyloadbalancer / groupvars / load_balancer / . Если вы просмотрите существующий файл * vars.yml *, вы увидите, что + do_token + и + ha_auth_key + присваиваются значения + vault_do_token + и + vault_ha_auth_key + соответственно. Мы собираемся создать вторичный файл с именем * vault.yml * и инициализировать переменные + vault +