De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador

El componente ETL del almacén de datos a menudo queda eclipsado por el propio almacén y recibe menos atención que la base de datos principal o el componente front-end, BI y los informes. Al mismo tiempo, desde el punto de vista de la mecánica de llenar el almacén con datos, ETL juega un papel clave y requiere no menos atención por parte de los administradores que otros componentes. Mi nombre es Alexander, ahora administro ETL en Rostelecom y en este artículo intentaré compartir un poco con lo que tiene que lidiar el administrador de uno de los sistemas ETL más famosos en un gran almacén de datos de Rostelecom.

Si, queridos lectores, ya están familiarizados en general con nuestro proyecto de almacén de datos y con el producto Informatica PowerCenter, pueden pasar inmediatamente a la siguiente sección.

Hace varios años, la idea de un único almacén de datos corporativo maduró y comenzó a implementarse en Rostelecom. Ya se habían creado varios repositorios que resolvían problemas individuales, pero la cantidad de escenarios creció, los costos de soporte también aumentaron y quedó claro que el futuro estaba en la centralización. Arquitectónicamente, este es el almacenamiento en sí, que consta de varias capas implementadas en Hadoop y GreenPlum, bases de datos auxiliares, mecanismos ETL y BI.

Al mismo tiempo, debido a la gran cantidad de fuentes de datos heterogéneas y distribuidas geográficamente, se creó un mecanismo especial de carga de datos, cuyo funcionamiento está controlado por Informatica. Como resultado, los paquetes de datos terminan en el área de la interfaz de Hadoop, después de lo cual comienzan los procesos de carga de datos a través de las capas de almacenamiento, Hadoop y GreenPlum, y son administrados por el llamado mecanismo de control ETL implementado en Informatica. Así, el sistema Informatica es uno de los elementos clave que asegura el funcionamiento del almacén.

Nuestro almacenamiento se describirá con más detalle en una de las siguientes publicaciones.

Informatica PowerCenter/Big Data Management se considera actualmente el software líder en el campo de las herramientas de integración de datos. Este es un producto de la empresa estadounidense Informatica, que es uno de los actores más fuertes en ETL (Extract Transform Load), gestión de calidad de datos, MDM (Master Data Management), ILM (Information Lifecycle Management) y más.

El PowerCenter que utilizamos es un servidor de aplicaciones Tomcat integrado en el que se ejecutan las propias aplicaciones de Informatica implementando sus servicios:

DominioDe hecho, esta es la base de todo lo demás; los servicios, los usuarios y los componentes GRID operan dentro del dominio.

Consola de administrador, una herramienta de gestión y seguimiento basada en web, además del cliente Informatica Developer, principal herramienta de interacción con el producto.

MRS, Servicio de repositorio de modelos, un repositorio de metadatos, es una capa entre la base de datos en la que se almacenan físicamente los metadatos y el cliente de Informatica Developer en el que se lleva a cabo el desarrollo. Los repositorios almacenan descripciones de datos y otra información, incluso para otros servicios de Infromatica, por ejemplo, cronogramas para ejecutar tareas (Programaciones) o monitorear datos, así como parámetros de la aplicación, en particular, lo que permite el uso de la misma aplicación para trabajar con diversas fuentes y receptores de datos.

DIS, Servicio de Integración de Datos, este es un servicio en el que tienen lugar los principales procesos funcionales, se ejecutan aplicaciones en él y los lanzamientos reales de Workflows (descripciones de la secuencia de mapeos y sus interacciones) y Mappings (transformaciones, bloques en los que ocurren las transformaciones mismas, procesamiento de datos). ) tener lugar.

Configuración de RED – esencialmente, una opción para construir un complejo utilizando varios servidores, cuando la carga lanzada por DIS se distribuye entre los nodos (es decir, servidores que forman parte del dominio). En el caso de esta opción, además de distribuir la carga en DIS a través de una capa de abstracción GRID adicional que une varios nodos, en los que se ejecuta DIS en lugar de trabajar en un único nodo específico, también se pueden crear instancias MRS de respaldo adicionales. Incluso puedes implementar alta disponibilidad, donde se pueden realizar llamadas externas a través de nodos de respaldo si el principal falla. Hemos abandonado esta opción de construcción por ahora.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Informatica PowerCenter, esquema

En las primeras etapas del trabajo como parte de la cadena de suministro de datos, surgieron regularmente problemas, algunos de ellos debido al funcionamiento inestable de Informatica en ese momento. Voy a compartir algunos de los momentos memorables de esta saga: dominar Informatica 10.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Antiguo logotipo de Informatica

Nuestra área de responsabilidad también incluye otros entornos de Informatica, tienen sus propias características específicas debido a una carga diferente, pero por ahora recordaré exactamente cómo se desarrolló Informatica como un componente ETL del propio almacén de datos.

Como paso

En 2016, cuando asumimos la responsabilidad del trabajo de Informatica, ya había alcanzado la versión 10.0, y para los colegas optimistas que decidieron utilizar un producto con una versión menor .0 en una solución seria, todo parecía obvio: debemos usar la nueva versión! Desde el punto de vista de los recursos de hardware, todo estaba bien en ese momento.

Desde la primavera de 2016, un contratista se encarga del trabajo de Informatica y, según los pocos usuarios del sistema, "funcionaba un par de veces por semana". Aquí es necesario aclarar que el repositorio estaba de facto en la etapa PoC, no había administradores en el equipo y el sistema fallaba constantemente por diversas razones, después de lo cual el ingeniero del contratista lo recuperó.

En el otoño, tres administradores se unieron al equipo, dividiéndose sus áreas de responsabilidad, y comenzó el trabajo normal para organizar el funcionamiento de los sistemas del proyecto, incluida Informatica. Por otra parte, hay que decir que este producto no está muy extendido y cuenta con una gran comunidad en la que podrás encontrar respuesta a cualquier duda y solucionar cualquier problema. Por lo tanto, fue muy importante el soporte técnico completo del socio ruso Informatica, con la ayuda del cual se corrigieron todos nuestros errores y errores de la entonces joven Informatica 10.

Lo primero que tuvimos que hacer por los desarrolladores de nuestro equipo y el contratista fue estabilizar el trabajo de Informatica, para garantizar la funcionalidad de la consola de administración web (Administrador de Informatica).

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Así nos encontramos a menudo con los desarrolladores de Informatica

Dejando de lado el proceso de descubrir las razones, la razón principal de las fallas fue el patrón de interacción del software de Informatica con la base de datos del repositorio, que estaba ubicada en un servidor relativamente remoto, desde el punto de vista del panorama de la red. Esto provocó retrasos e interrumpió los mecanismos que monitorean el estado del dominio de Informatica. Después de algunos ajustes de la base de datos, cambiar los parámetros de Informatica, lo que la hizo más tolerante a los retrasos de la base de datos y, finalmente, actualizar la versión de Informatica a 10.1 y transferir la base de datos del servidor anterior a un servidor ubicado más cerca de Informatica, el problema perdió su significado. relevancia, y desde entonces ha habido caídas de este tipo que no observamos.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Uno de los intentos de hacer funcionar Informatica Monitor

La situación con la consola de administración también fue crítica. Dado que el desarrollo activo estaba en marcha directamente en un entorno relativamente productivo, los colegas necesitaban constantemente analizar el trabajo de los mapeos y el flujo de trabajo "sobre la marcha". En la nueva Informatica, el Servicio de integración de datos no tiene una herramienta separada para dicho monitoreo, pero ha aparecido una sección de monitoreo en la consola web de administración (Informatica Administrator Monitor), en la que puede monitorear el funcionamiento de las aplicaciones, el flujo de trabajo y las asignaciones. lanzamientos, registros. Periódicamente, la consola dejaba de estar disponible por completo, la información sobre los procesos actuales en DIS dejaba de actualizarse o se producían errores al cargar páginas.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Selección de parámetros java para estabilizar la operación.

El problema se corrigió de muchas maneras, se llevaron a cabo experimentos para cambiar los parámetros, se recopilaron registros y jstack, se enviaron al soporte y al mismo tiempo se realizó una búsqueda activa en Google y simplemente observación.

