Consideraciones para el despliegue de Hadoop en Oracle Cloud Infrastructure

Despliegue

Cuando se suscribe a la infraestructura de Oracle como un servicio (IaaS), tiene acceso a todos los servicios informáticos, de almacenamiento y de red asociados. Los despliegues en Oracle Cloud Infrastructure son como los despliegues locales, en que las mismas versiones y funciones están disponibles para cada distribución de Hadoop.

Teraform y gestor de recursos

Los equipos de ingeniería de Oracle Cloud Infrastructure se han asociado a cada ISV de Hadoop para permitir el despliegue que aprovecha Terraform. Terraform permite implementar la infraestructura como código (IaC), y esto incluye todos los aspectos de un ecosistema Hadoop, desde redes (redes virtuales en la nube, subredes, VNIC) y listas de control de acceso de seguridad para calcular y almacenar. Terraform es flexible, altamente escalable y estándar entre muchos proveedores en la nube.

Puede seleccionar si desea utilizar estas plantillas como marco para desplegar Hadoop en Oracle Cloud Infrastructure, o puede mantener con la herramienta de despliegue existente que ha utilizado en la ubicación local. Ambos métodos son válidos.

Si desea utilizar Terraform para desplegar Hadoop, considere utilizar Oracle Resource Manager. Tenga en cuenta las ventajas clave del uso del gestor de recursos:

Los metadatos de estado de Terraform se mantienen en una ubicación de alta disponibilidad.
El acceso al gestor de recursos se puede gestionar con la misma seguridad y las mismas herramientas de auditoría incluidas para otros servicios de Oracle Cloud Infrastructure.
El gestor de recursos elimina la complejidad asociada a la configuración de Terraform para el despliegue en Oracle Cloud Infrastructure.

La interfaz del gestor de recursos soporta archivos de esquema basados en YAML rellenados con valores esperados para variables de pila. Esto permite definir las formas, versiones de software y otros parámetros permitidos para cada variable de la pila.

Descripción de la ilustración resource-manager-ui.png

Una vez que se rellena el archivo de esquema, los valores se muestran en una interfaz de usuario fácil de utilizar. El archivo de esquema permite tener listas desplegables con estos valores, así como campos de entrada personalizados en las que los usuarios pueden escribir o pegar entradas.

Los campos del archivo de esquema también pueden tener dependencias, de modo que si un usuario selecciona un valor en un campo, se muestran u ocultan otros campos en función de esa opción.

Topología de Servicio de Cluster

Al desplegar Hadoop, tenga en cuenta la siguiente asignación de topología de servicio de cluster a roles de nodo:

Tipo de nodo	Rol de Hadoop	Servicios Hadoop
Posición	Acceso de usuario desde perímetro	Bibliotecas de Cliente, Oozie
Utilidad	Gestión de Cluster	Cloudera Manager, Ambari, base de datos de metadatos
Maestro	Servicios de Cluster Principales	Zookeeper, NameNode, JournalNode, HIVE, HBase Master, Spark History, Job History, Resource Manager, HTTPFS, SOLR
Trabajador	Ejecución de Carga de Trabajo, Almacenamiento de Datos	HDFS, NodeManager, Servidor de Regiones, Broker de Kafka, Ejecutor de Spark, Mapa/Reducir

Al elegir qué unidades de computación utilizar para estos roles, las mejores prácticas se describen más adelante en esta solución. Tenga en cuenta también los siguientes criterios:

¿Cuántos usuarios simultáneos utilizarán el cluster?
Los nodos de posición se deben escalar tanto en cantidad como en OCPU, según el número de usuarios simultáneos. Dos usuarios simultáneos por OCPU es una buena instrucción, lo que permite un thread por usuario. Además, en diferentes dominios de errores se proporciona redundancia.
¿Tiene requisitos específicos de memoria del servidor de la región Spark u HBase?
Estos requisitos afectan directamente a la cantidad y la composición de los nodos del trabajador. El tamaño para HBase requiere tener en cuenta la aplicación subyacente, y varía. La mayoría de los clientes ya conocen sus requisitos para el despliegue de HBase, específicamente el número de servidores de región y memoria asignados por servidor. Las cargas de trabajo de Spark tienen de manera similar un destino de memoria agregada que se alcanza factorizando el número de nodos trabajadores multiplicados por la memoria disponible por trabajador.
¿Tiene un requisito de capacidad de HDFS específico?
La mayoría de los clientes tienen este requisito. Pero antes de ampliar la anchura a un gran número de nodos de trabajadores con hardware dedicado de DenseIO, considere que los volúmenes de bloques pueden aumentar el HDFS con el código base de NVMe para lograr la densidad HDFS necesaria, como se describe más adelante en esta solución. Oracle recomienda que comprenda los requisitos de HDFS, pero también cumpla los requisitos de carga de trabajo de modo que pueda “tamaño correcto” el cluster para que alcance ambos destinos al mismo tiempo que minimiza el costo.

