unicast switch multidifusión multidifusion mensajes los iptv ejemplos configurar característica java configuration multicast hazelcast

java - switch - ¿Cómo configura Hazelcast mediante programación para el mecanismo de descubrimiento de multidifusión?



multidifusion ip (7)

¿Puedes intentar crear tu instancia de Hazelcast de esta manera?

Config cfg = new Config(); HazelcastInstance hz = Hazelcast.newHazelcastInstance(cfg);

Las cosas del centro de administración y la creación de los ejecutores no son relevantes (agregué ese código en la aplicación de prueba, así que estoy 100% seguro de eso).

Entonces deberías tener exactamente la misma configuración de red que el TestApp.

¿Cómo configura Hazelcast mediante programación para el mecanismo de descubrimiento de multidifusión?

Detalles:

La documentation solo proporciona un ejemplo para TCP / IP y está desactualizada: utiliza Config.setPort (), que ya no existe.

Mi configuración se ve así, pero el descubrimiento no funciona (es decir, obtengo la salida "Members: 1" :

Config cfg = new Config(); NetworkConfig network = cfg.getNetworkConfig(); network.setPort(PORT_NUMBER); JoinConfig join = network.getJoin(); join.getTcpIpConfig().setEnabled(false); join.getAwsConfig().setEnabled(false); join.getMulticastConfig().setEnabled(true); join.getMulticastConfig().setMulticastGroup(MULTICAST_ADDRESS); join.getMulticastConfig().setMulticastPort(PORT_NUMBER); join.getMulticastConfig().setMulticastTimeoutSeconds(200); HazelcastInstance instance = Hazelcast.newHazelcastInstance(cfg); System.out.println("Members: "+hazelInst.getCluster().getMembers().size());

Actualización 1, teniendo en cuenta la respuesta de asimarslan.

Si busqué a tientas el MulticastTimeout, obtengo "Members: 1" o

05 de diciembre de 2013 20:50:42 p.m. com.hazelcast.nio.ReadHandler ADVERTENCIA: [192.168.0.9]: 4446 [dev] hz._hzInstance_1_dev.IO.thread-in-0 Socket de cierre al punto final Dirección [192.168.0.7] : 4446, Causa: java.io.EOFException: Socket remoto cerrado! 05 de diciembre de 2013 20:57:24 p.m. com.hazelcast.instance.Node SEVERE: [192.168.0.9]: 4446 [dev] No se pudo unir al clúster, ¡cerrándose! com.hazelcast.core.HazelcastException: ¡Error al unirse en 300 segundos!

Actualización 2, teniendo en cuenta la respuesta de pveentjer sobre el uso de TCP / IP

Si cambio la configuración a lo siguiente, todavía solo obtengo 1 miembro:

Config cfg = new Config(); NetworkConfig network = cfg.getNetworkConfig(); network.setPort(PORT_NUMBER); JoinConfig join = network.getJoin(); join.getMulticastConfig().setEnabled(false); join.getTcpIpConfig().addMember("192.168.0.1").addMember("192.168.0.2"). addMember("192.168.0.3").addMember("192.168.0.4"). addMember("192.168.0.5").addMember("192.168.0.6"). addMember("192.168.0.7").addMember("192.168.0.8"). addMember("192.168.0.9").addMember("192.168.0.10"). addMember("192.168.0.11").setRequiredMember(null).setEnabled(true); //this sets the allowed connections to the cluster? necessary for multicast, too? network.getInterfaces().setEnabled(true).addInterface("192.168.0.*"); HazelcastInstance instance = Hazelcast.newHazelcastInstance(cfg); System.out.println("debug: joined via "+join+" with "+hazelInst.getCluster() .getMembers().size()+" members.");

Más precisamente, esta ejecución produce la salida

debug: se unió a través de JoinConfig {multicastConfig = MulticastConfig [enabled = false, multicastGroup = 224.2.2.3, multicastPort = 54327, multicastTimeToLive = 32, multicastTimeoutSp.p.p.p.p.p.p.p.] miembros = [192.168.0.1, 192.168.0.2, 192.168.0.3, 192.168.0.4, 192.168.0.5, 192.168.0.6, 192.168.0.7, 192.168.0.8, 192.168.0.9, 192.168.0.10, 192.168.0.11], requiredMember = null], awsConfig = AwsConfig {enabled = false, region = ''us-east-1'', securityGroupName = ''null'', tagKey = ''null'', tagValue = ''null'', hostHeader = ''ec2.amazonaws.com'', connectionTimeoutSeconds = 5}} con 1 miembros.

