Этой статьей мы начинаем цикл заметок об использовании PostgreSQL в Microsoft Azure.

Первая статья будет об установке и настройке кластера PostgreSQL:

• Знакомство с ресурсами Azure
• Управление через azure cli
• Выбор подходящего хранилища
• Сборка классической связки ведущий-ведомый в одной группе доступности

Задача этой части — реализовать схему, включающую следующие компоненты, ресурсы Azure:

Делать мы будем это при помощи azure cli. Вы можете не устанавливать azure-cli и сделать все через веб-интерфейс portal.azure.com ^[1], но управление и создание через cli мне показалось более наглядным.

Утилита azure cli кроссплатформенная и работает везде, где можно работает nodejs. Установить ее под linux можно так:

# dnf install npm || apt-get install npm
NPM_CONFIG_PREFIX=~/.npm-global npm install -g 'git://github.com/Azure/azure-xplat-cli.git#v0.9.20-April2016'
echo 'NPM_PACKAGES="$HOME/.npm-global"' >> ~/.bash_profile
echo 'export PATH="$PATH:$NPM_PACKAGES/bin"' >> ~/.bash_profile

Ознакомиться с основными командами azure cli можно здесь ^[2]. Все последующие команды azure cli запускаются с вашего рабочего компьютера. Начнем с того, что нам необходимо представиться системе и получить токен:

azure login

Подробнее про способы авторизации можно прочитать здесь ^[3].

Создаем группу ресурсов (контейнер ресурсов) в Северной Европе:

azure group create --name pg-resource-group --location northeurope

Создаем виртуальную локальную сеть 10.0.0.0/8 и подсеть 10.0.0.0/24:

azure network vnet create -g pg-resource-group -l northeurope --address-prefixes 10.0.0.0/8 --name pg-vnet
azure network vnet subnet create -g pg-resource-group --vnet-name pg-vnet --address-prefix 10.0.0.0/24 --name pg-vnet-subnet

Так как управлять мы собираемся через ssh по внешнему ip-адресу, создаем правила сетевого экрана и разрешаем подключения извне только к 22 порту:

azure network nsg create -g pg-resource-group -l northeurope --name pg-nsg
azure network nsg rule create -g pg-resource-group --nsg-name pg-nsg --name AllowSSH --protocol Tcp --access Allow --destination-port-range 22 --priority 200 --direction Inbound

Настраиваем внешний ip-адрес (public-ip), сетевой адаптер с приватной сетью и подсеть для ведущего:

azure network public-ip create -g pg-resource-group -l northeurope --allocation-method Static --name pg-public-1
azure network nic create -g pg-resource-group -l northeurope --subnet-name pg-vnet-subnet --subnet-vnet-name pg-vnet --private-ip-address 10.0.0.101 --network-security-group-name pg-nsg --name pg-nic-1

Создаем группу доступности. Вкратце это кластер машин, разделенный на группы (домены), которые не могут быть недоступны одновременно:

azure availset create -g pg-resource-group -l northeurope --name pg-availability-set

Подробнее про группы доступности можно прочитать здесь ^[4].

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

azure vm sizes -l northeurope

В списке будет более 50 типов машин, с ценами можно ознакомиться здесь ^[5]. К более дешевым можно подключить меньшее количество дисков (общее количество дисков может быть от 1 до 40). Для тестирования мастера выбран Standard_DS4_v2: 8 CPU, 28GB RAM, к которому можно подключить до 16 дисков premium storage.

Команда создания виртуальной машины, которая подразумевает пользователя pg с sudo-правами и разрешеным входом по ssh с применением ssh-ключа:

azure vm create -g pg-resource-group -l northeurope --nic-name pg-nic-1 --os-type Linux --image-urn OpenLogic:CentOS:7.2:latest --admin-username pg --ssh-publickey-file ~/.ssh/id_rsa.pub --vm-size Standard_DS4_v2 --public-ip-name pg-public-1 --availset-name pg-availability-set --name pg-1

Посмотреть параметры созданной машины, а также внешние ip, можно через команду:

azure vm show -g pg-resource-group --name pg-1

Теперь мы имеем виртуальную машину с установленной CentOS 7.2, запущенной в приватной виртуальной сети pg-vnet с ip-адресом 10.0.0.101 и публичным pg-public-1, по которому мы можем попасть на ssh извне. Необходимо создать диск, на котором будут расположены данные нашего PostgreSQL. Про различные типы хранилищ можно почитать тут ^[6]. Для начала представим результаты нашего тестирования хранилища:

Создадим аккаунт хранилища Premium LRS с именем pgplrs (оно должно быть уникальным в пределах azure):

azure storage account create -g pg-resource-group -l northeurope --type PLRS pgplrs

Создадим диск и подключим его к виртуальной машине:

azure vm disk attach-new -g pg-resource-group -l northeurope --vm-name pg-1 --lun 1 --size-in-gb 512 --vhd-name pgdata-1 --host-caching ReadOnly --storage-account-name pgplrs

Создадим и запустим виртуальную машину pg-2:

azure network public-ip create -g pg-resource-group -l northeurope --allocation-method Static --name pg-public-2
azure network nic create -g pg-resource-group -l northeurope --subnet-name pg-vnet-subnet --subnet-vnet-name pg-vnet --private-ip-address 10.0.0.102 --network-security-group-name pg-nsg --name pg-nic-2
azure vm create -g pg-resource-group -l northeurope --nic-name pg-nic-2 --os-type Linux --image-urn OpenLogic:CentOS:7.2:latest --admin-username pg --ssh-publickey-file ~/.ssh/id_rsa.pub --vm-size Standard_DS4_v2 --public-ip-name pg-public-1 --availset-name pg-availability-set --name pg-2
azure vm disk attach-new -g pg-resource-group -l northeurope --vm-name pg-2 --lun 1 --size-in-gb 512 --vhd-name pgdata-2  --host-caching ReadOnly --storage-account-name pgplrs
azure vm start -g pg-resource-group pg-2

Теперь мы можем подключиться по ssh к pg-1 под пользователем pg:

ssh pg-public-1 -l pg -i ~/.ssh/id_rsa

Все дальнейшие действия мы будем выполнять на машине pg-1. Сразу после подключения диска нужно его сопоставить с физическим блочным устройством, доступным на виртуальной машине. Для этого запускаем команду:

[root@pg-1 ~] $ dmesg | tail -n 10
[  488.417024] Adjusting hyperv_clocksource more than 11% (1945964553 vs 1862270976)
[  525.969741] scsi 5:0:0:0: Direct-Access     Msft     Virtual Disk     1.0  PQ: 0 ANSI: 4
[  526.001471] sd 5:0:0:0: Attached scsi generic sg3 type 0
[  526.018792] sd 5:0:0:0: [sdc] 1073741824 512-byte logical blocks: (549 GB/512 GiB)
[  526.039690] sd 5:0:0:0: [sdc] 4096-byte physical blocks
[  526.053643] sd 5:0:0:0: [sdc] Write Protect is off
[  526.065818] sd 5:0:0:0: [sdc] Mode Sense: 0f 00 10 00
[  526.065985] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[  526.091754]  sdc: unknown partition table
[  526.105263] sd 5:0:0:0: [sdc] Attached SCSI disk

Из этих сообщений можно понять, что имя блочного устройства, назначенного подключенному диску: /dev/sdc. Создаем на нем файловую систему:

[root@pg-1 ~] $ mkfs.ext4 /dev/sdc
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdc is entire device, not just one partition!
Proceed anyway? (y,n) y

Теперь мы должны создать запись в fstab. Получаем UUID устройства:

[root@pg-1 ~] $ blkid /dev/sdc
/dev/sdc: UUID="8cb25a32-175b-4c78-b557-8153327d48ba" TYPE="ext4"

И монтируем диск, предварительно создав точку монтирования и добавив запись в fstab:

[root@pg-1 ~] $ mkdir -p /var/lib/pgsql
[root@pg-1 ~] $ echo 'UUID=8cb25a32-175b-4c78-b557-8153327d48ba /var/lib/pgsql  ext4  defaults  0 0' >> /etc/fstab
[root@pg-1 ~] $ mount -a

Пришло время установки софта, подключаем репозиторий:

[root@pg-1 ~] $ rpm -ivh http://repo.postgrespro.ru/pgpro-9.5/keys/postgrespro-9.5.centos95.noarch.rpm

Устанавливаем софт:

[root@pg-1 ~] $ yum install postgrespro95-server postgrespro95-contrib

Включаем сервис и инициализируем экземпляр СУБД:

[root@pg-1 ~] $ chkconfig postgresql-9.5 on
[root@pg-1 ~] $ service postgresql-9.5 initdb
[root@pg-1 ~] $ service postgresql-9.5 start

