发起

kvm虚拟机克隆过程详解

koyo 发表了文章 2 个评论 5993 次浏览 2015-10-17 18:44 来自相关话题

在使用ucloud云主机的时候，发现他们制作镜像只能克隆系统盘数据制作，这是为什么，为什么不能连数据盘一起克隆呢，然后就问了一下他们的技术人员，他们底层用的是kvm技术，因为kvm镜像制作会按照你主机空间大小块来克隆，意思就是说，比如我/ 分区大小为20G，数 ...查看全部
在使用ucloud云主机的时候，发现他们制作镜像只能克隆系统盘数据制作，这是为什么，为什么不能连数据盘一起克隆呢，然后就问了一下他们的技术人员，他们底层用的是kvm技术，因为kvm镜像制作会按照你主机空间大小块来克隆，意思就是说，比如我/ 分区大小为20G，数据盘/data分区大小为200G，然后你连着数据盘一起制作镜像的话，存在两个问题：
    []克隆镜像使用时间较长[/][]克隆出来的镜像大小较大，如上面所说的主机，那克隆出来的镜像大小为220G[/]

所以基于这种情况，ucloud的上面的云主机默认创建的主机系统磁盘大小为20G，创建镜像的时候只会克隆系统盘！所以你要做基准镜像，就需要先创建一个基准系统，安装好服务，然后做镜像，最后挂载数据盘！
 
同样我们公司内网也使用了一些kvm虚拟机作为内网的测试环境和一些服务。下面简单的记录自己的笔记，总结还是看自己的笔记比较有思路，回头看思路比较清晰！
 
查阅资料和书籍，kvm虚拟机克隆有如下两种方式：
    []KVM本机虚拟机直接克隆[/][]通过复制xml文件与磁盘文件复制克隆 (适用于异机的静态迁移和状态保存便于以后使用)。[/]
下面逐一介绍：

一、本机直接克隆

1、查看虚拟机配置文件获取磁盘文件路径
[root@kvmsuzhu2 ~]# cat /etc/libvirt/qemu/hysen_6101_101.xml |grep 'source file'|grep img      [root@kvmsuzhu2 ~]# cat /etc/libvirt/qemu/hysen_6101_101.xml |grep '^.*/name>$'  hysen_6101_101[root@kvmsuzhu2 ~]# 
克隆前确认主机已经关闭：
[root@kvmsuzhu ~]# virsh list --all Id    名称                         状态---------------------------------------------------- 3     dev_5974_74                    running 14    dev_5954_54                    running -     hysen_6101_101                 关闭 -     openstack_5978_78              关闭
不关闭则克隆会报ERROR    Domain with devices to clone must be paused or shutoff.
2、开始克隆
[root@kvmsuzhu2 ~]# virt-clone -o hysen_6101_101 -n hysen_6103_103 -f /data1/vmdisk/hysen_6103_103.img 正在克隆 hysen_6101_101.img                                                                        |  30 GB     13:55     Clone 'hysen_6103_103' created successfully.克隆已经完成30G的大小！
3、修改vnc端口号，启动主机
[root@kvmsuzhu2 ~]# cat /etc/libvirt/qemu/hysen_6103_103.xml |grep 'vnc'    [root@kvmsuzhu2 ~]# virsh edit hysen_6103_103    //这里你必须用virsh edit命令编辑配置文件，用vim编辑是不会生效的！编辑了域 hysen_6103_103 XML 配置。[root@kvmsuzhu2 ~]# cat /etc/libvirt/qemu/hysen_6103_103.xml |grep 'vnc'    [root@kvmsuzhu2 ~]# virsh start hysen_6103_103.xml域 hysen_6103_103 已开始[root@kvmsuzhu2 ~]# netstat -anltp |grep 6103tcp        0      0 0.0.0.0:6103                0.0.0.0:*                   LISTEN      13740/qemu-kvm [root@kvmsuzhu2 ~]#
4、修改主机名、ip地址
修改主机名[root@hysen_6101_101 ~]# vi /etc/sysconfig/networkNETWORKING=yes    NETWORKING_IPV6=no     HOSTNAME=hysen_6103_103 GATEWAY=10.0.1.1[root@hysen_6101_101 ~]# hostname hysen_6103_103修改IP地址[root@hysen_6103_103 ~]# vi /etc/sysconfig/network-script/ifcfg-eth0# Virtio Network Device    DEVICE=eth0     BOOTPROTO=static     ONBOOT=yes     HWADDR=52:54:00:ae:1d:7b     IPADDR=10.0.1.117     NETMASK=255.255.255.0注意修改mac地址，有uuid的配置修改uuid配置[root@hysen_6103_103 ~]# service network start重启报错：device eth0 does not seem to be present, delaying initialization如下操作解决：[root@hysen_6103_103 ~]# rm -rf /etc/udev/rules.d/70-persistent-net.rules 有说修改文件把eth0和eth1互换的也可以！[root@hysen_6103_103 ~]# reboot重启网卡服务[root@hysen_6103_103 ~]# service network start    Bringing up loopback interface:  [  OK  ]     Bringing up interface eth0:  [  OK  ]     [root@hysen_6103_103 ~]#

