Name node is in safe mode解决
将本地文件拷贝到hdfs上去，结果上错误：Name node is in safe mode
这是因为在分布式文件系统启动的时候，开始的时候会有安全模式，当分布式文件系统处于安全模式的情况下，文件系统中的内容不允许修改也不允许删除，直到安全模式结束。安全模式主要是为了系统启动的时候检查各个DataNode上数据块的有效性，同时根据策略必要的复制或者删除部分数据块。运行期通过命令也可以进入安全模式。在实践过程中，系统启动的时候去修改和删除文件也会有安全模式不允许修改的出错提示，只需要等待一会儿即可。
可以通过以下命令来手动离开安全模式：
enter - 进入安全模式
leave - 强制NameNode离开安全模式
get - 返回安全模式是否开启的信息
wait - 等待，一直到安全模式结束。 收起阅读 »
这是因为在分布式文件系统启动的时候，开始的时候会有安全模式，当分布式文件系统处于安全模式的情况下，文件系统中的内容不允许修改也不允许删除，直到安全模式结束。安全模式主要是为了系统启动的时候检查各个DataNode上数据块的有效性，同时根据策略必要的复制或者删除部分数据块。运行期通过命令也可以进入安全模式。在实践过程中，系统启动的时候去修改和删除文件也会有安全模式不允许修改的出错提示，只需要等待一会儿即可。
可以通过以下命令来手动离开安全模式：
bin/hadoop dfsadmin -safemode leave用户可以通过dfsadmin -safemode value 来操作安全模式，参数value的说明如下：
enter - 进入安全模式
leave - 强制NameNode离开安全模式
get - 返回安全模式是否开启的信息
wait - 等待，一直到安全模式结束。 收起阅读 »
Elasticsearch备份和恢复
备份
备份数据之前，要创建一个仓库来保存数据，仓库的类型支持共享文件系统、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注意:这是在第一段代码的基础上来增加配置，第一段代码利用的是PUT请求来创建存储库，这段代码则是利用POST请求来更新已经存在的存储库的settings配置。
{
"type": "fs",
"settings": {
"location": "/mount/EsDataBackupDir"
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
}
}
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 Region
- Access_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 和rename_replacement用来正则匹配要恢复的索引，并且重命名。和备份一样，api会立刻返回值，然后在后台执行恢复，使用wait_for_completion 标记强制同步执行。
{
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}
另外可以使用下面两个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性能测试
测试背景
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、启动kafka
cd /usr/local/kafka
vim config/server.properties #内容见下图
./bin/kafka-server-start.sh config/server.properties &
kafka-producer-perf-test.sh中参数说明：
messages 生产者发送走的消息数量bin/kafka-consumer-perf-test.sh中参数说明：
message-size 每条消息的大小
batch-size 每次批量发送消息的数量
topics 生产者发送的topic
threads 生产者
broker-list 安装kafka服务的机器ip:porta列表
producer-num-retries 一个消息失败发送重试次数
request-timeouts-ms 一个消息请求发送超时时间
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测试producer吞吐率
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
调整batch-size，thread，topic，压缩等参数测试producer吞吐率。
示例：
a)批处理为1，线程数为1，partition为1，复制因子为1说明：消息大小统一使用和业务场景中日志大小相近的512Bype，消息数为50w或200w条。
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
三、测试消费者吞吐率
测试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吞吐率。由上图可以看到此场景下，压缩对吞吐率影响小。 收起阅读 »
OVM混合虚拟化设计目标及设计思路
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分钟喔！
收起阅读 »
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分钟喔！
收起阅读 »
为国产技术点赞，与OVM社区共同开启用户满意度调研
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 收起阅读 »
从今年的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版已正式发布，新增虚拟机快照、备份等功能！
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-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聚合限制内存使用
限制内存使用
通常为了让聚合(或者任何需要访问字段值的请求)能够快点，访问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%
- 不超过32G
参数 indices.fielddata.cache.size 控制有多少堆内存是分配给fielddata。当你执行一个查询需要访问新的字段值的时候，将会把值加载到内存，然后试着把它们加入到fielddata。如果结果的fielddata大小超过指定的大小 ，为了腾出空间，别的值就会被驱逐出去。 默认情况下，这个参数设置的是无限制 — Elasticsearch将永远不会把数据从fielddata里替换出去。 这个默认值是故意选择的：fielddata不是临时的cache。它是一个在内存里为了快速执行必须能被访问的数据结构，而且构建它代价非常昂贵。如果你每个请求都要重新加载数据，性能就会很差。 一个有限的大小强迫数据结构去替换数据。我们将看看什么时候去设置下面的值，首先让我们看一个警告： 【warning】这个设置是一个保护措施，而不是一个内存不足的解决方案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命令学习小记
1，hadoop fs –fs [local |
2，hadoop fs –ls
3，hadoop fs –lsr
4，hadoop fs –du
5，hadoop fs –dus
6，hadoop fs –mv
7，hadoop fs –cp
8，hadoop fs –rm [-skipTrash]
9，hadoop fs –rmr [skipTrash]
10，hadoop fs –rmi [skipTrash]
11，hadoop fs –put
12，hadoop fs –copyFromLocal
13，hadoop fs –moveFromLocal
14，hadoop fs –get [-ignoreCrc] [-crc]
15，hadoop fs –getmerge
16，hadoop fs –cat
17，hadoop fs –copyToLocal [-ignoreCrc] [-crc]
18，hadoop fs –mkdir
19，hadoop fs –setrep [-R] [-w]
20，hadoop fs –chmod [-R]
21，hadoop fs -chown [-R] [OWNER][:[GROUP]] PATH…：修改文件的所有者和组。-R表示递归。
22，hadoop fs -chgrp [-R] GROUP PATH…：等价于-chown … :GROUP …。
23，hadoop fs –count[-q]
最后就是万能的hadoop fs –help 收起阅读 »
Hbase shell常用命令小记
$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> list2）创建表
TABLE
pythonTrace
1 row(s) in 0.1320 seconds
语法：create