Mi implementación que no es de hazelcast está utilizando multidifusiones UDP y funciona bien. Entonces, ¿puede un firewall realmente ser el problema?

Actualización 3, teniendo en cuenta la respuesta de pveentjer acerca de verificar la red

Ya que no tengo permisos para iptables o para instalar iperf, estoy usando com.hazelcast.examples.TestApp para verificar si mi red está funcionando, como se describe en Primeros pasos con Hazelcast en el Capítulo 2, Sección "Mostrar de inmediato ":

Llamo a java -cp hazelcast-3.1.2.jar com.hazelcast.examples.TestApp el 192.168.0.1 y obtengo la salida

...Dec 10, 2013 11:31:21 PM com.hazelcast.instance.DefaultAddressPicker INFO: Prefer IPv4 stack is true. Dec 10, 2013 11:31:21 PM com.hazelcast.instance.DefaultAddressPicker INFO: Picked Address[192.168.0.1]:5701, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5701], bind any local is true Dec 10, 2013 11:31:22 PM com.hazelcast.system INFO: [192.168.0.1]:5701 [dev] Hazelcast Community Edition 3.1.2 (20131120) starting at Address[192.168.0.1]:5701 Dec 10, 2013 11:31:22 PM com.hazelcast.system INFO: [192.168.0.1]:5701 [dev] Copyright (C) 2008-2013 Hazelcast.com Dec 10, 2013 11:31:22 PM com.hazelcast.instance.Node INFO: [192.168.0.1]:5701 [dev] Creating MulticastJoiner Dec 10, 2013 11:31:22 PM com.hazelcast.core.LifecycleService INFO: [192.168.0.1]:5701 [dev] Address[192.168.0.1]:5701 is STARTING Dec 10, 2013 11:31:24 PM com.hazelcast.cluster.MulticastJoiner INFO: [192.168.0.1]:5701 [dev] Members [1] { Member [192.168.0.1]:5701 this } Dec 10, 2013 11:31:24 PM com.hazelcast.core.LifecycleService INFO: [192.168.0.1]:5701 [dev] Address[192.168.0.1]:5701 is STARTED

Entonces llamo a java -cp hazelcast-3.1.2.jar com.hazelcast.examples.TestApp el 192.168.0.2 y obtengo la salida

...Dec 10, 2013 9:50:22 PM com.hazelcast.instance.DefaultAddressPicker INFO: Prefer IPv4 stack is true. Dec 10, 2013 9:50:22 PM com.hazelcast.instance.DefaultAddressPicker INFO: Picked Address[192.168.0.2]:5701, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5701], bind any local is true Dec 10, 2013 9:50:23 PM com.hazelcast.system INFO: [192.168.0.2]:5701 [dev] Hazelcast Community Edition 3.1.2 (20131120) starting at Address[192.168.0.2]:5701 Dec 10, 2013 9:50:23 PM com.hazelcast.system INFO: [192.168.0.2]:5701 [dev] Copyright (C) 2008-2013 Hazelcast.com Dec 10, 2013 9:50:23 PM com.hazelcast.instance.Node INFO: [192.168.0.2]:5701 [dev] Creating MulticastJoiner Dec 10, 2013 9:50:23 PM com.hazelcast.core.LifecycleService INFO: [192.168.0.2]:5701 [dev] Address[192.168.0.2]:5701 is STARTING Dec 10, 2013 9:50:23 PM com.hazelcast.nio.SocketConnector INFO: [192.168.0.2]:5701 [dev] Connecting to /192.168.0.1:5701, timeout: 0, bind-any: true Dec 10, 2013 9:50:23 PM com.hazelcast.nio.TcpIpConnectionManager INFO: [192.168.0.2]:5701 [dev] 38476 accepted socket connection from /192.168.0.1:5701 Dec 10, 2013 9:50:28 PM com.hazelcast.cluster.ClusterService INFO: [192.168.0.2]:5701 [dev] Members [2] { Member [192.168.0.1]:5701 Member [192.168.0.2]:5701 this } Dec 10, 2013 9:50:30 PM com.hazelcast.core.LifecycleService INFO: [192.168.0.2]:5701 [dev] Address[192.168.0.2]:5701 is STARTED

