Instalación y configuración de PostgreSQL HA

Alta disponibilidad de ThingWorx > Alta disponibilidad de PostgreSQL > Instalación y configuración de PostgreSQL HA

Las directrices que se proporcionan a continuación son para soportar la implementación del diagrama anterior. Están dirigidas a los administradores y los usuarios de PostgreSQL que implementen una instancia de PostgreSQL HA.

A modo de referencia, en Ejemplo de implementación de alta disponibilidad de PostgreSQL con Pgpool-II se incluye una guía de ejemplo de descargas, secuencias de línea de comandos y scripts que se utilizan para implementar esta solución.

Documentos de referencia

Antes de instalar PostgreSQL, se deben leer y comprender todos los documentos de instalación y configuración, incluida la documentación del software necesario. Es importante comprender y aplicar la configuración adecuada, incluidas las recomendaciones de seguridad.

En los siguientes vínculos se proporciona información útil para la instalación y configuración de PostgreSQL HA mediante la replicación en flujo y Pgpool-II para la gestión de nodos.

• Manuales de instalación detallados de PostgreSQL

• Opciones de replicación

• Documentación de alta disponibilidad

• Pgpool-II

Instalación de PostgreSQL y creación de rol de nuevo usuario en PostgreSQL

Las instrucciones para instalar y configurar PostgreSQL se proporcionan en el manual de instalación de ThingWorx. Consulte el manual de instalación para obtener la versión específica de ThingWorx que se implementará. Las mismas tareas de instalación y configuración se deben realizar en los tres nodos de PostgreSQL.

Configuración y ejecución del script de base de datos PostgreSQL

En el manual de instalación de ThingWorx se proporcionan instrucciones para crear la base de datos en PostgreSQL. Consulte el manual de instalación para obtener la versión específica de ThingWorx que se implementará. Las mismas tareas de instalación y configuración se deben realizar en los tres nodos de PostgreSQL.

Configuración y ejecución del script de esquemas del proveedor de modelos/datos

Las instrucciones para crear el esquema de ThingWorx en PostgreSQL se proporcionan en el manual de instalación de ThingWorx. Consulte el manual de instalación para ver la versión específica de ThingWorx que se implementará. Las mismas tareas de configuración se deben realizar en los tres nodos de PostgreSQL.

Creación de un usuario de replicación en todos los nodos de PostgreSQL

Cree un usuario de PostgreSQL para las tareas de replicación del administrador en todos los nodos. Se debe utilizar el mismo nombre de usuario y contraseña.

Adición de parámetros de replicación a todos los nodos de PostgreSQL

En la siguiente tabla se incluyen parámetros de PostgreSQL que controlan sus servicios de replicación.

En los valores que se indican en la columna de configuración se refleja la implementación de ejemplo de la arquitectura de referencia, pero los valores se pueden modificar para el entorno. Para gran parte de la configuración de la siguiente tabla, se proporcionan vínculos para determinar los valores de configuración adecuados del entorno.

