除了可以在Mesos或者YARN集群管理器上运行Spark外，Spark还提供了独立部署模式。你可以通过手动启动一个master和workers,或者使用提供的脚本来手动地启动单独的集群模式。你也可以在一台单独的机器上启动这些进程用来测试。
以独立模式安装Spark集群
你只需要将编译好的Spark版本拷贝到集群中的每台节点上。
手动启动集群
你可以通过执行以下脚本单独模式的master
./sbin/start-master.sh 启动之后，master将会打印
spark://HOST:PORT。你可以通过它连接workers，或者向SparkContext传递"master"参数。你也可以通过master的WEB UI来找到它，webUI的默认端口是8080.下面是webUI中的显示：
类似地，你可以使用下面的脚本启动一个或多个连接到master的worker
./sbin/start-slave.sh <master-spark-URL> 我分别在两台机器上启动worker,并指定master的URL.
root@Slave2:/usr/local/spark/spark-1.4.1-bin-hadoop2.6/sbin# ./start-slave.sh 192.168.181.128:7077
启动了worker之后，在master的webUI上就可以看到新的node列表了。
下面是一些可以传递给启动脚本的参数和含义：
参数 | 含义 |
| 监听主机名 |
| 监听主机名 (已过时, 使用 -h或者--host) |
| 服务监听端口 (master默认: 7077, worker是随机的) |
| web UI端口 (master默认: 8080 ; worker默认 8081) |
| 允许Spark应用程序使用的cpu核心数 （默认：所有cpu核心）; 只能对worker设置 |
| 允许Spark应用程序使用的内存数量。格式如:1000M or 2G (默认是 1 GB);只能对worker设置 |
| 为job输出日志划分的目录 (默认为: SPARK_HOME/work); 只能对worker设置 |
| Spark配置文件加载路径 (默认文件为: conf/spark-defaults.conf) |
集群启动脚本
要想通过脚本启动Spark的独立模式，你需要在Spark目录下创建一个conf/slaves文件。里面包含所有你希望作为worker启动的机器的hostname，每台机器一行。如果这个文件不存在，启动脚本默认只启动一个机器，即localhost，这样仅仅用来测试。
注意：master机器通过ssh访问每台worker。通过ssh访问worker是并行进行的，需要设置无密码访问（使用私钥）。如果你不设置无密码访问，你可以设置SPARK_SSH_FOREGROUND环境变量，然后一个一个地为worker输入密码。
一旦你设置好了这些文件，你就可以通过脚本启动或停止你的集群，这些脚本基于hadoop部署脚本。在SPARK_HOME/bin目录下:
sbin/start-master.sh- 在本机上启动一个master实例。sbin/start-slaves.sh- 启动在conf/slaves文件中指定的第个worker实例。sbin/start-slave.sh- 在本机上启动一个worker实例。sbin/start-all.sh- 启动所有的master和workers。sbin/stop-master.sh- 通过bin/start-master.sh脚本停止master。sbin/stop-slaves.sh-停止conf/slaves文件中指定的所有workers。sbin/stop-all.sh- 停止所有的master和workers。
注意：必须在你希望运行spark的机器上运行这些脚本，而不是你本地机器上。
你还可以通过在conf/spark-env.sh定义环境变量来进一步配置你的集群。通过conf/spark-env.template模版来创建这个文件，然后将它拷贝到Spark机器上使其生效。
下面是一些可以设置的配置：
Environment Variable | Meaning |
| Bind the master to a specific IP address, for example a public one. |
| Start the master on a different port (default: 7077). |
| Port for the master web UI (default: 8080). |
| Configuration properties that apply only to the master in the form "-Dx=y" (default: none). See below for a list of possible options. |
| Directory to use for "scratch" space in Spark, including map output files and RDDs that get stored on disk. This should be on a fast, local disk in your system. It can also be a comma-separated list of multiple directories on different disks. |
| Total number of cores to allow Spark applications to use on the machine (default: all available cores). |
| Total amount of memory to allow Spark applications to use on the machine, e.g. |
| Start the Spark worker on a specific port (default: random). |
| Port for the worker web UI (default: 8081). |
| Number of worker instances to run on each machine (default: 1). You can make this more than 1 if you have have very large machines and would like multiple Spark worker processes. If you do set this, make sure to also set |
| Directory to run applications in, which will include both logs and scratch space (default: SPARK_HOME/work). |
| Configuration properties that apply only to the worker in the form "-Dx=y" (default: none). See below for a list of possible options. |
| Memory to allocate to the Spark master and worker daemons themselves (default: 512m). |
| JVM options for the Spark master and worker daemons themselves in the form "-Dx=y" (default: none). |
| The public DNS name of the Spark master and workers (default: none). |
这些启动脚本还不支持Windows。要在Windows上启动集群，只能手动启动。
上面的SPARK_MASTER_OPTS变量可以设置如下属性：
Property Name | Default | Meaning |
| 200 | The maximum number of completed applications to display. Older applications will be dropped from the UI to maintain this limit. |
| 200 | The maximum number of completed drivers to display. Older drivers will be dropped from the UI to maintain this limit. |
| true | Whether the standalone cluster manager should spread applications out across nodes or try to consolidate them onto as few nodes as possible. Spreading out is usually better for data locality in HDFS, but consolidating is more efficient for compute-intensive workloads. |
| (infinite) | Default number of cores to give to applications in Spark's standalone mode if they don't set |
| 60 | Number of seconds after which the standalone deploy master considers a worker lost if it receives no heartbeats. |
SPARK_WORKER_OPTS变量可以设置如下属性：
Property Name | Default | Meaning |
| false | Enable periodic cleanup of worker / application directories. Note that this only affects standalone mode, as YARN works differently. Only the directories of stopped applications are cleaned up. |
| 1800 (30 minutes) | Controls the interval, in seconds, at which the worker cleans up old application work dirs on the local machine. |
| 7 * 24 * 3600 (7 days) | The number of seconds to retain application work directories on each worker. This is a Time To Live and should depend on the amount of available disk space you have. Application logs and jars are downloaded to each application work dir. Over time, the work dirs can quickly fill up disk space, especially if you run jobs very frequently. |
在集群上运行应用程序：
只需给SparkContext传递Master的URL spark://IP:PORT，就可以在集群上运行应用程序。
要在集群上运行交互式shell,执行如下命令：
./bin/spark-shell --master spark://IP:PORT你还可以通过--total-executor-cores <numCores>选项来控制spark-shell使用的集群cpu核心数。
启动Spark应用程序
spark-submit脚本提供了向集群提交编译好的应用程序的简单方法。对于独立模式，Spark目前支持2种部署模式。
client-mode:在客户模式上，driver与提交应用程序的客户端运行在同一进程中。
cluster-mode:在集群模式中，driver是从集群中的一个worker进程中启动的，这个进程只要完成了提交作业任务就会退出，不会等待提交的应用程序的完成。
如果你通过spark-submit来提交程序，应用程序的jar包会自动地部署到所有的worker nodes。对于应用程序依懒的其它jar包，你需要通过--jars选项来指定，并将jar包以","分隔。形如：--jars jar1,jar2. 如果你想控制应用程序的执行环境，可以查看Spark配置。
另外，如果你的应用程序以非0状态退出，独立集群模式支持重启程序。要支持自动重启，需要向spark-submit传递--supervise标志。
如果你想杀掉一个重复失败的应用程序，你可以使用如下方式：
./bin/spark-class org.apache.spark.deploy.Client kill <master url> <driver ID> 你可以找到driver ID在 Master的 web UI上
http://<master url>:8080.
你也可以在web UI上通过点击"Kill"终止程序，如下图所示：
资源调度
独立模式目前只支持FIFO的调度策略。然而，为了允许多个并发的用户，你可以控制每个应用程序使用的最大资源。默认情况下，它会获取集群中的所有CPU核心，这只对你仅运行一个应用程序有意义。你可以通过在SparkContext上设置“spark.cores.max”来控制应用程序使用的cpu核心上限。
val conf = new SparkConf()
.setMaster(...)
.setAppName(...)
.set("spark.cores.max", "10")
val sc = new SparkContext(conf)
另外，你可以通过在master上配置spark.deploy.defaultCores来改变那些没有设置“”spark.cores.max“”上限的应用程序的默认cpu核心数。这通过在conf/spark-env.sh里修改实现：
export SPARK_MASTER_OPTS="-Dspark.deploy.defaultCores=<value>"
这对于共享集群比较有用，在共享集群环境中，通常个人最大CPU核心数没有限制。
监控和日志
spark的独立模式为管理集群提供了基于web的用户接口。master和每个worker都有自己的webUI来展示集群和job数据。master的webUI默认为8080端口。可以通过配置文件或者命令行参数来更改这个端口。
另外，每个job都有详细的日志输出写到slave节点(默认路径为SPARK_HOME/work)。你将会看到每个job都有stderr,stdout两个文件，这里面包含了所有写到控制台的输出信息。
与hadoop一起运行
你可以将Spark与现存的hadoop集群一起运行。你只需要在hadoop的机器上以独立服务启动Spark。要想通过spark访问hadoop的数据，你只需要使用一个hdfs:// URL (典型的URL形如:hdfs://<namenode>:9000/path。你可以在hadoop的webUI上面找到准确的URL。
或者，你也可以安装完全独立的spark集群，然后通过网络访问hdfs,这将比以本地磁盘方式访问要慢些。但是，如果你在本地局域网内运行，影响会较小(比如你把把一些spark机器部署在一些hadoop的机架上)。
为网络安全配置端口
spark会频繁地使用网络，一些使用防火墙配置的场合对环境有严格的要求。可以通过安全配置链接查看完整的端口配置列表。
高可靠性
默认情况下，独立模式的Spark调度集群对失败的任务具有弹性（spark通过把丢失的工作移动到其他worker上来提供弹性）。
然而，只有master一个节点进行调度决策，这就会有单点故障。一旦master宕机，就不能创建新的程序。
我们有两种高可靠策略来避免这种问题：
1.通过ZooKeeper提供备用Master
概述
利用ZooKeeper提供master选举和状态存储功能。你可以在你的集群里启动多个Master连接到同一个Zookeeper实例。其中的一台机器会被选举为master,剩下的将会运行在StandBy模式。如果master宕机，新的master会被选举出来并恢复状态，从而继续提供调度服务。整个恢复过程（从第一个master宕机开始）需要1－2分钟。注意，这只会影响恢复过程中提交的新作业，而在宕机之前提交的作业不会受影响。
为了使能这种恢复模式，你可以在spark-env里通过以下参数设置SPARK_DAEMON_JAVA_OPTS：
系统属性 | 含义 |
| 设为ZOOKEEPER来使能standby Master恢复模式 (默认: NONE). |
| ZooKeeper集群的url (e.g., 192.168.1.100:2181,192.168.1.101:2181). |
| ZooKeeper存储恢复状态的路径 (默认: /spark). |
可能存在的问题：如果你在集群中有多个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重启时恢复。
配置
为了使能这种恢复模式，你可以在spark-evn中用如下参数配置SPARK_DAEMON_JAVA_OPTS：
系统属性 | 含义 |
| 设置为 FILESYSTEM 来使能单节点恢复模式 (默认: NONE). |
| 存储恢复数据的目录, Master需要可以访问. |
细节
这种模式可以与进程监控管理工具比如monitor配合使用，或者仅仅是为了能够通过重启来手工恢复。
尽管文件系统模式看起来比什么恢复也不做要好。但是对于开发或实现环境来说，也许并不好。通常情况下，通过stop-daemon.sh来杀死master进程并不会清除它的恢复状态，所以不管你什么时候再启动一个新的Master,它都会进入恢复模式。这可能会将启动时间延长1分钟，因为它要等待所有先前注册的Workers/Clients超时。
尽管没有官方支持，你可以mount一个NFS目录作为恢复路径。如果原来的Master宕机的话，你可以在一个不同的节点上启动一个Master，这样它就能正确地恢复原来注册的所有Workers和应用程序（和Zookeeper的恢复模式等价）。后面提交的应用程序为了能够注册，必须能够找到新的Master。
