하둡 네임노드와 HDFS

네임노드와 HDFS의 관계

1. 네임노드와 데이터 노드 등록:
   • 데이터 노드가 클러스터에 가입하려면 네임노드에 자신의 존재를 등록해야 합니다.
   • 데이터 노드는 주기적으로 네임노드에 하트비트 신호를 보내어 자신의 상태를 알립니다.
2. 블록 리포트:
   • 데이터 노드는 자신이 저장하고 있는 데이터 블록의 목록을 네임노드에 보고합니다.
   • 이 정보는 네임노드의 메모리에 저장되어 파일 시스템의 메타데이터를 관리하는 데 사용됩니다.
3. 블록 읽기 및 쓰기 요청:
   • 클라이언트가 데이터를 읽거나 쓰려면 먼저 네임노드에게 해당 데이터 블록의 위치 정보를 요청합니다.
   • 네임노드는 클라이언트에게 데이터 블록의 데이터 노드 위치 정보를 제공합니다.
4. 데이터 노드 간 직접 통신:
   • 클라이언트가 데이터를 읽거나 쓸 때, 실제 데이터는 데이터 노드 간 직접 통신을 통해 전송됩니다.
   • 데이터 노드는 클라이언트에게 데이터를 전송하거나 클라이언트로부터 데이터를 수신합니다.
5. 복제와 데이터 무결성:
   • HDFS에서 데이터는 보통 여러 복제본으로 저장됩니다. 데이터 노드 간에 복제본을 유지하고 무결성을 확인하기 위해 통신이 필요합니다.
   • 복제본 간의 동기화를 유지하며 데이터 무결성을 보장하기 위한 통신이 이루어집니다

https://techvidvan.com/tutorials/hadoop-hdfs-namenode-high-availability-hadoop/

 

 

하둡 Rack-Aware

랙 어웨어니스 (Rack Awareness): 랙 어웨어니스는 하둡 클러스터의 네트워크 토폴로지(Topology)를 이해하고 이를 활용하여 데이터 복제 및 작업 배치를 최적화하는 개념입니다. 하둡 클러스터 내의 모든 데이터 노드와 랙(Rack) 간의 관계를 인식하는 것을 의미합니다. 랙은 데이터 센터 내의 하위 네트워크 단위로, 서버 랙, 스위치 랙 등과 같은 것을 말합니다.

랙 어웨어니스를 이용하면 다음과 같은 이점을 얻을 수 있습니다

• 데이터 복제: 랙 어웨어니스를 활용하여 데이터를 랙 간에 균등하게 복제함으로써 데이터 가용성을 향상시킵니다.
• 네트워크 대역폭 최적화: 데이터 노드 간의 복제 및 데이터 전송 시 랙 간의 대역폭을 고려하여 최적의 경로를 선택하여 네트워크 병목 현상을 줄입니다.
• 장애 격리: 랙 어웨어니스를 통해 랙 간에 데이터 노드를 분산 배치하면 하나의 랙이 고장 났을 때 전체 클러스터에 영향을 미치는 것을 방지할 수 있습니다.

 

topology.py 파일:
topology.py는 Hadoop 클러스터 내에서 랙 어웨어니스를 구현하기 위한 설정 파일 중 하나입니다. 이 파일은 하둡 HDFS와 관련된 네트워크 토폴로지 정보를 정의하고 사용자 지정할 수 있는 스크립트 파일입니다. 주로 하둡 설정 디렉토리 내에서 찾을 수 있으며, 하둡 클러스터의 물리적 네트워크 구조를 설명하고 데이터 노드 및 랙 간의 관계를 설정하는 데 사용됩니다.

topology.py를 수정하면 클러스터의 랙 어웨어니스 구성을 사용자 정의로 변경할 수 있습니다. 이를 통해 데이터의 안정성과 성능을 개선하거나 특정 랙에 대한 제한적인 작업을 설정할 수 있습니다. 예를 들어, topology.py를 사용하여 특정 랙에 데이터를 복제하지 않도록 설정할 수 있습니다.

 

 

