스케줄러의 선택 기준 리스트

Grid in action: 리소스 매니저 관리하기

리소스 매니저를 관리하는 또 하나의 방법, 그리드 메타-스케줄러

  

  문서 옵션

   이 페이지를 이메일로 보내기

난이도 : 초급

Jeff Mausolf, IT Architect, IBM Global Services, Global Technology Center, Grid Computing Initiative

2005 년 7 월 12 일

그리드 시스템으로 리소스 매니저는 로컬 리소스들을 관리한다. 그렇다면, 리소스 매니저는 어떻게 관리하는가? 이 글에서 매니저 계층의 감독자 역할을 하는 메타-스케줄러를 소개하고, 리소스 매니저들의 워크로드 균형을 잡는 방법을 설명한다. 자신의 그리드 프로젝트에 맞는 최상의 메타-스케줄러를 선택하는 기준도 설명한다.

오래 전부터, 부서는 애플리케이션용 플랫폼을 구매했고, 쟁점 요구 사항들을 지원하기 위해 리소스들을 구매했다. 이러한 리소스들간 워크로드를 효율적으로 분배하기 위해서 리소스 매니저가 사용되곤 했다. 리소스 매니저에게 작업이 제출된다. 사전 정의된 스케줄링 정책과 현재의 리소스 가용성을 기준으로 리소스들 간 작업들이 스케줄링 된다.

시간이 흐르면서 부분화 된 리소스의 포켓들이 쌓여갔다. 이 포켓들은 가끔은 사용빈도가 저조했고, 가끔은 피크(peak) 로드를 핸들 할 만큼의 리소스가 부족했다. 다른 부서들도 비슷한 현상을 보였다.

만약, 각 부서마다 충분한 리소스가 있어서 매일의 워크로드를 감당할 수 있다면? 피크 타임 동안, 밀려드는 요청에 부응할 추가 리소스를 제공하거나 현재 리소스들을 엔터프라이즈 내 사용되지 않는 리소스들로 보충할 능력을 갖게 될 것이다. 이로서 전체적으로 리소스 활용률이 높아지게 될 것이다. 바로 이것이 그리드 컴퓨팅의 목표 중 하나이다.

리소스 매니저가 리소스를 관리하는 일을 한다는 것은 두말할 필요도 없다. 그리드는 리소스 매니저들의 컬렉션과 리소스들로 구성된다. 어떻게 하면 매니저들이 함께 작동하도록 할 수 있을까? 그리드 메타-스케줄러를 보자. 메타-스케줄러는 리소스 매니저들의 컬렉션을 통해 워크로드의 균형을 맞추면서 클러스터나 스케줄러 계층을 효율적으로 만들어 낸다. 메타-스케줄러는 여러 리소스 매니저들간 통신을 조정하면서 비즈니스 정책에 따라 운영하며 서비스 레벨 계약을 실행하고 리소스 매니저들이 로컬 리소스들을 통해 작업을 효율적으로 수행할 수 있도록 한다.

이 글에서는 자신의 필요에 맞는 메타-스케줄러를 선택하기 위해 그리드 프로젝트의 특성을 평가할 때 생각해야 할 체크리스트를 마련하였다. 개별 메타-스케줄러를 평가할 때 사용할 질문 리스트와 다양한 평가 항목들도 자세히 검토할 것이다.

그리드에서 메타-스케줄러의 자리

그리드 컴퓨팅의 또 다른 목적은 가상화를 통해 복잡함 속에서 사용자를 분리하는 것이다.

많은 사용자들이 리소스 매니저에게 작업을 제출한다. 여러 리소스 매니저들이 존재한다면 이들은 각각 로그인을 하여 작업 큐를 보고 어디에서 작업이 먼저 실행될지를 결정한다. 이때 사용자들은 가장 짧은 작업 큐를 가진 리소스 매니저에게 직접 제출한다. 사용자들은 다양한 시스템에 계정을 갖고 있어야 하고 다양한 리소스 매니저들을 통해 작업을 제출, 모니터, 제어하는 방법을 알고 있어야 한다.

메타-스케줄러를 가진 전산 그리드는 사용자들이 통일된 방식으로 작업을 제출할 수 있는 하나의 시스템으로 인증 받도록 하여 이러한 부담을 덜어준다. 시스템은 비즈니스 정책을 준수하고 서비스 레벨 계약(SLA)을 유지하면서 가장 짧은 시간 안에 작업을 완수할 수 있는 장소를 결정한다.

