Haproxy установка и настройка debian

Обновлено: 06.07.2024

Установка и настройка HAProxy на Debian/Ubuntu

Август 5th, 2016 Evgeniy Kamenev

Установка HAProxy

Debian8

Debian7

Ubuntu14

echo "deb http://archive.ubuntu.com/ubuntu trusty-backports main universe" >> / etc / apt / sources . list . d / backports . list

2.Настройка логирования HAProxy

[ ok ] Restarting rsyslog ( via systemctl ) : rsyslog . service .

3.Настройка HAProxy

ssl - default - bind - ciphers ECDH + AESGCM : DH + AESGCM : ECDH + AES256 : DH + AES256 : ECDH + AES128 : DH + AES : ECDH + 3DES : DH + 3DES : RSA + AESGCM : RSA + AES : RSA + 3DES : ! aNULL : ! MD5 : ! DSS

Для этого создадим на WEB-серверах в корне сайта по умолчанию файл test.php,например, с таким содержанием

Если Web-сервер недоступен/не проходит корректно проверку, он будет автоматически выброшен из кластера HAProxy и все запросы будут распределяться между оставшимися двумя Web-серверами.

Добавление HAProxy в автозагрузку
Debian 8

Debian 7/Ubuntu 14

Запуск HAProxy и проверка корректности запуска

13603 ? Ss 0 : 00 / usr / sbin / haproxy - systemd - wrapper - f / etc / haproxy / haproxy . cfg - p / run / haproxy . pid 13605 ? S 0 : 00 / usr / sbin / haproxy - f / etc / haproxy / haproxy . cfg - p / run / haproxy . pid - Ds 13607 ? Ss 0 : 00 / usr / sbin / haproxy - f / etc / haproxy / haproxy . cfg - p / run / haproxy . pid – Ds

5083 ? Ss 0:05 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid

В логах HAProxy

Aug 3 12 : 12 : 34 localhost haproxy [ 15459 ] : Server webcluster / app02 is UP , reason : Layer7 check passed , code : 200 , info : "OK" , check duration : 0ms. 1 active and 0 backup servers online . 0 sessions requeued , 0 total in queue . Aug 3 12 : 13 : 54 localhost haproxy [ 15459 ] : Server webcluster / app03 is UP , reason : Layer7 check passed , code : 200 , info : "OK" , check duration : 0ms. 2 active and 0 backup servers online . 0 sessions requeued , 0 total in queue . Aug 3 12 : 14 : 25 localhost haproxy [ 15459 ] : Server webcluster / app01 is UP , reason : Layer7 check passed , code : 200 , info : "OK" , check duration : 0ms. 3 active and 0 backup servers online . 0 sessions requeued , 0 total in queue .

Для проверки балансировки запросов на все три Web-сервера создаем на этих серверах в в корне для сайта по умолчанию либо разные странички, либо файл,например lb.php, с таким содержимым

Далее тестируем распределение запросов, например,с loadbalancera (EXT_IP-10.10.1.43,INT_IP-192.168.10.1)

Т.е запросы по очереди направляются на все три сервера Web-сервера

Favorite

Добавить в избранное

Главное меню » Debian » Установка HAProxy для настройки сервера балансировки нагрузки в Debian 10

Установите HAProxy для настройки сервера балансировки нагрузки в Debian 10

HAProxy или High Availability Proxy обеспечивает высокую доступность и решение для прокси. Он написан на C и работает на сетевом и прикладном уровнях модели TCP/IP. Лучше всего то, что у него есть бесплатная версия сообщества, и это приложение с открытым исходным кодом. Он работает в операционных системах Linux, FreeBSD и Solaris. Корпоративная версия тоже есть, но имеет свою цену.

В этой статье мы увидим, как установить HAProxy и настроить сервер балансировки нагрузки в Debian 10.

Предпосылки:

    ко всем машинам и базовые знания о запуске команд в терминале Linux.
  1. Частные IP-адреса добавлены к балансировщику нагрузки и внутренним серверам.
  2. Операционная система Debian 10 установлена на всех машинах.

Установка HAProxy на Debian 10

