 | |
|
난이도 : 중급 David Medinets, Freelance Writer, Consultant
David A. Cafaro, Computational Researcher, Consultant
2007 년 5 월 15 일 그리드 관리에는 그리드 전개에 사용하는 네트워크와 하드웨어부터, 보안, 작업 관리, 그리드 실행 중에 생성된 작업 매트릭스 및 통계 등 작업을 좀더 효과적으로 관리할 수 있게 해주는 많은 요소들이 개입되어 있습니다. 총 네 편으로 구성된 "그리드 관리하기" 시리즈에서는 하드웨어와 네트워크 기초와 이것이 그리드 프로세스에 미치는 영향, 매트릭스 정보를 스케줄링, 예상, 확장 툴로서 사용하는 방법 등 그리드 관리 프로세스의 핵심 요소들을 다루고 있습니다. 본 시리즈 마지막 글에서는, 매일 매일의 그리드 관리에 대해 설명합니다.
머리말
본 시리즈를 꾸준히 읽었다면, 그리드 인프라스트럭처의 디자인, 전개, 모니터링에 어떤 요소들이 개입되어 있는지에 대해 잘 알 것이다. 네트워크와 그리드 하드웨어와 소프트웨어를 볼 때 고려해야 할 것과 어떤 환경에서 어떤 서비스를 제공해야 하는 지에 대해서 배웠다. 디자인 단계에서 고려해야 할 부분에 대해서도 살펴보았다. 그리드의 실행 중 모니터링을 통해서 리소스의 운영 상태를 관리할 수 있다는 것도 배웠다.
Part 4에서는 일반적인 그리드 관리자의 작업 스케줄에 대해서 설명할 것이다. 일상적인 태스크, 문제 해결, 작업 관리, 플래닝에 대해서 알아보자.
일상적인 태스크
그리드 관리자의 일상적인 작업은 좋은 시스템 관리자의 그것과 크게 다르지 않다. 디자인이 잘 된 그리드 인프라스트럭처는 일반적으로 안정적이다. 보통, 문제들은 하드웨어 오류, 관리 업데이트, 사용자 에러(잘못된 애플리케이션이나 소소한 실수)에서 기인한다. 다음은 매일 발생하는 몇 가지 문제들이다.
-
로그와 모니터링 -- 하루 동안 여러분이 수행하게 되는 가장 우선적이고 중요한 것 중 하나가 로그를 분석하고 매트릭스 리포트를 보는 것이다. 소프트웨어를 사용하여 이러한 아이템들을 분석하고 키워드와 이슈들을 강조하여 쉽게 문제들을 찾을 수 있다. 로그 파일에 있는 에러와 경고 그리고 매트릭스에 나온 비정상적인 액티비티나 액티비티의 부재 같은 비정상적인 것을 찾게 된다. 다음의 스크린샷은 로그 기반 소프트웨어 에러의 모습이다.
그림 1. 인증 서비스의 에러
-
교육과 경고 -- 여러분이 사용하고 있는 기술과 툴을 최신으로 유지하는 것이 매우 중요하다. 메일링 리스트와 기타 여러 가지 통신 채널에 등록하여 여러분의 소프트웨어 개발에 대한 새로운 소식을 접하는 것이 좋다. (참고자료) 가끔, 애플리케이션에 잘못된 부분을 공지했다면, 누군가가 이미 같은 문제를 공지했을 것이고 이 부분에 대한 논의도 진행 중일 것이다. 심지어는 이미 해결되었을 수도 있다. 이러한 리스트는 여러분에게 앞으로의 문제점들을 알려주고 실제 문제가 발생하기 전에 이를 플래닝 할 수 있도록 돕는다.
-
시스템 관리 -- 관리 태스크는 온라인 태스크와 오프라인 태스크로 나뉜다. 온라인 태스크는 무효 임시 파일 삭제, 사용자 추가 또는 삭제, 실행 프로세스를 방해하지 않는 태스크 같은 간단한 것들이다. 오프라인 태스크는 주어진 시간 동안 해당 시스템이 사용될 수 없다는 것을 사용자에게 공지해야 할 필요성이 있는 시스템 업그레이드로 구성된다. 이 작업은 가능하다면 여러분의 일반적인 관리 작업 범위로 스케줄링 되어야 한다.
-
작업 요청 스케줄링 -- 여러분이 자동화된 스케줄러를 사용하는지, 수동 스케줄링 시스템을 사용하는지에 따라 다르다. 자동화 스케줄러를 사용하면, 적업이 실행 중이고 새로운 작업이 대기 중이라는 것이 체크된다. 수동 스케줄링을 사용하면 매트릭스를 보고 작업 요청과 가용 리소스를 매치시켜야 한다.
-
플래닝 -- 모든 것이 완벽히 진행되고 있다면, 유일하게 남은 큰 문제는 확장 및 업그레이드 플래닝이다. 다른 여타의 기술 분야와 마찬가지로, 어떤 것이 사용되고 이롭다고 간주되면 지속적인 향상 요청이 있을 것이다.
로그를 모니터링 하면 로그에 나타난 문제들(시스템 오류, 긴급 관리, 보안 응답)에 대해서 작업을 하게 된다. 메일링 리스트와 RSS 피드를 통해서도 문제점들을 파악할 수 있다. 시스템 관리에는 Java™ VM 리사이클링, 중지된 서비스 재시작 하기, 새로운 그리드 사용자 관리하기 등의 태스크들이 포함된다. 작업 유형과 그리드 인프라스트럭처에 따라서, 작업 스케줄링은 더 작은 시간 단위들 중 하나가 된다. 다음 섹션에서는 이와 관련한 태스크들을 보다 자세히 설명하도록 하겠다.
시스템 오류와 복구
가끔씩, 로그를 분석하거나 매트릭스 또는 이메일을 검사하여 시스템 오류를 발견하곤 한다. 오류가 발생했던 시스템에 따라서 사소한 문제가 될 수도 있고 큰 문제가 될 수 있다. 여분이 없는 라우터와 스위치, 컴퓨터 리소스상의 마스터 노드, 스토리지, 인증 시스템 같은 핵심 컴포넌트들은 그리드 리소스를 멈추게 할 수 있다. 이러한 핵심 컴포넌트들 중 하나라도 실패하면, 리소스를 오프라인으로 가져가서 긴급 관리를 수행해야 한다. 여러분의 아키텍처에 어느 정도의 중복을 구현할 수 있었다면 일정 시간 동안 리소스를 오프라인으로 가져 갈 필요가 없었을 것이다. 컴퓨터 노드나 스토리지 엘리먼트 오류의 경우, 모든 리소스를 가져올 필요가 없고 일상적인 관리 스케줄 범위 내에서 또는 사용량이 적을 때 작업을 수행한다. 하드웨어는 그리드 시스템에 구현된 여분의 리소스이기 때문에 오랜 시간 동안 오류 상태로 있어서는 안된다. 빠르게 처리되어야 하는 소프트웨어 오류도 있다. 소프트웨어 오류는 전체 리소스를 오프라인으로 가져가야 한다.
-
마스터 노드 오류 -- 그리드 또는 리소스를 정지 상태로 만들고 긴급하게 처리해야 할 오류 유형이다. 마스터 노드는 일반적으로 그리드에서 수행되는 모든 작업을 제어하기 때문에 마스터 노드가 없다면 모든 스케줄링과 워크플로우 컨트롤이 차단된다. 이러한 상황에서는, 마스터 노드를 복구 또는 대체하는 동안 영향을 받는 그리드를 중지시키는 것이 가장 쉬운 일이다. 마스터 노드가 온라인으로 복귀하면 모든 전산 노드와 스토리지 노드들은 다시 연결되고, 이는 콜드 스타트(cold start)로 시작하는 것이 쉽다. 오류가 난 마스터 노드를 대신 할 준비가 된 스탠바이 노드를 갖고 잇는 것이 좋다. 여전히 일부 실패한 작업에 대한 문제가 있지만, 새로운 작업들은 지속될 수 있고 전환 동안 실패했던 작업들은 재실행 되면서 오류가 난 마스터 노드는 재구현 및 재시작 된다.
-
인증 오류 -- 실행 작업에는 영향을 주지 않기 때문에 마스터 노드 오류만큼 심각한 것은 아니지만, 어떤 새로운 작업들도 제출될 수 없고 완료된 작업의 결과가 검색될 수 없다는 점에서 심각하다. 대부분 전체 그리드나 리소스를 중지시킬 필요는 없고 즉각 처리될 수 있다. 하지만, 새로운 작업들은 인증을 받을 수 없기 때문에 시작할 수 없고, 리소스를 할당할 수 없다. 다시 말해서, 백업 또는 중복 인증 서버들은 다운타임을 줄이거나 제거할 수 있다.
-
네트워크 장치 오류 -- 일반적으로 말해서, 네트워크 장치 오류는 다른 유형의 오류들 보다 덜 발생한다. 장치 오류가 발생하면 충분한 여유가 구현되지 않는 한 전체 그리드가 중지될 수 있다. 네트워크 장치가 조직 내에서 분산된 그리드를 연결하면 복구 작업이 진행되는 동안 각 그리드를 중지할 필요가 없다. 네트워크가 복구될 때 다시 연결하면 된다. 네트워크 장치가 그리드 노드들 간 중추 통신을 제공하면 영향을 받은 그리드를 중지시켜서 복구가 이루어진 후 깨끗하게 재시작 될 수 있도록 한다.
-
애플리케이션 오류 및 작업 오류 -- 이들은 가장 일반적인 오류 유형이다. 그리드를 오프라인으로 가져올 필요는 없지만 그리드에서 실행되는 다른 작업이 영향을 받기 전에 즉시 복구되어야 한다. 작업 또는 애플리케이션에서 온 실행 로그들은 해당 영역들을 가리키고 소프트웨어 개발자나 애플리케이션 공급자들과 협력하여 문제를 진단할 수 있다.
-
그리드 노드 오류 -- 아마도 이것은 가장 파괴력이 적은 오류 유형이다. 마스터 그리드 노드가 오류가 난 그리드 노드를 탐지하면 작업이 재할당 되고 오류가 난 노드가 표시된다. 이 부분에서, 오류가 난 노드의 복구 작업이 이루어진다. 그리드 노드가 실해하지만 마스터 그리드 노드에서는 실행하는 것으로 나타나는 경우도 있다. 이러한 상황에서는 예상 시간 보다 오래 걸리거나 에러를 만들어 내는 장기 실행 작업들을 찾아야 한다. 다시 말하지만, 이것은 일반적인 문제는 아니지만 알아둘 필요는 있다.
 |