Entonces, el descubrimiento de multidifusión generalmente funciona en mi clúster, ¿verdad? ¿Es 5701 también el puerto para el descubrimiento? ¿Está 38476 en la última salida un ID o un puerto?

La unión aún no funciona para mi propio código con la configuración programática :(

Actualización 4, teniendo en cuenta la respuesta de pveentjer sobre el uso de la configuración por defecto

El TestApp modificado da la salida.

joinConfig{multicastConfig=MulticastConfig [enabled=true, multicastGroup=224.2.2.3, multicastPort=54327, multicastTimeToLive=32, multicastTimeoutSeconds=2, trustedInterfaces=[]], tcpIpConfig=TcpIpConfig [enabled=false, connectionTimeoutSeconds=5, members=[], requiredMember=null], awsConfig=AwsConfig{enabled=false, region=''us-east-1'', securityGroupName=''null'', tagKey=''null'', tagValue=''null'', hostHeader=''ec2.amazonaws.com'', connectionTimeoutSeconds=5}}

y detecta otros miembros después de un par de segundos (después de cada instancia, una vez se muestra solo como miembro si todos se inician al mismo tiempo), mientras que

myProgram da la salida

joined via JoinConfig{multicastConfig=MulticastConfig [enabled=true, multicastGroup=224.2.2.3, multicastPort=54327, multica/ stTimeToLive=32, multicastTimeoutSeconds=2, trustedInterfaces=[]], tcpIpConfig=TcpIpConfig [enabled=false, connectionTimeoutSecond/ s=5, members=[], requiredMember=null], awsConfig=AwsConfig{enabled=false, region=''us-east-1'', securityGroupName=''null'', tagKey=''nu/ ll'', tagValue=''null'', hostHeader=''ec2.amazonaws.com'', connectionTimeoutSeconds=5}} with 1 members.

y no detecta miembros dentro de su tiempo de ejecución de aproximadamente 1 minuto (estoy contando los miembros aproximadamente cada 5 segundos).

PERO si al menos una instancia de TestApp se ejecuta simultáneamente en el clúster, se detectan todas las instancias de TestApp y todas las instancias de myProgram y mi programa funciona bien. En caso de que inicie TestApp una vez y luego myProgram dos veces en paralelo, TestApp da el siguiente resultado:

java -cp ~/CaseStudy/jtorx-1.10.0-beta8/lib/hazelcast-3.1.2.jar:. TestApp Dec 12, 2013 12:02:15 PM com.hazelcast.instance.DefaultAddressPicker INFO: Prefer IPv4 stack is true. Dec 12, 2013 12:02:15 PM com.hazelcast.instance.DefaultAddressPicker INFO: Picked Address[192.168.180.240]:5701, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5701], bind any local is true Dec 12, 2013 12:02:15 PM com.hazelcast.system INFO: [192.168.180.240]:5701 [dev] Hazelcast Community Edition 3.1.2 (20131120) starting at Address[192.168.180.240]:5701 Dec 12, 2013 12:02:15 PM com.hazelcast.system INFO: [192.168.180.240]:5701 [dev] Copyright (C) 2008-2013 Hazelcast.com Dec 12, 2013 12:02:15 PM com.hazelcast.instance.Node INFO: [192.168.180.240]:5701 [dev] Creating MulticastJoiner Dec 12, 2013 12:02:15 PM com.hazelcast.core.LifecycleService INFO: [192.168.180.240]:5701 [dev] Address[192.168.180.240]:5701 is STARTING Dec 12, 2013 12:02:21 PM com.hazelcast.cluster.MulticastJoiner INFO: [192.168.180.240]:5701 [dev] Members [1] { Member [192.168.180.240]:5701 this } Dec 12, 2013 12:02:22 PM com.hazelcast.core.LifecycleService INFO: [192.168.180.240]:5701 [dev] Address[192.168.180.240]:5701 is STARTED Dec 12, 2013 12:02:22 PM com.hazelcast.management.ManagementCenterService INFO: [192.168.180.240]:5701 [dev] Hazelcast will connect to Management Center on address: http://localhost:8080/mancenter-3.1.2/ Join: JoinConfig{multicastConfig=MulticastConfig [enabled=true, multicastGroup=224.2.2.3, multicastPort=54327, multicastTimeToLive=32, multicastTimeoutSeconds=2, trustedInterfaces=[]], tcpIpConfig=TcpIpConfig [enabled=false, connectionTimeoutSeconds=5, members=[], requiredMember=null], awsConfig=AwsConfig{enabled=false, region=''us-east-1'', securityGroupName=''null'', tagKey=''null'', tagValue=''null'', hostHeader=''ec2.amazonaws.com'', connectionTimeoutSeconds=5}} Dec 12, 2013 12:02:22 PM com.hazelcast.partition.PartitionService INFO: [192.168.180.240]:5701 [dev] Initializing cluster partition table first arrangement... hazelcast[default] > Dec 12, 2013 12:03:27 PM com.hazelcast.nio.SocketAcceptor INFO: [192.168.180.240]:5701 [dev] Accepting socket connection from /192.168.0.8:38764 Dec 12, 2013 12:03:27 PM com.hazelcast.nio.TcpIpConnectionManager INFO: [192.168.180.240]:5701 [dev] 5701 accepted socket connection from /192.168.0.8:38764 Dec 12, 2013 12:03:27 PM com.hazelcast.nio.SocketAcceptor INFO: [192.168.180.240]:5701 [dev] Accepting socket connection from /192.168.0.7:54436 Dec 12, 2013 12:03:27 PM com.hazelcast.nio.TcpIpConnectionManager INFO: [192.168.180.240]:5701 [dev] 5701 accepted socket connection from /192.168.0.7:54436 Dec 12, 2013 12:03:32 PM com.hazelcast.partition.PartitionService INFO: [192.168.180.240]:5701 [dev] Re-partitioning cluster data... Migration queue size: 181 Dec 12, 2013 12:03:32 PM com.hazelcast.cluster.ClusterService INFO: [192.168.180.240]:5701 [dev] Members [3] { Member [192.168.180.240]:5701 this Member [192.168.0.8]:5701 Member [192.168.0.7]:5701 } Dec 12, 2013 12:03:43 PM com.hazelcast.partition.PartitionService INFO: [192.168.180.240]:5701 [dev] Re-partitioning cluster data... Migration queue size: 181 Dec 12, 2013 12:03:45 PM com.hazelcast.partition.PartitionService INFO: [192.168.180.240]:5701 [dev] All migration tasks has been completed, queues are empty. Dec 12, 2013 12:03:46 PM com.hazelcast.nio.TcpIpConnection INFO: [192.168.180.240]:5701 [dev] Connection [Address[192.168.0.8]:5701] lost. Reason: Socket explicitly closed Dec 12, 2013 12:03:46 PM com.hazelcast.cluster.ClusterService INFO: [192.168.180.240]:5701 [dev] Removing Member [192.168.0.8]:5701 Dec 12, 2013 12:03:46 PM com.hazelcast.cluster.ClusterService INFO: [192.168.180.240]:5701 [dev] Members [2] { Member [192.168.180.240]:5701 this Member [192.168.0.7]:5701 } Dec 12, 2013 12:03:48 PM com.hazelcast.partition.PartitionService INFO: [192.168.180.240]:5701 [dev] Partition balance is ok, no need to re-partition cluster data... Dec 12, 2013 12:03:48 PM com.hazelcast.nio.TcpIpConnection INFO: [192.168.180.240]:5701 [dev] Connection [Address[192.168.0.7]:5701] lost. Reason: Socket explicitly closed Dec 12, 2013 12:03:48 PM com.hazelcast.cluster.ClusterService INFO: [192.168.180.240]:5701 [dev] Removing Member [192.168.0.7]:5701 Dec 12, 2013 12:03:48 PM com.hazelcast.cluster.ClusterService INFO: [192.168.180.240]:5701 [dev] Members [1] { Member [192.168.180.240]:5701 this } Dec 12, 2013 12:03:48 PM com.hazelcast.partition.PartitionService INFO: [192.168.180.240]:5701 [dev] Partition balance is ok, no need to re-partition cluster data...

