ℹ️ 이 강의 자료는 AWS 매뉴얼 을 한글 번역으로 그대로 불러온 강의자료이다. EMR 클러스터 설정시 필요한 개념이나 용어를 설명하기위해서 복사해온 것으로, 강의 시점의 snapshot 유지의 목적이 있다. 정확한 정보는 언제나 공식 매뉴얼에서 확인하는 것이 가장 정확하다.
여러 마스터 노드가 있는 EMR 클러스터를 사용하면 Hadoop에서 HDFS NameNode 고가용성 기능을 사용할 수 있습니다. HDFS.
Amazon EMR 클러스터에서는 두 개 이상의 개별 노드가 로 구성됩니다 NameNodes. NameNode 하나는active
상태에 있고 다른 하나는standby
상태에 있습니다. 있는 노드에active
NameNode 장애가 발생하면 Amazon EMR은 자동 HDFS 페일오버 프로세스를 시작합니다. 가 있는standby
NameNode 노드는 클러스터의 모든 클라이언트 작업이 되어 인계받습니다.active
Amazon EMR은 장애가 발생한 노드를 새 노드로 교체한 다음 새 노드로 다시 연결합니다standby
.
참고
Amazon EMR 버전 5.23.0 이상 5.30.1에서는 마스터 노드 3개 중 2개만 HDFS를 실행합니다 NameNode.
어느 NameNode 것이active
맞는지 알아내야 하는 경우 SSH를 사용하여 클러스터의 모든 마스터 노드에 연결하고 다음 명령을 실행할 수 있습니다.
hdfs haadmin -getAllServiceState
출력에는 설치된 NameNode 노드와 해당 상태가 나열됩니다. 예를 들면 다음과 같습니다.
ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby
여러 마스터 노드가 있는 EMR 클러스터를 통해 Hadoop의 YARN ResourceManager 고가용성 기능을 사용할 수 있습니다.
여러 마스터 노드가 있는 EMR 클러스터에서 YARN은 세 개의 마스터 노드 모두에서 ResourceManager 실행됩니다. ResourceManager 하나는active
상태 상태이고 다른 두 개는standby
상태 상태입니다. 마스터 노드에active
ResourceManager 장애가 발생하면 Amazon EMR은 자동 장애 조치 프로세스를 시작합니다. 가 있는 마스터 노드가 모든standby
ResourceManager 작업을 인계합니다. Amazon EMR은 장애가 발생한 마스터 노드를 새 노드로 교체한 다음 ResourceManager 쿼럼을 로 다시 연결합니다standby
.
모든 마스터 노드의 “http: //:8088/cluster*master-public-dns-name*
”에 연결하면 자동으로 리소스active
관리자로 연결됩니다. 어떤 리소스 관리자가 active
인지 확인하려면 SSH를 사용하여 클러스터의 모든 마스터 노드에 연결하십시오. 그런 다음 아래 명령을 실행하여 세 개의 마스터 노드 및 해당 상태 목록을 가져옵니다.
yarn rmadmin -getAllServiceState
여러 마스터 노드가 있는 EMR 클러스터에 다음 애플리케이션을 설치하고 실행할 수 있습니다. 각 애플리케이션에 따라 마스터 노드 장애 조치 프로세스가 다릅니다.
Application | 프라이머리 노드 장애 조치 중 가용성 | Notes |
---|---|---|
Flink | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | Amazon EMR에서 Flink 작업은 YARN 애플리케이션으로 실행됨. JobManager는 코어 노드에서 YARN 애플리케이션으로 실행되며 프라이머리 노드 장애 조치 프로세스의 영향을 받지 않음. EMR 5.27.0 이하: JobManager는 단일 장애 지점. 실패 시 모든 상태 손실 및 작업 재시작 불가. ZooKeeper 기반 HA 구성을 통해 개선 가능. EMR 5.28.0 이상: JobManager 고가용성이 기본 지원. |
Ganglia | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | 모든 프라이머리 노드에서 사용 가능하므로 장애 조치 중에도 계속 실행됨. |
Hadoop | 높은 가용성 | 활성 프라이머리 노드 장애 시 HDFS NameNode 및 YARN ResourceManager가 자동으로 대기 노드로 장애 조치됨. |
HBase | 높은 가용성 | 활성 프라이머리 노드 장애 시 HBase가 자동으로 대기 노드로 장애 조치됨. REST/Thrift 서버를 통해 연결 시 장애 발생 시 다른 프라이머리 노드로 전환 필요. |
HCatalog | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | 클러스터 외부 Hive 메타스토어 기반이므로 장애 조치 중에도 사용 가능. |
JupyterHub | 높은 가용성 | 세 개의 프라이머리 인스턴스 모두에 설치됨. 노트북 손실 방지를 위해 S3 기반 노트북 지속성 구성이 권장됨. |
Livy | 높은 가용성 | 세 개의 프라이머리 노드 모두에 설치됨. 활성 노드 장애 시 기존 세션은 손실되며, 다른 노드 또는 교체 노드에서 새 세션 생성 필요. |
Mahout | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | Daemon이 없으므로 장애 조치 프로세스의 영향을 받지 않음. |
MXNet | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | Daemon이 없으므로 장애 조치 프로세스의 영향을 받지 않음. |
Phoenix | 고가용성 | Phoenix Query Server는 세 개 프라이머리 노드 중 하나에서 실행됨. 모든 마스터에서 Phoenix는 PQS에 연결하도록 구성됨. /etc/phoenix/conf/phoenix-env.sh 에서 PQS의 Private IP 확인 가능. |
Pig | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | Daemon이 없으므로 장애 조치 프로세스의 영향을 받지 않음. |
Spark | 높은 가용성 | 모든 Spark 애플리케이션은 YARN 컨테이너에서 실행되며 YARN HA 기능과 동일하게 장애 조치 대응. |
Sqoop | 높은 가용성 | 기본적으로 로컬 디스크에 sqoop-job , sqoop-metastore 저장.외부 DB를 메타스토어로 설정 가능(공식 문서 참고). |
Tez | 높은 가용성 | YARN 컨테이너에서 실행되므로 장애 조치 시 YARN과 동일하게 동작. |
TensorFlow | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 | Daemon이 없으므로 장애 조치 프로세스의 영향을 받지 않음. |
Zeppelin | 높은 가용성 | 세 개의 프라이머리 노드 모두에 설치됨. 노트 및 인터프리터 구성을 HDFS에 저장하여 데이터 손실 방지. 세션은 인스턴스 간 격리되며 마스터 장애 시 세션 데이터는 손실됨. 여러 인스턴스에서 동일 노트 동시 수정은 권장되지 않음. |
ZooKeeper | 높은 가용성 | HDFS 자동 장애 조치 기능의 기반 서비스. 조정 데이터 유지, 클라이언트 알림, 장애 감지 등 고가용성 서비스 제공. |
여러 마스터 노드가 있는 Amazon EMR 클러스터에서 다음 애플리케이션을 실행하려면 외부 데이터베이스를 구성해야 합니다. 외부 데이터베이스는 클러스터 외부에 존재하며 마스터 노드 장애 조치 프로세스 중에 데이터를 영구 보존합니다. 다음 애플리케이션의 경우, 서비스 구성 요소는 마스터 노드 장애 조치 프로세스 중에 자동으로 복구되지만 활성 작업은 실패하여 재시도해야 할 수도 있습니다.
Application | 프라이머리 노드 장애 조치 중 가용성 | Notes |
---|---|---|
Hive | 서비스 구성 요소 전용 고가용성 | Hive용 외부 메타스토어가 필요함. PostgreSQL은 다중 마스터 클러스터에서 지원되지 않으므로 MySQL 외부 메타스토어여야 함. 자세한 내용은 Hive용 외부 메타스토어 구성 문서 참조. |
Hue | 서비스 구성 요소 전용 고가용성 | Hue용 외부 데이터베이스 필요. 자세한 내용은 Amazon RDS에서 원격 데이터베이스와 함께 Hue 사용 문서 참조. |
Oozie | 서비스 구성 요소 전용 고가용성 | Oozie용 외부 데이터베이스 필요. 자세한 내용은 Amazon RDS에서 원격 데이터베이스와 함께 Oozie 사용 문서 참조. Oozie-server 및 oozie-client는 모든 프라이머리 노드에 설치됨. Oozie-client는 기본적으로 올바른 Oozie-server에 연결되도록 구성됨. |
PrestoDB / PrestoSQL/ Trino | 서비스 구성 요소 전용 고가용성 | PrestoDB(EMR 6.1.0~6.3.0의 경우 PrestoSQL, EMR 6.4.0 이상은 Trino)에 대해 외부 Hive 메타스토어 필요. AWS Glue 데이터 카탈로그 또는 Hive용 외부 MySQL DB 사용 가능. Presto CLI는 모든 프라이머리 노드에 설치되어, 모든 노드에서 Presto 코디네이터에 액세스 가능. Presto 코디네이터는 단일 프라이머리 노드에만 설치됨. describe-cluster API 응답의 MasterPublicDnsName 필드에서코디네이터 노드의 DNS 확인 가능. |
참고
마스터 노드에 장애가 발생하면 JDBC(Java Database Connectivity) 또는 ODBC(Open Database Connectivity)가 마스터 노드에 대한 연결을 종료합니다. Hive 메타스토어 데몬은 모든 마스터 노드에서 실행되기 때문에 나머지 마스터 노드 중 하나에 연결하여 작업을 계속 할 수 있습니다. 또는 장애가 발생한 마스터 노드가 교체될 때까지 기다릴 수 있습니다.
단일 마스터 노드에 연결하는 것과 동일한 방식으로 SSH를 사용하여 Amazon EMR 클러스터의 세 마스터 노드 중 하나에 연결할 수 있습니다. 자세한 내용은 SSH를 사용하여 마스터 노드에 Connect 참조하십시오.
마스터 노드에 장애가 발생하면 해당 마스터 노드에 대한 SSH 연결이 종료됩니다. 작업을 계속하려면 다른 두 마스터 노드 중 하나에 연결하면 됩니다. 또는 Amazon EMR에서 장애가 발생한 노드를 새 노드로 교체한 후에 새 마스터 노드에 액세스할 수 있습니다.
참고
교체 마스터 노드의 프라이빗 IP 주소는 이전 마스터 노드의 IP 주소와 동일합니다. 교체 마스터 노드의 퍼블릭 IP 주소는 변경될 수 있습니다. 콘솔에서 또는AWS CLI의describe-cluster
명령을 사용하여 새 IP 주소를 검색할 수 있습니다.
NameNode 두 개의 마스터 노드에서만 실행됩니다. 그러나 hdfs
CLI 명령을 실행하고 작업을 실행하여 세 개의 마스터 노드 모두에서 HDFS에 액세스할 수 있습니다.
단일 마스터 노드가 있는 클러스터에서 단계를 처리하는 것과 동일한 방식으로 여러 마스터 노드가 있는 EMR 클러스터에 단계를 제출할 수 있습니다. .
다음은 여러 마스터 노드가 있는 EMR 클러스터에서 단계를 사용할 때 고려할 사항입니다.
_SUCCESS
파일을 사용하여 작업이 성공적으로 완료되었는지 확인합니다.Amazon EMR은 여러 마스터 노드가 있는 모든 클러스터에 대한 종료 보호를 자동으로 활성화하고 클러스터를 생성할 때 제공하는 모든 단계 실행 설정을 재정의합니다. 클러스터를 시작한 후 종료 방지를 비활성화할 수 있습니다. 실행 중인 클러스터에 대한 종료 방지 구성을 참조하세요. 마스터 노드가 여러 개 있는 클러스터를 종료하려면 먼저 클러스터 속성을 수정하여 종료 방지를 비활성화해야 합니다. 지침은 Amazon EMR 섹션을 참조하세요.
다음과 같은 Amazon EMR 기능은 현재 여러 마스터 노드가 있는 EMR 클러스터에서 사용할 수 없습니다.