Elasticsearch备份和恢复

采菊篱下 发表了文章 • 0 个评论 • 307 次浏览 • 2016-10-15 13:04 • 来自相关话题

备份

备份数据之前,要创建一个仓库来保存数据,仓库的类型支持共享文件系统、Amazon S3、 HDFS和Azure Cloud。 
 
Elasticsearch的一大特点就是使用简单,api也比较强大,备份也不例外。简单来说,备份分两步:
创建一个仓库备份指定索引
 
一、创建存储仓库
 
共享文件系统实例如下:
curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup
{
"type": "fs",
"settings": {
"location": "/mount/EsDataBackupDir"
}
}上面代码解释:
创建了一个名为EsBackup的存仓库指定的备份方式为共享文件系统(type: fs)指定共享存储的具体路径(location参数)
注意:共享存储路径,必须是所有的ES节点都可以访问的,最简单的就是nfs系统,然后每个节点都需要挂载到本地。
 
如上所示,创建存储仓库的时候,除了可以指定location参数以外,我们还可以指点max_snapshot_bytes_per_sec和max_restore_bytes_per_sec参数来限制备份和恢复时的速度,默认值都是20mb/s,假设我们有一个非常快的网络环境,我们可以增大默认值:
curl -XPOST http://127.0.0.1:9200/_snapshot/EsBackup
{
"type": "fs",
"settings": {
"location": "/mount/EsDataBackupDir"
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}注意:这是在第一段代码的基础上来增加配置,第一段代码利用的是PUT请求来创建存储库,这段代码则是利用POST请求来更新已经存在的存储库的settings配置。 
Amazon S3存储库实例如下:
curl -XPUT 'http://localhost:9200/_snapshot/s3-backup' -d '{
"type": "s3",
"settings": {
"bucket": "esbackup",
"region": "cn-north-1",
"access_key": "xxooxxooxxoo",
"secret_key": "xxxxxxxxxooooooooooooyyyyyyyyy"
}
}'参数名词解释:
Type: 仓库类型Setting: 仓库的额外信息Region: AWS RegionAccess_key: 访问秘钥Secret_key: 私有访问秘钥Bucket: 存储桶名称
不同的ES版本支持的region参考:https://github.com/elastic/elasticsearch-cloud-aws#aws-cloud-plugin-for-elasticsearch
 
使用上面的命令,创建一个仓库(s3-backup),并且还创建了存储桶(esbackup),返回{"acknowledged":true} 信息证明创建成功。
 
确认存储桶是否创建成功:curl -XPOST http://localhost:9200/_snapshot/s3-backup/_verify
查看刚创建的存储桶:curl -XGET localhost:9200/_snapshot/s3-backup?pretty
查看所有的存储桶:curl -XGET localhost:9200/_snapshot/_all?pretty
删除一个快照存储桶:curl -XDELETE localhost:9200/_snapshot/s3-backup?pretty
 
二、备份索引
创建好存储仓库之后就可以开始备份了。一个仓库可以包含多个快照(snapshots),快照可以存所有的索引或者部分索引,当然也可以存储一个单独的索引。(要注意的一点就是快照只会备份open状态的索引,close状态的不会备份)
 
 
备份所有索引
curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup/snapshot_all上面的代码会将所有正在运行的open状态的索引,备份到EsBacup仓库下一个叫snapshot_all的快照中。上面的api会立刻返回{"accepted":true},然后备份工作在后台运行。如果你想api同步执行,可以加wait_for_completion 标志:
curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup/snapshot_all?wait_for_completion=true上面的方法会在备份完全完成后才返回,如果快照数据量大的话,会花很长时间。

备份部分索引
默认是备份所有open状态的索引,如果你想只备份某些或者某个索引,可以指定indices参数来完成:
curl -XPUT 'http://localhost:9200/_snapshot/EsBackup/snapshot_12' -d '{ "indices": "index_1,index_2" }'


 查看快照信息
查看快照信息,只需要发起GET请求就好:
GET _snapshot/my_backup/snapshot_2这将返回关于快照snapshot_2的详细信息:
{
"snapshots": [
{
"snapshot": "snapshot_2",
"indices": [
".marvel_2014_28_10",
"index1",
"index2"
],
"state": "SUCCESS",
"start_time": "2014-09-02T13:01:43.115Z",
"start_time_in_millis": 1409662903115,
"end_time": "2014-09-02T13:01:43.439Z",
"end_time_in_millis": 1409662903439,
"duration_in_millis": 324,
"failures": [],
"shards": {
"total": 10,
"failed": 0,
"successful": 10
}
}
]
}查看所有快照信息如下:
GET http://127.0.0.1:9200/_snapshot/my_backup/_all另外还有个一api可以看到更加详细的信息:
GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2/_status
更多详细内容可以到官网查看-官方文档地址。
 
删除快照
DELETE _snapshot/my_backup/snapshot_2重要的是使用API来删除快照,而不是其他一些机制(如手工删除,或使用自动s3清理工具)。因为快照增量,它是可能的,许多快照依靠old seaments。删除API了解最近仍在使用的数据快照,并将只删除未使用的部分。如果你手动文件删除,但是,你有可能严重破坏你的备份,因为你删除数据仍在使用,如果备份正在后台进行,也可以直接删除来取消此次备份。
 
监控快照进展
wait_for_completion标志提供了一个基本形式的监控,但没有足够的快照恢复甚至中等大小的集群。
 
另外两个api会给你更细节的状态的快照。首先你可以执行一个快照ID,就像我们早些时候得到一个特定的快照信息:
GET _snapshot/my_backup/snapshot_3如果当你调用这个快照还在进步,你会看到信息的时候开始,已经运行多长时间,等等。但是请注意,这个API使用相同的threadpool快照机制。如果你是快照非常大的碎片,之间的时间状态更新可以相当大,因为API是争夺相同的threadpool资源。
 
