elasticsearch特点介绍

采菊篱下 发表了文章 • 0 个评论 • 1244 次浏览 • 2015-09-19 16:07 • 来自相关话题

    Elasticsearch是分布式,REST风格,搜索和分析系统。具有实时数据,实时分析,分布式,高可用性,多租户,全文搜索,面向文档,冲突管理,自由模式,rest风格API,每个操作的持久性,Apache 2的开源许可证,基于Apache Lucene之上的特点。

实时数据

数据流进入的系统后,数据怎么能够快速的可视化。用elasticsearch,所有数据立即可用被搜索和分析。




实时分析

结合搜索的速度与分析的力量,改变你的关系与你的数据。交互搜索,发现和分析,以获得改善你的产品或简化您的业务。




分布式

Elasticsearch允许你开始小规模使用,但是随着你使用数据的增长,它可以建立在横向扩展的开箱即用。当你需要更多的容量,只需添加更多的节点,并让集群重组,只需要增加额外的硬件,让集群自动利用额外的硬件。




高可用

Elasticsearch集群弹性-他们将发现新的或失败的节点,重组和重新平衡数据,确保您的数据是安全的和可访问的。




多租户

集群可以托管多个索引,可独立或作为一个组进行查询。索引别名允许你过滤视图时添加索引,可以透明地更新您的应用程序。




全文搜索

Elasticsearch在后台使用Lucene来提供最强大的全文检索,提供任何开源产品的能力。搜索自带的多语言支持,强大的查询语言,地理位置支持,上下文感知的建议,自动完成和搜索片段。




面向文档

存储复杂的真实世界的实体在Elasticsearch结构化JSON文件。所有的字段都被默认索引,所有的索引可以使用一个单一的查询,以方便快速的返回复杂的结果。




模式自由

Elasticsearch允许你快速上手。简单的指定一个JSON文档将自动检测数据的结构和类型,创建一个索引,并使你的数据检索。您还拥有完全控制,以自定义您的数据是如何被索引的。




友好的RESTful API

Elasticsearch是API驱动。几乎任何动作都可以用一个简单的RESTful API使用JSON基于HTTP请求。客户库可使用多种编程语言。




操作持久化

Elasticsearch把你的数据安全第一。文档改变被记录在群集上的多个节点上的事务日志(transaction logs)中记录,以减少任何数据丢失的机会。




Apache 2开源许可证

Elasticsearch可以下载,使用和免费修改。它是基于Apache 2的开源许可证,最灵活的开源许可证。




基于Apache Lucene之上

Apache Lucene是一个用Java编写的高性能,功能齐全信息检索库。elasticsearch内部利用lucene来构建的分布式和分析功能。




冲突管理

乐观的版本控制,可以使用在需要的地方,多个进程的冲突变化,开放式版本控制可以确保数据不会丢失。



英文地址:原文地址 查看全部
es1.jpeg

    Elasticsearch是分布式,REST风格,搜索和分析系统。具有实时数据,实时分析,分布式,高可用性,多租户,全文搜索,面向文档,冲突管理,自由模式,rest风格API,每个操作的持久性,Apache 2的开源许可证,基于Apache Lucene之上的特点。


实时数据


数据流进入的系统后,数据怎么能够快速的可视化。用elasticsearch,所有数据立即可用被搜索和分析。
elasticsearch1.png


实时分析


结合搜索的速度与分析的力量,改变你的关系与你的数据。交互搜索,发现和分析,以获得改善你的产品或简化您的业务。
elasticsearch2.png


分布式


Elasticsearch允许你开始小规模使用,但是随着你使用数据的增长,它可以建立在横向扩展的开箱即用。当你需要更多的容量,只需添加更多的节点,并让集群重组,只需要增加额外的硬件,让集群自动利用额外的硬件。
elasticsearch3.png


高可用


Elasticsearch集群弹性-他们将发现新的或失败的节点,重组和重新平衡数据,确保您的数据是安全的和可访问的。
elasticsearch4.png


多租户


集群可以托管多个索引,可独立或作为一个组进行查询。索引别名允许你过滤视图时添加索引,可以透明地更新您的应用程序。
elasticsearch5.png


全文搜索


Elasticsearch在后台使用Lucene来提供最强大的全文检索,提供任何开源产品的能力。搜索自带的多语言支持,强大的查询语言,地理位置支持,上下文感知的建议,自动完成和搜索片段。
elasticsearch6.png


面向文档


存储复杂的真实世界的实体在Elasticsearch结构化JSON文件。所有的字段都被默认索引,所有的索引可以使用一个单一的查询,以方便快速的返回复杂的结果。
elasticsearch7.png


模式自由


Elasticsearch允许你快速上手。简单的指定一个JSON文档将自动检测数据的结构和类型,创建一个索引,并使你的数据检索。您还拥有完全控制,以自定义您的数据是如何被索引的。
elasticsearch8.png


友好的RESTful API


Elasticsearch是API驱动。几乎任何动作都可以用一个简单的RESTful API使用JSON基于HTTP请求。客户库可使用多种编程语言。
elasticsearch9.png


操作持久化


Elasticsearch把你的数据安全第一。文档改变被记录在群集上的多个节点上的事务日志(transaction logs)中记录,以减少任何数据丢失的机会。
elasticsearch10.png


Apache 2开源许可证


Elasticsearch可以下载,使用和免费修改。它是基于Apache 2的开源许可证,最灵活的开源许可证。
elasticsearch11.png


基于Apache Lucene之上


Apache Lucene是一个用Java编写的高性能,功能齐全信息检索库。elasticsearch内部利用lucene来构建的分布式和分析功能。
elasticsearch12.png


冲突管理


乐观的版本控制,可以使用在需要的地方,多个进程的冲突变化,开放式版本控制可以确保数据不会丢失。
elasticsearch13.png

英文地址:原文地址

elasticsearch不能触碰的配置

采菊篱下 发表了文章 • 0 个评论 • 947 次浏览 • 2015-09-19 14:17 • 来自相关话题

    有几个elasticsearch的热点配置,似乎没有办法避免调整。我们熟知的:配置按钮都希望被打开。然而把所有的配置项都打开,你觉得就可以息事宁人了吗。这些配置常常被滥用,将会导致糟糕的稳定性和糟糕的性能问题,乃至这两种问题。

垃圾收集器(Garbage Collector)

    在这里简单介绍了垃圾收集器基本认识,JVM使用垃圾收集器来释放回收内存。这个技巧确实是最后一个技巧的延伸,但是值得强调的是:
    不要更改默认的垃圾收集器配置!Elasticsearh默认的GC是CMS。让GC并发的运行应用程序,以便最大限度的减少暂停时间。然而它有两个stop-the-world阶段,在回收大量的heaps。

尽管有这些缺点,它是目前对于像Elasticsearch低延迟服务器软件的最佳的GC。 官方建议使用CMS。

有一个新的GC叫垃圾第一GC(g1gc)。这个新的GC的设计是为了尽量减少停顿比CMS更大的堆,和操作。它的工作原理是将堆分割成区域,预测区域包含最可回收的空间。通过收集这些区域(第一),它可以最大限度地减少暂停和操作非常大的堆。

听起来很棒!不幸的是,g1gc仍然是新的,和新的漏洞被发现的常规。这些错误通常会导致各种各样的段错误,硬盘崩溃。Lucene的测试套件是残酷的GC算法,似乎g1gc没有扭结的工作了。

我们想总有一天会推荐g1gc,但现在,它只是不够稳定满足Elasticsearch和Lucene的要求





线程池(Threadpoolsedit)

每个人都喜欢好的线程池。不管出于什么原因,人们似乎无法抗拒增加线程数。索引很多?更多线程!搜索很多?更多线程!节点空闲时间95%的时间?更多线程!

