Solución:
1. El Administrador de clústeres es un servicio de larga duración, ¿en qué nodo se está ejecutando?
Cluster Manager es un proceso maestro en modo autónomo de Spark. Se puede iniciar en cualquier lugar haciendo ./sbin/start-master.sh, en YARN sería Resource Manager.
2. ¿Es posible que los nodos Master y Driver sean la misma máquina? Supongo que debería haber una regla en algún lugar que indique que estos dos nodos deberían ser diferentes.
Master es por racimo, y Driver es por aplicación. Para los clústeres independientes / de hilo, Spark actualmente admite dos modos de implementación.
- En modo cliente, el controlador se inicia en el mismo proceso que el cliente que envía la solicitud..
- En modo cluster, sin embargo, para independiente, el conductor se lanza desde uno de los trabajadores & por hilo, se lanza por dentro nodo maestro de la aplicación y el proceso del cliente finaliza tan pronto como cumple con su responsabilidad de enviar la aplicación sin esperar a que finalice la aplicación.
Si una solicitud enviada con --deploy-mode client en el nodo maestro, ambos El maestro y el controlador estarán en el mismo nodo. comprobar la implementación de la aplicación Spark sobre YARN
3. En caso de que falle el nodo del controlador, ¿quién es el responsable de volver a iniciar la aplicación? ¿Y qué pasará exactamente? es decir, ¿cómo se involucrarán los nodos Master, Cluster Manager y Workers (si lo hacen) y en qué orden?
Si el controlador falla, todas las tareas de los ejecutores serán eliminadas para esa solicitud de chispa enviada / activada.
4. En el caso de que falle el nodo maestro, ¿qué sucederá exactamente y quién es responsable de recuperarse de la falla?
Los fallos del nodo principal se tratan de dos formas.
-
Maestros en espera con ZooKeeper:
Al utilizar ZooKeeper para proporcionar elección de líder y algo de almacenamiento estatal, puede iniciar varios Masters en su clúster conectados a la misma instancia de ZooKeeper. Uno será elegido “líder” y los demás permanecerán en modo de espera. Si el líder actual muere, se elegirá otro Maestro, se recuperará el estado del antiguo Maestro y luego se reanudará la programación. Todo el proceso de recuperación (desde el momento en que cae el primer líder) debería tomar entre 1 y 2 minutos. Tenga en cuenta que este retraso solo afecta la programación de nuevas aplicaciones; las aplicaciones que ya se estaban ejecutando durante la conmutación por error maestra no se ven afectadas. verifique aquí las configuraciones
-
Recuperación de nodo único con sistema de archivos local:
ZooKeeper es la mejor manera de lograr una alta disponibilidad a nivel de producción, pero si desea poder reiniciar el Master si falla, el modo FILESYSTEM puede encargarse de ello. Cuando las aplicaciones y los trabajadores se registran, tienen suficiente estado escrito en el directorio proporcionado para que puedan recuperarse al reiniciar el proceso maestro. marque aquí para conf y más detalles
El Administrador de clústeres es un servicio de larga duración, ¿en qué nodo se está ejecutando?
Un administrador de clúster es solo un administrador de recursos, es decir, CPU y RAM, que SchedulerBackends usa para iniciar tareas. Un administrador de clúster no hace nada más con Apache Spark, pero ofrece recursos, y una vez que los ejecutores de Spark se inician, se comunican directamente con el controlador para ejecutar tareas.
Puede iniciar un servidor maestro independiente ejecutando:
./sbin/start-master.sh
Puede iniciarse en cualquier lugar.
Para ejecutar una aplicación en el clúster de Spark
./bin/spark-shell --master spark://IP:PORT
¿Es posible que los nodos Master y Driver sean la misma máquina? Supongo que debería haber una regla en algún lugar que indique que estos dos nodos deberían ser diferentes.
En modo autónomo, cuando inicie su máquina, se iniciará cierta JVM. Su SparK Master se iniciará y en cada máquina se iniciará Worker JVM y se registrarán con Spark Master. Ambos son el administrador de recursos. Cuando inicie su aplicación o envíe su aplicación en modo de clúster, un controlador se iniciará donde quiera que haga ssh para iniciar esa aplicación. El controlador JVM se pondrá en contacto con el SparK Master para ejecutores (Ex) y, en modo autónomo, el trabajador iniciará el Ex. Entonces Spark Master es por clúster y Driver JVM es por aplicación.
En caso de que falle el nodo del controlador, ¿quién es el responsable de reiniciar la aplicación? y que pasará exactamente? es decir, ¿cómo se involucrarán los nodos Master, Cluster Manager y Workers (si lo hacen) y en qué orden?
Si una Ex JVM falla, Worker JVM iniciará Ex y cuando Worker JVM falla, Spark Master las iniciará. Y con un clúster independiente de Spark con modo de implementación de clúster, también puede especificar –supervisar para asegurarse de que el controlador se reinicie automáticamente si falla con un código de salida distinto de cero. Spark Master iniciará Driver JVM
De manera similar a la pregunta anterior: en caso de que falle el nodo maestro, ¿qué pasará exactamente y quién es el responsable de recuperarse de la falla?
fallar en el maestro resultará en que los ejecutores no puedan comunicarse con él. Entonces, dejarán de funcionar. Si falla el maestro, el conductor no podrá comunicarse con él para conocer el estado del trabajo. Entonces, su aplicación fallará. La pérdida maestra será reconocida por las aplicaciones en ejecución, pero de lo contrario, estas deberían continuar funcionando más o menos como si nada hubiera sucedido con dos excepciones importantes:
1.La aplicación no podrá terminar de manera elegante.
2.Si Spark Master está inactivo, Worker intentará volver a registrarse conWithMaster. Si esto falla varias veces, los trabajadores simplemente se rendirán.
reregisterWithMaster (): vuelva a registrarse con el maestro activo con el que este trabajador se ha estado comunicando. Si no hay ninguno, significa que este trabajador todavía está realizando el arranque y aún no ha establecido una conexión con un maestro, en cuyo caso deberíamos volver a registrarnos con todos los maestros. Es importante volver a registrarse solo con el maestro activo durante las fallas. El trabajador intenta incondicionalmente volver a registrarse con todos los maestros, puede surgir una condición de carrera. Error detallado en SPARK-4592:
En este momento, las aplicaciones de ejecución prolongada no podrán continuar con el procesamiento, pero aún así no deberían provocar una falla inmediata. En su lugar, la aplicación esperará a que un maestro vuelva a estar en línea (recuperación del sistema de archivos) o un contacto de un nuevo líder (modo Zookeeper), y si eso sucede, continuará procesando.