В этой статье мы предположим следующую конфигурацию IP-адреса:

  1. Балансировщик нагрузки HAProxy 10.0.12.10
  2. Веб-сервер1: IP-адрес: 10.0.12.15
  3. Веб-сервер2: IP-адрес: 10.0.12.16

Шаг 1. Обновите системный репозиторий Debian и пакеты.

Сначала выполните приведенные ниже команды на всех системах, чтобы обновить пакеты программного обеспечения до последней версии.

Шаг: 2 Установите Nginx на внутренние серверы

Подготовьте свои внутренние серверы, установив веб-сервер Nginx на каждом. Вы также можете установить другие веб-серверы, такие как apache.

Чтобы установить Nginx, выполните следующие команды на каждом внутреннем сервере в вашей среде:

Шаг: 3 После того, как Nginx будет установлен на ваших внутренних серверах, запустите службу, как показано ниже:

СОВЕТ : Мы также можем управлять веб-сервером nginx, используя следующую команду:

Шаг: 4 Создайте собственные индексные страницы в веб-папке каждого веб-сервера Nginx. Это поможет нам определить, какой внутренний сервер обслуживает входящие запросы.

На каждом веб-сервере выполните следующие задачи:

Читать Как установить и настроить NIS Server в Debian 10

Сделайте резервную копию исходного индексного файла с помощью следующей команды:

Добавьте собственный текст в файл index.html. Мы добавляем IP-адрес каждого веб-сервера.

Для веб-сервера 1:

Для веб-сервера 2:

Вы также можете использовать редактор Vim, если вам это удобнее. Это показано ниже:

Когда файл откроется, введите текст и сохраните файл.

Откройте файл виртуального хоста по умолчанию в каталоге “/etc/nginx/sites-available/”.

Теперь внутри блока сервера измените корневую директиву с “/var/www/html” на “/usr/share/nginx/html”.

Чтобы проверить конфигурацию Nginx, выполните следующую команду:

Шаг 5: Теперь перезапустите службу с помощью команды:

Вы можете проверить статус nginx, используя следующую команду:

Шаг: 6 Чтобы установить HAProxy в Debian 10 (Buster), выполните следующую команду на балансировщике нагрузки.

Совет: после установки HAProxy вы можете управлять HAProxy с помощью сценария инициализации. Для этого установите для параметра «enabled» значение 1 в “/etc/default/haproxy”, как показано ниже:

Теперь со сценарием инициализации можно использовать следующую опцию:

Шаг: 7 Теперь настройте балансировщик нагрузки HAProxy, отредактировав файл конфигурации по умолчанию haproxy, то есть «/etc/haproxy/haproxy.cfg». Чтобы отредактировать этот файл, выполните следующую команду

Совет: сделайте резервную копию исходного файла, чтобы мы были в безопасности, если что-то пойдет не так. Чтобы выполнить резервное копирование, используйте следующую команду:

Теперь перейдите в конец файла и отредактируйте следующую информацию:

Не забудьте изменить IP-адреса в приведенном выше файле на тот, который вы добавили на свои веб-серверы.

Шаг: 8 Проверьте синтаксис конфигурации указанного выше файла с помощью следующей команды:

Если все пойдет правильно, появится такой вывод: “Configuration file is valid.”. Если вы получите какую-либо ошибку в выводе, перепроверьте файл конфигурации и проверьте его еще раз.

Читать Как подключить общий ресурс Windows на Linux с помощью CIFS

Шаг: 9 Теперь перезапустите службу HAProxy, чтобы применить изменения.

Тестирование конфигурации

Теперь пора проверить, правильно ли работает наша установка. Введите IP-адрес системы балансировки нагрузки в веб-браузере (в нашем случае это 10.0.12.10) и постоянно обновляйте страницу 2–4 раза, чтобы убедиться, что балансировщик нагрузки HAProxy работает правильно. Вы должны увидеть разные IP-адреса или любой текст, который вы ввели в файл index.html, когда продолжите обновлять страницу несколько раз.