하둡의 블록 복제

위에서 데이터노드는 블록 리포트를 주기적으로 네임노드에게 전송을 하게 되고 그것을 통해 데이터 노드의 죽음을 확인 하고 데이터 복제의 1차적인 위치를 확인 합니다.

추후에 hdfs 데이터 보호 아키텍쳐에 따라서 살아있는 노드에 데이터를 복제하게 됩니다.

1. 첫번째 복제본은 클라이언트가 위치한 노드에서 복제합니다. 외부 노드이면 무작위 복제합니다.

2. 두번째 복제본은 첫번째와 다른 랙에 있는 노드에 복제합니다.

3. 세번째 복제본은 두번째와 다른 랙에 있는 노드에 복제합니다.

 

위를 통해서 블록에 대한 복제본은 랙별로 1개씩 할당되게 됩니다.

복제본의 상태는 다음과 같습니다.

FINALIZED (최종): 복제본이 이 상태에 있을 때, 해당 복제본에 대한 쓰기 작업이 완료되었으며, 해당 복제본의 데이터는 "동결"되어 있습니다(길이가 최종적으로 확정됨). 단, 복제본이 추가 쓰기를 위해 다시 열릴 경우 예외입니다. 동일한 생성 스탬프(GS로 지칭하며 아래에서 정의)를 가진 블록의 모든 최종 복제본은 동일한 데이터를 가져야 합니다. 최종 복제본의 GS는 회복 작업의 결과로 인해 증가할 수 있습니다.

RBW (쓰이는 중인 복제본): 쓰이는 중인 복제본은 파일이 쓰기용으로 생성되거나 추가 쓰기를 위해 다시 열릴 때의 상태입니다. RBW 복제본은 항상 열린 파일의 마지막 블록입니다. 데이터는 아직 최종적으로 확정되지 않고 해당 복제본의 데이터 (필요한 경우 전체가 아니더라도)는 리더 클라이언트에게 표시됩니다. 장애가 발생하면 RBW 복제본의 데이터를 보존하려는 시도가 이루어집니다.

RWR (회복 대기 중인 복제본): 데이터 노드가 다운되고 재시작하면, 해당 노드의 모든 RBW 복제본은 RWR 상태로 변경됩니다. RWR 복제본은 오래되어 폐기될 수도 있고, 임대 복구에 참여할 수도 있습니다.

RUR (복구 중인 복제본): 비-임시 복제본은 임대 복구에 참여할 때 RUR 상태로 변경됩니다.

TEMPORARY (임시): 임시 복제본은 블록 복제를 위해 생성됩니다(복제 모니터 또는 클러스터 밸런서에 의해). 이것은 RBW 복제본과 유사하지만 해당 데이터는 모든 리더 클라이언트에게 보이지 않습니다. 블록 복제에 실패하면 임시 복제본이 삭제됩니다.

 

네임노드 관점에서 데이터블록은 다음과 같이 상태가 관리됩니다.

https://blog.cloudera.com/understanding-hdfs-recovery-processes-part-1/

UNDER_CONSTRUCTION (작성 중): 이 상태는 블록이 쓰여지는 상태입니다. 작성 중인 블록은 열린 파일의 마지막 블록이며, 길이와 생성 스탬프는 아직 변경 가능하며, 해당 블록의 데이터(전부가 아니더라도)는 리더에게 보이는 상태입니다. 네임노드의 UNDER_CONSTRUCTION 블록은 작성 파이프라인(유효한 RBW 복제본의 위치) 및 해당 RWR 복제본의 위치를 추적합니다.

UNDER_RECOVERY (복구 중): 파일의 마지막 블록이 UNDER_CONSTRUCTION 상태인 경우, 해당 클라이언트의 임대 기간이 만료되면 블록 복구가 시작될 때 UNDER_RECOVERY 상태로 변경됩니다.

COMMITTED (커밋됨): 커밋됨은 블록의 데이터와 생성 스탬프가 더 이상 변경되지 않으며(추가 쓰기를 위해 다시 열릴 경우 예외), FINALIZED 복제본의 GS(생성 스탬프)과 길이와 같은 속성을 가진 DataNode의 최소 복제 수보다 적은 개수가 있을 때 상태입니다. 읽기 요청을 처리하려면 커밋된 블록은 여전히 RBW 복제본의 위치, GS 및 FINALIZED 복제본의 길이를 추적해야 합니다. UNDER_CONSTRUCTION 블록은 클라이언트가 파일에 새 블록을 추가하거나 파일을 닫도록 네임노드에 요청할 때 COMMITTED로 변경됩니다. 파일의 마지막 또는 두 번째 마지막 블록이 COMMITTED 상태인 경우 파일을 닫을 수 없으며 클라이언트는 다시 시도해야 합니다.

COMPLETE (완료됨): 커밋된 블록은 최소 복제 수의 FINALIZED 복제본이 있는 것을 네임노드가 확인했을 때 COMPLETE로 변경됩니다. 파일의 모든 블록이 COMPLETE 상태가 되어야 파일을 닫을 수 있습니다. 블록이 최소 복제 수의 복제본을 가지고 있지 않더라도 클라이언트가 새 블록을 요청하고 이전 블록이 아직 COMPLETE 상태가 아닐 때 강제로 COMPLETE 상태로 변경될 수 있습니다.

hdfs의 복구 프로세스

1. 블록 복구 (Block Recovery):

• 개념: 블록 복구는 데이터 노드(DataNode)에서 데이터 블록의 복제본이 손상되거나 손실된 경우 해당 블록의 복원을 위한 과정을 의미합니다. HDFS는 데이터 블록을 여러 복제본으로 유지하므로 복제본 중 하나가 손상되면 해당 블록의 복구가 필요합니다.
• 동작 방식:
  1. 클라이언트가 손상된 블록의 위치를 식별합니다.
  2. 클라이언트는 네임노드(NameNode)에게 복구를 요청합니다.
  3. 네임노드는 손상된 블록의 복제본 목록을 반환하고 클라이언트는 다른 정상 복제본에서 누락된 데이터를 복사하여 손상된 블록을 복구합니다.
  4. 클라이언트가 복구 작업을 마치고 새로운 복제본을 데이터 노드에 저장합니다.
  5. 복구가 완료되면 네임노드에게 복구가 성공했음을 보고합니다.

2. 파이프라인 복구 (Pipeline Recovery):

• 개념: 파이프라인 복구는 데이터 블록을 쓰는 동안 데이터 전송 파이프라인 중에 장애가 발생한 경우 해당 파이프라인을 복구하는 과정입니다. 파이프라인은 클라이언트와 데이터 노드 간의 데이터 전송 경로를 나타냅니다.
• 동작 방식:
  1. 데이터를 쓰기 위해 클라이언트가 데이터 블록의 첫 번째 복제본과 통신합니다.
  2. 데이터를 전송하는 동안 중간 데이터 노드에서 장애가 발생하면 해당 파이프라인은 손상됩니다.
  3. 클라이언트는 손상된 파이프라인의 복구를 시작합니다.
  4. 클라이언트는 네임노드에게 파이프라인의 복구를 요청하고 네임노드는 해당 파이프라인에 참여하는 데이터 노드 목록을 반환합니다.
  5. 클라이언트는 복구된 파이프라인을 통해 데이터를 재전송하고 복구가 완료되면 네임노드에게 복구가 성공했음을 보고합니다.

블록 복구와 파이프라인 복구는 HDFS에서 데이터의 가용성과 신뢰성을 유지하는 데 중요한 역할을 합니다. 데이터 노드와 클라이언트 간의 통신 문제 또는 장애 상황에서도 데이터 손실을 최소화하고 데이터를 안정적으로 관리하기 위해 사용됩니다.