二、通过复制xml文件与磁盘文件复制克隆

我们这里还是拿hysen_6101_101虚拟机作为模板机器克隆。同样这种方法也需要模板机器已经关机！1、复制xml配置文件
[root@kvmsuzhu2 ~]# virsh dumpxml hysen_6101_101 > /etc/libvirt/qemu/hysen_6105_105.xml[root@kvmsuzhu2 ~]# ls -l /etc/libvirt/qemu/hysen_6105_105.xml-rw-r--r-- 1 root root 2748 10月 17 17:50 /etc/libvirt/qemu/hysen_6105_105.xml[root@kvmsuzhu2 ~]#
2、复制hysen_6101_101虚拟机磁盘文件
[root@kvmsuzhu2 ~]# cp  /data1/vmdisk/hysen_6101_101.img  /data1/vmdisk/hysen_6105_105.img[root@kvmsuzhu2 ~]# ls /data1/vmdisk/hysen_6105_105.img/data1/vmdisk/hysen_6105_105.img[root@kvmsuzhu2 ~]#
3、修改拷贝的配置文件
    []修改虚拟机的名称：hysen_6105_105[/][]修改uuid编号：13178d42-1055-8b94-1411-3c2bdd0e6e7a<[/][]修改mac地址：[/][]修改disk位置：[/][]修改vnc端口：[/]

此时还是将该配置文件注册进来，无法通过virsh edit进行编辑。
[root@kvmsuzhu2 ~]# vim /etc/libvirt/qemu/hysen_6105_105.xml

hysen_6101_101

13178d42-1055-8b94-1411-3c2bdd0e6e7a
4、定义新虚拟机配置文件
[root@kvmsuzhu2 ~]# virsh define /etc/libvirt/qemu/hysen_6105_105.xml 

定义域 hysen_6105_105（从 /etc/libvirt/qemu/hysen_6105_105.xml）



[root@kvmsuzhu2 ~]#
5、启动虚拟机并设置开机自启
[root@kvmsuzhu2 ~]# virsh start hysen_6105_105

域 hysen_6105_105 已开始



[root@kvmsuzhu2 ~]# virsh autostart hysen_6105_105

域 hysen_6105_105标记为自动开始



[root@kvmsuzhu2 ~]# virsh list --all |grep hysen_6105_105

 237   hysen_6105_105                 running

[root@kvmsuzhu2 ~]#
6、vnc连接修改主机名、ip地址
4、修改主机名、ip地址

修改主机名

[root@hysen_6101_101 ~]# vi /etc/sysconfig/network

NETWORKING=yes    

NETWORKING_IPV6=no     

HOSTNAME=hysen_6105_105 

GATEWAY=10.0.1.1

[root@hysen_6101_101 ~]# hostname hysen_6105_105



修改IP地址

[root@hysen_6105_105 ~]# vi /etc/sysconfig/network-script/ifcfg-eth0

# Virtio Network Device    

DEVICE=eth0     

BOOTPROTO=static     

ONBOOT=yes     

HWADDR=54:52:01:11:12:1f     

IPADDR=10.0.1.118     

NETMASK=255.255.255.0



重启网卡服务

[root@hysen_6105_105 ~]# service network start

重启报错：device eth0 does not seem to be present, delaying initialization



如下操作解决：

[root@hysen_6105_105 ~]# rm -rf /etc/udev/rules.d/70-persistent-net.rules 有说修改文件把eth0和eth1互换的也可以！

[root@hysen_6105_105 ~]# reboot



重启之后再次登陆重启动网卡：

[root@hysen_6105_105 ~]# service network start

Bringing up loopback interface:  [  OK  ]     

Bringing up interface eth0:  [  OK  ]
两种不同的方式有各有特点，你可以针对特点选择性使用！

kvm虚拟机怎么解决mac地址冲突

空心菜 回复了问题 3 人关注 2 个回复 7254 次浏览 2015-10-16 15:43 来自相关话题

HBase file layout needs to be upgraded案例分析

空心菜 发表了文章 0 个评论 7648 次浏览 2015-10-15 01:00 来自相关话题

今天在一个内网的测试环境平台，kafka的river插件状态非正常，然后同事只好重建kafka river，river的状态始终无法正常，没有办法，同事对服务还不是很熟悉，我只好帮忙看看了！   因为kafka 的river插件作为ka ...查看全部
hbase_image.png
今天在一个内网的测试环境平台，kafka的river插件状态非正常，然后同事只好重建kafka river，river的状态始终无法正常，没有办法，同事对服务还不是很熟悉，我只好帮忙看看了！
 
因为kafka 的river插件作为kafka消息数据的consumers角色，把消费掉的数据，通过Hbase转存储到hdfs中！
如下所示是river对hbase的配置：




 hbase.rootdir

 hdfs://10.2.2.39:9000/hbase





 hbase.cluster.distributed

 true





hbase.master

10.2.2.39:60000





 hbase.zookeeper.quorum

 10.2.2.56,10.2.2.94,10.2.2.225
从这可以看出river插件是需要hbase的，然后我执行创建river的命令，tail观看到hbase master的hbase-root-master-hbase1.log如下：
2015-10-14 17:34:13,980 INFO  [master:hbase1:60000] util.FSUtils: Waiting for dfs to exit safe mode...
从log中可以看出hbase在等待hdfs退出安全模式，为什么要等Hdfs退出安全模式呢？那下面就具体看看Hdfs的log中有什么线索，查看Hdfs的Namenode的hadoop-root-namenode-had1.log记录如下：
2015-10-14 17:33:52,283 ERROR org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException as:root (auth:SIMPLE) cause:org.apache.hadoop.hdfs.server.namenode.SafeModeException: Log not rolled. Name node is in safe mode.
运行如下命令等待退出安全模式
bin/hadoop dfsadmin -safemode wait
发现半分钟后没有反映，然后运行如下命令检查hdfs的健康状态
bin/hadoop fsck /
发现有很多corrupt blocks，不过还好备份数大于1.此时，hdfs需要自动的把备份数增加到2，所以需要对数据进行写操作，必须退出安全模式，于是：
bin/hadoop  dfsadmin -safemode leave
关闭之后等待集群把数据备份好，达到2，耐心等待一段时间吧，看数据量的大小，达到2之后，运行：
bin/hadoop  fsck -move
也可以尝试：执行健康检查，删除损坏掉的block。 bin/hdfs fsck  /  -delete 注意: 这种方式会出现数据丢失，损坏的block会被删掉.
把那些破坏的块移到/lost+found这个目录下面，启动Hbase，发现Hmaster启动之后进程又消失了，查看日志：
2015-10-14 17:48:29,476 FATAL [master:hbase1:60000] master.HMaster: Unhandled exception. Starting shutdown.