Configuración	Configuración	Descripción
listen_addresses	‘*’	Escuche en todas las interfaces de red. En algunas situaciones, si hay varias interfaces de red, es mejor restringir esta opción a interfaces de red específicas.
Puerto	5432	Este es el número de puerto por defecto.
max_connections	150	El valor por defecto en PostgreSQL es 100. La configuración por defecto en ThingWorx también es 100 (maxpoolsize). Este número se debe aumentar según el número total de conexiones simultáneas que se esperan en la base de datos. Siempre debe ser mayor que el de la configuración maxpoolsize en el fichero platform-settings.json de ThingWorx.
shared_buffers	1024MB	Ajuste del rendimiento opcional. Permite definir la cantidad de memoria que el servidor de bases de datos utiliza para los búferes de memoria compartida. Se recomienda definirlo en un cuarto de la memoria disponible en el ordenador. Consulte Resource Consumption > Memory.
work_mem	32MB	Ajuste del rendimiento opcional. Permite especificar la cantidad de memoria que las operaciones de clasificación interna y las tablas hash deben utilizar antes de escribir en ficheros de disco temporales. Consulte Resource Consumption > Memory. Desplácese hacia abajo hasta work_mem.
maintenance_work_mem	512MB	Ajuste del rendimiento opcional. Permite especificar la cantidad máxima de memoria que las operaciones de mantenimiento deben utilizar. Consulte Resource Consumption_Memory. Esta opción aparece justo después de work_mem.
wal_level	enum	Ajuste del rendimiento opcional. Permite especificar la cantidad máxima de memoria que las operaciones de mantenimiento deben utilizar. Consulte Write Ahead Log > Settings.
synchronous_commit	el	Vaya a Write Ahead Log > Settings y desplácese hacia abajo hasta synchronous_commit (enum).
archive_mode	el	• https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial#Setting_Up_Archiving_On_The_Master • Write Ahead Log >Archiving
archive_command	‘cd .’	Vaya a Write Ahead Log > Archiving y desplácese hacia abajo hasta archive_command (cadena).
max_wal_size	10	Vaya a Write Ahead Log y pulse en el enlace ARCHIVING. Desplácese hacia arriba hasta max_wal_size (número entero). Para obtener más información sobre la configuración de WAL, consulte WAL Configuration en la documentación de PostgreSQL 10.
synchronous_standby_names	node1, node2 or node2, node0, ornode0, node1	Como lista separada por comas, añada el valor "application_name" del otro nodo, tal como se especifica en los ficheros recovery.conf. Consulte synchronous_commit en la sección de configuración de Write Ahead Log.
hot_standby	true/false	Para obtener información sobre este modo, consulte Hot Standby
fsync	el	Vaya a Write Ahead Log > Settings y desplácese hacia abajo hasta fsync.
checkpoint settings		Consulte Checkpoints para obtener información sobre la configuración de controles.

Establecimiento de los scripts start_replication y retargetMaster

En cada nodo se debe establecer un script para activar los servicios de replicación y asegurarse de que el nodo de PostgreSQL esté sincronizado con el sistema.

Asimismo, en cada nodo se debe establecer un script que pueda crear e implementar un fichero recovery.conf. El fichero recovery.conf debe contener los cambios necesarios para definir cuál es el nodo maestro y cuál es el nodo de espera en función del fallo que se produzca.

Ajuste de los parámetros de conexión externa a todos los nodos de PostgreSQL

Modifique los parámetros de cada fichero pg_hba.conf para que el usuario y la base de datos puedan almacenar los datos de ThingWorx a los que se debe acceder desde la dirección IP. Esta dirección IP se conectará a la base de datos.

Si se conecta desde Pgpool-II, verifique que el acceso mediante autenticación se ajuste a la documentación de Pgpool-II (md5 o trust) incluida aquí.

Para obtener más información sobre el fichero pg_hba. conf, consulte el tema The pg_hba.conf File in the PostgreSQL 10 documentation.

Reinicio de los servicios de PostgreSQL para iniciar la replicación

Reinicie todos los nodos de PostgreSQL en una secuencia para controlar qué nodo es maestro (el primero que se inició), cuál es el nodo en espera principal (el segundo que se inició) y cuál es el tercero (el último que se inició).

Para el nodo maestro, inicie los servicios de PostgreSQL.

Para el nodo en espera principal, primero se debe ejecutar el script start_replication para sincronizarlo con el nodo maestro. A continuación, inicie los servicios de PostgreSQL.

Para el segundo nodo en espera, primero se debe ejecutar el script start_replication para sincronizarlo con el nodo en espera principal. A continuación, inicie los servicios de PostgreSQL.

Instalación de nodos de Pgpool-II

Antes de instalar Pgpool, se deben leer y comprender todos los documentos de instalación, incluida la documentación de cualquier software necesario como requisito previo. Es importante comprender y aplicar la configuración adecuada, incluidas las recomendaciones de seguridad.

La información de descarga de Pgpool-II está disponible aquí:

• http://pgpool.net/mediawiki/index.php/Downloads

