 | |
|
난이도 : 중급 David Medinets, Freelance Writer, Uniserve Communications Corporation
David A. Cafaro, Computational Researcher, Uniserve Communications Corporation
2007 년 5 월 02 일 그리드 관리에는 그리드 전개에 사용하는 네트워크와 하드웨어부터, 보안, 작업 관리, 그리드 실행 중에 생성된 작업 매트릭스 및 통계 등 작업을 좀더 효과적으로 관리할 수 있게 해주는 많은 요소들이 포함되어 있습니다. 총 네 편으로 구성된 "그리드 관리하기" 시리즈에서는 하드웨어와 네트워크 기본 원리 파악, 이것이 그리드 프로세스에 미치는 영향력, 그리고 매트릭스 정보를 스케줄링, 예측 그리고 확장 툴로서 사용하는 방법 등 그리드 관리 프로세스의 핵심 요소들을 다루고 있습니다. Part 3에서는, 그리드 모니터링, 통계, 전개 부분을 설명합니다.
머리말
로컬 컴퓨터에서 실행되는 프로그램을 모니터링 하기는 쉽다. 예를 들어, Microsoft® Windows®에는 Task Manager 프로그램이 있고, UNIX®에는 Top이라는 프로그램이 있다. 이 두 프로그램 모두는 특정 순간에 사용되고 있는 프로세스들, 사용되고 있는 CPU사용량, 그리고 메모리 사용량 같은 기타 통계들을 보여준다. 하지만, 컴퓨팅 그리드가 개입되면, 어플리케이션 수행 정보가 수 백 개의 컴퓨터들로 분산되어 지기 때문에 애플리케이션이 어떻게 동작하고 있는지를 알아내기가 훨씬 더 어려워진다.
"그리드 관리하기" 시리즈, Part 3에서는 모니터링의 유형, 모니터링 대상, 모니터링의 수행 방법, 그리고 모니터링이 전개 결정에 미치는 영향 등을 설명한다.
그리드에 관여된 많은 사람들 마다 서로 다른 유형의 정보를 필요로 한다는 것을 기억해야 한다. 엔드 유저들은 애플리케이션 결과(작업 실행 정보)에 관심이 있는 반면, 그리드 관리자는 디스크 공간 사용 같은 보다 구체적인 정보에 관심이 있다. 또한, 한 개 이상의 애플리케이션들 간의 균형을 맞춰주며 사용자와 관리자를 이어줄 사람이 있을 수 있다.
이 시점에서, 인증과 권한에 대해 언급하고자 한다. 이 주제는 상당히 복합적이어서, 이 글에서는 단지 이것의 중요성에 대한 힌트 정도만 언급할 것이다. 자세한 내용은 참고자료 섹션을 참조하라.
인증(Authentication)은 특별한 사용자를 구별한다. 간단한 패스워드로 보호되는 HTML 페이지들은 대부분의 애플리케이션 보안으로 충분하다. 한번 인증을 받은 사용자는 권한이 부여된 애플리케이션은 어디든지 액세스 할 수 있어야 한다. (모든 그리드 애플리케이션들에 싱글사인온(single sign-on)을 사용하면 더욱 수월하다.)
권한(Authorization)은 컴퓨팅 그리드에서 고유의 특별한 영역이 있다. 어떤 사용자가 어떤 애플리케이션에 액세스 할 수 있는지를 지정하는 것 외에도, 특수한 하드웨어에 액세스 할 수 있는 권한을 주고 디스크 스토리지 사용에 제한을 둘 수 있다. 각 애플리케이션은 고유의 내부 권한 요구 사항을 갖출 수 있다.
그리드 모니터링
그리드 모니터링의 경우 그리드의 다양한 측면, 이들의 상관 관계, 모니터링 된 정보가 사용되는 방법을 고려해야 한다. 다음은 여러분이 고려해야 할 사항들 중 일부이다.
-
사용자 유형(User types) -- 엔드 유저는 관리자에게서 다양한 정보를 요구한다. 관리자들은 OS 관리자와 데이터베이스 관리자로 분류될 수 있다. 여러분이 모니터링 하는 데이터는 각 사용자들의 요구사항에 맞아야 한다.
-
리소스 -- 그리드를 구성하고 있는 리소스들의 유형을 고려해야 한다. 스토리지, 서버, 데이터베이스 서버, 애플리케이션 등이 있다.
-
시간 -- 특정 값이 얼마나 자주 수집되는가? 예를 들어, 디스크 사용에 대한 정보를 모으는 일의 경우, 여러분의 그리드 애플리케이션이 많은 파일들을 만들지 않는 한 하루에 한 번 수행될 수 있다. 하지만, 그리드가 많은 중간 정보나 산출된 결과를 저장해야 한다면 한 시간에 한번씩 디스크 사용을 감시해야 한다.
-
애플리케이션 유형 -- 그리드에서 실행되는 애플리케이션 유형이다. 이들이 데이터 유형, 계산 유형, 서비스 유형인지를 파악해야 한다. 아마도 혼합된 유형이 많을 것이다. 각각의 애플리케이션 유형은 고유의 모니터링 필요성이 있다.
다음 섹션에서는 어떤 부분을 모니터링 해야 하는지에 대해 살펴보기로 하겠다.
모니터링 대상
각각의 측면들 마다 다른 특성들을 갖고 있다. 예를 들어, 엔드 유저 애플리케이션들은 에러가 있을 수 있다. 또는, 그리드에 있는 각 서버의 여유 디스크 공간을 계속 감시해야 한다. 이러한 예들은 다음과 같이 분류된다.
-
로그(Log) -- 문제와 이슈들을 발견해 낼 수 있도록 하는 그리드의 상태에 대한 에러와 경고를 포함하고 있다.
-
매트릭스(Metrics) -- 스케줄링에 사용될 수 있는 성능과 성취도를 나타낸다.
일반적으로 로그는 애플리케이션 내에서 생성되고, 매트릭스는 애플리케이션 밖에서 모니터링 소프트웨어에 의해 생성된다.
로그들은 성능과 연관이 되어서는 안 된다. 로그들은 사용되는 컴퓨팅 리소스 유형과는 독립적이다. 싱글 CPU 데스크탑 또는 멀티 CPU 고성능 서버에서 에러가 생성되었다는 사실은 진단 프로세스와 에러 해결 프로세스와는 관련이 적다. 하지만, 컴퓨터의 아키텍처 스타일은 프로그램이 실행되는 방식과 생성되는 에러에 영향을 미칠 수 있다.
반면, 매트릭스는 로그들을 모으는데 사용되는 하드웨어와 소프트웨어에 큰 영향을 받는다. 예를 들어, 디스크 하위 시스템의 처리량을 검사할 때, 사용 중인 하드웨어에 대한 성능 기대치를 알아야 한다. 하나의 하드웨어는 다른 것 보다 두 배나 빠를 수 있다, 이는 하나의 메트릭을 또 다른 메트릭과 비교할 시점을 알아내는데 중요하다. 일부 측정 소프트웨어는 실행 애플리케이션에 장비를 추가하지만, 또 다른 것은 OS를 사용하거나 네트워크를 감시한다.
모니터링이 실행하는 애플리케이션의 성능에 영향을 주는 것도 사실이다. 가끔, 해당 애플리케이션의 성능이 중요한 문제가 될 때, 적은 부분만 모니터링 하도록 하는 모니터링 시스템을 갖추는 것도 필요하다.
로그
다양한 유형의 메시지들이 로그 파일로 보내진다.
-
정보 메시지(Informational messages) -- 어떤 일이 발생했는지를 알려준다. (예를 들어, "특정 파일이 열렸다.") 이 메시지는 프로그램의 실행 플로우에 레퍼런스 포인트를 제공하기 때문에 에러 메시지를 해독하는데 도움이 된다.
-
경고 메시지(Warning messages) -- 이들은 일반적으로 무시되지만, 주의를 기울이는 것이 좋다. 특정 경고 메시지에 스파이크를 보게 되면, 조사를 해 보는 것이 좋다.
-
에러 메시지(Error messages) -- 프로그램이 예기치 못한 상황에 처했다는 것을 의미하며, 잘못된 인풋이나 정확하지 못한 구성 같이 픽스가 가능한 것들이다. 이러한 에러들은 후속 장애를 불러들이지 않기 위해서 즉시 해결되어야 한다. 에러가 발생하면 어느 정도의 디버깅과 분석이 필요하다. 쉬운 분석을 위해서는, 그리드에서 해당 머신을 가져와서 에러를 픽스할 수 있도록 하는 시스템이 필요하다. 그리드에서 머신을 제거하는 것이 그리드의 성능에 영향을 미치고, 스케줄링에도 영향을 준다는 것도 알아야 한다.
로그 파일을 검사할 때 다음과 같은 정보를 얻어낼 수 있다.
-
작업 실행(Job execution) -- 실행된 작업의 수와 이들의 마지막 상태를 트래킹 하는 것이 중요하다. 이들 모두가 실행되었는가? 성공, 실패, 또는 에러 상황으로 끝났는가? 실행하기 까지 얼마나 걸렸는가?
-
보안(Security) -- 그리드는 인증과 권한을 트래킹 할 수 있어야 한다. 이 정보는 로그에서 사용할 수도 있다.
-
하드웨어 -- 디스크가 공간 밖에서 얼마나 자주 실행되는가? 얼마나 자주 실패하는가? 네트워크가 실패하거나 패킷을 소실하는가?
-
소프트웨어 -- 설정 오류가 얼마나 자주 발생하는가? 작업이 리소스 범위를 얼마나 자주 벗어나는가? 소프트웨어 버그는 어떻게 처리되는가?
매트릭스
그리드와 애플리케이션과 관련하여 수 많은 매트릭스들이 수집된다. 그리드가 CPU 중심적인 태스크에 사용된다면, 매트릭스는 단위가 될 것이다. 그리드가 스토리지와 관련이 있다면, 매트릭스는 스토리지가 될 것이다. 다음은 여러분이 트래킹 할 수 있는 매트릭스다.
-
CPU -- CPU 사용은 프로그램의 실행 시간에 직접적인 영향을 미친다.
-
데이터 -- 데이터 스토리지를 보면서, 여유 공간의 양, 애플리케이션 안팎을 흐르는 바이트의 수, 필요한 임시 공간의 양에 대한 정보를 모을 수 있다.
-
메모리 -- 메모리는 많은 종류의 애플리케이션에 있어 중요하다. 메모리와 관련된 매트릭스에는 페이지 오류, 피크(peak) 메모리 사용, 가상 메모리 사이즈가 포함된다.
-
노드 -- 노드와 관련된 매트릭스에는 업타임(uptime), 처리된 요청, 트랜잭션 처리량 등이 포함된다.
-
네트워크 -- 네트워크와 관련된 매트릭스에는 레이턴시, 프로토콜의 통신 오버헤드, 패킷 드롭(drop), 패킷 처리량 등이 포함된다.
매트릭스 통계 대조하기
여러분은 모니터링 되는 그리드 매트릭스에서 많은 정보를 생성할 것이다. 이러한 정보를 통해 과거의 그리드 성능을 알 수 있고, 미래의 성능도 예견할 수 있다. 이 정보를 가지고 그래픽 형태로 만들면 그리드에 어떤 일이 발생했는지를 빠르게 볼 수 있다. 나중에, 통계 분석을 사용하여 리소스 사용에 대한 미래의 경향을 계산하여 향후 업그레이드를 계획하고, 잠재적인 위험 상황들을 발견할 수 있다.
-
매트릭스의 그래픽 표현 -- 매트릭스의 그래픽 형태를 사용하는 것도 좋은 생각이다. 현재의 성능과 리소스 사용은 물론 기본적인 경향 리포팅까지 쉽게 볼 수 있다. 대부분의 리포팅 애플리케이션은 리소스 매트릭스에 대한 그래픽 뷰를 생성하는 옵션을 제공한다.
-
웹 기반 리포팅과 클라이언트-서버 기반 리포팅 -- 이 두 가지 모두 다른 프로퍼티를 제공한다. 웹 기반 리포팅은 현재 시스템 성능의 빠른 스냅샷에 사용될 수 있고 과거 리소스 사용에 대한 간단한 뷰를 제공하여 사용자나 관리자가 작업을 어디에 두어야 하고 어떤 리소스가 자신들의 필요에 가장 잘 맞는지를 결정할 수 있도록 해준다. 클라이언트-서버 기반 리포팅은 상세한 데이터 분석을 위한 더 많은 옵션을 제공하고 경향 리포팅과 플래닝에 유용하다.
-
줌(zoom), 드릴-다운(drill-down), 롤업(roll-up) -- 매트릭스를 볼 때, 매트릭스에 구조화 된, 일관성 있는 계층적 뷰를 설정하고 사용하는 것이 좋다. 사용자들은 특정 노드 클러스터들의 고급 그리드 정보부터 구체적인 노드와 백업까지 쉽게 이동할 수 있다.
-
단기(Short-term) 경향 정보 대 장기(long-term) 경향 정보 -- 단기 경향 정보는 그리드 리소스에 대한 작업 제출을 계획하는데 좋다. 단기 정보는 시스템의 현재 워크로드에 대한 개요를 제공한다. 장기 경향 정보는 미래의 리소스 필요를 계획하는데 좋다. 알려진 미래의 프로젝트와 결합된 장기 경향 정보를 봄으로써, 그리드 인프라스트럭처를 어디로 확장해야 하는지 쉽게 예견할 수 있다. 아래는 웹 기반 그래픽 매트릭스 리포트에서 볼 수 있는 여러 예제들이다. 고급 뷰에서 시작하여 각 리소스에 대한 세분화된 상세로 내려갈 것이다. 이 스크린샷들은 무료 오픈 소스 프로젝트인 Ganglia Monitoring System에서 제공한 것이다.
그림 1은 그리드 리소스의 개요이다. 상단에는 모든 그리드 리소스에 대한 요약이 있다. 그 다음에는 각 그리드 리소스 클러스터의 개요들이 보인다.
그림 1. 그리드 리소스 개요
리소스의 호스트 네임을 클릭하면, 해당 클러스터의 리소스 사용에 대한 상세한 뷰를 볼 수 있다. 개별 호스트에 대한 정보도 포함된다.
그림 2. 클러스터의 리소스 사용에 대한 상세한 뷰
클러스터의 뷰 링크를 클릭함으로써, 어떤 리소스를 클러스터에서 사용할 수 있는지를 볼 수 있고, 개별 노드 리소스를 볼 수 있다.
그림3. 클러스터의 뷰 링크
개별 호스트를 클릭하면, 사용 통계 같은 특정 머신에 대한 상세한 정보를 얻을 수 있다.
그림 4. 사용 통계를 포함한 상세 정보
개별 호스트를 클릭하면 물리적 특성과 소프트웨어 특성에 대한 정보를 볼 수 있다.
그림 5. 정보와 물리적/소프트웨어 특성
매트릭스 사용하기
이러한 정보를 얻었다면, 이를 가장 잘 활용할 수 있는 방법을 결정해야 한다. 여러분이 리소스 사용자인지 관리자인지에 따라서, 또는 여러분이 다음 작업 제출을 계획하는지 아니면 미래의 그리드 사용과 확장을 계획 중인지에 따라서, 매트릭스 사용은 달라진다. 예를 들어:
-
엔드 유저(End User) -- 엔드 유저들은 작업을 수락하고 이를 시의 적절하게 성공적으로 완료하는 것에 관심이 있다. 단기 시스템/그리드 사용을 다루는 매트릭스는 엔드 유저에게 가장 중요하다. 어떤 리소스에 작업을 제출할 것인지 또는 어떤 리소스의 사용을 요청할 것인지를 결정하는데 도움이 된다. 또한 현재 작업에 어떤 일이 일어나는지의 상태를 체크할 수 있다.
-
관리자 -- 관리자는 단기 매트릭스와 장기 매트릭스에 관심이 있다. 단기 매트릭스는 리소스에서의 병목 현상을 발견하는데 도움이 되고, 단기 작업 제출과 소소한 관리를 조정하기 위해 현재 사용도가 낮은 리소스들을 찾는데 도움이 된다. 매트릭스에 나타난 장기 트랜드들은 자동화된 작업 제출 패턴을 계획하고, 장기적인 리소스 할당과 확장 플랜을 계획하는데 도움이 된다.
매트릭스를 이용한 리소스 관리
리소스 관리를 위한 매트릭스 사용은 좋은 그리드 관리의 기본이다. 리소스에 대한 매트릭스는 작업 제출 규칙을 수립하고, 시스템 최적화를 트래킹하고, 미래의 확장이나 리소스 재분배를 플래닝 하는데 도움이 된다. 다음은 다양한 유형의 매트릭스 정보의 사용 예제들이다.
-
현재 데이터 경향 -- 작업 제출을 계획하고 단기 병목 현상을 처리하는데 유용하다. 단기 경향을 봄으로써, 사용자는 리소스 부족에 대한 경고를 받을 수 있고 이와 관련한 계획을 세울 수 있다. 스토리지 매트릭스를 보는 동안, 필요한 스토리지 공간이 작업에 사용될 수 있는지 여부를 빠르게 파악할 수 있다. 애플리케이션이 임시(스크래치 공간) 스토리지와 장기 스토리지에 대한 필요가 각각 있음을 염두 해 두는 것이 좋다.
-
현재 프로세싱 경향 -- 이러한 매트릭스를 보는 것은 어떤 리소스를 작업에 사용할 수 있는지를 결정하는데 도움이 된다. 단기 작업을 제출하기 위해 어떤 시스템이 현재 유휴 상태인지 또는 활용도가 낮은지를 결정할 수 있다. 또한 시스템의 건전성에 대한 정보도 제공한다. 여러 번 실패한 노드들 또는 미스매치 된 CPU 활용은 작업을 제출하기 전에 근본적인 문제를 해결해야 됨을 나타낸다.
-
장기 데이터 경향 -- 자동화된 작업 제출을 계획하고 앞으로의 리소스 확장이나 재할당을 계획하는데 유용하다. 임시 스토리지(스크래치 공간)와 장기 스토리지를 개별적으로 봐야 한다. 장기 경향을 봄으로써, 어떤 리소스들이 과도하게 부담을 받고 있는지를 결정할 수 있고, 이에 따라 자동화된 로드 관리를 수정할 수 있다. 또한, 어떤 시스템이 더 많은 리소스들을 필요로 하는지를 보다 쉽게 결정할 수 있다. (또는 사용이 저조한 시스템에서 재할당 된다.)
-
장기 프로세싱 경향 -- 자동화된 작업 제출과 앞으로의 증가를 계획하는데 가장 적합하다. 이러한 매트릭스를 보면서, 자동화된 작업들을 스케줄링 하여 잘 사용되지 않는 시스템들을 더욱 잘 활용할 수 있다. 또한 확장은 물론이고 시스템 하드웨어를 특정 리소스로의 재할당과 관련한 정보를 제공한다.
매트릭스를 이용한 스케줄 관리
여러분이 그리드의 성능을 알고 있다면, 이에 맞춰 최상의 작업 스케줄링 방법을 결정할 수 있어야 한다. 과거의 히스토리를 사용하여 특정 작업에 걸린 시간을 산출해 낼 수 있다. 매트릭스를 사용하면, 여러분의 필요에 따라 다른 리소스들에 대한 동시 작업들을 스케줄링 함으로써 여러 개의 동시 프로젝트들을 지원할 수 있다.
하나의 집약된 작업을 고성능, 고출력(high-count) CPU 시스템의 클러스터에 보내면서, 풍부한 스토리지를 가진 또 다른 리소스에서 데이터 집약적인 작업을 실행할 수 있다. 매트릭스를 통해서 여러분은 이러한 리소스들을 보고, 최상의 방법으로 사용할 수 있다. 다음은 몇 가지 고려 사항 들이다.
-
집중 작업 대 지속적인 작업 -- 그리드 매트릭스를 볼 때, 리소스에서 어떤 유형의 작업이 수행되는지를 고려해야 한다. 집중 작업(Bursty Work) 또는 집중된 단기 작업들은 그리드 또는 그러한 작업 유형 전용의 전산 리소스에 의해서 더욱 잘 핸들된다. 다른 리소스에서 실행되는 길고 연속적인 작업의 워크로드를 파악하면서 그러한 작업들을 빠르게 스케줄링 및 완료할 수 있다. 또한, 미래의 확장을 계획할 때 이 부분을 고려하는 것이 좋다. 짧은 시간 동안 증가했다는 것은 부하가 큰 시스템이 사용 중이라는 것을 나타낸다.
-
자동 스케줄링과 수동 스케줄링 -- 자동 스케줄링을 통해 그리드 실행에 집중할 수 있지만, 급박한 작업이나 주요한 오류가 있을 경우 반응이 느리고, 작업이 분산 및 사용될 방법을 고려할 수 없다. 수동 스케줄링에는 실행될 작업이 순서를 직접 설정해야 한다는 점에서 더 많은 손이 간다. 하지만, 여러분에게 더 많은 제어권이 주어지고, 대형 작업에 앞서 작은 작업을 먼저 스케줄링 하게 된다. 또한 여러 개의 작은 작업들을 동시에 스케줄링 할 수 있다. 자동 스케줄링은 작업을 순차적으로 핸들 하는데, 이는 그리드에는 잘 맞지 않는다.
-
이기종의 환경에서 스케줄링 하기 -- 서로 다른 머신들, 환경들, 성능이 혼합된 곳이라면, 그리드 그룹들을 구현 또는 개발하여 다양한 환경의 기능 또는 능력에 따라 작업을 스케줄링 해야 한다. 예를 들어, 정수 기반인 CPU 중심 작업이 있을 경우, RISC-기반 CPU (SPARC)에서 작업을 실행하는 것이 더욱 효과적인 반면, 소수점 계산은 전용 FPU (Intel®/AMD 또는 PowerPC®와 Altivec units)를 가진 환경이 더욱 알맞다.
요약
지금까지, 그리드 모니터링, 통계, 전개에 대해 설명했다. 그리드의 다양한 측면들, 사용자, 리소스, 시간, 애플리케이션 유형들이 모니터링 되는 방식과, 로그와 매트릭스를 통해 모니터링 되는 방법을 설명했다. 또한, 이러한 정보를 사용하여 보다 효과적으로 그리드를 관리하는 방법도 설명했다.
Part 4에서는 하루 동안 그리드에서 발생하는 일반적인 태스크와 이벤트에 대해 설명하겠다. 시스템 오류와 복구, 일상적인 모니터링과 프로그레스, 향후 작업과 요구 사항을 처리하는 플래닝 방법을 설명할 것이다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | | | David Medinets는 TRS-80 Model 1을 시작했던 1980년부터 프로그래밍을 해왔다. 여전히 재미있는 캐릭터를 만들기 위해 키보드를 조작했던 시절을 기억하고 있다. 이후에 UNIX® 머신에서 Emacs 텍스트 디버깅을 수행했고, VAXen에서 작업했으며, 첨단 웹 애플리케이션을 구현했다. Kathryn과 결혼하여 버지니아, Fairfax에 살고 있다. Eclectic Consulting을 운영하고 있으며 Perl, PHP, BASH관련 서적도 집필했다. CodeBits.com 사이트도 운영하고 있다. |
| | | David A. Cafaro는 현재 Georgetown University의 Advanced Research Computing (ARC) 그룹 직원으로서, 리눅스와 오픈 소스 기술을 사용하여 전산 연구를 지원하고 있고, Red Hat Certified Engineer이기도 하다. Program Committee for LinuxWorld Expo와 Summit에서 트랙 내용과 기술을 개발하고 있다. Tresys Technology에서 보안 분석가로 활동하면서, SELinux 정책 작업에 초점을 맞추고 있다. 오픈 소스와 리눅스 커뮤니티에 활발히 참여하고 있다. (Tux.org) |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
