Descripción
La construcción del modo HDFS-HA se basa en la construcción completamente distribuida anterior. Para la construcción completamente distribuida, consulte el contenido anterior:
Preparación del entorno de instalación de Hadoop y análisis de conocimientos relacionados
Análisis preliminar de instalación distribuida y configuración de hadoop (imparable)
En términos generales, se divide a grandes rasgos en las siguientes partes:
JDK安装和JAVA_HOME配置
HOSTS映射
SSH免密登陆设置
HADOOP配置文件修改
配置HADOOP_HOME
初始化（格式化）
启动验证
Los módulos propios del proyecto hadoop que se mencionan a menudo son yarn, hdfs y mapreduce. Tanto hdfs como yarn se pueden construir como de alta disponibilidad (HA). Este artículo primero presenta solo la compilación HA de hdfs.
Planificación de máquinas
Los modos totalmente distribuido y HA no solo son diferentes en la configuración, sino también en los procesos que se inician después de la ejecución. Las máquinas y los procesos principales totalmente distribuidos anteriores son aproximadamente los siguientes
Totalmente distribuido
| anfitrión | nomenode | nodo de datos | administrador de recursos | nodeManager | secundarioNombreNodo |
|---|---|---|---|---|---|
| 192.168.139.9 maestro | ● | ● | ● | ||
| 192.168.139.19node01 | ● | ● | |||
| 192.168.139.29node02 | ● | ● |
Modo HA
En comparación con el modo completamente distribuido, HA ha agregado ZOOKEEPER, ZKFC y JOURNALNODE, pero sin el nodo de nombre secundario, el proceso y la distribución de nodos del modo HA después de ser construido o planificado es el siguiente:
| anfitrión | nomenode | nodo de datos | journalnode | zkfc | zk | nodeManager | administrador de recursos |
|---|---|---|---|---|---|---|---|
| 192.168.139.9 maestro |
● | ● | ● | ● | |||
| 192.168.139.19 nodo01 |
● | ● | ● | ● | |||
| 192.168.139.29 nodo02 |
● | ● | ● | ● | |||
| 192.168.139.39 nodo03 |
● | ● | ● | ● |
Cabe señalar que el ResourceManager aquí está en el nodo activo, no existen dos namenodes al mismo tiempo.
Comprensión de HDFS-HA
En el modo totalmente distribuido, solo hay un nodo de nombre y varios nodos de datos. El nodo de nombre se utiliza para administrar los datos de origen del nodo de datos. Una vez que falla el nodo de nombre, los hdfs completos no estarán disponibles.
Por lo tanto, el modo HA de HDFS mencionado aquí, mi entendimiento personal es en realidad el HA del namenode, agregando un modo maestro-esclavo al namenode, agregando failover y conmutación automática maestro-esclavo, ya sea el middleware zookeeper recién agregado o el proceso journalnode recién agregado, su La función principal es garantizar la alta disponibilidad del nodo de nombre, de modo que todo el nodo activo pueda seguir proporcionando servicios normales después de una falla.
Preparación básica del entorno
Como se puede ver en la tabla anterior, en comparación con el sistema completamente distribuido, he agregado otra máquina aquí, principalmente porque me temo que las tres no podrán soportarlo.
Entonces, la preparación del entorno básico aquí en realidad se refiere a la máquina recién agregada, porque el entorno básico es universal, es decir, jkd, ssh y mapeo de hosts. Para operaciones específicas, consulte el contenido de los dos blogs enumerados al principio.
Configuración
En el modo totalmente distribuido anterior, se configuró una gran cantidad de contenido, como hdfs-site.xml, hadoop-env.sh, core-site.xml, trabajadores, etc. Esta vez, la construcción del modo HA solo necesita modificar hdfs-site.xml , Hadoop-env.sh, core-site.xml estos tres.
hdfs-site.xml
Se dice que hadoop3.x puede admitir hasta 5 nodos de nombre, pero debido a los recursos limitados de la computadora, solo se usan dos. En la siguiente configuración, se divide principalmente en cuatro secciones, y la configuración general es la siguiente:
<!--1-->
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>master:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>node03:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>master:9870</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>node03:9870</value>
</property>
<!--2-->
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://master:8485;node01:8485;node02:8485/mycluster<
/value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/root/soft/bigdata/journal/data</value>
</property>
<!--3-->
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_rsa</value>
</property>
<!--4-->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
La primera parte anterior es configurar el cluster namenode, especificando el nombre del cluster, el nombre del nodo y el host del nodo. Los dos primeros se pueden personalizar.
La segunda parte especifica la máquina y el directorio de almacenamiento local donde se encuentra el nodo journalnode. Después de iniciar el journalnode, se iniciará el nodo configurado aquí, y los datos correspondientes también se almacenarán en el directorio especificado.
La tercera parte especifica la clase y el método del agente de conmutación de roles de HA; aquí se utiliza el método sin ssh.
La cuarta parte es configurar la automatización HA, que en realidad es ZKFC.
core-site.xml
La configuración de core-site es mucho más simple que la de HDFS. La configuración es la siguiente:
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>node01:2181,node02:2181,node03:2181</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/opt/hadoop/hadoopdata</value>
</property>
En el modo totalmente distribuido, la primera configuración es el nombre de host o la IP de una máquina específica. En el modo HA, debe modificarse al nombre del clúster namenode definido anteriormente. Aunque el nombre específico se puede personalizar, se configura aquí. Las necesidades son las mismas que las anteriores.
El segundo elemento es especificar el nodo del clúster guardián del zoológico y el tercer elemento es el modo totalmente distribuido anterior.
hadoop-env.sh
Parece que este archivo no se menciona en muchos lugares de Internet, pero la operación real encontró que si este archivo no está configurado, fallará al inicio.
En modo totalmente distribuido, además de JAVA_HOME configurado en este archivo, también se configura el siguiente contenido:
export HDFS_NAMENODE_USER=root
export HDFS_DATANODE_USER=root
export HDFS_SECONDARYNAMENODE=root
Ahora que journalnode y zkfc se agregaron recientemente, la siguiente configuración debe agregarse de manera similar:
HDFS_JOURNALNODE_USER=root
HDFS_ZKFC_USER=root
En este punto, la configuración del HDFS en sí en modo HA está completa, pero puede ver que se necesita zookeeper arriba, y completamente distribuido no tiene esto, por lo que primero debe instalar zookeeper en los nodos planificados.
Zookeeper construye y comienza
Primero obtenga el paquete de instalación, puede obtener la última versión del sitio web oficial, la dirección es la siguiente:
https://downloads.apache.org/zookeeper/current/
Luego use tar para descomprimir, los pasos específicos no se repetirán. Una vez completada la descompresión, debe cambiar el nombre del archivo zoo_sample.cfg en el directorio conf del directorio de instalación a zoo.cfg y luego modificar este archivo.
modificación zoo.cfg
En primer lugar, hay un archivo predeterminado en este archivo, dataDirque es el directorio temporal del sistema Linux configurado como hadoop al principio. Este directorio necesita ser modificado a un directorio no temporal, por ejemplo, lo modifiqué aquí /root/soft/bigdata/zookeeper/data.
Luego, debe configurar cada nodo del clúster del guardián del zoológico. Por ejemplo, mi configuración aquí es la siguiente:
server.1=node01:2888:3888
server.2=node02:2888:3888
server.3=node03:2888:3888
El número detrás del servidor anterior no tiene por qué ser el mismo que aquí, puede entenderse como un peso para la elección del propio cuidador del zoológico.
Seguido de dos números de puerto, uno es el puerto que se utiliza para la comunicación mutua cuando hay un maestro o líder, y el otro es el número de puerto que se usa para la comunicación sin un maestro.
mi identificación
Con la configuración anterior, también debe agregar un archivo de peso en el directorio de datos de zookeeper, escribir el valor de peso configurado anteriormente en este archivo y proporcionarlo al zookeeper para que lo lea.
Por ejemplo, /root/soft/bigdata/zookeeper/datarealizo las siguientes operaciones en node01 aquí :
echo 1 > myid
Realice las /root/soft/bigdata/zookeeper/datasiguientes operaciones en node02 :
echo 2 > myid
Del mismo modo, /root/soft/bigdata/zookeeper/datarealice las siguientes operaciones en el nodo03 :
echo 3 > myid
variables de entorno del guardián del zoológico
Antes de instalar jdk, redis o hadoop han configurado sus propias variables de entorno, el propósito es ejecutar fácilmente los comandos correspondientes en cualquier directorio y realizar las operaciones correspondientes, lo mismo ocurre con Zookeepere, lo mejor es configurar las variables de entorno. .
Inicio y verificación
Además de las variables de entorno, el paquete de instalación y la configuración propios de hadoop se pueden operar en una sola máquina, y luego deben distribuirse o copiarse en otras dos máquinas, y luego las variables de entorno se configuran a su vez, el clúster de zookeeper se puede iniciar y verificar. estado.
zkServer.sh startSe puede iniciar el servicio de zkServer.sh statuscuidador del zoológico y se puede ver el estado de ejecución del cuidador del zoológico.
Cuando ejecutamos start en una máquina ahora, veremos la pantalla inmediatamente con el estado not running, y podremos psver el proceso del guardián del zoológico cuando lo usemos . La razón es que cuando solo hay un guardián del zoológico, las elecciones no son posibles, por lo que hay procesos que no pueden brindar servicios.
Cuando inicie otro, verá que el que tiene el valor de peso más grande se convertirá leadery el valor de peso más pequeño será follower. Después de que se inicien los tres, habrá un líder y dos seguidores.
Inicialización e inicio de HDFS en modo HA
Como se mencionó anteriormente, namenode realmente administra datanode, mientras que zookeeper y journalnode funcionan para mejorar la disponibilidad de namenode, que puede considerarse simplemente como una administración de namenode.
Entonces, la situación normal es que el namenode se ejecute antes que el datanode, y zookeeper y journalnode deben ejecutarse antes que el namenode. Por lo tanto, después de que el clúster del guardián del zoológico se esté ejecutando normalmente, journalnode debe iniciarse nuevamente:
hadoop-daemon.sh start journalnode
Debido a que es una reconstrucción, debe inicializarse como un sistema completamente distribuido. Como dije antes, la función de esta inicialización es borrar los datos originales y luego crear algunos archivos nuevos. Normalmente, estas dos operaciones solo deben realizarse cuando el entorno está configurado. Una vez, de hecho, incluso debería deshabilitarse. La operación de formateo es la siguiente:
hdfs namenode -format
La comunicación del clúster de nombre maestro-esclavo debe basarse en la misma identificación de clúster, y la operación de inicialización anterior generará una identificación de clúster, por lo que otro nodo de nombre de nodo también debe almacenar la misma información de identificación, que debe sincronizarse desde arriba, y se requiere el nombre de nodo superior antes de pasar. Ejecútelo primero:
hadoop-daemon.sh start namenode
Luego está la sincronización.Para la operación anterior, operaré en el nodo maestro, es decir, uno de los nodos namenode planificados, por lo que las siguientes operaciones requieren otro nodo namenode, como node03:
hdfs namenode -bootstrapStandby
Después de sincronizar la configuración de namenode, es necesario inicializarla nuevamente para ZKFCconectar el namenode y el zookeeper.Esta operación también está en el nodo namenode al principio, como la máquina maestra aquí.
hdfs zkfc -formatZK
Después de las operaciones anteriores, la configuración básica está completa y luego ejecute el comando hdfs start en el nodo namenode activo para comenzar:
start-dfs.sh
Por lo menos, después de que se complete el inicio, puede usar los comandos relacionados con hdfs para agregar, eliminar, modificar y verificar archivos.
Si desea detenerse en este momento, puede detener uno por uno, o puede usar el stop-all.shcomando para detener namenode, journalnode, etc. directamente . Zookeeper está separado, por lo que aún necesita operarlo por separado.
Si necesita iniciar el clúster HDFS en modo HA más adelante, también puede usarlo directamente start-all.shpara iniciarlo.
Verificación HA
Al principio, dije que el propósito de HA es en realidad resolver el problema del punto único de falla del nodo de nombre, por lo que se requiere una verificación de selección maestra automática, es decir, cuando se determina que un nodo de nombre está activo, no está disponible, y luego ver si el otro puede ser normal y automático. Conviértete en activi.
Hay dos formas de ver qué namenode está activo. Una es acceder a la interfaz web, es decir, la dfs.namenode.http-addressconfiguración en hdfs-site.xml . Por ejemplo, he configurado master:9870y node03:9870, cuando el navegador visita, puedes ver cuál está activo. .
El otro está en zookeeper, puede usarlo para zkCli.shingresar a la interfaz de operación del cliente que viene con zookeeper, y luego usar get para obtener qué nodo tiene actualmente el bloqueo. Por ejemplo, el cluster namenode que configuré se llama mycluster, luego mi comando para consultar el estado del bloqueo es:
get /hadoop-ha/mycluster/ActiveStandbyElectorLock
El comando anterior también puede ver qué nodo tiene el bloqueo. Si conoce el nodo activo actual, puede usarlo hadoop-daemon.sh stop namenodepara detener este nodo de nombre, y luego observar si el otro se activará automáticamente, si cambia, y todo el servicio hdfs Si se usa normalmente, puede probar que el modo HA se construyó básicamente con éxito.