|
경향과 문제 알아내기
그리드가 사용되고 더욱 대중적이고 생산적이 되어감에 따라서, 여러분의 리소스는 한계가 있다는 것을 알게 된다. 다행히, 그리드 시스템에서는 현재 그리드에 대한 한계에 대해 걱정할 필요가 없다. 새로운 리소스를 추가하여 그리드를 쉽게 확장할 수 있기 때문이다. 어떤 경우에는, 작업이 스케줄링 되는 장소와 시간을 바꾸는 문제가 되기도 한다. 가장 어려운 태스크는 언제, 얼마나 많이 확장해야 하는지 또는 재 스케줄링 방식을 지속적으로 추적하는 것이다. 바로 이 부분에서 매트릭스가 사용된다. 장기 매트릭스를 분석함으로써, 리소스 사용 경향을 파악할 수 있다. 어떤 리소스 유형들이 가장 일반적이고 언제 가장 많이 사용되는지를 파악해야 한다.
-
작업을 재 분산 할 때 -- 전체적인 로드의 스냅샷과 그리드 로드의 평균을 보는 것이 중요하다. 50-60 퍼센트의 사용도를 보여주겠지만 100 퍼센트에 가까운 것처럼 느껴진다. 동시에 모든 것을 발생시키는 "버스트(bursty)" 작업도 감지하게 된다. 여러분의 시스템은 밤과 주말에는 사용되지 않을 수 있고, 한 주간 사용량이 많다가 그 다음 주에는 휴면 상태가 될 수도 있다. 여러분의 필요에 따라서 이러한 다운타임을 더욱 잘 활용할 수 있도록 워크로드를 효율적으로 스케줄링 할 수 있다. 하드웨어를 업그레이드 하기 전에, 현재 리소스를 최대한 활용하고 있는지를 체크하는 것이 좋다. 그림 2의 왼쪽 상단 그래프에는 버스트 작업 예제가 나타나 있다. 이 같은 시스템의 경우 작업 스케줄링을 하면 더욱 효과를 볼 수 있다.
그림 2. 그리드 리소스에서의 버스트 작업
-
확장 계획을 세울 때 -- 어떤 경우에는, 꾸준하게 75 퍼센트의 사용 경향을 보일 수도 있고, 작업의 특성상 재 스케줄링이 불가능 할 때도 있다. 이러한 경우에, 업그레이드 또는 확장이 필요한 시기를 결정해야 한다. 시스템이 75 퍼센트의 용량을 점유하지 않도록 해야 한다. 매트릭스를 보고 조직의 향후 계획과 구현 속도를 감안하여, 시스템이 이 지표에 다다를 때, 업그레이드와 확장을 계획할 수 있다. 이렇게 하여 예기치 못한 문제나 작업의 급증 같은 문제 발생 시 여유를 가질 수 있다. 그리드에서 만들어 내는 거대한 매트릭스 데이터를 활용하여 미리 계획을 세우는 것이 중요하다. 그림 3은 확장 또는 업그레이드의 필요를 알려주는 그리드 리소스 예제이다. 좌측 상단 그래프를 보면 시스템이 거의 포화 상태에 이르렀음을 알 수 있다.
그림 3. 부하가 많이 걸린 시스템
업데이트와 업그레이드
그리드 업데이트는 중요하지만, 다양한 방식들로 수행할 수 있다. 완전한 셧다운/중지는 그리드를 오프라인으로 만들지만, 모든 머신들이 동시에 업그레이드 된다. 단계별 업데이트는 머신 블록들을 중지시켜서 이들을 업데이트 한다. 이러한 방식은 그리드의 효과는 떨어뜨리지만, 단일 업데이트가 여러 날 또는 여러 주 동안 그리드를 중지해야 하는 것을 의미하는 상황에 알맞다.
-
스케줄링 -- 이상적으로, 사용자에게 최소한의 영향만 미칠 때 스케줄링 해야 한다. 예기치 못한 문제가 발생할 경우 외부적인 도움을 받는 것과 작업 오버런의 경우 추가 시간 같은 것을 고려해야 한다. 영향을 최소화 하려면 밤 또는 주말에 작업해야 하지만, 이렇게 하면 외부 지원을 받는 것이 어려워 진다. 사용자에게 다운타임 공지를 보내서 부하가 낮은 시간에 스케줄링을 하는 것이 더욱 쉽고 안전하다. 작업을 결정할 때, 분열, 예기치 못한 문제, 외부 지원 같은 것을 고려해야 한다.
-
전체 셧다운/업데이트 -- 이 작업은 그리드를 오프라인으로 가져가야 하므로 사용도가 낮은 기간 동안 수행되는 것이 가장 좋다. 또한 개입된 모든 당사자들에게 미리 알려야 한다. 그리드가 온라인으로 돌아올 때 각 컴포넌트를 확인할 수 있기 때문에 업데이트와 업그레이드를 수행하는 것이 더 쉽다. 이는 가장 긴 다운타임으로 이어질 수 있기 때문에 주요 하드웨어와 소프트웨어 업그레이드에만 사용되어야 한다.
-
단계별 셧다운/업데이트 -- 가장 선호되는 업데이트 및 업그레이드 방식이다. 특정 컴포넌트를 셧다운 하고 나머지는 실행 상태로 둘 수 있다. 전체적인 서비스의 손실을 일으키지 않고 전체 셧다운의 효과를 최대한 누릴 수 있다. 단점은 전체 그리드 인프라스트럭처를 위협할 수 있는 보안 문제나 중요한 소프트웨어 결합 같이, 시간에 민감한 업데이트에는 효과적이지 않다.
-
실시간 확장 -- 그리드 노드나 그리드 컴포넌트 추가는 가끔씩 셧다운 없이도 수행될 수 있다. 더 많은 전산 엘리먼트나 또 다른 그리드 스토리지 시스템을 추가하는 것은 장치를 온라인으로 가져오는 것과 다른 마스터 그리드 노드에서 설정을 업데이트 하여 새로운 리소스에 대해 공지하는 것처럼 단순한 일이다.
업그레이드나 확장 시, 미리 테스트 및 준비하는 것이 중요하다. 스케줄링에는 테스트 환경에서 테스트 하는 시간과 실제 이벤트 발생 시 모든 작동이 잘 수행되는지를 확인하는 시간까지 포함되어야 한다.
테스팅과 스테이징(staging)
이 섹션에서는 소프트웨어에 대한 업데이트와 변경 사항들이 그리드에 적용되기 전에 먼저 구성될 수 있도록 테스팅과 스테이징 서비스를 제공하는 기술을 설명하겠다. 머신이 크다면 좋겠지만, 3-노드 또는 4-노드 하드웨어 설정도 유용하다.
-
하드웨어 테스팅 그리드 -- 한 가지 테스트 방법은 테스트 랩에 작은 샘플 그리드를 만드는 것이다. 전개된 장치 또는 전개 될 장치 샘플들로 구성된다. 이 장치에서는 아키텍처 디자인을 테스트 할 수 있고 하드웨어의 여러 부분들이 어떻게 작동하는지를 테스트 할 수 있다. 또한, 실제 그리드 하드웨어와 매우 닮아있기 때문에 소프트웨어 테스팅을 수행하기에 알맞은 플랫폼이다. 단점이라면, 비용, 공간, 시스템 오류, 시스템 복구/이미지 등이 있다.
-
가상 테스팅 그리드 -- 가상화 된 서버와 네트워크를 사용하면 그리드에 소프트웨어를 전개하기 전에 테스트 할 수 있다. 많은 가상화 소프트웨어 패키지는 저장된 시스템 상태로 액세스 할 수 있고, 시스템 이미지의 롤백이 쉬우며, 다중 설정들을 다룰 정도로 유연하다. 다만 네트워킹 디자인과 성능 테스팅에 한계가 있다. 그림 4는 가상화 된 환경에서 실행되는 그리드 테스트 예제이다.
그림 4. 가상 테스트 그리드
-
스테이징 -- 새로운 장비가 그리드 인프라스트럭처에 추가되기 전에 테스팅 환경에서 테스트 되어야 한다. 이로써, 실제 그리드에 대한 네트워크 연결을 해지한 채 시스템을 조정할 수 있다. 나머지 그리드와 인터랙팅 하기 전에 시스템이 어떻게 작동하는지를 확인해야 한다. 테스팅 그리드에서 미리 테스트하여 실행 그리드와 인터랙팅 하는 방법도 테스트 할 수 있다.
요약
그리드를 안전하고 완벽하게 실행하는데 필요한 여러 가지 요소들에 대해서 배웠다. 본 "그리드 관리하기" 시리즈를 요약하면 다음과 같다.
- 시스템 오류 및 복구 -- 오류가 발생하기 전에 중요한 문제들이 무엇인지를 생각한다.
- 경향과 문제 -- 모든 시스템은 피크(peak)와 골짜기가 있다. 그 경향을 파악하고 그리드를 준비하라.
- 업데이트와 업그레이드 -- 경향을 분석하면 이에 따라 그리드를 업데이트/업그레이드 하여 최악의 상황을 대비할 수 있고 사용 점유율을 75 퍼센트 이하로 유지할 수 있다.
- 테스팅과 스테이징 -- 민감한 데이터에 영향을 주지 않는 샌드박스 환경에서 그리드를 테스트 하는 것이 좋다. 이것이 실패하면, 적어도 고객들에게는 피해가 가지 않는다. 여러분의 기술력으로 그리드를 픽스 및 업데이트 하고 준비가 되면 실행 환경으로 가져온다.
기사의 원문보기
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | | | David Medinets는 자바, SQL, XML을 전문으로 하는 독립 소프트웨어 컨설턴트이다. 1999년, ToysRs.com을 설계 및 코딩했다. 이후, 많은 업계에서 초기 구축 작업에 참여했다. Cordiem에서는 항공기 부품 데이터베이스를 만들었다. WWRE에서는, XML 밸리데이션과 프로세싱 엔진을 개발했다. 그 외에도 여러 기술 문서들을 기고하고 있다. |
| | | David A. Cafaro는 현재 조지타운 대학교의 Advanced Research Computing (ARC) 그룹 직원으로서, 리눅스와 오픈 소스 기술을 사용하여 전산 연구를 지원하고 있고, 레드햇 인증 엔지니어이기도 하다. Program Committee for LinuxWorld Expo와 Summit에서 트랙 내용과 기술을 개발하고 있다. Tresys Technology에서 보안 분석가로 활동하면서, SELinux 정책 작업에 초점을 맞추고 있다. 오픈 소스와 리눅스 커뮤니티에 활발히 참여하고 있다. (Tux.org) |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