org.apache.hadoop.hbase.util.FileSystemVersionException: HBase file layout needs to be upgraded. You have version null and I want version 8. Consult http://hbase.apache.org/book.html for further information about upgrading HBase. Is your hbase.rootdir valid? If so, you may need to run 'hbase hbck -fixVersionFile'.

	at org.apache.hadoop.hbase.util.FSUtils.checkVersion(FSUtils.java:600)

	at org.apache.hadoop.hbase.master.MasterFileSystem.checkRootDir(MasterFileSystem.java:462)

	at org.apache.hadoop.hbase.master.MasterFileSystem.createInitialFileSystemLayout(MasterFileSystem.java:153)

	at org.apache.hadoop.hbase.master.MasterFileSystem.(MasterFileSystem.java:129)

	at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:800)

	at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:605)

	at java.lang.Thread.run(Thread.java:744)
从什么log中可以发现可能是hbase.version文件消失了！我看很多网友的做法是先把/hbase清理调，然后重启就好了，但是以前的数据就丢失了，这有点不科学。于是我：
bin/hadoop fs -ls /hbase
发现/hbase/hbase.version确实已经消失了，这才恍然大悟，原来是之前的这个文件可能被损坏了，去/lost+found目录找确实能找到，但是这个文件似乎出了问题，-ls它也看不到。于是想到一个办法，我做了以下操作：
bin/hadoop fs -mv /hbase /hbase.bk
重启HBase，这时就生成了/hbase/hbase.version文件，然后：
bin/hadoop fs -cp /hbase/hbase.version /hbase.bk/



bin/hadoop fs -rmr /hbase 



bin/hadoop fs -mv /hbase.bk /hbase
这样再次重启HBase，发现Hbase开始splitting hlogs，数据得以恢复。然后再重建river，状态可以正常了！

docker与虚拟机性能比较

Geek小A 发表了文章 0 个评论 5109 次浏览 2015-10-12 19:14 来自相关话题

概要 docker是近年来新兴的虚拟化工具，它可以和虚拟机一样实现资源和系统环境的隔离。本文将主要根据IBM发表的研究报告，论述docker与传统虚拟化方式的不同之处，并比较物理机、docker容器、虚拟机三者的性能差异及差异产生的原 ...查看全部


概要


docker是近年来新兴的虚拟化工具，它可以和虚拟机一样实现资源和系统环境的隔离。本文将主要根据IBM发表的研究报告，论述docker与传统虚拟化方式的不同之处，并比较物理机、docker容器、虚拟机三者的性能差异及差异产生的原理。


docker与虚拟机实现原理比较


如下图分别是虚拟机与docker的实现框架。
dvk1.png 
比较两图的差异，左图虚拟机的Guest OS层和Hypervisor层在docker中被Docker Engine层所替代。虚拟机的Guest OS即为虚拟机安装的操作系统，它是一个完整操作系统内核；虚拟机的Hypervisor层可以简单理解为一个硬件虚拟化平台，它在Host OS是以内核态的驱动存在的。

 
虚拟机实现资源隔离的方法是利用独立的OS，并利用Hypervisor虚拟化CPU、内存、IO设备等实现的。例如，为了虚拟CPU，Hypervisor会为每个虚拟的CPU创建一个数据结构，模拟CPU的全部寄存器的值，在适当的时候跟踪并修改这些值。需要指出的是在大多数情况下，虚拟机软件代码是直接跑在硬件上的，而不需要Hypervisor介入。只有在一些权限高的请求下，Guest OS需要运行内核态修改CPU的寄存器数据，Hypervisor会介入，修改并维护虚拟的CPU状态。 




Hypervisor虚拟化内存的方法是创建一个shadow page table。正常的情况下，一个page table可以用来实现从虚拟内存到物理内存的翻译。在虚拟化的情况下，由于所谓的物理内存仍然是虚拟的，因此shadow page table就要做到：虚拟内存->虚拟的物理内存->真正的物理内存。



对于IO设备虚拟化，当Hypervisor接到page fault，并发现实际上虚拟的物理内存地址对应的是一个I/O设备，Hypervisor就用软件模拟这个设备的工作情况，并返回。比如当CPU想要写磁盘时，Hypervisor就把相应的数据写到一个host OS的文件上，这个文件实际上就模拟了虚拟的磁盘。


对比虚拟机实现资源和环境隔离的方案，docker就显得简练很多。docker Engine可以简单看成对Linux的NameSpace、Cgroup、镜像管理文件系统操作的封装。docker并没有和虚拟机一样利用一个完全独立的Guest OS实现环境隔离，它利用的是目前Linux内核本身支持的容器方式实现资源和环境隔离。简单的说，docker利用namespace实现系统环境的隔离；利用Cgroup实现资源限制；利用镜像实现根目录环境的隔离。
通过docker和虚拟机实现原理的比较，我们大致可以得出一些结论：
（1）docker有着比虚拟机更少的抽象层。由于docker不需要Hypervisor实现硬件资源虚拟化，运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上docker将会在效率上有优势，具体的效率对比在下几个小节里给出。在IO设备虚拟化上，docker的镜像管理有多种方案，比如利用Aufs文件系统或者Device Mapper实现docker的文件管理，各种实现方案的效率略有不同。
（2）docker利用的是宿主机的内核，而不需要Guest OS。因此，当新建一个容器时，docker不需要和虚拟机一样重新加载一个操作系统内核。我们知道，引导、加载操作系统内核是一个比较费时费资源的过程，当新建一个虚拟机时，虚拟机软件需要加载Guest OS，这个新建过程是分钟级别的。而docker由于直接利用宿主机的操作系统，则省略了这个过程，因此新建一个docker容器只需要几秒钟。另外，现代操作系统是复杂的系统，在一台物理机上新增加一个操作系统的资源开销是比较大的，因此，docker对比虚拟机在资源消耗上也占有比较大的优势。事实上，在一台物理机上我们可以很容易建立成百上千的容器，而只能建立几个虚拟机。


docker与虚拟机计算效率比较


在上一节我们从原理的角度推测docker应当在CPU和内存的利用效率上比虚拟机高。在这一节我们将根据IBM发表的论文给出的数据进行分析。以下的数据均是在IBM x3650 M4服务器测得，其主要的硬件参数是： 
（1）2颗英特尔xeon E5-2655 处理器，主频2.4-3.0 GHz。每颗处理器有8个核，因此总共有16个核。
（2）256 GB RAM.
在测试中是通过运算Linpack程序来获得计算能力数据的。结果如下图所示： 
dvk2.png 
图中从左往右分别是物理机、docker和虚拟机的计算能力数据。可见docker相对于物理机其计算能力几乎没有损耗，而虚拟机对比物理机则有着非常明显的损耗。虚拟机的计算能力损耗在50%左右。 
为什么会有这么大的性能损耗呢？一方面是因为虚拟机增加了一层虚拟硬件层，运行在虚拟机上的应用程序在进行数值计算时是运行在Hypervisor虚拟的CPU上的；另外一方面是由于计算程序本身的特性导致的差异。虚拟机虚拟的cpu架构不同于实际cpu架构，数值计算程序一般针对特定的cpu架构有一定的优化措施，虚拟化使这些措施作废，甚至起到反效果。
比如对于本次实验的平台，实际的CPU架构是2块物理CPU，每块CPU拥有16个核，共32个核，采用的是NUMA架构；而虚拟机则将CPU虚拟化成一块拥有32个核的CPU。这就导致了计算程序在进行计算时无法根据实际的CPU架构进行优化，大大减低了计算效率。


docker与虚拟机内存访问效率比较


内存访问效率的比较相对比较复杂一点，主要是内存访问有多种场景： 
（1）大批量的，连续地址块的内存数据读写。这种测试环境下得到的性能数据是内存带宽，性能瓶颈主要在内存芯片的性能上； 
（2）随机内存访问性能。这种测试环境下的性能数据主要与内存带宽、cache的命中率和虚拟地址与物理地址转换的效率等因素有关。
以下将主要针对这两种内存访问场景进行分析。在分析之前我们先概要说明一下docker和虚拟机的内存访问模型差异。下图是docker与虚拟机内存访问模型： 
dvk3.png 
可见在应用程序内存访问上，虚拟机的应用程序要进行2次的虚拟内存到物理内存的映射，读写内存的代价比docker的应用程序高。
下图是场景（1）的测试数据，即内存带宽数据。左图是程序运行在一块CPU（即8核）上的数据，右图是程序运行在2块CPU（即16核）上的数据。单位均为GB/s。 
dvk4.png