在Elasticsearch默认的线程池的设置是非常明智的。 对于所有的线程池(除了search )的经纬被设置为CPU核心的数量。 如果你有八个核心,你可以同时运行的只有八个线程。 它有道理仅分配八个线程在任何特定的线程池。

搜索得到一个较大的线程池,并且被配置为 # cores * 3

你可能会争辩说,一些线程可以阻止(如在一个磁盘上IO操作),这就是为什么你需要更多的线程。这不是一个问题:在Elasticsearch的磁盘I/O是由Lucene的线程处理,不是Elasticsearch。

此外,合作的线程池通过传递彼此之间的工作。 您不必再担心网络线程阻塞,因为它正在等待磁盘写入。 联网线程都有,因为另一个线程池转交给了工作单位长期得到回网络。

最后,你的程序的计算能力是有限的。 有更多的线程只是迫使处理器切换线程上下文。 处理器可以一次运行只有一个线程,因此当它需要切换到一个不同的线程,它存储了当前的状态(寄存器,等等),并装载另一个线程。 如果你是幸运的,交换机将发生在相同的核心。 如果你运气不好,开关可能会迁移到不同的核心,并要求运输核间通信总线上。

这个上下文切换吃掉周期只需做管理清洁; 估计能挂它高达对现代的CPU为30μs。 所以,除非该线程将被阻塞比为30μs长,极有可能是那个时候会被更好地用刚刚加工和提早完成。

人们通常设置线程池错误的值。 八核的机器,我们已经与60,100,甚至1000个线程运行在整个的configs。 这些设置将让CPU大于得到真正的工作要做。

所以。 下次你要调整一个线程池,请不要。 如果你绝对无法抗拒 ,请保持你的核心数量在心中,也许设置数量增加一倍。 更重要的是仅仅是一种浪费。
原文地址:https://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html 查看全部
eslogo.png

    有几个elasticsearch的热点配置,似乎没有办法避免调整。我们熟知的:配置按钮都希望被打开。然而把所有的配置项都打开,你觉得就可以息事宁人了吗。这些配置常常被滥用,将会导致糟糕的稳定性和糟糕的性能问题,乃至这两种问题。


垃圾收集器(Garbage Collector)


    在这里简单介绍了垃圾收集器基本认识,JVM使用垃圾收集器来释放回收内存。这个技巧确实是最后一个技巧的延伸,但是值得强调的是:
    不要更改默认的垃圾收集器配置!
Elasticsearh默认的GC是CMS。让GC并发的运行应用程序,以便最大限度的减少暂停时间。然而它有两个stop-the-world阶段,在回收大量的heaps。

尽管有这些缺点,它是目前对于像Elasticsearch低延迟服务器软件的最佳的GC。 官方建议使用CMS。

有一个新的GC叫垃圾第一GC(g1gc)。这个新的GC的设计是为了尽量减少停顿比CMS更大的堆,和操作。它的工作原理是将堆分割成区域,预测区域包含最可回收的空间。通过收集这些区域(第一),它可以最大限度地减少暂停和操作非常大的堆。

听起来很棒!不幸的是,g1gc仍然是新的,和新的漏洞被发现的常规。这些错误通常会导致各种各样的段错误,硬盘崩溃。Lucene的测试套件是残酷的GC算法,似乎g1gc没有扭结的工作了。

我们想总有一天会推荐g1gc,但现在,它只是不够稳定满足Elasticsearch和Lucene的要求





线程池(Threadpoolsedit)


每个人都喜欢好的线程池。不管出于什么原因,人们似乎无法抗拒增加线程数。索引很多?更多线程!搜索很多?更多线程!节点空闲时间95%的时间?更多线程!    

在Elasticsearch默认的线程池的设置是非常明智的。 对于所有的线程池(除了search )的经纬被设置为CPU核心的数量。 如果你有八个核心,你可以同时运行的只有八个线程。 它有道理仅分配八个线程在任何特定的线程池。

搜索得到一个较大的线程池,并且被配置为 # cores * 3

你可能会争辩说,一些线程可以阻止(如在一个磁盘上IO操作),这就是为什么你需要更多的线程。这不是一个问题:在Elasticsearch的磁盘I/O是由Lucene的线程处理,不是Elasticsearch。

此外,合作的线程池通过传递彼此之间的工作。 您不必再担心网络线程阻塞,因为它正在等待磁盘写入。 联网线程都有,因为另一个线程池转交给了工作单位长期得到回网络。

最后,你的程序的计算能力是有限的。 有更多的线程只是迫使处理器切换线程上下文。 处理器可以一次运行只有一个线程,因此当它需要切换到一个不同的线程,它存储了当前的状态(寄存器,等等),并装载另一个线程。 如果你是幸运的,交换机将发生在相同的核心。 如果你运气不好,开关可能会迁移到不同的核心,并要求运输核间通信总线上。

这个上下文切换吃掉周期只需做管理清洁; 估计能挂它高达对现代的CPU为30μs。 所以,除非该线程将被阻塞比为30μs长,极有可能是那个时候会被更好地用刚刚加工和提早完成。

人们通常设置线程池错误的值。 八核的机器,我们已经与60,100,甚至1000个线程运行在整个的configs。 这些设置将让CPU大于得到真正的工作要做。

所以。 下次你要调整一个线程池,请不要。 如果你绝对无法抗拒 ,请保持你的核心数量在心中,也许设置数量增加一倍。 更重要的是仅仅是一种浪费。
原文地址:https://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html

elasticsearch的索引如何才能做到平滑切换

采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 1499 次浏览 • 2015-09-18 23:22 • 来自相关话题

elasticsearch配置文件详解

OpenSkill 发表了文章 • 0 个评论 • 881 次浏览 • 2015-09-18 11:26 • 来自相关话题

elasticsearch的config文件夹里面有两个配置文件:elasticsearch.yml和logging.yml,第一个是es的基本配置文件,第二个是日志配置文件,es也是使用log4j来记录日志的,所以logging.yml里的设置按普通log4j配置文件来设置就行了。下面主要讲解下elasticsearch.yml这个文件中可配置的东西:

cluster.name: elasticsearch
配置es的集群名称,默认是elasticsearch,es会自动发现在同一网段下的es,如果在同一网段下有多个集群,就可以用这个属性来区分不同的集群。

node.name: "Franz Kafka"
节点名,默认随机指定一个name列表中名字,该列表在es的jar包中config文件夹里name.txt文件中,其中有很多作者添加的有趣名字。

node.master: true
指定该节点是否有资格被选举成为node,默认是true,es是默认集群中的第一台机器为master,如果这台机挂了就会重新选举master。

node.data: true
指定该节点是否存储索引数据,默认为true。

index.number_of_shards: 5
设置默认索引分片个数,默认为5片。

index.number_of_replicas: 1
设置默认索引副本个数,默认为1个副本。

path.conf: /path/to/conf
设置配置文件的存储路径,默认是es根目录下的config文件夹。

path.data: /path/to/data
设置索引数据的存储路径,默认是es根目录下的data文件夹,可以设置多个存储路径,用逗号隔开,例:
path.data: /path/to/data1,/path/to/data2

path.work: /path/to/work
设置临时文件的存储路径,默认是es根目录下的work文件夹。

path.logs: /path/to/logs
设置日志文件的存储路径,默认是es根目录下的logs文件夹

path.plugins: /path/to/plugins
设置插件的存放路径,默认是es根目录下的plugins文件夹

bootstrap.mlockall: true
设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低,所以要保证它不swap,可以把ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值,并且保证机器有足够的内存分配给es。同时也要允许elasticsearch的进程可以锁住内存,linux下可以通过`ulimit -l unlimited`命令。