这时候有个更好的选择_status的api接口:
GET _snapshot/my_backup/snapshot_3/_status_status API立即返回并给出一个更详细的输出的统计:
{
"snapshots": [
{
"snapshot": "snapshot_3",
"repository": "my_backup",
"state": "IN_PROGRESS",
"shards_stats": {
"initializing": 0,
"started": 1,
"finalizing": 0,
"done": 4,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"indices": {
"index_3": {
"shards_stats": {
"initializing": 0,
"started": 0,
"finalizing": 0,
"done": 5,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"shards": {
"0": {
"stage": "DONE",
"stats": {
"number_of_files": 1,
"processed_files": 1,
"total_size_in_bytes": 514,
"processed_size_in_bytes": 514,
"start_time_in_millis": 1409663054862,
"time_in_millis": 22
}
},
...快照当前运行将显示IN_PROGRESS作为其状态,这个特定的快照有一个碎片仍然转移(其他四个已经完成)。
 
响应包括总体状况的快照,但还深入每和每个实例统计数据。这给你一个令人难以置信的详细视图快照是如何进展的。碎片可以以不同的方式完成:
INITIALIZING: 集群的碎片是检查状态是否可以快照。这通常是非常快。
STARTED:数据被转移到存储库。
FINALIZING:数据传输完成;碎片现在发送快照的元数据。
DONE:快照完成。
FAILED:在快照过程中错误的出处,这碎片/索引/快照无法完成。检查你的日志以获取更多信息。
 

恢复

备份好后,恢复就更容易了,恢复snapshot_1里的全部索引:
POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore这个api还有额外的参数:
POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
{
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}参数indices 设置只恢复index_1索引,参数rename_pattern 和rename_replacement用来正则匹配要恢复的索引,并且重命名。和备份一样,api会立刻返回值,然后在后台执行恢复,使用wait_for_completion 标记强制同步执行。
 
另外可以使用下面两个api查看状态:
GET http://127.0.0.1:9200/_recovery/restored_index_3
GET http://127.0.0.1:9200/_recovery/如果要取消恢复过程(不管是已经恢复完,还是正在恢复),直接删除索引即可:
DELETE http://127.0.0.1:9200/restored_index_3更多内容参考-官方文档。
 
参考官方文档地址:

1、https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html#_listing_information_about_snapshots
2、https://www.elastic.co/guide/en/elasticsearch/guide/current/_restoring_from_a_snapshot.html 查看全部
elasticsearch.png


备份


备份数据之前,要创建一个仓库来保存数据,仓库的类型支持共享文件系统、Amazon S3、 HDFS和Azure Cloud。 
 
Elasticsearch的一大特点就是使用简单,api也比较强大,备份也不例外。简单来说,备份分两步:
  1. 创建一个仓库
  2. 备份指定索引

 
一、创建存储仓库
 
共享文件系统实例如下:
curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup
{
"type": "fs",
"settings": {
"location": "/mount/EsDataBackupDir"
}
}
上面代码解释:
  1. 创建了一个名为EsBackup的存仓库
  2. 指定的备份方式为共享文件系统(type: fs)
  3. 指定共享存储的具体路径(location参数)

注意:共享存储路径,必须是所有的ES节点都可以访问的,最简单的就是nfs系统,然后每个节点都需要挂载到本地。
 
如上所示,创建存储仓库的时候,除了可以指定location参数以外,我们还可以指点max_snapshot_bytes_per_secmax_restore_bytes_per_sec参数来限制备份和恢复时的速度,默认值都是20mb/s,假设我们有一个非常快的网络环境,我们可以增大默认值:
curl -XPOST http://127.0.0.1:9200/_snapshot/EsBackup
{
"type": "fs",
"settings": {
"location": "/mount/EsDataBackupDir"
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}
注意:这是在第一段代码的基础上来增加配置,第一段代码利用的是PUT请求来创建存储库,这段代码则是利用POST请求来更新已经存在的存储库的settings配置。 
Amazon S3存储库实例如下:
curl -XPUT 'http://localhost:9200/_snapshot/s3-backup' -d '{
"type": "s3",
"settings": {
"bucket": "esbackup",
"region": "cn-north-1",
"access_key": "xxooxxooxxoo",
"secret_key": "xxxxxxxxxooooooooooooyyyyyyyyy"
}
}'
参数名词解释:
  1. Type: 仓库类型
  2. Setting: 仓库的额外信息
  3. Region: AWS Region
  4. Access_key: 访问秘钥
  5. Secret_key: 私有访问秘钥
  6. Bucket: 存储桶名称

不同的ES版本支持的region参考:https://github.com/elastic/elasticsearch-cloud-aws#aws-cloud-plugin-for-elasticsearch
 
使用上面的命令,创建一个仓库(s3-backup),并且还创建了存储桶(esbackup),返回{"acknowledged":true} 信息证明创建成功。
 
确认存储桶是否创建成功:curl -XPOST http://localhost:9200/_snapshot/s3-backup/_verify
查看刚创建的存储桶:curl -XGET localhost:9200/_snapshot/s3-backup?pretty
查看所有的存储桶:curl -XGET localhost:9200/_snapshot/_all?pretty
删除一个快照存储桶:curl -XDELETE localhost:9200/_snapshot/s3-backup?pretty
 
二、备份索引
创建好存储仓库之后就可以开始备份了。一个仓库可以包含多个快照(snapshots),快照可以存所有的索引或者部分索引,当然也可以存储一个单独的索引。(要注意的一点就是快照只会备份open状态的索引,close状态的不会备份)
 
 
备份所有索引
curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup/snapshot_all
上面的代码会将所有正在运行的open状态的索引,备份到EsBacup仓库下一个叫snapshot_all的快照中。上面的api会立刻返回{"accepted":true},然后备份工作在后台运行。如果你想api同步执行,可以加wait_for_completion 标志:
curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup/snapshot_all?wait_for_completion=true
上面的方法会在备份完全完成后才返回,如果快照数据量大的话,会花很长时间。

备份部分索引
默认是备份所有open状态的索引,如果你想只备份某些或者某个索引,可以指定indices参数来完成:
curl -XPUT 'http://localhost:9200/_snapshot/EsBackup/snapshot_12' -d '{ "indices": "index_1,index_2" }'


 查看快照信息
查看快照信息,只需要发起GET请求就好:
GET _snapshot/my_backup/snapshot_2
这将返回关于快照snapshot_2的详细信息:
{
"snapshots": [
{
"snapshot": "snapshot_2",
"indices": [
".marvel_2014_28_10",
"index1",
"index2"
],
"state": "SUCCESS",
"start_time": "2014-09-02T13:01:43.115Z",
"start_time_in_millis": 1409662903115,
"end_time": "2014-09-02T13:01:43.439Z",
"end_time_in_millis": 1409662903439,
"duration_in_millis": 324,
"failures": [],
"shards": {
"total": 10,
"failed": 0,
"successful": 10
}
}
]
}
查看所有快照信息如下:
GET http://127.0.0.1:9200/_snapshot/my_backup/_all
另外还有个一api可以看到更加详细的信息:
GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2/_status
更多详细内容可以到官网查看-官方文档地址
 
删除快照
DELETE _snapshot/my_backup/snapshot_2
重要的是使用API来删除快照,而不是其他一些机制(如手工删除,或使用自动s3清理工具)。因为快照增量,它是可能的,许多快照依靠old seaments。删除API了解最近仍在使用的数据快照,并将只删除未使用的部分。如果你手动文件删除,但是,你有可能严重破坏你的备份,因为你删除数据仍在使用,如果备份正在后台进行,也可以直接删除来取消此次备份。
 
监控快照进展
wait_for_completion标志提供了一个基本形式的监控,但没有足够的快照恢复甚至中等大小的集群。
 
另外两个api会给你更细节的状态的快照。首先你可以执行一个快照ID,就像我们早些时候得到一个特定的快照信息:
GET _snapshot/my_backup/snapshot_3
如果当你调用这个快照还在进步,你会看到信息的时候开始,已经运行多长时间,等等。但是请注意,这个API使用相同的threadpool快照机制。如果你是快照非常大的碎片,之间的时间状态更新可以相当大,因为API是争夺相同的threadpool资源。
 
这时候有个更好的选择_status的api接口:
GET _snapshot/my_backup/snapshot_3/_status
_status API立即返回并给出一个更详细的输出的统计:
{
"snapshots": [
{
"snapshot": "snapshot_3",
"repository": "my_backup",
"state": "IN_PROGRESS",
"shards_stats": {
"initializing": 0,
"started": 1,
"finalizing": 0,
"done": 4,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"indices": {
"index_3": {
"shards_stats": {
"initializing": 0,
"started": 0,
"finalizing": 0,
"done": 5,
"failed": 0,
"total": 5
},
"stats": {
"number_of_files": 5,
"processed_files": 5,
"total_size_in_bytes": 1792,
"processed_size_in_bytes": 1792,
"start_time_in_millis": 1409663054859,
"time_in_millis": 64
},
"shards": {
"0": {
"stage": "DONE",
"stats": {
"number_of_files": 1,
"processed_files": 1,
"total_size_in_bytes": 514,
"processed_size_in_bytes": 514,
"start_time_in_millis": 1409663054862,
"time_in_millis": 22
}
},
...
快照当前运行将显示IN_PROGRESS作为其状态,这个特定的快照有一个碎片仍然转移(其他四个已经完成)。
 
响应包括总体状况的快照,但还深入每和每个实例统计数据。这给你一个令人难以置信的详细视图快照是如何进展的。碎片可以以不同的方式完成:
INITIALIZING: 集群的碎片是检查状态是否可以快照。这通常是非常快。
STARTED:数据被转移到存储库。
FINALIZING:数据传输完成;碎片现在发送快照的元数据。
DONE:快照完成。
FAILED:在快照过程中错误的出处,这碎片/索引/快照无法完成。检查你的日志以获取更多信息。
 


恢复


备份好后,恢复就更容易了,恢复snapshot_1里的全部索引:
POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
这个api还有额外的参数:
POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
{
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}
参数indices 设置只恢复index_1索引,参数rename_pattern 和rename_replacement用来正则匹配要恢复的索引,并且重命名。和备份一样,api会立刻返回值,然后在后台执行恢复,使用wait_for_completion 标记强制同步执行。
 
另外可以使用下面两个api查看状态:
GET http://127.0.0.1:9200/_recovery/restored_index_3
GET http://127.0.0.1:9200/_recovery/
如果要取消恢复过程(不管是已经恢复完,还是正在恢复),直接删除索引即可:
DELETE http://127.0.0.1:9200/restored_index_3
更多内容参考-官方文档
 
参考官方文档地址:


1、https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html#_listing_information_about_snapshots
2、https://www.elastic.co/guide/en/elasticsearch/guide/current/_restoring_from_a_snapshot.html


Kafka性能测试

chris 发表了文章 • 0 个评论 • 506 次浏览 • 2016-10-13 23:24 • 来自相关话题

测试背景

Apache Kafka是一种高吞吐、可扩展的分布式消息队列服务,它最初由LinkedIn公司开发,最后发展为Apache基金会的一个项目。目前kafka已经广泛应用于大数据分析,消息处理等环境,官方文档介绍kafka为提高吞吐率做了很多设计,但是其性能究竟如何呢?本文对kafka在不同参数下的性能进行测试。

测试目标

测试kafka 0.8n的性能(Producer/Consumer性能)。当消息大小、批处理大小、压缩等参数变化时对吞吐率的影响。



测试环境

软件版本:kafka 0.8.1.1
硬件环境:3台多磁盘服务组成的kafka集群。各服务器CPU E5645,内存47G,12快SAS盘,配置千兆网卡,配置如下:





测试方法

使用kafka官方提供的kafa-perf工具做性能测试,在测试时使用ganglia,kafka Web Console来记录服务情况。

测试步骤

一、测试环境准备
1、测试工具kafka-perf编译
kafka官方提供的二进制版本,并不包括性能测试的jar包,会报错找不到ProducerPerformance,要自己重新编译,编译方法如下:git clone https://git-wip-us.apache.org/repos/asf/kafka.git kafka.git
cd kafka.git/
git checkout -b 0.8.1 origin/0.8.1
vim build.gradle #编辑配置
./gradlew -PscalaVersion=2.10.4 perf:jar #生成2.10.4的kafka-perf的jar包,复制到libs目录下
cp perf/build/libs/kafka-perf_2.10-0.8.1.1-SNAPSHOT.jar /usr/local/kafka/libs/
2、启动kafkacd /usr/local/kafka
vim config/server.properties #内容见下图
./bin/kafka-server-start.sh config/server.properties &



kafka-producer-perf-test.sh中参数说明:messages 生产者发送走的消息数量
message-size 每条消息的大小
batch-size 每次批量发送消息的数量
topics 生产者发送的topic
threads 生产者
broker-list 安装kafka服务的机器ip:porta列表
producer-num-retries 一个消息失败发送重试次数
request-timeouts-ms 一个消息请求发送超时时间bin/kafka-consumer-perf-test.sh中参数说明:zookeeper zk配置
messages 消费者消费消息的总数量
topic 消费者需要消费的topic
threads 消费者使用几个线程同时消费
group 消费者组名称
socket-buffer-sizes socket缓存大小
fetch-size 每次想kafka broker请求消费消息大小
consumer.timeout.ms 消费者去kafka broker拿一条消息的超时时间
二、测试生产者吞吐率
此项只测试producer在不同的batch-zie,patition等参数下的吞吐率,也就是数据只被及计划,没有consumer读取数据消费情况。
生成Topic:
生成不同复制因子,partition的topicbin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati1-rep1 --partitions 1 --replication-factor 1
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati1-rep2 --partitions 1 --replication-factor 2

bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati10-rep1 --partitions 10 --replication-factor 1
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati10-rep2 --partitions 10 --replication-factor 2

bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati100-rep1 --partitions 100 --replication-factor 1
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati100-rep2 --partitions 100 --replication-factor 2测试producer吞吐率
调整batch-size,thread,topic,压缩等参数测试producer吞吐率。
示例:a)批处理为1,线程数为1,partition为1,复制因子为1
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 1 --topic test-pati1-rep1
--partitions 1 --threads 1 --broker-list host1:9092,host2:9092,host3:9092

b)批处理为10,线程数为1,partition为1,复制因子为2
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 10 --topic test-pati1-rep2
--partitions 1 --threads 1 --broker-list host1:9092,host2:9092,host3:9092

c)批处理为100,线程数为10,partition为10,复制因子为2,不压缩,sync
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 100 --topic test-pati10-rep2 --partitions 10 --threads 10 --compression-codec 0 --sync 1 --broker-list host1:9092,host2:9092,host3:9092

d)批处理为100,线程数为10,partition为10,复制因子为2,gzip压缩,sync
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 100 --topic test-pati10-rep2 --partitions 10 --threads 10 --compression-codec 1 --sync 1 --broker-list host1:9092,host2:9092,host3:9092说明:消息大小统一使用和业务场景中日志大小相近的512Bype,消息数为50w或200w条。
 
三、测试消费者吞吐率
测试consumer吞吐率
调整批处理数,线程数,partition数,复制因子,压缩等进行测试。
示例:a)批处理为10,线程数为10,partition为1,复制因子为1
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 10 --topic test-pai1-rep2 --partitions 1 --threads 10 --zookeeper zkhost:2181/kafka/k1001

b)批处理为10,线程数为10,partition为10,复制因子为2
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 10 --topic test-pai1-rep2 --partitions 10 --threads 10 --zookeeper zkhost:2181/kafka/k1001

c)批处理为100,线程数为10,partition为1,复制因子为1,不压缩
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 100 --topic test-pai100-rep1 --partitions 1 --threads 10 --compression-codec 0 --zookeeper zkhost:2181/kafka/k1001

d)批处理为100,线程数为10,partition为1,复制因子为1,Snappy压缩
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 100 --topic test-pai100-rep1 --partitions 1 --threads 10 --compression-codec 2 --zookeeper zkhost:2181/kafka/k1001

测试结果及分析

1、生产者测试结果及分析
调整线程数,批处理数,复制因子等参考,对producer吞吐率进行测试。在测试时消息大小为512Byte,消息数为200w,结果如下:












调整sync模式,压缩方式得到吞吐率数据如表3.在本次测试中msg=512Byte,message=2000000,Partition=10,batch_zie=100








 
结果分析:
1)kafka在批处理,多线程,不适用同步复制的情况下,吞吐率是比较高的,可以达80MB/s,消息数达17w条/s以上。
2)使用批处理或多线程对提升生产者吞吐率效果明显。




3)复制因子会对吞吐率产生较明显影响
   使用同步复制时,复制因子会对吞吐率产生较明显的影响。复制因子为2比因子为1(即无复制)时,吞吐率下降40%左右。




4)使用sync方式,性能有明显下降。
   使用Sync方式producer吞吐率会有明显下降,表3中async方式最大吞吐率由82.0MB/s,而使用sync方式时吞吐率只有13.33MB/s.
 




5)压缩与吞吐率
  见图3,粉笔使用Gzip及Snappy方式压缩,吞吐率反而有下降,原因待分析。而Snappy方式吞吐率高于gzip方式。

6)分区数与吞吐率
   分区数增加生产者吞吐率反而有所下降 
 
2、消费者结果及分析
调整批处理数,分区数,复制因子等参数,对consumer吞吐率进行测试。在测试时消息大小为512Byte,消息数为200结果如下:  
 








调整压缩方式,分区数,批处理数等,测试参数变化时consumer的吞吐率。测试的复制因子为1。








结果分析:1)kafka consumer吞吐率在parition,threads较大的情况下,在测试场景下,最大吞吐率达到了123MB/s,消息数为25w条/s

2)复制因子,影响较小。replication factor并不会影响consumer的吞吐率测试,运维consumer智慧从每个partition的leader读数据,而与replication factor无关。同样,consumer吞吐率也与同步复制还是异步复制无关。




3)线程数和partition与吞吐率关系




图5为msg_size=512,batch_zie=100时的测试数据备份。可以看到当分区数较大时,如partion为100时,增加thread数可显著提升consumer的吞吐率。Thread10较thread1提升了10倍左右,而thread为100时叫thread为1提升了近20倍,达到120MB/s.

但要注意在分区较大时线程数不改大于分区数,否则会出现No broker partitions consumed by consumer,对提升吞吐率也没有帮助。图5中partion为10时,thread_10,thread_100吞吐率相近都为35MB/s左右。
4)批处理数对吞吐率影响
图表5中可以看出改变批处理数对吞吐率影响不大

5)压缩与吞吐率




图表6当thread=10,复制因子=1不压缩,Gzip,Snappy时不同parititon时Concumser吞吐率。由上图可以看到此场景下,压缩对吞吐率影响小。 查看全部
kafka.png


测试背景


