Network load balancers - elastic load balancing

Установка terraform в Unix/Linux

Установка крайне примитивная и я описал как это можно сделать тут:

Так же, в данной статье, я создал скрипт для автоматической установки данного ПО. Он был протестирован на CentOS 6/7, Debian 8 и на Mac OS X. Все работает должным образом!

Чтобы получить помощь по использованию команд, выполните:

$ terraform --help
Usage: terraform   <command> 

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure
    env                Workspace management
    fmt                Rewrites config files to canonical format
    get                Download and install modules for the configuration
    graph              Create a visual graph of Terraform resources
    import             Import existing infrastructure into Terraform
    init               Initialize a Terraform working directory
    output             Read an output from a state file
    plan               Generate and show an execution plan
    providers          Prints a tree of the providers used in the configuration
    push               Upload this Terraform module to Atlas to run
    refresh            Update local state file against real resources
    show               Inspect Terraform state or plan
    taint              Manually mark a resource for recreation
    untaint            Manually unmark a resource as tainted
    validate           Validates the Terraform files
    version            Prints the Terraform version
    workspace          Workspace management

All other commands:
    debug              Debug output management (experimental)
    force-unlock       Manually unlock the terraform state
    state              Advanced state management

Приступим к использованию!

Нехватка портов

При каждом подключении к одному и тому же IP-адресу назначения и порту назначения используется порт SNAT. Для этого подключения поддерживается отдельный поток трафика от серверного экземпляра или клиента к серверу. В результате сервер получает отдельный порт, на который можно направлять трафик. Без этого процесса клиентский компьютер не знает, к какому потоку относится тот или иной пакет.

Представьте, что несколько браузеров обращаются к https://www.microsoft.com с такими параметрами:

IP-адрес назначения — 23.53.254.142;
порт назначения — 443;
протокол — TCP.

Если бы не было разных портов назначения для возвращаемого трафика (портов SNAT, используемых для установки подключения), клиенту не удавалось бы отделить результат одного запроса от результата другого.

Количество исходящих подключений может резко возрастать. Серверному экземпляру может быть выделено недостаточно портов. Используйте функции повторного использования подключения в приложении. Без повторного использования подключения повышается риск нехватки портов SNAT. Дополнительные сведения о пуле подключений в службе приложений Azure см. .

При нехватке портов новые исходящие подключения к IP-адресу назначения будут завершаться ошибкой. Подключения будут успешно установлены, когда появятся доступные порты. Нехватка возникает, когда 64 000 портов, выделенных для IP-адреса, распределены по большому количеству серверных экземпляров. Сведения о том, как справиться с нехваткой портов SNAT, см. в руководстве по устранению неполадок.

Для TCP-подключений подсистема балансировки нагрузки будет использовать один порт SNAT для каждого IP-адреса и порта назначения. Эта возможность многократного использования позволяет устанавливать несколько подключений к одному и тому же IP-адресу назначения с одним и тем же портом SNAT. Такое многократное использование ограничено, если подключение выполняется к одному порту назначения.

Для UDP-подключений подсистема балансировки нагрузки использует алгоритм NAT с ограничением по портам, который занимает один порт SNAT на один IP-адрес назначения независимо от порта назначения.

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

Работа с AWS ELB через командную строку в Unix/Linux

Устанавливаем AWS CLI:

Открываем конфиг:

# vim ~/.aws/credentials

Прописываем ключи. Например:

aws_access_key_id = XXXXXXXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = YYYYYYYYYYYYYYYYYYYY

Где:

Your_acc_name — Имя для аккаунта. Потом можно его использовать.
aws_access_key_id — Ключик.
aws_secret_access_key — Еще один ключик.

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

Проверим что содержится во всех LB по определенному аккаунту:

$ aws elb describe-load-balancers --profile Your_acc_name --region us-east-1 --output text

ИЛИ:

$ aws elb describe-load-balancers --profile Your_acc_name --region us-east-1 --output json

Для того, чтобы получить имена всех ELB, выполните:

$ aws elb describe-load-balancers --profile Your_acc_name --region us-east-1 | grep -E "LoadBalancerName"

Проверим что имеется в определенном ELB:

$ aws elb describe-load-balancers --profile Your_acc_name --region us-east-1 --load-balancer-name My_ELB_name