network.bind_host: 192.168.0.1
设置绑定的ip地址,可以是ipv4或ipv6的,默认为0.0.0.0。


network.publish_host: 192.168.0.1
设置其它节点和该节点交互的ip地址,如果不设置它会自动判断,值必须是个真实的ip地址。

network.host: 192.168.0.1
这个参数是用来同时设置bind_host和publish_host上面两个参数。

transport.tcp.port: 9300
设置节点间交互的tcp端口,默认是9300。

transport.tcp.compress: true
设置是否压缩tcp传输时的数据,默认为false,不压缩。

http.port: 9200
设置对外服务的http端口,默认为9200。

http.max_content_length: 100mb
设置内容的最大容量,默认100mb

http.enabled: false
是否使用http协议对外提供服务,默认为true,开启。

gateway.type: local
gateway的类型,默认为local即为本地文件系统,可以设置为本地文件系统,分布式文件系统,hadoop的HDFS,和amazon的s3服务器,其它文件系统的设置方法下次再详细说。

gateway.recover_after_nodes: 1
设置集群中N个节点启动时进行数据恢复,默认为1。

gateway.recover_after_time: 5m
设置初始化数据恢复进程的超时时间,默认是5分钟。

gateway.expected_nodes: 2
设置这个集群中节点的数量,默认为2,一旦这N个节点启动,就会立即进行数据恢复。

cluster.routing.allocation.node_initial_primaries_recoveries: 4
初始化数据恢复时,并发恢复线程的个数,默认为4。

cluster.routing.allocation.node_concurrent_recoveries: 2
添加删除节点或负载均衡时并发恢复线程的个数,默认为4。

indices.recovery.max_size_per_sec: 0
设置数据恢复时限制的带宽,如入100mb,默认为0,即无限制。

indices.recovery.concurrent_streams: 5
设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数,默认为5。

discovery.zen.minimum_master_nodes: 1
设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1,对于大的集群来说,可以设置大一点的值(2-4)

discovery.zen.ping.timeout: 3s
设置集群中自动发现其它节点时ping连接超时时间,默认为3秒,对于比较差的网络环境可以高点的值来防止自动发现时出错。

discovery.zen.ping.multicast.enabled: false
设置是否打开多播发现节点,默认是true。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
设置集群中master节点的初始列表,可以通过这些节点来自动发现新加入集群的节点。

下面是一些查询时的慢日志参数设置
index.search.slowlog.level: TRACE
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug:500ms
index.search.slowlog.threshold.fetch.trace: 200ms 查看全部
es1.jpg
elasticsearch的config文件夹里面有两个配置文件:elasticsearch.yml和logging.yml,第一个是es的基本配置文件,第二个是日志配置文件,es也是使用log4j来记录日志的,所以logging.yml里的设置按普通log4j配置文件来设置就行了。
下面主要讲解下elasticsearch.yml这个文件中可配置的东西:

cluster.name: elasticsearch
配置es的集群名称,默认是elasticsearch,es会自动发现在同一网段下的es,如果在同一网段下有多个集群,就可以用这个属性来区分不同的集群。

node.name: "Franz Kafka"
节点名,默认随机指定一个name列表中名字,该列表在es的jar包中config文件夹里name.txt文件中,其中有很多作者添加的有趣名字。

node.master: true
指定该节点是否有资格被选举成为node,默认是true,es是默认集群中的第一台机器为master,如果这台机挂了就会重新选举master。

node.data: true
指定该节点是否存储索引数据,默认为true。

index.number_of_shards: 5
设置默认索引分片个数,默认为5片。

index.number_of_replicas: 1
设置默认索引副本个数,默认为1个副本。

path.conf: /path/to/conf
设置配置文件的存储路径,默认是es根目录下的config文件夹。

path.data: /path/to/data
设置索引数据的存储路径,默认是es根目录下的data文件夹,可以设置多个存储路径,用逗号隔开,例:
path.data: /path/to/data1,/path/to/data2

path.work: /path/to/work
设置临时文件的存储路径,默认是es根目录下的work文件夹。

path.logs: /path/to/logs
设置日志文件的存储路径,默认是es根目录下的logs文件夹

path.plugins: /path/to/plugins
设置插件的存放路径,默认是es根目录下的plugins文件夹

bootstrap.mlockall: true
设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低,所以要保证它不swap,可以把ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值,并且保证机器有足够的内存分配给es。同时也要允许elasticsearch的进程可以锁住内存,linux下可以通过`ulimit -l unlimited`命令。

network.bind_host: 192.168.0.1
设置绑定的ip地址,可以是ipv4或ipv6的,默认为0.0.0.0。


network.publish_host: 192.168.0.1
设置其它节点和该节点交互的ip地址,如果不设置它会自动判断,值必须是个真实的ip地址。

network.host: 192.168.0.1
这个参数是用来同时设置bind_host和publish_host上面两个参数。

transport.tcp.port: 9300
设置节点间交互的tcp端口,默认是9300。

transport.tcp.compress: true
设置是否压缩tcp传输时的数据,默认为false,不压缩。

http.port: 9200
设置对外服务的http端口,默认为9200。

http.max_content_length: 100mb
设置内容的最大容量,默认100mb

http.enabled: false
是否使用http协议对外提供服务,默认为true,开启。

gateway.type: local
gateway的类型,默认为local即为本地文件系统,可以设置为本地文件系统,分布式文件系统,hadoop的HDFS,和amazon的s3服务器,其它文件系统的设置方法下次再详细说。

gateway.recover_after_nodes: 1
设置集群中N个节点启动时进行数据恢复,默认为1。

gateway.recover_after_time: 5m
设置初始化数据恢复进程的超时时间,默认是5分钟。

gateway.expected_nodes: 2
设置这个集群中节点的数量,默认为2,一旦这N个节点启动,就会立即进行数据恢复。

cluster.routing.allocation.node_initial_primaries_recoveries: 4
初始化数据恢复时,并发恢复线程的个数,默认为4。

cluster.routing.allocation.node_concurrent_recoveries: 2
添加删除节点或负载均衡时并发恢复线程的个数,默认为4。

indices.recovery.max_size_per_sec: 0
设置数据恢复时限制的带宽,如入100mb,默认为0,即无限制。

indices.recovery.concurrent_streams: 5
设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数,默认为5。

discovery.zen.minimum_master_nodes: 1
设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1,对于大的集群来说,可以设置大一点的值(2-4)

discovery.zen.ping.timeout: 3s
设置集群中自动发现其它节点时ping连接超时时间,默认为3秒,对于比较差的网络环境可以高点的值来防止自动发现时出错。

discovery.zen.ping.multicast.enabled: false
设置是否打开多播发现节点,默认是true。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
设置集群中master节点的初始列表,可以通过这些节点来自动发现新加入集群的节点。

下面是一些查询时的慢日志参数设置
index.search.slowlog.level: TRACE
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug:500ms
index.search.slowlog.threshold.fetch.trace: 200ms

docker run bash failed

采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 1440 次浏览 • 2015-09-17 00:18 • 来自相关话题

openstack nova集成docker

Geek小A 发表了文章 • 0 个评论 • 1343 次浏览 • 2015-09-16 19:31 • 来自相关话题

    docker已经可以作为compute driver来使用,脱离了原来HEAT的模式,可以做到真正地使用nova来启动容器.这里记录一下openstack Kilo + docker 1.8的集成过程.所有组件环境基于centos7. 
架构图如下: 





安装docker

    在compute node节点上安装docker,强烈建议安装docker-engine 1.8,需要linux3.1的kernal版本,拥有较高的生产稳定性,并且有启动用户组,旧版的docker-io是没有用户组,集成的时候docker.sock的权限每次都是手工修改很不方便.# curl -sSL https://get.docker.com/ | sh
