『壹』 配置Elasticsearch
Elasticsearch船只具有良好的默认值，并且只需要很少的配置。可以在运行的集群上使用集群更新设置API更改大多数设置。 配置文件应该包含特定于节点的设置(例如node.name和路径)，或者节点为了能够加入集群而需要的设置，例如 cluster.name 和 network.host 。
Elasticsearch有三个配置文件:
这些文件位于config目录中，其默认位置取决于安装是来自存档分发版(tar.gz或zip)还是包分发版(Debian或RPM包)。 对于存档发行版，config目录位置默认为 $ES_HOME/config 。配置目录的位置可以通过 ES_PATH_CONF 环境变量改变，如下所示:
或者，您可以通过命令行或shell配置文件导出ES_PATH_CONF环境变量。
对于包分发，配置目录位置默认为 /etc/elasticsearch 。配置目录的位置也可以通过 ES_PATH_CONF 环境变量更改，但是请注意，仅在shell中设置是不够的。相反，这个变量来源于 /etc/default/elasticsearch (用于Debian包)和 /etc/sysconfig/elasticsearch (用于RPM包)。您需要相应地在其中一个文件中编辑 ES_PATH_CONF=/etc/elasticsearch 条目，以更改配置目录的位置。
配置格式为YAML。下面是更改数据和日志目录路径的示例:
设置也可以扁平化如下:
在YAML中，你可以将非标量值格式化为序列:
虽然不太常见，但你也可以将非标量值格式化为数组:
使用${…}符号将被替换为环境变量的值。例如:
环境变量的值必须是简单字符串。使用逗号分隔的字符串来提供Elasticsearch将解析为列表的值。例如，Elasticsearch将以下字符串分割为 ${HOSTNAME} 环境变量的值列表
集群和节点设置可以根据配置方式进行分类:
您可以使用 集群更新设置API 在运行的集群上配置和更新动态设置。您还可以使用 elasticsearch.yml 在未启动或关闭的节点上本地配置动态设置。
使用集群更新设置API进行的更新可以是持久的(跨集群重启应用)，也可以是短暂的(在集群重启后重置)。您还可以通过使用API为临时或持久设置赋值为空来重置它们。
如果您使用多个方法配置相同的设置，Elasticsearch将按照以下优先顺序应用这些设置:
例如，您可以应用瞬变设置来覆盖持久设置或 elasticsearch.yml 设置。然而，对 elasticsearch.yml 的更改,不会覆盖已定义的瞬态或持久设置。
最好使用集群更新设置API设置动态的集群范围设置，并使用 elasticsearch.yml 仅用于本地配置。使用集群更新设置API可以确保所有节点上的设置是相同的。如果您不小心在 elasticsearch.yml 中配置了不同的设置。在不同的节点上，很难注意到差异。
静态设置只能在未启动或关闭的节点上使用 elasticsearch.yml 进行配置。
必须在集群中的每个相关节点上设置静态设置
Elasticsearch开始时只需要很少的配置，但是在生产环境中使用集群之前，有很多方面需要考虑:
Elasticsearch将创建索引的数据写入索引，将数据流写入数据目录。Elasticsearch将自己的应用程序日志(其中包含关于集群运行状况和操作的信息)写入日志目录
对于macOS .tar.gz、Linux .tar.gz和Windows .zip安装，数据和日志默认是 $ES_HOME 的子目录。但是，在升级过程中， $ES_HOME 中的文件有被删除的风险
In proction, we strongly recommend you set the path.data and path.logs in elasticsearch.yml to locations outside of $ES_HOME . Docker , Debian , RPM , macOS Homebrew , and Windows .msi installations write data and log to locations outside of $ES_HOME by default.
To avoid errors, only Elasticsearch should open files in the path.data directory. Exclude the path.data directory from other services that may open and lock its files, such as antivirus or backup programs.
Supported path.data and path.logs values vary by platform
只有当一个节点与集群中的所有其他节点共享 cluster.name 时，该节点才能加入集群。默认名称是 elasticsearch ，但是您应该将其更改为描述集群用途的适当名称。
不要在不同的环境中重用相同的集群名称。否则，节点可能会加入错误的集群
Elasticsearch使用 node.name 作为Elasticsearch特定实例的人类可读标识符。这个名称包含在许多api的响应中。当Elasticsearch启动时，节点名默认为机器的主机名，但是可以在 elasticsearch.yml 中显式配置
缺省情况下，Elasticsearch只绑定到 127.0.0.1 和 [::1] 等环回地址。这对于在单个服务器上运行一个或多个节点的集群进行开发和测试已经足够了，但是 弹性生产集群 必须包含其他服务器上的节点。有许多 网络设置 ，但通常你只需要配置 network.host :
当你为 network.host 提供值时。Elasticsearch假定您正在从开发模式转向生产模式，并将一些系统启动检查从警告升级到异常。看看 开发和生产模式 之间的区别。
在投入生产之前，配置两个重要的发现和集群形成设置，以便集群中的节点能够相互发现并选择一个主节点。
Elasticsearch可以开箱即用，无需任何网络配置，它将绑定到可用的环回地址，并扫描本地端口 9300 到 9305 ，以便与运行在同一服务器上的其他节点连接。这种行为提供了一种无需进行任何配置的自动集群体验。
当您希望与其他主机上的节点形成集群时，使用 静态 discovery.seed_hosts 设置. This setting provides a list of other nodes in the cluster that are master-eligible and likely to be live and contactable to seed the discovery process . 此设置接受集群中所有符合主节点的地址的YAML序列或数组。每个地址可以是一个IP地址，也可以是通过DNS解析为一个或多个IP地址的主机名。
当您第一次启动Elasticsearch集群时， 集群引导 步骤将确定在第一次选举中计票的符合主资格的节点集。在 开发模式 下，如果没有配置发现设置，这个步骤将由节点自己自动执行。
因为自动引导 本身就不安全 ,，所以在生产模式下启动新集群时，必须显式列出符合主资格的节点，这些节点的投票应该在第一次选举中计算。您可以使用集群设置此列表。 initial_master_nodes 设置。
在集群第一次成功形成之后，删除每个节点配置中的 Initial_master_nodes 设置。在重新启动集群或向现有集群添加新节点时，不要使用此设置。
通过节点的 node.name 标识初始主节点, 该节点默认为主节点的主机名。请确保 cluster.initial_master_nodes 值 与 node.name 完全匹配如果您使用完全限定的域名(FQDN)，例如master-node-a.example.com作为您的节点名，那么您必须在此列表中使用FQDN。相反，如果node.name是没有任何尾随限定符的裸主机名，您也必须省cluster.initial_master_nodes中的尾随限定符如果您使用完全限定的域名(FQDN)，例如 master-node-a.example.com 作为您的节点名, 那么您必须在此列表中使用FQDN。相反，如果f node.name 是没有任何尾随限定符的裸主机名，您也必须省略 cluster.initial_master_nodes 中的尾随限定符。
请参见 bootstrapping a cluster 以及 发现和集群形成设置 .
默认情况下，Elasticsearch会根据节点的 角色 和总内存自动设置JVM堆大小。对于大多数生产环境，我们建议使用默认大小。
自动堆大小需要 bundled JDK ，如果使用自定义JRE位置，则需要Java 14或更高版本的JRE。
如果需要，您可以通过手动 设置JVM堆大小 来覆盖默认大小
默认情况下，Elasticsearch将JVM配置为将堆内存溢出异常转储到默认数据目录。在RPM和Debian软件包中，数据目录是/var/lib/elasticsearch。在Linux、MacOS和Windows发行版上，数据目录位于Elasticsearch安装的根目录下。
如果此路径不适合接收堆转储，请修改 -XX:HeapDumpPath=… jvm.options
默认情况下，Elasticsearch启用垃圾收集(GC)日志。这些是在jvm中配置的 jvm.options 并输出到与Elasticsearch日志相同的默认位置。默认配置每64mb轮换一次日志，最多可以消耗2gb的磁盘空间。
您可以使用 JEP 158: Unified JVM Logging 中描述的命令行选项重新配置JVM日志。除非您更改了默认jvm。选项文件，Elasticsearch默认配置将应用于您自己的设置之外。要禁用默认配置，首先通过提供 -Xlog:disable 选项禁用日志记录，然后提供您自己的命令行选项。这将禁用所有JVM日志记录，因此一定要检查可用选项并启用所需的所有内容。
要查看原始JEP中未包含的其他选项，请参见使用 JVM统一日志框架启用日志记录 .
Change the default GC log output location to /opt/my-app/gc.log by creating $ES_HOME/config/jvm.options.d/gc.options with some sample options:
Configure an Elasticsearch Docker container to send GC debug logs to standard error ( stderr ). This lets the container orchestrator handle the output. If using the ES_JAVA_OPTS environment variable, specify:
默认情况下，Elasticsearch使用启动脚本直接在系统临时目录下创建的私有临时目录。
在某些Linux发行版上，如果最近没有访问过/tmp中的文件和目录，系统实用程序将清除它们。如果需要临时目录的特性长时间不使用，那么在Elasticsearch运行时，这种行为会导致私有临时目录被删除。如果随后使用需要此目录的特性，则删除私有临时目录会导致问题。
如果您使用.deb或.rpm包安装Elasticsearch，并在systemd下运行它，那么Elasticsearch使用的私有临时目录将被排除在定期清理之外。
如果您打算在Linux或MacOS上长时间运行.tar.gz发行版，请考虑为Elasticsearch创建一个专用的临时目录，该目录不在将旧文件和目录清除的路径下。这个目录应该设置权限，以便只有作为Elasticsearch运行的用户才能访问它。然后，在启动Elasticsearch之前，设置$ES_TMPDIR环境变量指向这个目录。
默认情况下，Elasticsearch将JVM配置为将致命错误日志写入默认日志目录。对于 RPM 和 Debian 软件包, 这个目录是 /var/log/elasticsearch . On Linux and MacOS and Windows 发行版, logs 目录位于Elasticsearch安装根目录下。
这些日志是JVM遇到致命错误(例如分段错误)时产生的。如果此路径不适合接收日志，请修改 -XX:ErrorFile=… 在 jvm.options 条目。
在灾难中，快照可以防止数据永久丢失。快照生命周期管理是对集群进行定期备份的最简单方法。有关更多信息，请参见备份集群。
在灾难中, 快照 可以防止数据永久丢失. 快照生命周期管理 是对集群进行定期备份的最简单方法. 有关更多信息, 请参见 备份集群 。
备份集群的唯一可靠和受支持的方法是使用快照。您不能通过复制Elasticsearch集群节点的数据目录来备份该集群。不支持从文件系统级备份恢复任何数据的方法。如果试图从这样的备份恢复集群，可能会出现损坏、丢失文件或其他数据不一致的报告，或者看起来已经成功地悄无声息地丢失了一些数据。
有些设置是敏感的，仅依靠文件系统权限来保护它们的值是不够的。对于这个用例，Elasticsearch提供了一个密钥存储库和 elasticsearch -keystore 工具 来管理密钥存储库中的设置。
只有重新启动Elasticsearch后，对keystore的所有修改才会生效。
这些设置就像elasticsearch中的常规设置一样。Yml配置文件，需要在集群中的每个节点上指定。目前，所有安全设置都是特定于节点的设置，在每个节点上必须具有相同的值。
Just like the settings values in elasticsearch.yml , 对密钥存储库内容的更改不会自动应用到运行的Elasticsearch节点。重新读取设置需要重新启动节点。但是，某些安全设置被标记为 可重新加载 。. Such settings can be re-read and applied on a running node .
所有安全设置的值(无论是否可重新加载)必须在所有集群节点上相同。在进行所需的安全设置更改后，使用 bin/elasticsearch-keystore add 命令, call:
keystore-password : 用于加密Elasticsearch密钥库的密码
此API在每个集群节点上解密并重新读取整个密钥存储库，但只应用可重新加载的安全设置。对其他设置的更改直到下次重启才会生效。一旦调用返回，重新加载就完成了，这意味着依赖于这些设置的所有内部数据结构都已更改。所有的设置都应该从一开始就具有新值。
当更改多个可重新加载的安全设置时，在每个集群节点上修改所有安全设置，然后发出 reload_secure_settings 调用，而不是在每次修改后重新加载。
有可重新加载的安全设置:
『贰』 使用 kubectl 管理 kubeconfig 配置文件
Kubernetes 集群在服务器搭建部署成功之后，通常我们都会通过 kubectl 命令行工具与集群互动、发送操作指令来管理集群。 kubectl 主要依赖于集群配置文件 kubeconfig 与集群进行通讯，这个文件通常在 Kubernetes 集群的 master 节点服务器的 $HOME/.kube/config 目录下。开发者可以从服务器获取改配置文件到开发者本地电脑上的相同目录位置上即可。 本篇文章主要介绍一下我们如何管理这个配置文件。如果熟悉 kubeconfig 文件的结构，读者当然可以使用文本编辑器自行修改，不过手工修改难免会有错误和不便。所以这里介绍一下如何利用 kubectl 工具来帮助我们管理和调整配置文件。 kubeconfig 是一个 Kubernetes 中的一个资源对象，叫做 Config , 内容格式是 YAML 。这个文件中主要包含了集群（clusters）、上下文（contexts）和用户（users）信息，他们的层次结构和关系如下图所示： 如图所示，上下文 context 是建立集群、用户和命名空间之间关系的桥梁和纽带，我们在本地切换所谓的“环境”其实就是将一个指定的上下文为当前激活的上下文（current-context）。再通俗点讲，这个上下文指的就是你当前是以什么身份（user) 在连接哪个集群（cluster），连接后自动切换到哪一个命名空间（namespace）下。 kubectl 中的 config 子命令可以帮助我们维护存储在本地的配置文件，我们先来看下它的帮助说明： 这里简要说明一下config下几个主要的子命令： 接下来我们列举一些常见的任务场景。 首先我们使用以下命令来看下集群 kubernetes 的 server 属性的值： 接下来我们是用 set-cluster 子命令来修改服务器的地址： kubectl config 未直接提供的删除用户的子命令，所以我们找不到类似于 delete-user 之类的选项。不过我们可以使用 unset 子命令来完成这个任务： 建议大家使用 kubectl config 的方式来配置 kubeconfig 文件，避免了手工修改的麻烦和误配置之外，对于自动化管理也可以更加规范和统一。
『叁』 搭建hadoop集群，常用配置文件是什么，以及配置哪些属性
一. 简介
参考了网上许多教程，最终把hadoop在ubuntu14.04中安装配置成功。下面就把详细的安装步骤叙述一下。我所使用的环境：两台ubuntu 14.04 64位的台式机，hadoop选择2.7.1版本。（前边主要介绍单机版的配置，集群版是在单机版的基础上，主要是配置文件有所不同，后边会有详细说明）
二. 准备工作
2.1 创建用户
创建用户，并为其添加root权限，经过亲自验证下面这种方法比较好。
1 sudo adser hadoop2 sudo vim /etc/sudoers3 # 修改内容如下：4 root ALL = (ALL)ALL5 hadoop ALL = (ALL)ALL
给hadoop用户创建目录，并添加到sudo用户组中，命令如下：
1 sudo chown hadoop /home/hadoop2 # 添加到sudo用户组3 sudo adser hadoop sudo
最后注销当前用户，使用新创建的hadoop用户登陆。
2.2安装ssh服务
ubuntu中默认是没有装ssh server的（只有ssh client），所以先运行以下命令安装openssh-server。安装过程轻松加愉快～
sudo apt-get install ssh openssh-server
2.3 配置ssh无密码登陆
直接上代码：执行完下边的代码就可以直接登陆了（可以运行ssh localhost进行验证）
1 cd ~/.ssh# 如果找不到这个文件夹，先执行一下 "ssh localhost"2 ssh-keygen -t rsa3 cp id_rsa.pub authorized_keys
注意：
这里实现的是无密登陆自己，只适用与hadoop单机环境。如果配置Hadoop集群设置Master与Slave的SSH无密登陆可
三. 安装过程
3.1 下载hadoop安装包
有两种下载方式：
1. 直接去官网下载：
2. 使用wget命令下载：
3.2 配置hadoop
1. 解压下载的hadoop安装包，并修改配置文件。我的解压目录是（/home/hadoop/hadoop-2.7.1），即进入/home/hadoop/文件夹下执行下面的解压缩命令。
tar -zxvf hadoop-2.7.1.tar.gz
2. 修改配置文件：（hadoop2.7.1/etc/hadoop/）目录下，hadoop-env.sh，core-site.xml，mapred-site.xml.template，hdfs-site.xml。
(1). core-site.xml 配置：其中的hadoop.tmp.dir的路径可以根据自己的习惯进行设置。
至此，wordcount demo 运行结束。
六. 总结
配置过程遇到了很多问题，最后都一一解决，收获很多，特此把这次配置的经验分享出来，方便想要配置hadoop环境的各位朋友～
（Hadoop集群安装配置过程基本和单机版是一样的，主要是在配置文件方面有所区别，以及ssh无密登陆要求master和slave能够互相无密登陆。
『肆』 六、rancher搭建rabbitmq集群化部署
一．Rabbitmq在rancher上面部署 Prod： 这里要做3个rabbitmq，取名分别prod，master，slave Master和slave基本配置一样，就是映射时候记得改一下映射文件名字就行下面是 master： 二．Rabbitmq在rancher添加服务如图： Slave: 三．Rabbitmq的配置命令如图： 如果执行失败说明你没给容器设置容器名字 如果成功如图日志会打印： 四：Rabbitmq整合对外端口外加测试是否成功 到这里启动会报错说找不到配置为文件 现在我们要配置这个统一管理配置文件，记得改成你自己的服务名字：
『伍』 Ceph 集群 scrub 设置策略(数据一致性校验)
基本概念 1、什么是 Scrub Scrub是 Ceph 集群副本进行数据扫描的操作，用于检测副本间数据的一致性，包括 scrub 和 deep-scrub。其中scrub 只对元数据信息进行扫描，相对比较快；而deep-scrub 不仅对元数据进行扫描，还会对存储的数据进行扫描，相对比较慢。 2、Scrub默认执行周期 OSD 的scrub 默认策略是每天到每周（如果集群负载大周期就是一周，如果集群负载小周期就是一天）进行一次，时间区域默认为全体（0时-24时），deep-scrub默认策略是每周一次。 配置scrub策略 为了避开客户业务高峰时段，建议在晚上0点到第二天早上5点之间，执行scrub 操作。 1、设置标识位 在任一monitor节点进行如下操作: 2、临时配置 先通过tell 方式，让scrub 时间区间配置立即生效，在任一monitor节点进行如下操作: 3、修改配置文件 为了保证集群服务重启或者节点重启依然有效，需要修改Ceph集群所有节点的配置文件 /etc/ceph/ceph.conf 添加以下区段配置： 注意: 该时间设置需要参考物理节点的时区设置 4、取消标识位 5、向 OSD {osd-num} 下达一个scrub命令. (用通配符 * 把命令下达到所有 OSD 。实测ceph 12.2.x版本不能加*) 6、设置 light scrub 周期 将osd_scrub_min_interval 和 osd_scrub_max_interval都设为4分钟,这里的单位是秒 7、通过命令手动启动scrub ： 8、尝试 pg repair 9、(Deep)Scrub的相关配置选项 同前端IO和Recovery一样，Ceph通过控制PGScrub来间接控制Scrub的所有IO优先级。
『陆』 Redis Cluster集群的搭建
搭建集群工作需要以下三个步骤： 1）准备节点。 2）节点握手。 3）分配槽。 Redis集群一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置cluster-enabled yes，让Redis运行在集群模式下。建议为集群内所有节点统一目录，一般划分三个目录：conf、data、log，分别存放配置、数据和日志相关文件。把6个节点配置统一放在conf目录下，集群相关配置如下： 其他配置和单机模式一致即可，配置文件命名规则redis-{port}.conf，准备好配置后启动所有节点。 Cluster集群启动过程如下图：每个节点目前只能识别出自己的节点信息，可以执行cluster nodes命令获取集群节点状 态。 节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户端发起命令：cluster meet{ip}{port} cluster meet命令是一个异步命令，执行之后立刻返回。内部发起与目标节点进行握手通信，握手通信过程： 1）节点6379本地创建6380节点信息对象，并发送meet消息。 2）节点6380接受到meet消息后，保存6379节点信息并回复pong消息。 3）之后节点6379和6380彼此定期通过ping/pong消息进行正常的节点通 信。 分别执行meet命令让其他节点加入到集群中， 最后执行cluster nodes命令确认6个节点都彼此感知并组成集群。 节点建立握手之后集群还不能正常工作，这时集群处于下线状态，所有的数据读写都被禁止，通过cluster info命令可以获取集群当前状态。 Redis集群把所有的数据映射到16384个槽中。每个key会映射为一个固定的槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过cluster addslots命令为节点分配槽。这里利用bash特性批量设置槽（slots），命令如下： 执行cluster info查看集群状态，如下所示： 当前集群状态是OK，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系： 集群模式下，Reids节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用cluster replicate{nodeId}命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行，nodeId是要复制主节点的节点ID，命令如下： Redis集群模式下的主从复制使用了之前介绍的Redis复制流程，依然支持全量和部分复制。复制（replication）完成后，整个集群的结构如图：集群搭建需要很多步骤当集群节点众多时，必然会加大搭建集群的复杂度和运维成本。因此Redis官方提供了redis-trib.rb工具方便我们快速搭建集群。 redis-trib.rb是采用Ruby实现的Redis集群管理工具。内部通过Cluster相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作，使用之前需要安装Ruby依赖环境。 1、安装Ruby： 2、安装rubygem redis依赖： 3、安装redis-trib.rb： 4、安装完Ruby环境后，执行redis-trib.rb命令确认环境是否正确，输出如 下： 首先我们跟之前内容一样准备好节点配置并启动： 启动好6个节点之后，使用redis-trib.rb create命令完成节点握手和槽分配过程，命令如下： –replicas参数指定集群中每个主节点配备几个从节点，这里设置为1。 如果部署节点使用不同的IP地址，redis-trib.rb会尽可能保证主从节点不分配在同一机器下，因此会重新排序节点列表顺序。节点列表顺序用于确定主从角色，先主节点之后是从节点。创建过程中首先会给出主从节点角色分配的计划，当我们同意这份计划之后输入yes，redis-trib.rb开始执行节点握手和槽分配操作。 集群完整性指所有的槽都分配到存活的主节点上，只要16384个槽中有一个没有分配给节点则表示集群不完整。可以使用redis-trib.rb check命令检测之前创建的集群是否成功，check命令只需要给出集群中任意一个节点地址就可以完成整个集群的检查工作，命令如下：
