No se puede conectar a Cloudera Manager, no se escucha en el puerto 7180

Agradecería un poco de ayuda para cloudera manager que se ejecutan en AWS EC2.
Es mi primera instalación, y estoy buscando para el uso de la capa Gratuita de AWS para hacer girar un par de nodos y un poco de entrenamiento en clúster Hadoop y el cloudera de distribución. Yo estoy usando el de red hat enterprise linux RedHat 7.2 de la imagen en AWS EC2.

Estoy siguiendo las instrucciones aquí… Cloudera Manager instalación

He instalado cloudera manager ACEPTAR y llegar a la pantalla donde se le invita a utilizar un navegador para iniciar sesión en el cloudera manager server. Pero ahí es donde empieza el problema. Parece que la aplicación no está escuchando en el puerto 7180, así que no hay esperanza de que se conecta desde otra máquina a través de la red. Ni siquiera puedo conectar localmente en el servidor, sin embargo, el servicio parece estar funcionando OK. Pero no la escucha en el puerto 7180.

Q1 – ¿Cómo puedo confirmar que la configuración está configurado para utilizar el puerto 7180.?

Q2 – hay pasos obvios de que me estoy perdiendo aquí ?

Gracias de antemano,

[Editar..]
Estoy empezando a preguntarme si el Libre EC2 host queda corto en memoria para ejecutar cloudera manager. Vi un comentario que implicaba que….AWS post del Foro . Pero el proceso no se bloquee o informar de cualquier problema en su archivo de registro. Así que se debe ACEPTAR, ¿verdad?

[Editar…. más información de diagnóstico….]

Aquí está una lista de los diagnósticos he comprobado:-

  • SELinux no se está ejecutando [para instalar y realizar las pruebas],
  • WAN firewalls,
  • EC2 firewall/grupo de Seguridad,
  • Local firewall en el servidor,
  • Cloudera manager de registro,
  • Es el servicio funcionando?
  • Puede conectar localmente?

Del seguro de grupo en la instancia de EC2, que contiene:-
SSH y Puerto 7180,

Firewall/iptables/firewalld en el RedHat instancia, trató de:-
la adición de puertos para iptables, entonces
dissabling iptables, entonces
la adición de puertos para firewalld, entonces
dissabling la firewalld servicio,

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:7180
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:7182

Pero estoy recibiendo la sensación de que la instalación de cloudera manager es no es feliz, o no se ejecuta correctamente.

He comprobado la cloudera manager de registro, y termina con la siguiente.

$ tail /var/log/cloudera-scm-server/cloudera-scm-server.log
2016-02-25 11:02:23,581 INFO main:com.cloudera.cmon.components.MetricSchemaUpdate: persisting 19264 new metrics
2016-02-25 11:02:28,920 INFO main:com.cloudera.cmon.components.MetricSchemaUpdate: persisting 0 updated metrics
2016-02-25 11:02:28,924 INFO main:com.cloudera.cmon.components.MetricSchemaManager: Cross entity aggregates processed.

Y cuando uso tail-f, y reiniciar el cloudera-scm-servicio servidor, el registro se desplaza mucho, y regresa el mismo estado. Si busco el ERROR, no hay líneas con «ERR».

$ sudo service cloudera-scm-server start
Starting cloudera-scm-server (via systemctl):              [  OK  ]

$ sudo systemctl status cloudera-scm-server
● cloudera-scm-server.service - LSB: Cloudera SCM Server
   Loaded: loaded (/etc/rc.d/init.d/cloudera-scm-server)
   Active: active (exited) since Thu 2016-02-25 12:23:03 EST; 44s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 747 ExecStart=/etc/rc.d/init.d/cloudera-scm-server start (code=exited, status=0/SUCCESS)

Por lo tanto, si trato de probar el servicio, mediante la conexión de la máquina local puedo conseguir el tipo de behavious que me hace cosa no sólo de su escucha, y tal vez no se inicia correctamente.

Intentar poke con un rizo de la misma shell como el cloudera-scm-servidor se inició el servicio

$ curl localhost:7180
curl: (7) Failed connect to localhost:7180; Connection refused