그리드는 리소스 매니저들이 그들의 리소스를 지속적으로 관리할 수 있도록 하고, 리소스 매니저에 대한 워크로드를 관리하는 메타-스케줄러를 구현한다. 메타-스케줄러는 비즈니스 정책과 관리를 받고 있는 리소스들의 피드백에 근거하여 워크로드를 효율적으로 분산시킨다. 사용자는 메타-스케줄러에게 작업을 제출하는데, 이때 메타-스케줄러는 모든 리소스 매니저들과 협업하여 현재 로드, 백로그, 작업 큐의 우선순위 등을 파악한다. 이러한 정보와, 비즈니스 정책 및 SLA에 대한 이해에 근거하여 메타-스케줄러는 지능적인 스케줄링 결정을 내린다. 또한 메타-스케줄러는 다중 리소스 매니저들의 워크로드 뿐만 아니라 다양한 유형의 리소스 매니저들을 조정하여, 다양한 부서들의 이종 리소스들의 통합에도 기여한다.

메타-스케줄러는 중앙 작업과 리소스 관리를 제공하여, 사용자들이 다양한 유형의 리소스 매니저들의 작업 제출 문법을 알지 못하더라도 작업을 제출할 수 있도록 한다.

선택 프로세스 개요

UT 그리드 프로젝트의 경우 가장 적합한 메타-스케줄러를 고르기 위해서는 여러 결정 사항들이 존재했다. 다음은 결정에 영향을 미치는 주요 기준들이다.

메타-스케줄러를 보고 캠퍼스 클러스터 상에서 실행되고 있는 리소스 매니저들과 잘 통합되지 않는 것들을 버린다.

남아있는 메타-스케줄러들의 기능을 검토하고 가장 중요한 기능을 제공하는 메타-스케줄러를 평가할 팀을 선발한다.

평가 팀의 역할은 사용 케이스를 검토하고 어떤 요구 사항들이 완전히 또는 부분적으로 충족되는지를 기록한다.

다루어지지 않았거나 부분적으로만 충족된 요구 사항에 대해서는 최선의 노력을 다해 순응하도록 하고있다.

체크리스트: 메타-스케줄러 선택하기

지금까지, 메타-스케줄러가 무엇이고 어떤 역할을 하는지를 설명했다. 이제 메타-스케줄러를 선택할 때 고려해야 할 많은 요소들을 살펴보겠다. 27 가지의 요소들은 제품 평가의 기준으로도 볼 수 있다.

다음은, 메타-스케줄러를 평가할 때 중요한 사항들 및 제품을 생산하고 관리하는 기업과 관련한 질문과 답이다.

제품 관련 질문:

메타-스케줄러와 통합되는 리소스 매니저는 무엇인가? 예: Platform LSF

어떤 플랫폼이 지원되는가? 예: 리눅스

어떤 보안 방식이 지원되는가? 예: GSI 보안

체크포인트를 지원하고 마이그레이션을 처리하는가?

글로벌 네임 스페이스는 갖고있는가?

작업 스케줄링 외에 데이터 스테이징도 조정할 수 있는가?

어떤 스케줄링 정책들이 제공되는가?

기존 정책들을 업데이트 하거나 사용자 정책을 추가하기 위한 툴이 있는가?

동적 정책 업데이트를 지원하는가?

병렬 및 직렬 작업 제출을 지원하는가?

고급 예약을 지원하는가?

동적 클라이언트를 지원하는가?

활발한 설정 변화를 지원하는가?

진단 툴을 제공하는가?

리소스 소비에 대한 평가가 제공되는가?

테스트 및 지원되는 설정은 무엇인가?

사용할 수 있는 문서 및 교육은 무엇이 있는가?

라이센스 비용은 얼마인가?

어떤 유형의 서비스를 사용할 수 있으며, 비용은 어느 정도인가?

사용자 및 관리자에게 어떤 유형의 인터페이스가 제공되는가?

기업 관련 질문:

비즈니스를 시작한지는 얼마나 되었는가?

개발, 테스트, 지원에 투입된 직원의 수는?

사무실의 위치는?

고객 레퍼런스를 갖고 있는가? 연락이 가능한가?

제품을 사용한 지는 얼마나 되는가?

설치 기반은 무엇인가?

릴리스 사이클은?

이제, 위 기준 항목들을 자세히 설명하겠다.

상세한 기준