На этом пока все! Попробуйте поэкспериментировать с HAProxy, чтобы узнать больше о том, как он работает. Например, вы можете попробовать:

  • Интеграция другого веб-сервера рядом с nginx.
  • Изменение алгоритма балансировки нагрузки на другой, кроме циклического.
  • Настройка проверки работоспособности HAProxy, чтобы определить, работает ли внутренний сервер.
  • Применение липких сеансов для подключения пользователя к одному и тому же внутреннему серверу.
  • Использование статистики HAProxy для получения информации о трафике на серверах.

HAProxy имеет обширную документацию, доступную как для версии сообщества HAProxy, так и для версии HAProxy для предприятий . Изучите эту документацию, чтобы получить больше информации о повышении производительности и надежности вашей серверной среды.

Это руководство было успешно выполнено в Debian 10 (Buster). Попробуйте установить HAProxy на другие дистрибутивы на основе Debian, такие как Ubuntu, Linux Mint и т. д. Пожалуйста, не забудьте поделиться этим руководством с другими.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.


Мануал

В этом руководстве мы узнаем, как настроить балансировщик нагрузки HAProxy с SSL в Ubuntu 18.04 / Debian 10/9.

Таким образом, HAProxy подходит для веб-сайтов с очень высоким показателем трафика.

Настройте балансировщик нагрузки HAProxy с помощью SSL в Ubuntu 18.04 / Debian 10/9

В этом руководстве мы продемонстрируем, как HAProxy выполняет балансировку нагрузки с использованием трех веб-серверов, обслуживающих простые HTML-страницы.

Наша архитектура выглядит как показано на схеме ниже;


Установите HAProxy в Ubuntu 18.04 / Debian 10 / Debian 9

Запустите обновление системы.

После завершения обновления перейдите к установке HAProxy в ваших системах Ubuntu / Debian.

Создайте HAProxy репозиторий

Для каждой системы существуют разные пакеты HAProxy.

Следовательно, вам нужно создать отдельный репозиторий для каждой системы.

Прежде чем вы сможете создать репозитории, установите ключ подписи APT.

Затем создайте репозитории HAProxy.

На Debian 10 Buster / Debian 9 Stretch выполните команду, показанную ниже, чтобы создать репо.

В Ubuntu 18.04 вам нужно добавить репозитории vbernat haproxy PPA, как показано ниже;

Как только репозитории созданы в каждой системе, выполните обновление системы и установите HAProxy.

Чтобы проверить версию установленного HAProxy, выполните команду ниже;

Настройте балансировщик нагрузки HAProxy в Ubuntu 18.04 / Debian 10/9

Поэтому он состоит из системы внешнего интерфейса и одной или нескольких внутренних систем.

Внешняя система определяет IP-адрес и порт, который прослушивает прокси-сервер, а также внутренние системы для использования для конкретного прокси.

Файл конфигурации HAProxy состоит из четырех разделов;

  • global
    раздел определяет настройки безопасности и производительности в рамках всего процесса, которые влияют на HAProxy на низком уровне.
  • defaults
    Раздел global определяет параметры конфигурации, которые применяются ко всем внешним и внутренним разделам. Вы можете определить несколько разделов по умолчанию, но последующие разделы по умолчанию переопределяют предшествующие ему.
  • frontend
    Когда HAProxy размещается в качестве обратного прокси-сервера, в разделе внешнего интерфейса определяются IP-адреса и порты, к которым могут подключаться клиенты.
  • backend
    Этот раздел определяет группу серверов, которые будут сбалансированы по нагрузке и назначены для обработки запросов.

Секции frontend и backend могут быть объединены с использованием секции listen.

Они также могут быть использованы для страницы статистики сервера HAProxy.

Чтобы узнать больше об объяснении разделов конфигурации HAProxy, посмотрите информацию тут.

Прежде чем мы сможем начать какую-либо настройку, давайте создадим резервную копию файла конфигурации.

Конфигурация HAProxy по умолчанию содержит параметры конфигурации по умолчанию для разделов global и default.

Мы оставим эти настройки такими, какие они есть, и добавим наши конфигурации для разделов frontend и backend.

