Hadoop: YARN Federation
Hadoop: YARN Federation
여러 YARN 하위 클러스터를 묶어 단일 YARN 클러스터를 수만 노드로 확장하는 YARN Federation을 설명하는 문서예요. 아키텍처(Router, AMRMProxy, GPG, State-Store), 구성, 샘플 작업 실행, 테스트 클러스터 구축을 다룹니다.
출처: 문서
본문
목적 (Purpose)
YARN은 수천 개 노드로 확장되는 것으로 알려져 있습니다. YARN의 확장성은 Resource Manager가 결정하며, 노드 수, 활성 애플리케이션 수, 활성 컨테이너 수, 하트비트 주기(노드와 애플리케이션 모두)에 비례합니다. 하트비트를 낮추면 확장성을 높일 수 있지만 활용도에 해롭습니다(옛 Hadoop 1.x 경험 참고). 이 문서는 여러 YARN 하위 클러스터를 페더레이션해 단일 YARN 클러스터를 수만 개 노드로 확장하는 페더레이션 기반 접근을 설명합니다. 제안된 접근은 큰(10-100k 노드) 클러스터를 sub-cluster라고 하는 작은 단위로 나누며, 각각 자체 YARN RM과 컴퓨트 노드를 가집니다. 페더레이션 시스템은 이 하위 클러스터들을 묶어 애플리케이션에게 하나의 큰 YARN 클러스터처럼 보이게 합니다. 이 페더레이션 환경에서 실행되는 애플리케이션은 하나의 거대한 YARN 클러스터를 보고 페더레이션 클러스터의 어떤 노드에서든 작업을 스케줄할 수 있습니다. 내부적으로 페더레이션 시스템은 하위 클러스터 리소스 매니저와 협상해 애플리케이션에 자원을 제공합니다. 목표는 개별 작업이 하위 클러스터를 원활하게 "가로질러" 수행되게 하는 것입니다.
이 설계는 구조적으로 확장 가능합니다. 각 RM이 담당하는 노드 수를 제한하고, 적절한 정책이 대부분의 애플리케이션이 단일 하위 클러스터 안에 머물도록 보장하며, 따라서 각 RM이 보는 애플리케이션 수도 제한합니다. 이는 하위 클러스터를 추가하기만 하면(그들 사이에 거의 조정이 필요 없으므로) 거의 선형으로 확장할 수 있다는 뜻입니다. 이 아키텍처는 각 하위 클러스터 안에서 스케줄링 불변 조건을 매우 엄격하게 적용할 수 있고(YARN에서 단순히 상속), 하위 클러스터 간 지속적인 리밸런싱으로 이런 속성이 전역 수준에서도 존중되도록(덜 엄격하게) 합니다(예: 하위 클러스터가 많은 노드를 잃으면 큐를 다른 하위 클러스터에 재매핑해 문제되는 하위 클러스터에서 실행 중인 사용자가 불공정하게 영향받지 않게).
Federation은 기존 YARN 코드베이스 위의 "계층"으로 설계되며, 핵심 YARN 메커니즘의 변경은 제한적입니다.
가정:
- 하위 클러스터 간 연결이 합리적으로 좋다고 가정합니다(예: 아직 DC 간 페더레이션은 목표로 하지 않지만, 미래 조사는 배제하지 않음).
- 저장소 측 확장성은 HDFS 페더레이션(또는 동등한 확장 가능한 DFS 솔루션)에 의존합니다.
아키텍처 (Architecture)
OSS YARN은 약 수천 개 노드까지 확장되는 것으로 알려져 있습니다. 제안된 아키텍처는 sub-cluster라고 하는 여러 작은 YARN 클러스터를 페더레이션해 수만 개 노드로 구성된 더 큰 페더레이션 YARN 클러스터를 만드는 개념을 활용합니다. 이 페더레이션 환경에서 실행되는 애플리케이션은 통합된 큰 YARN 클러스터를 보고 클러스터의 어떤 노드에서든 작업을 스케줄할 수 있습니다. 내부적으로 페더레이션 시스템은 하위 클러스터 RM과 협상해 애플리케이션에 자원을 제공합니다.
YARN Sub-cluster
sub-cluster는 최대 수천 개 노드를 가진 YARN 클러스터입니다. 정확한 크기는 배포·유지보수 용이성, 네트워크·가용성 영역과의 정렬, 일반 모범 사례를 고려해 결정합니다.
sub-cluster YARN RM은 작업 보존 고가용성(work-preserving high-availability)을 켠 채 실행됩니다. 즉 YARN RM, NM 실패를 최소 중단으로 견뎌야 합니다. 하위 클러스터 전체가 손상되면 외부 메커니즘이 작업을 별도 하위 클러스터에서 다시 제출하도록 보장합니다(이는 결국 페더레이션 설계에 포함될 수 있음).
sub-cluster는 페더레이션 환경에서 확장 단위이기도 합니다. 하위 클러스터를 하나 이상 추가해 페더레이션 환경을 확장할 수 있습니다.
참고: 설계상 각 sub-cluster는 완전히 기능하는 YARN RM이며, 페더레이션에 대한 기여는 전체 용량의 일부로만 설정할 수 있습니다. 즉 sub-cluster는 페더레이션에 대한 "부분적" 약속을 가지면서, 자신의 용량 일부를 완전히 로컬하게 나눠줄 능력을 유지할 수 있습니다.
Router
YARN 애플리케이션은 Router 중 하나에 제출되며, Router는 (Policy Store에서 얻은) 라우팅 정책을 적용하고, State Store에서 sub-cluster URL을 조회하고, 애플리케이션 제출 요청을 적절한 sub-cluster RM으로 리다이렉트합니다. 작업이 시작되는 sub-cluster를 "home sub-cluster"라고 하고, 작업이 걸쳐 있는 다른 모든 sub-cluster를 "secondary sub-clusters"라고 합니다. Router는 외부 세계에 ApplicationClientProtocol을 노출해 여러 RM의 존재를 투명하게 숨깁니다. 이를 달성하기 위해 Router는 애플리케이션과 home sub-cluster 사이의 매핑을 State Store에 영속화합니다. 이는 Router가 soft-state가 되면서도 사용자 요청을 저렴하게 지원하게 해 줍니다. 어떤 Router든 이 애플리케이션-홈 sub-cluster 매핑을 복구하고 요청을 올바른 RM으로 방송 없이 직접 보낼 수 있기 때문입니다. 성능을 위해 캐싱과 세션 유지가 권장될 수 있습니다. 페더레이션 상태(애플리케이션과 노드 포함)는 Web UI로 노출됩니다.
AMRMProxy
AMRMProxy는 애플리케이션이 하위 클러스터를 가로질러 확장·실행될 수 있게 하는 핵심 구성 요소입니다. AMRMProxy는 모든 NM 머신에서 실행되며 ApplicationMasterProtocol을 구현해 AM을 위한 YARN RM의 프록시 역할을 합니다. 애플리케이션은 sub-cluster RM과 직접 통신할 수 없습니다. 시스템이 강제로 AMRMProxy 엔드포인트에만 연결하게 하며, 이는 여러 YARN RM에 대한 투명한 접근을 제공합니다(통신을 동적으로 라우팅/분할/병합). 한 번에 작업은 하나의 home sub-cluster와 여러 secondary sub-cluster를 걸칠 수 있지만, AMRMProxy에서 동작하는 정책은 각 작업의 발자국을 제한해 스케줄링 인프라의 오버헤드를 최소화하려 합니다. ARMMProxy의 인터셉터 체인 아키텍처가 그림에 나와 있습니다.
AMRMProxy의 역할
- 오작동하는 AM으로부터 sub-cluster YARN RM을 보호합니다. AMRMProxy는 너무 많은 자원을 요청하는 AM을 쓰로틀링/종료해 DDOS 공격을 막을 수 있어요.
- 클러스터의 여러 YARN RM을 마스킹하고, AM이 하위 클러스터를 가로질러 걸칠 수 있게 투명하게 허용합니다. 모든 컨테이너 할당은 home과 다른 sub-cluster RM 앞에 있는 AMRMProxy로 구성된 YARN RM 프레임워크가 수행합니다.
- 모든 요청을 가로채므로 애플리케이션 쿼터를 시행할 수 있습니다. 이는 sub-cluster RM이 시행할 수 없습니다(각각 AM 요청의 일부만 보기 때문).
- AMRMProxy는 로드 밸런싱/오버플로 정책을 시행할 수 있습니다.
Global Policy Generator
Global Policy Generator는 전체 페더레이션을 관찰하고 시스템이 항상 올바르게 구성·튜닝되도록 보장합니다. 핵심 설계 포인트는 클러스터 가용성이 항상 켜진 GPG에 의존하지 않는다는 것입니다. GPG는 지속적으로 운영되지만 모든 클러스터 연산의 대역 밖(out-of-band)에서, 전역 불변 조건을 시행하고 로드 밸런싱에 영향을 주며 유지보수를 겪을 sub-cluster의 드레이닝을 트리거하는 등의 독특한 관점을 제공합니다. 더 정확히 GPG는 사용자 용량 할당-하위 클러스터 매핑을 갱신하고, 더 드물게 Router, AMRMProxy(그리고 가능하면 RM)에서 실행되는 정책을 변경합니다.
GPG를 사용할 수 없으면 클러스터 연산은 GPG가 정책을 게시한 마지막 시점 상태로 계속됩니다. 장기 사용 불가는 균형, 최적 클러스터 활용, 전역 불변 조건의 바람직한 속성 일부가 흘러갈 수 있음을 의미하지만, 컴퓨트와 데이터 접근은 손상되지 않습니다.
참고: 현재 구현에서 GPG는 수동 튜닝 프로세스이며 CLI로 노출됩니다(YARN-3657).
페더레이션 시스템의 이 부분은 YARN-5597의 향후 작업입니다.
Federation State-Store
Federation State는 여러 개별 sub-cluster를 단일 큰 페더레이션 클러스터로 느슨하게 결합하기 위해 유지해야 하는 추가 상태를 정의합니다. 다음 정보를 포함합니다.
Sub-cluster Membership
멤버 YARN RM은 상태 저장소에 지속적으로 하트비트를 보내 살아있음을 유지하고 현재 용량/부하 정보를 게시합니다. 이 정보는 Global Policy Generator(GPG)가 적절한 정책 결정을 내리는 데 사용됩니다. 또한 Router가 최선의 home sub-cluster를 선택하는 데 사용될 수 있습니다. 이 메커니즘으로 sub-cluster를 추가·제거해 "클러스터 함대"를 동적으로 키우고 줄일 수 있습니다. 이는 또한 각 sub-cluster의 쉬운 유지보수를 허용합니다. 이것은 YARN RM에 추가해야 할 새 기능이지만, 개별 YARN RM HA와 비슷해 메커니즘은 잘 이해되어 있습니다.
Application's Home Sub-cluster
Application Master(AM)가 실행되는 sub-cluster를 Application의 "home sub-cluster"라고 합니다. AM은 home sub-cluster의 자원에 제한되지 않고 다른 sub-cluster(secondary sub-cluster)의 자원도 요청할 수 있습니다. 페더레이션 환경은 AM이 sub-cluster에 배치될 때 대부분의 자원을 home sub-cluster에서 찾을 수 있도록 주기적으로 구성·튜닝됩니다. 특정 경우에만 다른 sub-cluster에서 자원을 요청해야 합니다.
Federation Policy Store
페더레이션 Policy Store는 논리적으로 별도 저장소입니다(같은 물리 구성 요소로 백업될 수 있음). 애플리케이션과 자원 요청이 어떻게 서로 다른 sub-cluster로 라우팅되는지에 대한 정보를 담습니다. 현재 구현은 random/hashing/round-robin/priority에서 sub-cluster 부하와 요청 로컬리티 필요를 고려하는 더 정교한 것까지 여러 정책을 제공합니다.
하위 클러스터를 가로질러 애플리케이션 실행 (Running Applications across Sub-Clusters)
애플리케이션이 제출되면 시스템은 애플리케이션을 실행할 가장 적절한 sub-cluster(애플리케이션의 home sub-cluster)를 결정합니다. AM에서 RM으로의 모든 통신은 AM 머신에 로컬로 실행되는 AMRMProxy를 통해 프록시됩니다. AMRMProxy는 YARN RM과 같은 ApplicationMasterService 프로토콜 엔드포인트를 노출합니다. AM은 저장소 계층이 노출한 로컬리티 정보를 사용해 컨테이너를 요청할 수 있습니다. 이상적인 경우 애플리케이션은 필요한 모든 자원과 데이터가 사용 가능한 sub-cluster에 배치되지만, 다른 sub-cluster의 노드에 컨테이너가 필요하면 AMRMProxy가 그 sub-cluster의 RM과 투명하게 협상해 자원을 제공함으로써 애플리케이션이 전체 페더레이션 환경을 하나의 거대한 YARN 클러스터로 볼 수 있게 합니다. AMRMProxy, Global Policy Generator(GPG), Router가 함께 동작해 이를 원활하게 만듭니다.
다음 작업 실행 흐름에 대한 시퀀스 다이어그램이 그림에 나와 있습니다.
- Router가 YARN Application Client Protocol을 따르는 애플리케이션 제출 요청을 받습니다.
- Router는 라우팅 테이블/정책을 조사해 작업의 "home RM"을 선택합니다(정책 구성은 하트비트로 state-store에서 받음).
- Router는 멤버십 상태를 조회해 home RM의 엔드포인트를 결정합니다.
- Router는 애플리케이션 제출 요청을 home RM으로 리다이렉트합니다.
- Router는 애플리케이션 상태를 home sub-cluster 식별자로 갱신합니다.
- 애플리케이션이 home RM에 제출되면 표준 YARN 흐름이 트리거됩니다. 즉 애플리케이션이 스케줄러 큐에 추가되고, 사용 가능한 자원이 있는 첫 NodeManager에서 home sub-cluster에 그 AM이 시작됩니다. a. 이 과정에서 AM 환경이 수정되어 AMRMProxy의 주소를 대화할 YARN RM으로 가리킵니다. b. AM 시작 시 NM이 보안 토큰도 수정해, AM이 AMRMProxy와만 통신할 수 있게 합니다. AM에서 YARN RM으로의 향후 모든 통신은 AMRMProxy가 중재합니다.
- AM은 HDFS가 노출한 로컬리티 정보를 사용해 컨테이너를 요청합니다.
- 정책에 따라 AMRMProxy는 Unmanaged AM을 제출하고 AM 하트비트를 관련 sub-cluster로 전달해 다른 sub-cluster에서 AM을 대신(impersonate)할 수 있습니다. a. Federation은 AMRMProxy HA와 함께 여러 애플리케이션 시도를 지원합니다. AM 컨테이너는 home sub-cluster에서 다른 attempt id를 가지지만, secondary의 같은 Unmanaged AM이 시도 간에 사용됩니다. b. AMRMProxy HA가 활성화되면 UAM 토큰이 Yarn Registry에 저장됩니다. 각 애플리케이션 시도의 registerApplicationMaster 호출에서 AMRMProxy가 레지스트리에서 기존 UAM 토큰을 가져와(있으면) 기존 UAM에 다시 연결합니다.
- AMRMProxy는 로컬리티 정보와 state-store에 구성된 플러그형 정책을 모두 사용해 AM이 받은 자원 요청을 Home RM으로 보낼지, 하나(또는 여러) Secondary RM으로 보낼지 결정합니다. 그림 1은 AMRMProxy가 요청을 secondary RM으로 보내기로 결정한 경우를 보여줍니다.
- secondary RM은 자신의 sub-cluster의 어떤 노드에서 새 컨테이너를 시작할 유효한 컨테이너 토큰을 AMRMProxy에 제공합니다. 이 메커니즘은 각 sub-cluster가 자체 보안 토큰을 사용하고, 토큰 생성용 클러스터 전체 공유 비밀의 필요를 피하게 합니다.
- AMRMProxy는 할당 응답을 AM에 다시 전달합니다.
- AM은 표준 YARN 프로토콜로 대상 NodeManager(sub-cluster 2)에서 컨테이너를 시작합니다.
구성 (Configuration)
YARN이 Federation을 사용하도록 구성하려면 conf/yarn-site.xml에 다음 속성을 설정합니다.
EVERYWHERE
이것들은 페더레이션의 각 머신에서 conf/yarn-site.xml에 나타나야 하는 공통 구성입니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.enabled |
true |
페더레이션 활성화 여부 |
yarn.resourcemanager.cluster-id |
<unique-subcluster-id> |
이 RM의 고유 subcluster 식별자(HA에 사용된 것과 동일) |
State-Store 구성
현재 state-store의 ZooKeeper와 SQL 기반 구현을 지원합니다.
참고: State-Store 구현은 항상 아래 중 하나로 덮어써야 합니다.
ZooKeeper: Hadoop용 ZooKeeper 설정을 설정해야 합니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.state-store.class |
org.apache.hadoop.yarn.server.federation.store.impl.ZookeeperFederationStateStore |
사용할 state-store 유형. |
yarn.federation.state-store.zk.address |
host:port |
ZooKeeper 앙상블 주소. |
SQL: 다음 파라미터를 설정해야 합니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.state-store.class |
org.apache.hadoop.yarn.server.federation.store.impl.SQLFederationStateStore |
사용할 state-store 유형. |
yarn.federation.state-store.sql.url |
jdbc:mysql://<host>:<port>/FederationStateStore |
SQLFederationStateStore에서 상태가 저장되는 DB 이름. |
yarn.federation.state-store.sql.jdbc-class |
com.mysql.jdbc.jdbc2.optional.MysqlDataSource |
SQLFederationStateStore에 사용할 jdbc 클래스. |
yarn.federation.state-store.sql.username |
<dbuser> |
SQLFederationStateStore의 DB 연결 사용자 이름. |
yarn.federation.state-store.sql.password |
<dbpass> |
SQLFederationStateStore의 DB 연결 비밀번호. |
yarn.federation.state-store.sql.max-connections |
1 |
각 Router가 state-store에 만드는 최대 병렬 연결 수. |
yarn.federation.state-store.sql.minimum-idle |
1 |
HikariCP가 풀에 유지하려 하는 최소 유휴 연결 수 제어. |
yarn.federation.state-store.sql.pool-name |
YARN-Federation-DataBasePool |
FederationSQLStateStore가 사용하는 연결 풀 이름. |
yarn.federation.state-store.sql.max-life-time |
30m |
풀에서 연결의 최대 수명 제어. |
yarn.federation.state-store.sql.idle-time-out |
10m |
연결이 풀에서 유휴로 머물 수 있는 최대 시간 제어. |
yarn.federation.state-store.sql.conn-time-out |
10s |
클라이언트가 풀에서 연결을 기다리는 최대 시간. |
MySQL과 Microsoft SQL Server용 스크립트를 제공합니다.
-
MySQL — MySQL의 경우 MVN Repository에서 최신 5.x 버전 jar를 다운로드해 CLASSPATH에 추가해야 합니다. 그다음 데이터베이스에서 다음 SQL 스크립트를 실행해 DB 스키마를 만듭니다.
- sbin/FederationStateStore/MySQL/FederationStateStoreDatabase.sql
- sbin/FederationStateStore/MySQL/FederationStateStoreUser.sql
- sbin/FederationStateStore/MySQL/FederationStateStoreTables.sql
- sbin/FederationStateStore/MySQL/FederationStateStoreStoredProcs.sql
같은 디렉터리에 Stored Procedures, Tables, User, Database를 삭제하는 스크립트도 제공합니다. 참고: FederationStateStoreUser.sql은 DB의 기본 사용자/비밀번호를 정의하며, 적절한 강한 비밀번호로 설정하는 것을 매우 권장합니다. MySQL이 지원하는 버전은 MySQL 5.7 이상입니다: MySQL 5.7, MySQL 8.0.
-
Microsoft SQL Server — SQL-Server의 경우 과정이 비슷하지만 jdbc 드라이버는 이미 포함되어 있습니다. SQL-Server 스크립트는 **sbin/FederationStateStore/SQLServer/**에 있습니다. SQL-Server가 지원하는 버전은 SQL Server 2008 R2 이상입니다: SQL Server 2008 R2 Enterprise, 2012, 2016, 2017, 2019 Enterprise.
Optional 구성
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.failover.enabled |
true |
각 sub-cluster 안의 RM failover를 고려해 재시도할지 여부. |
yarn.federation.non-ha.enabled |
false |
subCluster의 ResourceManager(RM)가 HA를 활성화하지 않았다면 이 파라미터를 true로 구성할 수 있음. 다만 프로덕션 환경에서는 RM HA를 권장. |
yarn.client.failover-proxy-provider |
org.apache.hadoop.yarn.server.federation.failover.FederationRMFailoverProxyProvider |
FederationStateStore를 사용해 연결할 ResourceManager를 결정하는 FailoverProxyProvider 구현. HA와 일반 모드(구성으로 제어)를 모두 지원. |
yarn.federation.blacklist-subclusters |
<subcluster-id> |
블랙리스트된 sub-cluster 목록. sub-cluster 비활성화에 유용. |
yarn.federation.policy-manager |
org.apache.hadoop.yarn.server.federation.policies.manager.WeightedLocalityPolicyManager |
policy manager 선택은 Applications와 ResourceRequests가 시스템을 통해 라우팅되는 방식을 결정. |
yarn.federation.policy-manager-params |
<binary> |
정책을 구성하는 페이로드. 예시에서는 router와 amrmproxy 정책의 가중치 집합. 보통 프로그래밍 방식으로 구성된 policymanager를 직렬화하거나 state-store를 .json 직렬화 형태로 채워 생성. |
yarn.federation.subcluster-resolver.class |
org.apache.hadoop.yarn.server.federation.resolver.DefaultSubClusterResolverImpl |
노드가 어떤 sub-cluster에, 랙이 어떤 subcluster(s)에 속하는지 해석하는 클래스. |
yarn.federation.machine-list |
<machine-list 파일 경로> |
SubClusterResolver가 사용하는 machine-list 파일 경로. 파일의 각 줄은 sub-cluster와 rack 정보가 있는 노드. 아래 예시: |
| node1, subcluster1, rack1 / node2, subcluster2, rack1 / node3, subcluster3, rack2 / node4, subcluster3, rack2 |
yarn.federation.policy-manager-params 구성
기본 큐의 가중치 정책을 나타내는 yarn.federation.policy-manager-params 파라미터를 구성하며, 관련 정보는 WeightedPolicyInfo로 파싱됩니다.
구성을 위해 다음 JSON 형식을 사용할 수 있습니다.
<property>
<name>yarn.federation.policy-manager-params</name>
<value>{"routerPolicyWeights":{"entry":[{"key":{"id":"SC-2"},"value":"0.3"},{"key":{"id":"SC-1"},"value":"0.7"}]},"amrmPolicyWeights":{"entry":[{"key":{"id":"SC-2"},"value":"0.4"},{"key":{"id":"SC-1"},"value":"0.6"}]},"headroomAlpha":"1.0"}</value>
</property>
이 JSON 구성은 기본 큐의 가중치 정책을 정의합니다.
routerPolicyWeights절은 router 정책의 가중치를 지정. 예를 들어SC-2에 가중치0.3,SC-1에0.7이면 제출된 애플리케이션 요청의30%를SC-2에,70%를SC-1에 할당.amrmPolicyWeights는 서로 다른 subclusters의 RM에서 컨테이너를 요청할 때 Application Master의 할당 비율을 나타냄. 예: AM이 컨테이너를 요청할 때SC-2에서40%,SC-1에서60%요청.headroomAlpha는 가중치 기반과 부하 기반 고려를 균형 잡는 정책이 사용. 1에 가까우면 결정이 대부분 현재 관찰된 다양한 sub-cluster의 headroom에 기반해야 하고, 0에 가까우면 결정이 대부분 가중치에 기반하고 현재 부하는 사실상 무시.
policy-manager 구성
Router Policy — Router Policy는 애플리케이션 제출 라우팅 결정 논리와 애플리케이션의 HomeSubCluster 결정을 정의합니다.
- HashBasedRouterPolicy — 작업의 큐 이름 해시에 기반해 sub-cluster 선택. 시스템에 큐가 많을 때 특히 유용하며 기본 동작을 제공. 또한 같은 큐에 속한 모든 작업이 일관되게 같은 sub-cluster에 매핑되도록 보장해 로컬리티와 성능을 개선.
- LoadBasedRouterPolicy — 단순화된 로드 밸런싱 정책 구현. 이진 가중치(0/1 값)를 사용해 각 sub-cluster를 활성화·비활성화. 부하가 가장 적은 sub-cluster를 선택해 애플리케이션 트래픽을 전달해 최적 분배 보장.
- LocalityRouterPolicy — 클라이언트가 애플리케이션 실행을 위해 지정한 노드에 기반해 sub-cluster 선택. 다음 조건을 따름.
- NODE, RACK, ANY 순서로 세 개의 AMContainerResourceRequests가 있으면 성공.
- 다음이면 WeightedRandomRouterPolicy로 폴백: null/빈 AMContainerResourceRequests; AMContainerResourceRequests 1개이고 ResourceName이 ANY인 경우; 노드가 블랙리스트된 SubClusters에 있는 경우.
- 다음이면 실패: 노드가 존재하지 않고 RelaxLocality가 False인 경우; 유효하지 않은 수(0, 1, 3이 아닌)의 리소스 요청.
- RejectRouterPolicy — 들어오는 모든 요청을 거부.
- UniformRandomRouterPolicy — 현재 활성 sub-cluster 중 균일 무작위로 선택. 사용하기 쉽고 테스트에 좋음.
- WeightedRandomRouterPolicy — 현재 활성 sub-cluster 사이에서 가중 무작위 표본을 구현.
AMRM Policy — AMRM Proxy는 AM이 받은 리소스 요청 목록을 RM들 사이에 분할하는 논리를 정의합니다.
- BroadcastAMRMProxyPolicy — 각 ResourceRequest를 사용 가능한 모든 sub-cluster에 방송.
- HomeAMRMProxyPolicy — ResourceRequest를 home sub-cluster로 보냄.
- LocalityMulticastAMRMProxyPolicy — 호스트 로컬라이즈된 ResourceRequests는 SubClusterResolver의 피드백에 따라 해당 노드를 소유한 RM으로 항상 전달. SubClusterResolver가 노드를 해석하지 못하면 home sub-cluster로 전달을 기본. 랙 로컬라이즈된 ResourceRequests는 해당 랙을 소유한 RM으로 전달. 일부 배포에서 각 랙이 여러 RM에 걸쳐 스트라이프될 수 있는데 이 정책이 존중. SubClusterResolver가 랙을 해석하지 못하면 home sub-cluster로 전달을 기본. 노드/랙 로컬 요청에 해당하는 ANY 요청은 해당 로컬라이즈 요청을 소유한 RM 집합에만 전달. 각 ANY에 나열된 컨테이너 수는 (같은 allocateRequestId로 연결된) 로컬라이즈된 컨테이너 요청 수에 비례.
- RejectAMRMProxyPolicy — 모든 요청을 거부. 앱이 어떤 sub-cluster에도 접근하지 못하게 막는 데 유용.
Policy Manager — PolicyManager는 RouterPolicy와 AMRMPolicy의 조합을 제공합니다.
다음처럼 policy-manager를 설정할 수 있습니다.
<!--
We provide 6 PolicyManagers, They have a common prefix: org.apache.hadoop.yarn.server.federation.policies.manager
1. HashBroadcastPolicyManager
2. HomePolicyManager
3. PriorityBroadcastPolicyManager
4. RejectAllPolicyManager
5. UniformBroadcastPolicyManager
6. WeightedLocalityPolicyManager
-->
<property>
<name>yarn.federation.policy-manager</name>
<value>org.apache.hadoop.yarn.server.federation.policies.manager.HashBroadcastPolicyManager</value>
</property>
- HashBroadcastPolicyManager — 큐 이름의 해시로 애플리케이션을 라우팅하고 리소스 요청을 방송하는 정책. 함께 동작하도록 설계된 router용 HashBasedRouterPolicy와 amrmproxy용 BroadcastAMRMProxyPolicy를 선택.
- HomePolicyManager — Router에 UniformRandomRouterPolicy를, AMRMProxy 정책으로 HomeAMRMProxyPolicy를 사용해 RM을 찾는 policy manager.
- PriorityBroadcastPolicyManager — 운영자가 라우팅 "가중치"를 구성하게 하는 정책. router에 PriorityRouterPolicy, amrmproxy에 BroadcastAMRMProxyPolicy 선택.
- RejectAllPolicyManager — router와 amrmproxy 라우팅 모두 모든 요청을 거부. RejectRouterPolicy와 RejectAMRMProxyPolicy 선택.
- UniformBroadcastPolicyManager — 함께 동작하도록 설계된 UniformRandomRouterPolicy와 BroadcastAMRMProxyPolicy를 결합해 sub-cluster 간 부하를 균일하게 "퍼뜨립니다". 모든 요청이 (복제되고) 방송되므로 RM에 많은 부하를 줄 수 있고 작업이 요청한 것보다 더 많은 컨테이너를 반환할 수 있음.
- WeightedLocalityPolicyManager — 운영자가 라우팅 "가중치"를 구성하게 하는 정책. LocalityRouterPolicy와 LocalityMulticastAMRMProxyPolicy 선택.
queue policy 구성
큐 정책을 보고·저장하는 명령 집합을 제공합니다.
Queue Policy(SubClusterPolicyConfiguration)는 다음을 포함합니다.
| 속성 | 설명 |
|---|---|
queue |
작업 제출용 큐 |
policyType |
Policy Manager 클래스 이름. 기본 UniformBroadcastPolicyManager |
policyParams |
WeightedPolicyInfo의 직렬화 객체 저장 |
WeightedPolicyInfo는 다음을 포함합니다.
- RouterWeight — 애플리케이션을 다른 subclusters로 라우팅하는 가중치. 구성된 가중치에 기반해 애플리케이션을 다른 subclusters로 라우팅. SC-1 0.7, SC-2 0.3 가중치가 있으면 애플리케이션의 70%가 SC-1에, 30%가 SC-2에 할당.
- AmRMWeight — Application Master(AM)에서 서로 다른 subclusters의 Resource Manager(RM)로의 리소스 요청 가중치. SC-1 0.6, SC-2 0.4 가중치가 있으면 AM이 리소스를 요청할 때 요청의 60%가 SC-1의 RM, 40%가 SC-2의 RM으로.
- HeadRoomAlpha — 가중치 기반과 부하 기반 고려를 균형 잡는 정책이 사용. 1에 가까우면 대부분 현재 headroom 기반, 0에 가까우면 대부분 가중치 기반.
ZookeeperFederationStateStore 계층 구성
YARN-2962와 비슷하게 특정 Znode 아래의 노드 수를 관리하기 위해 ZooKeeper federation 저장소의 애플리케이션에 대한 계층 저장을 구현했습니다.
yarn.resourcemanager.zk-appid-node.split-index를 구성할 수 있고, 기본 0입니다. 애플리케이션 id의 마지막 섹션(각 섹션은 _ 로 구분)이 분할되는 인덱스로, zookeeper RM state store에 저장된 애플리케이션 znode가 두 개의 다른 znode(부모-자식)로 저장되게 합니다. 분할은 끝에서 됩니다. 예를 들어 분할 없이 appid znode는 application_1352994193343_0001 형태입니다. 이 구성 값이 1이면 appid znode가 두 부분 application_1352994193343_000과 1로 나뉘고 전자가 부모 노드가 됩니다. application_1352994193343_0002는 부모 노드 application_1352994193343_000 아래의 2로 저장됩니다. 이 구성은 0부터 4까지의 값을 취할 수 있습니다. 0이면 분할 없음입니다. 값이 이 범위 밖이면 0(분할 없음)으로 처리됩니다. ZK 기반 RM state store에 많은 수의 앱을 저장하고 state store 연산이 Zookeeper의 LenError 때문에 실패한다면 0보다 큰 값(최대 4)을 구성해야 합니다.
ON RMs
이것들은 각 ResourceManager의 conf/yarn-site.xml에 나타나야 하는 추가 구성입니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.resourcemanager.epoch |
<unique-epoch> |
epoch의 시드 값. 서로 다른 RM이 생성하는 container-ID의 고유성을 보장하는 데 사용. 따라서 sub-cluster 간 고유하고, epoch를 증가시키는 실패를 허용하도록 well-spaced여야 함. 1000씩 증가는 많은 sub-cluster를 허용하고 충돌 가능성을 사실상 거의 0으로 보장. |
선택:
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.state-store.heartbeat-interval-secs |
60 |
RM이 중앙 state-store에 페더레이션 멤버십을 보고하는 비율. |
애플리케이션 정리 구성 — Router는 예약된 애플리케이션을 StateStore에 저장하는 것을 지원합니다. 그러나 애플리케이션 수가 증가하면 정리 메커니즘을 제공하는 것이 필수적입니다. ResourceManager(RM)에 자동 정리 방법을 구현했습니다. 애플리케이션이 실행을 완료하고 RM의 메모리에서 제거된 뒤 StateStore의 데이터를 정리하려 시도합니다. 또한 일부 애플리케이션이 제대로 정리되지 않는 예외적인 경우를 고려해, RM 시작 시 별도 스레드로 완료된 애플리케이션 정리를 시도합니다. YARN-11323 참고.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.state-store.clean-up-retry-count |
1 |
FederationStateStore에서 앱 정리 재시도 횟수. 기본 1. 즉 앱 정리 실패 후 다시 정리 시도. |
yarn.federation.state-store.clean-up-retry-sleep-time |
1s |
FederationStateStore에서 App 정리 재시도의 수면 시간. 앱 정리 실패 시 일정 시간 자고 다시 시도. 기본 1s. |
ON ROUTER
Router Mode 선택
Router는 YARN Federation mode와 Non-Federation 모드를 지원합니다.
- Non-YARN Federation mode — Router의 역할은 클라이언트 요청을 단순히 클러스터 resourcemanager로 전달하는 것입니다. 이 모드에서는 Router의 conf/yarn-site.xml에 클러스터의 ResourceManager 주소를 구성하기만 하면 됩니다.
- YARN Federation mode — Router는 사용자 구성 큐 정책에 따라 클라이언트 요청을 다른 sub-cluster resourcemanager로 분배합니다. 이 모드에서는 인터셉터, state store 등 항목을 구성해야 합니다.
이것들은 각 Router의 conf/yarn-site.xml에 나타나야 하는 추가 구성입니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.router.bind-host |
0.0.0.0 |
router를 바인딩할 호스트 IP. 서버가 바인딩할 실제 주소. 이 선택 주소를 설정하면 RPC·webapp 서버가 각각 이 주소와 yarn.router.*.address에 지정된 포트에 바인딩. 0.0.0.0으로 설정해 Router가 모든 인터페이스에서 수신하게 하는 데 가장 유용. |
yarn.router.clientrm.interceptor-class.pipeline |
org.apache.hadoop.yarn.server.router.clientrm.FederationClientInterceptor |
클라이언트와 인터페이스할 때 router에서 실행할 인터셉터 클래스의 쉼표 구분 목록. 이 파이프라인의 마지막 단계는 Federation Client Interceptor여야 함. |
yarn.router.rmadmin.interceptor-class.pipeline |
org.apache.hadoop.yarn.server.router.rmadmin.FederationRMAdminInterceptor |
Admin 인터페이스로 클라이언트와 인터페이스할 때 router에서 실행할 인터셉터 클래스의 쉼표 구분 목록. 마지막 단계는 Federation Admin Interceptor여야 함. |
yarn.router.webapp.interceptor-class.pipeline |
org.apache.hadoop.yarn.server.router.webapp.FederationInterceptorREST |
REST 인터페이스로 클라이언트와 인터페이스할 때 router에서 실행할 인터셉터 클래스의 쉼표 구분 목록. 마지막 단계는 Federation Interceptor REST여야 함. |
Router interceptor 구성
- yarn.router.clientrm.interceptor-class.pipeline — 인터셉터의 역할은 클라이언트 요청을 RM으로 전달하는 것입니다.
| 속성 | 모드 | 설명 |
|---|---|---|
org.apache.hadoop.yarn.server.router.clientrm.DefaultClientRequestInterceptor |
Non-Federation |
클라이언트 요청을 클러스터 resource manager로만 전달. |
org.apache.hadoop.yarn.server.router.clientrm.PassThroughClientRequestInterceptor |
Federation |
체인의 다음 인터셉터로 전달하는 것 외에는 아무것도 하지 않는 인터셉터. |
org.apache.hadoop.yarn.server.router.clientrm.FederationClientInterceptor |
Federation |
YARN RM 페더레이션과 여러 YARN SubClusters에 걸친 애플리케이션 확장의 구현을 제공하는 클래스. 모든 페더레이션 특정 구현이 이 클래스에 캡슐화. 항상 체인의 마지막 인터셉터. |
org.apache.hadoop.yarn.server.router.clientrm.ApplicationSubmissionContextInterceptor |
Federation |
ApplicationClientProtocol에 대한 DoS 공격을 막음. ApplicationSubmissionContext의 크기를 확인. 한도를 초과하면 Zookeeper 실패를 일으킬 수 있음. |
FederationClientInterceptor의 스레드 풀 구성 — FederationClientInterceptor는 여러 subClusters에서 데이터를 검색합니다. 성능을 개선하기 위해 여러 subClusters에 동시 접근하는 스레드 풀을 사용합니다. 아래는 스레드 풀 구성이며, 프로덕션 환경 요구사항에 따라 조정할 수 있습니다.
| 속성 | 기본 | 설명 |
|---|---|---|
yarn.router.interceptor.user-thread-pool.minimum-pool-size |
5 |
인터셉터 스레드 풀의 corePoolSize(minimumPoolSize) 설정. |
yarn.router.interceptor.user-thread-pool.maximum-pool-size |
5 |
인터셉터 스레드 풀의 maximumPoolSize 기본값 설정. |
yarn.router.interceptor.user-thread-pool.keep-alive-time |
0s |
인터셉터 스레드 풀의 keepAliveTime 설정. |
yarn.router.interceptor.user-thread-pool.allow-core-thread-time-out |
false |
keep-alive 시간 내에 작업이 도착하지 않을 때 core 스레드의 종료 정책 구성. true로 설정하려면 keep-alive-time이 0보다 커야 함. |
- yarn.router.rmadmin.interceptor-class.pipeline — 인터셉터의 역할은 클라이언트의 관리자 요청을 RM으로 전달하는 것입니다.
| 속성 | 모드 | 설명 |
|---|---|---|
org.apache.hadoop.yarn.server.router.rmadmin.DefaultRMAdminRequestInterceptor |
Non-Federation |
클라이언트 요청을 클러스터 resource manager로만 전달. |
org.apache.hadoop.yarn.server.router.rmadmin.FederationRMAdminInterceptor |
Federation |
클라이언트의 관리자 요청을 가로채 Yarn SubClusters의 ResourceManager로 전달. 항상 체인의 마지막 인터셉터. |
FederationRMAdminInterceptor의 스레드 풀 구성 — FederationRMAdminInterceptor가 사용하는 스레드 풀 구성은 FederationClientInterceptor와 일관되며, 직접 참조해 구성할 수 있습니다.
- yarn.router.webapp.interceptor-class.pipeline — 인터셉터의 역할은 클라이언트 Rest 요청을 RM으로 전달하는 것입니다.
| 속성 | 모드 | 설명 |
|---|---|---|
org.apache.hadoop.yarn.server.router.webapp.DefaultRequestInterceptorREST |
Non-Federation |
클라이언트 요청을 클러스터 resource manager로만 전달. |
org.apache.hadoop.yarn.server.router.webapp.FederationInterceptorREST |
Federation |
클라이언트의 Rest 요청을 가로채 Yarn SubClusters의 ResourceManager로 전달. 항상 체인의 마지막 인터셉터. |
ApplicationSubmissionContextInterceptor 활성화 방법:
FederationStateStore가Zookpeer저장으로 구성되면 앱 정보가Zookpeer에 저장됩니다. 앱 정보 크기가1MB를 초과하면Zookpeer가 실패할 수 있습니다.ApplicationSubmissionContextInterceptor가ApplicationSubmissionContext의 크기를 확인하고, 한도(기본 1MB)를 초과하면 예외를 던집니다.- 필요 구성은 다음과 같습니다.
<property>
<name>yarn.router.clientrm.interceptor-class.pipeline</name>
<value>org.apache.hadoop.yarn.server.router.clientrm.PassThroughClientRequestInterceptor,
org.apache.hadoop.yarn.server.router.clientrm.ApplicationSubmissionContextInterceptor,
org.apache.hadoop.yarn.server.router.clientrm.FederationClientInterceptor</value>
</property>
<property>
<name>yarn.router.asc-interceptor-max-size</name>
<value>1MB</value>
</property>
선택:
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.router.hostname |
0.0.0.0 |
Router 호스트 이름. |
yarn.router.clientrm.address |
0.0.0.0:8050 |
Router 클라이언트 주소. |
yarn.router.webapp.address |
0.0.0.0:8089 |
Router의 webapp 주소. |
yarn.router.admin.address |
0.0.0.0:8052 |
Router의 admin 주소. |
yarn.router.webapp.https.address |
0.0.0.0:8091 |
Router의 보안 webapp 주소. |
yarn.router.submit.retry |
3 |
포기하기 전 router의 재시도 횟수. |
yarn.router.submit.interval.time |
10ms |
두 재시도 사이 간격. 기본 10ms. |
yarn.federation.cache-ttl.secs |
300s |
Router가 정보를 캐시하고, 캐시가 무효화되기까지 남는 시간. |
yarn.federation.cache.class |
org.apache.hadoop.yarn.server.federation.cache.FederationJCache |
Router가 정보를 캐시. Cache 구현을 구성할 수 있고 기본 구현은 FederationJCache. |
Router security 구성
페더레이션에서 Kerberos 지원.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.router.keytab.file |
router가 서비스 프린시펄로 로그인하는 데 사용하는 keytab 파일. 프린시펄 이름은 'yarn.router.kerberos.principal'로 구성. | |
yarn.router.kerberos.principal |
Router 서비스 프린시펄. 보통 router/[email protected]로 설정. 각 Router는 시작 시 _HOST를 자신의 완전 도메인 호스트명으로 치환. _HOST 플레이스홀더 덕분에 설정의 모든 Router에서 같은 구성 설정을 사용할 수 있음. | |
yarn.router.kerberos.principal.hostname |
선택. 이 구성 파일을 담은 Router의 호스트명. 머신마다 다름. 기본 현재 호스트명. |
Router Cors 지원 구성
Yarn Router의 교차 출처 지원(CORS)을 활성화하려면 다음 구성 파라미터를 설정합니다.
| 속성 | 예시 | 설명 |
|---|---|---|
hadoop.http.filter.initializers |
org.apache.hadoop.security.HttpCrossOriginFilterInitializer |
선택. 필터를 HttpCrossOriginFilterInitializer로 설정. core-site.xml에서 구성. |
yarn.router.webapp.cross-origin.enabled |
true |
선택. CORS 필터 활성화/비활성화. yarn-site.xml에서 구성. |
Router Cache 구성
Cache는 기본적으로 활성화됩니다. yarn.federation.cache-ttl.secs 파라미터를 설정하고 값이 0보다 크면 Cache가 활성화됩니다. 현재 세 가지 Cache 구현을 제공합니다: JCache, GuavaCache, CaffeineCache.
- JCache —
geronimo-jcache를 사용하며, 이는 Apache Geronimo 프로젝트가 제공하는 Java Caching API(JSR-107) 규격의 구현입니다. YARN Federation에서는geronimo-jcache와Ehcache의 조합을 사용합니다. JCache를 사용하려면yarn.federation.cache.class를org.apache.hadoop.yarn.server.federation.cache.FederationJCache로 구성. - GuavaCache — Guava 프레임워크 기반 Cache. 사용하려면
yarn.federation.cache.class를org.apache.hadoop.yarn.server.federation.cache.FederationGuavaCache로 구성. - CaffeineCache — CaffeineCache는 Java용 고성능 캐싱 라이브러리로, Ehcache와 Guava Cache보다 나은 성능 제공. 사용하려면
yarn.federation.cache.class를org.apache.hadoop.yarn.server.federation.cache.FederationCaffeineCache로 구성.
Router AuditLog 구성
Router의 AuditLog 구성을 활성화하고 별도 로그 파일로 AuditLog를 수집할 수 있습니다. conf/log4j.properties 파일의 RouterAuditLog 관련 구성을 수정해야 합니다.
구성은 다음과 같습니다.
router.audit.logger=INFO,ROUTERAUDIT
router.audit.log.maxfilesize=256MB
router.audit.log.maxbackupindex=20
log4j.logger.org.apache.hadoop.yarn.server.router.RouterAuditLogger=${router.audit.logger}
log4j.additivity.org.apache.hadoop.yarn.server.router.RouterAuditLogger=false
log4j.appender.ROUTERAUDIT=org.apache.log4j.RollingFileAppender
log4j.appender.ROUTERAUDIT.File=${hadoop.log.dir}/router-audit.log
log4j.appender.ROUTERAUDIT.layout=org.apache.log4j.PatternLayout
log4j.appender.ROUTERAUDIT.layout.ConversionPattern=%d{ISO8601} %p %c{2}: %m%n
log4j.appender.ROUTERAUDIT.MaxFileSize=${router.audit.log.maxfilesize}
log4j.appender.ROUTERAUDIT.MaxBackupIndex=${router.audit.log.maxbackupindex}
Router Opts 구성
Router의 HEAPSIZE나 OPTS를 수정해야 한다면 yarn-env.sh 파일에서 변경할 수 있습니다.
- YARN_ROUTER_HEAPSIZE
# Specify the max heapsize for the Router. If no units are given, it will be assumed to be in MB.
# Default is the same as HADOOP_HEAPSIZE_MAX
export YARN_ROUTER_HEAPSIZE=
- YARN_ROUTER_OPTS
# Specify the JVM options to be used when starting the Router. These options will be appended to the options specified as HADOOP_OPTS
# and therefore may override any similar flags set in HADOOP_OPTS
export YARN_ROUTER_OPTS="-Drouter.audit.logger=INFO,ROUTERAUDIT"
클라이언트가 Router를 무작위로 선택하도록 구성
기본적으로 클라이언트는 구성된 router 목록의 첫 router부터 시도합니다. 연결이 성공하면 router는 교체되지 않습니다. 클라이언트가 Router를 무작위로 선택하도록 yarn.federation.failover.random.order를 true로 설정할 수 있습니다.
만료된 subClusters 정리 구성
Router가 모든 subClusters의 상태를 주기적으로 모니터링하는 별도 스레드를 시작하게 할 수 있습니다. subCluster의 하트비트가 특정 시간 임계값을 초과하면 그 subCluster를 "LOST"로 분류합니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.router.deregister.subcluster.enable |
true |
자동 subCluster 오프라인 기능 활성화 여부. 기본 true. |
yarn.router.subcluster.heartbeat.expiration.time |
30m |
기본 subCluster 하트비트 타임아웃 시간 30분. |
yarn.router.scheduled.executor.threads |
1 |
subCluster 타임아웃 확인을 위해 시작된 스레드 수. 기본 1. 기본값으로 충분. |
yarn.router.subcluster.cleaner.interval.time |
60s |
확인 스레드의 확인 간격. 기본 60s. |
참고 모든 Router에 subCluster deregister 확인 스레드를 구성할 필요는 없습니다. 1-2개 Router에서 확인하면 충분합니다.
부분 결과 허용 구성
Router는 여러 YARN SubClusters를 연결하고 특정 인터페이스에 대해 여러 subClusters의 반환 결과를 병합하는 역할을 합니다. 그러나 subcluster가 RM 업그레이드를 겪거나 RM 실패를 겪으면 그 특정 RM을 호출하면 올바른 결과를 반환하지 않습니다. 이 문제를 해결하기 위해 Router는 부분 결과 반환을 허용하는 구성을 제공합니다. 관련 파라미터를 구성하면 Router는 실패한 subClusters를 건너뛰고 다른 subClusters의 결과만 반환합니다. 이렇게 하면 최소한 일부 올바른 결과를 얻을 수 있습니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.router.interceptor.allow-partial-result.enable |
false |
부분 결과 반환 지원 여부. |
참고 파라미터를 구성해도 모든 sub-cluster가 실패를 반환하면 Router는 여전히 예외를 던집니다. 반환할 결과가 없어 유효한 응답을 제공할 수 없기 때문입니다.
Router Command Line 사용
- Cmd1: deregisterSubCluster — 이 명령은
subCluster를 등록 해제하는 데 사용됩니다. subCluster의 하트비트 시간과 현재 시간 간격이 타임아웃 기간을 초과하면 subCluster의 상태를SC_LOST로 설정.
사용법: yarn routeradmin -deregisterSubCluster [-sc|--subClusterId <subCluster Id>]
예시: SC-1을 deregisterSubCluster하려면
yarn routeradmin -deregisterSubCluster -sc SC-1
yarn routeradmin -deregisterSubCluster --subClusterId SC-1
- Cmd2: policy — Policy에 대한 목록·저장·배치 저장 명령 집합을 제공합니다.
사용법:
yarn routeradmin -policy -s|--save (queue;router weight;amrm weight;headroomalpha)
yarn routeradmin -policy -bs|--batch-save (--format xml) (-f|--input-file fileName)
yarn routeradmin -policy -l|--list ([--pageSize][--currentPage][--queue][--queues])
SubCmd1: -s|--save (queue;router weight;amrm weight;headroomalpha) — 큐의 정책 정보(큐와 가중치 정보 포함)를 저장하는 데 사용. routerWeight/amrmWeight의 모든 sub-cluster 가중치 합은 1이어야 합니다.
| 속성 | 설명 |
|---|---|
queue |
스케줄된 큐 |
router weight |
애플리케이션을 다른 subclusters로 라우팅하는 가중치. |
amrm weight |
Application Master(AM)에서 다른 subclusters의 Resource Manager(RM)로 리소스 요청하는 가중치. |
headroomalpha |
가중치 기반과 부하 기반 고려를 균형 잡는 정책이 사용. load-base 함수가 아직 완성되지 않았으므로 1.0 사용 권장. |
예시: 두 sub-cluster SC-1과 SC-2가 있습니다. root.a 큐에 가중치 정책을 구성하려 합니다. Router Weight는 SC-1 0.7, SC-2 0.3. AMRM Weight는 SC-1 0.6, SC-2 0.4. headroomalpha는 기본 0.1 사용.
yarn routeradmin -policy --save root.a;SC-1:0.7,SC-2:0.3;SC-1:0.6,SC-2:0.4;1.0
SubCmd2: -bs|--batch-save (--format xml) (-f|--input-file fileName) — 제공된 federation-weights.xml 파일을 기반으로 큐의 가중치 정보를 배치로 로드.
federation-weights.xml 구성:
<federationWeights>
<weight>
<queue>
<name>root.a</name>
<amrmPolicyWeights>
<subClusterIdInfo>
<id>SC-1</id>
<weight>0.7</weight>
</subClusterIdInfo>
<subClusterIdInfo>
<id>SC-2</id>
<weight>0.3</weight>
</subClusterIdInfo>
</amrmPolicyWeights>
<routerPolicyWeights>
<subClusterIdInfo>
<id>SC-1</id>
<weight>0.6</weight>
</subClusterIdInfo>
<subClusterIdInfo>
<id>SC-2</id>
<weight>0.4</weight>
</subClusterIdInfo>
</routerPolicyWeights>
<headroomAlpha>1.0</headroomAlpha>
</queue>
</weight>
<weight>
<queue>
<name>root.b</name>
<amrmPolicyWeights>
<subClusterIdInfo>
<id>SC-1</id>
<weight>0.8</weight>
</subClusterIdInfo>
<subClusterIdInfo>
<id>SC-2</id>
<weight>0.2</weight>
</subClusterIdInfo>
</amrmPolicyWeights>
<routerPolicyWeights>
<subClusterIdInfo>
<id>SC-1</id>
<weight>0.6</weight>
</subClusterIdInfo>
<subClusterIdInfo>
<id>SC-2</id>
<weight>0.4</weight>
</subClusterIdInfo>
</routerPolicyWeights>
<headroomAlpha>1.0</headroomAlpha>
</queue>
</weight>
</federationWeights>
예시:
yarn routeradmin -policy -bs --format xml -f /path/federation-weights.xml
yarn routeradmin -policy --batch-save --format xml -f /path/federation-weights.xml
SubCmd3: -l|--list (--pageSize --currentPage --queue --queues) — 구성된 큐 가중치 정보를 표시.
예시:
yarn routeradmin -policy -l --pageSize 20 --currentPage 1 --queue root.a
yarn routeradmin -policy -list --pageSize 20 --currentPage 1 --queues root.a,root.b
ON GPG
GlobalPolicyGenerator("GPG"로 약칭)는 subClusters의 전역 정책 자동 생성에 사용됩니다. GPG의 기능은 아직 개발 중이고 완성되지 않았습니다. 프로덕션 환경에서 사용을 권장하지 않습니다.
이것들은 GPG용 conf/yarn-site.xml에 나타나야 하는 추가 구성입니다. GPG는 하나만 허용합니다.
선택:
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.gpg.scheduled.executor.threads |
10 |
GPG 예약 executor 서비스에 사용할 스레드 수. 기본 10. |
yarn.federation.gpg.subcluster.cleaner.interval-ms |
-1 |
subcluster cleaner가 실행되는 간격. -1은 비활성화. |
yarn.federation.gpg.subcluster.heartbeat.expiration-ms |
30m |
subcluster 하트비트 만료 시간. 기본 30분. |
yarn.federation.gpg.application.cleaner.class |
org.apache.hadoop.yarn.server.globalpolicygenerator.DefaultApplicationCleaner |
사용할 application cleaner 클래스. |
yarn.federation.gpg.application.cleaner.interval-ms |
-1 |
application cleaner가 실행되는 간격. -1은 비활성화. |
yarn.federation.gpg.application.cleaner.contact.router.spec |
3,10,600000 |
쉼표로 구분된 세 값: 최소 성공 재시도, 최대 총 재시도, 재시도 간격(ms). |
yarn.federation.gpg.policy.generator.interval |
1h |
policy generator가 실행되는 간격. 기본 1시간. |
yarn.federation.gpg.policy.generator.class |
org.apache.hadoop.yarn.server.globalpolicygenerator.policygenerator.NoOpGlobalPolicy |
구성된 policy generator 클래스. 기본 NoOpGlobalPolicy 실행. |
yarn.federation.gpg.policy.generator.readonly |
false |
policy generator가 읽기 전용(정책 수정 안 함)으로 실행되는지 여부. 기본 false. |
yarn.federation.gpg.policy.generator.blacklist |
policy generator가 블랙리스트해야 할 sub-clusters. | |
yarn.federation.gpg.policy.generator.load-based.pending.minimum |
100 |
subCluster의 최소 pending 애플리케이션 수. |
yarn.federation.gpg.policy.generator.load-based.pending.maximum |
1000 |
subCluster의 최대 pending 애플리케이션 수. |
yarn.federation.gpg.policy.generator.load-based.weight.minimum |
0 |
subCluster의 부하가 매우 높으면 우리가 이 값을 subCluster에 할당. 기본 0, 즉 더 이상 이 subCluster에 애플리케이션을 할당하지 않음. |
yarn.federation.gpg.policy.generator.load-based.edit.maximum |
3 |
계산하려는 subClusters 수. 기본 3. |
yarn.federation.gpg.policy.generator.load-based.scaling |
LINEAR |
NONE, LINEAR, QUADRATIC, LOG의 4가지 계산 방법 제공. |
yarn.federation.gpg.webapp.address |
0.0.0.0:8069 |
GPG 웹 애플리케이션 주소. |
yarn.federation.gpg.webapp.https.address |
0.0.0.0:8070 |
GPG 웹 애플리케이션 https 주소. |
- yarn.federation.gpg.application.cleaner.contact.router.spec — 앱에 대해 Router에 (몇 번) 접촉할지에 대한 사양. 어떤 sub-cluster RM이 응답하지 않아(예: failover) Router가 부분 애플리케이션 목록을 반환할 수 있으므로 이것이 필요. 쉼표로 구분된 세 값: 최소 성공 재시도, 최대 총 재시도, 재시도 간격(ms).
- yarn.federation.gpg.policy.generator.load-based.scaling — 참고: 이 계산 방법은 subCluster의 Pending Applications 수가
yarn.federation.gpg.policy.generator.load-based.pending.maximum보다 작을 때입니다.- maxPendingVal =
yarn.federation.gpg.policy.generator.load-based.pending.maximum-yarn.federation.gpg.policy.generator.load-based.pending.minimum - curPendingVal =
subCluster의 Pending Applications-yarn.federation.gpg.policy.generator.load-based.pending.minimum - 계산이 필요 없고 이때 가중치는 1입니다.
- LINEAR: 선형 계산. (maxPendingVal - curPendingVal) / (maxPendingVal) 사용.
- QUADRATIC: 이차 계산. maxPendingVal, curPendingVal에 대해 이차 계산 후 공식 = (maxPendingVal - curPendingVal) / (maxPendingVal) 사용.
- LOG(LOGARITHM): 로그 계산. maxPendingVal, curPendingVal에 대해 로그 계산 후 공식 사용.
- 기본은 LINEAR. 참고 만료된 애플리케이션 정리에 GPG의 기능을 사용하는 것은 이 기능이 아직 개발 중이므로 프로덕션 환경에서 권장하지 않습니다.
- maxPendingVal =
GPG security 구성
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.federation.gpg.keytab.file |
GPG가 서비스 프린시펄로 로그인하는 데 사용하는 keytab 파일. 프린시펄 이름은 'yarn.federation.gpg.kerberos.principal.hostname'으로 구성. | |
yarn.federation.gpg.kerberos.principal |
GPG 서비스 프린시펄. 보통 GPG/[email protected]로 설정. GPG는 시작 시 _HOST를 자신의 FQDN으로 치환. | |
yarn.federation.gpg.kerberos.principal.hostname |
선택. 이 구성 파일을 담은 GPG의 호스트명. 머신마다 다름. 기본 현재 호스트명. |
GPG Cors 지원 구성
| 속성 | 예시 | 설명 |
|---|---|---|
hadoop.http.filter.initializers |
org.apache.hadoop.security.HttpCrossOriginFilterInitializer |
선택. core-site.xml에서 구성. |
yarn.federation.gpg.webapp.cross-origin.enabled |
true |
선택. CORS 필터 활성화/비활성화. yarn-site.xml에서 구성. |
GPG Opts 구성
GPG의 HEAPSIZE나 OPTS를 수정하려면 yarn-env.sh 파일에서 변경할 수 있습니다. YARN_GLOBALPOLICYGENERATOR_HEAPSIZE와 YARN_GLOBALPOLICYGENERATOR_OPTS를 사용합니다.
ON NMs
이것들은 각 NodeManager의 conf/yarn-site.xml에 나타나야 하는 추가 구성입니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.nodemanager.amrmproxy.enabled |
true |
AMRMProxy 활성화 여부. |
yarn.nodemanager.amrmproxy.interceptor-class.pipeline |
org.apache.hadoop.yarn.server.nodemanager.amrmproxy.FederationInterceptor |
amrmproxy에서 실행할 인터셉터의 쉼표 구분 목록. 페더레이션의 경우 파이프라인의 마지막 단계는 FederationInterceptor여야 함. |
선택:
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.nodemanager.amrmproxy.ha.enable |
true |
여러 애플리케이션 시도 지원을 위해 AMRMProxy HA가 활성화되는지 여부. |
yarn.federation.statestore.max-connections |
1 |
각 AMRMProxy에서 state-store로의 최대 병렬 연결 수. AMRMProxy가 많아 DB 연결을 빠르게 태울 수 있으므로 보통 router보다 낮음. |
yarn.federation.cache-ttl.secs |
300 |
AMRMProxy 캐시에 남는 시간. AMRMProxy 수가 많고 중앙 state-store 부하를 제한하고 싶으므로 보통 router보다 큼. |
샘플 작업 실행 (Running a Sample Job)
Federation 클러스터에 작업을 제출하려면 작업이 제출될 클라이언트용 별도 구성 집합을 만들어야 합니다. 여기서 conf/yarn-site.xml은 다음 추가 구성을 가져야 합니다.
| 속성 | 예시 | 설명 |
|---|---|---|
yarn.resourcemanager.address |
<router_host>:8050 |
클라이언트에서 실행된 작업을 router의 클라이언트 RM 포트로 리다이렉트. |
yarn.resourcemanager.scheduler.address |
localhost:8049 |
작업을 federation AMRMProxy 포트로 리다이렉트. |
위에서 설명한 클라이언트 구성에서 클러스터의 모든 YARN 작업을 제출할 수 있습니다. federation을 통해 작업을 실행하려면 먼저 여기 설명된 대로 federation에 관련된 모든 클러스터를 시작합니다. 다음으로 router 머신에서 다음 명령으로 router를 시작합니다.
$HADOOP_HOME/bin/yarn --daemon start router
이제 $HADOOP_CONF_DIR이 위에서 설명한 클라이언트 구성 폴더를 가리키게 하고 평소 방식으로 작업을 실행합니다. 위에서 설명한 클라이언트 구성 폴더의 구성이 작업을 router가 시작된 뒤 수신 중이어야 할 router의 클라이언트 RM 포트로 안내합니다. 클라이언트에서 federation 클러스터에서 Pi 작업을 실행한 예시입니다:
$HADOOP_HOME/bin/yarn jar hadoop-mapreduce-examples-3.0.0.jar pi 16 1000
이 작업은 router에 제출되며, 위에서 설명한 대로 GPG가 생성한 정책을 사용해 작업이 제출될 home RM을 선택합니다.
이 예시 작업의 출력은 다음과 같아야 합니다:
2017-07-13 16:29:25,055 INFO mapreduce.Job: Job job_1499988226739_0001 running in uber mode : false
2017-07-13 16:29:25,056 INFO mapreduce.Job: map 0% reduce 0%
...
2017-07-13 16:29:46,235 INFO mapreduce.Job: Job job_1499988226739_0001 completed successfully
...
Job Finished in 30.586 seconds
Estimated value of Pi is 3.14250000......
작업 상태는 Router Web UI routerhost:8089에서도 추적할 수 있습니다. federation을 사용하는 데 코드 변경이나 입력 jar 재컴파일이 필요하지 않다는 점에 유의하세요. 또한 이 작업의 출력은 federation 없이 실행했을 때와 정확히 같습니다. federation의 완전한 이점을 얻으려면 둘 이상의 클러스터가 필요하도록 충분히 많은 매퍼 수를 사용하세요. 위 예시에서 그 수는 16입니다.
테스트 Federation 클러스터 구축 (How to build a Test Federation Cluster)
이 문서의 목적은 YARN Federation 테스트 환경을 신속히 설정하도록 돕는 것입니다. 이 테스트 환경으로 YARN Federation의 핵심 기능을 사용할 수 있습니다. 필수 구성(YARN 비-HA 모드)만 있는 가장 단순한 테스트 클러스터 설정(리눅스 기반)입니다. 3대의 머신이 필요하며, 각 머신은 최소 <4C, 8GB>의 자원을 가져야 합니다. 이 문서는 YARN 구성만 다룹니다. HDFS와 ZooKeeper 구성은 다른 문서를 참고하세요.
테스트 환경 설명:
- HDFS 테스트 환경 구축, HDFS SingleCluster 참고.
- 두 YARN 클러스터 필요, 각 YARN 클러스터는 RM 1개와 NM 1개, RM과 NM은 같은 노드.
- ZK 클러스터 1개(ZooKeeper 노드 하나만 필요), ZookeeperStarted 참고.
- Router 1개와 Client 1개 필요.
머신-역할 매핑 예시(HDFS 제외):
| 머신 | 역할 |
|---|---|
| Machine A | RM1\NM1\ZK1 |
| Machine B | RM2\NM2 |
| Machine C | Router\Client |
YARN-1 (ClusterTest-Yarn1)
RM-1
ResourceManager용 구성:
<!-- YARN cluster-id -->
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>ClusterTest-Yarn1</value>
</property>
<!--
We can choose to use FairScheduler or CapacityScheduler. Different schedulers have different configuration.
FairScheduler: org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler
CapacityScheduler: org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
-->
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
<!--
This configuration option is used to specify the configuration file for FairScheduler.
If we are using CapacityScheduler, we don't need to configure this option.
-->
<property>
<name>yarn.scheduler.fair.allocation.file</name>
<value>/path/fair-scheduler.xml</value>
</property>
<!-- Enable YARN Federation mode -->
<property>
<name>yarn.federation.enabled</name>
<value>true</value>
</property>
<!-- We use ZooKeeper to query/store Federation information. -->
<property>
<name>yarn.federation.state-store.class</name>
<value>org.apache.hadoop.yarn.server.federation.store.impl.ZookeeperFederationStateStore</value>
</property>
<!-- ZK Address. -->
<property>
<name>yarn.federation.state-store.zk.address</name>
<value>zkHost:zkPort</value>
</property>
RM 시작:
$HADOOP_HOME/bin/yarn --daemon start resourcemanager
NM-1
NodeManager용 구성:
<!-- YARN cluster-id -->
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>ClusterTest-Yarn1</value>
</property>
<!-- local dir -->
<property>
<name>yarn.nodemanager.local-dirs</name>
<value>path/local</value>
</property>
<!-- log dir -->
<property>
<name>yarn.nodemanager.log-dirs</name>
<value>path/logdir</value>
</property>
<!-- Enable YARN Federation mode -->
<property>
<name>yarn.federation.enabled</name>
<value>true</value>
</property>
<!-- Disable YARN Federation FailOver -->
<property>
<name>yarn.federation.failover.enabled</name>
<value>false</value>
</property>
<!-- Enable YARN Federation Non-HA Mode -->
<property>
<name>yarn.federation.non-ha.enabled</name>
<value>true</value>
</property>
<!-- We use ZooKeeper to query/store Federation information. -->
<property>
<name>yarn.federation.state-store.class</name>
<value>org.apache.hadoop.yarn.server.federation.store.impl.ZookeeperFederationStateStore</value>
</property>
<!-- ZK Address. -->
<property>
<name>yarn.federation.state-store.zk.address</name>
<value>zkHost:zkPort</value>
</property>
<!-- Enable AmRmProxy. -->
<property>
<name>yarn.nodemanager.amrmproxy.enabled</name>
<value>true</value>
</property>
<!-- interceptors to be run at the amrmproxy -->
<property>
<name>yarn.nodemanager.amrmproxy.interceptor-class.pipeline</name>
<value>org.apache.hadoop.yarn.server.nodemanager.amrmproxy.FederationInterceptor</value>
</property>
NM 시작:
$HADOOP_HOME/bin/yarn --daemon start nodemanager
YARN-2 (ClusterTest-Yarn2)
RM-2
YARN-2 클러스터의 RM은 cluster-id를 제외하고 YARN-1의 RM과 같게 구성합니다.
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>ClusterTest-Yarn2</value>
</property>
NM-2
YARN-2 클러스터의 NM은 cluster-id를 제외하고 YARN-1의 NM과 같게 구성합니다.
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>ClusterTest-Yarn2</value>
</property>
YARN-2 클러스터 구성을 마친 뒤 YARN-2 클러스터를 시작할 수 있습니다.
Router
Router 구성:
<!-- Enable YARN Federation mode -->
<property>
<name>yarn.federation.enabled</name>
<value>true</value>
</property>
<!-- We use ZooKeeper to query/store Federation information. -->
<property>
<name>yarn.federation.state-store.class</name>
<value>org.apache.hadoop.yarn.server.federation.store.impl.ZookeeperFederationStateStore</value>
</property>
<!-- ZK Address. -->
<property>
<name>yarn.federation.state-store.zk.address</name>
<value>zkHost:zkPort</value>
</property>
<!-- Configure the FederationClientInterceptor -->
<property>
<name>yarn.router.clientrm.interceptor-class.pipeline</name>
<value>org.apache.hadoop.yarn.server.router.clientrm.FederationClientInterceptor</value>
</property>
<!-- Configure the FederationInterceptorREST -->
<property>
<name>yarn.router.webapp.interceptor-class.pipeline</name>
<value>org.apache.hadoop.yarn.server.router.webapp.FederationInterceptorREST</value>
</property>
<!-- Configure the FederationRMAdminInterceptor -->
<property>
<name>yarn.router.rmadmin.interceptor-class.pipeline</name>
<value>org.apache.hadoop.yarn.server.router.rmadmin.FederationRMAdminInterceptor</value>
</property>
Router 시작:
$HADOOP_HOME/bin/yarn --daemon start router
Yarn-Client
Yarn-Client 구성:
<!-- Enable YARN Federation mode -->
<property>
<name>yarn.federation.enabled</name>
<value>true</value>
</property>
<!-- Disable YARN Federation FailOver -->
<property>
<name>yarn.federation.failover.enabled</name>
<value>false</value>
</property>
<!-- Configure yarn.resourcemanager.address,
We need to set it to the router address -->
<property>
<name>yarn.resourcemanager.address</name>
<value>router-1-Host:8050</value>
</property>
<!-- Configure yarn.resourcemanager.admin.address,
We need to set it to the router address -->
<property>
<name>yarn.resourcemanager.admin.address</name>
<value>router-1-Host:8052</value>
</property>
<!-- Configure yarn.resourcemanager.scheduler.address,
We need to set it to the AMRMProxy address -->
<property>
<name>yarn.resourcemanager.scheduler.address</name>
<value>localhost:8049</value>
</property>
더 알아보기 (Learn more)
- 원문: 문서