다음 섹션에서는 위 체크리스트에 거론된 주제들을 상세하게 설명하겠다. 위 27개의 질문들에 대한 대답이 자신의 프로젝트에 맞는 메타-스케줄러를 선택하는 과정을 도와주는 툴이 되는지 알게 될 것이다.

리소스 매니저 지원

대중적인 리소스 매니저들은 다음과 같다.

Platform LSF

PBS Pro or OpenPBS

Sun Grid Engine

Condor

IBM LoadLeveler?

이미 사용하고 있는 리소스 매니저가 있다면 그 리소스 매니저와 메타-스케줄러가 얼마나 잘 통합될 수 있는지, 그리고 어떤 차원의 통합이 필요한지가 중요한 문제가 된다. 메타-스케줄러는 몇몇 리소스 매니저들과 완벽히 통합될 수 있다.

다른 경우, 직접적인 통합이 제공되지 않는다면, 메타-스케줄러는 The Globus Alliance에서 제공하는 Global Resource Allocation Manager (GRAM)를 통해 리소스 매니저에게 제출할 수 있다.

플랫폼과 체크포인트

일부 리소스 매니저들은 제한된 플랫폼에서만 지원된다. 제한된 수의 플랫폼을 지원하는 것과 그 플랫폼을 위한 소프트웨어 스택을 제어하는 것은 장점이 있다. 커널 소스 코드에 접근하여 변경과 커널 확장을 하기 때문에 체크포인트 기능 같은 향상된 기능들이 지원된다.

체크포인트와 마이그레이션을 사용하여 실행되는 작업의 상태를 저장하여 나중에, 심지어는 다른 리소스에서도 재시작 될 수 있다. 이미 수행된 전산도 소멸되지 않는다.

여러 리소스 매니저들은 애플리케이션 유형에 기반하여 체크포인트 및 재시작 기능을 제공한다. 예를 들어, MPI 작업의 체크포인트와 마이그레이션은 표준 작업의 체크포인트 보다 훨씬 복잡하다. 커널 확장에 의한 커널과의 협업을 통해서만 이루어 질 수 있다.

또한 고려해야 할 사항은 체크포인트와 마이그레이션 기능을 지원하기 위해 작업에 변경이 이루어져야 한다. 어떤 스케줄러의 경우 특정 라이브러리로 재 링크되어 체크포인트와 프로세스 마이그레이션을 지원해야 한다.

이미 스케줄링 정책이 선택되었다면 체크포인트와 프로세스 마이그레이션은 중요한 고려 사항이기 때문에 이 주제는 스케줄링 정책과 관련이 있다. 이미 정해진 스케줄링 정책에서 리소스 상에서 실행중인 우선순위가 낮은 작업은 높은 우선순위의 작업이 큐에 진입하면 선점될 것이다. 낮은 우선순위의 작업이 장기 실행 태스크라면 중요한 프로세싱이 이미 발생한 것이다. 체크포인트가 지원된다면 체크포인트는 낮은 우선순위의 작업에 대해 만들어지고 프로세스는 프로세싱을 지속할 또 다른 리소스로 마이그레이션 된다. 이것은 높은 우선순위의 태스크를 위해 리소스를 비워둔다. 체크포인트 없이 이미 수행된 전산은 소실된다.

보안

보안은 싱글사인온이 요구되는 분산 컴퓨팅 환경에서 보다 복잡한 문제이다. 싱글사인온으로 사용자들은 한번에 인증을 받고, 리소스 또는 태스크를 수행하는데 필요한 리소스들로 인증서를 전달한다.

중요한 고려사항은 메타-스케줄러가 어떤 보안 메커니즘을 지원하는가 이다. 어떤 메타-스케줄러는 기본적인 OS 보안에 의존한다. 이 경우, 사용자는 메타-스케줄러로 인증을 받는데 사용되는 것과 같은 사용자 아이디와 인증서로 목표 리소스에 대한 계정을 가져야 한다.

보다 세련된 접근 방식은 시스템들간 사용자 아이디(UID)와 그룹 아이디(GID)의 매핑을 지원하고 사용자가 다른 시스템들에 독자적 아이디를 가지도록 하는 것이다. 이 UID/GID 매핑은 사용자 인증의 전달을 지원하는 또 다른 고급 기능과 함께 사용된다. 델리게이션 방식을 통해 사용자를 대신하여 서비스들이 실행한다.

메타-스케줄러가 기존 또는 지정된 보안 메커니즘을 지원하는지 그리고 필요한 통합 레벨을 지원하는지도 고려해야 한다.

