除了可以在Mesos或者YARN集群管理器上运行Spark外，Spark还提供了独立部署模式。你可以通过手动启动一个master和workers,或者使用提供的脚本来手动地启动单独的集群模式。你也可以在一台单独的机器上启动这些进程用来测试。

以独立模式安装Spark集群

你只需要将编译好的Spark版本拷贝到集群中的每台节点上。

你可以通过执行以下脚本单独模式的master

启动之后，master将会打印

类似地，你可以使用下面的脚本启动一个或多个连接到master的worker

下面是一些可以传递给启动脚本的参数和含义：

要想通过脚本启动Spark的独立模式，你需要在Spark目录下创建一个conf/slaves文件。里面包含所有你希望作为worker启动的机器的hostname，每台机器一行。如果这个文件不存在，启动脚本默认只启动一个机器，即localhost，这样仅仅用来测试。

注意：master机器通过ssh访问每台worker。通过ssh访问worker是并行进行的，需要设置无密码访问（使用私钥）。如果你不设置无密码访问，你可以设置SPARK_SSH_FOREGROUND环境变量，然后一个一个地为worker输入密码。

一旦你设置好了这些文件，你就可以通过脚本启动或停止你的集群，这些脚本基于hadoop部署脚本。在SPARK_HOME/bin目录下:

注意：必须在你希望运行spark的机器上运行这些脚本，而不是你本地机器上。

你还可以通过在conf/spark-env.sh定义环境变量来进一步配置你的集群。通过conf/spark-env.template模版来创建这个文件，然后将它拷贝到Spark机器上使其生效。

下面是一些可以设置的配置：

这些启动脚本还不支持Windows。要在Windows上启动集群，只能手动启动。

在集群上运行应用程序：

要在集群上运行交互式shell,执行如下命令：

启动Spark应用程序

spark-submit脚本提供了向集群提交编译好的应用程序的简单方法。对于独立模式，Spark目前支持2种部署模式。

client-mode:在客户模式上，driver与提交应用程序的客户端运行在同一进程中。

cluster-mode:在集群模式中，driver是从集群中的一个worker进程中启动的，这个进程只要完成了提交作业任务就会退出，不会等待提交的应用程序的完成。

如果你通过spark-submit来提交程序，应用程序的jar包会自动地部署到所有的worker nodes。对于应用程序依懒的其它jar包，你需要通过--jars选项来指定，并将jar包以","分隔。形如：--jars jar1,jar2. 如果你想控制应用程序的执行环境，可以查看。

另外，如果你的应用程序以非0状态退出，独立集群模式支持重启程序。要支持自动重启，需要向spark-submit传递--supervise标志。

如果你想杀掉一个重复失败的应用程序，你可以使用如下方式：

你也可以在web UI上通过点击"Kill"终止程序，如下图所示：

独立模式目前只支持FIFO的调度策略。然而，为了允许多个并发的用户，你可以控制每个应用程序使用的最大资源。默认情况下，它会获取集群中的所有CPU核心，这只对你仅运行一个应用程序有意义。你可以通过在SparkContext上设置“spark.cores.max”来控制应用程序使用的cpu核心上限。

这对于共享集群比较有用，在共享集群环境中，通常个人最大CPU核心数没有限制。

spark的独立模式为管理集群提供了基于web的用户接口。master和每个worker都有自己的webUI来展示集群和job数据。master的webUI默认为8080端口。可以通过配置文件或者命令行参数来更改这个端口。

另外，每个job都有详细的日志输出写到slave节点(默认路径为SPARK_HOME/work)。你将会看到每个job都有stderr,stdout两个文件，这里面包含了所有写到控制台的输出信息。

或者，你也可以安装完全独立的spark集群，然后通过网络访问hdfs,这将比以本地磁盘方式访问要慢些。但是，如果你在本地局域网内运行，影响会较小(比如你把把一些spark机器部署在一些hadoop的机架上)。

spark会频繁地使用网络，一些使用防火墙配置的场合对环境有严格的要求。可以通过链接查看完整的端口配置列表。

默认情况下，独立模式的Spark调度集群对失败的任务具有弹性（spark通过把丢失的工作移动到其他worker上来提供弹性）。

然而，只有master一个节点进行调度决策，这就会有单点故障。一旦master宕机，就不能创建新的程序。

我们有两种高可靠策略来避免这种问题：

利用ZooKeeper提供master选举和状态存储功能。你可以在你的集群里启动多个Master连接到同一个Zookeeper实例。其中的一台机器会被选举为master,剩下的将会运行在StandBy模式。如果master宕机，新的master会被选举出来并恢复状态，从而继续提供调度服务。整个恢复过程（从第一个master宕机开始）需要1－2分钟。注意，这只会影响恢复过程中提交的新作业，而在宕机之前提交的作业不会受影响。

可能存在的问题：如果你在集群中有多个Master,但是没有正确地配置如何使用Zookeeper。所有的Master将不能发现彼此，从而认为自己是leader。这将会导致不健康的状态（每个Master独立的进行调度）。

安装了Zookeeper集群后，使能高可靠性功能。只需简单地在多台机器上以相同配置（ZooKeeper URL和目录）启动多个Master进程。可以在任何时间添加或删除Master。

为了在集群中调度新的程序或者向集群中添加新的worker，它们都需要知道当前leader的IP地址。你可以像只有单个节点时那样，传递一个Master列表。比如，你可以启动你的SparkContext指向spark://host1:port1,host2:port2。Spark会依次尝试向Master注册，如果host1失败，向host2注册。

向Master注册和普通操作之间是有区别的，只有在启动的时候，应用程序和Workers才需要向集群中的leader注册。一旦注册成功，这些状态就会保存在系统中（存储在Zookeeper中）。当发生故障时，新的leader会向所有先前注册的程序和workers通知leader的变化，所以在启动时，它们甚至不需要知道新leader的存在。

因为这个特性，新的Master可以在任何时刻创建。你仅仅需要关心新的程序和Workers在新leader产生时，能够找到并向它注册。一旦注册成功，你就不需要在关心了。

2.基于本地文件系统的单节点恢复

Zookeeper是生产环境中高可靠性的最佳方案。如果你仅仅是想在master宕机后重启它，文件系统模式也可以满足你。当应用程序和Workers注册时，将足够的状态写到文件中，这样它们就能在Master重启时恢复。

这种模式可以与进程监控管理工具比如配合使用，或者仅仅是为了能够通过重启来手工恢复。

尽管文件系统模式看起来比什么恢复也不做要好。但是对于开发或实现环境来说，也许并不好。通常情况下，通过stop-daemon.sh来杀死master进程并不会清除它的恢复状态，所以不管你什么时候再启动一个新的Master,它都会进入恢复模式。这可能会将启动时间延长1分钟，因为它要等待所有先前注册的Workers/Clients超时。

尽管没有官方支持，你可以mount一个NFS目录作为恢复路径。如果原来的Master宕机的话，你可以在一个不同的节点上启动一个Master，这样它就能正确地恢复原来注册的所有Workers和应用程序（和Zookeeper的恢复模式等价）。后面提交的应用程序为了能够注册，必须能够找到新的Master。