PostgreSQL в Azure. Часть 1
Этой статьей мы начинаем цикл заметок об использовании PostgreSQL в Microsoft Azure.
Первая статья будет об установке и настройке кластера PostgreSQL:
- Знакомство с ресурсами Azure
- Управление через azure cli
- Выбор подходящего хранилища
- Сборка классической связки ведущий-ведомый в одной группе доступности
Задача этой части — реализовать схему, включающую следующие компоненты, ресурсы Azure: 
Делать мы будем это при помощи azure cli. Вы можете не устанавливать azure-cli и сделать все через веб-интерфейс portal.azure.com, но управление и создание через 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 можно здесь. Все последующие команды azure cli запускаются с вашего рабочего компьютера. Начнем с того, что нам необходимо представиться системе и получить токен:
azure login
Подробнее про способы авторизации можно прочитать здесь.
Создаем группу ресурсов (контейнер ресурсов) в Северной Европе:
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
Подробнее про группы доступности можно прочитать здесь.
Настало время настройки виртуальной машины. Доступные типы виртуальных машин и их ограничения можно узнать через команду:
azure vm sizes -l northeurope
В списке будет более 50 типов машин, с ценами можно ознакомиться здесь. К более дешевым можно подключить меньшее количество дисков (общее количество дисков может быть от 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. Про различные типы хранилищ можно почитать тут. Для начала представим результаты нашего тестирования хранилища:
Создадим аккаунт хранилища 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
Итого мы имеем две виртуальные машины, между которыми настроена потоковая асинхронная репликация, работающая в одной группе доступности. В следующей части статьи мы обсудим резервные копии и балансировку клиентов.
Ждите продолжения!
