Uso de Big Data Studio

Big Data Studio se ejecuta en el segundo nodo de utilidad de un cluster de alta disponibilidad (HA) o en el primer (y único) nodo de utilidad de un cluster sin HA. Para poder acceder a Big Data Studio desde un explorador, un administrador debe:

• Haga que el nodo esté disponible para las conexiones entrantes de los usuarios. La dirección IP privada del nodo se puede asignar a una dirección IP pública. Como alternativa, el cluster se puede configurar para utilizar un bastion host u Oracle FastConnect. Consulte Conexión a nodos de cluster con direcciones IP privadas.
• Abra el puerto 30000 en el nodo configurando las reglas de entrada en la lista de seguridad de la red. Consulte Definición de reglas de seguridad.

Las credenciales de conexión de administrador por defecto para Big Data Studio son las siguientes:

• Nombre de usuario: datastudio

• Contraseña: contraseña de administrador de Apache Ambari o Cloudera Manager. Se trata de la contraseña del administrador del cluster que se especificó cuando se creó el cluster.

El administrador crea usuarios adicionales y sus credenciales de conexión y proporciona dichas credenciales a esos usuarios. Consulte Creación y supresión de usuarios.

Para acceder a Big Data Studio directamente desde un explorador:

1. Abra una ventana del explorador.
2. Introduzca una URL con el siguiente formato:

   https://<node_ip_address>:30000

   Por ejemplo:

   https://192.0.2.0:30000

3. Conéctese con sus credenciales.

También puede crear un equilibrador de carga para proporcionar un front-end seguro para acceder a los servicios, incluido Big Data Studio. Consulte Connecting to Services on a Cluster Using Load Balancer.

Para realizar estas acciones, debe tener derechos de acceso al cluster a través del sistema operativo.

Para cambiar la ruta por defecto:

1. Conéctese como el usuario opc al nodo de utilidad donde reside Big Data Studio (el segundo nodo de utilidad de un cluster de alta disponibilidad [HA] o el primer y único nodo de utilidad de un cluster sin HA).
2. Cambie al usuario root:

   sudo su

3. Como root, confirme que tiene el problema mediante route -n. El problema se produce cuando se utiliza ens3 para la ruta por defecto (ens3 es la interfaz que corresponde a la subred del cluster). Por ejemplo:

   $ route -n
   Kernel IP routing table
   Destination Gateway Genmask Flags Metric Ref Use Iface
   0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 ens3

   En este ejemplo, 10.0.0.1 es el gateway de la subred del cluster.

4. Determine el gateway de su subred ejecutando route -n | grep ens5. La salida tendrá un aspecto similar al siguiente:

   10.200.0.0 0.0.0.0 255.255.128.0 U 0 0 0 ens5

   donde la primera cadena es la red (en este caso, 10.200.0.0). El gateway es la red incrementada en 1 (en este caso, 10.200.0.1).

5. Agregue la nueva ruta por defecto:

   route add default gw <your-subnet-gateway> ens5

   En el ejemplo anterior, <your-subnet-gateway> es 10.200.0.1, por lo que el comando sería:

   route add default gw 10.200.0.1 ens5

6. Elimine la ruta por defecto anterior:

   route del default gw <cluster-subnet-gateway>

   En el ejemplo anterior, <cluster-subnet-gateway> es 10.0.0.1, por lo que el comando sería:

   route del default gw 10.0.0.1

7. Verifique la nueva ruta por defecto. Debería ver algo similar a lo siguiente:

   $ route -n
   Kernel IP routing table
   Destination Gateway Genmask Flags Metric Ref Use Iface
   0.0.0.0 10.200.0.1 0.0.0.0 UG 0 0 0 ens5

Se accede a cada sección desde los iconos de la izquierda.