De la topología de dominio y el desarrollo de policies al procesamiento de tráfico, alta disponibilidad y operación corporativa
Edición en profundidad - material de estudio y consulta profesional
Por João Ricardo Dutra••Material completo
De la configuración en al procesamiento distribuido en runtime
Figura de apertura: la plataforma combina herramientas de diseño, administración centralizada, runtime de políticas y componentes de persistencia y observabilidad.
Principio central
Axway combina topología administrativa, configuración versionable y runtime de políticas de alto rendimiento.
Edición en profundidad: material de estudio y consulta profesional.
Presentación del capítulo
El capítulo anterior estudió las políticas de como unidades ejecutables de seguridad, transformación, enrutamiento y observabilidad. Ahora la atención se centra en una implementación corporativa concreta: Axway . El producto materializa estos conceptos a través de dominios administrativos, grupos, instancias de , administradores de nodos, , herramientas de operación web y repositorios de datos utilizados por las políticas y el .
Entender la arquitectura requiere separar tres puntos de vista. La primera es la visión de diseño, en la que los equipos construyen circuitos de políticas, oyentes, servicios, certificados, y configuraciones de entorno. La segunda es la vista administrativa, donde el controla grupos, instancias, implementaciones y acceso operativo. La tercera es la vista en runtime, en la que un mensaje ingresa a través de un oyente, recibe contexto, pasa por filtros, puede consultar repositorios, llama a un y produce una respuesta, registros y métricas.
En entornos bancarios y de gran escala, la puerta de entrada rara vez está sola. Por lo general, opera detrás de balanceadores, en zonas externas e internas, con bancos de métricas, Cassandra, servicios de identidad, , directorios, observabilidad empresarial y distribuidos. Una falla en cualquiera de estas dependencias puede parecerle al consumidor como un tiempo de espera, 502, 401, reinicio o error de política. Por lo tanto, el operador necesita dominar tanto la herramienta como la red, , y los fundamentos de identidad estudiados en capítulos anteriores.
Este capítulo no pretende reemplazar la documentación de una versión específica del producto. Su objetivo es construir un modelo mental estable para arquitectura, operación, implementación, alta disponibilidad, rendimiento y retroubleshooting. Los nombres de los menús y los detalles de configuración pueden variar entre versiones, pero los conceptos de , grupos, instancias, administración y aplicación de políticas siguen siendo fundamentales.
Cómo estudiar este capítulo
Siga cada sección distinguiendo plan administrativo, runtime del tráfico y persistencia. Al solucionar problemas, escriba explícitamente qué componente se está observando: , Admin , , de , , Cassandra, base de datos de métricas o .
Objetivos de aprendizaje
Explique la relación entre , grupos, instancias, administradores de nodos y administrador de nodos.
Distinga , , y .
Describir cómo se modelan, validan, implementan y activan las configuraciones en runtime.
Explique los oyentes, los servicios, los circuitos de políticas, los filtros y el .
Relacione con sin confundir los dos productos.
Comprender el papel de , Cassandra, bancos de métricas y archivos de configuración.
Diseñar centros de datos de alta disponibilidad, escalabilidad horizontal, multizona y múltiples.
Aplique , , , claves , certificados y en el contexto del producto.
Interpretar registros, métricas, y trazas para diagnóstico.
Planifique el rendimiento, la capacidad, el despliegue de contenedores y el refuerzo operativo.
Estructura del capítulo
23.1 Posicionamiento del producto y componentes principales.
23.2 , grupos e instancias
23.3 y administradores de nodos
23.4 y modelo de configuración
23.5 Tiempo de ejecución: oyentes, servicios, circuitos y filtros
23.6 y flujo de ejecución
23.7 Administrador de sobre
23.8 , Cassandra y bancos de métricas
23.9 Despliegue, promoción y reversión
23.10 Alta disponibilidad y escalabilidad
23.11 Topologías de zona y múltiples centros de datos
23.12 , , y cifrado
23.13 Claves de autenticación, y
23.14 Enrutamiento, conexión a y resiliencia
23.15 Monitor de Observabilidad y Tráfico
23.16 Rendimiento y capacidad
23.17 Contenedores y OpenShift
23.18 Seguridad y refuerzo administrativo
23.19 y estudios de casos
Resumen, lista de verificación, laboratorios, glosario y referencias.
23.1 Posicionamiento del producto y componentes principales.
Axway es un runtime de mediación y seguridad para y tráfico de servicios. Recibe mensajes en oyentes configurados, interpreta protocolos admitidos, ejecuta cadenas de filtros y reenvía llamadas a destinos. El producto puede funcionar como inverso, punto de cumplimiento de seguridad, transformador de mensajes, enrutador y punto de observabilidad. Sus capacidades no se concentran en un solo ejecutable: está organizado por herramientas de diseño, administración, runtime y persistencia.
es la principal herramienta de desarrollo y configuración. es la interfaz web para administrar la topología, rastrear instancias, registros y tráfico. El Admin centraliza las operaciones de gestión de dominios, mientras que los Node Managers administran los componentes en los hosts y grupos correspondientes. Las instancias de ejecutan tráfico empresarial. agrega capacidades de publicación, virtualización, aplicaciones, consumidores, claves, portales y ciclo de vida además del runtime de la .
Esta separación le permite desarrollar políticas sin acoplar el tráfico a la consola administrativa. También requiere disciplina: los puertos administrativos deben estar segregados, el acceso debe estar protegido por , las configuraciones deben estar versionadas y las dependencias externas deben monitorearse. En producción, el runtime debe continuar procesando el tráfico incluso cuando las herramientas de diseño están apagadas; sin embargo, los cambios administrativos y las operaciones dependen del estado del de gestión.
Tabla 1 - Componentes con diferentes funciones dentro de la plataforma.
Componente
Responsabilidad principal
Pregunta operativa
Policy Studio
Desarrollar y configurar políticas, oyentes, certificados y entorno.
¿Qué configuración se creó y validó?
Admin Node Manager
Administración central de dominios.
¿Está disponible el plan administrativo?
Node Manager
Administre instancias y componentes en el host o grupo.
¿El nodo recibe y aplica operaciones?
Instancia de API Gateway
Ejecutar circuitos de tráfico y políticas.
¿La solicitud alcanzó el runtime?
API Gateway Manager
Supervise la topología, los registros, las métricas y el tráfico.
¿Qué evidencia produjo el runtime?
API Manager
Gestione API, consumidores y publicaciones.
¿Cómo se virtualizó y expuso la API?
23.2 , grupos e instancias
Un es el límite administrativo que reúne a grupos e instancias bajo una estructura de gestión común. El tiene un administrador de nodo de administración y puede contener varios grupos. Un representa una unidad lógica de implementación y administración, a menudo alineada con una función, zona, entorno o conjunto de instancias. Dentro de cada , las instancias de realizan configuraciones y procesan el tráfico.
La organización en grupos evita tratar cada como una configuración aislada. Cuando se implementa una configuración en un , las instancias de ese deben funcionar de forma coherente. Esto es esencial en los clústeres detrás de un equilibrador: cualquier nodo elegible debe reconocer los mismos oyentes, certificados, políticas, rutas y referencias de entorno, salvo diferencias parametrizadas explícitamente.
El no debe confundirse con el o el empresarial. Esta es una unidad del producto. Tampoco se debe dar por sentado que todos los grupos de un reciben la misma configuración. Es posible organizar grupos externos, internos, administrativos o especializados, con diferentes responsabilidades y exposiciones. La elección influye en el radio de explosión, la gobernanza y el proceso de promoción.
Figura 1: el organiza la administración central, los grupos, los administradores de nodos y las instancias de runtime.
modelo mental
El es una unidad lógica de implementación; la es el proceso de ejecución; gestiona los componentes; Admin coordina el . Confundir estos niveles conduce a implementaciones en objetivos equivocados y diagnósticos inexactos.
23.3 y administradores de nodos
El administrador del nodo de administración, a menudo abreviado como , es el servidor administrativo central del . Herramientas como y se conectan al plano administrativo a través de él. El coordina las operaciones de topología, implementación y gestión y, por lo tanto, debe protegerse como un componente crítico. Su falta de disponibilidad puede impedir cambios y ciertas operaciones administrativas, incluso si las instancias de continúan atendiendo tráfico con la configuración ya activa.
Los administradores de nodos realizan funciones de administración en hosts o grupos y se comunican con el administrador de nodos. La separación permite a mantener una visión central mientras los administradores de nodos realizan las operaciones locales. En topologías grandes, el estado de esta comunicación es tan importante como el estado de las instancias de . Los problemas con certificados, puertos, , firewall o versiones pueden impedir la administración sin afectar inmediatamente el tráfico empresarial.
La alta disponibilidad administrativa requiere una planificación específica. No basta con colocar el detector de detrás de un equilibrador de carga. El canal de gestión utiliza sus propios puertos y flujos y necesita una estrategia de HA, respaldo, recuperación y segregación. El acceso a debe restringirse a redes administrativas, cuentas con least privilege y autenticación sólida. Los registros administrativos deben conservarse para la auditoría.
Tabla 2: La disponibilidad de gestión y la disponibilidad de tráfico son dimensiones diferentes.
Fallo observado
Tráfico comercial
administración
Hipótesis
ANM no disponible
Puedes continuar con la configuración activa.
La implementación y la topología pueden fallar.
Fallo en el plan administrativo.
Node Manager aislados
La instancia puede permanecer activa.
Las operaciones locales no son suficientes.
Red, certificado o proceso local.
Instancia de API Gateway detenida
El nodo no atiende tráfico.
Puede aparecer sin conexión.
Proceso, JVM, recursos o configuración.
Puerto administrativo bloqueado
Las API pueden responder.
El estudio/administrador de políticas falla.
Firewall o ruta de gestión.
23.4 y el modelo de configuración
ofrece una vista estructurada del proyecto de . Configura circuitos de políticas, filtros, oyentes, servicios, certificados, almacenes, alertas, , recursos del entorno y referencias a sistemas externos. La herramienta no debe tratarse simplemente como un editor visual: lo que produce es una infraestructura ejecutable, con dependencias, orden de filtros, variables y efectos secundarios que necesitan revisión y prueba.
Una política bien diseñada tiene insumos, resultados y responsabilidades claras. Los filtros de autenticación deben establecer atributos predecibles; los filtros de autorización deben consumir identidad confiable; los filtros de enrutamiento deben tener una definida y un tiempo de espera; Los filtros de error deben producir respuestas consistentes. Los subcircuitos reutilizables reducen la duplicación, pero pueden aumentar el radio de los cambios. Por lo tanto, la reutilización requiere control de versiones y un contrato.
Los datos de configuración y entorno deben separarse siempre que sea posible. Las de , los alias de certificados, las credenciales, los nombres de host, los tiempos de espera y los parámetros por entorno no deberían requerir la edición manual de la lógica central. Esta separación facilita la promoción del mismo artefacto entre desarrollo, aprobación y producción, lo que reduce la deriva y el riesgo humano.
Ejemplo conceptual:
# Estructura conceptual de una política Inicio -> ID de correlación -> Validación de canales y métodos -> Autenticación -> Autorización -> Límite de tasa/cuota -> Transformación controlada -> Enrutamiento al -> Normalización de respuesta -> Auditoría y métricas ->
23.5 Tiempo de ejecución: oyentes, servicios, circuitos y filtros
En runtime, el oyente es el punto de entrada asociado con la dirección, el puerto, el protocolo y los parámetros . Cuando llega una conexión, la negocia el transporte y la seguridad, identifica el servicio aplicable y crea el . El servicio seleccionado dirige la ejecución a un . El circuito se compone de filtros conectados según el éxito, el fracaso y las rutas de derivación explícitas.
Los filtros son unidades de procesamiento: validar certificado, extraer encabezado, consultar , llamar al servicio, verificar , transformar / , registrar registro o definir un mensaje. Cada filtro lee y escribe atributos del . El comportamiento final depende del orden y los caminos. Un filtro aparentemente simple puede consumir cuerpo, bloquear subprocesos, acceder a la red o producir una respuesta, cambiando el rendimiento y la semántica.
Los circuitos pueden llamar a subcircuitos y compartir lógica. Esta modularidad ayuda a estandarizar la autenticación, la auditoría y el error. Sin embargo, las dependencias implícitas de los atributos generados por otro circuito hacen que la configuración sea frágil. Un subcircuito debe documentar qué atributos requiere, cuáles produce y cómo señala fallas. Sin este contrato, los pequeños cambios generan regresiones difíciles de localizar.
Figura 2: El runtime convierte una conexión entrante en filtrado, enrutamiento y ejecución de respuesta observable.
23.6 y flujo de ejecución
El es la memoria de trabajo de la transacción. Contiene propiedades de solicitud, conexión, autenticación, certificados, , cuerpo, destino, respuesta y atributos intermedios creados por filtros. Muchas decisiones en se expresan como selectores o referencias a atributos de contexto. Esto ofrece flexibilidad, pero requiere estandarización de nombres y tipos.
Un atributo sólo puede existir en una ruta determinada. Si la autenticación falla antes de crear el asunto, un filtro de auditoría no puede asumir que el atributo está presente. Si una llamada es atendida por caché, es posible que los atributos generados cuando se enruta al no existan. Las políticas sólidas manejan explícitamente la ausencia, los valores vacíos y los tipos inesperados.
El contexto también es un límite de seguridad. Los recibidos del consumidor no deben promocionarse directamente a la identidad confiable. La debe eliminar o sobrescribir los atributos que se propagarán al . Los datos confidenciales, como , contraseñas y claves, no deben incluirse en los rastreos de forma indiscriminada. El operador necesita equilibrar el diagnóstico y la protección de la información.
Tabla 3: El contexto es poderoso, pero necesita higiene de contrato y seguridad.
Tipo de atributo
Ejemplo
Precaución
Transporte
IP, puerto, TLS, certificado.
NAT y los proxies cambian el origen observado.
HTTP
Método, URI, headers, cuerpo.
El cuerpo puede transmitirse y tener límite de memoria.
Identidad
asunto, client_id, scopes.
Sólo después de una validación fiable.
Enrutamiento
URL final, tiempo de espera, grupo.
No registre secretos presentes en la URL.
Observabilidad
ID de correlación, hora, estado.
Preservar la coherencia en todos los caminos.
23.7 Administrador de sobre
es una capa de administración de construida sobre el runtime de . Agrega conceptos como virtualizadas, aplicaciones de consumo, credenciales, planes, publicación, catálogo y portal. El sigue siendo el mecanismo que ejecuta políticas y atiende el tráfico. Esta relación explica por qué la instalación y configuración de depende de un y de las instancias de disponibles.
La virtualización de una convierte un contrato importado o definido en una interfaz publicada en la . El proceso asocia , , seguridad, cuotas, políticas y metadata del catálogo. Los cambios realizados en pueden generar o actualizar artefactos que la ejecutará. Por lo tanto, los equipos deben evitar editar manualmente los componentes administrados por sin comprender cómo se comportan las sincronizaciones futuras.
también utiliza su propia persistencia, a menudo respaldada por Cassandra, para datos de aplicaciones, organizaciones, y credenciales. El estado del runtime y el estado del plano de gestión pueden diferir. Una existente puede continuar respondiendo mientras las operaciones de registro o publicación fallan debido a la falta de disponibilidad de Cassandra. El diagnóstico debe separar el consumo de , la gestión de y el almacenamiento de datos del plan de gestión.
Tabla 4: El plano de gestión y el runtime cooperan, pero no son la misma capa.
Objeto
API Manager
Tiempo de ejecución de API Gateway
API virtualizada
Define publicación, frontend y políticas.
Realiza escucha, circuitos y enrutamiento.
Solicitud
Representa al consumidor y las credenciales.
Valida credencial durante la llamada.
Cuota/plan
Configurar regla de consumo.
Aplica contraataques y decisión.
Portal/catálogo
Facilita el descubrimiento y la incorporación.
No participa en todas las convocatorias.
23.8 , Cassandra y bancos de métricas
Key Property Store, o , es una tabla de datos consultados por políticas. Es adecuado para información que se lee con frecuencia y se cambia con menos frecuencia, como asignaciones, parámetros, listas y datos auxiliares. no debe utilizarse como reemplazo genérico de un bancario transaccional. Las consultas y los índices deben reflejar los patrones de acceso reales de las políticas.
Cassandra es utilizada por y también puede admitir datos de y otros componentes según la configuración. Debido a que está distribuido, el banco ofrece escalabilidad y tolerancia a fallos, pero requiere operaciones especializadas: la coherencia, la replicación, la reparación, la compresión, el espacio en disco, el montón, la latencia y el estado del clúster influyen directamente en el plan de gestión y las políticas dependientes.
Las métricas y los informes pueden utilizar bases de datos relacionales compatibles. Este repositorio tiene un perfil diferente al de Cassandra y . La falta de disponibilidad del banco de métricas puede degradar los informes y la visibilidad sin necesariamente impedir el tráfico. Sin embargo, las configuraciones de registro sincrónico o las dependencias mal diseñadas pueden convertir la observabilidad en un cuello de botella. El objetivo es que la recopilación de métricas esté controlada y que la plataforma tenga una retención y depuración planificada.
Figura 3: Diferentes tiendas tienen diferentes propósitos: ejecución de políticas, gestión y observabilidad.
regla de arquitectura
No coloque datos en o Cassandra que requieran transacciones sólidas, consultas arbitrarias o actualizaciones por solicitud sin evaluar el impacto. La tienda debe elegirse en función de los estándares de coherencia y acceso, no solo porque ya existe en la plataforma.
23.9 Despliegue, promoción y reversión
Implementar una configuración significa transferir artefactos validados al y activarlos en los grupos o instancias elegidos. En entornos maduros, esta operación debe automatizarse por canalización, vincularse al versionado y acompañarse de evidencia. Exportar e importar manualmente configuraciones sin trazabilidad aumenta la deriva y dificulta la reversión.
La promoción entre entornos debe separar la lógica y los datos específicos. El mismo proyecto puede hacer referencia a variables, alias y parametrizados por entorno. Antes de la implementación, las canalizaciones deben realizar validación estática, pruebas de políticas, verificación de certificados y compatibilidad con la versión en runtime. Después de la implementación, las pruebas de humo deben cubrir los oyentes, la autenticación, las rutas, los errores y la observabilidad.
Revertir no es simplemente reinstalar un archivo anterior. Si el cambio creó estructuras en , cambió certificados, cambió el esquema en Cassandra o actualizó dependencias externas, restaurar la configuración por sí sola puede ser insuficiente. El plan debe describir artefactos, datos, secuencia y criterios de devolución. En grupos con múltiples instancias, el tiempo de inactividad cero requiere coordinación para evitar que todas se recarguen o se detengan simultáneamente.
Figura 4: El ciclo de implementación debe controlarse desde el diseño hasta la activación en runtime.
23.10 Alta disponibilidad y escalabilidad
La alta disponibilidad del tráfico se logra ejecutando múltiples instancias detrás de un equilibrador o mecanismo equivalente. Cada debe poder ofrecer la misma con configuración y dependencias coherentes. Los controles de estado deben distinguir el proceso en vivo, el oyente activo y la preparación real para llamar a los . Una prueba superficial puede dejar un nodo en el sin acceso a , Cassandra, o un servicio crítico.
La escalabilidad horizontal funciona mejor cuando las políticas no tienen estado o utilizan almacenes distribuidos adecuados. El estado local, la caché no compartida y la afinidad inadecuada pueden producir un comportamiento incoherente. Cuando alguna función requiere rigidez, el motivo debe ser explícito y se debe probar el impacto en la conmutación por error. La preferencia debe ser por identidad, cuota y sesión independientes del nodo siempre que sea posible.
La alta disponibilidad administrativa es una dimensión separada. El de administración se puede configurar con una estrategia de alta disponibilidad y el canal administrativo utiliza un puerto diferente al del tráfico empresarial. La copia de seguridad de configuración, datos, certificados y archivos esenciales también forma parte de la disponibilidad. HA sin la capacidad de recuperar credenciales y configuración después de que el desastre esté incompleto.
Figura 5 - El equilibrio del tráfico y la disponibilidad administrativa requieren diseños propios.
23.11 Topologías de zona y múltiples centros de datos
Las organizaciones suelen separar las en zonas externas e internas. La zona exterior recibe tráfico de consumidores y aplica controles de borde; la zona interna realiza mediación adicional o accede a sistemas protegidos. La comunicación entre zonas debe ser autenticada, limitada y observable. Replicar todas las políticas en ambas capas aumenta la latencia y dificulta la propiedad; cada zona debe tener una responsabilidad clara.
En múltiples centros de datos, el diseño debe decidir qué componentes son locales y qué datos se replican. Las en runtime pueden operar cerca de los consumidores y los , mientras que la administración, Cassandra, las métricas y el catálogo requieren coherencia y una estrategia de recuperación. La latencia entre centros de datos no debe ignorarse en , introspección, llamadas de políticas o bases de datos distribuidas.
Es necesario realizar una conmutación por error entre sitios. , GSLB, certificados, rutas, firewall, replicación y capacidad de supervivencia del sitio son parte de la prueba. No basta con confirmar que el proceso se inicia en el segundo centro de datos; es necesario demostrar que los consumidores eligen la dirección correcta, que las credenciales siguen siendo válidas y que las cuotas, las y los datos de gestión son coherentes.
Tabla 5: La topología debe equilibrar el aislamiento, la latencia, la coherencia y la operatividad.
Topología
ventaja
Riesgo principal
Un solo sitio, múltiples nodos
Simplicidad y HA local.
Fallo del centro de datos.
Grupos externos + internos
Separación de zonas y responsabilidades.
Duplicación de políticas y latencia.
Multi-DC activo/pasivo
Recuperación más sencilla.
Capacidad inactiva y conmutación por error mal probada.
DC múltiple activo/activo
Distribución y menor RTO.
Coherencia, enrutamiento y operación complejos.
23.12 , , y cifrado
Los oyentes dependen de certificados de servidor, claves privadas, conjuntos criptográficos y almacenes de confianza. La puede finalizar desde el consumidor e iniciar una nueva conexión al . Estos dos fragmentos son independientes: el certificado, la versión, el , la verificación del nombre de host, el almacén de confianza y pueden ser diferentes. La debe indicar en qué parte falló el protocolo de enlace.
En entrante, el oyente solicita el certificado del cliente y valida la cadena y las propiedades. Luego, la política puede asignar el certificado a una identidad, pero debería preferir y reglas explícitas en lugar de simplemente confiar en el CN. En salida, la puede presentar un certificado al . Un alias incorrecto, una cadena incompleta, una clave no disponible o un permiso faltante en el provocan un error antes de .
En entornos con o aceleración criptográfica, las operaciones clave se delegan al dispositivo o proveedor. Esto aumenta la protección de claves, pero introduce dependencias de sesión, controlador, red y capacidad. El monitoreo debe incluir la latencia y la disponibilidad del módulo. Es necesario ensayar la rotación de certificados para evitar interrupciones debido a recargas, alias o almacenes de confianza desactualizados.
Tabla 6 - Cada canal tiene su propia identidad criptográfica y cadena de confianza.
Extracto
La API Gateway actúa como
Configuraciones críticas
Cliente -> API Gateway
Servidor TLS.
Certificado, oyente, confianza del cliente, suites.
API Gateway -> Servidor
Cliente TLS.
Truststore, SNI, nombre de host, certificado de cliente.
administración
Gestión de servidor/cliente.
Certificados administrativos y RBAC.
HSM
Consumidor clave protegido.
Proveedor, sesión, slot, PIN y capacidad.
23.13 Claves de autenticación, y
La ofrece filtros y configuraciones para varios mecanismos de autenticación. Las claves se pueden almacenar o consultar en y vincularse a aplicaciones administradas por . Los de pueden validarse localmente, consultarse mediante introspección o emitirse cuando la actúa como authorization server, según la arquitectura. Los certificados, LDAP, Kerberos y mecanismos personalizados también pueden participar en las políticas.
La elección debe preservar la separación entre autenticación y autorización. La validación de una clave o establece cliente y sujeto; no significa que se libere ninguna operación. El circuito necesita verificar , roles, contrato, producto, cuota, tenant y contexto. La identidad propagada al debe estar firmada, protegida por o aceptada únicamente desde redes confiables.
El de claves, la introspección y los metadata mejora el rendimiento, pero cambia el tiempo de revocación. La política debe documentar el , el comportamiento de falla y la coherencia. La autenticación de error de apertura suele ser inapropiada. Si el servicio de identidad no responde, permitir la llamada puede convertir la indisponibilidad en una elusión de seguridad.
Canal conceptual de autenticación y autorización
# Flujo de seguridad conceptual extraer credencial validar integridad y validez resolver cliente y sujeto verificar audience y consultar cuota o plan aplicar autorización contextual eliminar que no sean confiables propagar la identidad confiable al
23.14 Enrutamiento, y resiliencia
El enrutamiento saliente transforma una decisión lógica en una conexión real con un . La política define , método, , , tiempo de espera, agrupación y manejo de respuestas. , ruta , firewall, y certificado siguen siendo relevantes. Un error de filtro de enrutamiento puede deberse a una ruta faltante, un agotado, un tiempo de espera de conexión, un tiempo de espera de lectura, una discrepancia en el nombre de host o un reinicio del servidor.
Los grupos de conexiones reducen los costos del protocolo de enlace, pero requieren límites, mantenimiento, tiempo de inactividad y validación. Si el cierra las conexiones antes que la , la reutilización puede producir reinicios intermitentes. Si la abre demasiadas conexiones, puede agotar los puertos efímeros o . Las métricas de pool y deben estar correlacionadas con el rendimiento y la latencia.
El reintento solo debe aplicarse a operaciones idempotentes o aquellas protegidas por una clave de idempotencia. Repetir una transferencia financiera después de un tiempo de espera de lectura puede duplicar el efecto. El disyuntor, el respaldo y el equilibrio deben considerar la semántica empresarial. La resiliencia no es simplemente volver a intentarlo; es contener fallas sin multiplicar la carga ni corromper el estado.
Tabla 7 - El error que presenta el gateway debe desglosarse por capa.
Síntoma
capa probable
evidencia
Tiempo de espera de conexión
Red backend o oyente.
SYN, ruta, firewall, grupo.
Tiempo de espera de lectura
Backend lento o respuesta bloqueada.
Tiempo y rastreo aguas arriba.
Restablecer conexión
Conexión cerrada entre pares o intermediarios.
Capture registros de TCP y backend.
502 desde la API Gateway
No se pudo obtener una respuesta válida.
Monitor de tráfico, filtro de seguimiento y enrutamiento.
Error de salida TLS
Confianza, SNI, nombre de host o certificado.
Apretón de manos y cuerda presentada.
23.15 Observabilidad, registros y Monitor de Tráfico
proporciona información operativa sobre instancias, registros y tráfico. registra los detalles del mensaje según la configuración y puede ayudar a reconstruir la ruta de una transacción. revela mensajes de ejecución y diagnóstico. Las métricas agregadas le permiten observar el rendimiento, el estado, la latencia y el estado. Cada fuente tiene un costo y propósito diferente.
La supervisión detallada del tráfico puede consumir CPU, E/S, base de datos y almacenamiento. En grandes volúmenes, registrar la carga útil completa es costoso y arriesgado. La estrategia debe seleccionar eventos, enmascarar datos, limitar el tamaño y definir la retención. El rastreo de alto nivel debe ser temporal y aplicarse al menor posible. La observabilidad no puede comprometer la disponibilidad que pretende explicar.
La correlación de un extremo a otro debe utilizar un identificador creado o validado al principio de la política y propagado al . Los registros de la deben registrar la , la operación, el cliente, el asunto cuando está permitido, el , la , el , el estado, la latencia y el motivo del error. Para la investigación de seguridad, conserve los eventos administrativos, los cambios de configuración y las autenticaciones de consola.
Tabla 8 - Cada fuente responde a una pregunta operativa diferente.
Fuente
Granularidad
Uso
Registro de seguimiento
Detalles de ejecución y diagnóstico.
Investigar políticas, filtros y excepciones.
Traffic Monitor
Transacción y mensaje según configuración.
Reconstruir llamadas y respuestas.
Métricas
Agregados temporales.
Capacidad, SLA y tendencias.
Registros de auditoría/administración
Acciones de gestión.
Gobernanza e investigación.
Abrir registro/SIEM
Eventos exportados.
Correlación y retención corporativa.
23.16 Planificación del desempeño y la capacidad
El rendimiento depende de la CPU, la memoria, la recolección de basura, los subprocesos, los , el cifrado, el tamaño del mensaje, la complejidad de las políticas y la latencia de dependencia. Una política que solo valida un encabezado tiene un perfil diferente a una que realiza transformación , firma digital, llamada externa y registro detallado. La planificación de la capacidad debe utilizar una carga de trabajo representativa, no sólo solicitudes abstractas por segundo.
Los filtros de red síncronos aumentan la latencia y consumen recursos mientras se espera. Las consultas de y Cassandra necesitan índices y proximidad. Las grandes transformaciones pueden requerir almacenamiento en búfer. El cifrado asimétrico y el protocolo de enlace son más costosos que la reutilización de la conexión. El análisis de rendimiento necesita descomponer el tiempo dentro de la y el tiempo dedicado a servicios externos.
El ajuste sin evidencia puede empeorar el sistema. Aumentar demasiado el montón prolonga las pausas; aumentar los hilos puede aumentar la contención; La ampliación de los grupos puede ejercer presión sobre los y . El proceso correcto establece una línea de base, mide percentiles, identifica un cuello de botella, cambia una variable y repite la prueba. Las configuraciones de seguimiento y Monitor de tráfico deben incluirse en los escenarios, porque cambian el costo del runtime.
Tabla 9: La planificación de capacidad requiere métricas y dependencias de runtime.
Dimensión
Métrica
Interpretación
CPU
usar, hacer cola, robar.
Políticas computacionales y criptografía.
Memoria
montón, GC, RSS.
Buffering, fugas y volumen de objetos.
Conexiones
activo, grupo, errores.
TCP/TLS y capacidad de backend.
Latencia
p50, p95, p99.
Colas lentas y dependencias.
tiendas
latencia y error de KPS/Cassandra.
Impacto de la persistencia en la política.
23.17 Contenedores, Kubernetes y OpenShift
se puede implementar en arquitecturas en contenedores, incluidos Kubernetes y OpenShift, siguiendo las referencias de productos. La creación de contenedores no elimina los conceptos de , configuración, secretos, persistencia y HA. La diferencia es que las instancias se vuelven efímeras, escaladas por el orquestador y sujetas a sondeos, solicitudes, límites, volúmenes y mecanismos de distribución de configuración.
Las imágenes deben ser inmutables y las configuraciones deben promoverse de forma reproducible. Los certificados y credenciales deben ingresarse mediante secretos o integraciones de bóveda, no escritos en la imagen. La preparación debe confirmar que la está realmente lista para recibir tráfico; liveness no puede reiniciar el pod debido a la lentitud transitoria de un . El período de gracia de preparada y terminación ayuda a drenar las conexiones.
Cassandra y los bancos métricos requieren su propio diseño y no deben tratarse como detalles del . Escalar la sin respetar los límites de dependencia solo puede aumentar la presión. En OpenShift, las SCC, las rutas, los servicios, las políticas de red, el almacenamiento y la observabilidad deben estar alineados con las políticas corporativas y de referencia.
Atención en contenedores
El ajuste de escala automático de pod horizontal solo de CPU puede reaccionar tarde a la latencia o las conexiones del . Combine métricas comerciales, conexiones, colas y capacidad de los sistemas dependientes. Ampliar la no crea capacidad en el núcleo bancario.
23.18 Seguridad y refuerzo administrativo
El plano administrativo deberá estar aislado del tráfico público. Los puertos , los administradores de nodos y las consolas no deben estar expuestos a Internet. debe separar el desarrollo de políticas, la implementación, la operación, la auditoría y la administración de seguridad. Las cuentas compartidas comprometen la trazabilidad. Las credenciales y los secretos predeterminados de los archivos deben eliminarse o protegerse según la versión.
El refuerzo incluye parches, versiones compatibles, administrativo, rotación de certificados, protección de archivos, least privilege del sistema operativo, limitación del acceso a Cassandra y a los bancos, copia de seguridad cifrada e integración SIEM. Se deben inventariar las configuraciones personalizadas para que no desaparezcan ni se rompan durante las actualizaciones.
La actualización es un proyecto de compatibilidad. Es necesario evaluar políticas personalizadas, scripts, filtros, bibliotecas, controladores, , Cassandra, base de datos de métricas y sistema operativo. El entorno debe probarse con tráfico y reversión realistas. Mantener una versión antigua sin soporte aumenta los riesgos de seguridad y dificulta la integración con dependencias modernas.
Tabla 10: El hardening combina producto, sistema operativo, red y proceso.
controlar
Objetivo
evidencia
RBAC
Mínimo privilegio administrativo.
Perfiles, grupos y revisión periódica.
Segregación de red
Puertos de gestión seguros.
Cortafuegos, rutas y bastión.
Gestión de secretos
Evite la exposición en el proyecto y los registros.
Bóveda, alias y rotación.
Parche/actualización
Corrija vulnerabilidades y mantenga el soporte.
Inventario y calendario.
Auditoría
Seguimiento de cambios y accesos.
Registros inmutables y SIEM.
23.19 orientada a capas
Una investigación eficiente comienza por clasificar el problema. Si el nombre no se resuelve, la póliza aún no ha participado. Si no se establece, examine la ruta, el firewall y el oyente. Si falla, examine el certificado, el y la confianza. Si la solicitud ingresa a y no pasa un filtro, analice el y la ruta de la política. Si el filtro de enrutamiento se inicia y el no responde, continúe con la conexión saliente.
El punto de observación es imprescindible. Los registros de consumidor, equilibrador, externa, interna y describen diferentes conexiones. y cambian y puerto. La marca de tiempo debe estar sincronizada. Se debe conservar el ID de correlación. Sin estos elementos, los equipos pueden comparar transacciones dispares y concluir incorrectamente que la perdió un mensaje.
Evite habilitar el seguimiento máximo en todo el clúster durante el pico. Reproducir en un entorno controlado o limitar por y ventana. Recopile la configuración de políticas, la versión implementada, el , la , los registros, las métricas, la captura cuando esté autorizado y la evidencia del . Luego, formule hipótesis comprobables en lugar de cambiar varios tiempos de espera simultáneamente.
Tabla 11: El diagnóstico por capas reduce el ensayo y error.
paso
prueba
Interpretación
DNS
Resuelva el frontend y el backend en el host de la API Gateway.
Nombre, dividir DNS y caché.
tcp
Pruebe la conexión a los puertos requeridos.
Ruta, firewall y oyente.
TLS
Inspeccionar el apretón de manos y la cadena.
Confianza, SNI, nombre de host y mTLS.
Política
Encuentra el filtro y la ruta ejecutada.
Contexto, condición y excepción.
backend
Correlacionar la llamada entrante.
La API Gateway llamó o finalizó antes de tiempo.
persistencia
Consulta KPS, Cassandra y métricas.
Dependencia externa del flujo.
23.20 Estudios de caso
Estudio de caso 1: 502 intermitente después de un aumento de tráfico. muestra que la política llega al filtro de enrutamiento, pero algunas conexiones se restablecen. Las métricas revelan la reutilización de conexiones mantenidas durante más tiempo que el tiempo de inactividad del . La solución alinea la validación de mantenimiento y de ; aumentar el tiempo de espera de lectura no resolvería la causa.
Estudio de caso 2: no se implementa, pero las continúan respondiendo. El error está restringido al puerto administrativo entre la estación y el administrador del nodo de administración. El oyente empresarial está sano. La separación de planes evita una mayor indisponibilidad y dirige la investigación al firewall, certificado administrativo y servicio .
Estudio de caso 3: el registro de una nueva aplicación falla en mientras las existentes permanecen activas. Cassandra introduce latencia y nodos no disponibles. El runtime ya tiene datos cargados, pero el plano de administración no puede persistir en la operación. El incidente requiere un equipo de banca distribuida, no un cambio en la política frontal.
Estudio de caso 4: después de la rotación de certificados salientes, solo falla un nodo. El equilibrador distribuye llamadas entre dos instancias y la falla parece aleatoria. La comparación muestra el almacén de confianza o el alias no actualizado en la configuración efectiva de un miembro del . La solución es arreglar la promoción y validar la coherencia entre instancias.
Resumen del capítulo
Axway organiza el runtime y la administración entre dominios, grupos, instancias, administradores de nodos y un administrador de nodos central. modela la configuración; proporciona operación y observabilidad; Las instancias de ejecutan escuchas, circuitos de políticas y enrutamiento. agrega administración de y consumidores además de este runtime.
El funcionamiento de una llamada depende del , los filtros, las tiendas, la red, , la identidad y los servidores. , Cassandra y los bancos de métricas tienen propósitos diferentes y no deben tratarse como un repositorio único. La implementación, HA, múltiples DC y contenedores requieren una configuración reproducible y una separación clara entre el plano administrativo y el tráfico empresarial.
Operar la plataforma de forma segura requiere , segregación de puertos administrativos, gestión de certificados, observabilidad controlada, planificación de capacidad y actualización disciplinada. La retroubleshooting debe seguir las capas y los puntos de observación, preservando la identificación de correlación y la evidencia de cada componente.
Siguiente paso del curso
El siguiente capítulo profundiza en Azure Management ( ), permitiéndole comparar una plataforma gestionada en la nube con la arquitectura y el funcionamiento estudiados en Axway .
Lista de verificación operativa
El , los grupos, las instancias, los administradores de nodos y los están documentados e inventariados.
Los puertos administrativos están segregados y protegidos por y la red de gestión.
Las políticas tienen contratos de atributos de propiedad, control de versiones, pruebas y contexto de mensajes.
Los datos de configuración y entorno están separados y canalizados.
, Cassandra y base de datos de métricas cuentan con monitoreo, respaldo y capacidad.
Los controles de estado verifican la preparación real sin sobrecargar las dependencias.
Los entrantes, salientes y administrativos tienen almacenes de confianza controlados y rotativos.
Los pools, los tiempos de espera, los reintentos y los disyuntores respetan la semántica de las operaciones.
y el seguimiento tienen , enmascaramiento y retención definidos.
La capacidad se probó con percentiles representativos de carga de trabajo y latencia.
Los contenedores tienen la preparación, la vivacidad, el drenaje, los secretos y los límites adecuados.
Las actualizaciones incluyen políticas personalizadas, controladores, , tiendas y reversión.
Los runbooks de separan , , , políticas, y persistencia.
laboratorios y ejercicios
Dibujar un con dos grupos y dos instancias por , indicando , Administradores de Nodos y flujos administrativos.
Crear una política conceptual de autenticación, autorización, , enrutamiento y errores; documentar los atributos producidos y consumidos.
Simule la falla de y explique qué puede continuar funcionando en runtime.
Diferenciar una falla de Cassandra en de una falla de conexión saliente al .
Proponer una estrategia de implementación sin tiempo de inactividad para un con cuatro instancias.
Enumere evidencia para investigar un 502 intermitente en un solo nodo.
Diseñar topología de zona externa/interna con distintas responsabilidades.
Explique cómo validar la rotación de certificados entrantes y salientes.
Proponer un conjunto mínimo de métricas para la planificación de la capacidad de la .
Describa cómo migrar la plataforma a OpenShift sin incorporar secretos en la imagen.
Glosario
Tabla 12 - Vocabulario esencial del capítulo.
Término
Definición
Node Manager de administración (ANM)
Componente de administración central para un dominio API Gateway.
API Gateway Manager
Consola web para administración, monitoreo, logs y topología.
API Manager
Capa de gestión de API, aplicaciones, consumidores y publicaciones en la API Gateway.
Dominio
Frontera administrativa que agrupa a grupos e instancias.
Filtrar
Unidad de procesamiento utilizada en un circuito de pólizas.
grupo
Unidad lógica, por ejemplo, implementación y administración.
instancia
Proceso API Gateway que ejecuta el tráfico.
KPS
Key Property Store consultado por políticas para obtener datos auxiliares.
Contexto del mensaje
Conjunto de atributos y mensajes mantenidos durante la transacción.
Node Manager
Componente de gestión de instancias y servicios en un nodo o grupo.
Circuito de políticas
Flujo de filtros conectados por rutas de éxito y fracaso.
Policy Studio
Herramienta de desarrollo y configuración de API Gateway.
Traffic Monitor
Vista de tráfico y transacciones disponible en API Gateway Manager.
API virtualizada
API publicada y mediada por API Manager/API Gateway.
Referencias técnicas
Documentación Axway. Grupos y dominios de .
Documentación Axway. Configure la alta disponibilidad de Admin .
Documentación Axway. Administrar y gestionar operaciones.
Documentación Axway. Desarrollar políticas y configuración de .
Documentación Axway. Descripción general y configuración de Key Property Store.
Documentación Axway. Monitoreo, Monitor de Tráfico, registro y métricas.
Documentación Axway. Configure y virtualice las .
Documentación Axway. Administrador Apache Cassandra para Management.
Documentación Axway. Configuración multicentro de datos de Management.
Documentación Axway. Arquitecturas de referencia de contenedores para Kubernetes y OpenShift.
Documentación Axway. Ajuste del rendimiento y requisitos del sistema.
Nota de lanzamiento
El producto evoluciona a través de lanzamientos y parches. Antes de aplicar comandos, puertos, parámetros o procedimientos validar la documentación oficial correspondiente a la versión instalada, sistema operativo, banco, modo de implementación y componentes licenciados en el entorno.
