集群配置文件統一

『壹』 配置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命令只需要給出集群中任意一個節點地址就可以完成整個集群的檢查工作，命令如下：