Migración

Cuando los clientes que ejecutan Hadoop deciden desplegar en Oracle Cloud Infrastructure, suelen tener un gran volumen de datos para migrar. El bloque de estos datos está presente en HDFS, con los metadatos de cluster de soporte presentes en una base de datos.

La copia de datos de HDFS directamente por Internet puede ser difícil por varios motivos:

El volumen de datos es demasiado grande, o el ancho de banda disponible está demasiado restringido, para admitir la copia de datos sin transmisión en cualquier marco temporal significativo.
Los datos son sensibles a mayúsculas y se copian mediante Internet podría no estar permitidos por requisitos normativos o reguladores.
Los recursos de cluster locales están restringidos y la copia de datos afectaría a la carga de trabajo en curso.

Se admiten varios enfoques para la migración de datos. Se definen mediante el tipo de datos que se están migrando.

Migración de Datos de HDFS

Hay tres formas más comunes de copiar datos HDFS en Oracle Cloud Infrastructure:

Copie los datos directamente de un cluster local en el almacenamiento de objetos en una región de Oracle Cloud Infrastructure mediante VPN a través de Internet o con FastConnect. Una vez completado este proceso, se puede rehidratar un cluster de Oracle Cloud Infrastructure con los datos del almacenamiento de objetos.
Copie los datos directamente de un cluster local en un cluster de Oracle Cloud Infrastructure en Internet o mediante FastConnect.
Copiar datos a un dispositivo de transferencia de datos, que se despliega en el centro de datos del cliente, se rellena con datos y, a continuación, se envía a Oracle y se carga en Object Storage. Un cluster de Oracle Cloud Infrastructure se puede rehidratar con estos datos.

En esta solución, se analizan los detalles técnicos acerca de cada uno de estos métodos.

Migración de metadatos

Los metadatos del cluster suelen ser mucho más pequeños que los datos de HDFS y existen en una base de datos en el cluster local.

La migración de metadatos de cluster depende de dos factores: la distribución de Hadoop en el cluster de origen y la base de datos que se utiliza para almacenar metadatos. La transferencia de estos datos es directa y específica para cada distribución de Hadoop.

En esta solución se presentan detalles sobre cada distribución de Hadoop.

Seguridad

La seguridad en la nube es especialmente importante para Hadoop y hay muchas formas de garantizar que el despliegue en Oracle Cloud Infrastructure sigue siendo seguro.

Tenga en cuenta primero algunos controles de seguridad específicos de Oracle Cloud Infrastructure:

Aproveche Identity and Access Management (IAM) para controlar quién tiene acceso a recursos en la nube, qué tipo de acceso tiene un grupo de usuarios y a qué recursos específicos. Esta arquitectura puede proporcionar los siguientes resultados:
- Aislar de forma segura los recursos de nube según la estructura de organización
- Autentique a los usuarios para acceder a servicios en la nube a través de una interfaz de explorador, API de REST, SDK o CLI
- Autorizar a grupos de usuarios realizar acciones en los recursos en la nube adecuados
- Federación con proveedores de identidad existentes
- Permitir que un proveedor de servicios gestionado (MSP) o el integrador de sistemas (SI) gestione los activos de infraestructura aunque los operadores puedan acceder a los recursos.
- Autorizar instancias de aplicación para realizar llamadas de API con servicios en la nube
Auditar listas de seguridad para todas las redes de la red virtual en la nube (VCN). Convierta estas reglas en lo más restrictivo posible y permita el tráfico de confianza solo en subredes de Internet.
Active firewalls de host en hosts orientados a Internet y permita sólo el tráfico necesario.
Considere la posibilidad de utilizar la auditoría de seguridad con regularidad.

El cifrado también es una buena opción para datos en el resto y datos en el movimiento. Considere los siguientes recursos:

Mecanismos de cifrado de Cloudera
Hortonworks
- Cifrado HDFS en el resto
- Cifrado mediante giro
Cifrado en MapR

Otras consideraciones de seguridad específicas de Hadoop incluyen:

Despliegue clusters en subredes con direcciones IP privadas, que sólo expone las API o interfaces de usuario necesarias a subredes orientadas a Internet.
Ejecutar Hadoop con Seguridad de Cluster
Utilice nodos de límite para acceder a los servicios de cluster mediante un canal SSH. Esto resulta incluso más fácil en Mac o Linux.
Aproveche Apache Knox para proteger puntos finales de API.
Utilice el navegador de Apache Sentry o Cloudera para el acceso basado en roles a los datos y metadatos de cluster.

Seguridad de la Red

Debido a la naturaleza abierta de Hadoop y las consideraciones de seguridad, la mayoría de los clientes prefieren desplegar su cluster de Hadoop en una subred privada. A continuación, el acceso a los servicios del cluster solo está disponible mediante el uso de nodos de borde, el equilibrio de carga para acceder a IU, API y paneles de control de servicio, o mediante acceso directo a través de VPN o canal SSH de FastConnect a través de un proxy de borde.

Las subredes públicas aumentan el despliegue del cluster para los nodos de posición y de utilidad, que ejecutan servicios orientados a Internet (como Cloudera Manager o Ambari). Esto es totalmente opcional. Puede seleccionar aprovechar la VPN de FastConnect y ejecutar todo el despliegue como una extensión de la topología de red local. De esta manera, se requiere solo un segmento IP privado que el cliente puede enrutar, que está asociado en el nivel de VCN y, luego, se divide en subredes apropiadas de Oracle Cloud Infrastructure. El acceso se controla mediante listas de seguridad, que se aplican en el nivel de subred. La práctica recomendada es agrupar recursos que tienen requisitos de acceso similares en las mismas subredes.

Topología de Subred

VCN cubre un único bloque IPv4 CIDR contiguo que elija. Dentro de VCN, se pueden desplegar subredes individuales de IPv4 para hosts de cluster. El acceso a cada subred se controla mediante listas de seguridad. La seguridad adicional se controla a nivel de host mediante firewalls.

La práctica recomendada es separar los recursos del cluster de Hadoop en una subred privada a la que no se puede acceder directamente desde Internet. El acceso al cluster se debe controlar a través de hosts adicionales en subredes dirigidas al público y se debe proteger mediante las reglas de lista de seguridad adecuadas para gestionar el tráfico entre los segmentos de red pública y privada. Este modelo proporciona la mejor seguridad para el cluster de Hadoop.

Las subredes públicas se pueden utilizar para los nodos de posición (acceso de usuario) y para cualquier servicio que necesite exponer una interfaz de usuario o API (como Cloudera Manager o Ambari) para el acceso externo.
Las subredes privadas se deben utilizar para hosts de cluster (maestro, trabajador) y no se puede acceder directamente desde Internet. En su lugar, necesitan un host intermedio en una subred pública para el acceso, un equilibrador de carga o acceso directo por VPN, FastConnect o proxy SSH.

Listas de Seguridad

Las listas de seguridad controlan el tráfico de entrada y salida a nivel de subred. Para Hadoop, es mejor tener acceso bidireccional sin restricciones entre subredes con hosts de cluster tanto para el tráfico TCP como UDP. Las subredes públicas deben tener listas de seguridad muy restrictivas para permitir sólo puertos de confianza (e incluso direcciones IP de origen) para el acceso a las API y las interfaces de usuario.

Alta Disponibilidad

Hadoop tiene métodos incorporados para alta disponibilidad (HA) y no se cubren aquí. A continuación, se indican las mejores prácticas para aprovechar Oracle Cloud Infrastructure for Hadoop para lograr alta disponibilidad.

Selección de región

Cada región de Oracle Cloud Infrastructure consta de uno a tres dominios de disponibilidad. Cada dominio de disponibilidad consta de tres dominios de errores. Seleccione una región inicial que esté cerca de usted y sus recursos de negocio (como su centro de datos). La composición de la región que elija determina si puede utilizar un despliegue de dominio de única disponibilidad o un despliegue de dominio de varias disponibilidad.

Despliegue de Dominio de Disponibilidad Única

Oracle recomienda un despliegue de dominio de disponibilidad única para despliegues de Hadoop en Oracle Cloud Infrastructure. Para despliegues de MapR, esta arquitectura es la única soportada. Este modelo de despliegue es el más utilizado desde una perspectiva de red, ya que el tráfico entre clusters se incluye en segmentos de red locales, lo que mantiene baja latencia y un alto rendimiento. Los recursos del dominio de disponibilidad se segmentan entre dominios de fallos para lograr la alta disponibilidad de la infraestructura física.