# usermod -aG docker nova
# systemctl enable docker.service
# systemctl start docker.service

安装novadocker

直接从github上clone安装# pip install -e git+https://github.com/stackforge/nova-docker#egg=novadocker
# cp -R src/etc/nova/rootwrap.d /etc/nova/
# chmod -R root.nova /etc/nova/rootwrap.d
# cd src/novadocker/
# python setup.py install

配置nova调用docker驱动

# vi /etc/nova/nova.conf
compute_driver = novadocker.virt.docker.DockerDriver

配置glance支持容器格式

# vi /etc/glance/glance-api.conf (修改后重启glance-api服务)
container_formats = ami,ari,aki,bare,ovf,docker

Fix bug设置

    由于novadocker开发的版本是基于nova比较新的版本,在现在发行的版本中使用会有一个BUG,下面是修复记录.
    
1.重启openstack-nova-compute服务时提示没有找到oslo_log模块# pip install oslo.log2.重启openstack-nova-compute服务时提示没有找到hv_type模块通过代码定位发现目前的版本中模块是nova.compute.hvtype
修改/usr/lib/python2.7/site-packages/novadocker/virt/docker/driver.py
把from nova.compute import hv_type 改为 from nova.compute import hvtype3.直接导入driver测试提示报错,CONF没有’my_ip’这个opt配置通过代码排查发现目前的openstack是使用oslo.config这个模块包来做cfg的导入和导出
但是在novadocker整个项目里面使用的oslo_config这个独立的模块
修改driver.py, client.py, hostinfo.py, vifs.py模块
from oslo_config import cfg 改为 from oslo.config import cfg4.直接导入driver测试提示继续报错,没有找到hvtype.DOCKER属性修改 /usr/lib/python2.7/site-packages/nova/compute/hvtype.py
在# specific ‘baremetal’ & ‘fake’ then added in.下面增加
DOCKER=’docker’    此时启动openstack-nova-compute已经正常

glance导入docker镜像

# docker pull hipache
# docker save hipache | glance image-create --is-public=True --container-format=docker --disk-format=raw --name hipache    需要注意的是glance导入后的名字一定要和docker images下显示的名字一模一样,否则创建时会提示无法找到镜像

启动容器实例

nova boot --image hipache --flavor 1 --nic net-id=342a0eef-e03d-4fd8-af3c-1ed485bee989 docker



1.此时启动容器实例报错失败,从nova-compute.log的日志看异常信息是”attach vif error”,具体是无法使用nova-rootwrap来提权进入namespace创建实例的网络接口google找到的这个BUG的解决是禁用compute节点的selinux2.继续下一个BUG,日志抛出一个Python异常是没有找到hardware.InstanceInfo模块进入目录/usr/lib/python2.7/site-packages/nova/virt
查看hardware.py的代码的确没有找到这个类或者函数,在github上找到nova项目的最新代码可以看到是有的.



把这个类的代码复制到本地的hardware.py里面
 
3.重启启动一个实例后,异常继续保持 



异常提示InstanceInfo没有getitem这个内置方法
根据driver.py里面的调用可以发现get_info调用的时候是hardware.InstanceInfo是返回一个字典
删除刚才在hardware.py复制的代码,重写InstanceInfodef InstanceInfo(state=None, max_mem_kb=0, mem_kb=0, num_cpu=0,cpu_time_ns=0, id=None):
Info={}
Info['state'] = state
Info['max_mem_kb'] = max_mem_kb
Info['self.mem_kb'] = mem_kb
Info['num_cpu'] = num_cpu
Info['cpu_time_ns'] = cpu_time_ns
Info['id'] = id
return Info此时启动实例正常无报错[root@openstack-k ~]# nova list
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| c9d7ef23-f0fe-488d-88b1-3b5650901820 | hipache | ACTIVE | - | Running | admin_private=192.168.0.101, 172.24.4.228 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
[root@openstack-k ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14583d5d6308 hipache "supervisord -n" 5 hours ago Up 5 hours nova-c9d7ef23-f0fe-488d-88b1-3b5650901820
[root@openstack-k ~]#参考连接:https://wiki.openstack.org/wiki/Docker
http://docs.docker.com/installation/centos/
https://bugs.launchpad.net/nova-docker/+bug/1480246
https://github.com/openstack/nova/
https://github.com/stackforge/nova-docker原文链接:原文地址 查看全部
opdock1.png

    docker已经可以作为compute driver来使用,脱离了原来HEAT的模式,可以做到真正地使用nova来启动容器.这里记录一下openstack Kilo + docker 1.8的集成过程.所有组件环境基于centos7. 
架构图如下: 
openstack1.png


安装docker


    在compute node节点上安装docker,强烈建议安装docker-engine 1.8,需要linux3.1的kernal版本,拥有较高的生产稳定性,并且有启动用户组,旧版的docker-io是没有用户组,集成的时候docker.sock的权限每次都是手工修改很不方便.
# curl -sSL https://get.docker.com/ | sh
# usermod -aG docker nova
# systemctl enable docker.service
# systemctl start docker.service


安装novadocker


直接从github上clone安装
# pip install -e git+https://github.com/stackforge/nova-docker#egg=novadocker
# cp -R src/etc/nova/rootwrap.d /etc/nova/
# chmod -R root.nova /etc/nova/rootwrap.d
# cd src/novadocker/
# python setup.py install


配置nova调用docker驱动


# vi /etc/nova/nova.conf
compute_driver = novadocker.virt.docker.DockerDriver


配置glance支持容器格式


# vi /etc/glance/glance-api.conf (修改后重启glance-api服务)
container_formats = ami,ari,aki,bare,ovf,docker


Fix bug设置


    由于novadocker开发的版本是基于nova比较新的版本,在现在发行的版本中使用会有一个BUG,下面是修复记录.
    
1.重启openstack-nova-compute服务时提示没有找到oslo_log模块
# pip install oslo.log
2.重启openstack-nova-compute服务时提示没有找到hv_type模块
通过代码定位发现目前的版本中模块是nova.compute.hvtype 
修改/usr/lib/python2.7/site-packages/novadocker/virt/docker/driver.py
把from nova.compute import hv_type 改为 from nova.compute import hvtype
3.直接导入driver测试提示报错,CONF没有’my_ip’这个opt配置
通过代码排查发现目前的openstack是使用oslo.config这个模块包来做cfg的导入和导出 
但是在novadocker整个项目里面使用的oslo_config这个独立的模块
修改driver.py, client.py, hostinfo.py, vifs.py模块
from oslo_config import cfg 改为 from oslo.config import cfg
4.直接导入driver测试提示继续报错,没有找到hvtype.DOCKER属性
修改 /usr/lib/python2.7/site-packages/nova/compute/hvtype.py 
在# specific ‘baremetal’ & ‘fake’ then added in.下面增加
DOCKER=’docker’
    此时启动openstack-nova-compute已经正常


glance导入docker镜像


# docker pull hipache
# docker save hipache | glance image-create --is-public=True --container-format=docker --disk-format=raw --name hipache
    需要注意的是glance导入后的名字一定要和docker images下显示的名字一模一样,否则创建时会提示无法找到镜像


启动容器实例


nova boot --image hipache --flavor 1 --nic net-id=342a0eef-e03d-4fd8-af3c-1ed485bee989 docker
openstack2.png

1.此时启动容器实例报错失败,从nova-compute.log的日志看异常信息是”attach vif error”,具体是无法使用nova-rootwrap来提权进入namespace创建实例的网络接口
google找到的这个BUG的解决是禁用compute节点的selinux
2.继续下一个BUG,日志抛出一个Python异常是没有找到hardware.InstanceInfo模块
进入目录/usr/lib/python2.7/site-packages/nova/virt 
查看hardware.py的代码的确没有找到这个类或者函数,在github上找到nova项目的最新代码可以看到是有的.
openstack3.png

把这个类的代码复制到本地的hardware.py里面
 
3.重启启动一个实例后,异常继续保持 
openstack4.png
异常提示InstanceInfo没有getitem这个内置方法 
根据driver.py里面的调用可以发现get_info调用的时候是hardware.InstanceInfo是返回一个字典
删除刚才在hardware.py复制的代码,重写InstanceInfo
def InstanceInfo(state=None, max_mem_kb=0, mem_kb=0, num_cpu=0,cpu_time_ns=0, id=None):
Info={}
Info['state'] = state
Info['max_mem_kb'] = max_mem_kb
Info['self.mem_kb'] = mem_kb
Info['num_cpu'] = num_cpu
Info['cpu_time_ns'] = cpu_time_ns
Info['id'] = id
return Info
此时启动实例正常无报错
[root@openstack-k ~]# nova list
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
| c9d7ef23-f0fe-488d-88b1-3b5650901820 | hipache | ACTIVE | - | Running | admin_private=192.168.0.101, 172.24.4.228 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------------------------+
[root@openstack-k ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14583d5d6308 hipache "supervisord -n" 5 hours ago Up 5 hours nova-c9d7ef23-f0fe-488d-88b1-3b5650901820
[root@openstack-k ~]#
参考连接:
https://wiki.openstack.org/wiki/Docker 
http://docs.docker.com/installation/centos/
https://bugs.launchpad.net/nova-docker/+bug/1480246
https://github.com/openstack/nova/
https://github.com/stackforge/nova-docker
原文链接:原文地址

控制Elasticsearch分片和副本的分配

OpenSkill 发表了文章 • 1 个评论 • 10904 次浏览 • 2015-09-15 00:04 • 来自相关话题

    ES集群中索引可能由多个分片构成,并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片,我们可以处理不能在一个单一的服务器上面运行的大型索引,简单的说就是索引的大小过大,导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本,通过将副本分配到多个服务器,可以提高查询的负载能力。
 
    为了进行分片和副本的操作,ES需要确定将这些分片和副本放到集群节点的哪个位置,就是需要确定把每个分片和副本分配到哪台服务器/节点上。
 

一、显式控制分配

生产情景:比如生产环境有三个索引分别为 man、woman、katoey
希望达到的效果:
man索引放置在一些集群节点上
woman索引又单独放置到集群的另外一些集群节点上
katoey索引希望放置在所有放置man索引和woman索引的集群节点上

这么做是因为katoey索引比其他两个索引小很多,因此我们可以将它和其他两个索引一起分配。
但是基于ES默认算法的处理方法,我们不能确定分片和副本的存放位置,但是ES允许我们对其做相应的控制!
1、指定节点的参数



    如上图所示,我们将ES集群划分为两个"空间"。当然你也可以叫做区域,随便命名。我们将左边的三台ES节点服务器放置到zone_one的空间上面,将右边的三台ES节点服务器放到zone_two的空间上。
 
配置
    为了做到我们需要的效果,我们需要将如下属性配置到左边三台ES集群节点服务器的elasticsearch.yml配置文件中node.zone: zone_one    将如下属性配置到右边的三台ES集群节点服务器elasticsearch.yml配置文件中node.zone: zone_two 
索引创建
    当所有节点配置文件属性配置完成后,我们就可以根据空间名称,我们就可以创建索引放到指定的空间。
    首先我们运行如下命令,来创建man索引:# curl -XPOST "http://ESnode:9200/man'
# curl -XPUT "http://ESnode:9200/man/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_one"
}'    第一条命令是创建man索引;第二条命令是发送到_settings REST端点,用来指定这个索引的其他配置信息。我们将index.routing.allocation.include.zone属性设置为zone_one值,就是我们所希望的把man索引放置到node.zone属性值为zone_one的ES集群节点服务器上。
 
    同样对woman索引我们做类似操作:# curl -XPOST "http://ESnode:9200/woman'
# curl -XPUT "http://ESnode:9200/woman/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_two"
}'    不同的是,这次指定woman索引放置在node.zone属性值为zone_two的ES集群节点服务器上
 
    最后我们需要将katoey索引放置到上面所有的ES集群节点上面,配置设置命令如下:# curl -XPOST "http://ESnode:9200/katoey"
