OVM-V1.5版本正式发布，此版本新增对Esxi节点的支持，目前OVM混合虚拟化平台已经能够统一管理KVM、ESXI、Docker三种类型的底层虚拟化技术。同时也提升了OVM的易用性，管理平台和计算节点 iso镜像合并到一个镜像里，安装方面同时新增u盘安装，提高工作效率。


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


OVM-V1.5虚拟化管理平台功能变动清单：

 

Ø  新增对VMwareEsxi节点的支持


Ø  合并管理平台和计算节点镜像为一个iso


Ø  支持通过USB安装OVM


Ø  修复其他若干bug

 

详细信息


1、新增对VMwareEsxi节点的支持

 

OVM-V 1.5版本新增对Esxi节点的支持，支持将现有的VMwareEsxi计算节点直接添加到OVM虚拟化管理平台进行管理，并支持将原有Esxi虚拟机导入到平台进行统一管理。目前OVM混合虚拟化平台已经能够统一管理KVM、ESXI、Docker三种类型的底层虚拟化技术。

 

2.   管理平台和计算节点 iso镜像合并


OVM-V 1.5版本将管理平台和计算节点原来的两个iso镜像合并到一个iso镜像里面，在安装过程中提供选项来安装不同的服务，此次的合并不仅方便了大家的下载，也提升了OVM的易用性。



3.   支持通过USB方式安装，提高工作效率

OVM1.5版本镜像支持通过USB方式进行安装，极大提高了一线运维人员的工作效率。

 

获得帮助

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

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

 

今天用脚本部署一个Docker私有化环境，挂载宿主机目录出现Permission denied的情况，导致服务启动失败，具体情况如下：


问题原因及解决办法：
原因是CentOS7中的安全模块selinux把权限禁掉了，至少有以下三种方式解决挂载的目录没有权限的问题：
1、在运行容器的时候，给容器加特权，及加上 --privileged=true 参数

docker run -i -t -v /data/mysql/data:/data/var-3306 --privileged=true b0387b8279d4 /bin/bash -c "/opt/start_db.sh"

2、临时关闭selinux

setenforce 0

3、添加selinux规则，改变要挂载的目录的安全性文本：

# 更改安全性文本的格式如下

chcon [-R] [-t type] [-u user] [-r role] 文件或者目录



选顷不参数： 

-R  ：连同该目录下癿次目录也同时修改； 

-t  ：后面接安全性本文的类型字段！例如 httpd_sys_content_t ； 

-u  ：后面接身份识别，例如 system_u； 

-r  ：后面街觇色，例如 system_r



[root@localhost Desktop]# chcon --help

Usage: chcon [OPTION]... CONTEXT FILE...

  or:  chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...

  or:  chcon [OPTION]... --reference=RFILE FILE...

Change the SELinux security context of each FILE to CONTEXT.

With --reference, change the security context of each FILE to that of RFILE.



Mandatory arguments to long options are mandatory for short options too.

      --dereference      affect the referent of each symbolic link (this is

                         the default), rather than the symbolic link itself

  -h, --no-dereference   affect symbolic links instead of any referenced file

  -u, --user=USER        set user USER in the target security context

  -r, --role=ROLE        set role ROLE in the target security context

  -t, --type=TYPE        set type TYPE in the target security context

  -l, --range=RANGE      set range RANGE in the target security context

      --no-preserve-root  do not treat '/' specially (the default)

      --preserve-root    fail to operate recursively on '/'

      --reference=RFILE  use RFILE's security context rather than specifying

                         a CONTEXT value

  -R, --recursive        operate on files and directories recursively

  -v, --verbose          output a diagnostic for every file processed



The following options modify how a hierarchy is traversed when the -R

option is also specified.  If more than one is specified, only the final

one takes effect.



  -H                     if a command line argument is a symbolic link

                         to a directory, traverse it

  -L                     traverse every symbolic link to a directory

                         encountered

  -P                     do not traverse any symbolic links (default)



      --help     display this help and exit

      --version  output version information and exit



GNU coreutils online help: 

For complete documentation, run: info coreutils 'chcon invocation'

在主机中修改/data/mysql/data目录的安全性文档

[root@localhost Desktop]# chcon -Rt svirt_sandbox_file_t /data/mysql/data

在docker中就可以正常访问该目录下的相关资源了。
卷权限参考：https://yq.aliyun.com/articles/53990 

