В этой статье мы рассмотрим один подход к развертыванию ProxySQL за балансировщиком нагрузки в Google Cloud.

Рассматривая развертывание ProxySQL, у вас есть в основном следующие возможности:

1. Установка ProxySQL на существующие серверы приложений
2. Предоставление выделенного сервера (ов) ProxySQL между серверами приложений и уровнем базы данных.

Каждый подход имеет свои плюсы и минусы, но если существует значительное количество серверов приложений (более дюжины или около того), имеющих выделенный уровень ProxySQL, это может быть более привлекательным вариантом, особенно если нет механизма обнаружения службы на месте ( например,  Consul).

Рассмотрим простой сценарий с мастером и небольшим количеством вспомогательных устройств в одном географическом регионе. Предполагая, что вы следите за лучшей практикой, ваши серверы баз данных должны быть разделены на разные зоны доступности. Поэтому для ProxySQL также имеет смысл иметь как минимум 3 экземпляра (опять же, в разных зонах доступности).

Вот как это будет выглядеть:

Начало работы

Начнем с создания базовой инфраструктуры для нашей POC из оболочки Google Cloud.

Сетевая инфраструктура

Вы можете пропустить эту часть, если у вас уже есть сетевая конфигурация.

1. Создайте собственную сеть VPC

gcloud compute networks create my-custom-network --subnet-mode custom

2. Создайте новую подсеть в своей пользовательской сети VPC.

gcloud compute networks subnets create my-custom-subnet \
--network my-custom-network \
--range 10.240.0.0/16 \
--region us-central1

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

4. Создайте правило брандмауэра, чтобы разрешить трафик ssh, mysql, icmp из любой точки в пользовательскую сеть (опционально)

gcloud compute firewall-rules create allow-tcp22-tcp3306-icmp \
--network my-custom-network \
--allow tcp:22,tcp:3306,icmp

Экземпляры ProxySQL

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

1. Создайте 3 экземпляра ProxySQL в разных зонах

gcloud compute instances create tst-proxysql01 \
--image-family debian-9 \
--image-project debian-cloud \
--tags proxysql-lb \
--zone us-central1-a \
--subnet my-custom-subnet

gcloud compute instances create tst-proxysql02 \
--image-family debian-9 \
--image-project debian-cloud \
--tags proxysql-lb \
--zone us-central1-b \
--subnet my-custom-subnet

gcloud compute instances create tst--proxysql03 \
--image-family debian-9 \
--image-project debian-cloud \
--tags proxysql-lb \
--zone us-central1-c \
--subnet my-custom-subnet

Теперь мы создадим группы экземпляров. Можно было бы установить свойства автоматического масштабирования группы для более эффективного управления экземплярами, но это выходит за рамки этой статьи.

2. Создайте 3 группы экземпляров для экземпляров ProxySQL в каждой зоне

gcloud compute instance-groups unmanaged create us-proxysql-ig1 \
--zone us-central1-a

gcloud compute instance-groups unmanaged create us-proxysql-ig2 \
--zone us-central1-b

gcloud compute instance-groups unmanaged create us-proxysql-ig3 \
--zone us-central1-c

3. Добавьте экземпляры ProxySQL в соответствующую группу экземпляров

gcloud compute instance-groups unmanaged add-instances us-proxysql-ig1 \
--instances tst-proxysql01 \
--zone us-central1-a

gcloud compute instance-groups unmanaged add-instances us-proxysql-ig2 \
--instances tst-proxysql02 \
--zone us-central1-b

gcloud compute instance-groups unmanaged add-instances us-proxysql-ig3 \
--instances tst-proxysql03 \
--zone us-central1-c

ProxySQL за балансировщиком нагрузки

Проверка состояния

Первое, что нам нужно настроить - это проверка состояния. Это то, что позволит балансировщику нагрузки узнать, какие экземпляры ProxySQL работоспособны.

Мы могли бы использовать простую проверку TCP здесь, поэтому, когда TCP ACK получен, член отмечен как работоспособный. Проблема в том, что были (редкие) случаи, когда ProxySQL не реагирует, а TCP ACK все еще возвращается операционной системой. Поэтому лучше проверить фактическую строку ответа от ProxySQL.

Мы заметили, что ProxySQL возвращает букву J в первой строке ответа, поэтому мы решили использовать это в строке ответа, чтобы проверить, что ProxySQL жив. Мы немного играли с более сложными строками ответа, но не смогли заставить их работать.

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