Consulte la documentación del sistema operativo para obtener las instrucciones de instalación de Pgpool-II. La misma versión de Pgpool-II debe instalarse en todos los nodos para ejecutar los servicios de Pgpool-II.

Configuración de nodos de Pgpool-II

En la siguiente tabla se incluyen los parámetros que se deben modificar para una instalación de Pgpool-II. Todos los parámetros de Pgpool-II se mantienen en el fichero pgpool. conf. Estos valores y propiedades deben añadirse a todos los nodos de Pgpool-II.

Configuración

Valor

Descripción

listen_addresses

‘*’

Elija valores que permitan al proveedor de modelos de la aplicación ThingWorx conectarse a Pgpool-II, independientemente de si se encuentra en el mismo servidor o en otro distinto.

port

5432

Puerto TCP de escucha de conexiones de cliente.

pcp_listen_address

Filtro de IP/host para conexiones del Protocolo de control de puertos (PCP) (*permite todo).

pcp_port

9898

Puerto TCP de escucha para conexiones de PCP.

backend_hostname

backend_port

backend_weight

backend_data_directory

backend_flag

<n.º de puerto del backend>

/var/lib/postgresql/10.x/main

ALLOW_TO_FAILOVER

Defina estos valores de configuración de backend para los tres nodos (el maestro y los dos en espera). Por ejemplo, backend_hostname0 es el maestro, backend_hostname1 está en espera, etc. Consulte la documentación en línea de PostgreSQL para obtener más información.

enable_pool_hba

Permite activar pool_hba.conf.

master_slave_mode

Esto indica a Postgres que se está utilizando la replicación de maestro/en espera.

load_balance_mode

off

PTC no recomienda el equilibrio de la carga para ThingWorx.

master_slave_sub_mode

stream

Esto indica a Pgpool-II que debe utilizar la replicación en flujo de fábrica de PostgreSQL.

replication_mode

off

No utilice la replicación de Pgpool-II. En su lugar, utilice la replicación en flujo de fábrica de PostgreSQL.

sr_check_period

Retraso en segundos de la replicación en flujo.

sr_check_user

replicator

Usuario de replicación en flujo.

sr_check_password

replicator

Contraseña de replicación en flujo.

sr_check_database

postgres

Base de datos de replicación en flujo.

health_check_user

postgres

Usuario de comprobación de estado de conmutación por error.

health_check_password

postgres

Contraseña de comprobación de estado de conmutación por error.

health_check_database

postgres

Base de datos de comprobación de estado de conmutación por error.

failover_command

/etc/pgpool2/failover.sh %d %h %D %m %H %R %M %P

Consulte la sección failover_command que aparece a continuación para obtener más información sobre esta configuración.

Consulte también los siguientes scripts de ejemplo en el Apéndice C:

• failover.sh

• retargetMaster_001.sh

• retargetMaster_002.sh

• retargetMaster_003.sh

num_init_children

max_pool

max_child_connections

superuser_reserved_connections

Parámetros de ajuste de rendimiento. Esta configuración está relacionada con las funciones de agrupación de conexiones de Pgpool-II. Es necesario asegurarse de proporcionar suficientes conexiones al inicio, necesarias para satisfacer los requisitos de rendimiento de tráfico de volumen más altos, además de no superar la configuración de conexiones máximas de los nodos de las bases de datos de PostgreSQL. Consulte la sección Agrupaciones del manual (véase el vínculo anterior) para obtener sugerencias y fórmulas para calcular valores.

Es necesario asegúrese de que num_init_children sea mayor que maxpoolsize en modelproviderconfig.json y que max_connections en postgresql.conf sea mayor que la configuración num_init_children.

Configuración del script de conmutación por error de PostgreSQL

Establezca un script de conmutación por error en cada nodo de Pgpool-II al que el servicio de Pgpool-II llamará cuando se detecte un fallo. Este script debe contener la lógica y las tareas que se deben realizar para cualquier fallo de nodo de PostgreSQL.

Consulte Failover section of the PostgreSQL 10 online documentation.

Actualización de la configuración de PCP

Actualice el fichero pool_hba. conf de modo que se reconozcan todos los servidores ThingWorx.

Para las solicitudes de ThingWorx a PostgreSQL, Pgpool-II se conectará a los nodos de PostgreSQL mediante las credenciales de ThingWorx para mantener las restricciones y los privilegios de acceso establecidos. En el fichero pool_hba.conf se utilizan los mismos métodos de autenticación, opciones de autenticación (md5, trust, etc.) y formato que pg_hba.conf.

Encontrará más información sobre la configuración de pool_hba. conf aquí.

• http://www.pgpool.net/docs/latest/en/html/client-authentication.html

Actualización de la autenticación del cliente

Actualice el fichero pool_hba.conf de modo que se reconozcan todos los servidores ThingWorx.

Encontrará más información sobre la configuración de pool_hba.conf aquí.

• http://www.pgpool.net/docs/latest/en/html/client-authentication.html

Configuración de Pgpool-II para la conmutación por error

En las configuraciones de alta disponibilidad, Pgpool-II mantiene un funcionamiento activo/pasivo, normalmente con un nodo de Pgpool-II activo y un nodo en espera. Pgpool-II proporciona el proceso de guardián para supervisar el estado de los nodos y activa el nodo en espera cuando falla el nodo principal.

Consulte la documentación de Pgpool para obtener más información sobre la configuración de Watchdog http://www.pgpool.net/docs/latest/en/html/example-watchdog.html).

En la siguiente tabla se incluyen la configuración y los valores que se deben tener en cuenta al configurar el guardián en Pgpool-II. Estos valores y configuraciones se deben añadir al fichero pgpool. conf de cada nodo de Pgpool-II.

Configuración	Valor	Descripción
use_watchdog	el	Permite activar el guardián en Pgpool-II.
wd_hostname	'{IP address of this Pgpool-II node}'	Nombre de host o dirección IP de este guardián.
wd_port	9000	Número de puerto de este guardián.
delegate_IP	'{Virtual IP address to access PostgreSQL}'	Dirección IP virtual que los clientes utilizan para acceder a PostgreSQL (a través de Pgpool-II).
ifconfig_path	/etc/pgpool2	Ruta absoluta del directorio que contiene los comandos o scripts if_up_cmd e if_down_cmd.
if_up_cmd	'ifup.sh $_IP_$ <eni id of Pgpool node>'	Comando que se emite cuando Pgpool-II intenta abrir la interfaz IP virtual con la dirección delegate_IP. El usuario puede recuperar el ID de eni del nodo de Pgpool-II conectándose a la consola de administración de EC2 y yendo a su instancia de Pgpool-II. En su descripción de la consola, busque la entrada Network interfaces, pulse en eth0 y busque el ID de interfaz. Utilícela para el $<eni id of Pgpool node>.
if_down_cmd	'ifdown.sh $_IP_$ <eni id of Pgpool node>'	Comando que se emite cuando Pgpool-II intenta cerrar la interfaz IP virtual con la dirección delegate_IP. Consulte if_up_cmd para obtener el ID de eni del nodo de Pgpool-II.
arping_path	/usr/bin	Ruta del paquete de instalación de iputils-arping.
arping_cmd	arping -U $_IP_$ -w 1	Comando arping que se utiliza para verificar las direcciones IP.
heartbeat_destination0	'{IP address of the other Pgpool-II node}'	Dirección IP en la que se realiza la comprobación de latidos; valor de la configuración other_pgpool_hostname0
heartbeat_destination_port0	9694	Utilice el valor por defecto.
heartbeat_device	'eth0'	Dispositivo NIC de la dirección IP para la comunicación de latidos.
other_pgpool_hostname0	'{IP address of the other Pgpool-II node}'	Dirección IP de la otra instancia del servidor Pgpool-II.
other_pgpool_port0	5432	Puerto al que escucha el otro nodo de Pgpool-II.
other_wd_port0	9000	Puerto al que escucha la otra función de guardián de Pgpool-II.