Google cluster-usage trace: format, schema
Introduction
Google 클러스터는 고대역폭 클러스터 네트워크로 연결된 머신으로, 랙으로 구성되어 있습니다.
셀은 일반적으로 모든 클러스터가 하나인 컴퓨터 세트로, 공통 클러스터 관리 시스템을 공유하여 작업을 컴퓨터에 할당합니다.
작업은 하나 이상의 테스크로 구성되며 각 작업에는 테스크를 컴퓨터에 예약 (포장)하는 데 사용되는 리소스 요구 사항 집합이 수반됩니다.
각 작업은 하나의 컴퓨터에서 실행될 수있는 여러 프로세스로 구성된 Linux 프로그램을 나타냅니다.
작업 및 작업은 아래에 설명 된 수명주기에 따라 시스템에 예약됩니다.
자원 요구 사항 및 작업 사용 데이터는 셀의 관리 시스템과 셀의 개별 시스템에서 제공하는 정보에서 파생됩니다.
단일 사용 현황 추적은 일반적으로 이러한 계산 셀 중 하나에서 몇 일 간의 작업량을 나타냅니다.
추적은 여러 데이터 세트로 구성됩니다.
데이터 집합에는 일반적으로 타임 스탬프가 포함 된 기본 키로 인덱싱 된 단일 테이블이 포함됩니다.
각 데이터 세트는 압축 된 CSV 형식으로 제공되는 하나 이상의 파일 세트로 패키지됩니다. (자세한 내용은 아래를 참조하십시오.)
다운로드 및 원문은 첨부파일을 참조바랍니다.
Google cluster-usage traces format schema 2014-11-17 external.pdf
Common techniques and fields
여러 테이블에서 발생하는 필드의 표현과 의미를 설명합니다.
Obfuscation techniques
대부분의 데이터 형식에 사용되는 변환내용
- unchanged: 난독화 하지 않은 값
- hashed: 각 값은 암호화 된 해시가 갖는 포인트 값으로 변환
- rescaled: 각 값은 최소 측정값에 의해 변형되어 트레이스에 표기함, 예를 들어 모든 시스템에서 관찰된 최대 메모리 용량은 모든 메모리 요청 및 사용 값을 다시 조정하는 데 사용, 이 값은 max (1.0 / 210, max_value / 220) 단위로 반올림
- special: 몇 가지 값은 특별한 방법으로 취급
Time and timestamps
각 레코드는 트레이스 기간의 시작 전 600 초부터 마이크로 초 단위의 타임 스탬프를 가지며, 64 비트 정수로 기록 (즉, 트레이스 시작 후 20 초 후에 timestamp = 620s)
Unique identifiers
모든 작업과 모든 시스템에는 고유 한 64 비트 식별자가 지정됩니다.
이 ID는 재사용되지 않습니다. 그러나 시스템이 클러스터에서 제거되어 리턴 될 때 동일하게 유지 될 수 있습니다.
매우 드물게 동일한 작업이 중지, 재구성 및 재시작 될 때 작업 ID가 동일하게 유지 될 수 있습니다.
테스크는 작업의 작업 ID와 작업 내 0-based 색인으로 식별됩니다.
User and job names
사용자 및 작업 이름은 hash 값으로 변경되어 테스트 할 수있는 opaque 한 base64 인코딩 문자열로 제공됩니다.
User name은 Google 엔지니어 및 서비스를 나타냅니다. 동일한 User name으로 실행되는 생산 작업은 동일한 외부 또는 내부 서비스의 일부일 수 있습니다. 단일 프로그램이 여러 작업을 실행할 때마다 (예 : MapReduce 프로그램이 마스터 작업과 작업자 작업을 생성 함) 이러한 작업은 거의 항상 동일한 사용자로 실행됩니다.
Resource units
대부분의 리소스 사용량 측정 및 요청은 다음을 포함하여 표준화되었습니다.
- CPU (core count or core-seconds/second)
- memory (bytes)
- disk space (bytes)
- disk time fraction (I/O seconds/second)
각각에 대해 별도의 정규화를 계산합니다.
정규화는 트레이스의 모든 시스템에서 리소스의 최대 용량 (1.0)과 관련된 비율 조정입니다.
Data tables
아래에서는 제공될 테이블을 설명합니다.
테이블 키는 기울임 꼴입니다. 일부 키는 여러 필드로 구성됩니다.
주의 사항 : 여기에 설명된 모든 유형의 데이터가 모두 포함되는 것은 아닙니다.
열은 다른 순서로 표시되거나 여기에 표시된 것과 다른 이름을 가질 수 있습니다. 이러한 세부 정보의 최종 사양은 schema.csv 파일에서 찾을 수 있습니다.
Machines
machine events table 과 machine attributes table로 구성됩니다.
Machine events
각 machine은 machine events table의 하나 이상의 레코드로 설명됩니다.
대다수의 레코드는 추적 시작시 존재했던 시스템을 설명합니다.
- machine events table:
- timestamp
- machineID
- eventtype
- platformID
- capacity: CPU
- capacity: memory
machine events 에는 세 가지 유형이 있습니다.
- ADD (0): 머신이 클러스터에서 사용 가능하게 됨 - 트레이스의 모든 머신은 ADD 이벤트가 있습니다.
- REMOVE (1): 시스템이 클러스터에서 삭제되었습니다. 제거 또는 실패로 인해 삭제가 발생할 수 있습니다.
- UPDATE (2): 클러스터에 사용 가능한 시스템의 사용 가능한 자원이 변경되었습니다.
machine capacities는 각 치수에 따른 각 기계의 표준화 된 물리적 용량을 반영합니다.
각 치수 (CPU 코어, RAM 크기)은 독립적으로 정규화됩니다.
platform ID는 컴퓨터의 마이크로 아키텍처 및 칩셋 버전을 나타내는 opaque 한 문자열입니다.
마이크로 아키텍처 (예 : Nehalem 또는 Bulldozer와 같은 공급 업체 칩 코드 이름)와 메모리 기술 (예 : DDR2 대 DDR)의 서로 다른 조합은 플랫폼 ID가 서로 다릅니다.
동일한 플랫폼 ID를 가진 두 대의 기계는 실질적으로 서로 다른 클럭 속도, 메모리 속도, 코어 수 등을 가질 수 있습니다.
Machine attributes
- Machine attributes 테이블
- timestamp
- machine ID
- attribute name: an opaque string
- attribute value: either an opaque string or an integer
- attribute delete: a boolean indicating whether the attribute was deleted
machine attributes은 커널 버전, 클럭 속도, 외부 IP 주소의 존재 여부와 같은 machine properties를 나타내는 key - value 쌍입니다.
테스크는 machine attribues에 대한 제한 조건을 지정할 수 있습니다.
Jobs and tasks
- Jobs and tasks 는 다음과 같이 구성됩니다:
- Job events table
- Task events table
- Task constraints table
두 이벤트 테이블은 작업 / 태스크 및 해당 라이프 사이클을 설명합니다.
constraints (제약 조건) 테이블은 작업을 예약 할 수있는 컴퓨터를 제한하는 작업 배치 제약 조건을 설명합니다.
일반적으로 작업 내의 모든 작업은 동일한 옵션과 자원 요청을 사용하여 정확하게 동일한 바이너리를 실행합니다.
서로 다른 자원 요구 사항에 대한 여러 유형의 테스크를 실행해야하는 프로그램은 적으로 여러 작업으로 실행됩니다.
예를 들어, MapReduce는 별도의 작업으로 마스터와 작업자를 실행합니다.
Job and task life cycles and event types
각 작업 및 테스크 이벤트에는 이벤트 유형을 나타내는 값이 있습니다. 이벤트 이후의 작업 또는 테스크 상태는이 이벤트 유형에서 항상 판별 될 수 있습니다. 이벤트 (전환) 코드는 다음과 같습니다.
- SUBMIT (0) : 테스크 또는 작업이 스케줄링에 적합하게 되었습니다.
- SCHEDULE (1) : 테스크 또는 작업이 시스템에서 예약되었습니다.
- EVICT (2) : 우선 순위가 높은 테스크 또는 작업으로 인해 테스크 또는 작업이 일정을 보류했으나, 스케줄러가 과도하게 커밋되어 실제 시스템이 실행중인 시스템을 사용할 수 없게되거나 (예 : 복구를 위해 오프라인으로 전환) 또는 테스크 데이터를 보유한 디스크가 손실 되었기 때문에 실제 수요가 시스템 용량을 초과했기 때문입니다.
- FAIL (3) : 테스크 실패로 인해 테스크 또는 작업이 예정 취소되었습니다 (드물 긴하지만 대기중인 동안 예약 할 자격이 없어짐).
- FINISH (4) : 테스크 또는 작업이 정상적으로 완료되었습니다.
- KILL (5) : 테스크 또는 작업이 사용자 또는 드라이버 프로그램에 의해 취소되었거나 이 작업이 종속 된 다른 테스크 또는 작업이 사망했습니다.
- LOST (6) : 테스크 또는 작업이 아마도 종료되었지만 그 테스크 또는 작업을 나타내는 기록 종료 데이터가 소스 데이터에서 누락되었습니다.
- UPDATE_PENDING (7) : 테스크 또는 작업의 스케줄링 클래스, 자원 요구 사항 또는 제약 조건이 업데이트되기를 기다리는 동안 업데이트 되었습니다.
- UPDATE_RUNNING (8) : 테스크 또는 작업의 스케줄링 클래스, 자원 요구 사항 또는 제약 조건은 예정된 동안 업데이트 되었습니다.
Missing event records
우리의 데이터 소스에는 작업 및 작업 변경의 time-series과 테스크 및 작업 상태의 주기적인 스냅 샷이 모두 포함되어 있으므로 이들 간의 일관성을 확인할 수 있습니다. 이벤트 기록이 누락 된 것으로 보이는 경우 대체품을 합성합니다. 마찬가지로 추적 time-window 끝 부분에서 활성화 된 모든 테스크 또는 작업의 레코드를 찾고 찾지 못한 경우 누락 된 레코드를 합성합니다.
- SNAPSHOT_BUT_NO_TRANSITION (0) : 주어진 이벤트를 나타내는 레코드를 찾지 못했지만 작업 또는 태스크 상태의 이후 스냅 샷이 전환이 발생했음을 나타냅니다. 합성 이벤트의 시간 소인은 스냅 샷의 timestamp 입니다.
- NO_SNAPSHOT_OR_TRANSITION (1) : 주어진 종료 이벤트를 나타내는 레코드를 찾지 못했지만 작업 또는 테스크가 클러스터 상태의 최신 스냅 샷에서 사라져서 종료되어야 합니다. 합성 이벤트의 timestamp는 하나의 스냅 샷에서 누락되었다고 가정 할 때 실제 종료 시간에 대한 상한선입니다.
- EXISTS_BUT_NO_CREATION (2) : 주어진 테스크 또는 작업의 생성을 나타내는 레코드를 찾지 못했습니다. 이 경우 테스크 또는 작업에 대한 메타 데이터 (작업 이름, 자원 요청 등)가 누락되었을 수 있으며 실제로 SCHEDULE 또는 SUBMIT 이벤트를 실제로 배치 한 것보다 나중에 처리 할 수 있습니다.
Job events table
- timestamp
- missing info
- job ID
- event type
- user name
- scheduling class
- job name
- logical job name
작업 / 테스크 이벤트 테이블에는 활성 (RUNNING) 또는 실행 자격이 있지만 트레이스의 어느 지점에서나 스케줄링 대기 중 (PENDING)하는 모든 작업이 포함됩니다. 트레이스의 모든 작업에 대해 모든 작업에 대해 적어도 하나의 레코드가 포함됩니다. 여기에는 스케줄링 제약 조건이 포함됩니다.
스케줄링 클래스는 하나의 숫자로 표현되며 3은 대기 시간에 민감한 작업 (예 : 수익 창출 사용자 요청 제공)을 나타내며 0은 비 생산 작업 (예 : 개발, 비 핵심 업무 분석 등)을 나타냅니다. )
Task events table
- timestamp
- missing info
- job ID
- task index -with in the job
- machine ID
- event type
- user name
- scheduling class
- priority
- resource request for CPU cores
- resource request for RAM
- resource request for local disk space
- different-machine constraint
각 작업에는 우선 순위가 가장 낮은 (중요도가 가장 낮은) 값이 0 인 정렬 된 값 집합으로 여기에 매핑되는 작은 정수가 포함됩니다. 우선 순위 번호가 큰 작업은 우선 순위 번호가 작은 작업보다 리소스 우선 순위가 높습니다.
특별한 우선 순위 범위가 있습니다 :
* “free”우선 순위 : 가장 낮은 우선 순위입니다. 이러한 우선 순위에서 요청 된 리소스는 내부 요금이 거의 청구되지 않습니다.
* “production”우선 순위 : 우선 순위가 가장 높습니다. 클러스터 스케줄러는 이러한 우선 순위의 대기 시간에 민감한 작업이 시스템 자원의 과도한 할당으로 인해 제거되지 않도록 시도합니다.
* “monitoring”우선 순위 :이 우선 순위는 다른 우선 순위가 낮은 작업의 상태를 모니터링하는 작업을 대상으로합니다
different-machine constraint 필드가 있고 true 이면 작업에서 현재 실행중인 다른 작업과 다른 시스템에서 실행되도록 작업을 예약해야 함을 나타냅니다. 특수한 제약 조건입니다.
resource request 는 테스크가 사용할 수있는 CPU, 메모리 또는 디스크 공간의 최대 크기를 나타냅니다 (limit). 제한을 초과하여 사용하는 작업은 CPU와 같은 리소스에 대해 제한되거나 메모리와 같은 리소스에 대해 제한 될 수 있습니다. 스케줄러는 시스템의 리소스를 지나치게 커밋 할 수 있습니다. 결과적으로, 각 테스크가 제한보다 적게 사용하더라도 테스크의 모든 런타임 요청을 충족시킬 수있는 자원이 충분하지 않을 수 있습니다. 이 경우 하나 이상의 우선 순위가 낮은 작업이 중지 될 수 있습니다.
또한 런타임 환경에서 태스크가 요청보다 많은 것을 사용하는 경우도 있습니다. 예를 들어 작업은 시스템에서 사용 가능한 CPU 용량을 사용할 수 있으므로 대기 시간이 중요하지 않은 CPU 버스트가있는 작업은 요청 된 CPU 할당이 0 일 때 유용하게 실행될 수 있습니다.
Task constraints
테스크는 0 개 이상의 테스크 배치 제약 조건이 있어 테스크를 실행할 수있는 컴퓨터를 제한합니다. 각 제한 조건 레코드는 정확히 하나의 테스크 이벤트 레코드에 해당합니다.
- timestamp
- job ID
- task index
- attribute name - corresponds to machine attribute table
- attribute value - either an opaque string or an integer or the empty string
- comparison operator
비교 연산자는 다음과 같습니다.
- LESS THAN (2), GREATER THAN (3) : machine attribute 를 정수 (또는 속성이없는 경우 0)로 표시 한 다음 제공된 속성 값과 비교하십시오. 이러한 비교는 엄격합니다.
- EQUAL (0), NOT EQUAL (1) : machine attribute 를 문자열 (또는 존재하지 않으면 빈 문자열)로 표시 한 다음 제공된 속성 값과 비교하십시오.
Task usage
우리 클러스터는 리소스 격리 및 사용 통계를 위해 Linux 컨테이너를 사용합니다. 각 테스크는 자체 컨테이너 내에서 실행되며 해당 컨테이너에 여러 프로세스를 만들 수 있습니다.
일반적으로 5 분 (300 초) 인 각 측정 기간의 사용 값을 보고 합니다. 단, 일부 측정 레코드의 기간이 짧아 지는데, 일반적으로 작업이 해당 기간 내에 업데이트 되기 때문입니다. 작업이 종료되면 작업이 종료 된 후 측정 시간이 최대 수십 초까지 연장되고 작업이 종료 된 후 몇 분의 측정 기록이 연장됩니다.
시스템 부하로 인해 리소스 정보가 원하는 속도로 샘플링되지 못하는 경우가 있기는하지만 각 측정 기간 내에서 측정은 일반적으로 1 초 간격으로 수행되므로 측정 시간이 1 초를 넘을 수 있습니다. 이러한 사례를 확인하는 데 도움이되도록 우리는 예상 샘플 수 (예 : 300 초 측정 윈도우 300 개)와 관찰 샘플 수 사이의 비율 인 충분한 부분 (즉, 증폭률)을 제공합니다.
1 초 샘플은 각 측정 기간의 길이에 걸쳐 집계되어 측정 기간의 평균값과 해당 기간의 1 초 샘플에서 볼 수있는 최대 값을 제공합니다.
경우에 따라 컨테이너의 총 가치는 여러 하위 컨테이너에서 얻은 측정 값으로 구성됩니다. 각 하위 컨테이너의 최대 사용량을 알고 있지만 측정 시스템에서 외부 컨테이너의 실제 최대 값을보고하지 못할 수 있습니다. 이 경우보고하는 최대 값은 하위 컨테이너의 최대 값 합계이며이 방식으로 최대 사용량 집계 된 레코드는 집계 유형 마커 1로 표시됩니다. 다른 모든 레코드의 집계 유형은 0입니다. 또한 평균 사용 측정에 사용량이 포함되어 있어도 모든 하위 컨테이너에 대해 최대 값을 가질 수 없습니다
측정 기록이 누락되었을 수 있습니다. 누락 된 레코드가 반드시 작업이 실행 중이 아님을 나타내지는 않습니다.
태스크에 속한 프로세스가 태스크 컨테이너에서 실행 중이 지 않은 기간에 대한 일부 태스크 사용 측정이 있습니다. 예를 들어, 바이너리가 시스템에 복사되는 동안 이러한 측정이 발생할 수 있습니다. 이 경우 작업의 메모리, CPU 및 디스크 사용량은 합법적으로 0 일 수 있습니다. 경우에 따라 작업이 오랜 기간 동안 프로세스없이 실행될 수 있습니다.
- start time of the measurement period
- end time of the measurement period
- job ID
- task index
- machine ID
- mean CPU usage rate
- canonical memory usage
- assigned memory usage
- unmapped page cache memory usage
- total page cache memory usage
- maximum memory usage
- mean disk I/O time
- mean local disk space used
- maximum CPU usage
- maximum disk IO time
- cycles per instruction (CPI)
- memory accesses per instruction (MAI)
- sample portion
- aggregation type (1 if maximums from subcontainers were summed)
- sampled CPU usage: mean CPU usage during a random 1s sample in the
measurement period (only in v2.1 and later)
CPU 사용률 (CPU 속도라고도 함)은 초당 CPU 코어 초 단위로 측정됩니다. 작업이 항상 두 개의 코어를 사용하는 경우 2.0 코어 -s / s의 사용으로 반영됩니다.
메모리 격리는 Linux 컨테이너를 통해 이루어지기 때문에 작업 대신 커널 메모리 사용이 고려됩니다. 작업은 그러한 할당을 포함 할만큼 충분한 메모리를 요청해야합니다. 다음과 같은 메모리 사용 데이터가 포함되어 있습니다.
- memory usage : 정식 메모리 사용량 측정; 페이지 캐시를 포함하여 사용자가 액세스 할 수있는 페이지의 수는 부실 페이지로 표시됩니다.
- unmapped page cache memory : 사용자 공간 프로세스에 매핑되지 않은 Linux 페이지 캐시 (파일 기반 메모리).
- page cache memory : 총 Linux 페이지 캐시 (파일 기반 메모리)
- assigned memory : 컨테이너에 실제로 할당 된 메모리를 기반으로 한 메모리 사용량 (반드시 사용해야하는 것은 아님)
- maximum memory usage : 측정 간격 동안 관찰 된 표준 메모리 사용량 측정의 최대 값. 일부 작업에서는이 값을 사용할 수 없습니다.
디스크 I / O 시간은 Linux 컨테이너의 blkio 서브 시스템을 사용하여 측정됩니다. 사용량 측정은 초당 디스크 시간 초의 단위로 시스템의 모든 디스크에 걸친 합계입니다.
이 추적에 기록 된 디스크 공간은 런타임 로컬 디스크 용량 사용을 나타냅니다. 바이너리 및 기타 읽기 전용 사전 스테이지 런타임 파일에 필요한 디스크 사용량은 포함되지 않습니다. 또한 분산 된 영구 저장소 (예 : GFS, 거상)가 사용하는 대부분의 디스크 공간은이 추적에서 차지하지 않습니다.
CPI 및 MAI 통계는 프로세서 성능 카운터에서 수집됩니다. 메모리 액세스는 마지막 레벨 캐시 미스의 측정을 기반으로합니다.