ES 有Master节点和Data节点，Master节点什么意思呢？ 就是主人节点，这个集群的主人，就是皇帝。ES同一时刻只有一个Master节点。小生一直看古装走火入魔，所谓心里有王朝，眼里就有王朝，看啥啥是王朝。就用王朝解释下集群，皇帝比喻下Master。我们先来看2个配置项。
 
node.master: true  就是皇子，意思是有资格成为Master,成为皇帝的人选，这是天生的，是无字天书，在elasticsearch.yml里写好的。

discovery.zen.minimum_master_nodes: 1 就是几个皇子在场的时候，才能选新皇帝，不然难以服众，容易脑裂（brain split）是吧。
 

Master的职责

只有皇帝才有资格发布圣旨ClusterState(集群状态)。他维护着这个王朝的状态，决定着这个王朝很多重要的大小事物。有一些事情必须皇帝才能执行，比如砍头（删除索引）。但是ES作为P2P集群，Master的职责，还是被弱化了一些。一张图看一下皇帝的工作内容。


 

什么时候选Master

只有在皇帝驾崩，和王朝诞生的时候，才选举Master皇帝，是吧，想让皇帝禅位，除非他死了，或者王朝被推翻了（所有节点重启）

 
节点启动，要加入一个集群的时候
 

//ZenDiscovery