En primer lugar, se creó un MRS separado para el monitoreo; como se vio más tarde, este es uno de los principales consumidores de recursos en nuestro entorno, ya que los mapeos se lanzan de manera muy intensiva. Se han cambiado los parámetros relacionados con el montón de Java y muchos otros.
Como resultado, con la próxima actualización de Informatica 10.1.1, el funcionamiento de la consola y el monitor se estabilizó, los desarrolladores comenzaron a trabajar de manera más eficiente y los procesos regulares se volvieron cada vez más regulares.

La experiencia de interacción entre desarrollo y administración puede resultar interesante. La cuestión de una comprensión general de cómo funcionan las cosas, qué se puede hacer y qué no se puede hacer, siempre es importante cuando se utilizan sistemas complejos. Por lo tanto, podemos recomendar con seguridad que primero capacite al equipo administrativo sobre cómo administrar el software y al equipo de desarrollo sobre cómo escribir código y dibujar procesos en el sistema, y ​​solo entonces envíe al primero y al segundo a trabajar en el resultado. Esto es realmente importante cuando el tiempo no es un recurso infinito. Muchos problemas pueden resolverse incluso mediante una búsqueda aleatoria de opciones, pero a veces algunos requieren conocimiento a priori; nuestro caso confirma la importancia de comprender este axioma.

Por ejemplo, cuando intentamos habilitar el control de versiones en MRS (al final resultó que se necesitaba una versión diferente de SVN), después de un tiempo nos alarmamos al descubrir que el tiempo de reinicio del sistema había aumentado a varias decenas de minutos. Habiendo encontrado el motivo del retraso en el inicio y deshabilitando el control de versiones, lo hicimos bien nuevamente.

Los obstáculos notables asociados con Informatica incluyen la batalla épica con los crecientes subprocesos de Java. En algún momento ha llegado el momento de la replicación, es decir, de extender los procesos establecidos a una gran cantidad de sistemas fuente. Resultó que no todos los procesos en 10.1.1 funcionaban bien y, después de un tiempo, DIS dejó de funcionar. Se detectaron decenas de miles de hilos, cuyo número aumentó especialmente durante el proceso de implementación de la aplicación. A veces tenía que reiniciar varias veces al día para restaurar la funcionalidad.

Aquí tenemos que agradecer al soporte; los problemas se localizaron y solucionaron relativamente rápido usando EBF (Emergency Bug Fix); después de eso, todos tuvieron la sensación de que la herramienta realmente funciona.

¡Aún funciona!

Cuando empezamos a trabajar en modo de destino, Informatica tenía este aspecto. Versión de Informatica 10.1.1HF1 (HF1 es HotFix1, un ensamblaje del proveedor de un complejo de EBF) con EBF instalado adicionalmente, que corrige nuestros problemas de escalado y algunos otros, en un servidor de cada tres que formaban parte de GRID, 20 núcleos x86_64 y almacenamiento, en una enorme y lenta matriz de discos locales: esta es la configuración del servidor para un clúster de Hadoop. En otro servidor similar: Oracle DBMS, con el que funcionan tanto el dominio de Informatica como el mecanismo de control ETL. Todo esto es monitoreado por herramientas de monitoreo estándar utilizadas en el equipo (Zabbix + Grafana) en ambos lados: la propia Informatica con sus servicios y los procesos de carga que conlleva. Ahora tanto el rendimiento como la estabilidad, sin tener en cuenta factores externos, ahora dependen de los ajustes que limitan la carga.

Por separado, podemos decir sobre GRID. El entorno se construyó sobre tres nodos, con posibilidad de equilibrio de carga. Sin embargo, durante las pruebas, se descubrió que debido a problemas de interacción entre las instancias en ejecución de nuestras aplicaciones, esta configuración no funcionaba como se esperaba y decidieron abandonar temporalmente este esquema de construcción, eliminando dos de los tres nodos del dominio. Al mismo tiempo, el esquema en sí sigue siendo el mismo, y ahora es precisamente un servicio GRID, pero degenerado en un nodo.