Un dominio de fallos es una agrupación de hardware e infraestructura en un dominio de disponibilidad. Cada dominio de disponibilidad contiene tres dominios de errores. Los dominios de fallos permiten distribuir las instancias de modo que no se encuentren en el mismo hardware físico dentro de un único dominio de disponibilidad. Un fallo de hardware o mantenimiento de hardware de cálculo que afecta a un dominio de fallos no afecta a las instancias de otros dominios de fallos.

Despliegue de Varios Dominios de Disponibilidad

Los despliegues de varios dominios (dominio de disponibilidad por expansión) solo están soportados por Cloudera y Hortonworks, pero también son posibles mediante Apache Hadoop.

Sin embargo, tenga en cuenta las siguientes advertencias a la hora de expandir el dominio de disponibilidad:

La conectividad entre clusters debe recorrer segmentos WAN, lo que aumenta la latencia y reduce el rendimiento global óptimo. Esto tiene un impacto medible en el rendimiento, en especial con nodos de trabajador con hardware dedicado. En el caso de nodos de trabajadores de VM más pequeños, el impacto en el rendimiento es menos perceptible.
No todas las regiones de Oracle Cloud Infrastructure soportan este modelo.

En el siguiente diagrama se muestra el impacto en el rendimiento medido al utilizar 10-TB TeraSort en un único dominio de disponibilidad frente a la expansión del dominio de disponibilidad con un cluster formado por cinco nodos de trabajador y tres nodos maestros:

Descripción de comparison-availability-domain-spanning.png

Descripción de la ilustración comparison-availability-domain-spanning.png

El dominio de disponibilidad que abarca no proporciona redundancia adicional de los servicios de cluster en una sola región. Los recursos del cluster también pueden aprovechar los dominios de fallos en cada dominio de disponibilidad para una “topología del rack” lógica adicional; cada dominio de fallos se considera un “rack” para el conocimiento del rack. Estos beneficios se ilustran con el siguiente diagrama.

Descripción de Architecture e-multiple-availability-domains.png:

Descripción de la ilustración Architecture e-multiple-availability-domains.png

Recuperación ante Desastres

La recuperación ante desastres (DR) en Oracle Cloud Infrastructure depende directamente de los requisitos de Objetivo de punto de recuperación (RPO) y Objetivo de tiempo de recuperación (RTO).

Si el RPO o el RTO están cerca de tiempo real, su única opción para Hadoop es crear un cluster de DR en otro dominio o región de disponibilidad y, a continuación, replicar datos entre la producción y los clusters de DR. Si los requisitos de RPO y RTO son más flexibles, se recomienda aprovechar el almacenamiento de objetos como destino de copia de seguridad para HDFS y los metadatos del cluster. Programe el proceso de copia con la frecuencia necesaria para cumplir su destino de RPO y empuje los datos al almacenamiento de objetos mediante una herramienta como DistCp (copia distribuida). También puede realizar una copia de seguridad de las bases de datos (Oracle, MySQL) en bloques de Object Storage o replicar en instancias de base de datos adicionales en otros dominios o regiones de disponibilidad.

Si los requisitos de DR especifican georedundancia para los datos que no puede proporcionar una sola región, también puede copiar datos en Object Storage entre regiones. Si se produce un desastre, considere utilizar Terraform para aprovisionar rápidamente recursos en otro dominio de disponibilidad (ya sea en la misma región o en otra diferente) y rehidratar el cluster de DR de los datos del almacenamiento de objetos.

Gestión de costos

Como se detalla en el resto de esta solución, existen varias formas de “tamaño derecho” de los recursos informáticos y los requisitos de almacenamiento para reducir los costos de infraestructura. Oracle Cloud Infrastructure tiene herramientas adicionales para ayudarle a gestionar el costo asociado con un despliegue de Hadoop:

Puede utilizar el etiquetado para los despliegues para facilitar el seguimiento del consumo.
Puede definir cuotas en el nivel de compartimiento para limitar el consumo mediante distintas líneas de negocio. Considere el uso de varios compartimentos para gestionar entornos de producción, control de calidad y desarrollo y restrinja las cuotas según corresponda.

La migración de la naturaleza dinámica de la nube también es muy grande para entornos que posiblemente no necesiten ser persistentes. Si utiliza el almacenamiento de objetos como copia de seguridad (o lago de datos) para los datos, es fácil crear entornos cuando los necesite mediante Terraform, rehydrate HDFS con datos de Object Storage y destruir el entorno cuando ya no lo necesite.

Los entornos de VM con volúmenes en bloque también se pueden pausar para detener la facturación de los recursos informáticos y se le cobrará solo para el consumo de almacenamiento.