Análisis del código fuente de Memcheck
En general, el trasfondo de todo esto es que el hardware del servidor tiene garantía excesiva y la arquitectura del clúster se optimiza y transforma aprovechando la oportunidad de reemplazar el servidor con garantía excesiva. ?
1. El objetivo de la transformación de la arquitectura del clúster
Antes se han resumido algunos problemas potenciales que existen actualmente, que también son los objetivos de esta mejora de la arquitectura de implementación:
1) Anteriormente, el número de segmentos de GP estaba sobrediseñado debido a limitaciones de recursos, consideración excesiva de funciones y desempeño, y falta de estabilidad del grupo y equilibrio de recursos. Cada nodo de la máquina física se implementa con 10 nodos maestros y 10 nodos espejo. Una vez que un nodo de servidor no está disponible, todo el clúster difícilmente podrá admitir servicios.
2) El equilibrio entre los recursos de almacenamiento y el rendimiento del clúster GP no es suficiente. El almacenamiento GP se basa en RAID-5. Si hay un disco defectuoso, el costo de la reconstrucción del disco es relativamente alto. Si hay otro disco defectuoso durante la reconstrucción, será muy pasivo. Además, los almacenes fuera de línea tienen altos requisitos de calidad de datos y una capacidad de almacenamiento relativamente pequeña. Por tanto, considerando la capacidad de almacenamiento y el rendimiento, elegimos RAID-10.
3) Es necesario mejorar la recuperación de escenarios anormales del clúster. Los escenarios de recuperación de fallas en condiciones anormales del clúster (como apagado anormal del servidor, nodos de datos no disponibles, reemplazo continuo de nodos después de que el servidor esté fuera de garantía). no se ha probado completamente, lo que resulta en que la confianza es relativamente baja en algunas migraciones y transformaciones, y existen algunos puntos ciegos en el conocimiento.
4) La versión del clúster es demasiado baja y todavía hay margen de mejora en la funcionalidad y el rendimiento. Después de todo, este clúster es una versión de hace 4 años y la versión del nodo PG subyacente también es relativamente antigua. Existen ciertas expectativas en términos de funciones y rendimiento, que al menos pueden mantenerse al día.
5) Actualización de la versión del sistema operativo. El sistema operativo anterior estaba basado en CentOS6 y necesitaba adaptarse al menos a CentOS 7.
6) Aceptación de la prueba de presión del grupo TPCH. Una vez implementado el clúster, se requiere una aceptación general de la prueba de estrés del TPCH. Si hay problemas obvios, se requieren ajustes constantes en la configuración y la arquitectura para lograr los objetivos de rendimiento esperados.
Además, existen algunas consideraciones a nivel de aplicación. En resumen, esperamos resolver la mayoría de los puntos débiles, ya sea a nivel del sistema o de la aplicación.
2. Selección y pensamiento de la planificación y el diseño del clúster
Objetivos claros, es decir, dividir las tareas en planificación y diseño. Existen principalmente los siguientes problemas en la planificación y el diseño:
p >
1) Selección de la versión de Greenplum. Actualmente hay dos categorías de versiones principales, una es distribución de código abierto y la versión oficial de Pivotal. Una diferencia entre ellos es que la versión oficial requiere el registro y la firma de un acuerdo, en el que se pueden utilizar herramientas como GPCC, mientras que la versión de código abierto puede implementar la compilación del código fuente o la instalación rpm, y GPCC no se puede configurar. En conjunto, elegimos la versión de código abierto 6.16.2. También preguntamos a algunos amigos de la industria y seleccionamos especialmente algunas versiones que implican correcciones de errores de estabilidad.
2) Selección de tecnología del data mart. En términos de selección de tecnología para el mercado de datos, inicialmente insistí en un modelo basado en PostgreSQL, mientras que el lado comercial esperaba que GP pudiera soportar alguna lógica compleja. Después de mucho tiempo, consultamos a algunos amigos de la industria sobre las opciones basadas en GP, por lo que intentamos hacer una prueba de estrés para que el almacén de datos y el data mart fueran administrados por dos grupos de GP de diferentes tamaños y volúmenes de soporte. .
3) 3) Planificación de capacidad de GP, debido a que el diseño del nodo anterior era un poco excesivo, redujimos la cantidad. Cada servidor tiene 12 nodos de segmento, por ejemplo, un máximo de 12 servidores, 10 de los cuales son nodos de segmento, cada servidor tiene 6 nodos maestros, 6 nodos y 6 espejos, y los otros dos tienen servidores maestros y de respaldo.
4) Selección de la solución de arquitectura de implementación. Es relativamente fácil pensar en la arquitectura de implementación, pero hay muchos detalles a considerar en la implementación.
En primer lugar, considerando que el uso mixto de los nodos activos y en espera de GP puede ahorrar algunos recursos, la arquitectura de implementación del almacén de datos y el mercado de datos está diseñada de esta manera. Sin embargo, tras entrar en la fase de despliegue, rápidamente se descubrió que este modelo de despliegue cruzado no era viable o tenía cierta complejidad.
Además, a nivel de arquitectura de implementación de un único clúster de GP, hay cuatro opciones a considerar.
? Opción 1: Implementación mixta de segmentos activos y de respaldo.
? Opción 2: los segmentos activo, en espera y en espera se implementan de forma independiente y la cantidad de nodos en todo el clúster será menor.
? Opción 3: Despliegue independiente en segmentos, desplegando máquinas virtuales activas y en espera.
? Opción 4: Minimizar la implementación de clústeres de un solo nodo (¿cuál es la opción más segura para los data marts)?
Hay mucho margen de mejora en esta área y, en general, el coste de este tipo de verificación es relativamente alto. La práctica me enseñó una lección. Cuanto más desee tomar atajos, menos desvíos tomará. A veces no sabe cómo cambiar y optimizar y siente que no tiene camino a seguir. Por eso, hemos realizado pruebas y verificaciones relevantes sobre lo anterior. cuatro soluciones.
3. Diseño detallado y práctica de la arquitectura del cluster.
1) Diseñar un diagrama detallado de la arquitectura de implementación.
Basado en el plan general, diseñé el siguiente diagrama de arquitectura de implementación. Cada nodo de servidor tiene seis nodos maestros, seis nodos espejo y seis nodos espejo, y estos servidores se asignan en pares.
2) Optimización de los parámetros centrales
De acuerdo con las recomendaciones y configuraciones específicas de los documentos oficiales, configuramos los parámetros del kernel de la siguiente manera:
vm.swappiness = 10
vm.zone_reclaim_mode = 0
vm.dirty_expire_centisecs = 500
VM sucio _ escritura posterior _ centi segundos = 100
vm.dirty_background_ratio = 0 #Ver memoria del sistema
vm.dirty_ratio = 0
VM sucio_fondo_bytes = 1610612736
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 3943084
vm.overcommit_memory=2
kernel.sem = 500 2048000 200 4096
4. Pasos
1) El primer paso es configurar /etc/hosts, lo que requiere ordenar la IP y los nombres de host de todos los nodos. ?
2) Configurar usuarios, este es un paso habitual.
groupaddgpadmin
useradd gpadmin -g gpadmin
passwd gpadmin
3) Configurar sysctl.conf y la configuración de recursos.
4) Instalar en modo rpm
# yum install-y apr apr-util bzip2 krb5-devel zip
# rpm -ivh open source-greenplum- d b-6.16.2-rhel 7-x86 _ 64 . rpm
5) La configuración de dos archivos host también facilitará la implementación unificada en el futuro. Se recomienda abrir primero los permisos sudo de gpadmin, para que algunas operaciones por lotes complejas puedan procesarse a través de gpssh.
6) Utilice gpssh-exkeys para abrir la relación de confianza ssh. Debe quejarse de esta confianza ssh. El puerto debe ser 22, de lo contrario será muy problemático de manejar. /etc/ssh/sshd_config archivo.
gpssh-exkeys -f lista de hosts
7) Un paso complicado es empaquetar el software Greenplum-db-6.16.2 del maestro y luego distribuirlo a cada máquina de segmento. Todo el proceso incluye empaquetado de archivos, transferencia por lotes y configuración. Puede utilizar gpscp y gpssh para transferir archivos, como gpscp. Los siguientes comandos se transferirán al directorio /tmp.
gpscp -f /usr/local/greenplum-db/conf/host list/tmp/greenplum -d b-6.16.2 .tar .gz=:/tmp
O Instale rpm -ivh directamente en cada servidor.
8)8) El nodo maestro necesita configurar los directorios relevantes por separado, mientras que los directorios de los nodos de segmento se pueden planificar con anticipación. Por ejemplo, colocamos el servidor maestro y el servidor espejo en particiones diferentes. ?
mkdir-p/datos 1/datos gp/datos gp 1
mkdir-p/datos 1/datos gp/datos gp 2
mkdir-p /data 2/gp data/gp datam 1
mkdir -p /data2/gpdata/gpdatam2
9) Lo más importante en todo el proceso es la configuración de gpinitsystem_config, porque el nodo de segmento y la configuración de ID y el nombre del intervalo de puerto se generan dinámicamente de acuerdo con ciertas reglas, por lo que se debe prestar especial atención a la configuración del directorio.
10) El comando clave para implementar un clúster de GP es
gpinitsystem-c gpinitsystem_config-s? Nombre de host en espera
El contenido principal del archivo gpinitsystem_config es el siguiente:
Nombre de host principal=xxxx
declare-a DATA _ DIRECTORY =(/DATA 1/gp DATOS /gp DATOS 1/DATOS 1/gp DATOS/gp DATOS 2/DATOS 1/gp DATOS/gp DATOS 3/DATOS 1/gp DATOS/gp DATOS 4/DATOS 1/gp DATOS/gp DATOS 5/DATOS 1/gp DATOS /gp DATOS 6)
TRUSTED_SHELL=ssh
declarar-a ESPEJO _ DATOS _ DIRECTORIO =(/DATOS 2/gp DATOS/gp datosm 1/DATOS 2/ gp DATOS/gp datos 2/gp DATOS 2/gp DATOS/gp datos 3/DATOS 2/gp DATOS/gp datos 4/DATOS 2/gp DATOS/gp datos 5/DATOS 2/gp DATOS/gp datos 6)
Archivo de lista de máquinas =/usr/local/greenplum-db/conf/seg _ hosts
Todo el proceso tarda entre 5 y 10 minutos en completarse. Durante el proceso de implementación, se recomienda verificar los registros del backend para ver si hay alguna anomalía. La experiencia en situaciones inusuales no es muy buena y puede desperdiciarse.
5. Resolver problemas de implementación del clúster
Hay muchos problemas detallados en la implementación del clúster, no mencionaré los básicos. Son básicamente configuración, permisos de directorio y otros. Permítanme mencionar algunos otros ejemplos:
1) Problemas de asignación de recursos. Si la configuración de recursos de /etc/security/limits.conf es insuficiente, se dará la siguiente advertencia durante el proceso de instalación:
2) Problema de red.
El clúster puede ejecutarse normalmente después de la implementación, pero se generarán errores al consultar datos. Por ejemplo, el SQL parece simple de la siguiente manera: seleccione recuento (*) del cliente, pero arroja el siguiente error:
La razón principal de este problema está relacionada con la configuración del firewall. De hecho, no sólo es necesario configurar los permisos de entrada, sino también los permisos de salida. ?
Para los nodos de datos, puede abrir permisos un poco más grandes, por ejemplo:
Configuración de entrada:
-A entrada -p all -s xxxxx? -j aceptar
Salir de configuración:
-A salida -p todo -s xxxxx -j aceptar
3) Problema de configuración de red. Lo extraño de este problema es que el informe de error es el mismo que el anterior, excepto que después de excluir la configuración del firewall, se puede seleccionar el recuento (*) del cliente, pero el tiempo de espera para la ejecución es relativamente alto; largo. Por ejemplo, la línea de pedido de la tabla es relativamente grande y el volumen de datos supera los 100 millones. Cuando hay 65,438 00 nodos físicos, el tiempo de respuesta de la consulta es 65,438 00 segundos, pero para 4 nodos físicos, el tiempo de respuesta de la consulta es 90 segundos, lo que hace que la eliminación general no parezca razonable.
Para solucionar problemas de red, también probamos herramientas como gpcheckperf. Las configuraciones básicas de 4 y 10 nodos son las mismas.
gpcheckperf-f/usr/local/greenplum-db/conf/seg _ hosts-r N-d/tmp
$ cat /etc/hosts
127.0 .0.1 localhost localhost localhost localhost4 localhost4 .localdomain4
::1? localhost localhost.localdomain localhost6 localhost6 .localdomain6
#127.0.0.1?test-dbs-gp-128-230
xxxxx.128.238 test-dbs-gp-svr-128-238
xxxxx.128.239 test- dbs-gp-svr-128-239
Hay un problema con la configuración de 127.0.0.1 en la sección maestra y de respaldo del segmento mixto. Todo estará bien después de la corrección. Esta cuestión clave también fue descubierta por Guo Yunkai.
5. Pruebas de recuperación de fallas del clúster
Las pruebas de fallas del clúster son una parte clave de este diseño de arquitectura, por lo que esta área también está ansiosa por intentarlo.
En general, incluimos dos escenarios: recuperación del clúster después de la reparación del tiempo de inactividad del servidor y modo de recuperación cuando el servidor no está disponible.
El primer escenario es relativamente simple, que consiste en permitir que el nodo de segmento se reincorpore al clúster e intercambie los roles de activo y espejo a nivel del clúster. Sin embargo, el segundo escenario lleva más tiempo, principalmente porque el nodo de datos. necesita ser reconstruido y el costo es alto. Básicamente es recuperación de datos a nivel de PG. Para simular completamente toda la prueba y recuperación, adoptamos métodos de recuperación similares, como reiniciar el servidor para reparar el tiempo de inactividad y limpiar el directorio de datos cuando el servidor no está disponible, similar a una máquina recién configurada.
1) Recuperación del clúster después del tiempo de inactividad y reparación del servidor
seleccione * de gp_segmento_configuración donde estado. = ' u
gprecoverseg? -o/recov
gprecoverseg? -r
seleccione * de gp _ segment _ configuración, donde status='u '
2) Recuperación del clúster cuando el servidor no está disponible
Reconstrucción de datos durante Durante el proceso del nodo, en general, el ancho de banda de la red se utiliza por completo.
seleccione * de gp_segmento_configuración, donde status='u'
seleccione * de gp_segmento_configuración donde estado='u' y rol! =preferred_role;
gprecoverseg? -r
seleccione * de gp _ segmento _ configuración donde estado = 'u' y rol. =preferred_role;
Después de la prueba, se necesitan aproximadamente 3 minutos para reiniciar el nodo y reparar los datos.
6. Resolver problemas de optimización del clúster
1) Optimización e iteración de la arquitectura de implementación
Los problemas de optimización son una parte particularmente preocupante y controvertida de esta prueba. ?
En primer lugar, después de la selección preliminar, la implementación del sistema de almacén múltiple fue relativamente fluida y se adoptó el primer plan.
Debido a que la parte del clúster del centro de datos tiene relativamente pocos nodos, se eligió la segunda opción.
Durante el proceso de prueba real, debido a problemas de configuración, los resultados de TPCH no cumplieron con las expectativas.
Así que hay algunas dudas y dudas en esta etapa. Una es volver a la primera solución, pero la cantidad de nodos será mucho menor, o la tercera es implementar máquinas virtuales en modo La solución más segura es la implementación de un solo nodo. Por supuesto, esta es la opción más descabellada.
Esta etapa es realmente difícil, pero después de las reparaciones de configuración anteriores, el clúster parece iluminarse repentinamente y el rendimiento es bueno. La prueba TPCH de un volumen de datos de 100G y 1T se completó rápidamente.
En transformaciones posteriores, también probamos la tercera solución, un modelo basado en máquinas virtuales. A través de las pruebas, descubrimos que estaba lejos de lo que esperábamos. Bajo el mismo nodo de datos, las máquinas primarias y secundarias son máquinas físicas y máquinas virtuales. El rendimiento es muy diferente, lo cual es inesperado. Por ejemplo, para el mismo SQL, el plan de ejecución 3 tarda 2 segundos, mientras que el plan de ejecución 2 tarda 80 segundos. Comparamos varios indicadores de esta diferencia. Finalmente, personalmente entiendo que la diferencia radica en la parte de la tarjeta de red.
Por lo tanto, después de la comparación, se seleccionó el modelo de implementación híbrida de la opción 2.
2) Análisis 2) Optimización del rendimiento de SQL
Además, el TPCH de todo el proceso también proporciona una referencia para el rendimiento del clúster. Por ejemplo, en el modo de implementación híbrida de la opción 2, una declaración SQL tarda 18 segundos, pero en comparación con el mismo tipo de clúster, puede que solo tarde unos 2 segundos. Esto es obviamente problemático. ?
Después de eliminar las diferencias entre configuración del sistema y configuración del hardware, la solución clásica es comprobar el plan de ejecución.
Plan de ejecución SQL con bajo rendimiento:
#Explicación y análisis del recuento de selección de clientes (*);
¿Plan de consulta?
Total (coste=0.00..431.00 filas=1 ancho=8) (tiempo real=24792.916..24792.916 filas=1 ciclo=1)
? - gt;reunir movimiento 36:1(corte 1;número de segmentos:36)(costo=0,00)..431,00 líneas=1 ancho=1)(tiempo real=3,255..16489.394 líneas=15000000 ciclos=1)
? - gt; escaneo secuencial del cliente (coste=0.00..431.00 filas=1 ancho=1) (tiempo real=0.780..1267.878 filas=4172607 ciclos=1)
Tiempo planificado: 4.466 milisegundos
? (slice0) Memoria del ejecutor: 680K bytes.
? (segmento1) Memoria del ejecutor: promedio de 218 KB x 36 subprocesos de trabajo, máximo 218 KB (seg0).
Memoria utilizada: 2457600kB
Optimizador: Optimizador pivotal (GPORCA)
Tiempo de ejecución: 24832,611 milisegundos
(9 líneas)
Tiempo: 24892.500 milisegundos
Mejor plan de ejecución de SQL:
#Análisis de explicación recuento de selección de clientes (*);
Plan de consulta
Total (coste=0.00..842.08 filas=1 ancho=8) (tiempo real=1519.311..1519.311 filas=1 bucle=1)
? - gt;movimiento de recolección 36:1 (corte 1; número de segmentos: 36) (coste=0.00)..842.08 filas=1 ancho=8) (tiempo real=634.787..1519.214 filas=36 bucles=1)
? - gt total(coste=0.00..842.08 filas=1 ancho=8)(tiempo real=1473.296)..1473.296 filas=1 bucle=1)
? - gt; escaneo secuencial del cliente (coste=0.00..834.33 filas=4166667 ancho=1) (tiempo real=0.758..438.319 filas=4172607 bucles=1)
Tiempo planificado: 5.033 milisegundos
? (slice0) Memoria del ejecutor: 176K bytes.
? (segmento1) Memoria del ejecutor: promedio de 234 KB x 36 subprocesos de trabajo, máximo 234 KB (seg0).
Memoria utilizada: 2457600kB
Optimizador: Optimizador pivotal (GPORCA)
Tiempo de ejecución: 1543.611 milisegundos
(10 líneas)
Tiempo: 1549,324 milisegundos
Obviamente, la implementación está equivocada y los factores engañosos se basan en información estadística. La reparación de este problema es muy simple:
Analice al cliente;
Pero la razón es que primero se usó 100G para medir la presión, la estructura de la tabla original. se retuvo e importó directamente el volumen de datos 1T resultó en que el plan de ejecución no se actualizara.
3) Optimización de la configuración del clúster
Además, se han realizado algunas optimizaciones de la configuración del clúster, como ajustar la caché. ?
gpconfig -c state_mem -m 2457600 -v 2457600
gp config-c gp_vmem_protect_limit-m 32000-v 32000
7. Datos de optimización del clúster
Finalmente, sintamos el rendimiento del clúster:
1) 10 nodos físicos, (6 6)*10 2.
tpch_1t=# iming on
Se inicia el cronómetro.
tpch_1t=# select count(*) proviene del cliente;
? ¿Contar?
-
150000000
(1 línea)
Tiempo: 1235.801 milisegundos
tpch_1t = # seleccione el recuento (*) de la línea de pedido;
? Contar
-
5999989709
(1 línea)
Tiempo: 10661.756 milisegundos
2)6 físicos nodos, (6 6)*6
#Seleccione recuento (*) del cliente;
Conteo
-
? 150000000
(1 línea)
Tiempo: 1346,833 milisegundos
# seleccione recuento (*) del elemento de línea;
¿Conteo?
-
? 5999989709
(1 línea)
Tiempo: 18145.092 milisegundos
3) 4 nodos físicos, (6 6)*4
# Seleccione recuento (*) de clientes;
Conteo
-
? 150000000
(1 línea)
Tiempo: 1531,621 milisegundos
# seleccione recuento (*) del elemento de línea;
¿Conteo?
-
? 5999989709
(1 fila)
Tiempo: 2572,501 milisegundos
4) TPCH tiene 19 modelos de consulta. Parte de la lógica SQL es demasiado complicada y se ignorará durante el proceso. Por el momento, también fue compilado por la lista de Guo Yunkai.
Rendimiento de referencia bajo el benchmark 1T: