2020. 6. 9. 15:11ㆍNifi
나이파이에서 가장 중요한 것은 뭐니뭐니해도 DISK 관리이다. 중요한 이유는 성능 때문이다.
아무래도 FlowFileRepository, Provenance Repository, ContentRepository의 경우 각 각 Disk I/O 발생량이 많은데 세 Repository를 하나에 묶으면 그만큼 성능 저하가 일어나기에 무조건적으로 분산하여 각 각 마운트를 가져가야하며 특히 FlowFileRepository, ContentRepository의 경우 Raid를 권장합니다.
Disk Recommand 환경
1. Recommand 환경
디스크 구성은 5 + N개(ContentRepository) Recommand
1. Logs, Nifi 설치파일 용도, Cloudera log 용도 등을 위한 Root 영역 디스크 혹은 별도 디스크 (최소 1T)
2. Flowfile , database repository 전용 별도 디스크 (500G)
3. Content Repository 전용 별도 디스크 (최소 1T)
4. Provenance Repository 전용 별도 디스크 (최소 1T)
5. Zookeeper 전용 별도 디스크 최소 (최소 500G)
6. 여기에 시나리오 Flowfile의 사이즈에 따라 N개의 Content Repository 디스크를 붙인다.
## 사정에 따라 위와 같은 환경구성이 어려운경우 최소 디스크 장수는 3장 FlowFile Repo, ContentRepo, ProvenanceRepo + zookeeper + log 이렇게 3장 구성이 좋다
2.Repository 역할
FlowFile Repository : Flowfile에 대한 메타정보가 저장되는공간
Content Repository : 실제 데이터가 저장되는 공간
Procenance Repository : FlowFile들에 대한 Lineage 정보가 저장되는 공간
Database Repository : nifi-user-keys.h2.db, nifi-flow-audit.h2.db으로 구성
nifi-user-keys.h2.db, NiFi에 로그인 한 사람에 대한 정보가 포함 된 경우에만 사용됩니다. 여기에 동일한 정보가 nifi-user.log에도 출력됩니다
nifi-flow-audit.h2.db: NiFi에서 사용되는 모든 구성 변경 사항을 추적하기 위해 NiFi에서 사용합니다. 이 DB에 포함 된 정보는 NiFi UI의 오른쪽 상단 모서리 햄버거 메뉴에있는 "Flow Configuration History"내장 UI를 통해 볼 수 있습니다.
#Repository 별 Full일 경우 나타나는 증상
구분 |
UI 접속여부 |
Flow 실행 여부 |
Process 설정값 수정 여부 |
Queue 삭제 및 조회 여부 |
Flowfile Repository |
X |
X |
X |
X |
Database Repository |
O |
X |
X |
X |
Content Repository |
O |
O |
O |
O |
Provenance Repository |
X |
X |
X |
X |
NIFI LOG DIRECTORY |
X |
O |
X |
X |
#Content Repository를 제외한 Repository가 Disk Full인 경우
운영에 직접적으로 영향을 줄 수 있는 Critical한 Repository는 Flowfile Repository와 Provenanve Repository , NIFI LOG Directory입니다. Repository 사용량은 LGU+ POC 기준으로 MB 단위를 넘지 않습니다. 따라서 전용 디스크를 할당하여 관리한다면 NIFI에 급격히 많은 데이터가 유입되더라도 Content Repository의 메타데이터를 기록하는 저장소들이기 때문에 Content Repository보다 먼저 Disk Full이 일어나지 않습니다. 따라서 전용 디스크를 할당하여 관리한다면 Disk Full을 예방할 수 있습니다.
#Content Repository가 Disk Full인경우
가장 중요한 점은 ContRepository 전용 Disk가 Full이 나지 않게 관리하는것입니다. 그럼에도 DiskFull이 난다면 2가지 해결 방안이 있습니다.
1. Queue에 쌓여있는 데이터를 모두 소진한후 NIFI Service 재시작한다.
2. Content Repository에 추가로 디스크를 할당 관리한다.
1.Queue에 쌓여있는 데이터를 소진한후 NIFI Service 재시작한다.
상황 : Content Repository가 Full 이났다면 어떠한 원인에 의해 현재 Queue에 많은 양의 데이터가 Target으로 들어가 소진 되지 못하고 hang 상태.
조치 순서
-
Source에서 데이터를 가져오는 Processor(ex : listsftp) stop
-
Target으로 Writing이 될 수 있도록 상황 조치(Test환경에서는 PutHDFS를 Stop 시켜놓고 Queue를 Hang 상태로 만든 이후에 Disk Full이 난 이후에 해당 Processor를 실행)
-
모든 FlowFile을 Writing하여 Queue의 개수를 0개로 만듦
-
CM에서 NIFI 서비스 중지
-
모든 Node의 Content Repository를 rm으로 삭제 (flowfile들은 이미 Target에 Writing 된 상태)
(기존에는 Target에 Writing을 하면 해당 데이터는 Archive로 넘어가거나 현재 디스크 사용률이 설정값 이상이면 Archive로 넘기지 않고 바로 해당 데이터 삭제. 하지만 Content Repository 전용 디스크가 사용률이 100%면 Target에 데이터 Writing은 가능하지만 Writing된 데이터에 대해서 Contnet Repositroy 로컬 디스크 영역에서 삭제는 불가.)
6. 클러스터 재시작
**LoadBalance가 걸려있는 큐에 대해서는 큐 소진을 완전하게 하지 못함 NIFI-5919 Bug https://issues.apache.org/jira/browse/NIFI-5919
환경
2. Content Repository에 디스크를 추가로 할당
상황 : Content Repository가 Full 이났다면 어떠한 원인에 의해 현재 Queue에 많은 양의 데이터가 Target으로 들어가 소진 되지 못하고 hang 상태.
조치 순서(VM 환경에서 Test)
-
CDH stop, CMS stop, cloudera-manager-server stop, cloudera-manager-agent stop
-
Full 상태인 Content Repository 전용 디스크에 추가 디스크 할당
-
Fstab에 들어가 해당 디스크 설정 해제 및 해당 디스크 umount
-
Fdisk /dev/sdb 를 통하여 Full이 난 디스크 파티션 delete
-
File system partition을 다시 만듦
-
해당 파티션 확인 후 저장
-
서버 재시작
-
xfs_growfs /dev/sdb1 커맨드 입력
9. Mount –t xfs /dev/sdb1 /data01 입력
10. /etc/fstab에 Mount 풀리지 않도록 설정
11. Df -Th를 통해 확인
12. NIFI 접속을 통하여 확인
https://qastack.kr/ubuntu/66000/how-to-merge-partitions
https://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&pageno=0&detail=1&wid=12070
NIFI에서 디스크를 확보하기 위한 정책 설정
Nifi content Repository에서 Archive 영역이란?
Event가 발생한 FlowFile (Queue 삭제, Target에 Writing이 된경우, Processor에서 Auto terminate가 된 FlowFile)들의 경우 일정 기간동안 Archive 영역으로 FlowFile들을 옮겨 보관한다. 위의 설정의 경우 12시간 보관
NIFI.content.repository.archive.max.usage.percentage 설정값 이란??
NIFI.content.repository.archive.max.usage.percentage 설정 값을 50%로 지정한 경우 Content Repository가 사용률이 50%가 넘어간 해당 ContentRepository 디스크에 대해서 Archive 영역을 지우면서 디스크 공간을 확보하려고 합니다. 즉 보관기간이 12시간이 안되었더라도 디스크 사용률이 50%가 넘었다면 Archive 영역을 삭제합니다.
그러나 모든 Archive영역을 삭제 했는데도 계속 새롭운 Flowfile들이 Nifi 노드들로 들어온다면 디스크 사용률은 50%넘게 됩니다. 디스크 사용률이 지정 %이상으로 넘어갔을때 Queue를 삭제하면 이때 Archive 영역으로 들어가는 것이 아니라 바로 ContentRepository에서 삭제됩니다.
Content Repository Disk Full 예방 가이드1
1.예방 정책은 Archive 보관 기간 기준으로 Content repository 크기결정
nifi.content.repository.archive.max.retention.period 해당 값은 12시간 default
Source에서 12시간동안 발생하는 데이터의 양 * 2~3 으로 Content Repository 전용 디스크를 잡는다.
(Source가 1T더라도 Nifi Processor를 거치면서 양이 증가 할 수 있는 부분과 갑작스럽게 많은 데이터가 유입될 수 있는 양을 고려 )
만약 retention.period를 6시간으로 한다면 6시간 동안 발생하는 데이터의 양 * 2~3
6시간의 의미는 Archive 영역의 데이터를 6시간 동안 보유하는 의미
Archive 영역이란???
Target에 Writing되거나 AutoTermination, Empty Queue를 통하여 Queue를 비운 경우 해당 데이터를 Archive 영역에서 확인 할 수 있도록 만든 영역
따라서 Nifi Content Repository에 저장된지 6시간이 지난 FlowFile은 NIFI에서 확인 불가하고 Target에서 직접 확인해야함
nifi.content.repository.archive.max.retention.period 를 기준으로 수립한 정책이 유의미 하기 위해선
nifi.content.repository.archive.max.usage.percentage 설정도 필수 (default 50%)
해당 설정은 Content Repository disk 사용률이 설정한 % 이상으로 사용되면 기존에 존재 하였던 Archive 영역을 삭제하여 디스 공간 확보 🡪 더 이상 지울 Archive 영역이 없다면 더 이상 Archive 영역을 만들지 않고 지속적으로 데이터를 디스크에 저장
따라서 만약 시간을 12시간으로 잡았는데 12시간 이전에 content.repository.archive.max.usage.percentage 이상으로 Flowfile들이 디스크에 저장 되려고 한다면 Nifi에서는 Archive 영역을 삭제하여 디스크 공간을 확보하려고함 따라서 Content Repository를 Source 데이터 양의 2~3배가 되도록 디스크를 잡았다면 70%혹은 80%로 설정하여 Archive 영역이 미리 지워지는 일이 없도록 조치
Content Repository Disk Full 예방 가이드2
만약 Nifi canvas의 모든 커넥션이 100개 이고 Nifi Cluster는 노드 5대에 Content Repository는 1T 디스크가 2장 즉 총량이 10T라고 한다면 10T/100*0.7 = 700G 로 모든 Connection의 Size Threshold를 조정
그러면 모든 커넥션이 풀이 차도 7T 이기에 Content Repository가 Disk Full이 나는 상황을 원천적으로 봉쇄 가능
#.*0.7의 값은 nifi.content.repository.archive.max.usage.percentag보다 약간 적게 설정( Archive 영역 보존을 위하여 )
'Nifi' 카테고리의 다른 글
Nifi Kerberos 연동절차 (0) | 2020.06.12 |
---|---|
NIFI 모든 노드에 작업 분배하기 (Using ListSFTP -> RPG / Input Port -> FetchSFTP) (3) | 2020.04.16 |
NIFI Flow 관리를 위한 Data Provenance event API 호출 (0) | 2020.04.07 |
Nifi를 통하여 File형태를 AWS Redshift에 LOAD (0) | 2020.04.07 |
Nifi를 통하여 AWS RedShift Connection 및 load data (2) | 2020.04.06 |