private void innterJoinCluster() {

        boolean retry = true;

        while (retry) {

            if (lifecycle.stoppedOrClosed()) {

                return;

            }

            retry = false;

            DiscoveryNode masterNode = findMaster(); //找一个节点出来当皇帝

            if (masterNode == null) {

                logger.trace("no masterNode returned");

                retry = true;

                continue;

            }

            //....

或者节点关闭 Master Gone

private void handleMasterGone(final DiscoveryNode masterNode, final String reason) {

 if (lifecycleState() != Lifecycle.State.STARTED) {

            return;

        }

        if (master) {

            return;

        }

        logger.info("master_left [{}], reason [{}]", masterNode, reason);

        clusterService.submitStateUpdateTask("zen-disco-master_failed (" + masterNode + ")", Priority.HIGH, new ProcessedClusterStateUpdateTask() {

            @Override

            public ClusterState execute(ClusterState currentState) {

                if (!masterNode.id().equals(currentState.nodes().masterNodeId())) {

                    return currentState;

                }

                DiscoveryNodes.Builder nodesBuilder = DiscoveryNodes.newNodesBuilder()

                        .putAll(currentState.nodes())

                        .remove(masterNode.id())

                        .masterNodeId(null);

                if (!electMaster.hasEnoughMasterNodes(nodesBuilder.build())) {

                    return rejoin(ClusterState.builder().state(currentState).nodes(nodesBuilder).build(), "not enough master nodes after master left (reason = " + reason + ")");

                }

                final DiscoveryNode electedMaster = electMaster.electMaster(nodesBuilder.build()); // 选举Master

 

Master选举

首先必须是皇子(node.master: true)，具体哪皇子成为皇帝呢？ 看天意啊，最先启动的那个节点。老臣认为。当立嫡长子为太子，成为皇帝啊，这样江山社稷才能稳固啊，（一阵激动）省略上万句。。。好了，演完戏了，看代码。

 
ZenDiscovery模块启动的时候，要加入集群。findMaster 方法里，Ping一堆节点出来，Ping就是发现节点，这里的Ping不是Linux的命令Ping，是向ES的9300端口发送数据的意思。Linux的Ping是可以禁止的，不能因为命令Ping不通机器，就认为相互不能发现节点。Ping有组播MulticastZenPing和单播UnicastZenPing 两种。如果节点少，用单播也可以。组播在一些环境下可能无法相互发现节点，或者被安全软件识别为恶意程序。节点列表确定后。交给 ElectMasterService 去选举，快排后的第一个节点

//ElectMasterService

    /**

     * Elects a new master out of the possible nodes, returning it. Returns null

     * if no master has been elected.

     */

    public DiscoveryNode electMaster(Iterable nodes) {

        List sortedNodes = sortedMasterNodes(nodes);

        if (sortedNodes == null || sortedNodes.isEmpty()) {

            return null;

        }

        return sortedNodes.get(0);

    }



    private List sortedMasterNodes(Iterable nodes) {

        List possibleNodes = Lists.newArrayList(nodes);

        if (possibleNodes.isEmpty()) {

            return null;

        }

        // clean non master nodes

        for (Iterator it = possibleNodes.iterator(); it.hasNext(); ) {

            DiscoveryNode node = it.next();

            if (!node.masterNode()) {

                it.remove();

            }

        }

        CollectionUtil.quickSort(possibleNodes, nodeComparator);

        return possibleNodes;

    }

对了，皇帝上位以后，第一件事情是发布圣旨，昭告天下，以后寡人就是皇帝了。

怎么看，现在谁是皇帝呢？
 

curl http://localhost:9200/_cat/master?v

脑裂问题
 
关于brain split脑裂问题，可以看这个:
如何避免脑裂: http://blog.trifork.com/2013/10/24/how-to-avoid-the-split-brain-problem-in-elasticsearch/  
官方讨论：https://github.com/elasticsearch/elasticsearch/issues/2488 
 
最后，为了让大家对皇帝有个感性的认识，赠图一张，不谢！

原文分享：http://www.codeweblog.com/elasticsearch-%E6%BA%90%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90%E4%B9%8Bmaster%E9%80%89%E4%B8%BE/ 

这是许多Kafka用户提出的常见问题。 这篇文章的目的是解释几个重要的决定因素，并提供一些简单的公式。
 

更多的分区提供更高的吞吐量

首先要理解的是，主题分区是Kafka中并行性的单位。 在生产者和代理端，对不同分区的写入可以完全并行完成。 因此，昂贵的操作（例如压缩）可以利用更多的硬件资源。 在消费者方面，Kafka总是将一个分区的数据提供给一个消费者线程。 因此，消费者（在消费者组内）的并行度受所消耗的分区的数量的限制。 因此，一般来说，Kafka集群中的分区越多，吞吐量就越高。

用于选择分区数量的粗略公式基于吞吐量。 你衡量整个，你可以在生产单个分区（称之为P）和消费实现（称为C）。 比方说，你的目标吞吐量吨 。 然后，你需要至少有MAX（T / P，T / C）分区。 人们可以在生产者上实现的每分区吞吐量取决于诸如批处理大小，压缩编解码器，确认类型，复制因子等等的配置。然而，一般来说，可以在10秒的MB /如在此所示单个分区的基准 。 消费者吞吐量通常是与应用相关的，因为它对应于消费者逻辑可以如何快速地处理每个消息。 所以，你真的需要测量它。

虽然可以随着时间增加分区的数量，但是如果使用密钥生成消息，则必须小心。 当发布带密钥的消息时，Kafka基于密钥的散列将消息确定性地映射到分区。 这提供了保证具有相同密钥的消息总是路由到同一分区。 此保证对于某些应用可能是重要的，因为分区内的消息总是按顺序递送给消费者。 如果分区的数量改变，则这样的保证可能不再保持。 为了避免这种情况，一种常见的做法是过度分区。 基本上，您可以根据未来的目标吞吐量确定分区数，比如一两年后。 最初，您可以根据您的当前吞吐量只有一个小的Kafka集群。 随着时间的推移，您可以向集群添加更多代理，并按比例将现有分区的一部分移动到新代理（可以在线完成）。 这样，当使用密钥时，您可以跟上吞吐量增长，而不会破坏应用程序中的语义。

除了吞吐量，还有一些其他因素，在选择分区数时值得考虑。 正如你将看到的，在某些情况下，分区太多也可能产生负面影响。
 

更多分区需要打开更多的文件句柄

每个分区映射到broker中文件系统中的目录。 在该日志目录中，每个日志段将有两个文件（一个用于索引，另一个用于实际数据）。 目前，在Kafka中，每个broker打开每个日志段的索引和数据文件的文件句柄。 因此，分区越多，底层操作系统中需要配置打开文件句柄限制的分区越多。 这大多只是一个配置问题。 我们已经看到生产Kafka集群中，运行的每个broker打开的文件句柄数超过30000。
 

更多分区可能是不可用性增加

Kafka支持群集内复制 ，它提供更高的可用性和耐用性。 分区可以有多个副本，每个副本存储在不同的代理上。 其中一个副本被指定为领导者，其余的副本是追随者。 在内部，Kafka自动管理所有这些副本，并确保它们保持同步。 生产者和消费者对分区的请求都在领导副本上提供。 当代理失败时，该代理上具有leader的分区变得暂时不可用。 Kafka将自动将那些不可用分区的领导者移动到其他一些副本以继续服务客户端请求。 这个过程由指定为控制器的Kafka代理之一完成。 它涉及在ZooKeeper中为每个受影响的分区读取和写入一些元数据。 目前，ZooKeeper的操作是在控制器中串行完成的。

在通常情况下，当代理被干净地关闭时，控制器将主动地将领导者一次一个地关闭关闭代理。 单个领导者的移动只需要几毫秒。 因此，从客户的角度来看，在干净的代理关闭期间只有一小窗口的不可用性。

然而，当代理不干净地关闭（例如，kill -9）时，所观察到的不可用性可能与分区的数量成比例。 假设代理具有总共2000个分区，每个具有2个副本。 大致来说，这个代理将是大约1000个分区的领导者。 当这个代理不干净失败时，所有这1000个分区完全不能同时使用。 假设为单个分区选择新的领导需要5毫秒。 对于所有1000个分区，选择新的领导将需要5秒钟。 因此，对于一些分区，它们的观察到的不可用性可以是5秒加上检测故障所花费的时间。

如果一个是不幸的，失败的代理可能是控制器。 在这种情况下，选举新领导者的过程将不会开始，直到控制器故障转移到新的代理。 控制器故障转移自动发生，但需要新控制器在初始化期间从ZooKeeper读取每个分区的一些元数据。 例如，如果Kafka集群中有10,000个分区，并且从ZooKeeper初始化元数据每个分区需要2ms，则可以向不可用性窗口添加20多秒。

一般来说，不洁的故障是罕见的。 但是，如果在这种极少数情况下关心可用性，则可能最好将每个代理的分区数限制为两个到四千个，集群中的分区总数限制到几万个。
 

更多分区可能会增加端到端延迟

Kafka中的端到端延迟由从生产者发布消息到消费者读取消息的时间来定义。 Kafka仅在提交后向消费者公开消息，即，当消息被复制到所有同步副本时。 因此，提交消息的时间可以是端到端等待时间的显着部分。 默认情况下，对于在两个代理之间共享副本的所有分区，Kafka代理仅使用单个线程从另一个代理复制数据。 我们的实验表明，将1000个分区从一个代理复制到另一个代理可以添加大约20毫秒的延迟，这意味着端到端延迟至少为20毫秒。 这对于一些实时应用来说可能太高。

请注意，此问题在较大的群集上减轻。 例如，假设代理上有1000个分区引导，并且在同一个Kafka集群中有10个其他代理。 剩余的10个代理中的每个仅需要从第一代理平均获取100个分区。 因此，由于提交消息而增加的延迟将仅为几毫秒，而不是几十毫秒。

作为一个经验法则，如果你关心的延迟，它可能是一个好主意，每个经纪人的分区数量限制为100 * b * r，其中b是经纪人在kafka集群的数量和r是复制因子。
 

更多分区可能需要更多的内存在客户端

在最新的0.8.2版本，我们汇合到我们平台1.0，我们已经开发出一种更有效的Java生产商。 新生产者的一个好的功能是它允许用户设置用于缓冲传入消息的内存量的上限。 在内部，生产者缓冲每个分区的消息。 在累积了足够的数据或已经过去足够的时间之后，累积的消息从缓冲器中移除并发送到代理。

如果增加分区的数量，消息将在生产者中的更多分区中累积。 所使用的内存总量现在可能超过配置的内存限制。 当这种情况发生时，生产者必须阻止或丢弃任何新的消息，这两者都不是理想的。 为了防止这种情况发生，需要重新配置具有较大内存大小的生产者。

作为经验法则，为了实现良好的吞吐量，应该在生成器中分配至少几十KB的每个分区，并且如果分区的数量显着增加，则调整存储器的总量。

消费者也存在类似的问题。 消费者每个分区获取一批消息。 消费者消耗的分区越多，需要的内存就越多。 然而，这通常只是不是实时的消费者的问题。
 

总结

通常，Kafka集群中的更多分区导致更高的吞吐量。 然而，人们不得不意识到在总体上或每个代理中具有过多分区对可用性和等待时间的潜在影响。 在未来，我们计划改进一些限制，使Kafka在分区数方面更具可扩展性。
 

翻译原文：https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/  
作者：饶俊