$ wget localhost:7180
--2016-02-25 08:00:16--  http://localhost:7180/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:7180... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:7180... failed: Connection refused.

Intentar comprobar qué puertos están escuchando en ese equipo, no 7180 , qué pasa con eso???

$ netstat -nltp
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:7432            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::7432                 :::*                    LISTEN      -                   
tcp6       0      0 :::22                   :::*                    LISTEN      -                   
tcp6       0      0 ::1:25                  :::*                    LISTEN      -  
  • Bingo – problema encontrado con memoria insuficiente – mensaje en los registros $ sudo tail -100 /var/log/cloudera-scm-server/cloudera-scm-server.out JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x000000078dc58000, 265809920, 0) failed; error='Cannot allocate memory' (errno=12) # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 265809920 bytes for committing reserved memory. # An error report file with more information is saved as: # /tmp/hs_err_pid831.log
InformationsquelleAutor Hadoop_noob | 2016-02-25

5 Kommentare

  1. 2

    Aquí está lo que buscas, y una posible solución – para darle más memoria…

    Comprobar el estado de la cloudera-scm-servicio de servidor utilizando [dependiendo de su sabor de linux]

    $ sudo service cloudera-scm-server status
    

    O

    $ sudo systemctl status cloudera-scm-server
    

    Mirar por el estado – Active: active (running)
    Pero si usted encuentra – Active: active (exited)
    usted puede tener un problema durante el inicio de la cloudera-scm-servidor.

    En cuyo caso, buscar en los archivos de registro para cloudera-scm-servidor

    $sudo ls -l /var/log/cloudera-scm-server
    
    $sudo cat /var/log/cloudera-scm-server/cloudera-scm-server.out 
    JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera
    Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x000000078dc58000, 265809920, 0) failed; error='Cannot allocate memory' (errno=12)
    #
    # There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (malloc) failed to allocate 265809920 bytes for committing reserved memory.
    # An error report file with more information is saved as:
    # /tmp/hs_err_pid831.log
    [[email protected] ~]$ sudo tail -100 /var/log/cloudera-scm-server/cloudera-scm-server.out
    JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera
    Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x000000078dc58000, 265809920, 0) failed; error='Cannot allocate memory' (errno=12)
    

    Utilice el comando top para indicar la cantidad de memoria disponible para tu sistema.

    Posible solución – eche un vistazo a esta discusión en Cloudera foro

    En este caso, el almacenamiento dinámico de java tamaño era demasiado pequeño.

    Como vemos que el montón estaba agotado, suponiendo que esto no es una pérdida de memoria
    o algo por el estilo, Cloudera Manager puede necesitar más del montón a
    operar. Esto se puede configurar en:
    /etc/default/cloudera-scm-servidor de Usted, por ejemplo, podría cambiar «-Xmx2G» a «-Xmx3G» o «-Xmx4G» Si el problema sigue
    sucede, tal vez el montón volcados yeild algunas pistas.

  2. 0

    Te sugiero que la cola de los registros. Si usted está usando la capa gratuita, cloudera manager va a tomar un tiempo para llegar… posiblemente hasta 5 minutos o más después de iniciar el cloudera-scm-server.

    Los registros deben mostrar si hay cualquier error, posiblemente problemas con la asignación de memoria desde la capa gratuita de servidores han limitado la memoria disponible. El pequeño fragmento de las entradas del registro se ve bien y típico – se va a ir a través de una larga lista de procesos antes de que la interfaz de usuario aparece en 7180.

    También mientras que está pasando, ejecutar top o incluso free -g para ver la cantidad de recursos que están siendo utilizados – en particular de la memoria.

    • Gracias por tu comentario @OkezieE. CM se queda atascado en el mismo lugar. Su sido de alrededor de 3-4 horas desde el inicio, y el archivo de registro no se ha movido de {código}2016-02-25 12:19:47,762 INFORMACIÓN principal:com.cloudera.cmon.componentes.MetricSchemaManager: la Cruz de la entidad agregados procesados. {código}
    • También he descubierto que la base de datos se está ejecutando. Yo empezaba a pensar que tal vez se me olvidó instalar una db para Cloudera para persistir los datos. # Auto-generated by initialize_embedded_db.sh # # 20160225-073401 # # These are database settings for CM Manager # com.cloudera.cmf.db.type=postgresql com.cloudera.cmf.db.host=localhost:7432 com.cloudera.cmf.db.name=scm com.cloudera.cmf.db.user=scm
    • ¿Cómo el uso de los recursos de la mirada en ese servidor. Francamente, yo creo que la capa gratuita de la instancia de ec2 (t2.micro, t1.micro e.t.c) son demasiado limitados, tanto en términos de CPU y de Memoria. Tiene un solo núcleo y la memoria es de ~500 MB disponibles para el no uso del sistema. No creo que es suficiente teniendo en cuenta los requisitos del sistema de Cloudera Manager. Revise esta página, antes de ir más lejos: cloudera.com/documentation/enterprise/5-4-x/topics/…
  3. 0

    Yo estaba teniendo el mismo problema, no se puede golpear el CM de inicio de sesión utilizando los DNS o IP en el puerto 7180.

    Siguientes pasos le ayudarán a :

    iptables stopped (service iptables stop)  
    SELinux disabled (got to /etc/selinux/config and disbaled the selinux)   
    curl/wget localhost:7180 works (check the curl status)  
    ufw allow 7180  
    service httpd status should be running.  
    check va/log/cloudera-scm-server log : if any error found then troubleshoot the error      
    cloudera-scm-server status (should be running state)
    netstat -nap | grep 7180 returns  (if running other service then kill it)
    

    telnet localhost 7180 (debe estar conectado)

  4. 0

    No se puede conectar a Cloudera Manager, no se escucha en el puerto 7180

    1] Comprobar el estado:

    sudo service cloudera-scm-estado del servidor

    *cloudera-scm-server.service - LSB: Cloudera SCM Server Loaded: loaded (/etc/rc.d/init.d/cloudera-scm-server; bad; vendor preset: disabled)   Active: active (exited) since  UTC; 47min ago      Docs: man:systemd-sysv-generator(8) rm /var/run/cloudera-scm-server.pid
    

    NOTA : El Cloudera Manager de servicio no se ejecuta como se sale de forma anormal.
    Ejecutando el servicio de cloudera-scm-estado del servidor imprimirá el siguiente mensaje «cloudera-scm-server muerto, pero pid archivo existe».

    Razón: Fuera de la memoria.

    Solución : Examinar el montón de volcado de que el Cloudera Manager Server crea cuando se ejecuta fuera de la memoria. El montón de volcado de archivo es creado en el directorio /tmp, tiene la extensión de archivo .hprof y permisos de archivo de 600. Su propietario y grupo será el propietario y el grupo de la Cloudera Manager de proceso de servidor, normalmente cloudera-scm:cloudera-scm.

    Enlace : http://www.cloudera.com/documentation/manager/5-0-x/Cloudera-Manager-Diagnostics-Guide/cm5dg_troubleshooting_cluster_config.html

  5. 0
        Check the status of `cloudera-scm-server` and follow the instructions ahead:
    
        [[email protected] ~]# `service cloudera-scm-server status`
        By default, Cloudera's QuickStart VM manages CDH using Linux's configuration
        and service management. To use Cloudera Manager instead, you must shut down
        and disable the existing CDH services and then start Cloudera Manager. You can
        do this by running the following command:
    
    `sudo /home/cloudera/cloudera-manager`    
    
    
        [[email protected] ~]#    `sudo /home/cloudera/cloudera-manager `    
        `[QuickStart] Shutting down CDH services via init scripts...
        JMX enabled by default
        Using config: /etc/zookeeper/conf/zoo.cfg
        [QuickStart] Disabling CDH services on boot...
        [QuickStart] Starting Cloudera Manager services...
        [QuickStart] Deploying client configuration...
        [QuickStart] Starting CM Management services...
        [QuickStart] Enabling CM services on boot...
        [QuickStart] Starting CDH services...`
        ________________________________________________________________________________
    
        Success! You can now log into Cloudera Manager from the QuickStart VM's browser:
    
        http://quickstart.cloudera:7180
    
        Username: cloudera
        Password: cloudera
    

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea