기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
지원되는 애플리케이션 및 기능
이 주제에서는 Amazon EMR 클러스터의 HDFS NameNode 하둡 고가용성 기능에 대한 정보와, 고가용성 기능이 오픈 소스 애플리케이션 및 기타 Amazon 기능과 함께 작동하는 방식에 대한 정보를 제공합니다. YARN ResourceManager EMR
고가용성 HDFS
여러 기본 노드가 있는 Amazon EMR 클러스터를 사용하면 하둡의 HDFS NameNode 고가용성 기능을 사용할 수 있습니다. 자세한 내용은 HDFS고가용성을
Amazon EMR 클러스터에서는 두 개 이상의 개별 노드가 다음과 같이 구성됩니다 NameNodes. NameNode 하나는 active
상태에 있고 다른 하나는 standby
상태에 있습니다. 가 있는 노드에 active
NameNode 장애가 발생하면 EMR Amazon은 자동 HDFS 장애 조치 프로세스를 시작합니다. 가 있는 노드는 클러스터의 모든 클라이언트 작업이 standby
NameNode active
되어 이를 인수합니다. Amazon은 장애가 발생한 노드를 새 노드로 EMR 교체한 다음 a로 다시 연결합니다. standby
참고
5.30.1까지의 Amazon EMR 버전 5.23.0에서는 기본 노드 세 개 중 두 개만 실행됩니다. HDFS NameNode
어떤 NameNode 노드인지 확인해야 하는 경우 를 사용하여 SSH 클러스터의 모든 기본 노드에 연결하고 다음 명령을 실행할 수 있습니다. active
hdfs haadmin -getAllServiceState
출력에는 설치된 NameNode 노드와 해당 상태가 나열됩니다. 예:
ip-##-#-#-##1.ec2.internal:8020 active ip-##-#-#-##2.ec2.internal:8020 standby ip-##-#-#-##3.ec2.internal:8020 standby
고가용성 YARN ResourceManager
여러 기본 노드가 있는 Amazon EMR 클러스터를 사용하면 하둡의 YARN ResourceManager 고가용성 기능을 사용할 수 있습니다. 자세한 내용은 ResourceManager 고가용성을
여러 기본 노드가 있는 Amazon EMR 클러스터에서는 세 개의 기본 노드 모두에서 YARN ResourceManager 실행됩니다. ResourceManager 하나는 active
상태에 있고 다른 두 개는 standby
상태에 있습니다. 가 있는 기본 노드에 active
ResourceManager 장애가 발생하면 EMR Amazon은 자동 장애 조치 프로세스를 시작합니다. 가 있는 기본 노드가 모든 작업을 standby
ResourceManager 인계합니다. Amazon은 장애가 발생한 기본 노드를 새 노드로 EMR 교체한 다음 새 노드를 a로 ResourceManager 쿼럼에 다시 연결합니다. standby
“http://에 연결할 수 있습니다.master-public-dns-name
모든 기본 노드에 대한 :8088/cluster”. 그러면 자동으로 리소스 관리자로 이동합니다. active
어떤 리소스 매니저인지 active
알아보려면 SSH 를 사용하여 클러스터의 기본 노드에 연결하십시오. 그런 다음 아래 명령을 실행하여 세 개의 프라이머리 노드 및 해당 상태 목록을 가져옵니다.
yarn rmadmin -getAllServiceState
여러 기본 노드가 있는 Amazon EMR 클러스터에서 지원되는 애플리케이션
여러 기본 노드가 있는 Amazon EMR 클러스터에 다음 애플리케이션을 설치하고 실행할 수 있습니다. 각 애플리케이션에 따라 프라이머리 노드 장애 조치 프로세스가 다릅니다.
애플리케이션 | 프라이머리 노드 장애 조치 중 가용성 | 참고 |
---|---|---|
Flink | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
Amazon의 Flink 작업은 YARN 애플리케이션으로 EMR 실행됩니다. Flink는 코어 YARN 노드에서와 같이 JobManagers 실행됩니다 ApplicationMasters . 기본 노드 페일오버 프로세스의 영향을 받지 않습니다. JobManager Amazon EMR 버전 5.27.0 또는 이전 버전을 사용하는 경우 단일 JobManager 장애 지점이 발생합니다. 에 JobManager 실패하면 모든 작업 상태가 손실되고 실행 중인 작업이 재개되지 않습니다. 애플리케이션 시도 횟수, 체크포인트를 구성하고 Flink용 상태 저장소로 활성화하여 JobManager 고가용성을 활성화할 수 ZooKeeper 있습니다. 자세한 내용은 여러 기본 노드가 있는 Amazon EMR 클러스터에서 Flink 구성을 참조하십시오. Amazon EMR 버전 5.28.0부터는 JobManager 고가용성을 활성화하기 위해 수동 구성이 필요하지 않습니다. |
Ganglia | 프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
Ganglia는 모든 프라이머리 노드에서 사용할 수 있으므로 프라이머리 노드 장애 조치 프로세스 중에 계속 실행할 수 있습니다. |
Hadoop | 높은 가용성 |
HDFS NameNode 활성 기본 노드에 장애가 발생하면 YARN ResourceManager 자동으로 대기 노드로 페일오버됩니다. |
HBase |
높은 가용성 |
HBase활성 기본 노드에 장애가 발생하면 자동으로 대기 노드로 페일오버됩니다. REST또는 Thrift 서버를 HBase 통해 연결하는 경우 활성 기본 노드에 장애가 발생하면 다른 기본 노드로 전환해야 합니다. |
HCatalog |
프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
HCatalog클러스터 외부에 있는 Hive 메타스토어를 기반으로 구축됩니다. HCatalog기본 노드 페일오버 프로세스 중에도 계속 사용할 수 있습니다. |
JupyterHub | 높은 가용성 |
JupyterHub 세 개의 기본 인스턴스 모두에 설치됩니다. 프라이머리 노드 장애 시 노트북 손실을 방지하기 위해 노트북 지속성을 구성하는 것이 좋습니다. 자세한 내용은 Amazon S3에서 노트북의 지속성 구성을 참조하세요. |
Livy | 높은 가용성 |
Livy는 3개의 프라이머리 노드 모두에 설치됩니다. 활성 프라이머리 노드에 장애가 발생하면 현재 Livy 세션에 대한 액세스 권한이 손실되므로 다른 프라이머리 노드 또는 새 교체 노드에 새로운 Livy 세션을 생성해야 합니다. |
Mahout |
프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
Mahout에는 대몬(daemon)이 없으므로 프라이머리 노드 장애 조치 프로세스의 영향을 받지 않습니다. |
MXNet |
프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
MXNet에는 데몬이 없으므로 기본 노드 장애 조치 프로세스의 영향을 받지 않습니다. |
피닉스 |
고가용성 |
Phoenix'는 세 개의 기본 노드 중 하나에서만 QueryServer 실행됩니다. 세 마스터의 피닉스는 모두 피닉스를 연결하도록 구성되어 있습니다. QueryServer |
Pig |
프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
Pig에는 대몬(daemon)이 없으므로 프라이머리 노드 장애 조치 프로세스의 영향을 받지 않습니다. |
Spark | 높은 가용성 |
모든 Spark 애플리케이션은 YARN 컨테이너에서 실행되며 YARN 고가용성 기능과 동일한 방식으로 기본 노드 페일오버에 대응할 수 있습니다. |
Sqoop | 높은 가용성 |
기본적으로 명령을 실행하는 마스터의 로컬 디스크에 있는 sqoop-job 및 sqoop-metastore 스토어 데이터(작업 설명)입니다. 외부 데이터베이스에 메타스토어 데이터를 저장하려면 Apache Sqoop 설명서를 참조하십시오. |
Tez |
높은 가용성 |
Tez 컨테이너는 에서 실행되므로 YARN Tez는 기본 노드 장애 조치 프로세스와 동일한 방식으로 작동합니다YARN. |
TensorFlow |
프라이머리 노드 장애 조치의 영향을 받지 않는 가용성 |
TensorFlow 데몬이 없으므로 기본 노드 장애 조치 프로세스의 영향을 받지 않습니다. |
Zeppelin |
높은 가용성 |
Zeppelin은 3개의 프라이머리 노드 모두에 설치됩니다. Zeppelin은 데이터 손실을 방지하기 위해 기본적으로 노트와 인터프리터 구성을 저장합니다. HDFS 인터프리터 세션은 세 개의 프라이머리 인스턴스 모두에서 완전히 격리됩니다. 마스터 장애 시 세션 데이터가 손실됩니다. 다른 여러 프라이머리 인스턴스에서 동일한 노트를 동시에 수정하지 않는 것이 좋습니다. |
ZooKeeper | 높은 가용성 |
ZooKeeper 자동 페일오버 기능의 기초입니다. HDFS ZooKeeper 조정 데이터를 유지 관리하고, 해당 데이터의 변경 사항을 클라이언트에게 알리고, 클라이언트의 장애 여부를 모니터링하기 위한 고가용성 서비스를 제공합니다. 자세한 내용은 HDFS자동 |
여러 기본 노드가 있는 Amazon EMR 클러스터에서 다음 애플리케이션을 실행하려면 외부 데이터베이스를 구성해야 합니다. 외부 데이터베이스는 클러스터 외부에 존재하며 프라이머리 노드 장애 조치 프로세스 중에 데이터를 영구 보존합니다. 다음 애플리케이션의 경우, 서비스 구성 요소는 프라이머리 노드 장애 조치 프로세스 중에 자동으로 복구되지만 활성 작업은 실패하여 재시도해야 할 수도 있습니다.
애플리케이션 | 프라이머리 노드 장애 조치 중 가용성 | 참고 |
---|---|---|
Hive | 서비스 구성 요소 전용 고가용성 |
Hive용 외부 메타스토어가 필요합니다. SQLPostgre는 다중 SQL 마스터 클러스터에서 지원되지 않으므로 내 외부 메타스토어여야 합니다. 자세한 내용은 Hive용 외부 메타스토어 구성을 참조하세요. |
Hue | 서비스 구성 요소 전용 고가용성 |
Hue용 외부 데이터베이스가 필요합니다. 자세한 내용은 RDSAmazon의 원격 데이터베이스에서 Hue 사용을 참조하십시오. |
Oozie |
서비스 구성 요소 전용 고가용성 |
Oozie용 외부 데이터베이스가 필요합니다. 자세한 내용은 Amazon의 원격 데이터베이스에서 Oozie 사용을 참조하십시오. RDS Oozie-server 및 oozie-client는 세 개의 모든 프라이머리 노드에 설치됩니다. oozie-client는 기본적으로 올바른 oozie-server에 연결하도록 구성됩니다. |
프레스토DB 또는 프레스토/트리노 SQL |
서비스 구성 요소 전용 고가용성 |
PrestoDB용 외부 하이브 메타스토어 (아마존 EMR 6.1.0-6.3.0에서는 프레스토 또는 SQL 아마존 6.4.0 이상에서는 트리노) 가 필요합니다. EMR Presto를 AWS Glue 데이터 카탈로그와 함께 사용하거나 Hive용 외부 내 SQL 데이터베이스를 사용할 수 있습니다. CLIPresto는 세 개의 기본 노드 모두에 설치되므로 모든 기본 노드에서 Presto를 사용하여 Presto 코디네이터에 액세스할 수 있습니다. Presto 코디네이터는 하나의 프라이머리 노드에만 설치됩니다. EMR |
참고
기본 노드에 장애가 발생하면 Java 데이터베이스 연결 (JDBC) 또는 개방형 데이터베이스 연결 (ODBC) 이 기본 노드에 대한 연결을 종료합니다. Hive 메타스토어 대몬(daemon)은 모든 프라이머리 노드에서 실행되기 때문에 나머지 프라이머리 노드 중 하나에 연결하여 작업을 계속할 수 있습니다. 또는 장애가 발생한 프라이머리 노드가 교체될 때까지 기다릴 수 있습니다.
여러 기본 노드가 있는 클러스터에서 Amazon EMR 기능이 작동하는 방식
를 사용하여 기본 노드에 연결 SSH
단일 기본 노드에 연결하는 것과 동일한 방법을 사용하여 SSH Amazon EMR 클러스터의 세 기본 노드 중 하나에 연결할 수 있습니다. 자세한 내용은 를 사용하여 주 노드에 연결을 참조하십시오SSH.
기본 노드에 장애가 발생하면 해당 기본 노드에 대한 SSH 연결이 종료됩니다. 작업을 계속하려면 다른 두 프라이머리 노드 중 하나에 연결하면 됩니다. 또는 Amazon이 장애가 발생한 노드를 새 노드로 EMR 교체한 후 새 기본 노드에 액세스할 수 있습니다.
참고
교체 프라이머리 노드의 프라이빗 IP 주소는 이전 프라이머리 노드의 IP 주소와 동일합니다. 교체 프라이머리 노드의 퍼블릭 IP 주소는 변경될 수 있습니다. 콘솔에서 또는 의 describe-cluster
명령을 사용하여 새 IP 주소를 검색할 수 있습니다. AWS
CLI
NameNode 두 개의 기본 노드에서만 실행됩니다. 하지만 세 개의 기본 노드 모두에 액세스할 HDFS 수 있도록 hdfs
CLI 명령을 실행하고 작업을 조작할 수 있습니다.
여러 기본 노드가 있는 Amazon EMR 클러스터의 단계 작업
단일 기본 노드가 있는 EMR 클러스터에서 단계를 작업하는 것과 동일한 방식으로 여러 기본 노드가 있는 Amazon 클러스터에 단계를 제출할 수 있습니다. 자세한 내용은 클러스터에 작업 제출을 참조하세요.
다음은 여러 기본 노드가 있는 Amazon EMR 클러스터에서 단계를 작업할 때 고려할 사항입니다.
-
기본 노드에 장애가 발생하는 경우 기본 노드에서 실행 중인 단계는 로 표시됩니다FAILED. 로컬로 작성된 모든 데이터는 손실됩니다. 그러나 상태는 단계의 실제 상태를 반영하지 FAILED 않을 수 있습니다.
-
기본 노드에 장애가 발생하여 실행 중인 단계가 YARN 응용 프로그램을 시작한 경우 기본 노드의 자동 장애 조치 덕분에 해당 단계가 계속 진행되어 성공할 수 있습니다.
-
작업 출력을 참조하여 단계의 상태를 확인하는 것이 좋습니다. 예를 들어, MapReduce 작업은
_SUCCESS
파일을 사용하여 작업이 성공적으로 완료되었는지 확인합니다. -
ActionOnFailure 매개 변수를 _ _ 또는 _ 대신 CONTINUE WAITTERMINATE, 또는 CANCEL AND _ _로 설정하는 것이 좋습니다. JOB FLOW TERMINATE CLUSTER
자동 종료 방지
Amazon은 여러 기본 노드가 있는 모든 클러스터에 대해 EMR 자동으로 종료 보호를 활성화하고 클러스터를 생성할 때 제공하는 모든 단계 실행 설정을 재정의합니다. 클러스터가 시작된 후 종료 보호를 비활성화할 수 있습니다. 실행 중인 클러스터에 대한 종료 방지 구성을 참조하세요. 여러 프라이머리 노드가 있는 클러스터를 종료하려면 먼저 클러스터 속성을 수정하여 종료 보호를 비활성화해야 합니다. 지침은 여러 기본 노드가 있는 Amazon EMR 클러스터 종료 단원을 참조하십시오.
종료 보호에 대한 자세한 내용은 종료 방지 사용 섹션을 참조하세요.
여러 기본 노드가 있는 Amazon EMR 클러스터에서 지원되지 않는 기능
여러 기본 노드가 있는 Amazon EMR 클러스터에서는 현재 다음과 같은 Amazon EMR 기능을 사용할 수 없습니다.
-
EMR노트북
-
영구 Spark 기록 서버에 대한 원클릭 액세스
-
영구 애플리케이션 사용자 인터페이스
-
여러 기본 노드가 있는 Amazon 클러스터 또는 AWS Lake Formation과 통합된 Amazon EMR 클러스터에서는 현재 영구 애플리케이션 사용자 인터페이스에 원클릭 액세스를 사용할 수 없습니다. EMR
참고
클러스터에서 Kerberos 인증을 사용하려면 외부 인증을 구성해야 합니다. KDC
Amazon EMR 버전 5.27.0부터 여러 기본 노드가 있는 Amazon EMR 클러스터에서 HDFS 투명한 암호화를 구성할 수 있습니다. 자세한 내용은 HDFSAmazon의 투명한 암호화를 참조하십시오EMR.