Tachyon Cluster: 基于Zookeeper的Master High Availability(HA)高可用配置实现

1.Tachyon简介

Tachyon是一个高容错的分布式文件系统,允许文件以内存的速度在集群框架中进行可靠的共享,就像Spark和 MapReduce那样。通过利用信息继承,内存侵入,Tachyon获得了高性能。Tachyon工作集文件缓存在内存中,并且让不同的 Jobs/Queries以及框架都能内存的速度来访问缓存文件。因此,Tachyon可以减少那些需要经常使用的数据集通过访问磁盘来获得的次数。

2.Tachyon能解决什么问题:(摘自Tachyon 分布式内存文件系统

1.不同FrameWork之间共享内存数据Slow问题
     给定一个场景,MapReduce任务的输出结果会存入到Tachyon里,Spark的Job会从Tachyon里读取MapReduce任务的输出作为输入。如果把Disk当作文件的落地,那么写的性能是十分低下的。但是如果把Memory当作落地,写的性能是非常高的,fast write,以便Spark Job不会感觉到这是2个计算框架的操作,因为写和读的速度都非常快。同样的,你可以用Impala的输出结果当作Spark的输入。
2.Spark的Executor Crash问题
     Spark的执行引擎和存储引擎都是在Executor进程里,即在一个Executor内会有多个Task在运行,并且这个Executor的内存会放入cache的RDD里。
问题来了,一旦我的Executor挂了,那么Tasks会失败,并且这些cache的RDD的Block也会丢失,这就会有ReCompute的过程,重新去取数据,根据血缘关系递归的去计算丢失的数据,这当然会很耗费资源,而且性能低下。
3.内存冗余问题
     这里说的内存冗余是说,Spark中不同Job之间可能同时读取了同一个文件,比如:job1和job2的计算任务都需要读取到账号信息表中的数据,那么我们都在他们各自的Executor里都cache了这一张账号表,是不是就出现了一个数据,2个内存副本,其实这样做是完全没有必要的,是冗余的。
4.GC时间过长
     有时候影响程序执行的并不是代码本身,而是由于内存中存了太多的Java Objects,如果Executor这个Jvm里cache的对象太多,比如:达到80G UP,这个时候出现几次FULL GC,你就会很纳闷我的程序怎么不动了?你去看GC log,原来在GC。

3.基于Zookeeper的Fault Tolerant Tachyon Cluster 实现

3.0 配置前提

  • hadoop version:2.2.0.2.0.6.0-101
  • zookeeper version:2.3.5
  • Tachyon version: 0.4.1

集群情况:

Cluster  Masters Slaves
Tachyon bigdata001,bigdata002 bigdata001,bigdata002,bigdata003,bigdata004,bigdata005,bigdata006,bigdata007,bigdata008

zookeeper url: bigdata001:2181,bigdata002:2181,bigdata003:2181

3.1 HA架构

3.2 配置(conf/tachyon-env.sh )

1.参考官方文档Fault Tolerant Tachyon Cluster

①HDFS

export TACHYON_UNDERFS_ADDRESS=hdfs://[namenodeserver]:[namenodeport]

②ZooKeeper:

Property Name Example Meaning
tachyon.usezookeeper true Whether or not Master processes should use ZooKeeper.
tachyon.zookeeper.address localhost:2181 The hostname and port ZooKeeper is running on.

③Master Node Configuration

export TACHYON_MASTER_ADDRESS=[externally visible address of this machine]

TACHYON_JAVA_OPTS to include:

-Dtachyon.master.journal.folder=hdfs://[namenodeserver]:[namenodeport]/tachyon/journal

④Worker Node Configuration

export TACHYON_MASTER_ADDRESS=[address of one of the master nodes in the system]

2.集群配置

Master节点配置:bigdata001节点的tachyon/conf/tachyon-env.sh添加如下(下划线部分)

export TACHYON_MASTER_ADDRESS=192.168.1.101export TACHYON_UNDERFS_ADDRESS=hdfs://192.168.1.101:8020
export TACHYON_JAVA_OPTS+="
  -Dlog4j.configuration=file:$CONF_DIR/log4j.properties
  -Dtachyon.debug=false
  -Dtachyon.underfs.address=$TACHYON_UNDERFS_ADDRESS
  -Dtachyon.underfs.hdfs.impl=$TACHYON_UNDERFS_HDFS_IMPL
  -Dtachyon.data.folder=$TACHYON_UNDERFS_ADDRESS/tmp/tachyon/data
  -Dtachyon.workers.folder=$TACHYON_UNDERFS_ADDRESS/tmp/tachyon/workers
  -Dtachyon.worker.memory.size=$TACHYON_WORKER_MEMORY_SIZE
  -Dtachyon.worker.data.folder=$TACHYON_RAM_FOLDER/tachyonworker/
  -Dtachyon.master.worker.timeout.ms=60000
  -Dtachyon.master.hostname=$TACHYON_MASTER_ADDRESS
  -Dtachyon.master.journal.folder=$TACHYON_UNDERFS_ADDRESS/tachyon/journal/
  -Dtachyon.master.pinlist=/pinfiles;/pindata
  -Dorg.apache.jasper.compiler.disablejsr199=true
  -Dtachyon.user.default.block.size.byte=67108864
  -Dtachyon.user.file.buffer.bytes=8388608
  -Dtachyon.usezookeeper=true
  -Dtachyon.zookeeper.address=bigdata001:2181,bigdata002:2181,bigdata003:2181
"

配置同步到所有的slave节点:bigdata002,bigdata003,bigdata004,bigdata005,bigdata006,bigdata007,bigdata008

由于我们要将bigdata002作为另外一个master,因此,此节点的配置需要做修改TACHYON_MASTER_ADDRESS的值,如下

export TACHYON_MASTER_ADDRESS=192.168.1.102
export TACHYON_UNDERFS_ADDRESS=hdfs://192.168.1.101:8020
export TACHYON_JAVA_OPTS+="
  -Dlog4j.configuration=file:$CONF_DIR/log4j.properties
  -Dtachyon.debug=false
  -Dtachyon.underfs.address=$TACHYON_UNDERFS_ADDRESS
  -Dtachyon.underfs.hdfs.impl=$TACHYON_UNDERFS_HDFS_IMPL
  -Dtachyon.data.folder=$TACHYON_UNDERFS_ADDRESS/tmp/tachyon/data
  -Dtachyon.workers.folder=$TACHYON_UNDERFS_ADDRESS/tmp/tachyon/workers
  -Dtachyon.worker.memory.size=$TACHYON_WORKER_MEMORY_SIZE
  -Dtachyon.worker.data.folder=$TACHYON_RAM_FOLDER/tachyonworker/
  -Dtachyon.master.worker.timeout.ms=60000
  -Dtachyon.master.hostname=$TACHYON_MASTER_ADDRESS
  -Dtachyon.master.journal.folder=$TACHYON_UNDERFS_ADDRESS/tachyon/journal/
  -Dtachyon.master.pinlist=/pinfiles;/pindata
  -Dorg.apache.jasper.compiler.disablejsr199=true
  -Dtachyon.user.default.block.size.byte=67108864
  -Dtachyon.user.file.buffer.bytes=8388608
  -Dtachyon.usezookeeper=true
  -Dtachyon.zookeeper.address=bigdata001:2181,bigdata002:2181,bigdata003:2181
"

3.启动集群

[[email protected] tachyon]# ./bin/tachyon-stop.sh

Killed  processes
Killed  processes
192.168.1.103: Killed  processes
192.168.1.101: Killed 0 processes
192.168.1.102: Killed  processes
192.168.1.104: Killed  processes
192.168.1.106: Killed  processes
192.168.1.105: Killed  processes
192.168.1.107: Killed  processes
192.168.1.108: Killed  processes

[[email protected] tachyon]# ./bin/tachyon format

192.168.1.101: Formatting Tachyon Worker @ bigdata001
192.168.1.102: Formatting Tachyon Worker @ bigdata002
192.168.1.103: Formatting Tachyon Worker @ bigdata003
192.168.1.104: Formatting Tachyon Worker @ bigdata004
192.168.1.105: Formatting Tachyon Worker @ bigdata005
192.168.1.106: Formatting Tachyon Worker @ bigdata006
192.168.1.107: Formatting Tachyon Worker @ bigdata007
192.168.1.102: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.101: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.103: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.104: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.108: Formatting Tachyon Worker @ bigdata008
192.168.1.105: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.106: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.107: Removing local data under folder: /mnt/ramdisk/tachyonworker/
192.168.1.108: Removing local data under folder: /mnt/ramdisk/tachyonworker/
Formatting Tachyon Master @ 192.168.1.101
Formatting JOURNAL_FOLDER: hdfs://192.168.1.101:8020/tachyon/journal/
Formatting UNDERFS_DATA_FOLDER: hdfs://192.168.1.101:8020/tmp/tachyon/data
Formatting UNDERFS_WORKERS_FOLDER: hdfs://192.168.1.101:8020/tmp/tachyon/workers

[[email protected] tachyon]# ./bin/tachyon-start.sh all Mount

Killed 0 processes
Killed 0 processes
192.168.1.103: Killed 0 processes
192.168.1.101: Killed 0 processes
192.168.1.105: Killed 0 processes
192.168.1.102: Killed 0 processes
192.168.1.107: Killed 0 processes
192.168.1.106: Killed 0 processes
192.168.1.104: Killed 0 processes
192.168.1.108: Killed 0 processes
Starting master @ 192.168.1.101
192.168.1.101: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.102: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.101: Starting worker @ bigdata001
192.168.1.103: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.102: Starting worker @ bigdata002
192.168.1.103: Starting worker @ bigdata003
192.168.1.104: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.105: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.104: Starting worker @ bigdata004
192.168.1.105: Starting worker @ bigdata005
192.168.1.106: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.106: Starting worker @ bigdata006
192.168.1.107: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.107: Starting worker @ bigdata007
192.168.1.108: Formatting RamFS: /mnt/ramdisk (2gb)
192.168.1.108: Starting worker @ bigdata008

[[email protected] tachyon]# jps

可以看到Master和Worker的进程号:8315 Master  8458 Worker

在另个master节点bigdata002上启动另外一个master:

[[email protected] tachyon]# ./bin/tachyon-start.sh master

Starting master @ 192.168.1.102

4.测试HA

web界面查看:http://bigdata001:19999

kill掉bigdata001的master进程,切换时间大概需要20s,再次查看新的Web UI:http://bigdata002:19999/home

5.Zk上查看

[[email protected] conf]# zkCli.sh

[zk: localhost:2181(CONNECTED) 61] ls /election
[_c_ae6213f4-a2e3-46f9-8fc0-5c5c64d7e773-lock-0000000027, _c_12297d87-56fc-4cd9-8f8d-7312a6af4cc2-lock-0000000026]

[zk: localhost:2181(CONNECTED) 63] ls /leader
[bigdata001:19998, bigdata002:19998]

时间: 2024-12-19 19:33:00

Tachyon Cluster: 基于Zookeeper的Master High Availability(HA)高可用配置实现的相关文章

基于NFS共享的Mysql之HA高可用集群实现

192.168.139.8 作为NFS-Server ,192.168.139.2和192.168.13.4用来安装mysql ___________________________________________________________________________________________以下操作在192.168.139.8上操作 [[email protected] ~]# fdisk -l //首先要准备一块磁盘进行分区,用来做lv,再将此lv格式化后挂载并      

基于keepalived的Haproxy高可用配置

一.概述: HAProxy是一个用于4层或7层的高性能负载均衡软件,在大型网站的大型Web服务器群集中,HAProxy可用来替代专业的硬件负载均衡设备,节省大量的开支. 通常情况下,为了避免整个体系中出现单点故障,在至关重要的架构中,都需要部署备份设备,同样,负载均衡设备也不能部署单台,一旦主设备出现问题之后,备份设备可对主设备进行接管.实现不间断的服务,这便是Keepalived的作用. 于是,HAProxy和Keepalived的组合便成了省钱高效的Web服务器负载均衡架构. 拓扑图: 二.

ActiveMQ + ZooKeeper 集群高可用配置

一. 准备条件: (1) 最好是有3台服务器[2台也行, 只是根据(replicas/2)+1 公式至少得2个ActiveMQ服务存在才能保证运行, 自己测试的时候麻烦点, 关掉其中一个, 再开启, 看会不会选举到另一个ActiveMQ服务, 多试几次可以看到效果] (2)  ActiveMQ安装参考: ActiveMQ (3)  ZooKeeper安装参考:ZooKeeper 二. 配置 : ActiveMQ根目录下的conf/activemq.xml, 原来默认如下: <persistenc

转】Spark:Master High Availability(HA)高可用配置的2种实现

原博文出自于: 感谢! Spark Standalone集群是Master-Slaves架构的集群模式,和大部分的Master-Slaves结构集群一样,存在着Master单点故障的问题.如何解决这个单点故障的问题,Spark提供了两种方案: 基于文件系统的单点恢复(Single-Node Recovery with Local File System) 基于zookeeper的Standby Masters(Standby Masters with ZooKeeper)      (企业里,一

Spark:Master High Availability(HA)高可用配置的2种实现

Spark Standalone集群是Master-Slaves架构的集群模式,和大部分的Master-Slaves结构集群一样,存在着Master单点故障的问题.如何解决这个单点故障的问题,Spark提供了两种方案: 基于文件系统的单点恢复(Single-Node Recovery with Local File System) 基于zookeeper的Standby Masters(Standby Masters with ZooKeeper) ZooKeeper提供了一个Leader El

CentOS6.4 高可用集群之基于heartbeat(crm)和nfs的mysql高可用

CentOS6.4 高可用集群之基于heartbeat和nfs的高可用mysql CentOS版本: CentOS release 6.4(Final) 2.6.32-358.el6.i686 效果演示: 使用ssh连接(nod-1.magedu.com)192.168.3.7 并执行以下命令: [[email protected] ha.d]# hb_gui & 说明:hb_gui是heartbeat为了方便管理集群资源而提供的一个图形用户接口 安装heartbeat默认会在系统中创建一个名为

基于heartbeat的单播方式实现tomcat高可用

1.节点规划 在master.backup节点上添加eth0.eth1两网卡,具体添加过程,参考“基于VMware为CentOS 6.5配置两个网卡” 2.IP规划   master backup eth0 192.168.46.128 192.168.46.130 eth1 192.168.46.129 192.168.46.131 上面这个表格说明master节点中的eth0网卡的IP是192.168.46.128,eth1网卡的IP是192.168.46.129:backup节点中eth0

zookeeper + LevelDB + ActiveMQ实现消息队列高可用

通过集群实现消息队列高可用. 消息队列在项目中存储订单.邮件通知.数据分发等重要信息,故对消息队列稳定可用性有高要求. 现在通过zookeeper选取activemq leader的形式实现当某个activemq节点出问题时,保证系统的可用性. zookeeper做为服务选取器来选择activemq作为master. 开发环境将zoopkeeper zoo_sample.cfg拷贝并修改文件名称为zoo.cfg. activemq 配置禁用kahadb启用LevelDB 其中 zkAddress

Kubernetes master节点的高可用配置

了解Kubernetes架构都知道Master节点在整个集群中的位置,为了保证整个架构的高可用,Kubernetes提供了HA的架构,处于兴趣和对架构的进一步了解,我在自己的电脑实践以下. 环境: CentOS 7.3,Kubernetes版本 Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"82450d03cb057b