amazon ec2 - aws - Configuración del servidor Kafka-oyentes vs. advertised.listeners
aws kafka (3)
Como todavía no puedo comentar, publicaré esto como una "respuesta", agregando a la respuesta de M.Situations.
Dentro del mismo documento que él vincula, existe una propaganda sobre qué escucha utiliza un cliente KAFKA ( https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+External+traffic ):
Como se indicó anteriormente, los clientes nunca ven los nombres de los oyentes y realizarán solicitudes de metadatos exactamente como antes. La diferencia es que la lista de puntos finales que obtienen está restringida al nombre del oyente del punto extremo donde realizaron la solicitud.
Esto es importante ya que, dependiendo de la URL que use en su configuración bootstrap.servers, será la URL * que el cliente recuperará si se asigna en advertised.listeners (no sé cuál es el comportamiento si el oyente no existe ).
También tenga en cuenta esto:
La excepción son los consumidores basados en ZooKeeper. Estos consumidores recuperan la información de registro del agente directamente desde ZooKeeper y elegirán al primer oyente con PLAINTEXT como protocolo de seguridad (el único protocolo de seguridad que admiten).
Como ejemplo de configuración de intermediario (para todos los intermediarios en clúster):
advertised.listeners = EXTERNAL: //XXXXX.compute-1.amazonaws.com: 9990, INTERNAL: //ip-XXXXX.ec2.internal: 9993
inter.broker.listener.name = INTERNO
listener.security.protocol.map = EXTERNO: SSL, INTERNO: PLAINTEXT
Si el cliente utiliza XXXXX.compute-1.amazonaws.com:9990 para conectarse, la búsqueda de metadatos irá a ese agente. Sin embargo, la URL de retorno para usar con el Coordinador de Grupo o el Líder podría ser 123.compute-1.amazonaws.com:9990* (¡una máquina diferente!). Esto significa que la coincidencia se realiza en el nombre del oyente tal como lo anuncia KIP-103 independientemente de la URL real (nodo).
Dado que el mapa de protocolo para EXTERNAL es SSL, esto obligaría a utilizar un almacén de claves SSL para conectarse.
Si, por otro lado, está dentro de AWS, digamos, puede emitir ip-XXXXX.ec2.internal: 9993 y la conexión correspondiente sería texto simple según el mapa de protocolo.
Esto es especialmente necesario en IaaS donde, en mi caso, los intermediarios y los consumidores viven en AWS, mientras que mi productor vive en el sitio de un cliente, por lo que necesita diferentes escuchas y protocolos de seguridad.
EDITAR: también es mucho más fácil agregar Reglas de entrada ahora que tiene diferentes puertos para diferentes clientes (intermediarios, productores, consumidores).
Para que Kafka se ejecute, debe configurar algunas propiedades en el archivo config/server.properties . Hay dos configuraciones que no entiendo.
¿Alguien puede explicar la diferencia entre los oyentes y la propiedad advertised.listeners?
La documentación dice:
escuchas: La dirección en la que el servidor de socket escucha.
y
advertised.listeners: Nombre de host y puerto que el intermediario anunciará a productores y consumidores.
¿Cuándo tengo que usar qué configuración?
Desde este enlace: https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+External+traffic
Durante el ciclo de lanzamiento 0.9.0.0, se introdujo el soporte para múltiples escuchas por agente. Cada escucha se asocia con un protocolo de seguridad, ip / host y puerto. Cuando se combina con el mecanismo de escuchas anunciado, hay una gran cantidad de flexibilidad con una limitación: a lo sumo un oyente por protocolo de seguridad en cada una de las dos configuraciones (escuchas y anunciantes).
En algunos entornos, uno puede querer diferenciar entre clientes externos, clientes internos y tráfico de replicación independientemente del protocolo de seguridad por razones de costo, rendimiento y seguridad. Algunos ejemplos que ilustran esto:
- El tráfico de replicación se asigna a una interfaz de red separada para que no interfiera con el tráfico del cliente.
- El tráfico externo pasa a través de un proxy / equilibrador de carga (seguridad, flexibilidad) mientras que el tráfico interno afecta directamente a los corredores (rendimiento, costo).
- Diferentes configuraciones de seguridad para el tráfico externo en comparación con el tráfico interno, aunque el protocolo de seguridad sea el mismo (por ejemplo, un conjunto diferente de mecanismos SASL habilitados, servidores de autenticación, diferentes almacenes de claves, etc.)
Como tal, proponemos que los agentes de Kafka puedan definir múltiples escuchas para el mismo protocolo de seguridad para vinculación (es decir, escuchas) y compartir (es decir, anunciantes. Listers) para que el tráfico interno, externo y de replicación se pueda separar si es necesario.
Asi que,
escuchas: lista de URI separadas por comas que escucharemos y sus protocolos. Especifique el nombre de host como 0.0.0.0 para enlazar a todas las interfaces. Deje el nombre de host vacío para enlazar a la interfaz predeterminada. Ejemplos de listas de oyentes legales:
- PLAINTEXT: // myhost: 9092, TRACE: //: 9091
- PLAINTEXT: //0.0.0.0: 9092, TRACE: // localhost: 9093
advertised.listeners - Oyentes para publicar en ZooKeeper para que los clientes los utilicen, si son diferentes a los oyentes anteriores. En los entornos IaaS, es posible que esto deba ser diferente de la interfaz a la que se vincula el intermediario. Si esto no se establece, se utilizará el valor para los listeners .
listeners es lo que el agente utilizará para crear sockets de servidor.
advertised.listeners es lo que los clientes usarán para conectarse a los corredores.
Las dos configuraciones pueden ser diferentes si tiene una configuración de red "compleja" (con elementos como subredes públicas y privadas y enrutamiento intermedio).