Однако вы можете добавить строку tune.ssl.default-dh-param 2048 в глобальный раздел, который устанавливает максимальный размер параметров Диффи-Хеллмана, используемых для генерации эфемерного / временного ключа Диффи-Хеллмана в случае обмена ключами DHE.

Настройте HAProxy с SSL на Ubuntu 18.04 / Debian 10/9

Как указано выше, раздел внешнего интерфейса определяет IP-адрес, на котором следует прослушивать запросы на подключение.

Поскольку мы настраиваем HAProxy с SSL, вам необходимо сгенерировать сертификаты SSL / TLS.

В этом руководстве используются самоподписанные сертификаты.

Вы можете получить свой собственный от доверенного CA.

Создание самоподписанных сертификатов SSL для HAProxy

Начните с генерации закрытого ключа.

Затем сгенерируйте запрос на подпись сертификата (CSR).

Создайте самоподписанный сертификат (CRT)

Создайте файл pem SSL, содержащий ключ и сертификат.

Определите параметры конфигурации внешнего интерфейса HAProxy

Откройте файл конфигурации HAProxy и настройте параметры внешнего интерфейса, как показано ниже;

Это наши основные настройки конфигурации интерфейса.

  • Параметр bind назначает слушателя для данного IP-адреса и порта. ssl crt инструктирует HAProxy использовать SSL.
  • default_backend дает имя бэкенда для отправки трафика.

Определите настройки конфигурации HAProxy Backend

В базовой конфигурации настройки внешнего бэкенда определены ниже;

Настройка balance определяет алгоритм планирования балансировки нагрузки.
Roundrobin выбирает серверы по очереди.
Другие распространенные алгоритмы включаютe leastconn, которые позволяют балансировщику нагрузки пересылать запросы на серверы с наименьшим количеством соединений.

настройки server указывает серверы, доступные в бэкэнде.

Включить статистику HAProxy через Интернет

Проверьте конфигурацию HAProxy

После завершения настройки вы можете выполнить команду ниже, чтобы проверить конфигурацию HAProxy на наличие ошибок.

Запуск HAProxy

После установки HAProxy настроен на запуск по умолчанию.

Перезапустите и разрешите запуск HAProxy при загрузке системы;

Если UFW работает, откройте порт 443,

Проверьте балансировку нагрузки HAProxy

Первая страница загрузки показывает контент-сервер из webapp_01.

Для этой демонстрации у нас есть три тестовых HTML-страницы.

При обновлении отображается содержимое с других серверов.




Как вы понимаете, страницы обслуживаются по порядку, одна за другой.

Вот и все, что касается нашего основного руководства по настройке HAProxy Load Balancer с самоподписанным сертификатом в Ubuntu 18.04 / Debian 10 / Debian 9.


Этой публикацией я хочу начать цикл статей про развертывание полноценной среды оркестрации контейнерами Kubernetes, которая будет готова к эксплуатации и запуску приложений.
Я хочу рассказать не просто про то, как развернуть кластер Kubernetes, но и про то, как настроить кластер после установки, как добавить в него удобных инструментов и дополнений для использования микросервисной архитектуры.

Данный цикл будет состоять минимум из четырех статей:

  1. В первой из них я расскажу, как на голое железо установить отказоустойчивый кластер kubernetes, как установить стандартный дашборд и настроить доступ к нему, как установить ingress контроллер.
  2. Во второй статье я расскажу, как развернуть отказоустойчивый кластер Ceph и как начать использовать RBD тома в нашем кластере Kubernetes. Также немного затрону остальные виды стораджей (storages) и более подробно рассмотрю local-storage. Дополнительно расскажу, как на базе созданного кластера CEPH организовать отказоустойчивое хранилище S3
  3. В третьей статье я расскажу, как в нашем кластере Kubernetes развернуть отказоустойчивый кластер MySql, а именно — Percona XtraDB Cluster on Kubernetes. И также опишу все проблемы с которыми мы столкнулись, когда решили перенести БД в kubernetes.
  4. В четвертой статье я постараюсь собрать все вместе и рассказать, как задеплоить и запустить приложение, которое будет использовать БД и тома ceph. Расскажу, как настроить ingress контроллер для доступа к нашему приложению извне и сервис автоматического заказа сертификатов от Let's Encrypt. Еще — как автоматически поддерживать данные сертификаты в актуальном состоянии. Также немного затронем тему RBAC в контексте доступа до панели управления. Расскажу в двух словах про Helm и его установку.
    Если Вам интересна информация данных публикаций, то — добро пожаловать !