Иногда, выпадают ноды из кластера и чтобы проверить статус хелса всех нод в кластере ELB ( нужно знать имя. Я в верху описывал как получить его):

$ aws elb describe-instance-health --profile Your_acc_name --region us-east-1 --output text --load-balancer-name My_ELB_name
INSTANCESTATES	N/A	i-02eb2e3a74dc8755b	N/A	InService
INSTANCESTATES	N/A	i-03e2bf392cf4d65e6	N/A	InService
INSTANCESTATES	N/A	i-041101b6ade745211	N/A	InService
INSTANCESTATES	N/A	i-05dd40ff3e5c566db	N/A	InService
INSTANCESTATES	N/A	i-088bad3a48ac31542	N/A	InService
INSTANCESTATES	N/A	i-08e1958dfd3df0989	N/A	OutService
INSTANCESTATES	N/A	i-09d6cb51aaadbc909	N/A	InService
INSTANCESTATES	N/A	i-0be24594ebc5c3522	N/A	InService
INSTANCESTATES	N/A	i-0e00a72a7a6ec154e	N/A	InService
INSTANCESTATES	N/A	i-0f7a57e6bc0024d31	N/A	InService

Я указал какой регион использовать:

--region us-east-1

Можно добавить данную опцию в конфигурационный файл, например:

aws_access_key_id = XXXXXXXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = YYYYYYYYYYYYYYYYYYYY
region=us-east-1

Тогда, можно будет выполнять:

$ aws elb describe-instance-health --profile Your_acc_name --output text --load-balancer-name My_ELB_name

Предположим, что необходимо убрать одну из нод в ELB кластере, то выполнить это можно так:

$ aws elb deregister-instances-from-load-balancer --profile Your_acc_name --load-balancer-name My_ELB_name --instances i-08e1958dfd3df0989

Предположим, что необходимо добавить еще одну ноду в ELB кластер, то выполнить это можно так:

$ aws elb register-instances-with-load-balancer --profile Your_acc_name --load-balancer-name My_ELB_name --instances i-08e1958dfd3df0989

PS: Возможно, потребуется указать региона, например:

--region us-east-1

На этом у меня все, статья «Работа с AWS ELB через командную строку в Unix/Linux» завершена.

исходящий доступ по умолчанию

Примечание

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

Любой ресурс Azure без связанного с ним общедоступного IP-адреса не содержит Load Balancer с правилами исходящего трафика, который не входит в состав набора масштабируемых наборов виртуальных машин или не имеет ресурса шлюза NAT, связанного с его подсетью, выделяется минимальное количество портов для исходящего трафика. Этот доступ известен как исходящий доступ по умолчанию и является наихудшим методом для обеспечения исходящего подключения к приложениям.

Ниже приведены некоторые другие примеры исходящего доступа по умолчанию.

При использовании базового Load Balancer
Виртуальная машина в Azure (без описанных выше связей). В этом случае исходящее подключение предоставляется по IP-адресу исходящего трафика по умолчанию. Этот IP-адрес — это динамический IP-адрес, назначенный Azure, который нельзя контролировать. SNAT по умолчанию не рекомендуется для производственных рабочих нагрузок и может привести к сбоям подключения.
Виртуальная машина во внутреннем пуле Load Balancer без правил для исходящего трафика. В результате вы используете интерфейсный IP-адрес подсистемы балансировки нагрузки для исходящих и входящих подключений, что более подвержено сбоям подключения из-за нехватки портов SNAT.

Что такое порты SNAT?

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

Если порт используется для входящих подключений, на нем есть прослушиватель для запросов на такие подключения. Этот порт нельзя использовать для исходящих подключений. Чтобы установить исходящее подключение, в качестве порта для обмена данными и поддержки отдельного потока трафика используется временный порт. Если эти временные порты используются для SNAT, они называются портами SNAT.

По определению каждый IP-адрес имеет 65 535 портов. Каждый порт может использоваться для входящих или исходящих подключений по протоколам TCP и UDP. Если общедоступный IP-адрес добавлен в подсистему балансировки нагрузки в качестве интерфейсного IP-адреса, для SNAT будет предоставлено 64 000 портов. Все общедоступные IP-адреса, добавленные в качестве интерфейсных IP-адресов, могут быть распределены по одному. Например, если два серверных экземпляра распределяются по портам 64 000, с доступом к двум интерфейсным IP-адресам, то оба экземпляра будут использовать порты из первого интерфейса, пока не будут исчерпаны все порты 64 000.

