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.
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
|
200
|
El valor por defecto en PostgreSQL es 100. La configuración por defecto en ThingWorx 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 número de servidores en el clúster multiplicado por el tamaño máximo de agrupación configurado en el fichero platform-settings.json para 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
|
|
|
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 o node2, node0 o node0, 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í:
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
|
<ip of backend#>
<n.º de puerto del backend>
1
/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
|
el
|
Permite activar pool_hba.conf.
|
||
|
master_slave_mode
|
el
|
Esto indica a PostgresSQL que se está utilizando la replicación de maestro/en espera.
|
||
|
load_balance_mode
|
off
|
|
||
|
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
|
10
|
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.
|
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.
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.
Para obtener información detallada sobre la configuración de pool_hba.conf, consulte 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.
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.
Para obtener información detallada sobre la configuración de pool_hba.conf, consulte 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.
|