Вступление:

Для кого предназначены данные статьи? В первую очередь, для тех, кто только начинает свой путь в изучении Kubernetes. Также данный цикл будет полезен для инженеров, которые думают переходить от монолита к микросервисам. Все описанное — это мой опыт, в том числе полученный и при переводе нескольких проектов из монолита в Kubernetes. Возможно, что какие-то части публикаций будут интересны и опытным инженерам.

Что я не буду подробно рассматривать в данной серии публикаций:

  • подробно объяснять, что такое примитивы kubernetes, такие как: pod, deployment, service, ingress и тд.
  • CNI (Container Networking Interface) я рассмотрю очень поверхностно, мы используем callico поэтому другие решения, я только перечислю.
  • процесс сборки docker образов.
  • процессы CI\CD. (Возможно отдельной публикацией, но после всего цикла)
  • helm; про него написано уже достаточно много, я затрону лишь процесс его инсталляции в кластер и настройку клиента.

Что я хочу рассмотреть подробно:

  • пошаговый процесс развертывания кластера Kubernetes. Я буду использовать kubeadm. Но при этом я подробно шаг за шагом рассмотрю процесс инсталляции кластера на голое железо, различные виды инсталляции ETCD, составление конфигфайлов для kube admina. Постараюсь разъяснить все варианты балансировки для Ingress контроллера и отличие в разнообразных схемах доступа worknodes до api сервера.
    Я знаю, что сегодня для развертывания kubernetes есть много прекрасных инструментов, например, kubespray или тот же rancher. Возможно, кому-то будет более удобно использовать их. Но, я думаю, найдется немало инженеров которые захотят рассмотреть вопрос более детально.
  • терминологию CEPH и пошаговую инсталляцию кластера CEPH, а также пошаговую инструкцию подключение хранилища ceph к созданному Kubernetes кластеру.
  • local-storages, подключение к кластеру kubernetes, а также отличия от подключений типа hostpath и тд.
  • kubernetes операторы и развертывание Percona XtraDB Cluster с помощью оператора, а также постараюсь рассказать про плюсы и минусы такого решения после полугодового опыта использования в продакшене. А также немного поделюсь планами по доработке оператора от percona.

Оглавление:

  1. Cписок хостов, ресурсы хостов, версии ОС и ПО
  2. Схема HA кластера kubernetes
  3. До начала работы или before you begin
  4. Заполняем файл create-config.sh
  5. Обновление ядра ОС
  6. Подготовка нод Установка Kubelet, Kubectl, Kubeadm и docker
  7. Установка ETCD (различные варианты)
  8. Запуск первого мастера kubernetes
  9. Установка CNI Callico
  10. Запуск второго и третьего мастера kubernetes
  11. Добавляем worker нод в кластер
  12. Устанавливаем haproxy на worker ноды для HA
  13. Установка Ingress контроллера
  14. Установка Web UI (Dashboard)

Список и назначение хостов

Все ноды моего кластера будут располагаться на виртуальных машинах с предустановленной системой Debian 9 stretch c ядром 4.19.0-0.bpo.5-amd64. Для виртуализации я использую Proxmox VE.

Таблица ВМ и их ТТХ:

Name IP адрес Comment CPU MEM DISK1 DISK2
master01 10.73.71.25 master node 4vcpu 4Gb HDD ---
master02 10.73.71.26 master node 4vcpu 4Gb HDD ---
master03 10.73.71.27 master node 4vcpu 4Gb HDD ---
worknode01 10.73.75.241 work node 4vcpu 4Gb HDD SSD
worknode02 10.73.75.242 work node 4vcpu 4Gb HDD SSD
worknode03 10.73.75.243 work node 4vcpu 4Gb HDD SSD