Порт, используемый для подсистемы балансировки нагрузки или правила NAT для входящего трафика, потребляет восемь из 64 000 портов. Такое использование сокращает количество портов, подходящих для SNAT. Если правило балансировки нагрузки или правило NAT для входящего трафика занимает тот же диапазон из восьми портов, что и другое правило, дополнительные порты использоваться не будут.

Как SNAT работает по умолчанию?

Когда виртуальная машина создает исходящий поток, Azure преобразует исходный IP-адрес во временный IP-адрес. Это преобразование выполняется с помощью SNAT.

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

Пример. Использование Load Balancer программного обеспечения для перенаправления трафика

Если необходимо подключить виртуальный IP-адрес к одному сетевому интерфейсу в виртуальной сети без определения отдельных портов, можно создать правило пересылки L3. Это правило перенаправляет весь входящий и исходящий трафик виртуальной машины с помощью назначенного виртуального IP-адреса, содержащегося в объекте PublicIPAddress.

Если виртуальный IP-адрес и DIP определены как одна и та же подсеть, это эквивалентно выполнению пересылки L3 без преобразования сетевых адресов (NAT).

Примечание

Для этого процесса не требуется создавать объект балансировщика нагрузки. Назначение PublicIPAddress для сетевого интерфейса достаточно для того, чтобы Load Balancer программного обеспечения выполняла конфигурацию.

Создайте объект общедоступного IP-адреса, который будет содержать VIP.
Назначьте PublicIPAddress сетевому интерфейсу.

Authentication

Поставщик AWS предлагает гибкие средства предоставления учетных данных для аутентификации.Следующие методы поддерживаются в этом порядке и объясняются ниже:

Статические удостоверения личности
Переменные среды
Файл общих учетных данных
Роль EC2

Статические удостоверения личности

Статические учетные данные могут быть предоставлены путем добавления и в блоке поставщика AWS:

Usage:

provider "aws" {
  region     = "us-west-2"
  access_key = "anaccesskey"
  secret_key = "asecretkey"
}

Переменные среды

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

Обратите внимание, что установка учетных данных AWS с использованием этих (или устаревших) переменных среды переопределит использование и. В и также используются переменные окружения, если это применимо:

provider "aws" {}

Usage:

$ export AWS_ACCESS_KEY_ID="anaccesskey"
$ export AWS_SECRET_ACCESS_KEY="asecretkey"
$ export AWS_DEFAULT_REGION="us-west-2"
$ terraform plan

Общий файл учетных данных

Вы можете использовать файл учетных данных AWS, чтобы указать свои учетные данные. Расположение по умолчанию — в Linux и OS X или для пользователей Windows. Если нам не удастся обнаружить учетные данные в строке или в среде, Terraform проверит это местоположение. При желании вы можете указать другое расположение в конфигурации, атрибут shared_credentials_file , или в среде с переменной . Этот метод также поддерживает конфигурацию и соответствующую переменную среды :

Usage:

provider "aws" {
  region                  = "us-west-2"
  shared_credentials_file = "/Users/tf_user/.aws/creds"
  profile                 = "customprofile"
}

Роли задач ECS и CodeBuild

Если вы используете Terraform на ECS или CodeBuild и настроили роль задачи IAM , Terraform будет использовать роль задачи контейнера. Terraform переменной среды AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, которую AWS вводит при настройке роли задачи. Если вы не определили роль задачи для своего контейнера или задания CodeBuild, Terraform продолжит использовать .

Роль EC2

Если вы запускаете Terraform из экземпляра EC2 с профилем экземпляра IAM с использованием роли IAM, Terraform просто запросит учетные данные у конечной точки .

Это предпочтительный подход по сравнению с любым другим при работе в EC2,так как вы можете избежать жесткого кодирования учетных данных.Вместо этого они сдаются в аренду «на лету» компанией Terraform,что снижает вероятность утечки.

Вы можете предоставить конечную точку API пользовательских метаданных с помощью переменной , которая ожидает URL-адрес конечной точки, включая версию, и по умолчанию имеет значение .