La única diferencia que veo en la configuración de TestApp es

config.getManagementCenterConfig().setEnabled(true); config.getManagementCenterConfig().setUrl("http://localhost:8080/mancenter-"+version); for(int k=1;k<= LOAD_EXECUTORS_COUNT;k++){ config.addExecutorConfig(new ExecutorConfig("e"+k).setPoolSize(k)); }

así que también lo agregué en un intento desesperado en mi Programa. Pero no resuelve el problema, aún así, cada instancia solo se detecta a sí misma como miembro durante toda la ejecución.

Actualización sobre cuánto tiempo se ejecuta myProgram

¿Podría ser que el programa no se está ejecutando el tiempo suficiente (como lo dijo pveentjer)?

Mis experimentos parecen confirmar esto: si el tiempo t entre Hazelcast.newHazelcastInstance(cfg); e inicializar cleanUp() (es decir, ya no se comunica a través de hazelcast y ya no verifica el número de miembros)

  • Menos de 30 segundos, sin comunicación y members: 1
  • más de 30 segundos: se encuentran todos los miembros y ocurre la comunicación (lo que parece extraño que ocurre durante mucho más tiempo que t - 30 segundos).

¿Es 30 segundos un lapso de tiempo realista que necesita un clúster de hazelcast, o está pasando algo extraño? Aquí hay un registro de 4 myPrograms que se ejecutan simultáneamente (buscando miembros de hazelcast que se solapan 30 segundos para la instancia 1 y la instancia 3):

