cdh看完官方文檔后小結002

1、Cloudera Manager包含內部機架感知腳本，但您必須指定群集中主機所在的機架。如果您的群集包含10個以上的主機，Cloudera建議您為每個主機指定機架。 HDFS，MapReduce和YARN將自動使用您指定的機架。
https://www.cloudera.com/documentation/enterprise/5-13-x/topics/cm_mc_specify_rack.html

2、cdh不同版本支持的操作系統 參考鏈接為
https://blog.csdn.net/high3011/article/details/78131668
https://www.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#concept_xdm_rgj_j1b

3、停用主機停用并停止主機上的所有角色，而無需單獨停用每個服務上的角色。 退役僅適用于HDFS DataNode，MapReduce TaskTracker，YARN NodeManager和HBase RegionServer角色。 如果主機上運行了其他角色，則會停止這些角色。在主機上的所有角色都已停用并停止后，可以從服務中刪除主機。 您可以并行停用多個主機。

4、如果DataNode的數量等于HDFS中存儲的任何文件的復制因子（默認值為3），則無法停用DataNode或具有DataNode的主機。例如，如果任何文件的復制因子為3，并且您有三個DataNode，則無法停用DataNode或具有DataNode的主機。如果在這種情況下嘗試停用DataNode或具有DataNode的主機，則DataNode將被停用，但停用過程將無法完成。您必須中止退役并重新啟動DataNode。
//這句話的意思就是 只有3臺datanode 但是你要停用一臺，但是復制因子是3 必須修改復制因子之后，才可以停用一臺datanode
注意：退出DataNode時，不會從存儲目錄中刪除數據塊。您必須手動刪除數據。

5、當一個DataNode退役時，NameNode確保來自DataNode的每個塊仍然可以在復制因子的指示下在整個群集中可用。 此過程涉及以小批量從DataNode復制塊。 如果DataNode有數千個塊，則退役可能需要幾個小時。 在使用DataNodes停用主機之前，您應首先調整HDFS：
(1、)運行以下命令以識別HDFS文件系統中的任何問題：
hdfs fsck / -list-corruptfileblocks -openforwrite -files -blocks -locations 2>&1 > /tmp/hdfs-fsck.txt
(2、)修復fsck命令報告的任何問題。 如果命令輸出列出了損壞的文件，請使用fsck命令將它們移動到lost + found目錄或刪除它們：
hdfs fsck file_name -move 或者 hdfs fsck file_name -delete
(3、)提高DataNodes的堆大小。 DataNodes應配置至少4 GB的堆大小，以允許迭代和最大流的增加。
????轉到HDFS服務頁面。
????單擊“配置”選項卡。
????選擇Scope> DataNode。
????選擇類別>資源管理。
????按建議設置“字節數”中的“數據堆大小”。
(4、)設置DataNode平衡帶寬：
???? 選擇Scope> DataNode。
???? 展開“類別”>“性能”類別。
???? 將DataNode Balancing Bandwidth屬性配置為磁盤和網絡上的帶寬。 您可以使用低于此值的值，以便最大限度地減少退役對群集的影響，但權衡是退役將需要更長時間。
???? 單擊“保存更改”以提交更改。
(5、)將每次迭代的復制工作乘數增加到更大的數字（默認值為2，但建議為10）：
???? 選擇Scope> NameNode。
???? 展開“類別”>“高級”類別。
???? 將“每次迭代復制工作乘數”屬性配置為值10，例如10。
???? 要根據需要將此配置屬性應用于其他角色組，請編輯相應角色組的值。 請參閱使用Cloudera Manager修改配置屬性。
???? 單擊“保存更改”以提交更改。
(6、)增加復制最大線程數和最大復制線程硬限制：
???? 選擇Scope> NameNode。
???? 展開“類別”>“高級”類別。
???? 將DataNode上的最大復制線程數和DataNode屬性上復制線程數的硬限制分別配置為50和100。 您可以減少線程數（或使用默認值）以最小化退役對群集的影響，但權衡是退役將花費更長時間。
???? 要根據需要將此配置屬性應用于其他角色組，請編輯相應角色組的值。 請參閱使用Cloudera Manager修改配置屬性。
???? 單擊“保存更改”以提交更改。
(7、)重啟HDFS服務。
有關其他調整建議，請參閱性能注意事項。
參考鏈接為 ： https://www.cloudera.com/documentation/enterprise/5-13-x/topics/cm_mc_decomm_host.html

6、在退役DataNode之前調整HBase
要提高滾動重新啟動HBase服務的速度，請將Region Mover Threads屬性設置為更高的值。這增加了可以并行移動的區域的數量，但是對HMaster施加了額外的壓力。在大多數情況下，Region Mover Threads應設置為5或更低。重新啟動主機
只有使用Cloudera Manager退役的主機才能重新啟動。

7、退役datanode
性能注意事項
（1）退出DataNode不會立即發生，因為該過程需要復制可能大量的塊。在淘汰期間，群集的性能可能會受到影響。
退役分兩步進行：
第一步：?DataNode的委員會狀態標記為退役，數據從此節點復制到其他可用節點。在復制所有塊之前，節點仍處于退役狀態。您可以從NameNode Web UI查看此狀態。 （轉到HDFS服務并選擇Web UI> NameNode Web UI。）當所有數據塊都復制到其他節點時，該節點將標記為“已停用”。
第二步：當所有數據塊都復制到其他節點時，該節點將標記為“已停用”。
退役可以通過以下方式影響性能：
A 其他活動DataNode上必須有足夠的磁盤空間才能復制數據。 在退役之后，剩余的活動DataNode具有更多塊，因此將來停用這些DataNode可能需要更多時間。
B 在復制數據塊時，將增加網絡流量和磁盤I / O.
C 數據平衡和數據位置可能會受到影響，這可能會導致任何正在運行或提交的作業的性能下降。
D 同時停用大量DataNode會降低性能。
E 如果要淘汰少數DataNode，那么從這些節點讀取數據的速度會限制退役的性能，因為當從DataNode讀取數據塊時，退役會最大化網絡帶寬，并將用于復制塊的帶寬擴展到其他DataNode中。 簇。 為避免群集中的性能影響，Cloudera建議您僅同時停用少數DataNode。
F 您可以減少可用于平衡DataNode的帶寬和復制線程的數量，以降低復制的性能影響，但這將導致退役過程需要更長時間才能完成。 請參閱在退役DataNode之前調整HDFS。

//Cloudera建議您以較小的組并行添加DataNode和停用DataNode。 例如，如果復制因子為3，則應添加兩個DataNode并同時停用兩個DataNode。

8、排除退役性能
退役DataNode時，以下條件也會影響性能：
（???? 打開文件
???? 無法重定位塊，因為沒有足夠的DataNode來滿足塊放置策略。）
打開文件
???? DataNode上的寫操作不涉及NameNode。 如果存在與位于DataNode上的打開文件關聯的塊，則在文件關閉之前不會重定位它們。 這通常發生在：
???????? 使用HBase的集群
???????? 打開Flume文件
???????? 長期運行的任務

???? 要查找和關閉打開的文件：分為一下5步
第一步：
登錄NameNode主機，切換到日志目錄。
可以使用NameNode日志目錄屬性配置此目錄的位置。 默認情況下，此目錄位于：/var/log/hadoop-hdfs/
第二步：
運行以下命令以驗證日志是否提供了所需的信息：
grep "Is current datanode" NAME | head
日志文件的第六列顯示塊ID，該消息應與DataNode退役相關。 執行以下命令，查看相關日志條目：
grep "Is current datanode" NAME | awk '{print $6}' | sort -u > blocks.open
第三步：
運行以下命令以返回打開文件，其塊以及這些塊的位置列表：
hadoop fsck / -files -blocks -locations -openforwrite 2>&1 > openfiles.out
第四步：
查看由命令為顯示blocks.open的塊創建的openfiles.out文件。 還要驗證DataNode IP地址是否正確。
第五步：
使用打開的文件列表，執行相應的操作以重新啟動進程以關閉文件。
例如，主要壓縮會關閉HBase區域中的所有文件。

無法重定位塊，因為沒有足夠的DataNode來滿足塊放置策略。
???? 例如對于10節點集群，如果在嘗試取消配置一個DataNode時將mapred.submit.replication設置為默認值10，則重新定位與map / reduce作業關聯的塊將會很困難。 此條件將導致NameNode日志中的錯誤類似于以下內容：
org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicyDefault: Not able to place enough replicas, still in need of 3 to reach 3
使用以下步驟查找塊復制策略等于或高于當前群集大小的文件數：
第一步
通過運行以下命令提供打開文件，其塊以及這些塊的位置的列表：
???? hadoop fsck / -files -blocks -locations -openforwrite 2>＆1> openfiles.out
第二步：
運行以下命令以返回具有給定復制因子的文件的列表：
???? grep repl= openfiles.out | awk '{print $NF}' | sort | uniq -c
???? 例如，當復制因子為10時，退役一個：
???? egrep -B4 "repl=10" openfiles.out | grep -v '<dir>' | awk '/^\//{print $1}'
第三步
???? 檢查路徑，并決定是減少文件的復制因子，還是從群集中刪除它們。

9、刪除主機2種方式
1、?完全從Cloudera Manager中刪除主機。
2、 從群集中刪除主機，但將其保留給Cloudera Manager管理的其他群集
這兩種方法都會停用主機，刪除角色和刪除托管服務軟件，但會保留數據目錄。

10、
維護模式允許您禁止主機，服務，角色或整個群集的警報。 當您需要在群集中執行操作（進行配置更改并重新啟動各種元素）并且不希望看到由于這些操作而生成的警報時，這非常有用。
將實體置于維護模式不會阻止記錄事件; 它只會抑制那些事件會產生的警報。 您可以查看在這些實體處于維護模式期間為實體記錄的所有事件的歷史記錄。

參考鏈接：