Apache Kafka是一种高吞吐、可扩展的分布式消息队列服务,它最初由LinkedIn公司开发,最后发展为Apache基金会的一个项目。目前kafka已经广泛应用于大数据分析,消息处理等环境,官方文档介绍kafka为提高吞吐率做了很多设计,但是其性能究竟如何呢?本文对kafka在不同参数下的性能进行测试。


测试目标


测试kafka 0.8n的性能(Producer/Consumer性能)。当消息大小、批处理大小、压缩等参数变化时对吞吐率的影响。



测试环境


软件版本:kafka 0.8.1.1
硬件环境:3台多磁盘服务组成的kafka集群。各服务器CPU E5645,内存47G,12快SAS盘,配置千兆网卡,配置如下:
configure.png


测试方法


使用kafka官方提供的kafa-perf工具做性能测试,在测试时使用ganglia,kafka Web Console来记录服务情况。


测试步骤


一、测试环境准备
1、测试工具kafka-perf编译
kafka官方提供的二进制版本,并不包括性能测试的jar包,会报错找不到ProducerPerformance,要自己重新编译,编译方法如下:
git clone https://git-wip-us.apache.org/repos/asf/kafka.git kafka.git
cd kafka.git/
git checkout -b 0.8.1 origin/0.8.1
vim build.gradle #编辑配置
./gradlew -PscalaVersion=2.10.4 perf:jar #生成2.10.4的kafka-perf的jar包,复制到libs目录下
cp perf/build/libs/kafka-perf_2.10-0.8.1.1-SNAPSHOT.jar /usr/local/kafka/libs/

2、启动kafka
cd /usr/local/kafka
vim config/server.properties #内容见下图
./bin/kafka-server-start.sh config/server.properties &
KafkaConfig.png

kafka-producer-perf-test.sh中参数说明:
messages 生产者发送走的消息数量
message-size 每条消息的大小
batch-size 每次批量发送消息的数量
topics 生产者发送的topic
threads 生产者
broker-list 安装kafka服务的机器ip:porta列表
producer-num-retries 一个消息失败发送重试次数
request-timeouts-ms 一个消息请求发送超时时间
bin/kafka-consumer-perf-test.sh中参数说明:
zookeeper  zk配置
messages 消费者消费消息的总数量
topic 消费者需要消费的topic
threads 消费者使用几个线程同时消费
group 消费者组名称
socket-buffer-sizes socket缓存大小
fetch-size 每次想kafka broker请求消费消息大小
consumer.timeout.ms 消费者去kafka broker拿一条消息的超时时间

二、测试生产者吞吐率
此项只测试producer在不同的batch-zie,patition等参数下的吞吐率,也就是数据只被及计划,没有consumer读取数据消费情况。
生成Topic:
生成不同复制因子,partition的topic
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati1-rep1 --partitions 1 --replication-factor 1
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati1-rep2 --partitions 1 --replication-factor 2

bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati10-rep1 --partitions 10 --replication-factor 1
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati10-rep2 --partitions 10 --replication-factor 2

bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati100-rep1 --partitions 100 --replication-factor 1
bin/kafka-topics.sh --zookeepr 10.x.x.x:2181/kafka/k1001 --create --topic test-pati100-rep2 --partitions 100 --replication-factor 2
测试producer吞吐率
调整batch-size,thread,topic,压缩等参数测试producer吞吐率。
示例:
a)批处理为1,线程数为1,partition为1,复制因子为1
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 1 --topic test-pati1-rep1
--partitions 1 --threads 1 --broker-list host1:9092,host2:9092,host3:9092

b)批处理为10,线程数为1,partition为1,复制因子为2
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 10 --topic test-pati1-rep2
--partitions 1 --threads 1 --broker-list host1:9092,host2:9092,host3:9092

c)批处理为100,线程数为10,partition为10,复制因子为2,不压缩,sync
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 100 --topic test-pati10-rep2 --partitions 10 --threads 10 --compression-codec 0 --sync 1 --broker-list host1:9092,host2:9092,host3:9092

d)批处理为100,线程数为10,partition为10,复制因子为2,gzip压缩,sync
bin/kafka-producer-perf-test.sh --messages 2000000 --message-size 512 --batch-size 100 --topic test-pati10-rep2 --partitions 10 --threads 10 --compression-codec 1 --sync 1 --broker-list host1:9092,host2:9092,host3:9092
说明:消息大小统一使用和业务场景中日志大小相近的512Bype,消息数为50w或200w条。
 
三、测试消费者吞吐率
测试consumer吞吐率
调整批处理数,线程数,partition数,复制因子,压缩等进行测试。
示例:
a)批处理为10,线程数为10,partition为1,复制因子为1
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 10 --topic test-pai1-rep2 --partitions 1 --threads 10 --zookeeper zkhost:2181/kafka/k1001

b)批处理为10,线程数为10,partition为10,复制因子为2
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 10 --topic test-pai1-rep2 --partitions 10 --threads 10 --zookeeper zkhost:2181/kafka/k1001

c)批处理为100,线程数为10,partition为1,复制因子为1,不压缩
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 100 --topic test-pai100-rep1 --partitions 1 --threads 10 --compression-codec 0 --zookeeper zkhost:2181/kafka/k1001

d)批处理为100,线程数为10,partition为1,复制因子为1,Snappy压缩
./bin/kafka-consumer-perf-test.sh --messages 500000 --batch-size 100 --topic test-pai100-rep1 --partitions 1 --threads 10 --compression-codec 2 --zookeeper zkhost:2181/kafka/k1001


测试结果及分析


1、生产者测试结果及分析
调整线程数,批处理数,复制因子等参考,对producer吞吐率进行测试。在测试时消息大小为512Byte,消息数为200w,结果如下:
pic1.png

pic2.png

pic3.png

调整sync模式,压缩方式得到吞吐率数据如表3.在本次测试中msg=512Byte,message=2000000,Partition=10,batch_zie=100
pic4.png

pic5.png

 
结果分析:
1)kafka在批处理,多线程,不适用同步复制的情况下,吞吐率是比较高的,可以达80MB/s,消息数达17w条/s以上。
2)使用批处理或多线程对提升生产者吞吐率效果明显。
p1.png

3)复制因子会对吞吐率产生较明显影响
   使用同步复制时,复制因子会对吞吐率产生较明显的影响。复制因子为2比因子为1(即无复制)时,吞吐率下降40%左右。
p2.png

4)使用sync方式,性能有明显下降。
   使用Sync方式producer吞吐率会有明显下降,表3中async方式最大吞吐率由82.0MB/s,而使用sync方式时吞吐率只有13.33MB/s.
 
p3.png

5)压缩与吞吐率
  见图3,粉笔使用Gzip及Snappy方式压缩,吞吐率反而有下降,原因待分析。而Snappy方式吞吐率高于gzip方式。

6)分区数与吞吐率
   分区数增加生产者吞吐率反而有所下降 
 
2、消费者结果及分析
调整批处理数,分区数,复制因子等参数,对consumer吞吐率进行测试。在测试时消息大小为512Byte,消息数为200结果如下:  
 
c1.png

c2.png

调整压缩方式,分区数,批处理数等,测试参数变化时consumer的吞吐率。测试的复制因子为1。
c3.png

c4.png

结果分析:1)kafka consumer吞吐率在parition,threads较大的情况下,在测试场景下,最大吞吐率达到了123MB/s,消息数为25w条/s

2)复制因子,影响较小。replication factor并不会影响consumer的吞吐率测试,运维consumer智慧从每个partition的leader读数据,而与replication factor无关。同样,consumer吞吐率也与同步复制还是异步复制无关。
r1.png

3)线程数和partition与吞吐率关系
r2.png

图5为msg_size=512,batch_zie=100时的测试数据备份。可以看到当分区数较大时,如partion为100时,增加thread数可显著提升consumer的吞吐率。Thread10较thread1提升了10倍左右,而thread为100时叫thread为1提升了近20倍,达到120MB/s.

但要注意在分区较大时线程数不改大于分区数,否则会出现No broker partitions consumed by consumer,对提升吞吐率也没有帮助。图5中partion为10时,thread_10,thread_100吞吐率相近都为35MB/s左右。
4)批处理数对吞吐率影响
图表5中可以看出改变批处理数对吞吐率影响不大

5)压缩与吞吐率
r3.png

图表6当thread=10,复制因子=1不压缩,Gzip,Snappy时不同parititon时Concumser吞吐率。由上图可以看到此场景下,压缩对吞吐率影响小。

zookeeper客户端连接zookeeper服务器策略是什么?

采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 274 次浏览 • 2016-10-11 12:29 • 来自相关话题

Elasticsearch怎么备份和迁移数据

OpenSkill 回复了问题 • 2 人关注 • 1 个回复 • 528 次浏览 • 2016-09-30 12:19 • 来自相关话题

OVM混合虚拟化设计目标及设计思路

maoliang 发表了文章 • 0 个评论 • 282 次浏览 • 2016-09-29 09:42 • 来自相关话题

1、OVM虚拟化的目标:

OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产品要么架构太大,开发难度高,易用性不够强,要么就是单纯的虚拟化,类似vmware等。

新形式下,我们需要的产品要同时具备如下目标:

跨平台,支持KVM、Esxi和Docker容器

因为我们单位过去采用虚拟化技术混杂,上面又遗留很多虚拟机,这就要求我们新开发产品能够兼容不同hypervior,同时还能识别并管理原有hypervior上的虚拟机,能够识别并导入原数据库技术并不难,难的是导入后还能纳入新平台管理,这部分我们又研发了自动捕获技术,而不同混合虚拟化管理技术可以摆脱对底层Hypervisor的依赖,专心于资源的统一管理。

单独的用户自助服务门户

过去采用传统虚拟化时,解决了安装部署的麻烦,但资源的申请和扩容、准备资源和切割资源仍然没有变,还是要让我们做,占据了日常运维工作的大部分工作量,每天确实烦人,所以我们想而这部分工作是可以放给相关的部门Leader或者专员,来减少运维的工作量,所以我们希望新设计的OVM允许用户通过一个单独的Web门户来直接访问自己的资源(云主机、云硬盘、网络等),而且对自己的资源进行管理,而不需要知道资源的具体位置,同时用户的所有云主机都建立在高可用环境之上,也不必担心实际物理硬件故障引起服务瘫痪。

Opscode Chef自动化运维集成

实行自助服务后,有一个问题,就是软件不同版本部署不兼容,这就需要设计能够把操作系统、中间件、数据库、web能统一打包部署,减少自助用户哭天喊地甚至骂我们,我们通过对chef的集成,可以一键更新所有的虚拟机,在指定的虚拟机上安装指定的软件。有了chef工具,为虚拟机打补丁、安装软件,只需要几个简单的命令即可搞定。

可持续性

做运维不要故障处理办法是不行,而且还要自动化的,同时我们有vmware和kvm,就需要新平台能在esxi上(不要vcenter,要付钱的)和kvm同时实现ha功能

可运维性
一个平台再强大,技术再厉害,如果不可运维,那结果可想而知。因此我们希望OVM可以给用户带来一个稳定、可控、安全的生产环境

弹性伸缩
自助服务部门拿到资源后,通过对各项目资源的限额,以及对各虚拟机和容器性能指标的实时监控,可以实现弹性的资源伸缩,达到合理分配利用资源。

资源池化
将数据中心的计算、存储、网络资源全部池化,然后通过OVM虚拟化平台统一对外提供IaaS服务。

2、OVM设计思路

OVM架构选型一

我们觉得架构就是一个产品的灵魂所在,决定着产品日后的发展。

我们团队在产品选型初期,分别调研了目前比较热门的openstack,以及前几年的明星产品convirt、ovirt,这几个产品可谓是典型的代表。

Openstack偏重于公有云,架构设计的很不错,其分布式、插件式的模块化架构,可以有效避免单点故障的发生,从发布之初便备受推崇,但是其存在的问题也同样令人头疼目前使用Openstack的大多是一些有实力的IDC、大型的互联网公司在用。而对于一般的企业来说,没有强大的开发和维护团队,并不敢大规模的采用openstack,初期使用一段时间后我们放弃了OS。

而前几年的convirt,在当时也掀起了一股使用热潮,其简单化的使用体验,足以满足小企业的虚拟化需求,但是他的问题是架构采用了集中式的架构,而且对于上了规模之后,也会带来性能方面的瓶颈,除非是把数据库等一些组件松藕合,解决起来也比较麻烦,所以到了后期也是不温不火,官方也停止了社区的更新和维护。