Крайний срок по умолчанию для конечной точки API метаданных EC2 составляет 100 миллисекунд, которые можно переменную среды AWS_METADATA_TIMEOUT . Переменная ожидает положительную строку Golang Time.Duration, которая представляет собой последовательность десятичных чисел и суффикс единицы; допустимые суффиксы: (наносекунды), (микросекунды), (миллисекунды), (секунды), (минуты) и (часы). Примеры допустимых входов: , , , , , .

Предполагать роль

Если предоставляется роль ARN,компания Terraform попытается взять на себя эту роль,используя предоставленные учетные данные.

Usage:

provider "aws" {
  assume_role {
    role_arn     = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
    session_name = "SESSION_NAME"
    external_id  = "EXTERNAL_ID"
  }
}

Мониторинг

До применения:

> show route forwarding-table vpn mgmt destination 10.11.0.72/29 
Routing table: mgmt.inet
Internet:
Enabled protocols: Bridging, All VLANs, 
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.11.0.72/29      user     0                    indr  1052491    22
                                                ulst  1051444     2
                             212.1.241.53      Push 35    11727     2 xe-1/0/4.10

После применения:

> show route forwarding-table vpn mgmt destination 10.11.0.72/29 
Routing table: mgmt.inet
Internet:
Enabled protocols: Bridging, All VLANs, 
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.11.0.72/29      user     0                    indr  1052491    22
                             212.1.240.179     Push 35, Push 933692(top)    12775     2 ae26.910
                             212.1.241.53      Push 35    11727     2 xe-1/0/4.10

Примененные изменения в load-balancing можно увидеть только в forwarding-table! В routing-table всё будет как прежде.

ulst — это список unicast ip next-hop. Пакеты, посленнаые к этому next-hop, отправляются к любому из next-hop в листе.

Filter-based forwarding

При этом методе балансировки на выбор пути будет влиять не только dst адрес, что делает данный тип балансировки более гибким. С помощью firewall filter пакеты классифицируются и для них определяется путь в рамках данного роутера.

Поддерживается для IPv4 и IPv6.

Можем пустить трафик от src address 10.10.0.0/24 до dst address 1.1.1.1/32 через одного ISP2, а трафик от src address 10.10.1.0/24 до dst address 1.1.1.1/32 через второго ISP2.

Создание балансировщика нагрузки¶

Вы можете настроить несколько типов балансировщиков нагрузки в облаке Amazon:

Classic Load Balancer
Network Load Balancer
Application Load Balancer

Сравнение балансировщиков нагрузки

Подробная информация о различиях балансировщиков доступна .

В этом документе в качестве примера будут продемонстрированы настройка и использование Network Load Balancer, который занимается балансировкой на транспортном уровне сетевой модели OSI/ISO.

Создайте балансировщик нагрузки, выполнив следующие действия:

Перейдите на вкладку Load Balancers в дашборде Amazon EC2 и нажмите на кнопку Create Load Balancer.
Создайте Network Load Balancer, нажав на соответствующую кнопку Create.
Настройте базовые параметры балансировщика:
1. Имя балансировщика (параметр Name)
2. Тип балансировщика (параметр Scheme)
  
  Обычно необходимо, чтобы балансировщик был доступен в Интернете. Для этого выберите вариант internet-facing.
3. Укажите, на каких портах необходимо слушать входящие соединения, с помощью группы параметров Listeners.
4. Задайте необходимые VPC и зоны доступности (Availability Zones), в которых балансировщик должен осуществлять маршрутизацию трафика.
  
  Проверьте доступность группы масштабирования
  
  Убедитесь, что вы выбрали VPC и зоны доступности, в которых находится развернутая ранее группа автоматического масштабирования.
Перейдите к следующему шагу, нажав на кнопку Next: Configure Security Settings.

При необходимости настройте параметры безопасности.
Перейдите к следующему шагу, нажав на кнопку Next: Configure Routing.

Настройте маршрутизацию входящих соединений к нодам в группе автоматического масштабирования:
1. Создайте новую целевую группу и задайте для нее имя в поле Name. Балансировщик нагрузки будет маршрутизировать входящие запросы к инстансам, находящимся в указанной целевой группе (например, demo-target).
2. Настройте протокол и порт, с помощью которого необходимо осуществлять маршрутизацию запросов.
  
  Для ноды Валарм укажите протокол TCP, порты 80 и 443 (если у вас присутствует HTTPS‑трафик).