En este momento, la dificultad sigue estando asociada con una caída en el rendimiento al limpiar regularmente el circuito del monitor; con procesos simultáneos en el CNN y la limpieza en ejecución, pueden ocurrir fallas en el funcionamiento del mecanismo de control ETL. Actualmente, esto se está resolviendo "como una muleta", limpiando manualmente el circuito del monitor, con la pérdida de todos sus datos anteriores. Esto no es demasiado crítico para la productividad durante el funcionamiento normal, pero por ahora se está buscando una solución normal.

De esta misma situación surge otro problema: a veces se producen múltiples lanzamientos de nuestro mecanismo de control.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Múltiples lanzamientos de aplicaciones provocan fallos en el mecanismo

Cuando se ejecuta según un cronograma, en momentos de gran carga en el sistema, a veces ocurren situaciones que provocan la avería del mecanismo. El problema todavía se está solucionando manualmente y se busca una solución permanente.

En general podemos resumir que cuando hay una carga pesada es muy importante brindar recursos adecuados a la misma, esto también aplica a los recursos de hardware para la propia Informatica, y lo mismo para su repositorio de bases de datos, así como brindar configuraciones óptimas. para ellos. Además, queda abierta la pregunta de qué esquema de ubicación de la base de datos es mejor: en un host separado o en el mismo donde se ejecuta el software de Informatica. Por un lado, será más económico en un servidor y, cuando se combinan, prácticamente se elimina el posible problema con la interacción de la red; por otro lado, la carga en el host desde la base de datos se complementa con la carga de Informatica.

Como ocurre con cualquier producto serio, Informatica también tiene momentos divertidos.
Una vez, mientras solucionaba algún tipo de accidente, noté que en los registros del MRS se indicaba extrañamente la hora de los hechos.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Dualismo temporal en registros MRS "por diseño"

Resultó que las marcas de tiempo están escritas en formato de 12 horas, sin especificar AM/PM, es decir, antes del mediodía o después. Incluso se abrió una solicitud sobre este asunto y se recibió una respuesta oficial: así es como se pretendía, las marcas se escriben en el registro de MRS exactamente en este formato. Es decir, a veces queda alguna intriga respecto al momento de ocurrencia de algún ERROR...

Esforzarse por lo mejor

Hoy en día, Informatica es una herramienta bastante estable, conveniente para administradores y usuarios, extremadamente poderosa en términos de sus capacidades y potencial actuales. Supera con creces nuestras necesidades funcionales y, de facto, ahora se utiliza en el proyecto de una manera que no es la más típica y típica. Las dificultades están en parte relacionadas con la forma en que funcionan los mecanismos: lo específico es que en un corto período de tiempo se lanza una gran cantidad de subprocesos que actualizan intensamente los parámetros y trabajan con la base de datos del repositorio, mientras que los recursos de hardware del servidor se utilizan casi por completo. por la CPU.

Ahora estamos cerca de pasar a Informatica 10.2.1 o 10.2.2, que han reelaborado algunos de los mecanismos internos y prometen soporte para eliminar algunos de los problemas de rendimiento y funcionalidad que tenemos actualmente. Y desde el punto de vista del hardware, esperamos servidores con una configuración óptima para nosotros, teniendo en cuenta la reserva para el futuro próximo debido al crecimiento y desarrollo del almacenamiento.

Por supuesto, habrá pruebas, comprobaciones de compatibilidad y posiblemente cambios arquitectónicos en la parte HA GRID. El desarrollo dentro de Informatica continuará, ya que a corto plazo no podemos suministrar nada para reemplazar el sistema.
Y aquellos que serán responsables de este sistema en el futuro seguramente podrán llevarlo a los indicadores de confiabilidad y rendimiento requeridos por los clientes.

El artículo fue preparado por el equipo de gestión de datos de Rostelecom.

De los accidentes cotidianos a la estabilidad: Informatica 10 a través de los ojos de un administrador
Logotipo actual de Informatica

Fuente: habr.com

Añadir un comentario