OVM架构选型二

      通过对以上产品的优劣势分析,我们决定采用用分布式、松耦合的模块化插件架构,分布式使其可以规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的我们即将需要的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

而目前阶段我们则专心于实现虚拟化的全部功能,发掘内部对虚拟化的需求,打造一款真正简单、易用、稳定、可运维的一款虚拟化管理软件,并预留向上、向下的接口留作后期发展。(架构图大家可以查看刚才上面发的图片)

虚拟化技术选择

    Docker当下很火,其轻量级、灵活、高密度部署是优点,但是大规模使用还未成熟。许多场景还是需要依赖传统的虚拟化技术。所以我们选择传统虚拟化技术KVM+Docker,确保线上业务稳定性、连续性的同时,开发、测试环境又可以利用到Docker的轻量级、高密度和灵活。

     另外很多用户的生产环境存在不止一种虚拟化技术,例如KVM+Esxi组合、KVM+XenServer组合、KVM+Hyper-V组合,而目前的虚拟化管理平台,大多都是只支持一种Hypervisor的管理,用户想要维护不同的虚拟化技术的虚拟机,就要反复的在不同环境之间切换。

    基于此考虑,我和团队内部和外部一些同行选择兼容(兼容KVM、Esxi,Docker),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 网络方面,我们对所有Hypervisor的虚拟机使用统一的网络管理(包括Docker容器),这样做的一个好处就是可以减少运维工作量,降低网络复杂性。初期我们只实现2层的虚拟网络管理,为虚拟机和容器提供Vlan隔离、DHCP分配网络,当然也可以手工为虚拟机挑选一个网络,这个可以满足一般的虚拟化需求,后期我们会在此基础上增加虚拟网络防火墙、负载均衡。

存储

存储上面我们采用本地存储+NFS两种方式,对于一般中小企业来说,不希望购买高昂的商业存储,直接使用本地存储虚拟机的性能是最好的,而且我们也提供了存储快照、存储热迁移、虚拟机的无共享热迁移来提升业务安全。此外NFS作为辅助,可以为一些高风险业务提供HA。后期存储方面我们会考虑集成Ceph和GlusterFS存储来提升存储管理。

镜像中心

顾名思义,镜像中心就是用来存放镜像的。传统虚拟化我们使用NFS来作为镜像中心,所有宿主机共享一个镜像中心,这样可以更方便的来统一管理镜像,而针对Docker容器则保留了使用Docker自己的私有仓库,但是我们在WEB UI的镜像中心增加了从Docker私有仓库下载模板这么一个功能,实现了在同一个镜像中心的管理,后期我们会着重打造传统虚拟化镜像与Docker镜像的相互转换,实现两者内容的统一。

HA

OVM 主机HA依然坚持全兼容策略,支持对可管理的所有Hypervisor的HA。

在启用HA的资源池,当检测到一个Hypervisor故障,创建和运行在该Hypervisor共享存储上的虚拟机将在相同资源池下的另外一个主机上重启。

具体工作流程为:

第一次检测到故障会将该故障主机标记;

第二次检测依然故障将启动迁移任务;

迁移任务启动后将在该故障主机所在的资源池寻找合适的主机;

确定合适主机后,会将故障主机上所有的虚拟机自动迁移到合适的主机上面并重新启动;

 

VM分配策略

负载均衡

PERFORMANCE(性能): 这条策略分配虚拟机到不同的主机上。它挑选一组中可用资源最多的主机来部署虚拟机。如果有多个主机都有相同的资源可用,它使用一个循环算法,每个虚拟机分配到一个不同的主机上。

PROGRESSIVE(逐行扫描): 这条策略意味着,所有虚拟机将被分配在同一个主机上,直到它的资源被用尽。此项策略将一个主机资源使用完,然后再切换到另一个主机。

负载均衡级别

所有资源池: 如果选定此选项,则负载均衡级别策略将适用于所选定数据中心的所有资源池中的主机。

所有主机: 该策略将适用于所选数据中心单个资源池的所有主机。

特定主机: 该策略仅适用于所选的特定主机。

 

VM设计一

VM是整个虚拟化平台的核心,我们开发了一个单独的模块来负责虚拟机的相关操作。其采用异步通信和独立的并行操作,提升了虚拟机性能、稳定性和扩展性。

可扩展性:独立、并发

可追溯性:错误信息和log、监控控制台、性能

非阻塞操作:稳定性、改进重新配置、改进回滚、标准、统一的hypervisor通信、自动化测试

 

VM设计二

我们设计基于vApp来部署虚拟机,一个vApp可包含N个虚拟机:

N 个虚拟机配置

N个开机请求

我们希望并行运行N个配置(要求资源允许),并在配置后每个虚拟机请求一个开机。这些操作都是并发和独立的。

 

平台设计

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVM UI、OVM API和OVM数据中心组件。

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

账户管理

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

“ 实践是检验真理唯一标准“,OVM社区视您为社区的发展动力,此刻,诚邀您参与我们的调查,共同做出一款真正解决问题、放心的产品,一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!
https://www.wenjuan.com/s/iiEVZv 查看全部
1、OVM虚拟化的目标:

OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产品要么架构太大,开发难度高,易用性不够强,要么就是单纯的虚拟化,类似vmware等。

新形式下,我们需要的产品要同时具备如下目标:

跨平台,支持KVM、Esxi和Docker容器

因为我们单位过去采用虚拟化技术混杂,上面又遗留很多虚拟机,这就要求我们新开发产品能够兼容不同hypervior,同时还能识别并管理原有hypervior上的虚拟机,能够识别并导入原数据库技术并不难,难的是导入后还能纳入新平台管理,这部分我们又研发了自动捕获技术,而不同混合虚拟化管理技术可以摆脱对底层Hypervisor的依赖,专心于资源的统一管理。

单独的用户自助服务门户

过去采用传统虚拟化时,解决了安装部署的麻烦,但资源的申请和扩容、准备资源和切割资源仍然没有变,还是要让我们做,占据了日常运维工作的大部分工作量,每天确实烦人,所以我们想而这部分工作是可以放给相关的部门Leader或者专员,来减少运维的工作量,所以我们希望新设计的OVM允许用户通过一个单独的Web门户来直接访问自己的资源(云主机、云硬盘、网络等),而且对自己的资源进行管理,而不需要知道资源的具体位置,同时用户的所有云主机都建立在高可用环境之上,也不必担心实际物理硬件故障引起服务瘫痪。

Opscode Chef自动化运维集成

实行自助服务后,有一个问题,就是软件不同版本部署不兼容,这就需要设计能够把操作系统、中间件、数据库、web能统一打包部署,减少自助用户哭天喊地甚至骂我们,我们通过对chef的集成,可以一键更新所有的虚拟机,在指定的虚拟机上安装指定的软件。有了chef工具,为虚拟机打补丁、安装软件,只需要几个简单的命令即可搞定。

可持续性

做运维不要故障处理办法是不行,而且还要自动化的,同时我们有vmware和kvm,就需要新平台能在esxi上(不要vcenter,要付钱的)和kvm同时实现ha功能

可运维性
一个平台再强大,技术再厉害,如果不可运维,那结果可想而知。因此我们希望OVM可以给用户带来一个稳定、可控、安全的生产环境

弹性伸缩
自助服务部门拿到资源后,通过对各项目资源的限额,以及对各虚拟机和容器性能指标的实时监控,可以实现弹性的资源伸缩,达到合理分配利用资源。

资源池化
将数据中心的计算、存储、网络资源全部池化,然后通过OVM虚拟化平台统一对外提供IaaS服务。

2、OVM设计思路

OVM架构选型一

我们觉得架构就是一个产品的灵魂所在,决定着产品日后的发展。

我们团队在产品选型初期,分别调研了目前比较热门的openstack,以及前几年的明星产品convirt、ovirt,这几个产品可谓是典型的代表。

Openstack偏重于公有云,架构设计的很不错,其分布式、插件式的模块化架构,可以有效避免单点故障的发生,从发布之初便备受推崇,但是其存在的问题也同样令人头疼目前使用Openstack的大多是一些有实力的IDC、大型的互联网公司在用。而对于一般的企业来说,没有强大的开发和维护团队,并不敢大规模的采用openstack,初期使用一段时间后我们放弃了OS。

而前几年的convirt,在当时也掀起了一股使用热潮,其简单化的使用体验,足以满足小企业的虚拟化需求,但是他的问题是架构采用了集中式的架构,而且对于上了规模之后,也会带来性能方面的瓶颈,除非是把数据库等一些组件松藕合,解决起来也比较麻烦,所以到了后期也是不温不火,官方也停止了社区的更新和维护。

OVM架构选型二

      通过对以上产品的优劣势分析,我们决定采用用分布式、松耦合的模块化插件架构,分布式使其可以规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的我们即将需要的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

而目前阶段我们则专心于实现虚拟化的全部功能,发掘内部对虚拟化的需求,打造一款真正简单、易用、稳定、可运维的一款虚拟化管理软件,并预留向上、向下的接口留作后期发展。(架构图大家可以查看刚才上面发的图片)

虚拟化技术选择

    Docker当下很火,其轻量级、灵活、高密度部署是优点,但是大规模使用还未成熟。许多场景还是需要依赖传统的虚拟化技术。所以我们选择传统虚拟化技术KVM+Docker,确保线上业务稳定性、连续性的同时,开发、测试环境又可以利用到Docker的轻量级、高密度和灵活。

     另外很多用户的生产环境存在不止一种虚拟化技术,例如KVM+Esxi组合、KVM+XenServer组合、KVM+Hyper-V组合,而目前的虚拟化管理平台,大多都是只支持一种Hypervisor的管理,用户想要维护不同的虚拟化技术的虚拟机,就要反复的在不同环境之间切换。

    基于此考虑,我和团队内部和外部一些同行选择兼容(兼容KVM、Esxi,Docker),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 网络方面,我们对所有Hypervisor的虚拟机使用统一的网络管理(包括Docker容器),这样做的一个好处就是可以减少运维工作量,降低网络复杂性。初期我们只实现2层的虚拟网络管理,为虚拟机和容器提供Vlan隔离、DHCP分配网络,当然也可以手工为虚拟机挑选一个网络,这个可以满足一般的虚拟化需求,后期我们会在此基础上增加虚拟网络防火墙、负载均衡。

存储

存储上面我们采用本地存储+NFS两种方式,对于一般中小企业来说,不希望购买高昂的商业存储,直接使用本地存储虚拟机的性能是最好的,而且我们也提供了存储快照、存储热迁移、虚拟机的无共享热迁移来提升业务安全。此外NFS作为辅助,可以为一些高风险业务提供HA。后期存储方面我们会考虑集成Ceph和GlusterFS存储来提升存储管理。

镜像中心

顾名思义,镜像中心就是用来存放镜像的。传统虚拟化我们使用NFS来作为镜像中心,所有宿主机共享一个镜像中心,这样可以更方便的来统一管理镜像,而针对Docker容器则保留了使用Docker自己的私有仓库,但是我们在WEB UI的镜像中心增加了从Docker私有仓库下载模板这么一个功能,实现了在同一个镜像中心的管理,后期我们会着重打造传统虚拟化镜像与Docker镜像的相互转换,实现两者内容的统一。

HA

OVM 主机HA依然坚持全兼容策略,支持对可管理的所有Hypervisor的HA。

在启用HA的资源池,当检测到一个Hypervisor故障,创建和运行在该Hypervisor共享存储上的虚拟机将在相同资源池下的另外一个主机上重启。

具体工作流程为:

第一次检测到故障会将该故障主机标记;

第二次检测依然故障将启动迁移任务;

迁移任务启动后将在该故障主机所在的资源池寻找合适的主机;

确定合适主机后,会将故障主机上所有的虚拟机自动迁移到合适的主机上面并重新启动;

 

VM分配策略

负载均衡

PERFORMANCE(性能): 这条策略分配虚拟机到不同的主机上。它挑选一组中可用资源最多的主机来部署虚拟机。如果有多个主机都有相同的资源可用,它使用一个循环算法,每个虚拟机分配到一个不同的主机上。

PROGRESSIVE(逐行扫描): 这条策略意味着,所有虚拟机将被分配在同一个主机上,直到它的资源被用尽。此项策略将一个主机资源使用完,然后再切换到另一个主机。

