本地运行Spark Standalone - II

接下来我们将在：

master运行: Spark的Master进程

worker1运行: spark的1个worker进程

Worker2运行: spark的1个worker进程

先将上面master节点的spark-shell停掉，然后进入sbin目录运行start-master.sh:

image-20240218223135221

访问master节点的8080端口，能看到master节点的url，将其复制下来：

image-20240218223247230

登录到worker1, 运行start-slave.sh:

 cd spark-3.5.0-bin-hadoop3/sbin/
./start-slave.sh spark://<<hostname/ipaddress>>:7077

image-20240218223714813

刷新master节点的8080 URL，看到新注册的节点：

image-20240218224112668

同样操作，登录到worker2节点，运行start-slave.sh。再次刷新页面，看到有两个worker节点注册到上面去：

image-20240218224331078

分别以cluster/client模式运行spark应用

以client模式运行spark应用：

cd ~/spark-3.5.0-bin-hadoop3/
./bin/spark-submit --class org.apache.spark.examples.SparkPi --master spark://ip-172-31-45-168.us-west-2.compute.internal:7077 --deploy-mode client ./examples/jars/spark-examples_*.jar 5

client模式下，日志会输出到控制台：

image-20240218224859766

在最后看到了Pi的计算结果：

image-20240218224718283

以cluster模式运行spark应用：

cd ~/spark-3.5.0-bin-hadoop3/
./bin/spark-submit --class org.apache.spark.examples.SparkPi --master spark://ip-172-31-45-168.us-west-2.compute.internal:7077 --deploy-mode cluster --driver-java-options "--add-exports java.base/sun.nio.ch=ALL-UNNAMED"  ./examples/jars/spark-examples_*.jar 5

注意多加了--driver-java-options "--add-exports java.base/sun.nio.ch=ALL-UNNAMED"参数，是因为java 17有bug： https://stackoverflow.com/questions/72724816/running-unit-tests-with-spark-3-3-0-on-java-17-fails-with-illegalaccesserror-cl

此时输出需要到driver的日志来看：

image-20240219000229101

刷新URL，看到完成的application：

image-20240218225303181

Stand Alone HA模式

Spark Standalone集群是Master-Slaves架构的集群模式，和大部分的Master-Slaves结构集群一样，存在着Master单点故障的问题。一旦Master节点宕机，就没有进程处理集群资源的规划，资源无法进行规划，那么集群就无法获得资源。

解决方式：Spark提供了两种方案

1.基于文件系统的单点恢复(Single-Node Recovery with Local File System)–只能用于开发或测试环境。

2.基于zookeeper的Standby Masters(Standby Masters with ZooKeeper)—-可以用于生产环境。

ZooKeeper提供了一个Leader Election机制，利用这个机制可以保证虽然集群存在多个Master，但是只有一个是Active的，其他的都是Standby。当Active的Master出现故障时，另外的一个Standby Master会被选举出来。由于集群的信息，包括Worker， Driver和Application的信息都已经持久化到文件系统，因此在切换的过程中只会影响新Job的提交，对于正在进行的Job没有任何的影响。加入ZooKeeper的集群整体架构如下图所示。 在这里插入图片描述 在配置了HA模式情况下，Master在启动之后都会去 zookeeper中去注册一个临时节点，第一个注册的Master就是Alive状态，后面去注册的Master发现节点被注册，并将自己Master设置为standby状态。

worker也会和zookeeper进行通讯，从zookeeper中获取活跃的Master，也就是配置文件中指定的节点名称，从节点中获取当前Alive的master。worker就和活跃的Master组成集群。

当Alive的master宕机，zookeeper收不到心跳包，将临时节点删除（大概需要15s左右的时间)，那么之前监听的状态为standby的master和zookeeper进行通讯，谁先抢到这个临时节点创建的权限谁就从standby状态转到Alive状态。

worker发现master宕机之后，就会询问zookeeper，zookeeper会将新的Master告知worker，然后新的Master就会进行接管工作，和worker组成集群继续工作，中间这段宕机时间成为中断期，包括节点删除时间在内，大约在30s

参考： https://blog.csdn.net/m0_48639280/article/details/128472177