instance 1: 2013-12-19T12:39:16.553+0100 LOG 0 (START) engine started looking for members between 2013-12-19T12:39:21.973+0100 and 2013-12-19T12:40:27.863+0100 2013-12-19T12:40:28.205+0100 LOG 35 (Torx-Explorer) Model SymToSim is about to/ exit instance 2: 2013-12-19T12:39:16.592+0100 LOG 0 (START) engine started looking for members between 2013-12-19T12:39:22.192+0100 and 2013-12-19T12:39:28.429+0100 2013-12-19T12:39:28.711+0100 LOG 52 (Torx-Explorer) Model SymToSim is about to/ exit instance 3: 2013-12-19T12:39:16.593+0100 LOG 0 (START) engine started looking for members between 2013-12-19T12:39:22.145+0100 and 2013-12-19T12:39:52.425+0100 2013-12-19T12:39:52.639+0100 LOG 54 (Torx-Explorer) Model SymToSim is about to/ exit INSTANCE 4: 2013-12-19T12:39:16.885+0100 LOG 0 (START) engine started looking for members between 2013-12-19T12:39:21.478+0100 and 2013-12-19T12:39:35.980+0100 2013-12-19T12:39:36.024+0100 LOG 34 (Torx-Explorer) Model SymToSim is about to/ exit

¿Cómo comienzo mejor mi algoritmo distribuido real solo después de que haya suficientes miembros presentes en el clúster de hazelcast? ¿Puedo configurar hazelcast.initial.min.cluster.size programación? https://groups.google.com/forum/#!topic/hazelcast/sa-lmpEDa6A suena como que esto bloquearía Hazelcast.newHazelcastInstance(cfg); hasta que se llega a initial.min.cluster.size. ¿Correcto? ¿Qué tan sincrónicamente (dentro de qué lapso de tiempo) se desbloquearán las diferentes instancias?

¿Puedes probar con tcp / ip cluster primero para asegurarte de que todo lo demás está bien? Una vez que haya confirmado que no hay problema, intente multidifusión. También podría ser un problema de firewall por cierto.