负载均衡级别

所有资源池: 如果选定此选项,则负载均衡级别策略将适用于所选定数据中心的所有资源池中的主机。

所有主机: 该策略将适用于所选数据中心单个资源池的所有主机。

特定主机: 该策略仅适用于所选的特定主机。

 

VM设计一

VM是整个虚拟化平台的核心,我们开发了一个单独的模块来负责虚拟机的相关操作。其采用异步通信和独立的并行操作,提升了虚拟机性能、稳定性和扩展性。

可扩展性:独立、并发

可追溯性:错误信息和log、监控控制台、性能

非阻塞操作:稳定性、改进重新配置、改进回滚、标准、统一的hypervisor通信、自动化测试

 

VM设计二

我们设计基于vApp来部署虚拟机,一个vApp可包含N个虚拟机:

N 个虚拟机配置

N个开机请求

我们希望并行运行N个配置(要求资源允许),并在配置后每个虚拟机请求一个开机。这些操作都是并发和独立的。

 

平台设计

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVM UI、OVM API和OVM数据中心组件。

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

账户管理

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

“ 实践是检验真理唯一标准“,OVM社区视您为社区的发展动力,此刻,诚邀您参与我们的调查,共同做出一款真正解决问题、放心的产品,一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!
https://www.wenjuan.com/s/iiEVZv

为国产技术点赞,与OVM社区共同开启用户满意度调研

maoliang 发表了文章 • 0 个评论 • 249 次浏览 • 2016-09-28 14:52 • 来自相关话题

OVM正是从国内中小企业目前的困境得到启发,完全基于国内企业特点开发,更多的关注国内中小企业用户的产品需求。我们把OVM定位于国内首款、完全免费、企业级 ——混合虚拟化管理平台! 

从今年的6月13日推出的OVM的第一个Beta版本至今,已推出四个版本,OVM社区团队非常关心 ”宝宝们“ 对免费OVM虚拟化管理平台的想法!

“ 实践是检验真理唯一标准“

OVM社区视您为社区的发展动力

此刻,诚邀您参与我们的调查

共同做出一款真正解决问题、放心的产品,

一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!

https://www.wenjuan.com/s/iiEVZv

6月13日--推出了OVM的第一个Beta版本。这个版本主要提供了HA、负载均衡、虚拟机无共享热迁移、PCI直通模式等一些商业级的收费功能,但我们是完全免费的,有了这些免费功能,用户进入虚拟化的成本直接降低到了最低,并且更加的安全。

7月18日---发布了第二个版本,除了对原有功能的优化和改进,又增加了新的虚拟化引擎Docker功能,给更多的用户带去了全新的操作使用体验。

8月18日---发布的OVM-V1.0版本,相对于前两个版本来讲,进行了全新的改变。推出单独的OVM-Node和OVM虚拟化管理平台。

9月18日--推出OVM-V1.1,除了增加了如虚拟机的快照、快照恢复功能及虚拟机备份以外,全面支持导入centos6的虚拟机。重点对产品稳定性进行改善。

10月18日将推出OVM-V1.2,敬请期待..........??????
 

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939 查看全部
OVM正是从国内中小企业目前的困境得到启发,完全基于国内企业特点开发,更多的关注国内中小企业用户的产品需求。我们把OVM定位于国内首款、完全免费、企业级 ——混合虚拟化管理平台! 

从今年的6月13日推出的OVM的第一个Beta版本至今,已推出四个版本,OVM社区团队非常关心 ”宝宝们“ 对免费OVM虚拟化管理平台的想法!

“ 实践是检验真理唯一标准“

OVM社区视您为社区的发展动力

此刻,诚邀您参与我们的调查

共同做出一款真正解决问题、放心的产品,

一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!

https://www.wenjuan.com/s/iiEVZv


6月13日--推出了OVM的第一个Beta版本。这个版本主要提供了HA、负载均衡、虚拟机无共享热迁移、PCI直通模式等一些商业级的收费功能,但我们是完全免费的,有了这些免费功能,用户进入虚拟化的成本直接降低到了最低,并且更加的安全。

7月18日---发布了第二个版本,除了对原有功能的优化和改进,又增加了新的虚拟化引擎Docker功能,给更多的用户带去了全新的操作使用体验。

8月18日---发布的OVM-V1.0版本,相对于前两个版本来讲,进行了全新的改变。推出单独的OVM-Node和OVM虚拟化管理平台。

9月18日--推出OVM-V1.1,除了增加了如虚拟机的快照、快照恢复功能及虚拟机备份以外,全面支持导入centos6的虚拟机。重点对产品稳定性进行改善。

10月18日将推出OVM-V1.2,敬请期待..........??????
 

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

OVM-V1.1版已正式发布,新增虚拟机快照、备份等功能!

maoliang 发表了文章 • 0 个评论 • 252 次浏览 • 2016-09-28 14:48 • 来自相关话题

OVM是国内首款、完全免费、企业级——混合虚拟化管理平台,OVM是从中小企业目前的困境得到启发,完全基于国内企业特点开发,更多的关注国内中小企业用户的产品需求。

OVM-V1.1版本已在9月18日正式发布,此版本全面支持导入centos6的虚拟机,同时,在OVM虚拟化管理平台新增了虚拟机的快照、快照恢复功能及虚拟机的备份功能。OVM-Node丰富了物理机、容器、容器镜像等详细信息,欢迎下载安装(51ovm.com)。

版本功能变动如下:

OVM-Node提供如下功能:

丰富物理机详情信息

丰富容器详细信息

丰富容器镜像详细信息

  通过admin账户的图形界面设置网桥

OVM虚拟化管理平台新增功能:

Ø  虚拟机快照

Ø  虚拟机备份

Ø  修复若干重要Bug

详细信息

1. 丰富物理机详情信息

该版本新增了物理机的如下详细信息展现:

Libvirt版本信息;docker版本信息,容器数量,正在运行的容器数量;OS信息(内核版本,内核架构信息,发行版本),cpu信息(型号,厂商,处理器,几个核,速度为多少赫兹,目前的cpu使用率),内存信息(总内存,可用内存,内存使用率),存储使用信息(目前存储的大小,存储挂载详情,存储使用率),网卡信息(IP,网关,掩码,DNS)

2.    丰富容器详细信息

该版本新增了容器的如下信息显示:

ID,名称,创建时间,运行状态,使用的镜像ID,对外开放的端口号,环境变量,挂载的目录信息,创建时运行的脚本,网络信息

3、丰富容器镜像详细信息

该版本新增了容器镜像的如下信息显示:

ID,名称,创建时间,对外开放的端口号,环境变量,创建镜像的作者信息

4、通过admin账户的图形界面设置网桥

该版本我们新增了通过admin用户登录进来的图形界面配置网桥的方法,大大降低了用户配置网桥的复杂度。

5、  虚拟机快照功能

在该版本,OVM虚拟化管理平台新增的虚拟机的快照,以及快照恢复功能,快照可以帮助用户快速的恢复到某个时间点。当虚拟机系统崩溃或系统异常,你可以通过使用恢复到快照来保持的磁盘和系统状态。

6、虚拟机备份功能

在该版本,OVM虚拟化管理平台新增了虚拟机的备份功能,包括全量备份和增量备份。全量备份可以帮助用户快速的将整个虚拟机打包备份;而增量备份则可以帮助用户在第一次全量备份的基础上,只备份产生的差异数据,从而节省磁盘空间

OVM混合虚拟化系统物理服务器的最低配置要求是:

最低要求
推荐配置

CPU

64位Intel@  VT-x或AMD-VTMCPU,支持虚拟化

内存

8G

64G

硬盘

300G

1T或更高

网卡

1个100Mb/s或1Gb/s网口

2个1Gb/s或10Gb/s网口

光驱

如果您准备使用光盘安装OVM,请配置DVD光驱

为了体验高级功能,它至少需要两台服务器来构建一测试系统,推荐三台最佳。 查看全部
OVM是国内首款、完全免费、企业级——混合虚拟化管理平台,OVM是从中小企业目前的困境得到启发,完全基于国内企业特点开发,更多的关注国内中小企业用户的产品需求。

OVM-V1.1版本已在9月18日正式发布,此版本全面支持导入centos6的虚拟机,同时,在OVM虚拟化管理平台新增了虚拟机的快照、快照恢复功能及虚拟机的备份功能。OVM-Node丰富了物理机、容器、容器镜像等详细信息,欢迎下载安装(51ovm.com)。

版本功能变动如下:

OVM-Node提供如下功能:

丰富物理机详情信息

丰富容器详细信息

丰富容器镜像详细信息

  通过admin账户的图形界面设置网桥

OVM虚拟化管理平台新增功能:

Ø  虚拟机快照

Ø  虚拟机备份

Ø  修复若干重要Bug

详细信息

1. 丰富物理机详情信息

该版本新增了物理机的如下详细信息展现:

Libvirt版本信息;docker版本信息,容器数量,正在运行的容器数量;OS信息(内核版本,内核架构信息,发行版本),cpu信息(型号,厂商,处理器,几个核,速度为多少赫兹,目前的cpu使用率),内存信息(总内存,可用内存,内存使用率),存储使用信息(目前存储的大小,存储挂载详情,存储使用率),网卡信息(IP,网关,掩码,DNS)

2.    丰富容器详细信息

该版本新增了容器的如下信息显示:

ID,名称,创建时间,运行状态,使用的镜像ID,对外开放的端口号,环境变量,挂载的目录信息,创建时运行的脚本,网络信息

3、丰富容器镜像详细信息

该版本新增了容器镜像的如下信息显示:

ID,名称,创建时间,对外开放的端口号,环境变量,创建镜像的作者信息

4、通过admin账户的图形界面设置网桥

该版本我们新增了通过admin用户登录进来的图形界面配置网桥的方法,大大降低了用户配置网桥的复杂度。

5、  虚拟机快照功能

在该版本,OVM虚拟化管理平台新增的虚拟机的快照,以及快照恢复功能,快照可以帮助用户快速的恢复到某个时间点。当虚拟机系统崩溃或系统异常,你可以通过使用恢复到快照来保持的磁盘和系统状态。

6、虚拟机备份功能

在该版本,OVM虚拟化管理平台新增了虚拟机的备份功能,包括全量备份和增量备份。全量备份可以帮助用户快速的将整个虚拟机打包备份;而增量备份则可以帮助用户在第一次全量备份的基础上,只备份产生的差异数据,从而节省磁盘空间

OVM混合虚拟化系统物理服务器的最低配置要求是:

最低要求
推荐配置

CPU

64位Intel@  VT-x或AMD-VTMCPU,支持虚拟化

内存

8G

64G

硬盘

300G

1T或更高

网卡

1个100Mb/s或1Gb/s网口

2个1Gb/s或10Gb/s网口

光驱

如果您准备使用光盘安装OVM,请配置DVD光驱

为了体验高级功能,它至少需要两台服务器来构建一测试系统,推荐三台最佳。

Elasticsearch聚合限制内存使用

push 发表了文章 • 0 个评论 • 382 次浏览 • 2016-09-14 15:05 • 来自相关话题

限制内存使用

通常为了让聚合(或者任何需要访问字段值的请求)能够快点,访问fielddata一定会快点, 这就是为什么加载到内存的原因。但是加载太多的数据到内存会导致垃圾回收(gc)缓慢, 因为JVM试着发现堆里面的额外空间,甚至导致OutOfMemory异常。
 
最让你吃惊的是,你会发现Elaticsearch不是只把符合你的查询的值加载到fielddata. 而是把index里的所document都加载到内存,甚至是不同的 _type 的document。
 
逻辑是这样的,如果你在这个查询需要访问documents X,Y和Z, 你可能在下一次查询就需要访问别documents。而一次把所有的值都加载并保存在内存 , 比每次查询都去扫描倒排索引要更方便。
 
JVM堆是一个有限制的资源需要聪明的使用。有许多现成的机制去限制fielddata对堆内存使用的影响。这些限制非常重要,因为滥用堆将会导致节点的不稳定(多亏缓慢的垃圾回收)或者甚至节点死亡(因为OutOfMemory异常);但是垃圾回收时间过长,在垃圾回收期间,ES节点的性能就会大打折扣,查询就会非常缓慢,直到最后超时。
 
如何设置堆大小
对于环境变量 $ES_HEAP_SIZE 在设置Elasticsearch堆大小的时候有2个法则可以运用:
不超过RAM的50%
Lucene很好的利用了文件系统cache,文件系统cache是由内核管理的。如果没有足够的文件系统cache空间,性能就会变差。
不超过32G
如果堆小于32GB,JVM能够使用压缩的指针,这会节省许多内存:每个指针就会使用4字节而不是8字节。
 
把对内存从32GB增加到34GB将意味着你将有更少的内存可用,因为所有的指针占用了双倍的空间。同样,更大的堆,垃圾回收变得代价更大并且可能导致节点不稳定;这个限制主要是大内存对fielddata影响比较大。

Fielddata大小

参数 indices.fielddata.cache.size 控制有多少堆内存是分配给fielddata。当你执行一个查询需要访问新的字段值的时候,将会把值加载到内存,然后试着把它们加入到fielddata。如果结果的fielddata大小超过指定的大小 ,为了腾出空间,别的值就会被驱逐出去。
 
默认情况下,这个参数设置的是无限制 — Elasticsearch将永远不会把数据从fielddata里替换出去。
 
这个默认值是故意选择的:fielddata不是临时的cache。它是一个在内存里为了快速执行必须能被访问的数据结构,而且构建它代价非常昂贵。如果你每个请求都要重新加载数据,性能就会很差。
 
一个有限的大小强迫数据结构去替换数据。我们将看看什么时候去设置下面的值,首先让我们看一个警告:
 
【warning】
这个设置是一个保护措施,而不是一个内存不足的解决方案




 
如果你没有足够的内存区保存你的fielddata到内存里,Elasticsearch将会经常性的从磁盘重新加载数据,并且驱逐别的数据区腾出空间。这种数据的驱逐会导致严重的磁盘I/O,并且在内存里产生大量的垃圾,这个会在后面被垃圾回收。
 
假设你在索引日志,每天使用给一个新的索引。通常情况下你只会对过去1天或者2天的数据感兴趣。即使你把老的索引数据保留着,你也很少查询它们。尽管如此,使用默认的设置, 来自老索引的fielddata也不会被清除出去!fielddata会一直增长直到它触发fielddata circuit breaker --参考断路器 --它将阻止你继续加载fielddata。
 
在那个时候你被卡住了。即使你仍然能够执行访问老的索引里的fielddata的查询, 你再也不能加载任何新的值了。相反,我们应该把老的值清除出去给新的值腾出空间。
 
为了防止这种情景,通过在 config/elasticsearch.yml 文件里加上如下的配置给fielddata 设置一个上限:indices.fielddata.cache.size: 40%当然可以设置成堆大小的百分比,也可以是一个具体的值,比如 8gb;通过适当的设置这个值,最近被访问的fielddata将被清除出去,给新加载的数据腾出空间。
 
在网上你可能会看到另外一个设置参数: indices.fielddata.cache.expire 。千万不要使用这个设置!这个设置高版本已经废弃。

这个设置告诉Elasticsearch把比过期时间老的数据从fielddata里驱逐出去,而不管这个值是否被用到。

这对性能是非常可怕的 。驱逐数据是有代价的,并且这个有目的的高效的安排驱逐数据并没有任何真正的收获。

没有任何理由去使用这个设置;我们一点也不能从理论上制造一个假设的有用的情景。现阶段存 在只是为了向后兼容。我们在这个书里提到这个设置是因为这个设置曾经在网络上的各种文章里 被作为一个 ``性能小窍门'' 被推荐过。
记住永远不要使用它,就ok!

监控fielddata

监控fielddata使用了多少内存以及是否有数据被驱逐是非常重要的。大量的数据被驱逐会导致严重的资源问题以及不好的性能。
 
Fielddata使用可以通过下面的方式来监控:
对于单个索引使用 {ref}indices-stats.html[indices-stats API]:
GET /_stats/fielddata?fields=*
对于单个节点使用 {ref}cluster-nodes-stats.html[nodes-stats API]:
GET /_nodes/stats/indices/fielddata?fields=*
或者甚至单个节点单个索引
GET /_nodes/stats/indices/fielddata?level=indices&fields=*通过设置 ?fields=* 内存使用按照每个字段分解了.

断路器(breaker)

聪明的读者可能已经注意到fielddata大小设置的一个问题。fielddata的大小是在数据被加载之后才校验的。如果一个查询尝试加载到fielddata的数据比可用的内存大会发生什么情况?答案是不客观的:你将会获得一个OutOfMemory异常。
 
Elasticsearch包含了一个 fielddata断路器 ,这个就是设计来处理这种情况的。断路器通过检查涉及的字段(它们的类型,基数,大小等等)来估计查询需要的内存。然后检查加 载需要的fielddata会不会导致总的fielddata大小超过设置的堆的百分比。
 
如果估计的查询大小超过限制,断路器就会触发并且查询会被抛弃返回一个异常。这个发生在数据被加载之前,这就意味着你不会遇到OutOfMemory异常。
 
Elasticsearch拥有一系列的断路器,所有的这些都是用来保证内存限制不会被突破:indices.breaker.fielddata.limit这个 fielddata 断路器限制fielddata的大小为堆大小的60%,默认情况下。indices.breaker.request.limit这个 request 断路器估算完成查询的其他部分要求的结构的大小,比如创建一个聚集通, 以及限制它们到堆大小的40%,默认情况下。indices.breaker.total.limit这个total断路器封装了 request 和 fielddata 断路器去确保默认情况下这2个 使用的总内存不超过堆大小的70%。
 
断路器限制可以通过文件 config/elasticsearch.yml 指定,也可以在集群上动态更新:PUT /_cluster/settings
{
"persistent" : {
"indices.breaker.fielddata.limit" : 40% (1)
}
}这个限制设置的是堆的百分比。
 
最好把断路器设置成一个相对保守的值。记住fielddata需要和堆共享 request 断路器, 索引内存缓冲区,过滤器缓存,打开的索引的Lucene数据结构,以及各种各样别的临时数据 结构。所以默认为相对保守的60%。过分乐观的设置可能会导致潜在的OOM异常,从而导致整 个节点挂掉。

从另一方面来说,一个过分保守的值将会简单的返回一个查询异常,这个异常会被应用处理。 异常总比挂掉好。这些异常也会促使你重新评估你的查询:为什么单个的查询需要超过60%的 堆空间。

断路器和Fielddata大小

在 Fielddata大小部分我们谈到了要给fielddata大小增加一个限制去保证老的不使用 的fielddata被驱逐出去。indices.fielddata.cache.size 和 indices.breaker.fielddata.limit 的关系是非常重要的。如果断路器限制比缓冲区大小要小,就会没有数据会被驱逐。为了能够 让它正确的工作,断路器限制必须比缓冲区大小要大。

我们注意到断路器是和总共的堆大小对比查询大小,而不是和真正已经使用的堆内存区比较。 这样做是有一系列技术原因的(比如,堆可能看起来是满的,但是实际上可能正在等待垃圾 回收,这个很难准确的估算)。但是作为终端用户,这意味着设置必须是保守的,因为它是 和整个堆大小比较,而不是空闲的堆比较。

参考:Elasticsearch权威指南笔记 
官网:https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html 查看全部


限制内存使用


通常为了让聚合(或者任何需要访问字段值的请求)能够快点,访问fielddata一定会快点, 这就是为什么加载到内存的原因。但是加载太多的数据到内存会导致垃圾回收(gc)缓慢, 因为JVM试着发现堆里面的额外空间,甚至导致OutOfMemory异常。
 
最让你吃惊的是,你会发现Elaticsearch不是只把符合你的查询的值加载到fielddata. 而是把index里的所document都加载到内存,甚至是不同的 _type 的document。
 
逻辑是这样的,如果你在这个查询需要访问documents X,Y和Z, 你可能在下一次查询就需要访问别documents。而一次把所有的值都加载并保存在内存 , 比每次查询都去扫描倒排索引要更方便。
 
JVM堆是一个有限制的资源需要聪明的使用。有许多现成的机制去限制fielddata对堆内存使用的影响。这些限制非常重要,因为滥用堆将会导致节点的不稳定(多亏缓慢的垃圾回收)或者甚至节点死亡(因为OutOfMemory异常);但是垃圾回收时间过长,在垃圾回收期间,ES节点的性能就会大打折扣,查询就会非常缓慢,直到最后超时。
 
如何设置堆大小
对于环境变量 $ES_HEAP_SIZE 在设置Elasticsearch堆大小的时候有2个法则可以运用:
  • 不超过RAM的50%

Lucene很好的利用了文件系统cache,文件系统cache是由内核管理的。如果没有足够的文件系统cache空间,性能就会变差。
  • 不超过32G

如果堆小于32GB,JVM能够使用压缩的指针,这会节省许多内存:每个指针就会使用4字节而不是8字节。
 
把对内存从32GB增加到34GB将意味着你将有更少的内存可用,因为所有的指针占用了双倍的空间。同样,更大的堆,垃圾回收变得代价更大并且可能导致节点不稳定;这个限制主要是大内存对fielddata影响比较大。


Fielddata大小


参数 indices.fielddata.cache.size 控制有多少堆内存是分配给fielddata。当你执行一个查询需要访问新的字段值的时候,将会把值加载到内存,然后试着把它们加入到fielddata。如果结果的fielddata大小超过指定的大小 ,为了腾出空间,别的值就会被驱逐出去。
 
默认情况下,这个参数设置的是无限制 — Elasticsearch将永远不会把数据从fielddata里替换出去。
 
这个默认值是故意选择的:fielddata不是临时的cache。它是一个在内存里为了快速执行必须能被访问的数据结构,而且构建它代价非常昂贵。如果你每个请求都要重新加载数据,性能就会很差。
 
一个有限的大小强迫数据结构去替换数据。我们将看看什么时候去设置下面的值,首先让我们看一个警告:
 
【warning】
这个设置是一个保护措施,而不是一个内存不足的解决方案
break.png

 
如果你没有足够的内存区保存你的fielddata到内存里,Elasticsearch将会经常性的从磁盘重新加载数据,并且驱逐别的数据区腾出空间。这种数据的驱逐会导致严重的磁盘I/O,并且在内存里产生大量的垃圾,这个会在后面被垃圾回收。
 
假设你在索引日志,每天使用给一个新的索引。通常情况下你只会对过去1天或者2天的数据感兴趣。即使你把老的索引数据保留着,你也很少查询它们。尽管如此,使用默认的设置, 来自老索引的fielddata也不会被清除出去!fielddata会一直增长直到它触发fielddata circuit breaker --参考断路器 --它将阻止你继续加载fielddata。
 
在那个时候你被卡住了。即使你仍然能够执行访问老的索引里的fielddata的查询, 你再也不能加载任何新的值了。相反,我们应该把老的值清除出去给新的值腾出空间。
 
为了防止这种情景,通过在 config/elasticsearch.yml 文件里加上如下的配置给fielddata 设置一个上限:
indices.fielddata.cache.size:  40%
当然可以设置成堆大小的百分比,也可以是一个具体的值,比如 8gb;通过适当的设置这个值,最近被访问的fielddata将被清除出去,给新加载的数据腾出空间。
 
在网上你可能会看到另外一个设置参数: indices.fielddata.cache.expire 。千万不要使用这个设置!这个设置高版本已经废弃。

这个设置告诉Elasticsearch把比过期时间老的数据从fielddata里驱逐出去,而不管这个值是否被用到。

这对性能是非常可怕的 。驱逐数据是有代价的,并且这个有目的的高效的安排驱逐数据并没有任何真正的收获。

没有任何理由去使用这个设置;我们一点也不能从理论上制造一个假设的有用的情景。现阶段存 在只是为了向后兼容。我们在这个书里提到这个设置是因为这个设置曾经在网络上的各种文章里 被作为一个 ``性能小窍门'' 被推荐过。
记住永远不要使用它,就ok!


监控fielddata


监控fielddata使用了多少内存以及是否有数据被驱逐是非常重要的。大量的数据被驱逐会导致严重的资源问题以及不好的性能。
 
Fielddata使用可以通过下面的方式来监控:
  • 对于单个索引使用 {ref}indices-stats.html[indices-stats API]:

GET /_stats/fielddata?fields=*

  • 对于单个节点使用 {ref}cluster-nodes-stats.html[nodes-stats API]:

GET /_nodes/stats/indices/fielddata?fields=*

  • 或者甚至单个节点单个索引