# curl -XPUT "http://ESnode:9200/katoey/_settings" -d '{
"index.routing.allocation.include.zone" : "zone_one,zone_two"
}'
 2、分配时排除节点
    跟我们上面操作为索引指定放置节点位置一样,我们也可以在索引分配的时候排除某些节点。参照之前的例子,我们新建一个people索引,但是不希望people索引放置到zone_one的ES集群节点服务器上,我们可以运行如下命令操作:# curl -XPOST "http://EScode:9200/people"
# curl -XPUT "http://EScode:9200/people/_settings" -d '{
"index.routing.allocation.exclude.zone" : "zone_one"
}'    请注意,在这里我们使用的是index.routing.allocation.exclude.zone属性而不是index.routing.allocation.include.zone属性。
 
使用IP地址进行分配配置
    除了在节点的配置中添加一些特殊的属性参数外,我们还可以使用IP地址来指定你将分片和副本分配或者不分配到哪些节点上面。为了做到这点,我们应该使用_ip属性,把zone换成_ip就好了。例如我们希望lucky索引分配到IP地址为10.0.1.110和10.0.1.119的节点上,我们可以运行如下命令设置:# curl -XPOST "http://ESnode:9200/lucky"
# curl -XPUT "http://ESnode:9200/lucky/_settings" -d '{
"index.routing.allocation.include._ip" "10.0.1.110,10.0.1.119"
}'

二、集群范围内分配

    除了索引层面指定分配活着排除分配之外(上面我们所做的都是这两种情况),我们还可以指定集群中所有索引的分配。例如,我们希望将所有的新索引分配到IP地址为10.0.1.112和10.0.1.114的节点上,我们可以运行如下命令设置:# curl -XPUT "http://ESnode:9200/_cluster/settings" -d '{
"transient" : {
"cluster.routing.allocation.include._ip" "10.0.1.112,10.0.1.114"
}
}'    集群级别的控制后续还会分享transient和persistent属性介绍
 

三、每个节点上分片和副本数量的控制

    除了指定分片和副本的分配,我们还可以对一个索引指定每个节点上的最大分片数量。例如我们希望ops索引在每个节点上只有一个分片,我们可以运行如下命令:# curl -XPUT "http://ESnode:9200/ops/_settings" -d '{
"index.routing.allocation.total_shards_per_node" : 1
}'    这个属性也可以直接配置到elasticsearch.ym配置文件中,或者使用上面命令在活动索引上更新。如果配置不当,导致主分片无法分配的话,集群就会处于red状态。
 

四、手动移动分片和副本

    接下来我们介绍一下节点间手动移动分片和副本。可以使用ElasticSearch提供的_cluster/reroute REST端点进行控制,能够进行下面操作:
[]将一个分片从一个节点移动到另外一个节点[/][]取消对分片的分配[/][]强制对分片进行分配[/]
 
移动分片
    假设我们有两个节点:es_node_one和es_node_two,ElasticSearch在es_node_one节点上分配了ops索引的两个分片,我们现在希望将第二个分片移动到es_node_two节点上。可以如下操作实现:# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [ {
"move" : {
"index" : "ops",
"shard" : 1,
"from_node" : "es_node_one",
"to_node" : "es_node_two"
}
}]
}'    我们通过move命令的index属性指定移动哪个索引,通过shard属性指定移动哪个分片,最终通过from_node属性指定我们从哪个节点上移动分片,通过to_node属性指定我们希望将分片移动到哪个节点。
 