Así que parece que Multicast está trabajando en su red; lo que es bueno.

Podrías intentarlo con la siguiente configuración:

Config cfg = new Config(); NetworkConfig network = cfg.getNetworkConfig(); JoinConfig join = network.getJoin(); join.getTcpIpConfig().setEnabled(false); join.getAwsConfig().setEnabled(false); join.getMulticastConfig().setEnabled(true); HazelcastInstance instance = Hazelcast.newHazelcastInstance(cfg);

Como puedes ver, he eliminado toda la personalización.

El problema aparentemente es que el clúster se inicia (y se detiene) y no espera hasta que haya suficientes miembros en el clúster. Puede configurar la propiedad hazelcast.initial.min.cluster.size para evitar que esto suceda.

Puedes configurar ''hazelcast.initial.min.cluster.size'' programáticamente usando:

Config config = new Config(); config.setProperty("hazelcast.initial.min.cluster.size","3");

Parece que Hazelcast usa la dirección de multidifusión 224.2.2.3 en el puerto UDP 54327 (por defecto) para el descubrimiento, y luego el puerto 5701 para la comunicación TCP. Abriendo el puerto UDP 54327 en el descubrimiento de firewall fijo para mí. (También había abierto el puerto TCP 5701, pero eso no fue suficiente).

Parece que estás usando clúster TCP / IP, así que eso es bueno. Prueba lo siguiente (del libro hazelcast)

Si está utilizando iptables, se puede agregar la siguiente regla para permitir el tráfico de salida desde los puertos 33000-31000:

iptables -A OUTPUT -p TCP --dport 33000:31000 -m state --state NEW -j ACCEPT

y para controlar el tráfico entrante desde cualquier dirección al puerto 5701:

iptables -A INPUT -p tcp -d 0/0 -s 0/0 --dport 5701 -j ACCEPT

y para permitir el tráfico de multidifusión entrante:

iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT

Prueba de conectividad Si tiene problemas porque las máquinas no se unen a un clúster, puede verificar la conexión de la red entre las 2 máquinas. Puedes usar una herramienta llamada iperf para eso. En una máquina ejecuta: iperf -s -p 5701 Esto significa que está escuchando en el puerto 5701.

En la otra máquina ejecutas el siguiente comando:

iperf -c 192.168.1.107 -d -p 5701

Donde reemplaza ''192.168.1.107'' por la dirección IP de su primera máquina. Si ejecuta el comando y obtiene una salida como esta:

------------------------------------------------------------ Server listening on TCP port 5701 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.1.107, TCP port 5701 TCP window size: 59.4 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.1.105 port 40524 connected with 192.168.1.107 port 5701 [ 4] local 192.168.1.105 port 5701 connected with 192.168.1.107 port 33641 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.2 sec 55.8 MBytes 45.7 Mbits/sec [ 5] 0.0-10.3 sec 6.25 MBytes 5.07 Mbits/sec

Usted sabe que las 2 máquinas pueden conectarse entre sí. Sin embargo, si estás viendo algo como esto:

Server listening on TCP port 5701 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ connect failed: No route to host

Entonces sabrá que puede tener un problema de conexión de red en sus manos.

Su configuración es correcta, PERO ha establecido un tiempo de espera de multidifusión muy largo de 200 segundos, donde el valor predeterminado es 2 segundos. establecer un valor menor lo resolverá.

De Hazelcast Java API Doc: MulticastConfig.html#setMulticastTimeoutSeconds(int)

Especifica el tiempo en segundos que un nodo debe esperar una respuesta de multidifusión válida de otro nodo que se ejecuta en la red antes de declararse como nodo maestro y crear su propio clúster. Esto se aplica solo al inicio de nodos donde aún no se ha asignado un maestro. Si especifica un valor alto, por ejemplo, 60 segundos, significa que hasta que se seleccione un maestro, cada nodo esperará 60 segundos antes de continuar, así que tenga cuidado al proporcionar un valor alto . Si el valor es demasiado bajo, es posible que los nodos se rindan demasiado pronto y creen su propio clúster.