GET /_nodes/stats/indices/fielddata?level=indices&fields=*
通过设置 ?fields=* 内存使用按照每个字段分解了.


断路器(breaker)


聪明的读者可能已经注意到fielddata大小设置的一个问题。fielddata的大小是在数据被加载之后才校验的。如果一个查询尝试加载到fielddata的数据比可用的内存大会发生什么情况?答案是不客观的:你将会获得一个OutOfMemory异常。
 
Elasticsearch包含了一个 fielddata断路器 ,这个就是设计来处理这种情况的。断路器通过检查涉及的字段(它们的类型,基数,大小等等)来估计查询需要的内存。然后检查加 载需要的fielddata会不会导致总的fielddata大小超过设置的堆的百分比。
 
如果估计的查询大小超过限制,断路器就会触发并且查询会被抛弃返回一个异常。这个发生在数据被加载之前,这就意味着你不会遇到OutOfMemory异常。
 
Elasticsearch拥有一系列的断路器,所有的这些都是用来保证内存限制不会被突破
indices.breaker.fielddata.limit
这个 fielddata 断路器限制fielddata的大小为堆大小的60%,默认情况下。
indices.breaker.request.limit
这个 request 断路器估算完成查询的其他部分要求的结构的大小,比如创建一个聚集通, 以及限制它们到堆大小的40%,默认情况下。
indices.breaker.total.limit
这个total断路器封装了 request 和 fielddata 断路器去确保默认情况下这2个 使用的总内存不超过堆大小的70%。
 
断路器限制可以通过文件 config/elasticsearch.yml 指定,也可以在集群上动态更新:
PUT /_cluster/settings
{
"persistent" : {
"indices.breaker.fielddata.limit" : 40% (1)
}
}
这个限制设置的是堆的百分比。
 
最好把断路器设置成一个相对保守的值。记住fielddata需要和堆共享 request 断路器, 索引内存缓冲区,过滤器缓存,打开的索引的Lucene数据结构,以及各种各样别的临时数据 结构。所以默认为相对保守的60%。过分乐观的设置可能会导致潜在的OOM异常,从而导致整 个节点挂掉。

从另一方面来说,一个过分保守的值将会简单的返回一个查询异常,这个异常会被应用处理。 异常总比挂掉好。这些异常也会促使你重新评估你的查询:为什么单个的查询需要超过60%的 堆空间。


断路器和Fielddata大小


在 Fielddata大小部分我们谈到了要给fielddata大小增加一个限制去保证老的不使用 的fielddata被驱逐出去。indices.fielddata.cache.size 和 indices.breaker.fielddata.limit 的关系是非常重要的。如果断路器限制比缓冲区大小要小,就会没有数据会被驱逐。为了能够 让它正确的工作,断路器限制必须比缓冲区大小要大。

我们注意到断路器是和总共的堆大小对比查询大小,而不是和真正已经使用的堆内存区比较。 这样做是有一系列技术原因的(比如,堆可能看起来是满的,但是实际上可能正在等待垃圾 回收,这个很难准确的估算)。但是作为终端用户,这意味着设置必须是保守的,因为它是 和整个堆大小比较,而不是空闲的堆比较。


参考:Elasticsearch权威指南笔记 
官网:https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html


Hadoop fs命令学习小记

采菊篱下 发表了文章 • 0 个评论 • 326 次浏览 • 2016-09-13 20:08 • 来自相关话题

1,hadoop fs –fs [local | <file system URI>]:声明hadoop使用的文件系统,如果不声明的话,使用当前配置文件配置的,按如下顺序查找:hadoop jar里的hadoop-default.xml->[Math Processing Error]HADOOPCONFDIR下的hadoop−default.xml−>HADOOP_CONF_DIR下的hadoop-site.xml。使用local代表将本地文件系统作为hadoop的DFS。如果传递uri做参数,那么就是特定的文件系统作为DFS。

2,hadoop fs –ls <path>:等同于本地系统的ls,列出在指定目录下的文件内容,支持pattern匹配。输出格式如filename(full path)   <r n>  size.其中n代表replica的个数,size代表大小(单位bytes)。

3,hadoop fs –lsr <path>:递归列出匹配pattern的文件信息,类似ls,只不过递归列出所有子目录信息。