글로벌 네임 스페이스

메타-스케줄러가 할 일은 모든 가용 리소스를 통해 워크로드의 균형을 맞추는 것이다. 메타-스케줄러에 작업을 제출할 때 실행 머신은 알려지지 않는다. 작업이 인풋 파일을 요청하면 메타-스케줄러는 인풋 데이터로의 경로를 책임지고 작업이 어디에서 실행되는지에 상관없이 실행파일은 같은가?

이것은 모든 리소스들이 스토리지 영역 네트워크(SAN)에 연결되었거나 글로벌 네임 스페이스를 가지고 있을 경우이다. 하지만 이러한 경우가 아니라면 메타-스케줄러는 인풋 데이터의 스테이징과, 작업을 위해 선택된 목표 리소스에 대한 실행파일을 조정할 수 있는가?

스케줄링 정책, 메트릭스, 리포트

메타-스케줄러는 일반적으로 워크로드의 균형을 맞추고 공정한 공유 규칙을 제공하는 사전 정의된 스케줄링 정책을 갖고 있다. 하지만 정책들은 기업들 마다 현격히 다르고 조직의 비즈니스 정책을 구현하기 위해서는 개인화가 필요하다. 우선순위, 인풋 데이터, CPU 수, 메모리의 양, 디스크 공간 같은 작업 속성들을 토대로 해서, 스케줄링이 결정될 수도 있지만, 스케줄링 정책은 주로 비용과 작업 요구사항 사이에서 결정된다.

예를 들어, 특정 소프트웨어 라이센스나 고속 인터커넥션을 갖춘 상당수의 CPU를 요구하는 작업은 보다 비싼 리소스를 필요로 하고 단순한 애플리케이션 보다 실행 비용이 더 들것이다. 정책은 특정 형식의 메트릭스를 구현하게 될 것이다. 이 메트릭스는 비싼 리소스 사용에 대한 계산서로 사용될 수 있다.

메타-스케줄러가 리소스 소비에 대한 트래킹을 지원하면서 중요한 메트릭스를 포착하고 필요한 리포트를 만들어낸다면?

사용자 정책

사용자 정책이 종종 요구되기 때문에 새로운 정책이 얼마나 쉽게 구현될 수 있는지 또는 기존 정책들이 쉽게 개인화 될 수 있는지를 고려해야 한다. 새로운 정책을 구현하는 일은 GUI로 비즈니스 규칙을 정의하는 것 만큼 쉽다. 또는 스케줄링 정책이 적용되는 각 작업 큐에 적용되어야 하는 사용자 스케줄링 플러그인을 코딩 해야 한다.

정책을 정의하는 방식으로 메타-스케줄러에 의해서 변화가 포착되는 방식도 정할 수 있다. 비즈니스 규칙 변화는 런타임 시 추가될 수 있는 반면, 사용자가 개발한 스케줄러 플러그인을 추가할 때는 시스템을 재시작 해야 한다. 시스템 재시작은 대부분의 환경에서는 바람직하지 못하다.

동적 리소스

여분의 사이클을 남기는 환경에서, 리소스들은 리소스 매니저에서 동적으로 추가되거나 제거된다. 이는 또한 프로비저닝 또는 오케스트레이션이 구현될 때의 경우이다.

리소스 매니저가 리소스의 동적인 추가와 제거를 지원하는가? 리소스 매니저가 추가 리소스들을 인식하고 이것이 앞으로의 작업에 쓰일 것이라고 생각하는데 필요한 단계는? 리소스 매니저는 실패하거나 제거된 리소스들을 어떻게 핸들 할 것인가? 실패한 리소스에서 실행되는 태스크는 또 다른 리소스에 자동으로 다시 제출되는가?

고급 예약

작업 제출에 대해 이야기하면서, 이 작업이, 가장 짧은 시간 안에 작업을 완료할 수 있는 리소스에서 실행되어야 하는 것을 가정했다. 우리가 또한 고려해야 할 것은 고급 예약 기능이다. 고급 예약으로 사용자들은 미래의 어떤 시점에 사용할 리소스를 예약할 수 있다. 고급 예약이 필요할 경우, 메타-스케줄러는 고급 예약을 지원하고 그 예약 내용과 리소스를 조정할 수 있는가?

문서