1. Настройте проверки работоспособности балансировщика нагрузки для портов ProxySQL.

gcloud compute health-checks create tcp my-proxysql-health-check \
--port 6032 \
--response="J"

Серверная служба

Следующий шаг - создание резервной копии и добавление к ней групп экземпляров.

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

2. Создайте серверную службу

gcloud compute backend-services create my-proxysql-lb \
--load-balancing-scheme internal \
--region us-central1 \
--health-checks my-proxysql-health-check \
--protocol tcp \
--session-affinity="CLIENT_IP"

3. Добавьте группы экземпляров в бэкэнд

gcloud compute backend-services add-backend my-proxysql-lb \
--instance-group us-proxysql-ig1 \
--instance-group-zone us-central1-a \
--region us-central1

gcloud compute backend-services add-backend my-proxysql-lb \
--instance-group us-proxysql-ig2 \
--instance-group-zone us-central1-b \
--region us-central1

gcloud compute backend-services add-backend my-proxysql-lb \
--instance-group us-proxysql-ig3 \
--instance-group-zone us-central1-c \
--region us-central1

Правила пересылки

Теперь нам нужно создать правило пересылки балансировки нагрузки. Обратите внимание, что если вы не укажете IP-адрес через параметр address, он будет автоматически сгенерирован для вас.

4. Создайте правило пересылки

gcloud compute forwarding-rules create my-proxysql-lb-forwarding-rule \

--load-balancing-scheme internal \

--ports="3306" \

--network default \

--region us-central1 \

--backend-service my-proxysql-lb \

--subnet my-custom-subnet

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/forwardingRules/my-proxysql-lb-forwarding-rule].

IPAddress: 10.240.0.163

IPProtocol: TCP

Правила брандмауэра

Нам нужны некоторые правила брандмауэра, поэтому серверам приложений разрешено доходить до серверов ProxySQL. Обратите внимание, что нам не нужно определенное правило для IP-адреса балансировки нагрузки, достаточно использовать тег, используемый для бэкэндов.

Нам также нужно правило, позволяющее проводить проверки работоспособности. Для этого требуется белый список некоторых внутренних IP-диапазонов, принадлежащих Google.

1. Добавьте правило брандмауэра, чтобы разрешить трафик на балансировщик нагрузки, и от балансировщика нагрузки до внутренних блоков

gcloud compute firewall-rules create allow-proxysql-lb \
--network default \
--source-ranges 10.240.0.0/16 \
--target-tags proxysql-lb \
--allow tcp:3306

2. Добавьте правило брандмауэра, чтобы обеспечить проверку работоспособности

gcloud compute firewall-rules create allow-proxysql-health-check \
--network default \
--source-ranges 130.211.0.0/22,35.191.0.0/16 \
--target-tags proxysql-lb \
--allow tcp:6032

Завершение

Следующим шагом является тестирование, которое вы можете получить в экземплярах ProxySQL через балансировщик нагрузки.

Сначала давайте посмотрим, как выглядят бэкенды:

gcloud compute backend-services get-health my-proxysql-lb --region=us-central1

---
backend: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-a/instanceGroups/us-proxysql-ig1
status:
healthStatus:
- healthState: HEALTHY
instance: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-a/instances/tst-proxysql01
ipAddress: 10.240.0.29
port: 80
kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-proxysql-ig2
status:
healthStatus:
- healthState: HEALTHY
instance: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/tst-proxysql02
ipAddress: 10.240.0.30
port: 80
kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instanceGroups/us-proxysql-ig3
status:
healthStatus:
- healthState: HEALTHY
instance: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instances/tst-proxysql03
ipAddress: 10.240.0.33
port: 80
kind: compute#backendServiceGroupHealth

Немного неясно, почему сообщается о порте 80, но кроме этого все бэкэнды кажутся работоспособными.

Теперь попробуем подключить клиент MySQL через IP-адрес балансировщика нагрузки:

[root@tst-adm01 ~]# mysql -h 10.240.0.163 -uapp_rw -p
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5461327
Server version: 5.5.30 (ProxySQL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select @@hostname;
+------------------------+
| @@hostname |
+------------------------+
| tst-mysql-01 |
+------------------------+
1 row in set (0.05 sec)

Вы можете видеть, что нам удалось добраться до сервера MySQL, называемого tst-mysql-01, который был ранее настроен в ProxySQL.

No Comments