3. При необходимости настройте проверку доступности с помощью группы параметров Health Checks.
Перейдите к следующему шагу, нажав на кнопку Next: Register Targets.

На данном шаге не требуется выполнять никаких действий.
Перейдите к следующему шагу, нажав на кнопку Next: Review.

Убедитесь, что все параметры заданы верно, и запустите процесс создания балансировщика нагрузки, нажав на кнопку Create.

Дождитесь окончания настройки балансировщика

После создания балансировщика должно пройти некоторое количество времени, прежде чем он сможет принимать трафик.

Prerequisites

This walkthrough requires the following prerequisites:

IIS 7.0 or above on Windows 2008 (any SKU) or newer.
Microsoft Application Request Routing Version 1 and dependent modules.
Minimum of two content servers with working sites and applications.

If Application Request Routing Version 1 has not been installed, it is available for download at:

Microsoft Application Request Routing Version 1 for IIS 7 (x86) here.
Microsoft Application Request Routing Version 1 for IIS 7 (x64) here.

Follow the steps outlined in this document to install Application Request Routing.

Another prerequisite is that the reader has defined and configured a server farm using the steps outlined in Define and Configure an Application Request Routing (ARR) Server Group.

Глобальная балансировка нагрузки

Будущее балансировки нагрузки будет все чаще рассматривать отдельные балансировщики как товар. На мой взгляд, настоящие инновационные и коммерческие возможности лежат в плоскости управления. Рисунок показывает пример глобальной системы балансировки нагрузки. В этом примере происходит несколько разных вещей:

Каждый прокси-сервер sidecar связывается с серверами в трех разных зонах (A, B и C).
Как показано, 90% трафика отправляется в зону C, а 5% трафика отправляется в обе зоны A и B.
Прокси-сервер sidecar и внутренние серверы сообщают о периодическом состоянии глобального балансировщика нагрузки. Это позволяет ему принимать решения, учитывающие задержки, затраты, нагрузку, текущие сбои и т.д.
Глобальный балансировщик нагрузки периодически настраивает каждый прокси-сервер sidecar с текущей информацией о маршрутизации.

Глобальный балансировщик нагрузки будет в состоянии делать сложные вещи, которые ни один балансировщик нагрузки не может сделать самостоятельно. Например:

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

Чтобы сделать глобальную балансировку нагрузки возможной, балансировщик нагрузки, используемый в качестве data plane, должен обладать сложными возможностями динамической конфигурации. Для получения дополнительной информации по этой теме, пожалуйста, см. мой пост Envoy’s universal data plane API, а также service mesh data plane vs. control plane..

Заключение и будущее балансировки нагрузки

Подводя итог, приведем ключевые выводы этой публикации:

Балансировщики нагрузки являются ключевым компонентом в современных распределенных системах.
Существуют два общих класса балансиров нагрузки: L4 и L7.
Оба балансировщика нагрузки L4 и L7 актуальны в современных архитектурах.
L4-балансировщики двигаются в направлении горизонтально масштабируемых распределенных консистентных решений хеширования.
В связи с распространением динамических архитектур микросервиса сейчас активно инвестируются балансировщики L7.
Глобальная балансировка нагрузки и разделение между control и data plane — это будущее балансировки нагрузки с инновационными и коммерческими возможностями.
Индустрия агрессивно продвигается к аппаратным и программным продуктам OSS для сетевых решений. Я считаю, что традиционные поставщики балансировщиков нагрузки, такие как F5, будут сначала заменены программным обеспечением OSS и облачными поставщиками.

Я думаю, что это захватывающее время в компьютерных сетях! Переход к OSS и программному обеспечению для большинства систем увеличивает темпы итерации на порядок. Кроме того, поскольку распределенные системы продолжают свой путь к динамизму с помощью «бессерверных» парадигм, сложность базовой сети и систем балансировки нагрузки должна быть соразмерно увеличена.

Оригинал: Introduction to modern network load balancing and proxying

Step 1 — Verify URL rewrite rules

Provided that the server farm has been created using the steps outlined in Define and Configure an Application Request Routing (ARR) Server Group, the URL rewrite rules have already been created for a simple load balancing scenario.

To verify URL rewrite rules using the UI:

Launch IIS Manager.
Select the server farm, myServerFarm, which was created in Define and Configure an Application Request Routing (ARR) Server Group.
The following icons are shown:
Double-click Routing Rules.
Verify that the Use URL Rewrite to inspect incoming requests checkbox is checked.
SSL offloading is enabled by default. When this feature is enabled, all communication between the ARR server and the application servers are done in clear text, even for HTTPS requests from clients to the ARR server. When both the ARR server and the application servers are deployed within a trusted network, such as within the same datacenter, enabling SSL offloading does not sacrifice security. Also, enabling this feature can further help to maximize the server resources on the application servers, since they do not have to spend cycles in encrypting and decrypting requests and responses.
To disable SSL offloading, uncheck the Enable SSL offloading checkbox, and then click Apply.
Open a browser and send several requests to the ARR server.
To verify that the requests are being load balanced equally between the application servers, select myServerFarm. Double-click Monitoring and Management.
In the dashboard view, verify that the requests are being evenly distributed.

To verify URL rewrite rules using the command-line:

Open a command prompt with administrator privileges.
Navigate to .
To verify that the URL rewrite rules have been created correctly, enter appcmd.exe list config -section:system.webServer/rewrite/globalRules. It returns the globalRules that looks like the following:
To disable SSL offloading, first remove all URL rewrite rules:

Then, create the URL rewrite rules to forward HTTPS traffic. More specifically, with this rule, ARR forwards requests using SSL if the incoming requests are HTTPS:

Finally, create the URL rewrite rules to forward HTTP traffic in clear text to the application servers:
To verify that the URL rewrite rules have been created correctly with SSL offloading disabled, enter appcmd.exe list config -section:system.webServer/rewrite/globalRules. It returns the globalRules that looks like the following:

Работа с CloudFlare и Terraform в Unix/Linux

У меня есть папка terraform, в ней у меня будут лежать провайдеры с которыми я буду работать. Т.к в этом примере я буду использовать AWS, то создам данную папку и перейду в нее. Далее, в этой папке, стоит создать:

$ mkdir examples modules

В папке examples, я буду хранить так званые «плейбуки» для разварачивания различных служб, например — zabbix-server, grafana, web-серверы и так далее. В modules директории, я буду хранить все необходимые модули.

Начнем писать модуль, но для этой задачи, я создам папку:

$  mkdir modules/cloudflare_record

Переходим в нее:

$ cd modules/cloudflare_record

Открываем файл:

$ vim cloudflare_record.tf

В данный файл, вставляем:

#---------------------------------------------------
# Add a record to the domain
#---------------------------------------------------
resource "cloudflare_record" "record" {
    count   = "${var.domain !="" && var.name !="" && var.value !="" ? 1 : 0}"

    domain      = "${var.domain}"
    name        = "${var.name}"
    value       = "${var.value}"
    type        = "${var.type}"
    ttl         = "${var.ttl}"
    priority    = "${var.priority}"
    proxied     = "${var.proxied}"
}

Открываем файл:

$ vim variables.tf

И прописываем:

#-----------------------------------------------------------
# Global or/and default variables
#-----------------------------------------------------------
variable "name" {
    description = " The name of the record"
    default     = "cloudflare_name"
}

variable "domain" {
    description = "The domain to add the record to"
    default     = ""
}

variable "value" {
    description = "The value of the record. Ex: 192.168.13.113"
    default     = ""
}

variable "type" {
    description = "The type of the record"
    default     = "A"
}

variable "ttl" {
    description = "The TTL of the record"
    default     = 3600
}

variable "priority" {
    description = "The priority of the record"
    default     = "1"
}

variable "proxied" {
    description = "Whether the record gets Cloudflare's origin protection."
    default     = ""
}

Собственно в этом файле храняться все переменные. Спасибо кэп!

Открываем последний файл:

$ vim outputs.tf

И в него вставить нужно следующие строки:

output "record_ids" {
    description = ""
    value       = "${cloudflare_record.record.*.id}"
}

output "record_names" {
    description = ""
    value       = "${cloudflare_record.record.*.name}"
}

output "record_values" {
    description = ""
    value       = "${cloudflare_record.record.*.value}"
}

output "record_types" {
    description = ""
    value       = "${cloudflare_record.record.*.type}"
}

output "record_ttls" {
    description = ""
    value       = "${cloudflare_record.record.*.ttl}"
}