取消分配
    如果希望取消一个正在进行的分配过程,我们通过运行cancel命令来指定我们希望取消分配的索引、节点以及分片,如下所示:# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [ {
"cancel" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_one"
}
} ]
}'    运行上面的命令将会取消es_node_one节上ops索引的第0个分片的分配
 
分配分片
    除了取消和移动分片和副本之外,我们还可以将一个未分配的分片分配到一个指定的节点上。假设ops索引上有一个编号为0的分片尚未分配,并且我们希望ElasticSearch将其分配到es_node_two上,可以运行如下命令操作:# curl -XPOST "http://ESnode:9200/_cluster/reroute' -d '{
"commands" : [ {
"allocate" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_two"
}
} ]
}'一次HTTP请求包含多个命令
    我们可以在一次HTTP请求中包含多个命令,例如:# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [
{"move" : {"index" : "ops", "shard" : 1, "from_node" : "es_node_one", "to_node" : "es_node_two"}},
{"cancel" : {"index" : "ops", "shard" : 0, "node" : "es_node_one"}}
]
}' 查看全部
    ES集群中索引可能由多个分片构成,并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片,我们可以处理不能在一个单一的服务器上面运行的大型索引,简单的说就是索引的大小过大,导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本,通过将副本分配到多个服务器,可以提高查询的负载能力。
 
    为了进行分片和副本的操作,ES需要确定将这些分片和副本放到集群节点的哪个位置,就是需要确定把每个分片和副本分配到哪台服务器/节点上。
 


一、显式控制分配


生产情景:
比如生产环境有三个索引分别为 man、woman、katoey
希望达到的效果:
man索引放置在一些集群节点上
woman索引又单独放置到集群的另外一些集群节点上
katoey索引希望放置在所有放置man索引和woman索引的集群节点上

这么做是因为katoey索引比其他两个索引小很多,因此我们可以将它和其他两个索引一起分配。
但是基于ES默认算法的处理方法,我们不能确定分片和副本的存放位置,但是ES允许我们对其做相应的控制!

1、指定节点的参数
epei1.png

    如上图所示,我们将ES集群划分为两个"空间"。当然你也可以叫做区域,随便命名。我们将左边的三台ES节点服务器放置到zone_one的空间上面,将右边的三台ES节点服务器放到zone_two的空间上。
 
配置
    为了做到我们需要的效果,我们需要将如下属性配置到左边三台ES集群节点服务器的elasticsearch.yml配置文件中
node.zone: zone_one
    将如下属性配置到右边的三台ES集群节点服务器elasticsearch.yml配置文件中
node.zone: zone_two
 
索引创建
    当所有节点配置文件属性配置完成后,我们就可以根据空间名称,我们就可以创建索引放到指定的空间。
    首先我们运行如下命令,来创建man索引:
# curl -XPOST "http://ESnode:9200/man'
# curl -XPUT "http://ESnode:9200/man/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_one"
}'
    第一条命令是创建man索引;第二条命令是发送到_settings REST端点,用来指定这个索引的其他配置信息。我们将index.routing.allocation.include.zone属性设置为zone_one值,就是我们所希望的把man索引放置到node.zone属性值为zone_one的ES集群节点服务器上。
 
    同样对woman索引我们做类似操作:
# curl -XPOST "http://ESnode:9200/woman'
# curl -XPUT "http://ESnode:9200/woman/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_two"
}'
    不同的是,这次指定woman索引放置在node.zone属性值为zone_two的ES集群节点服务器上
 
    最后我们需要将katoey索引放置到上面所有的ES集群节点上面,配置设置命令如下:
# curl -XPOST "http://ESnode:9200/katoey"
# curl -XPUT "http://ESnode:9200/katoey/_settings" -d '{
"index.routing.allocation.include.zone" : "zone_one,zone_two"
}'

 2、分配时排除节点
    跟我们上面操作为索引指定放置节点位置一样,我们也可以在索引分配的时候排除某些节点。参照之前的例子,我们新建一个people索引,但是不希望people索引放置到zone_one的ES集群节点服务器上,我们可以运行如下命令操作:
# curl -XPOST "http://EScode:9200/people"
# curl -XPUT "http://EScode:9200/people/_settings" -d '{
"index.routing.allocation.exclude.zone" : "zone_one"
}'
    请注意,在这里我们使用的是index.routing.allocation.exclude.zone属性而不是index.routing.allocation.include.zone属性。
 
使用IP地址进行分配配置
    除了在节点的配置中添加一些特殊的属性参数外,我们还可以使用IP地址来指定你将分片和副本分配或者不分配到哪些节点上面。为了做到这点,我们应该使用_ip属性,把zone换成_ip就好了。例如我们希望lucky索引分配到IP地址为10.0.1.110和10.0.1.119的节点上,我们可以运行如下命令设置:
# curl -XPOST "http://ESnode:9200/lucky"
# curl -XPUT "http://ESnode:9200/lucky/_settings" -d '{
"index.routing.allocation.include._ip" "10.0.1.110,10.0.1.119"
}'


二、集群范围内分配


    除了索引层面指定分配活着排除分配之外(上面我们所做的都是这两种情况),我们还可以指定集群中所有索引的分配。例如,我们希望将所有的新索引分配到IP地址为10.0.1.112和10.0.1.114的节点上,我们可以运行如下命令设置:
# curl -XPUT "http://ESnode:9200/_cluster/settings" -d '{
"transient" : {
"cluster.routing.allocation.include._ip" "10.0.1.112,10.0.1.114"
}
}'
    集群级别的控制后续还会分享transient和persistent属性介绍
 


三、每个节点上分片和副本数量的控制


    除了指定分片和副本的分配,我们还可以对一个索引指定每个节点上的最大分片数量。例如我们希望ops索引在每个节点上只有一个分片,我们可以运行如下命令:
# curl -XPUT "http://ESnode:9200/ops/_settings" -d '{
"index.routing.allocation.total_shards_per_node" : 1
}'
    这个属性也可以直接配置到elasticsearch.ym配置文件中,或者使用上面命令在活动索引上更新。如果配置不当,导致主分片无法分配的话,集群就会处于red状态。
 


四、手动移动分片和副本


    接下来我们介绍一下节点间手动移动分片和副本。可以使用ElasticSearch提供的_cluster/reroute REST端点进行控制,能够进行下面操作:
    []将一个分片从一个节点移动到另外一个节点[/][]取消对分片的分配[/][]强制对分片进行分配[/]

 
移动分片
    假设我们有两个节点:es_node_one和es_node_two,ElasticSearch在es_node_one节点上分配了ops索引的两个分片,我们现在希望将第二个分片移动到es_node_two节点上。可以如下操作实现:
# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d  '{
"commands" : [ {
"move" : {
"index" : "ops",
"shard" : 1,
"from_node" : "es_node_one",
"to_node" : "es_node_two"
}
}]
}'
    我们通过move命令的index属性指定移动哪个索引,通过shard属性指定移动哪个分片,最终通过from_node属性指定我们从哪个节点上移动分片,通过to_node属性指定我们希望将分片移动到哪个节点。
 
取消分配
    如果希望取消一个正在进行的分配过程,我们通过运行cancel命令来指定我们希望取消分配的索引、节点以及分片,如下所示:
# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [ {
"cancel" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_one"
}
} ]
}'
    运行上面的命令将会取消es_node_one节上ops索引的第0个分片的分配
 
