Consideraciones sobre el rendimiento y la forma
Existen consideraciones importantes de precio y rendimiento para ejecutar Hadoop en Oracle Cloud Infrastructure. También debe tener en cuenta cómo afectan sus requisitos a las formas de despliegue.
Análisis Comparativo
Oracle Cloud Infrastructure ofrece ventajas de rendimiento y costo para empresas interesadas en ejecutar clusters de Hadoop en Oracle Cloud.
TeraSort es una referencia común para Hadoop porque aprovecha todos los elementos del cluster (recursos informáticos, memoria, almacenamiento, red) para generar, asignar/reducir y validar un juego de datos aleatorio.
Un análisis comparativo normaliza clusters de Oracle Cloud Infrastructure con 300 OCPU y volúmenes de bloques utilizados para el almacenamiento HDFS. Ese análisis concreto ha detectado que Oracle Cloud Infrastructure ha ejecutado tres veces más rápido y proporcionado un costo menor del 80% que un despliegue adicional en la nube de un competidor.
En el siguiente gráfico se muestra el rendimiento general de las distintas formas de Oracle Cloud Infrastructure al ejecutar este TeraSort de 10TB con el tamaño de cluster normalizado:
Descripción de la ilustración comparison-terasort-phase-cpu.png
Oracle Cloud Infrastructure proporciona instancias de recursos informáticos con hardware dedicado estándar con CPU de Intel y AMD, además de una opción de HPC especializada. Como muestra el gráfico, los clusters de HPC especializados se ejecutan más rápido que los equivalentes de Intel y AMD, aunque estas instancias tengan recuentos de núcleos más bajos. Este resultado se produce principalmente porque este cluster utiliza más nodos para lograr el mismo recuento de OCPU normalizadas, que directamente afecta al rendimiento global de agregados de HDFS, aumentando el rendimiento.
Las unidades de HPC también se benefician de una capacidad de red 100-GBps, que permite una transferencia de datos dentro del cluster más rápida.
En la siguiente figura, se compara el rendimiento de los trabajadores basados en VM con volúmenes en bloque y con hardware dedicado NVMe, que ejecutan Cloudera y normalizados con 10 nodos de trabajador en el cluster:
Descripción de la ilustración comparison-terasort-vm-bm-performance.png
El rendimiento aprovecha la recopilación de tamaño de VM de trabajador de 8 a 16 núcleos es aproximadamente dos veces más eficaz, lo que tiene sentido porque el rendimiento global de red de VM es un recurso compartido fraccional de la NIC física subyacente. Las ventajas del hardware dedicado con NVMe local también son aparentes. El cluster aprovecha la alta velocidad del almacenamiento local de NVMe combinado con la interfaz de red 25-Gbps.
La determinación de qué formas utilizar para los recursos informáticos de un cluster de Hadoop es coherente entre los ISV de Hadoop.
Selección de Instancia de Cálculo
En esta sección, se proporcionan las mejores prácticas para seleccionar una forma para cada rol de nodo.
Nodos Maestros
Los nodos maestros solo son aplicables a distribuciones de Cloudera, Hortonworks y Apache Hadoop. Por defecto, MapR no separa los servicios del cluster de los nodos del trabajador. En la práctica, Oracle recomienda utilizar una buena densidad de memoria en los nodos maestros para soportar la sobrecarga de la gestión de cluster y servicio. Los nodos maestros ejecutan servicios de Zookeeper, NameNode, JournalNode, Resource Manager, HBase, Spark y gestión de cluster (Cloudera Manager y Ambari).
- Forma mínima: VM.Standard2.8
- Forma recomendada: VM.Standard2.24
Nodos de trabajador
Los nodos de trabajador son consistentes entre todos los ISV de Hadoop y Apache. Escala la forma del nodo de trabajador según corresponda para cumplir los requisitos de la carga de trabajo. Esto se aplica tanto para los requisitos de cálculo como para la memoria porque muchos clientes buscan memoria agregada para utilizar con cargas de trabajo basadas en Spark. El mapa tradicional/reducción de cargas de trabajo también se beneficia de una mayor huella de memoria en los nodos trabajadores.
- Forma mínima: VM.Standard2.8
- Forma recomendada: BM.DenseIO2.52
Nodos de compatibilidad
La infraestructura de soporte incluye nodos de borde u otros nodos que pueden estar ejecutando servicios de cluster complementarios o código de aplicación personalizado. Los requisitos para estos nodos varían según la escala y el caso de uso. Para los nodos de posición, se recomienda un tamaño mínimo de VM.Standard2.2. Amplíe esta opción en función del número de usuarios por nodo de borde. Recomendamos varios nodos de borde para alta disponibilidad entre dominios de fallos y para crear varias rutas de acceso para que los usuarios interactúen con el cluster.
Consideraciones para las redes
Hadoop depende mucho de la red para tráfico dentro del cluster. Como tal, las formas seleccionadas para desplegar para cada rol en la topología de cluster tienen un impacto directo en la conectividad dentro del cluster.
Cuando se utilizan unidades con hardware dedicado, los hosts de recursos informáticos pueden usar tarjetas de interfaz de red virtual de 25-GB completas (VNIC). Las unidades de máquina virtual se ajustan en relación con su tamaño de cálculo.
Si utiliza volúmenes en bloque para la capacidad HDFS, recuerde que el tráfico de E/S de un volumen en bloque comparte la misma VNIC que el tráfico de aplicaciones (por defecto). Una forma de optimizar esto al usar las unidades con hardware dedicado es crear una VNIC secundaria para utilizarla con la conectividad de cluster en la segunda interfaz física. De esta manera, se reserva la VNIC principal para solamente el tráfico de volúmenes de bloques, lo que optimiza el uso de la red.
En el diagrama siguiente se muestra este concepto:
Descripción de la ilustración Architecture e-vnic.png
Al utilizar volúmenes en bloque, tenga en cuenta que la E/S de HDFS agregado está directamente relacionada con la cantidad y el tamaño de los volúmenes en bloque asociados a cada nodo de trabajador. Para lograr la capacidad necesaria de HDFS, Oracle recomienda escalar un número mayor de volúmenes por trabajador en lugar de un pequeño número de volúmenes más grandes.
Consideraciones de almacenamiento
Para despliegues de Hadoop, se pueden utilizar dos tipos de almacenamiento para la capacidad de HDFS: formas de DenseIO con NVMe local y volúmenes en bloque. Para los despliegues de MapR, se debe elegir un único tipo de almacenamiento para los nodos de trabajadores (homogéneos), a menos que tenga licencia para los niveles de datos. Otros ISV de Hadoop admiten almacenamiento heterogéneo (mezclando DenseIO NVMe y bloques) sin costes adicionales de licencia.
Configuraciones de almacenamiento admitidas por el proveedor
Cloudera y Hortonworks soportan todas las formas de almacenamiento en Oracle Cloud Infrastructure para su uso con Hadoop:
- NVMe local en unidades de DenseIO
- Volúmenes en bloque
- Almacenamiento de objetos (uso de la compatibilidad de S3)
Cloudera soporta el archivado de niveles de datos (almacenamiento heterogéneo) para despliegues que constan de NVMe local y volúmenes en bloque para HDFS.
Los despliegues de MapR pueden aprovechar NVMe local en unidades DenseIO o volúmenes en bloque para el despliegue.
- Almacenamiento de objetos: consulte MapR XD Object Tiering.
- MapR no admite almacenamiento heterogéneo sin licencia adicional.
DenseIO NVMe
DenseIO NVMe es la opción de almacenamiento más rendimiento para Hadoop en Oracle Cloud Infrastructure. Las unidades de NVMe locales de alta velocidad para usar con HDFS están disponibles en unidades de máquina virtual y con hardware dedicado.
Al utilizar NVMe local, Oracle recomienda configurar la replicación de DFS en tres réplicas para garantizar la redundancia de los datos.
Como alternativa, para los clusters de Cloudera, considere la posibilidad de utilizar la codificación de borrado para aumentar la eficiencia de almacenamiento para tipos de datos concretos.
Volúmenes en bloque
Los volúmenes en bloque de Oracle Cloud Infrastructure son una opción de alto rendimiento y proporcionan una configuración flexible para la capacidad de HDFS. Los volúmenes en bloque son un almacenamiento asociado a la red y, por ejemplo, utilizan ancho de banda VNIC para E/S. Los volúmenes en bloque también se escalan en IOPS y MB/s según su tamaño configurado (por GB). Rendimiento global de volúmenes en bloque individuales máximo a 320 MB/s para 700GB o volúmenes más grandes.
En la siguiente tabla, se muestra el ajuste del rendimiento de un solo nodo de trabajador con volúmenes 700GB:
| Volúmenes en bloque | Rendimiento global agregado (GB/s) |
|---|---|
| 3 | 0.94 |
| 4 | 1.25 |
| 5 | 1.56 |
| 6 | 1.88 |
| 7 | 2.19 |
| 8 | 2.50 |
| 9 | 2.81 |
| 10 | 3.13 |
| 11 | 3.44 |
Oracle lo ha detectado que, después de 11 volúmenes en bloque, al agregar volúmenes en bloque adicionales, disminuye el rendimiento.
Cuando utiliza máquinas virtuales como trabajadores, recuerde que el tráfico de volúmenes de bloques comparte la misma VNIC que el tráfico de Hadoop (aplicación). En la siguiente tabla, se muestran los volúmenes de bloques máximos recomendados y el ancho de banda de VNIC medido para una selección de unidades Oracle Cloud Infrastructure, lo que permite que las instancias tengan suficiente ancho de banda adicional para soportar el tráfico de aplicaciones sobre la E/S de disco:
| Forma Oracle Cloud Infrastructure | Ancho de banda de VNIC | Volúmenes en bloque máximos sugeridos para HDFS |
|---|---|---|
| BM.DenseIO2.52 | 25Gbps | 11 |
| BM.Standard2.52 | 25Gbps | 11 |
| VM.Standard2.24 | 24.6Gbps | 6 |
| VM.Standard2.16 | 16.4Gbps | 4 |
| VM.Standard2.8 | 8.2Gbps | 3 |
Al utilizar volúmenes en bloque para la capacidad de HDFS, se recomienda utilizar un número mayor de volúmenes en bloque pequeños en lugar de un número menor de volúmenes en bloque grandes por trabajador para lograr la capacidad de destino de HDFS.
Con el mínimo de tres nodos de trabajador como ejemplo, con el tamaño de volumen en bloque 700GB para HDFS:
Descripción de la ilustración block-volume-hdfs-capacity-chart.png
Tenga en cuenta que tres volúmenes en bloque por trabajador son los requisitos mínimos. Oracle recomienda escalar la cantidad y el tamaño del volumen en bloque para optimizar la capacidad de HDFS necesaria, sabiendo que más volúmenes en bloque por trabajador aumenta el ancho de banda global de HDFS agregado disponible. Esto es especialmente importante para cargas de trabajo grandes de alto rendimiento, que requieren una mayor E/S agregada en el cluster.
También es importante que los clusters persistentes dejen una mayor sobrecarga para el crecimiento o la refactorización.
Registro y Datos de Aplicación
Si utiliza volúmenes en bloque para HDFS, debe reservar algunos volúmenes en bloque para utilizarlos con los logs y los datos de la aplicación de Hadoop (Cloudera Parcels, NameNode y metadatos del asiento). Aunque el volumen del sistema operativo se puede ampliar para incluir estos datos, es mejor utilizar volúmenes de bloques dedicados para este propósito. Los volúmenes en bloque le proporcionan más portabilidad si desea cambiar el tipo de instancia de los nodos maestros y más flexibilidad si necesita más rendimiento de E/S para una ubicación de datos concreta. La agregación de varios volúmenes en bloque a la instancia, la creación de una matriz RAID y la migración de los datos existentes es más sencilla cuando tiene anexos de volúmenes de repuesto para utilizar.
Lo mismo es verdadero para HDFS. Tener una sobrecarga para agregar más volúmenes en bloque puede ser más fácil que retirar a los trabajadores, regenerarlos con discos más grandes, volver a agregarlos al cluster y volver a equilibrar HDFS. Ambos enfoques son válidos; es tan solo cierto si la carga de trabajo del cluster requiere un complemento completo de los volúmenes en bloque para soportar el rendimiento de los datos. Si ese es el caso, considere el cambio de los trabajadores a unidades de E/S densa con hardware dedicado con un almacenamiento rápido de NVMe y mediante un modelo de almacenamiento heterogéneo con distintos niveles de datos.
Almacenamiento de objetos
Es posible la integración del almacenamiento de objetos con todas las ISV de Hadoop, incluido Apache Hadoop. Oracle Cloud Infrastructure tiene un conector HDFS nativo compatible con Apache Hadoop. Hadoop ISV (Cloudera, Hortonworks y MapR) muestra los puntos finales externos permitidos para la integración de Object Storage y necesita que la compatibilidad de S3 con la integración de Object Storage funcione correctamente.
Una excepción es que la compatibilidad de S3 solo funciona con la región de inicio de arrendamiento. Esto significa que para cualquier integración realizada con el almacenamiento de objetos, los clusters de Hadoop también se deben desplegar en la misma región (directorio raíz).
Otra excepción es que cuando utiliza Object Storage para transferir o extraer datos del cluster, HDFS no se utiliza como capa de almacenamiento en caché. De hecho, el sistema de archivos del sistema operativo es donde se almacenan los datos en caché como transacciones entre Object Storage y HDFS. Si un gran volumen de datos se mueve hacia atrás y hacia adelante entre el cluster HDFS y el almacenamiento de objetos, se recomienda crear una capa de almacenamiento en caché de volúmenes en bloque en el sistema operativo para soportar este movimiento de datos.
En la siguiente figura, se muestra un diagrama de partición típico para admitir el movimiento de datos de S3, junto con los niveles de datos para nodos de trabajador.
Descripción de la ilustración object-storage-partitioning-throughput.png
Capa de datos
Puede combinar todas las opciones de almacenamiento anteriores cuando usa el modelo de almacenamiento Apache Hadoop, Cloudera o Hortonworks para crear un sólido de almacenamiento de almacenamiento (heterogéneo). También puede utilizar la gestión del ciclo de vida de los datos para enviar datos de una capa de almacenamiento a otra como argumentos, con el fin de optimizar los costos de almacenamiento HDFS.
Descripción de la ilustración data-lifecycle-tiering.png
Codificación del Rendimiento
A partir de Hadoop 3.0, la codificación de borrado (EC) está soportada en despliegues de HDFS. EC reduce los requisitos de almacenamiento de los datos de HDFS locales almacenando datos con una sola copia aumentada por celdas de paridad. La topología de HDFS se puede etiquetar como EC, que permite esta funcionalidad para cualquier dato almacenado en esa ubicación etiquetada. Esto reduce eficazmente el requisito de almacenamiento sin formato para datos HDFS etiquetados con ECS, lo que permite una mayor eficacia del almacenamiento.
Existen advertencias sobre EC:
- Se requiere un recuento mínimo de nodos de trabajador para activar EC.
- La localidad de datos se pierde para los datos etiquetados de la EC.
- El EC es adecuado para los archivos con tamaño mediano a los que se accede de forma poco frecuente. Es ineficaz para archivos pequeños y para los archivos a los que se accede con frecuencia.
- EC aumenta el número de objetos de bloque presentes en los metadatos del nodo de nombre en comparación con datos similares con la replicación tradicional (3x).
- La recuperación de datos de EC requiere recursos informáticos del cluster (reconstrucción de paridad). Este tiempo de recuperación es más largo que los datos replicados tradicionales (3x).
Supervisión del Rendimiento
El servicio Oracle Cloud Infrastructure Monitoring le permite supervisar de forma activa y pasiva los recursos en la nube mediante las funciones de métricas y alarmas. La definición de alarmas para notificar cuando se cumplen los umbrales de rendimiento o capacidad es una gran manera de aprovechar las herramientas nativas de Oracle Cloud Infrastructure para gestionar la infraestructura
Arquitecturas de Referencia
En este tema se proporciona material de referencia para cada ISV de Hadoop. Las siguientes arquitecturas de referencia y listas de materiales reflejan una huella mínima necesaria para el despliegue soportado por el proveedor de Hadoop en Oracle Cloud Infrastructure.
Como proyecto de código abierto, el despliegue de Apache Hadoop no tiene una huella mínima necesaria proporcionada por el proveedor. Oracle recomienda utilizar el despliegue de Hortonworks que se muestra aquí como una guía razonable para un despliegue de Apache mínimo.
Cloudera
Descripción de la ilustración Architecture e-cloudera.png
Los requisitos mínimos para el despliegue de Hadoop con Cloudera son:
| Rol | Cantidad | Forma de cálculo recomendada |
|---|---|---|
| Posición | 1 | VM.Standard2.4 |
| Cloudera Manager | 1 | VM.Standard2.16 |
| Nodo Maestro | 2 | VM.Standard2.16 |
| Nodo de trabajador | 3 | BM.DenselO2.52 |
En este despliegue mínimo, el nodo de Cloudera Manager también ejecuta servicios maestros.
Debe traer su propia licencia para desplegar Cloudera en Oracle Cloud Infrastructure; todo el soporte de software se realiza a través de Cloudera.
Hortonworks
Descripción de la ilustración Architecture e-hortonworks.png
Los requisitos mínimos para el despliegue de Hadoop mediante Hortonworks son:
| Rol | Cantidad | Forma de cálculo recomendada |
|---|---|---|
| Posición | 1 | VM.Standard2.4 |
| Ambari | 1 | VM.Standard2.16 |
| Nodo Maestro | 2 | VM.Standard2.16 |
| Nodo de trabajador | 3 | BM.DenselO2.52 |
En este despliegue mínimo, el nodo Ambari también ejecuta servicios maestros.
Debe traer su propia licencia para desplegar Hortonworks en Oracle Cloud Infrastructure; todo soporte de software mediante Hortonworks.
MapR
Descripción de la ilustración Architecture e-mapr.png
Los requisitos mínimos para el despliegue de Hadoop mediante MapR son:
| Rol | Cantidad | Forma de cálculo recomendada |
|---|---|---|
| Posición | 1 | VM.Standard2.4 |
| Nodo de Datos | 3 | BM.DenselO2.52 |
Debe llevar su propia licencia para desplegar MapR en Oracle Cloud Infrastructure; toda la compatibilidad de software se realiza mediante MapR.
Despliegues de Terraform
Puede encontrar plantillas de Terraform para cada ISV de Hadoop en la sección Código de descarga de esta solución.
Los repositorios de Cloudera y Hortonworks tienen plantillas compatibles con Oracle Resource Manager. Tenga en cuenta que son específicos del gestor de recursos. La bifurcación base (maestra) contiene una plantilla de Terraform autónoma. Las plantillas del gestor de recursos para Cloudera y Hortonworks también contienen un esquema YAML que rellena fácilmente las variables Terraform para cada plantilla. Esto proporciona una selección de interfaz de usuario desplegable para las variables, que puede personalizar para los casos de uso, básicamente llenando cada plantilla con opciones de forma permisibles y valores de seguridad/configuración.