output "record_prioritys" {
    description = ""
    value       = "${cloudflare_record.record.*.priority}"
}

output "record_hostnames" {
    description = ""
    value       = "${cloudflare_record.record.*.hostname}"
}

output "record_proxieds" {
    description = ""
    value       = "${cloudflare_record.record.*.proxied}"
}

Переходим теперь в папку aws/examples и создадим еще одну папку для проверки написанного чуда:

$ mkdir cloudflare_record && cd $_

Внутри созданной папки открываем файл:

$ vim main.tf

И вставим в него следующий код:

#
# MAINTAINER Vitaliy Natarov "vitaliy.natarov@yahoo.com"
#
terraform {
  required_version = "> 0.9.0"
}
provider "cloudflare" {
    email = ""
    token = ""
}
module "cloudflare_record" {
    source                          = "../../modules/cloudflare_record"
    name                            = "cloudflare_record"
}

В файле стоит прописать все необходимое, но самое главное:

email — Мыло при регистрации аккаунта в клаудфлюре.
token — Сгенерированный токен от клаудфлюра.

Еще полезности:

Все уже написано и готово к использованию. Ну что, начнем тестирование. В папке с вашим плейбуком, выполняем:

$ terraform init

Этим действием я инициализирую проект. Затем, подтягиваю модуль:

$ terraform get

PS: Для обновление изменений в самом модуле, можно выполнять:

$ terraform get -update

Проверим валидацию:

$ terraform validate

Запускем прогон:

$ terraform plan

Мне вывело что все у меня хорошо и можно запускать деплой:

$ terraform apply

Как видно с вывода, — все прошло гладко! Чтобы удалить созданное творение, можно выполнить:

$ terraform destroy

Весь материал аплоаджу в github аккаунт для удобства использования:

$ git clone https://github.com/SebastianUA/terraform.git

Вот и все на этом. Данная статья «Работа с CloudFlare и Terraform в Unix/Linux» завершена.

PER-FLOW

Индивидуальные потоки трафика передаются по одному или второму линку. При этом уходит проблема с реордерингом пакетов >> на application level меньше зажержек. Также становится возможным эффективное внедрение QOS, т.к. на сети одинаковый пользовательский трафик будет гулять потоками.

По умолчанию поток (flow) — это трафик, имеющий один вх интерфейс, одинаковый src и dst address, а также одинаковый протокол. Можно включить дополнительные элементы 3 и 4 уровня, но это требует доп конфигурации.

Для распознавания потока по параметрам 3/4 уровней, настраиваем hash-key:

set forwarding-options hash-key family inet layer-3
set forwarding-options hash-key family inet layer-4
set forwarding-options hash-key family mpls label-1
set forwarding-options hash-key family mpls label-2
set forwarding-options hash-key family mpls payload ip
set forwarding-options hash-key family multiservice source-mac
set forwarding-options hash-key family multiservice destination-mac
set forwarding-options hash-key family multiservice payload ip layer-3

Для IP обязательно указывать l3 и l4. Иначе не будет работать ни l3, ни l4.
Для ipv6 load-balancing по дефолту делается по l3 и l4, так что дополнительной настойки не требует.
Для mpls и vpls также можно поменять дефолтные hash-key.

IGP load-balancing: выбирается один возможный путь к адресу назначения. Даже есть есть обходные пути. Когда добавляются или удаляются возможные next-hop — junos заново делает выбор пути.

BGP load-balancing = per-prefix load balancing: включается в случае, когда у маршруты получены от IBGP соседа с одинаковым next-hop. Далее роутер резолвит next-hop и в случает, если до него есть несколько путей, трафик до него пойдет по рандомно-выбранным путям. Но при этом трафик до каждого префикса будет следовать только по одному выбранному пути.

То есть если от ibgp-пира прилетело 20 префиксов, где в качестве hext-hop стоит ip ibgp-пира: рандомным образом (используя hashing алгоритм) трафик до ibgp-пира будет выбран одним из путей. То есть для 15-ти префиксов трафик до ibgp-пира пойдет одним путем, для 5ти — другим. (или 10/10, то есть из-за рандомности может возникнуть вариант распределения 20/0 — тогда ни о какой балансировке речи и не идёт). Поэтому погалаться полностью на дефолтное поведение не стоило бы.