dvk5.png 
从图中数据可以看出，在内存带宽性能上docker与虚拟机的性能差异并不大。这是因为在内存带宽测试中，读写的内存地址是连续的，大批量的，内核对这种操作会进行优化（数据预存取）。因此虚拟内存到物理内存的映射次数比较少，性能瓶颈主要在物理内存的读写速度上，因此这种情况docker和虚拟机的测试性能差别不大; 
内存带宽测试中docker与虚拟机内存访问性能差异不大的原因是由于内存带宽测试中需要进行虚拟地址到物理地址的映射次数比较少。根据这个假设，我们推测，当进行随机内存访问测试时这两者的性能差距将会变大，因为随机内存访问测试中需要进行虚拟内存地址到物理内存地址的映射次数将会变多。
结果如下图所示:
dvk6.png

dvk7.png 
1图是程序运行在一个CPU上的数据，右图是程序运行在2块CPU上的数据。从左图可以看出，确实如我们所预测的，在随机内存访问性能上容器与虚拟机的性能差距变得比较明显，容器的内存访问性能明显比虚拟机优秀；但出乎我们意料的是在2块CPU上运行测试程序时容器与虚拟机的随机内存访问性能的差距却又变的不明显。
针对这个现象，IBM的论文给出了一个合理解释。这是因为当有2块CPU同时对内存进行访问时，内存读写的控制将会变得比较复杂，因为两块CPU可能同时读写同一个地址的数据，需要对内存数据进行一些同步操作，从而导致内存读写性能的损耗。这种损耗即使对于物理机也是存在的，可以看出右图的内存访问性能数据是低于左图的。2块CPU对内存读写性能的损耗影响是非常大的，这个损耗占据的比例远大于虚拟机和docker由于内存访问模型的不同产生的差异，因此在右图中docker与虚拟机的随机内存访问性能上我们看不出明显差异。


docker与虚拟机启动时间及资源耗费比较


上面两个小节主要从运行在docker里的程序和运行在虚拟机里的程序进行性能比较。
事实上，docker之所以如此受到开发者关注的另外一个重要原因是启动docker的系统代价比启动一台虚拟机的代价要低得多：无论从启动时间还是从启动资源耗费角度来说。docker直接利用宿主机的系统内核，避免了虚拟机启动时所需的系统引导时间和操作系统运行的资源消耗。利用docker能在几秒钟之内启动大量的容器，这是虚拟机无法办到的。快速启动、低系统资源消耗的优点使docker在弹性云平台和自动运维系统方面有着很好的应用前景。


docker的劣势


前面的内容主要论述docker相对于虚拟机的优势，但docker也不是完美的系统。相对于虚拟机，docker还存在着以下几个缺点：
1.资源隔离方面不如虚拟机，docker是利用cgroup实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。
2.安全性问题。docker目前并不能分辨具体执行指令的用户，只要一个用户拥有执行docker的权限，那么他就可以对docker的容器进行所有操作，不管该容器是否是由该用户创建。比如A和B都拥有执行docker的权限，由于docker的server端并不会具体判断docker cline是由哪个用户发起的，A可以删除B创建的容器，存在一定的安全风险。 
3.docker目前还在版本的快速更新中，细节功能调整比较大。一些核心模块依赖于高版本内核，存在版本兼容问题


原文作者：chenbiaolong
 
 
分享原文地址：http://blog.csdn.net/cbl709/article/details/43955687


怎么限制docker容器的磁盘和带宽

Ansible 回复了问题 2 人关注 1 个回复 7307 次浏览 2015-10-12 18:10 来自相关话题

elasticsearch中文分词插件IK使用

空心菜 发表了文章 0 个评论 3896 次浏览 2015-09-21 11:40 来自相关话题

