EMR Kafka磁碟寫滿營運 - E-MapReduce

本文以EMR Kafka 2.4.1版本為例，介紹Kafka磁碟寫滿時的營運操作。

業務情境

Kafka將日誌資料存放區到磁碟中，當磁碟寫滿時，相應磁碟上的Kafka日誌目錄會出現offline問題。此時，該磁碟上的分區副本不可讀寫，降低了分區的可用性與容錯能力，同時由於leader遷移到其他Broker，增加了其他Broker的負載。因此，當磁碟出現寫滿情況時，應及時處理。

磁碟寫滿營運概述

本文從磁碟寫滿監控和磁碟寫滿恢複角度來介紹磁碟寫滿營運策略。

磁碟寫滿監控

Kafka服務層面：可以在CloudMonitor系統中設定EMR Kafka叢集的OfflineLogDirectoryCount指標警示，及時發現日誌目錄offline的情況。

磁碟寫滿恢複

從排查問題角度來看，當Kafka出現log directory offline時，需要儘快定位是否是由於日誌目錄所在磁碟寫滿導致的。

當日誌目錄磁碟空間被寫滿時，您可以考慮如下營運策略：

磁碟擴容：通過擴容雲端硬碟的方式來增加磁碟容量，適用於Broker掛載雲端硬碟的情境，詳情請參見磁碟擴容方式恢複。
節點內分區遷移：將寫滿磁碟中的分區遷移到本節點的其他磁碟,適用於本Broker節點內磁碟使用率不均衡的情境，詳情請參見節點內分區遷移方式恢複。
資料清理：清理寫滿磁碟的日誌資料，適用於舊資料可以刪除的情境，詳情請參見資料清理方式恢複。

磁碟擴容方式恢複

方案描述

磁碟擴容方式是指當Broker磁碟空間被寫滿時，通過擴容磁碟儲存的方式來滿足磁碟需求。其優點在於操作簡單、風險小、能夠快速解決磁碟空間不足的問題。

適用情境

適用於Broker掛載雲端硬碟的情境。

操作步驟

在EMR控制台擴容Broker節點的資料盤，詳情請參見擴容磁碟。

節點內分區遷移方式恢複

方案描述

當Broker磁碟容量被寫滿時，對應的log directory被offline，無法使用kafka-reassign-partitions.sh工具遷移分區。此時，可以通過ECS執行個體層面的操作，將分區副本資料挪到當前Broker的其他磁碟並修改相應Kafka資料目錄中繼資料的方式來解決故障盤空間不足的問題。

適用情境

故障磁碟所在Broker使用容量不均衡、存在空間使用率較低的磁碟。

注意事項

該方法只能進行節點內部磁碟遷移。
分區遷移有可能導致磁碟的IO熱點，進而影響叢集的效能。需要評估每次遷移資料的大小、遷移時間長度對業務的影響程度。
由於該方法是非標操作，請在相應的Kafka版本測試後再用於生產叢集。

操作步驟

當磁碟寫滿時，由於log directory已經offline了，所以不能用kafka-reassign-partitions.sh工具進行分區遷移。本文通過非標方式直接移動檔案、修改Kafka相關中繼資料的方式來遷移分區。

建立測試Topic。

以SSH方式登入到源Kafka叢集的Master節點，詳情請參見登入叢集。

執行以下命令，建立測試Topic，分區副本分布在Broker 0，1節點。

kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --replica-assignment 0:1 --create

您可以通過以下命令查看Topic詳情。

kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe

返回如下資訊，此時Broker 0是在Isr列表中的。

Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 0       Replicas: 0,1   Isr: 0,1

執行以下命令，類比資料寫入。

kafka-producer-perf-test.sh --topic test-topic --record-size 1000 --num-records 600000000 --print-metrics --throughput 10240 --producer-props linger.ms=0 bootstrap.servers=core-1-1:9092

修改Broker 0分區對應的日誌目錄許可權。
1. 在Master節點上切換到emr-user帳號。
```
su emr-user
```
2. 免密碼登入到對應的Core節點。
```
ssh core-1-1
```
3. 通過sudo獲得root許可權。
```
sudo su - root
```
4. 執行以下命令，尋找分區所在磁碟。
```
sudo find / -name test-topic-0
```
  返回資訊如下，則表示分區在/mnt/disk4/kafka/log目錄下。
```
/mnt/disk4/kafka/log/test-topic-0
```
5. 執行以下命令，將Broker 0分區對應的日誌目錄使用權限設定成000。
```
sudo chmod 000 /mnt/disk4/kafka/log
```
6. 執行以下命令，查看test-topic的狀態。
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
  返回資訊如下，可以看到Broker 0已經不在Isr列表中了。
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 1       Replicas: 0,1   Isr: 1
```
停止Broker 0節點。
在EMR控制台停止Broker 0的Kafka服務。
執行以下命令，將Broker 0的test-topic的分區移動到本節點的其他磁碟。
```
mv /mnt/disk4/kafka/log/test-topic-0 /mnt/disk1/kafka/log/
```
修改檔案。
根據來源目錄/mnt/disk4/kafka/log和目標目錄/mnt/disk1/kafka/log的中繼資料檔案。需要修改的檔案包括replication-offset-checkpoint和recovery-point-offset-checkpoint。
- 修改replication-offset-checkpoint檔案，將test-topic相關的條目從原日誌目錄下的replication-offset-checkpoint檔案挪到目標日誌目錄的replication-offset-checkpoint中，並修改該檔案條目的數量。
- 修改recovery-point-offset-checkpoint檔案，將test-topic相關的條目從原日誌目錄下的recovery-point-offset-checkpoint檔案挪到目標日誌目錄的recovery-point-offset-checkpoint中，並修改該檔案條目的數量。
執行以下命令，將源broker 0的日誌目錄使用權限設定成正確的許可權。
```
sudo chmod 755 /mnt/disk4/kafka/log
```
啟動Broker 0節點。
在EMR控制台啟動Broker 0的Kafka服務。

執行以下命令，觀察叢集的狀態是正常的。

kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe

資料清理方式恢複

方案描述

資料清理是指當磁碟被寫滿時，將業務日誌資料（非Kafka內部Topic資料）按照從舊到新的方式刪除，直到釋放出足夠的空間。

適用情境

寫滿磁碟存在允許刪除的業務資料。

如果不改變資料的儲存時間長度，資料有可能又被快速的寫滿。因此，通常適用於因特殊情況而導致的資料突增的情境。

注意事項

不能刪除Kafka內部的Topic資料，即不能刪除以底線（_）開頭命名的Topic。

操作步驟

登入到相應的機器上。
找到寫滿的磁碟，刪除掉不需要的業務資料。
資料清理原則：
- 不可直接刪除Kafka的資料目錄，避免造成不必要的資料丟失。
- 找到佔用空間較多或者明確不需要的Topic，選擇其中某些Partition，從最早的日誌資料開始刪除。刪除segment及相應地index和timeindex檔案。不要清理內建的Topic，例如__consumer_offsets和_schema等。
重啟磁碟被寫滿的相應的Broker節點，使日誌目錄online。