개발자 가이드는 API를 개발할 때 유용하다. 다른 문서들도 중요하다. 벤더가 고급 설치 가이드, 관리 가이드, 사용자 가이드를 제공하는가? 어떤 교육자료를 사용할 수 있으며 사용자와 관리자들에게 어떤 훈련이 권장되는가?

라이센스

메타-스케줄러는 지능적인 스케줄링 결정을 위해 메타-스케줄러가 제어하고 있는 리소스에서 피드백을 얻어야 한다. 에이전트는 이 기능을 수행하고 모든 관리 리소스상에서 실행된다. 에이전트는 메타-스케줄러에 정보를 보내 지능적인 스케줄링 결정을 도모한다.

종종, 메타-스케줄러용 라이센스는 에이전트 당 가격이 책정되지만 가격과 가격 책정은 매우 달라질 수 있기 때문에 제품 벤더를 확인해야 한다.

인터페이스

또 다른 중요한 고려 사항으로 인터페이스가 있다. 예를 들어, 리소스 상태를 보는 태스크는 시각적 GUI에 더 알맞고 다른 태스크의 경우는 명령행 인터페이스에 알맞다. 메타-스케줄러가 사용자와 관리자를 위해 GUI와 CLI 모두를 지원하는가? 프로그램 방식의 작업 제출, 모니터링, 제어를 지원하는 API가 있는가?

웹 서비스 인터페이스 또는 자바 API는 이 경우 많이 사용된다. 메타-스케줄러가 조직이 필요로 하는 인터페이스를 지원하는가?

제품과 기업 역사

기업과 소프트웨어 역사 모두가 고려되어야 한다.

이 제품을 언제부터 생산했는가? 일반적으로 사용할 수 있는 소프트웨어 배포판은 무엇인가? 배포 사이클은 어떻게 되며 벤더가 제품 로드맵을 제공하여 미래 배포 내용을 설명할 수 있는가? 현재 제품의 설치 베이스는 무엇인가? 사용자 레퍼런스가 제공되는가? 그렇다면 제품과 서비스와 관련하여 직접적인 정보를 얻을 수 있는가? 현재 제품의 설정은 어떻게 되는가? 얼마나 많은 리소스들이 있으며 어떤 유형의 리소스들을 조정하는가? 어떤 설정이 지원되며 다른 설정들은 테스트 되었는가?

기업 정보도 중요하다. 사업을 시작한지는 얼마나 되었는지, 그리고 재정 상태는 어떠한가? 개발, 테스팅, 지원 분야에 직원들은 어느 정도 보유하고 있는가? 프로젝트가 개발 및 호스팅되는 곳 가까이에 지원 사무실이 있는가? 지원 계약은 있는가? 응답 시간, 문제 결정, 고립화, 해결 또는 에스컬레이션과 관련된 서비스 레벨 계약은 있는가?

결론

지금까지, 그리드 메타-스케줄러가 어떻게 작동하는지, 그리고 프로젝트에 맞는 메타-스케줄러를 평가할 때 고려해야 할 27 개의 기준을 살펴보았다. 제품을 비교하는 간단한 접근 방식은 제품 대비 기능을 나타낸 표를 만드는 것이다.

지원 레벨이 다양하기 때문에 1번은 부분적으로 지원되고 5번이 완전히 지원된다면 1-5 등으로 번호를 할당해야 한다. 각 열이 평가된 후에 칼럼을 통합하여 점수를 계산한다.

보다 세련된 방식은 조직에 이 기능이 얼마나 중요한가를 나타내는 각 열 마다 가중 인자를 두는 것이다. 가중 인자는 열 스코어에 따라 증대하여 조직에서의 이 기능에 대한 지원과 중요성을 나타내게 될 것이다.

다음에는, GT4에 번들 된 Community Scheduler Framework V4.0 Meta-scheduler from Platform Computing을 검토하겠다.

위로

참고자료

“Use Community Scheduler Framework to implement grid meta-schedulers” (developerWorks, July 2004)

“How grid infrastructure affects application design” (developerWorks, July 2003)

A Metascheduler Proof of Concept using IBM Tivoli Workload Scheduler (IBM Redpaper, April 2005)

“Grid computing: What are the key components?” (developerWorks, June 2003)

“zSeries servers and grid computing” (developerWorks, May 2003)

Moab Grid Scheduler

Platform LSF scheduling products

OpenPBS

“Grid in action: Developing a wide grid” (developerWorks, June 2005)

“Grid in action: Harvesting and reusing idle compute cycles” (developerWorks, June 2005)