分配分片
    除了取消和移动分片和副本之外,我们还可以将一个未分配的分片分配到一个指定的节点上。假设ops索引上有一个编号为0的分片尚未分配,并且我们希望ElasticSearch将其分配到es_node_two上,可以运行如下命令操作:
# curl -XPOST "http://ESnode:9200/_cluster/reroute' -d '{
"commands" : [ {
"allocate" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_two"
}
} ]
}'
一次HTTP请求包含多个命令
    我们可以在一次HTTP请求中包含多个命令,例如:
# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [
{"move" : {"index" : "ops", "shard" : 1, "from_node" : "es_node_one", "to_node" : "es_node_two"}},
{"cancel" : {"index" : "ops", "shard" : 0, "node" : "es_node_one"}}
]
}'

如何改变docker image的存放路径

OpenSkill 回复了问题 • 2 人关注 • 1 个回复 • 1729 次浏览 • 2015-09-13 18:09 • 来自相关话题

HDFS高可用方案之QJM

OpenSkill 发表了文章 • 0 个评论 • 919 次浏览 • 2015-09-12 20:18 • 来自相关话题

喜欢一个人,可以为TA做任何事,得到不接受却依然心甘情愿鞍前马后,苦苦等候那一线希望。对,这就是备胎,挂在汽车背后,可能一辈子也用不到的那个圆圈状的玩意儿,大部分情况下,它都会默默地挂在那里,等待几千分之一的机会,有个倒霉的轮子兄弟出事了,于是它就能派上用场了……(摘自豆瓣)
 
在Hadoop的分布式文件系统HDFS中,NameNode用来保存文件系统的元数据(包含目录结构/数据块位置等),如果NameNode上的数据丢失,HDFS上对应的文件数据就无法找回来了。Hadoop在2.0.0之前的版本,使用SecondaryNameNode备份NameNode的数据,但SecondaryNameNode无法转成NameNode,如果NameNode挂了,整个HDFS就会挂掉,无法实现真正的failover。这篇博文总结了5种Hadoop HA(High Available,高可用)方案,Hadoop2之后官方引入了QJM(Quorum Journal Manager)和NFS用于NameNode的备份和切换。本方将介绍的是QJM方案,它使用第二个NameNode实时同步当前NameNode的数据,相比于SecondaryNameNode,他可以随时切换成为真正的NameNode(一个可转正的高级备胎)。
 
先看看没有HA的HDFS的系统架构(用draw.io画的,尼马这么好的网站也被墙了):




然后有HA方案的系统架构:




以下的实验基于4个节点的Hadoop集群。其中每个节点的运行的进程列表如下:




实验环境中,所有节点的运行环境基本相同:
[]Ubuntu14.04 X64[/][]4G内存[/][]OpenJDK-1.7.0[/][]100Mbps以太网[/]
下面是实现这个系统的流程(官方文档+个人注解+辅助Shell命令)。

安装Hadoop系统
严格按照单节点搭建和集群搭建两个步骤,系统建起来完全没压力。我遇到的问题是刚开始在配置文件(salves和core-site.xml等文件)中使用的是ip地址而非主机名,然后在log文件里看到各种无法连接。解决方案是修改主机名并在hosts文件里建立映射关系。hostname {new_hostname} # 修改主机名,只有当前Session有效
sudo vi /etc/hostname # 永久修改主机名的方法另外,对于64位的系统,最好重新编译源码。

修改配置文件
hdfs-site.xml文件:<configuration>
<property>
<name>dfs.namenode.name.dir</name>
<value>/data/hadoop/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>/data/hadoop/datanode</value>
</property>
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>hd1:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>hd3:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>hd1:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>hd3:50070</value>
</property>
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://hd1:8485;hd2:8485;hd4:8485/mycluster</value>
</property>
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/hduser/.ssh/id_rsa</value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/hadoop/journalnode</value>
</property>
</configuration>
[]其中nameservices是集群的命名空间,即使有多个集群,可以共用配置文件,但是要注意某些配置项的顺序。[/][]dfs.ha.namenodes.mycluster中的mycluster是可以任取的,但是要和dfs.nameservices对应。[/][]dfs.namenode.rpc-address.mycluster.nn1参考上一条。[/][]dfs.namenode.shared.edits.dir值的格式是"qjournal://host1:port1;host2:port2;host3:port3/journalId",用来指定对应的JN节点,journalId建议使用和nameservices相同的名称。[/][]dfs.client.failover.proxy.provider.mycluster指定激活NameNode的Java类,目前Hadoop内置的只有上面那个。[/][]dfs.ha.fencing.methods是来用来隔离失效的NameNode的方法,有sshfence和Shell两种方式。sshfence需要配置dfs.ha.fencing.ssh.private-key-files私钥文件,以便交互的过程不需要输入密码。[/][]dfs.journalnode.edits.dir是JN保存数据的文件。[/]
 
core-site.xml文件:<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
</configuration>
[]注意mycluster要和dhfs-site.xml中的dfs.nameservices对应。fs.defaultFS不用端口号。[/]
 

部署
改好配置文件好,就要将配置文件同步到所有的机器上了。可以用rsync将文件同步到多台机器上。rsync是一个增量同步工具,需要先安装。下面的rsync.sh的功能是将当前目录的所有文件发送到文件或参数对应的机器上。$ cat rsync.sh
#! /bin/bash

dir=`pwd`
pdir=`dirname $dir`

send(){
echo "Sending to $2:$1"
rsync -avez -e ssh $1 $2:$3
}

mul_send(){
while read host
do
send $dir $host $pdir
done < $1
}

[ -f $1 ] && mul_send $1 || send $dir $1 $pdir将rsync.sh放在etc/hadoop目录下,进入目录运行chmod +x rsync.sh
./rsync.sh slaves
# or ./rsync.sh hostname发送完文件之后,就是启动系统。步骤如下:
 
启动JNs.

在所有JournalNode上运行sbin/hadoop-daemon.sh --script hdfs start journalnode启动NameNode.
 
在原NameNode上运行bin/hadoop --script hdfs start namenode # NameNode需要已经format。[url=使用上面的rsync.sh文件]/code[/url]将原NameNode(nn1)上的数据复制到第二个NameNode(nn2)。然后在nn2上运行:[code]bin/hdfs namenode -bootstrapStandby启动其他节点

在NameNode上运行sbin/start-dfs.sh

切换NameNode
手动方式

上面的NameNode默认以standby的状态启动,这时因为没有active的NameNode,所以是不能在HDFS读写文件,需要将其中的一个转成active状态。比如将nn1(对应前面的配置)转成Active:bin/hdfs haadmin -transitionToActive nn1然后在NameNode的web页面上部的括号里的standby变成active。
转成standby的命令是:
bin/hdfs haadmin -transitionToStandby nn1
 
自动切换
在当前NameNode不能使用时自动切换到第二个NameNode上,需要借助于ZooKeeper[url=ZK]/url。

ZK的安装过程和Hadoop差不多,就是下载文件、修改配置、复制到所有机器、启动。具体步骤在这里。

配置文件conf/zoo.conf:tickTime=2000
dataDir=/data/hadoop/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=hd2:2888:3888
server.2=hd3:2888:3888
server.3=hd4:2888:3888hd2,hd3,hd4是主机名,至少需要三台,这个在一台机挂了整个系统还能用,ZK的数量一般是奇数,为什么为奇数可以参考这里。
 
然后要在hdfs-site.xml上添加配置:<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>hd2:2181,hd3:2181,hd4:2181</value>
</property>然后就是在NameNode的机器上初始化NameNode在ZK的状态了:bin/hdfs zkfc -formatZK重启HDFS或手动启动DFSZKFailoverController(ZKFC):sbin/stop-dfs.sh # 重启hdfs
sbin/start-dfs.sh
sbin/hadoop-daemon.sh start zkfc # 启动ZKFC在该HA方案中,每一个NameNode都有一个对应的ZKFC。ZKFC会随NameNode启动。
 