ES支持中文的前提是安装正确的分词组件，比如elasticsearch-analysis-ik。 版本支持如下： 安装 # git clo ...查看全部
eslogo.png

ES支持中文的前提是安装正确的分词组件，比如elasticsearch-analysis-ik。
版本支持如下：
ik1.png


安装


# git clone https://github.com/medcl/elasticsearch-analysis-ik.git --depth 1

# cd elasticsearch-analysis-ik/

# mvn package

# unzip ./target/releases/elasticsearch-analysis-ik-1.2.9.zip

OR
# git clone https://github.com/medcl/elasticsearch-analysis-ik

# cd elasticsearch-analysis-ik

# mvn compile

# mvn package

# plugin --install analysis-ik --url file:///#{project_path}/elasticsearch-analysis-ik/target/releases/elasticsearch-analysis-ik-1.3.0.zip
zip解压得到5个jar包：
    []- elasticsearch-analysis-ik-1.2.9.jar[/][]- httpclient-4.3.5.jar[/][]- httpcore-4.3.2.jar[/][]- commons-logging-1.1.3.jar[/][]- commons-codec-1.6.jar[/]

 
返回ES目录，新建路径./plugins/analysis-ik并把上述jar包全部移进去。
第二步，把elasticsearch-analysis-ik/config/ik文件夹（IK自带的词典）复制到ES目录的./config路径下。
第三步，在./config/elasticsearch.yml文件的最后加上：
index:

  analysis:

    analyzer:

      ik:

          alias: [news_analyzer_ik,ik_analyzer]

          type: org.elasticsearch.index.analysis.IkAnalyzerProvider



index.analysis.analyzer.default.type : "ik"

OR
[b]index.analysis.analyzer.ik.type : "ik"[/b]
注意配置分词组件必须在创建索引之前，否则是无效的。


Example


1.create a index
# curl -XPUT http://localhost:9200/index
2.create a mapping
# curl -XPUT http://localhost:9200/index

create a mapping

curl -XPOST http://localhost:9200/index/fulltext/_mapping -d'

{

    "fulltext": {

             "_all": {

            "indexAnalyzer": "ik",

            "searchAnalyzer": "ik",

            "term_vector": "no",

            "store": "false"

        },

        "properties": {

            "content": {

                "type": "string",

                "store": "no",

                "term_vector": "with_positions_offsets",

                "indexAnalyzer": "ik",

                "searchAnalyzer": "ik",

                "include_in_all": "true",

                "boost": 8

            }

        }

    }

}'
3.index some docs
# curl -XPOST http://localhost:9200/index/fulltext/1 -d'

{"content":"美国留给伊拉克的是个烂摊子吗"}

'
# curl -XPOST http://localhost:9200/index/fulltext/2 -d'

{"content":"公安部：各地校车将享最高路权"}

'
# curl -XPOST http://localhost:9200/index/fulltext/3 -d'

{"content":"中韩渔警冲突调查：韩警平均每天扣1艘中国渔船"}

' 
# curl -XPOST http://localhost:9200/index/fulltext/4 -d'

{"content":"中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"}

'
4.query with highlighting
# curl -XPOST http://localhost:9200/index/fulltext/_search  -d'

{

    "query" : { "term" : { "content" : "中国" }},

    "highlight" : {

        "pre_tags" : ["", ""],

        "post_tags" : ["", ""],

        "fields" : {

            "content" : {}

        }

    }

}

'
Result
{

    "took": 14,

    "timed_out": false,

    "_shards": {

        "total": 5,

        "successful": 5,

        "failed": 0

    },

    "hits": {

        "total": 2,

        "max_score": 2,

        "hits": [

            {

                "_index": "index",

                "_type": "fulltext",

                "_id": "4",

                "_score": 2,

                "_source": {

                    "content": "中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"

                },

                "highlight": {

                    "content": [

                        "中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首 "

                    ]

                }

            },

            {

                "_index": "index",

                "_type": "fulltext",

                "_id": "3",

                "_score": 2,

                "_source": {

                    "content": "中韩渔警冲突调查：韩警平均每天扣1艘中国渔船"

                },

                "highlight": {

                    "content": [

                        "均每天扣1艘中国渔船 "

                    ]

                }

            }

        ]

    }

}