4,hadoop fs –du <path>:列出匹配pattern的指定的文件系统空间总量(单位bytes),等价于unix下的针对目录的du –sb <path>/*和针对文件的du –b <path> ,输出格式如name(full path)  size(in bytes)。

5,hadoop fs –dus <path>:等价于-du,输出格式也相同,只不过等价于unix的du -sb。

6,hadoop fs –mv <src> <dst>:将制定格式的文件 move到指定的目标位置。当src为多个文件时,dst必须是个目录。

7,hadoop fs –cp <src> <dst>:拷贝文件到目标位置,当src为多个文件时,dst必须是个目录。

8,hadoop fs –rm [-skipTrash] <src>:删除匹配pattern的指定文件,等价于unix下的rm <src>。

9,hadoop fs –rmr [skipTrash] <src>:递归删掉所有的文件和目录,等价于unix下的rm –rf <src>。

10,hadoop fs –rmi [skipTrash] <src>:等价于unix的rm –rfi <src>。

11,hadoop fs –put <localsrc> … <dst>:从本地系统拷贝文件到DFS。

12,hadoop fs –copyFromLocal <localsrc> … <dst>:等价于-put。

13,hadoop fs –moveFromLocal <localsrc> … <dst>:等同于-put,只不过源文件在拷贝后被删除。

14,hadoop fs –get [-ignoreCrc] [-crc] <src> <localdst>:从DFS拷贝文件到本地文件系统,文件匹配pattern,若是多个文件,则dst必须是目录。

15,hadoop fs –getmerge <src> <localdst>:顾名思义,从DFS拷贝多个文件、合并排序为一个文件到本地文件系统。

16,hadoop fs –cat <src>:展示文件内容。

17,hadoop fs –copyToLocal [-ignoreCrc] [-crc] <src> <localdst>:等价于-get。

18,hadoop fs –mkdir <path>:在指定位置创建目录。

19,hadoop fs –setrep [-R] [-w] <rep> <path/file>:设置文件的备份级别,-R标志控制是否递归设置子目录及文件。

20,hadoop fs –chmod [-R] <MODE[,MODE]…|OCTALMODE> PATH…:修改文件的权限,-R标记递归修改。MODE为a+r,g-w,+rwx等,OCTALMODE为755这样。

21,hadoop fs -chown [-R] [OWNER][:[GROUP]] PATH…:修改文件的所有者和组。-R表示递归。

22,hadoop fs -chgrp [-R] GROUP PATH…:等价于-chown … :GROUP …。

23,hadoop fs –count[-q] <path>:计数文件个数及所占空间的详情,输出表格的列的含义依次为:DIR_COUNT,FILE_COUNT,CONTENT_SIZE,FILE_NAME或者如果加了-q的话,还会列出QUOTA,REMAINING_QUOTA,SPACE_QUOTA,REMAINING_SPACE_QUOTA。

最后就是万能的hadoop fs –help 查看全部
HDFS.png

1,hadoop fs –fs [local | <file system URI>]:声明hadoop使用的文件系统,如果不声明的话,使用当前配置文件配置的,按如下顺序查找:hadoop jar里的hadoop-default.xml->[Math Processing Error]HADOOPCONFDIR下的hadoop−default.xml−>HADOOP_CONF_DIR下的hadoop-site.xml。使用local代表将本地文件系统作为hadoop的DFS。如果传递uri做参数,那么就是特定的文件系统作为DFS。

2,hadoop fs –ls <path>:等同于本地系统的ls,列出在指定目录下的文件内容,支持pattern匹配。输出格式如filename(full path)   <r n>  size.其中n代表replica的个数,size代表大小(单位bytes)。

3,hadoop fs –lsr <path>:递归列出匹配pattern的文件信息,类似ls,只不过递归列出所有子目录信息。

4,hadoop fs –du <path>:列出匹配pattern的指定的文件系统空间总量(单位bytes),等价于unix下的针对目录的du –sb <path>/*和针对文件的du –b <path> ,输出格式如name(full path)  size(in bytes)。

5,hadoop fs –dus <path>:等价于-du,输出格式也相同,只不过等价于unix的du -sb。

6,hadoop fs –mv <src> <dst>:将制定格式的文件 move到指定的目标位置。当src为多个文件时,dst必须是个目录。

7,hadoop fs –cp <src> <dst>:拷贝文件到目标位置,当src为多个文件时,dst必须是个目录。

8,hadoop fs –rm [-skipTrash] <src>:删除匹配pattern的指定文件,等价于unix下的rm <src>。

9,hadoop fs –rmr [skipTrash] <src>:递归删掉所有的文件和目录,等价于unix下的rm –rf <src>。

10,hadoop fs –rmi [skipTrash] <src>:等价于unix的rm –rfi <src>。

11,hadoop fs –put <localsrc> … <dst>:从本地系统拷贝文件到DFS。

12,hadoop fs –copyFromLocal <localsrc> … <dst>:等价于-put。

13,hadoop fs –moveFromLocal <localsrc> … <dst>:等同于-put,只不过源文件在拷贝后被删除。

14,hadoop fs –get [-ignoreCrc] [-crc] <src> <localdst>:从DFS拷贝文件到本地文件系统,文件匹配pattern,若是多个文件,则dst必须是目录。

15,hadoop fs –getmerge <src> <localdst>:顾名思义,从DFS拷贝多个文件、合并排序为一个文件到本地文件系统。

16,hadoop fs –cat <src>:展示文件内容。

17,hadoop fs –copyToLocal [-ignoreCrc] [-crc] <src> <localdst>:等价于-get。

18,hadoop fs –mkdir <path>:在指定位置创建目录。

19,hadoop fs –setrep [-R] [-w] <rep> <path/file>:设置文件的备份级别,-R标志控制是否递归设置子目录及文件。

20,hadoop fs –chmod [-R] <MODE[,MODE]…|OCTALMODE> PATH…:修改文件的权限,-R标记递归修改。MODE为a+r,g-w,+rwx等,OCTALMODE为755这样。

21,hadoop fs -chown [-R] [OWNER][:[GROUP]] PATH…:修改文件的所有者和组。-R表示递归。

22,hadoop fs -chgrp [-R] GROUP PATH…:等价于-chown … :GROUP …。

23,hadoop fs –count[-q] <path>:计数文件个数及所占空间的详情,输出表格的列的含义依次为:DIR_COUNT,FILE_COUNT,CONTENT_SIZE,FILE_NAME或者如果加了-q的话,还会列出QUOTA,REMAINING_QUOTA,SPACE_QUOTA,REMAINING_SPACE_QUOTA。

最后就是万能的hadoop fs –help

Hbase shell常用命令小记

采菊篱下 发表了文章 • 0 个评论 • 305 次浏览 • 2016-09-13 00:19 • 来自相关话题

1、进入hbase shell console
$HBASE_HOME/bin/hbase shell
如果有kerberos认证,需要事先使用相应的keytab进行一下认证(使用kinit命令),认证成功之后再使用hbase shell进入可以使用whoami命令可查看当前用户hbase(main):002:0> whoami
2016-09-12 13:09:42,440 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
root (auth:SIMPLE)
groups: root
 2、表的管理
1)查看有哪些表hbase(main):001:0> list
TABLE
pythonTrace
1 row(s) in 0.1320 seconds2)创建表
语法:create <table>, {NAME => <family>, VERSIONS => <VERSIONS>}
例如:创建表t1,有两个family name:f1,f2,且版本数均为2hbase(main):001:0> create 't1',{NAME => 'f1', VERSIONS => 2},{NAME => 'f2', VERSIONS => 2}
0 row(s) in 0.4400 seconds

=> Hbase::Table - t13)删除表
分两步:首先disable,然后drop ;  例如:删除表t1hbase(main):002:0> disable 't1'
0 row(s) in 1.2030 seconds

hbase(main):003:0> drop 't1'
0 row(s) in 0.1870 seconds4)查看表的结构
语法:describe <table> ,  例如:查看表t1的结构hbase(main):005:0> describe 't1'
Table t1 is ENABLED
t1
COLUMN FAMILIES DESCRIPTION
{NAME => 'f1', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '2', COMP
RESSION => 'NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'FALSE', BLOCKSIZE => '65536', IN_M
EMORY => 'false', BLOCKCACHE => 'true'}
{NAME => 'f2', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '2', COMP
RESSION => 'NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'FALSE', BLOCKSIZE => '65536', IN_M
EMORY => 'false', BLOCKCACHE => 'true'}
2 row(s) in 0.0240 seconds5)修改表结构
修改表结构必须先disable
语法:alter 't1', {NAME => 'f1'}, {NAME => 'f2', METHOD => 'delete'}; 例如:修改表t1的cf的TTL为180天hbase(main):006:0> disable 't1'
0 row(s) in 1.1950 seconds

hbase(main):007:0> alter 't1',{NAME=>'body',TTL=>'15552000'},{NAME=>'meta', TTL=>'15552000'}
Updating all regions with the new schema...
1/1 regions updated.
Done.
Updating all regions with the new schema...
1/1 regions updated.
Done.
0 row(s) in 2.1910 seconds

hbase(main):008:0> enable 't1'
0 row(s) in 0.3930 seconds
3、权限管理
1)分配权限
语法 : grant <user> <permissions> <table> <column family> <column qualifier> 参数后面用逗号分隔
权限用五个字母表示: "RWXCA"; READ('R'), WRITE('W'), EXEC('X'), CREATE('C'), ADMIN('A')
例如,给用户‘test'分配对表t1有读写的权限hbase(main)> grant 'test','RW','t1'2)查看权限
语法:user_permission <table> ; 例如,查看表t1的权限列表hbase(main)> user_permission 't1'3)收回权限
与分配权限类似,语法:revoke <user> <table> <column family> <column qualifier>
例如,收回test用户在表t1上的权限hbase(main)> revoke 'test','t1'
4、表数据的增删改查
1)添加数据
语法:put <table>,<rowkey>,<family:column>,<value>,<timestamp>
例如:给表t1的添加一行记录:rowkey是rowkey001,family name:f1,column name:col1,value:value01,timestamp:系统默认hbase(main)> put 't1','rowkey001','f1:col1','value01'用法比较单一
2)查询数据
a)查询某行记录
语法:get <table>,<rowkey>,[<family:column>,....]   ;例如:查询表t1,rowkey001中的f1下的col1的值hbase(main)> get 't1','rowkey001', 'f1:col1'# 或者:hbase(main)> get 't1','rowkey001', {COLUMN=>'f1:col1'}查询表t1,rowke002中的f1下的所有列值hbase(main)> get 't1','rowkey001'b)扫描表
语法:scan <table>, {COLUMNS => [ <family:column>,.... ], LIMIT => num}
另外,还可以添加STARTROW、TIMERANGE和FITLER等高级功能; 例如:扫描表t1的前5条数据hbase(main)> scan 't1',{LIMIT=>5}c)查询表中的数据行数
语法:count <table>, {INTERVAL => intervalNum, CACHE => cacheNum}
INTERVAL设置多少行显示一次及对应的rowkey,默认1000;CACHE每次去取的缓存区大小,默认是10,调整该参数可提高查询速度
例如,查询表t1中的行数,每100条显示一次,缓存区为500hbase(main)> count 't1', {INTERVAL => 100, CACHE => 500}3)删除数据
a )删除行中的某个列值
语法:delete <table>, <rowkey>,  <family:column> , <timestamp>,必须指定列名
例如:删除表t1,rowkey001中的f1:col1的数据hbase(main)> delete 't1','rowkey001','f1:col1'注:将删除改行f1:col1列所有版本的数据
 
b )删除行
语法:deleteall <table>, <rowkey>,  <family:column> , <timestamp>,可以不指定列名,删除整行数据
例如:删除表t1,rowk001的数据hbase(main)> deleteall 't1','rowkey001'c)删除表中的所有数据
语法: truncate <table>
其具体过程是:disable table -> drop table -> create table ;例如:删除表t1的所有数据hbase(main)> truncate 't1'
5、Region管理
1)移动region
语法:move 'encodeRegionName', 'ServerName'
encodeRegionName指的regioName后面的编码,ServerName指的是master-status的Region Servers列表
示例如下:hbase(main)>move '4343995a58be8e5bbc739af1e91cd72d', 'db-41.xxx.xxx.org,60020,1390274516739'2)开启/关闭region
语法:balance_switch true|falsehbase(main)> balance_switch3)手动split
语法:split 'regionName', 'splitKey'
4)手动触发major compaction
#语法:#Compact all regions in a table:
hbase> major_compact 't1'
#Compact an entire region:
hbase> major_compact 'r1'
#Compact a single column family within a region:
hbase> major_compact 'r1', 'c1'
#Compact a single column family within a table:
hbase> major_compact 't1', 'c1'
6、配置管理及节点重启
1)修改hdfs配置
hdfs配置位置:/etc/hadoop/conf
# 同步hdfs配置cat /home/hadoop/slaves|xargs -i -t scp /etc/hadoop/conf/hdfs-site.xml hadoop@{}:/etc/hadoop/conf/hdfs-site.xml# 关闭:cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf stop datanode"# 启动:cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf start datanode"2)修改hbase配置
hbase配置位置:
# 同步hbase配置cat /home/hadoop/hbase/conf/regionservers|xargs -i -t scp /home/hadoop/hbase/conf/hbase-site.xml hadoop@{}:/home/hadoop/hbase/conf/hbase-site.xml# graceful重启cd ~/hbase
bin/graceful_stop.sh --restart --reload --debug inspurXXX.xxx.xxx.org 查看全部
hbase.png
1、进入hbase shell console
$HBASE_HOME/bin/hbase shell
如果有kerberos认证,需要事先使用相应的keytab进行一下认证(使用kinit命令),认证成功之后再使用hbase shell进入可以使用whoami命令可查看当前用户
hbase(main):002:0> whoami
2016-09-12 13:09:42,440 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
root (auth:SIMPLE)
groups: root

 2、表的管理
1)查看有哪些表
hbase(main):001:0> list
TABLE
pythonTrace
1 row(s) in 0.1320 seconds
2)创建表
语法:create <table>, {NAME => <family>, VERSIONS => <VERSIONS>}
例如:创建表t1,有两个family name:f1,f2,且版本数均为2
hbase(main):001:0> create 't1',{NAME => 'f1', VERSIONS => 2},{NAME => 'f2', VERSIONS => 2}
0 row(s) in 0.4400 seconds

=> Hbase::Table - t1
3)删除表
分两步:首先disable,然后drop ;  例如:删除表t1
hbase(main):002:0> disable 't1'
0 row(s) in 1.2030 seconds

hbase(main):003:0> drop 't1'
0 row(s) in 0.1870 seconds
4)查看表的结构
语法:describe <table> ,  例如:查看表t1的结构
hbase(main):005:0> describe 't1'
Table t1 is ENABLED
t1
COLUMN FAMILIES DESCRIPTION
{NAME => 'f1', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '2', COMP
RESSION => 'NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'FALSE', BLOCKSIZE => '65536', IN_M
EMORY => 'false', BLOCKCACHE => 'true'}
{NAME => 'f2', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '2', COMP
RESSION => 'NONE', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'FALSE', BLOCKSIZE => '65536', IN_M
EMORY => 'false', BLOCKCACHE => 'true'}
2 row(s) in 0.0240 seconds
5)修改表结构
修改表结构必须先disable
语法:alter 't1', {NAME => 'f1'}, {NAME => 'f2', METHOD => 'delete'}; 例如:修改表t1的cf的TTL为180天
hbase(main):006:0> disable 't1'
0 row(s) in 1.1950 seconds

hbase(main):007:0> alter 't1',{NAME=>'body',TTL=>'15552000'},{NAME=>'meta', TTL=>'15552000'}
Updating all regions with the new schema...
1/1 regions updated.
Done.
Updating all regions with the new schema...
1/1 regions updated.
Done.
0 row(s) in 2.1910 seconds

hbase(main):008:0> enable 't1'
0 row(s) in 0.3930 seconds

3、权限管理
1)分配权限
语法 : grant <user> <permissions> <table> <column family> <column qualifier> 参数后面用逗号分隔
权限用五个字母表示: "RWXCA"; READ('R'), WRITE('W'), EXEC('X'), CREATE('C'), ADMIN('A')
例如,给用户‘test'分配对表t1有读写的权限
hbase(main)> grant 'test','RW','t1'
2)查看权限
语法:user_permission <table> ; 例如,查看表t1的权限列表
hbase(main)> user_permission 't1'
3)收回权限
与分配权限类似,语法:revoke <user> <table> <column family> <column qualifier>
例如,收回test用户在表t1上的权限
hbase(main)> revoke 'test','t1'

4、表数据的增删改查
1)添加数据
语法:put <table>,<rowkey>,<family:column>,<value>,<timestamp>
例如:给表t1的添加一行记录:rowkey是rowkey001,family name:f1,column name:col1,value:value01,timestamp:系统默认
hbase(main)> put 't1','rowkey001','f1:col1','value01'
用法比较单一
2)查询数据
a)查询某行记录
语法:get <table>,<rowkey>,[<family:column>,....]   ;例如:查询表t1,rowkey001中的f1下的col1的值
hbase(main)> get 't1','rowkey001', 'f1:col1'
# 或者:
hbase(main)> get 't1','rowkey001', {COLUMN=>'f1:col1'}
查询表t1,rowke002中的f1下的所有列值
hbase(main)> get 't1','rowkey001'
b)扫描表
语法:scan <table>, {COLUMNS => [ <family:column>,.... ], LIMIT => num}
另外,还可以添加STARTROW、TIMERANGE和FITLER等高级功能; 例如:扫描表t1的前5条数据
hbase(main)> scan 't1',{LIMIT=>5}
c)查询表中的数据行数
语法:count <table>, {INTERVAL => intervalNum, CACHE => cacheNum}
INTERVAL设置多少行显示一次及对应的rowkey,默认1000;CACHE每次去取的缓存区大小,默认是10,调整该参数可提高查询速度
例如,查询表t1中的行数,每100条显示一次,缓存区为500
hbase(main)> count 't1', {INTERVAL => 100, CACHE => 500}
3)删除数据
a )删除行中的某个列值
语法:delete <table>, <rowkey>,  <family:column> , <timestamp>,必须指定列名
例如:删除表t1,rowkey001中的f1:col1的数据
hbase(main)> delete 't1','rowkey001','f1:col1'
注:将删除改行f1:col1列所有版本的数据
 
b )删除行
语法:deleteall <table>, <rowkey>,  <family:column> , <timestamp>,可以不指定列名,删除整行数据
例如:删除表t1,rowk001的数据
hbase(main)> deleteall 't1','rowkey001'
c)删除表中的所有数据
语法: truncate <table>
其具体过程是:disable table -> drop table -> create table ;例如:删除表t1的所有数据
hbase(main)> truncate 't1'

5、Region管理
1)移动region
语法:move 'encodeRegionName', 'ServerName'
encodeRegionName指的regioName后面的编码,ServerName指的是master-status的Region Servers列表
示例如下:
hbase(main)>move '4343995a58be8e5bbc739af1e91cd72d', 'db-41.xxx.xxx.org,60020,1390274516739'
2)开启/关闭region
语法:balance_switch true|false
hbase(main)> balance_switch
3)手动split
语法:split 'regionName', 'splitKey'
4)手动触发major compaction
#语法:
#Compact all regions in a table:
hbase> major_compact 't1'
#Compact an entire region:
hbase> major_compact 'r1'
#Compact a single column family within a region:
hbase> major_compact 'r1', 'c1'
#Compact a single column family within a table:
hbase> major_compact 't1', 'c1'

6、配置管理及节点重启
1)修改hdfs配置
hdfs配置位置:/etc/hadoop/conf
# 同步hdfs配置
cat /home/hadoop/slaves|xargs -i -t scp /etc/hadoop/conf/hdfs-site.xml hadoop@{}:/etc/hadoop/conf/hdfs-site.xml
# 关闭:
cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf stop datanode"
# 启动:
cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf start datanode"
2)修改hbase配置
hbase配置位置:
# 同步hbase配置
cat /home/hadoop/hbase/conf/regionservers|xargs -i -t scp /home/hadoop/hbase/conf/hbase-site.xml hadoop@{}:/home/hadoop/hbase/conf/hbase-site.xml
# graceful重启
cd ~/hbase
bin/graceful_stop.sh --restart --reload --debug inspurXXX.xxx.xxx.org