Дальнейшие команды мы будем выполнять под пользователем postgres:

[root@pg-1 ~] $ su -l postgres

Разрешаем подключение к серверу в pg_hba с ip 10.0.0.101-102 для репликации:

[postgres@pg-1 ~] $ echo 'host  replication  replication  10.0.0.101/30  md5'  >> /var/lib/pgsql/9.5/data/pg_hba.conf

Создаем пользователя для репликации:

[postgres@pg-1 ~] $ /usr/pgsql-9.5/bin/psql -U postgres postgres

postgres=$ CREATE ROLE replication WITH REPLICATION PASSWORD 'password' LOGIN;
CREATE ROLE

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

[postgres@pg-1 ~] $ /usr/pgsql-9.5/bin/psql -U postgres postgres

postgres=$ alter system set listen_addresses to '*';
ALTER SYSTEM
postgres=$ alter system set wal_level to hot_standby;
ALTER SYSTEM
postgres=$ alter system set max_wal_senders to 3;
ALTER SYSTEM
postgres=$ alter system set wal_keep_segments to 128;
ALTER SYSTEM

Проверяем, применены ли параметры:

postgres=$ select * from pg_file_settings where not applied;
                  sourcefile                  | sourceline | seqno |       name       |   setting   | applied
----------------------------------------------+------------+-------+------------------+-------------+---------
 /var/lib/pgsql/9.5/data/postgresql.auto.conf |          3 |    20 | wal_level        | hot_standby | f
 /var/lib/pgsql/9.5/data/postgresql.auto.conf |          4 |    21 | max_wal_senders  | 3           | f
 /var/lib/pgsql/9.5/data/postgresql.auto.conf |          6 |    23 | listen_addresses | *           | f
(3 rows)

Перезапускаем службу:

[postgres@pg-1 ~] $ /usr/pgsql-9.5/bin/pg_ctl restart -D /var/lib/pgsql/9.5/data -w

Теперь мы можем подключиться по ssh к pg-2 под пользователем pg:

ssh pg-public-2 -l pg -i ~/.ssh/id_rsa

Все дальнейшие команды мы выполняем на машине pg-2. Пришло время заняться репликой: аналогично подключаем диск и устанавливаем postgrespro. И выполняем вход на pg-2 под пользователем postgres:

[root@pg-2 ~] $ su -l postgres

После этого подготавливаем реплику одной командой:

[postgres@pg-2 ~] $ /usr/pgsql-9.5/bin/pg_basebackup -U replication -D /var/lib/pgsql/9.5/data -R -x -P -c spread -h 10.0.0.101 -W
Password:
38895/38895 kB (100%), 1/1 tablespace

Теперь у нас есть полная копия в /var/lib/pgsql/9.5/data и прописанный файл recovery.conf, в который рекомендую добавить информацию о файле-триггере, при создании которого этот экземпляр СУБД из ведомого превратится в полноценный ведущий сервер. Таким образом, содержимое файла будет такое:

[postgres@pg-2 ~] $ cat /var/lib/pgsql/9.5/data/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=replication password=password host=10.0.0.101 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'
trigger_file = '/var/lib/pgsql/stop_replication_trigger'

Запускаем экземпляр с репликой:

[postgres@pg-2 ~] $ /usr/pgsql-9.5/bin/pg_ctl start -w -D /var/lib/pgsql/9.5/data

И проверяем, запущен ли приёмник WAL (процесс wal receiver):

[postgres@pg-2 ~] $ ps axufwwww
postgres 29423  0.1  0.2 372920 16564 ?        S    09:07   0:00 /usr/pgsql-9.5/bin/postmaster -D /var/lib/pgsql/9.5/data
postgres 29425  0.0  0.0 225568  1608 ?        Ss   09:07   0:00  _ postgres: logger process
postgres 29426  0.1  0.0 372960  2464 ?        Ss   09:07   0:00  _ postgres: startup process   recovering 0000010000000000000003
postgres 29427  0.0  0.0 372920  1964 ?        Ss   09:07   0:00  _ postgres: checkpointer process
postgres 29428  0.0  0.0 372920  1976 ?        Ss   09:07   0:00  _ postgres: writer process
postgres 29429  0.2  0.0 379640  3360 ?        Ss   09:07   0:00  _ postgres: wal receiver process   streaming 0/3000060

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

Ждите продолжения!

Автор: Postgres Professional

Источник ^[7]