Не обязательно, что у Вас должна быть именно такая конфигурация машин, но все таки я советую придерживаться рекомендациям официальной документации, а для мастеров увеличить количество оперативной памяти минимум до 4Гб. Забегая вперед скажу, что при более маленьком количестве, я ловил глюки в работе CNI Callico
Ceph тоже достаточно прожорлив к памяти и производительности дисков.
Наши продакшн инсталляции работают без виртуализации на голом железе, но я знаю много примеров, где хватало и виртуальных машин с достаточно скромными ресурсами. Все зависит от ваших потребностей и нагрузок.

Список и версии ПО

Name Version
Kubernetes 1.15.1
Docker 19.3.1

Kubeadm, начиная с версии 1.14, перестал поддерживать API версии v1alpha3 и полностью перешел на API версии v1beta1, которую будет поддерживать в ближайшем будущем, поэтому в статье я буду рассказывать только про v1beta1.
Итак, мы считаем, что у Вы подготовили машины для kubernetes кластера. Они все доступны друг другу по сети, имеют "выход" в интернет и на них установлена "чистая" операционная система.
Для каждого шага установки я буду уточнять, на каких именно машинах выполняется команда или блок команд. Все команды выполнять из-под пользователя root, если не указано иного.
Все файлы конфигурации, а также скрипт для их подготовки доступны для скачивания в моем github
Итак, начнем.

Схема HA кластера kubernetes



Примерная схема HA кластера. Художник из меня так себе, если честно, но постараюсь объяснить в двух словах и достаточно упрощенно, особо не углубляясь в теорию.
Итак, наш кластер будет состоять из трех master нод и трех worker нод. На каждой master ноде kubernetes у нас будет работать etcd (на схеме зеленые стрелочки) и служебные части kubernetes; назовем их обобщенно — kubeapi.
Через кластер etcd master ноды обмениваются состоянием кластера kubernetes. Эти же адреса я укажу как точки входа ingress контроллера для внешнего трафика (на схеме красные стрелочки)
На worker нодах у нас работает kubelet, который связывается с api сервером kubernetes через haproxy установленным локально на каждой worker ноде. В качестве адреса api сервера для kubelet я буду использовать локалхост 127.0.0.1:6443, а haproxy по roundrobin будет раскидывать запросы по трем master нодам, также он будет проверять доступность master нод. Данная схема позволит нам создать HA, и в случае выхода из строя одной из master нод, worker ноды будут спокойно посылать запросы на две оставшихся в живых master ноды.

Перед началом работы

Перед началом работы на каждую ноду кластера поставим пакеты, которые нам понадобятся для работы:

На master ноды скопируем репозиторий с шаблонами конфигов

Проверим, что ip адрес хостов на мастерах соответствует тому, на котором будет слушать API сервер kubernetes

и так для всех master нод.

Обязательно отключите SWAP, иначе kubeadm будет выдавать ошибку

Отключить можно командой

Не забудьте закомментировать в файле /etc/fstab

Заполняем файл create-config.sh

Для автоматического заполнения конфигов, нужных для установки кластера kubernetes, я накидал небольшой скриптик create-config.sh. Вам нужно заполнить в нем буквально 8 строчек. Указать IP адреса и hostname своих мастеров. А также указать etcd tocken, можете его не менять. Я приведу ниже ту часть скрипта в которой нужно сделать изменения.

Обновление ядра ОС

Данный шаг является необязательным, так как ядро нужно будем обновлять из back портов, и делаете Вы это на свой страх и риск. Возможно, Вы никогда столкнетесь с данной проблемой, а если и столкнетесь, то обновить ядро можно и после разворачивания kubernetes. В общем, решать Вам.
Обновление ядра требуется для устранения старого бага docker, который исправили только в ядре linux версии 4.18. Более подробно про этот баг можно почитать вот здесь. Выражался баг в периодическом зависании сетевого интерфейса на нодах kubernetes c ошибкой:

У меня после установки ОС было ядро версии 4.9

На каждой машине для kubernetes выполняем
Шаг №1
Добавляем back ports в source list

Читайте также: