클러스터 스케줄링 시스템의 진화
쿠버네티스는 컨테이너 오케스트레이션 영역에서 사실상 표준이 되었다. 모든 애플리케이션은 향후 쿠버네티스에서 개발되고 실행될 것이다. 이 기사 시리즈의 목적은 쿠버네티스의 기본 구현 원칙을 심오하고 간단한 방법으로 소개하는 것이다.
쿠버네티스는 클러스터 스케줄링 시스템이다. 이 기사는 주로 쿠버네티스의 이전 클러스터 스케줄링 시스템 아키텍처를 소개한다. 그들의 디자인 아이디어와 아키텍처 특성을 분석함으로써 클러스터 스케줄링 시스템 아키텍처의 진화 과정과 아키텍처 디자인에서 고려해야 할 주요 문제를 연구 할 수 있습니다. 이는 쿠버네티스 아키텍처를 이해하는 데 매우 도움이 될 것이다.
우리는 분명히하기 위해,클러스터 스케줄링 시스템의 기본 개념 중 일부를 이해할 필요가,나는 예를 통해 개념을 설명의 우리가 분산 크론을 구현하고자한다고 가정 할 것이다. 이 시스템은 리눅스 호스트 세트를 관리합니다. 사용자는 시스템에서 제공하는 작업을 통해 작업을 정의합니다. 시스템은 작업 정의를 기반으로 해당 작업을 주기적으로 수행합니다.이 예에서는 기본 개념이 아래에 있습니다:
- 클러스터:이 시스템에서 관리하는 리눅스 호스트는 작업을 실행할 리소스 풀을 형성합니다. 이 리소스 풀을 클러스터라고 합니다.
- 작업:클러스터가 작업을 수행하는 방법을 정의합니다. 이 예에서 크론탭은 정확히 어떤 시간(시간 간격)에 수행해야 할 작업(실행 스크립트)을 명확하게 보여주는 간단한 작업입니다.일부 작업의 정의는 여러 작업에서 완료할 작업의 정의,작업 간의 종속성 및 각 작업의 리소스 요구 사항과 같이 더 복잡합니다.
- 작업:작업을 특정 성능 작업으로 예약해야 합니다. 매일 밤 오전 1 시에 스크립트를 수행하는 작업을 정의하면 매일 오전 1 시에 수행되는 스크립트 프로세스가 작업입니다.
클러스터 스케줄링 시스템을 설계 할 때 시스템의 핵심 작업은 두 가지입니다:
- 작업 예약: 클러스터 스케줄링 시스템에 작업을 전송한 후에는 제출된 작업을 특정 실행 작업으로 나누어야 하며 작업의 실행 결과를 추적 및 모니터링해야 합니다. 분산 크론의 예에서,스케줄링 시스템은 적시에 동작의 요구 사항에 따라 프로세스를 시작할 필요가있다. 프로세스가 수행되지 않으면 재시도가 필요합니다. 이러한 하둡지도와 같은 일부 복잡한 시나리오가 감소,스케줄링 시스템은지도가 대응하는 여러 맵으로 작업을 줄이고 작업을 줄이고,궁극적으로 작업 실행 결과 데이터를 얻을 분할 할 필요가있다.
- 리소스 스케줄링:기본적으로 태스크 및 리소스를 일치시키는 데 사용되며 클러스터에 있는 호스트의 리소스 사용에 따라 태스크를 실행하기 위해 적절한 리소스가 할당됩니다. 이는 운영체제의 스케줄링 알고리즘의 프로세스와 유사하며,자원 스케줄링의 주요 목표는 자원의 고정된 공급 조건 하에서 가능한 한 자원 이용률을 향상시키고 태스크의 대기 시간을 감소시키고,태스크 또는 응답 시간의 지연을 감소시키는 것이다(일괄 태스크인 경우,태스크 작업의 시작부터 끝까지의 시간을 가리키며,웹 애플리케이션과 같은 온라인 응답 타입 태스크인 경우,요청에 대한 각각의 응답 시간을 가리킨다). 가능한(자원은 모든 작업에 공정하게 할당됩니다). 이러한 목표 중 일부는 상충되며 자원 활용,응답 시간,공정성 및 우선 순위와 같이 균형을 유지해야합니다.
맵 축소는 병렬 컴퓨팅 모델의 일종이다. 하둡은 병렬 컴퓨팅 클러스터 관리 플랫폼의 종류를 실행할 수 있습니다. 지도의 첫 번째 세대 버전은 하둡 플랫폼의 작업 스케줄링 엔진을 줄일 수 있습니다. 사용자가 계산을 줄이고 하둡에 제출 맵을 정의 할 때 즉,클러스터에서 작업을 예약 및 실행을 담당하고,계산 결과로 돌아갑니다. 여기에 다음과 같은 아키텍처가 있습니다:
- 작업 추적기는 리소스 스케줄링과 작업 스케줄링을 모두 담당하는 클러스터의 주요 관리 구성 요소입니다.
- 작업 추적기는 호스트에서 특정 작업을 실행하고 상태를 보고하는 역할을 하는 클러스터의 각 컴퓨터에서 실행됩니다.
하둡의 인기와 다양한 요구의 증가로 다음과 같은 문제가 개선 될 수있다:
- 성능에 특정 병목 현상이 있습니다: 관리를 지원하는 최대 노드 수는 5,000 개이며 지원 작업의 최대 작업 수는 40,000 개입니다. 여전히 개선의 여지가 있습니다.
- 다른 작업 유형을 확장하거나 지원할 만큼 유연하지 않습니다. 하둡 생태계에는 스파크,하이브,하이베이스,스톰,우지 등과 같이 예약해야 하는 다른 많은 작업 유형이 있습니다. 따라서 더 많은 작업 유형을 지원하고 확장 할 수있는보다 일반적인 스케줄링 시스템이 필요합니다
- 낮은 리소스 사용률: 각 노드에 대해 고정된 수의 슬롯을 정적으로 구성하며,각 슬롯은 특정 작업 유형(매핑 또는 축소)에 대해서만 사용할 수 있으므로 리소스 사용 문제가 발생합니다. 예를 들어,많은 수의 맵 작업이 유휴 리소스에 대해 대기하고 있지만 실제로는 많은 수의 축소 슬롯이 컴퓨터에 대해 유휴 상태입니다.
- 다중 테넌시 및 다중 버전 문제. 예를 들어 서로 다른 부서에서 동일한 클러스터에서 작업을 실행하지만 논리적으로 서로 격리되거나 동일한 클러스터에서 서로 다른 버전의 하둡을 실행합니다.
원사
원사(또 다른 자원 협상은)하둡의 2 세대,주요 목적은 모든 종류의 문제를 해결하는 것입니다. 원사 아키텍처는 다음과 같습니다:
- : 그것은 자원 스케줄링에 대한 책임,모든 자원을 관리,작업의 다른 유형에 자원을 할당,쉽게 플러그 아키텍처를 통해 자원 스케줄링 알고리즘을 확장.
- 응용 프로그램 마스터:작업 스케줄링을 담당합니다. 각 작업(원사의 응용 프로그램이라고 함)은 해당 응용 프로그램 마스터를 시작합니다.이 응용 프로그램은 작업을 특정 작업으로 분할하고 리소스 관리자에서 리소스를 신청하고 작업을 시작하고 작업 상태를 추적하고 결과를 보고합니다.
- 작업 추적기의 원래 작업 스케줄링 책임을 분할하고,상당한 성능 향상의 결과. 원래 작업 추적기의 작업 스케줄링 책임은 응용 프로그램 마스터에 의해 수행되도록 분할되고 응용 프로그램 마스터가 배포되었으며 각 인스턴스는 한 작업의 요청 만 처리하여 최대 클러스터 노드 수를 5,000 개에서 10,000 개로 승격했습니다.
- 작업 스케줄링,응용 프로그램 마스터 및 리소스 스케줄링의 구성 요소는 분리되고 작업 요청에 따라 동적으로 생성됩니다. 하나의 응용 프로그램 마스터 인스턴스는 하나의 예약 작업만 담당하므로 다양한 유형의 작업을 보다 쉽게 지원할 수 있습니다.
- 컨테이너 격리 기술이 도입되어 각 작업이 격리 된 컨테이너에서 실행되므로 동적으로 할당 할 수있는 리소스에 대한 작업의 요구에 따라 리소스 활용도가 크게 향상됩니다. 이것의 단점은 원사의 리소스 관리 및 할당은 하나의 메모리 차원 만 가지고 있다는 것입니다.
메소 아키텍처
원사의 설계 목표는 여전히 하둡 생태계의 스케줄링을 제공하는 것입니다. 메소의 목표는 전체 데이터 센터의 동작을 관리 할 수있는 일반적인 스케줄링 시스템이 될 수 있도록 설계,가까이 가져옵니다. 우리가 보는 바와 같이,메소의 건축 설계는 참조 용 원사를 많이 사용,작업 스케줄링 및 자원 스케줄링은 별도로 다른 모듈에 의해 부담된다. 그러나 메소와 원사 사이의 가장 큰 차이점은 자원에 대한 스케줄링 방법,자원 제공이라는 고유 한 메커니즘이 설계되었습니다. 리소스 스케줄링의 압력이 추가로 해제되고 작업 스케줄링 확장성도 증가합니다.
메소의 주요 콤포넌트는 입니다:
- 메소 마스터:그것은 내부 원사에 대응하는 자원 관리자 자원 할당 및 관리의 구성 요소에 대한 책임은 전적으로 구성 요소입니다. 그러나 작동 모드는 나중에 논의 될 경우 약간 다릅니다.
- 프레임 워크:작업 스케줄링에 대한 책임,다른 작업 유형은 스파크 작업을 담당하는 스파크 프레임 워크와 같은 해당 프레임 워크를해야합니다.
메소의 자원 제공
그것은 메소와 원사 아키텍처처럼 보일 수 있습니다 사실,자원 관리의 측면에서,메소의 마스터는 매우 독특한(다소 기괴한)자원 제공 메커니즘을 가지고,매우 유사하지만:
- 털실은 잡아당기기입니다: 자원(응용 프로그램 마스터)의 소비자가 자원을 필요로 할 때 원사 자원 관리자에 의해 제공되는 자원은 자원을 얻기 위해 자원 관리자의 인터페이스를 호출 할 수 있으며,자원 관리자는 수동적으로 응용 프로그램 마스터의 요구에 응답,수동이다.
- 메소 푸시:메소 마스터가 제공하는 리소스는 사전이다. 메소의 마스터는 정기적으로 프레임 워크(소위 자원 제공,나는 지금부터 제공 호출합니다)현재 사용 가능한 모든 자원을 밀어 주도권을 쥐고 것입니다. 프레임워크에서 수행할 작업이 있는 경우 오퍼가 수신되지 않는 한 리소스를 적극적으로 적용할 수 없습니다. 프레임 워크는 수락 제안에서 자격을 갖춘 자원을 선택(이 운동은 메소에 동의라고,)나머지 이벤트를 거부(이 운동은 거부라고). 이 제안 라운드에서 충분한 자격을 갖춘 자원이없는 경우,우리는 제안을 제공하기 위해 마스터의 다음 라운드를 기다려야합니다.
나는 당신이이 활성 제공 메커니즘을 볼 때,당신은 나와 같은 느낌을 가질 것이라고 믿는다. 즉,효율이 상대적으로 낮고 다음과 같은 문제가 발생할 것입니다:
- 모든 프레임 워크의 의사 결정 효율성은 전반적인 효율성에 영향을 미칩니다. 일관성을 위해 마스터는 한 번에 하나의 프레임 워크에만 오퍼를 제공하고 나머지 프레임 워크를 다음 프레임 워크에 제공하기 전에 프레임 워크가 오퍼를 선택할 때까지 기다릴 수 있습니다. 이러한 방식으로 모든 프레임 워크의 의사 결정 효율은 전반적인 효율성에 영향을 미칩니다.
- 자원을 필요로하지 않는 프레임 워크에 많은 시간을”낭비”합니다. 메소 정말 자원을 필요로하는 프레임 워크를 알 수 없습니다. 그래서 자원 요구 사항과 프레임 워크가 오퍼 큐에있을 것입니다,하지만 자원 요구 사항이없는 프레임 워크는 자주 오퍼를받습니다.
위의 문제에 대한 응답으로,메소는 프레임 워크가 결정을 내리는 시간 제한을 설정하거나 프레임 워크가 억제 상태로 설정하여 제안을 거부 할 수 있도록하는 등의 문제를 완화하기위한 몇 가지 메커니즘을 제공했습니다. 이 토론의 초점이 아니기 때문에 세부 사항은 여기에서 무시됩니다.
사실,활성 제공이 메커니즘을 사용하여 메소에 대한 몇 가지 분명한 장점이있다:
- 성능이 분명히 향상되었습니다. 클러스터는 최대 100,000 개의 노드를 지원할 수 있습니다 시뮬레이션 테스트에 따르면 트위터의 프로덕션 환경에서 가장 큰 클러스터는 80,000 개의 노드를 지원할 수 있습니다. 주된 이유는 메소 마스터 메커니즘의 활성 제공이 더 메소의 책임을 단순화한다는 것입니다. 자원 스케줄링 프로세스,자원 매칭을 작업,메소에서 두 단계로 나누어 져 있습니다:자원을 제공하고,작업을 제공합니다. 메소 마스터는 첫 번째 단계를 완료하는 데만 책임이 있으며 두 번째 단계의 일치는 프레임 워크에 남아 있습니다.
- 보다 유연하고 작업 스케줄링의보다 책임있는 정책을 충족 할 수 있습니다. 예를 들어,전체 또는 아무것도의 리소스 사용 전략.
메소디자인프로젝트의 스케줄링 알고리즘(지배적인 자원 공정성)
메소디자인프로젝트의 스케줄링 알고리즘은 사실 메소 아키텍처에 대한 우리의 이해와는 아무 상관이 없지만 메소에서는 매우 핵심이며 중요하므로 여기서 좀 더 설명하겠습니다.
위에서 언급 한 바와 같이,메소는 차례로 프레임 워크에 제안을 제공합니다,그래서 어떤 프레임 워크가 제공 할 때마다 제공하기 위해 선택되어야한다? 이 알고리즘에 의해 해결 될 핵심 문제입니다. 기본 원칙은 공정성과 효율성을 모두 고려하는 것입니다. 프레임 워크의 모든 리소스 요구 사항을 충족하면서 하나의 프레임 워크가 너무 많은 리소스를 소비하고 다른 프레임 워크를 굶어 죽지 않도록 가능한 한 공정해야합니다.
최소-최대 공정성 알고리즘의 변형이다. 간단히 말해서,그것은 제안을 매번 제공하기 위하여 가장 낮은 지배적인 자원 사용량에 기구를 선정하기 위한 것이다. 어떻게 프레임 워크의 지배적 인 자원 사용을 계산하는 방법? 프레임워크가 차지하는 모든 리소스 유형에서 리소스 점유율이 가장 낮은 리소스 유형이 주요 리소스로 선택됩니다. 그것의 자원 점령 비율은 정확하게 프레임 워크의 지배적 인 자원 사용량입니다. 예를 들어,프레임 워크는 전체 리소스의 20%,메모리의 30%및 디스크의 10%를 차지합니다. 따라서 프레임 워크의 지배적 인 리소스 사용은 10%가 될 것이고,공식 용어는 디스크를 지배적 인 리소스라고 부르며,이 10%를 지배적 인 리소스 사용이라고합니다.
자원봉사자의 궁극적인 목표는 모든 프레임워크에 자원을 동등하게 분배하는 것이다. 만약 프레임워크가 이번 오퍼 라운드에서 너무 많은 리소스를 수용한다면,다음 오퍼 라운드의 기회를 얻는 데 훨씬 더 오래 걸릴 것입니다. 그러나 신중한 독자는이 알고리즘에 가정이 있다는 것을 알게 될 것입니다.이 알고리즘에는 프레임 워크가 리소스를 수락 한 후 신속하게 릴리스 할 것이며 그렇지 않으면 두 가지 결과가 발생할 것입니다:
- 다른 프레임 워크는 굶어 죽습니다. 하나의 프레임워크는 클러스터의 대부분의 리소스를 한 번에 수용하며,작업은 종료하지 않고 계속 실행되므로 대부분의 리소스가 항상 프레임워크에 의해 점유되고 다른 프레임워크는 더 이상 리소스를 얻지 않습니다.
- 굶어 죽어라. 이 프레임 워크의 지배적 인 자원 사용량이 항상 매우 높기 때문에 오랜 시간 동안 제안을 얻을 기회가 없으므로 더 많은 작업을 실행할 수 없습니다.
따라서 메소는 짧은 작업을 예약하는 데만 적합하며 메소는 원래 데이터 센터의 짧은 작업을 위해 설계되었습니다.
요약
대형 아키텍처에서 모든 스케줄링 시스템 아키텍처는 마스터/슬레이브 아키텍처이며,슬레이브 엔드는 호스트 정보를 수집하고 호스트에서 작업을 수행하는 데 사용되는 관리 요구 사항이있는 각 시스템에 설치됩니다. 마스터는 주로 리소스 스케줄링 및 작업 스케줄링을 담당합니다. 리소스 스케줄링은 성능에 대한 요구 사항이 더 높고 작업 스케줄링은 확장성에 대한 요구 사항이 더 높습니다. 일반적인 경향은 의무의 두 종류의 디커플을 논의하고 다른 구성 요소에 의해 그들을 완료하는 것입니다.
