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吞吐率。由上图可以看到此场景下，压缩对吞吐率影响小。 收起阅读 »
Linux下应用程序带宽限制神器「Trickle」
有时候我们经常会遇到某个应用程序占满了整个系统的带宽，然后影响到了其他程序的运行效率。这个时候其实是可以限制这个程序的带宽占用的，然后达到带宽均衡被瓜分。这个时候Trickle就可以做到，他可以控制应用程序的上下行带宽，达到带宽不至于被一个程序霸占。
什么是 Trickle
rickle是一个网络带宽调整工具，可以让我们管理应用程序的网络上下行速度，使得可以避免其中的某个应用程序霸占了全部或大部分可用的带宽。换句话说，Trickle可以让你基于单个应用程序来控制网络流量速率，而不是仅仅针对与单个用户——这是在客户端网络环境中经典的带宽调整情况。
Trickle 可以限制 Linux 命令行工具的上传和下载流量。在跨地域文件传输或者备份时非常有用，因为外网带宽往往会比较贵。
或者你想备份进程或者下载进程不对同机器的其他服务产生影响，也需要 Trickle 这样的限流工具。
再或者你在办公室想下载大文件，不希望影响其他网络用户或者应用，Trickle 就是为此设计。
Trickle 如何工作
trickle 可以帮助我们基于应用来定义优先级，所以当对整个系统进行了全局限制设定，高优先级的应用依然会自动地获取更多的带宽。为了实现这个目标，trickle 对 TCP 连接上的套接字的数据发送、接收设置流量限制。我们必须注意到，除了影响传输速率之外，在这个过程中，trickle任何时候都不会以任何方式来改变其中的数据。
Trickle不能做什么
trickle唯一的限制就是不支持静态链接的应用程序或者具有SUID或SGID位设置的二进制程序，因为它使用动态链接的方式将其载入到需要调整的进程和其关联的网络套接字之间。 Trickle此时会在这两种软件组件之间扮演代理的角色。
由于trickle并不需要超级用户的权限来运行，所以用户可以设置他们自己的流量限制。可能这并不是你想要的，我们会探索如何使用全局设定来限制系统中的所有用户的流量限制。也即是说，此时系统中的每个用户具有管理各自的流量速率，但是无论如何，都会受到系统管理员给他们设置的总体限制。
在这篇文章中，我们会描述如何通过trickle在linux平台上管理应用程序使用的网络带宽。为了生成所需的流量，在此会在客户端(CentOS 7 server – dev1: 192.168.0.17)上使用 ncftpput 和 ncftpget， 在服务器(Debian Wheezy 7.5 – dev2: 192.168.0.15)上使用vsftpd 来进行演示。 相同的指令也可以在RedHat，Fedora和Ubuntu等系统使用。
使用案例
前提条件
对于 RHEL/CentOS 7/6， 开启EPEL仓库。这些用于企业版 Linux 的额外软件包是一个由Fedora项目维护的高质量、开源的软件仓库，而且百分之百与其衍生产品相兼容，如企业版本Linux和CentOS。 在这个仓库中trickle和ncftp两者都是可用的。按照如下方式安装ncftp：
# yum update && sudo yum install ncftp [基于 RedHat 的系统]在单独的服务器上设置一个FTP服务器。需要注意的是，尽管FTP天生就不安全，但是仍然被广泛应用在安全性无关紧要的文件上传下载中。 在这篇文章中我们使用它来演示trickle的优点，同时它也会在客户端的标准输出流中显示传输速率。我们将是否在其它时间使用它放在一边讨论。
# aptitude update && aptitude install ncftp [基于 Debian 的系统]
现在，在FTP服务器上按照以下方式编辑 /etc/vsftpd/vsftpd.conf 文件。
anonymous_enable=NO在此之后，确保在你的当前会话中启动了vsftpd，并在之后的启动中让其自动启动。
local_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
# systemctl start vsftpd [基于 systemd 的系统]如果你选择在一个使用 SSH 密钥进行远程访问的 CentOS/RHEL 7中搭建FTP服务器，你需要一个密码受保护的用户账户，它能访问root目录之外的某个目录，并有能在其中上传和下载文件的权限。
# systemctl enable vsftpd
# service vsftpd start [基于 init 的系统]
# chkconfig vsftpd on
你可以通过在你的浏览器中输入以下的URL来浏览你的家目录。一个登录窗口会弹出来提示你输入FTP服务器中的有效的用户名和密码。
ftp://192.168.0.15如果验证成功，你就会看到你的家目录中的内容。该教程的稍后部分中，你将可以刷新页面来显示在你之前上传过的文件。
使用方法：
只需要把 trickle 和相关参数附加在其他 Linux 命令行工具命令之前即可。
比如限制 Wget 下载文件的速度为 20KB/S
trickle -s -d 20 wget -c http://blog.eood.cn/
限制文件备份到 AWS S3 的上传速度为 1MB/S：
trickle -s -u 1024 s3cmd sync /mnt/data/ s3://my-backup
当然，你也可以把 trickle 加在现有的服务器自动化脚本中完成限流功能。
其他功能：
trickle -L 设置延迟为多少 ms
trickle -w 设置窗口长度为多少 KB
假如你使用 Linux 系统作为办公和开发环境。Trickle 还可以针对每个不同的 Linux 工具进行限流，这样你可以限制 BT 下载的速度，而不影响浏览网页。 收起阅读 »
MySQL远程代码执行漏洞安全预警
MySQL最近爆出高危漏洞CVE-2016-6662，可导致远程代码执行/权限提升。
影响范围：
MySQL <= 5.7.15，PerconaDB与MariaDB也受此漏洞影响。
<=5.6.33，
<= 5.5.52
修复方案：
1.oracle官网发布mysql修复补丁后立即升级版本。PerconaDB与MariaDB官网已经发布补丁，请升级到最新版本。下载地址分别如下：
https://mariadb.org/download/
https://www.percona.com/downloads/
2.暂时的缓解策略：
修改MySQL所有用户密码为复杂密码；
关闭MySQL普通用户的File文件访问权限；
以root用户身份创建一个虚假my.cnf文件；
漏洞详情：
攻击者通过一个拥有File权限的MySQL普通用户将恶意库文件路径插入到MySQL配置文件的malloc_lib变量中，当MySQL服务重启时就可以加载恶意库文件实现以root权限执行任意代码。
漏洞利用条件：
- 攻击者可以在配置文件中注入恶意配置；
- 上传恶意的so到lib库中；
- db重启（重新加载恶意配置）。
验证方法参考：http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html 收起阅读 »
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光驱
为了体验高级功能，它至少需要两台服务器来构建一测试系统，推荐三台最佳。 收起阅读 »
Python程序软件目录规范化
为什么要设计好目录结构？
"设计项目目录结构"，就和"代码编码风格"一样，属于个人风格问题。对于这种风格上的规范，一直都存在两种态度:
- 一类同学认为，这种个人风格问题"无关紧要"。理由是能让程序work就好，风格问题根本不是问题；
- 另一类同学认为，规范化能更好的控制程序结构，让程序具有更高的可读性。
我是比较偏向于后者的，因为我是前一类同学思想行为下的直接受害者。我曾经维护过一个非常不好读的项目，其实现的逻辑并不复杂，但是却耗费了我非常长的时间去理解它想表达的意思。从此我个人对于提高项目可读性、可维护性的要求就很高了。"项目目录结构"其实也是属于"可读性和可维护性"的范畴，我们设计一个层次清晰的目录结构，就是为了达到以下两点:
- 可读性高: 不熟悉这个项目的代码的人，一眼就能看懂目录结构，知道程序启动脚本是哪个，测试目录在哪儿，配置文件在哪儿等等。从而非常快速的了解这个项目。
- 可维护性高: 定义好组织规则后，维护者就能很明确地知道，新增的哪个文件和代码应该放在什么目录之下。这个好处是，随着时间的推移，代码/配置的规模增加，项目结构不会混乱，仍然能够组织良好。
所以，保持一个层次清晰的目录结构是有必要的。更何况组织一个良好的工程目录，其实是一件很简单的事儿。
目录组织方式
关于如何组织一个较好的Python工程目录结构，已经有一些得到了共识的目录结构。在Stackoverflow关于这个问题 ，可以看到很多赞同对Python目录结构规范的情况。
假设你的项目名为foo, 我比较建议的最方便快捷目录结构这样就足够了:
Foo/简要解释一下:
|-- bin/
| |-- foo
|
|-- foo/
| |-- tests/
| | |-- __init__.py
| | |-- test_main.py
| |
| |-- __init__.py
| |-- main.py
|
|-- docs/
| |-- conf.py
| |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README
- bin/: 存放项目的一些可执行文件，当然你可以起名script/之类的也行。
- foo/: 存放项目的所有源代码。(1) 源代码中的所有模块、包都应该放在此目录。不要置于顶层目录。(2) 其子目录tests/存放单元测试代码； (3) 程序的入口最好命名为main.py。
- docs/: 存放一些文档。
- setup.py: 安装、部署、打包的脚本。
- requirements.txt: 存放软件依赖的外部Python包列表。
- README: 项目说明文件。
除此之外，有一些方案给出了更加多的内容。比如LICENSE.txt,ChangeLog.txt文件等，我没有列在这里，因为这些东西主要是项目开源的时候需要用到。如果你想写一个开源软件，目录该如何组织，可以参考开源Python项目的正确方法 。
关于README的内容
这个我觉得是每个项目都应该有的一个文件，目的是能简要描述该项目的信息，让读者快速了解这个项目。
它需要说明以下几个事项:
- 软件定位，软件的基本功能。
- 运行代码的方法: 安装环境、启动命令等。
- 简要的使用说明。
- 代码目录结构说明，更详细点可以说明软件的基本原理。
- 常见问题说明。
我觉得有以上几点是比较好的一个README。在软件开发初期，由于开发过程中以上内容可能不明确或者发生变化，并不是一定要在一开始就将所有信息都补全。但是在项目完结的时候，是需要撰写这样的一个文档的。
可以参考Redis源码中Readme的写法，这里面简洁清晰的描述了Redis功能和源码结构。
关于requirements.txt和setup.py
setup.py
一般来说，用setup.py来管理代码的打包、安装、部署问题。业界标准的写法是用Python流行的打包工具setuptools 来管理这些事情。这种方式普遍应用于开源项目中。不过这里的核心思想不是用标准化的工具来解决这些问题，而是说，一个项目一定要有一个安装部署工具，能快速便捷的在一台新机器上将环境装好、代码部署好和将程序运行起来。
我想大多数人是踩过坑的，刚开始接触Python写项目的时候，安装环境、部署代码、运行程序这个过程全是手动完成，遇到过以下问题:
- 安装环境时经常忘了最近又添加了一个新的Python包，结果一到线上运行，程序就出错了。
- Python包的版本依赖问题，有时候我们程序中使用的是一个版本的Python包，但是官方的已经是最新的包了，通过手动安装就可能装错了。
- 如果依赖的包很多的话，一个一个安装这些依赖是很费时的事情。
- 新同学开始写项目的时候，将程序跑起来非常麻烦，因为可能经常忘了要怎么安装各种依赖。
setup.py可以将这些事情自动化起来，提高效率、减少出错的概率。"复杂的东西自动化，能自动化的东西一定要自动化。"是一个非常好的习惯。
setuptools的文档比较庞大，刚接触的话，可能不太好找到切入点。学习技术的方式就是看他人是怎么用的，可以参考一下Python的一个Web框架，flask是如何写的:setup.py 。
当然，简单点自己写个安装脚本（deploy.sh）替代setup.py也未尝不可。
requirements.txt
这个文件存在的目的是:
- 方便开发者维护软件的包依赖。将开发过程中新增的包添加进这个列表中，避免在setup.py安装依赖时漏掉软件包。
- 方便读者明确项目使用了哪些Python包。
这个文件的格式是每一行包含一个包依赖的说明，通常是flask>=0.10这种格式，要求是这个格式能被pip识别，这样就可以简单的通过 pip install -r requirements.txt来把所有Python包依赖都装好了。具体格式说明参考 。
关于配置文件的使用方法
注意，在上面的目录结构中，没有将conf.py放在源码目录下，而是放在docs/目录下。
很多项目对配置文件的使用做法是:
- 配置文件写在一个或多个python文件中，比如此处的conf.py。
- 项目中哪个模块用到这个配置文件就直接通过import conf这种形式来在代码中使用配置。
这种做法我不太赞同:
- 这让单元测试变得困难（因为模块内部依赖了外部配置）
- 另一方面配置文件作为用户控制程序的接口，应当可以由用户自由指定该文件的路径。
- 程序组件可复用性太差，因为这种贯穿所有模块的代码硬编码方式，使得大部分模块都依赖conf.py这个文件。
所以，我认为配置的使用，更好的方式：
- 模块的配置都是可以灵活配置的，不受外部配置文件的影响。
- 程序的配置也是可以灵活控制的。
能够佐证这个思想的是，用过nginx和mysql的同学都知道，nginx、mysql这些程序都可以自由的指定用户配置。
所以，不应当在代码中直接import conf来使用配置文件。上面目录结构中的conf.py，是给出的一个配置样例，不是在写死在程序中直接引用的配置文件。可以通过给main.py启动参数指定配置路径的方式来让程序读取配置内容。当然，这里的conf.py你可以换个类似的名字，比如settings.py。或者你也可以使用其他格式的内容来编写配置文件，比如settings.yaml之类的。 收起阅读 »
nmap深度入门讲解
接着讲上节的内容，上节中提到了一个时间优化的问题是使用参数-n,通过不解析地址来进行优化时间的，但是优化时间的方法还有很多，比如说我们可以通过时间优化(0-5)，指定单位时间内的探针数，设置组的大小。
时间优化
时间优化的参数是(-T0~5)，最快的扫描速度为-T5,最慢的扫描速度为-T0,实现的原理：通过设置各个端口的扫描周期，从而来控制整个扫描的时间，比如说T0各个端口的扫描周期大约为5分钟，而T5各个端口的扫描周期为5ms，但是过快的扫描也是有缺点的，扫描的周期过快，会很容易被防火墙和IDS发现并记录，因为防火墙大多数会将端口周期过段识别为扫描从而屏蔽掉，如果不对其进行设置的话，默认值为T4
--min-hostgroup/--max-hostgroup size 设置组的大小在上节中还讲漏了一个知识点获取指定端口的参数（-p），这个参数的意义在于对于我们有时候只想监控某个特定的端口的状态，这个参数是即为有用的，可以节约了不少的时间
--min-parallelism/--max-parellelism time 指定时间内的探针数
例如：监控nmap.org的80端口的状态，命令：
nmap -p 80 baidu.com
怎样规避被防火墙或IDS发现的风险以及操作的步骤
上节中我们假设的是在一个网络安全较为薄弱的情况下就可以正常进行的，但是正常的网站或者个人都是对安全有一定的防范的，网站中基本上都会存在安全狗、防火墙等规避风险的措施，个人电脑也会安装各种安全软件，所以对于做扫描工作的人来说，我们不知道通过扫描获取相关的信息，同时也要保护好自己的隐私，比如IP等信息，防止被防火墙或者是网络日志所记录下来
在讲这节之前我们来了解一下什么是防火墙？
防火墙的原理图如下:
防火墙是通过在客户端与服务器端之间搭建一个监控（运行的原理有点像Fiddler），通过对特定开放的端口进行屏蔽掉，从而达到网络安全的作用，防火墙在其功能上也会有一些其他的功能，这个要看防火墙的实际情况。
规避的基本思路：
- 通过伪造访问的IP地址
- 通过对发送信息进行处理
- 将风险进行嫁接
- 其他的技术
伪造IP地址
伪造IP地址有很多种方法，可以通过下面的这几种方法是我认为比较常见让大家了解。
一、诱饵扫描(-D)
诱饵扫描的工作原理是：通过伪造大量的IP与自己真实的IP一起访问网站，从而混淆管理员的判断，其中问你们使用ME来代表自己的真实地址
例子：虚构一个IP为203.88.163.34与自己的真实地址去扫描baidu.com
命令：sudo nmap -F -D 203.88.163.34,ME baidu.com
结果如下：
Starting Nmap 7.00 ( https://nmap.org ) at 2016-09-20 20:07 CST但是在使用伪造的IP的同时，我们要注意要对伪造的IP进行主机发现，来判断主机是否存在，是否开启，因为有些防火墙策略是有这样规定的：如果访问的IP主机是关闭或者是为空的话，就讲所有的返回内容过滤掉。试想一下，如果主机关闭或者是不存在，那么怎么可能会发送扫描的命令给目标主机呢？
Nmap scan report for baidu.com (123.125.114.144)
Host is up (0.10s latency).
Other addresses for baidu.com (not scanned): 220.181.57.217 180.149.132.47 111.13.101.208
Not shown: 98 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 3.59 seconds
要找到开启的目标主机理论上是没有什么要求的，但是为了节约时间，我建议是直接使用某个网站的IP地址，这样有如下几个好处：
- IP地址容易获得，一般的网站是通过ping参数就可以直接获取该网站的IP地址，除了一些不让进行Ping操作的网站除外
- 容易保证IP的正常开启，因为谁家的网站会经常关闭服务器，服务器一般是总是开启的
二、源地址欺骗(-S)
源地址欺骗的原理是：通过将自己的IP伪装成为其他的IP去扫描目标主机从而骗过目标主机的追踪
假设要伪装成为1.1.1.1：参数-S 1.1.1.1 使用1.1.1.1进行扫描，让防火墙误以为是来自1.1.1.1的扫描行为
在使用的时候要注意与-e进行使用，因为除了制定要伪装成为的对象IP外，还要指定返回的IP地址
三、时间优化（-T）
通过时间优化也提高通过防火墙和IDS的通过率
发送信息处理
指定使用分片(-f)
分片的工作原理是：将可疑的探测包进行分片处理（例如将TCP包拆分成多个IP包发送过去），某些简单的防火墙为了加快处理速度可能不会进行重组检查，以此避开其检查。
将风险责任进行嫁接
空闲扫描（-sI）：
这里有一篇比较全面的文章http://www.2cto.com/Article/201505/396631.html 在这就不多做介绍
其他的相关技术：
有MAC伪造技术等
防火墙/IDS躲避和哄骗