Elasticsearch索引存储类型

空心菜 发表了文章 0 个评论 9114 次浏览 2015-09-20 16:59 来自相关话题

文件系统存储类型     基于文件系统的存储是默认索引存储方式。有不同的实现或存储类型。最好的一个操作系统的自动选择是：mmapfs使用在Windows的64bit系统上，simplefs使用在windows的32bit系统上，除此之外默认是用(h ...查看全部
eslogo.png


文件系统存储类型
    基于文件系统的存储是默认索引存储方式。有不同的实现或存储类型。最好的一个操作系统的自动选择是：mmapfs使用在Windows的64bit系统上，simplefs使用在windows的32bit系统上，除此之外默认是用(hybrid niofs 和 mmapfs)。
 
    你可以通过修改配置文件elasticsearch.yml来指定存储类型：
index.store.type: niofs
    当然你也可以在创建索引的时候指定：
curl -XPUT localhost:9200/my_index -d '{

    "settings": {

        "index.store.type": "niofs"

    }

}';
    下面是所有支持的不同存储类型：


Simple FS（简单文件系统）


Simplefs类型是一个简单的实现随机访问文件的文件存储系统（映射到Lucene SimpleFsDirectory的）。该实现的并发性能较差（多线程是个瓶颈）。当你需要将索引持久化，最好使用niofs。


NIO FS（NIO文件系统）


niofs类型是通过NIO将分片索引文件写到文件系统上（映射到Lucene NIOFSDirectory）。它允许多线程同时读取文件。不建议在Windows系统上使用，由于SUN JAVA实现上的一个错误。


MMap FS（内存映射文件系统）


mmapfs类型存储分片索引到文件系统上（映射到Lucene MMapDirectory）通过映射文件到内存中（MMAP）。内存映射的过程中将划分出与被映射文件大小一样的虚拟内存空间。使用这个类之前，请确保您有足够的虚拟地址空间。
Linux下虚拟内存设置：

  # sysctl -w vm.max_map_count=262144

  永久生效：

  update the vm.max_map_count setting in /etc/sysctl.conf.

  # echo "vm.max_map_count=262144" >> /etc/sysctl.conf && sysctl -p


Hybrid MMap / NIO FS


默认类型存储碎片索引在文件系统中根据不同的文件类型的文件映射到内存(mmap)或使用Java NIO。目前只Lucene术语字典和doc值文件内存映射到减少对操作系统的影响。所有其他文件都使用Lucene NIOFSDirectory打开。

内存
    内存类型索引存储在主内存,使用Lucene的RamIndexStore。
    
    也有节点级别的设置来控制高速缓存（重要的，当使用直接缓冲区）：
estore.png

参考：https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html#store-memory
           https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#file-descriptors

docker怎么让nginx访问我指定的目录

koyo 回复了问题 2 人关注 1 个回复 6436 次浏览 2015-09-19 20:26 来自相关话题

elasticsearch特点介绍

空心菜 发表了文章 0 个评论 5566 次浏览 2015-09-19 16:07 来自相关话题

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

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


实时数据


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


实时分析


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


分布式


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


高可用


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


多租户


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


全文搜索


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


面向文档


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


模式自由


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


友好的RESTful API


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


操作持久化


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


Apache 2开源许可证


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


基于Apache Lucene之上


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


冲突管理


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

英文地址：原文地址

elasticsearch不能触碰的配置

空心菜 发表了文章 0 个评论 3041 次浏览 2015-09-19 14:17 来自相关话题

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

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


垃圾收集器(Garbage Collector)


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



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



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

 

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

 

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


线程池(Threadpoolsedit)


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



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



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

 

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



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



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



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



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



    所以。 下次你要调整一个线程池，请不要。 如果你绝对无法抗拒 ，请保持你的核心数量在心中，也许设置数量增加一倍。 更重要的是仅仅是一种浪费。


原文地址：https://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html
更多话题 >>

热门话题

更多用户 >>

热门用户