测试
 
在当前NameNode运行jps看NameNode的进程ID,然后kill掉。通过Web页面( http://hdx:50070 ),可以看到standby的NameNode几乎在kill的同时转成active了。
转载地址:原文地址 查看全部
喜欢一个人,可以为TA做任何事,得到不接受却依然心甘情愿鞍前马后,苦苦等候那一线希望。对,这就是备胎,挂在汽车背后,可能一辈子也用不到的那个圆圈状的玩意儿,大部分情况下,它都会默默地挂在那里,等待几千分之一的机会,有个倒霉的轮子兄弟出事了,于是它就能派上用场了……(摘自豆瓣)
 
在Hadoop的分布式文件系统HDFS中,NameNode用来保存文件系统的元数据(包含目录结构/数据块位置等),如果NameNode上的数据丢失,HDFS上对应的文件数据就无法找回来了。Hadoop在2.0.0之前的版本,使用SecondaryNameNode备份NameNode的数据,但SecondaryNameNode无法转成NameNode,如果NameNode挂了,整个HDFS就会挂掉,无法实现真正的failover。这篇博文总结了5种Hadoop HA(High Available,高可用)方案,Hadoop2之后官方引入了QJM(Quorum Journal Manager)和NFS用于NameNode的备份和切换。本方将介绍的是QJM方案,它使用第二个NameNode实时同步当前NameNode的数据,相比于SecondaryNameNode,他可以随时切换成为真正的NameNode(一个可转正的高级备胎)。
 
先看看没有HA的HDFS的系统架构(用draw.io画的,尼马这么好的网站也被墙了):
hd21.png

然后有HA方案的系统架构:
hd22.png

以下的实验基于4个节点的Hadoop集群。其中每个节点的运行的进程列表如下:
hd23.png

实验环境中,所有节点的运行环境基本相同:
    []Ubuntu14.04 X64[/][]4G内存[/][]OpenJDK-1.7.0[/][]100Mbps以太网[/]

下面是实现这个系统的流程(官方文档+个人注解+辅助Shell命令)。


  1. 安装Hadoop系统


严格按照单节点搭建集群搭建两个步骤,系统建起来完全没压力。我遇到的问题是刚开始在配置文件(salves和core-site.xml等文件)中使用的是ip地址而非主机名,然后在log文件里看到各种无法连接。解决方案是修改主机名并在hosts文件里建立映射关系。
hostname {new_hostname} # 修改主机名,只有当前Session有效
sudo vi /etc/hostname # 永久修改主机名的方法
另外,对于64位的系统,最好重新编译源码。


  1. 修改配置文件


hdfs-site.xml文件:
<configuration>
<property>
<name>dfs.namenode.name.dir</name>
<value>/data/hadoop/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>/data/hadoop/datanode</value>
</property>
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>hd1:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>hd3:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>hd1:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>hd3:50070</value>
</property>
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://hd1:8485;hd2:8485;hd4:8485/mycluster</value>
</property>
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/hduser/.ssh/id_rsa</value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/hadoop/journalnode</value>
</property>
</configuration>

    []其中nameservices是集群的命名空间,即使有多个集群,可以共用配置文件,但是要注意某些配置项的顺序。[/][]dfs.ha.namenodes.mycluster中的mycluster是可以任取的,但是要和dfs.nameservices对应。[/][]dfs.namenode.rpc-address.mycluster.nn1参考上一条。[/][]dfs.namenode.shared.edits.dir值的格式是"qjournal://host1:port1;host2:port2;host3:port3/journalId",用来指定对应的JN节点,journalId建议使用和nameservices相同的名称。[/][]dfs.client.failover.proxy.provider.mycluster指定激活NameNode的Java类,目前Hadoop内置的只有上面那个。[/][]dfs.ha.fencing.methods是来用来隔离失效的NameNode的方法,有sshfence和Shell两种方式。sshfence需要配置dfs.ha.fencing.ssh.private-key-files私钥文件,以便交互的过程不需要输入密码。[/][]dfs.journalnode.edits.dir是JN保存数据的文件。[/]

 
core-site.xml文件:
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
</configuration>

    []注意mycluster要和dhfs-site.xml中的dfs.nameservices对应。fs.defaultFS不用端口号。[/]

 


  1. 部署


改好配置文件好,就要将配置文件同步到所有的机器上了。可以用rsync将文件同步到多台机器上。rsync是一个增量同步工具,需要先安装。下面的rsync.sh的功能是将当前目录的所有文件发送到文件或参数对应的机器上。
$ cat rsync.sh 
#! /bin/bash

dir=`pwd`
pdir=`dirname $dir`

send(){
echo "Sending to $2:$1"
rsync -avez -e ssh $1 $2:$3
}

mul_send(){
while read host
do
send $dir $host $pdir
done < $1
}

[ -f $1 ] && mul_send $1 || send $dir $1 $pdir
将rsync.sh放在etc/hadoop目录下,进入目录运行
chmod +x rsync.sh
./rsync.sh slaves
# or ./rsync.sh hostname
发送完文件之后,就是启动系统。步骤如下:
 
启动JNs.

在所有JournalNode上运行
sbin/hadoop-daemon.sh --script hdfs start journalnode
启动NameNode.
 
在原NameNode上运行
bin/hadoop --script hdfs start namenode # NameNode需要已经format。[url=使用上面的rsync.sh文件]/code[/url]将原NameNode(nn1)上的数据复制到第二个NameNode(nn2)。然后在nn2上运行:[code]bin/hdfs namenode -bootstrapStandby
启动其他节点

在NameNode上运行
sbin/start-dfs.sh


  1. 切换NameNode


手动方式

上面的NameNode默认以standby的状态启动,这时因为没有active的NameNode,所以是不能在HDFS读写文件,需要将其中的一个转成active状态。比如将nn1(对应前面的配置)转成Active:
bin/hdfs haadmin -transitionToActive nn1
然后在NameNode的web页面上部的括号里的standby变成active。
转成standby的命令是:
bin/hdfs haadmin -transitionToStandby nn1
 
自动切换
在当前NameNode不能使用时自动切换到第二个NameNode上,需要借助于ZooKeeper[url=ZK]/url

ZK的安装过程和Hadoop差不多,就是下载文件、修改配置、复制到所有机器、启动。具体步骤在这里。

配置文件conf/zoo.conf:
tickTime=2000
dataDir=/data/hadoop/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=hd2:2888:3888
server.2=hd3:2888:3888
server.3=hd4:2888:3888
hd2,hd3,hd4是主机名,至少需要三台,这个在一台机挂了整个系统还能用,ZK的数量一般是奇数,为什么为奇数可以参考这里。
 
然后要在hdfs-site.xml上添加配置:
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>hd2:2181,hd3:2181,hd4:2181</value>
</property>
然后就是在NameNode的机器上初始化NameNode在ZK的状态了:
bin/hdfs zkfc -formatZK
重启HDFS或手动启动DFSZKFailoverController(ZKFC):
sbin/stop-dfs.sh # 重启hdfs
sbin/start-dfs.sh
sbin/hadoop-daemon.sh start zkfc # 启动ZKFC
在该HA方案中,每一个NameNode都有一个对应的ZKFC。ZKFC会随NameNode启动。
 
测试
 
在当前NameNode运行jps看NameNode的进程ID,然后kill掉。通过Web页面( http://hdx:50070 ),可以看到standby的NameNode几乎在kill的同时转成active了。
转载地址:原文地址

Docker镜像无法删除

采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 1406 次浏览 • 2015-09-10 11:09 • 来自相关话题