 | |
|
난이도 : 중급 Martin Brown, Freelance Writer
2006 년 11 월 21 일 그리드 관리에는 많은 요소들이 개입되어 있습니다. 그리드를 전개하는데 사용되는 네트워크와 하드웨어부터 보안, 작업 관리, 그리드 실행 중에 생긴 작업 매트릭스와 통계 등, 작업을 효과적으로 관리하는데 사용되는 것들입니다. 총 네 편으로 구성된 “그리드 관리하기” 시리즈에서는 그리드 관리 프로세스의 핵심 요소들을 검토할 것입니다. 하드웨어와 네트워크, 그리고 이것이 그리드 프로세스에 미치는 영향, 스케줄링, 예견, 확장 툴로서 매트릭스 정보를 사용하는 방법을 설명합니다. 그리드 네트워킹의 핵심 요소들과 아울러, 그리드의 하드웨어 인프라스트럭처와 이것이 다른 그리드 관리 영역에 미치는 영향을 알아봅니다.
머리말
올바른 네트워크 하드웨어와 그리드 하드웨어의 선택은 그리드 관리에 있어서 큰 차이를 만든다. 그리드 인프라스트럭처를 단순화 하면, 전개하기도 쉬워진다. 하지만, 장기적으로 볼 때, 그리드 요구 사항이나 리소스가 커지는 만큼 확장하기 어려워 진다. 이 두 가지 요소들간 균형을 유지하는 것이 효과적인 그리드 관리의 열쇠이다.
네 편으로 구성된 “그리드 관리하기” 시리즈의 첫 번째 글에서는, 그리드 관리의 프로세스와 핵심 컴포넌트를 상세히 설명한다. 업데이트와 하드웨어 오류를 다루는 방법, 보안 방식과 적용 방법, 네트워크의 모니터링과 평가 방법을 설명한다.
그리드 관리 개요
그리드 사용과 개발에는 많은 측면들이 있다. 보안, 애플리케이션, 아키텍처를 비롯하여 작업을 전개하고 분산하는 방식에 이르기까지 다양하다. 일단, 그리드와 애플리케이션이 적재적소에 배치되면, 그 이후에도 문제들은 생기기 마련이다.
예를 들어, 여러분은 일정한 형태의 모니터링 시스템을 사용하여 그리드를 계속 관리하게 될 것이다. (참고자료) 그 정보를 통해, 가용 리소스들을 최대로 활용하기 위해 그리드 전반에 걸쳐서 작업을 로딩 및 분산하는 결정을 내릴 수 있다.
그리드 관리는 그리드 환경을 설치하고 설정하는 순간부터 시작한다는 사실을 기억하라. 관리 프로세스를 시작하는 장소에는 나머지 그리드의 프레임웍을 형성하게 될 네트워킹과 하드웨어가 있어야 한다.
네트워크 구조와 토폴로지
그리드에 사용할 네트워크 구조와 토폴로지는 그리드의 효율성, 네트워크 퍼포먼스(그리드 애플리케이션에 중요하기도 하고, 중요하지 않을 수도 있음), 향후 그리드 환경의 관리, 지원, 확장에 중요한 영향력을 갖고 있다.
어떤 유형의 그리드를 전개할 것인지를 결정해야 한다: 전용(dedicated), 비전용(nondedicated), 분산(distributed)
-
전용 그리드(dedicated grid)는 그리드에만 전적으로 사용되는 전용 네트워크 하드웨어와 컴퓨팅 리소스로 구성된다. 전용 그리드는 그리드 아키텍처에 최상의 컨트롤과 유연성을 제공하고, 모든 연산들을 선택할 수 있다.
-
비전용 그리드(Nondedicated grid)는 기존 컴퓨팅 인프라스트럭처의 리소스와 환경을 사용하는 그리드이다. 예를 들어, 데스크탑 또는 서버 컴퓨터가 유휴 상태일 때, 회사의 컴퓨팅 리소스를 사용하는 그리드는 비전용(nondedicated) 그리드이다. 이들이 그리드에 사용되지 안을 때 머신을 지원하는데 사용되는 핵심 구조를 변경할 수 없기 때문에, 환경과 네트워크 구조에 대한 컨트롤이 적다. 하지만, 보다 효과적인 그리드를 위해 현재 인프라스트럭처에서 그리드 요구 사항에 따라 변경을 관리할 수 있다.
-
분산 그리드(distributed grid)는 WAN 또는 인터넷을 통해 분산된, 내부 또는 외부 어디든 위치할 수 있는 머신들로 구성된다. 분산 그리드에서는, 네트워크 구조에 대한 어떤 컨트롤도 가질 수 없지만, 분산 컴포넌트들이 서로 효과적으로 통신하는 부분에 대한 제어권은 있다.
네트워킹 토폴로지와 하드웨어는 여러분이 전개한 그리드의 유형에 가장 먼저 영향을 받는다. 전용 그리드는 토폴로지와 네트워킹 하드웨어를 최대한 자유자재로 선택할 수 있다.
비전용 그리드의 경우, 기존 네트워크와 인프라스트럭처에 기반하기 때문에, 네트워킹 선택도 제한이 있다.
분산 그리드에서는, 네트워킹 하드웨어와 구조의 컨트롤 또는 관리가 퍼블릭 또는 WAN 기반 솔루션을 통해 그리드 머신들이 통신하는 방법에만 영향을 미친다. 관리는 액세스, 보안(방화벽과 인증 포함), 오류 시 연결을 제공하는 백업 솔루션에 치중한다.
상용 네트워킹 하드웨어
그리드 네트워킹 구조 유형과 관계 없이, 여러분이 선택해야 할 핵심 네트워킹은 하드웨어이다. 상용 네트워킹 하드웨어를 사용한다면(예를 들어, 표준 스위치와 케이블링을 사용하는 Ethernet), 네트워크는 기존 환경과 하드웨어에 쉽게 전개되고 통합될 것이다.
상용 네트워킹 하드웨어를 사용하면, 네트워킹 구조는 일반적으로 측평형 버스가 된다. (그림 1)
그림 1. 상용 네트워크 토폴로지
상용 네트워킹 하드웨어에는 많은 장단점을 갖고 있다. 장점은 시스템의 가용성과 단순함이다. 단점은 그리드 환경에서의 잠재적인 속도와 효과에 관한 것이다. 상용 그리드는:
-
전개가 쉽다 -- 이더넷 스위치는 획득, 설치, 연결이 쉽다. 이더넷 카드는 거의 모든 플랫폼과 운영 체계에서 사용할 수 있는 드라이버이다.
-
저렴하다 -- 상용 하드웨어는 저렴하고, 아마도 그리드 내에서 가장 저렴한 비용일 것이다.
-
확장이 쉽다 -- 이더넷을 사용하면, 필요한 만큼 네트워크 포트를 추가 및 확장할 수 있다. 올바른 스위치와 라우터를 사용한다면, 대형 네트워크에는 속도 제한이 있겠지만, 이론상으로는 거의 상한선이 없다.
-
빠르다 -- 상용 하드웨어는 빠르다. (gigabit Ethernet 또는10-GB Ethernet). 하지만, 일반적으로 노드의 수가 증가하면, 네트워크의 전체적인 속도는 느려지고, 이로써 네트워크 확장성에 제한이 생긴다.
-
레이턴시가 높다 -- gigabit Ethernet일지라도, 연결 초기화와 데이터를 보내는 것 사이에 지연이 생길 수 있다. 이는 고성능 그리드에서는 문제점이 될 수 있다.
특화된 네트워킹 하드웨어
반면, InfiniBand 또는 Myrinet 같은, 특화된 전용 하드웨어는, 주로 그물 구조(그림 2)에서, 속도에 초점을 맞춘, 완전히 다른 토폴로지를 사용한다. 그물 구조는 노드들 간 빠른 연결을 가능케 하고, 쓰루풋(데이터 트랜스퍼) 또는 레이턴시(연결 사이의 지연)를 위해 최적화 된다.
그림 2. 특화된 네트워크 하드웨어의 그물 네트워킹
그물 구조에서 작동하는 전용의 특화된 네트워킹 시스템들 역시 많은 장단점들이 있다:
-
속도 -- 고성능 그리드에서, 네트워크 속도와 레이턴시는 중요하다. 그물 네트워크는 이러한 문제들을 해결한다.
-
가격 -- 이러한 네트워킹 시스템들은 매우 특화된 것이기 때문에, 가격이 높다.
-
확장성 제한 -- 수 백, 수천 개의 노드들을 가진 대형 네트워크를 만들더라도, 퍼포먼스나 레이턴시에 영향을 미치지 않고도, 네트워크상의 노드의 수에 제한이 생긴다.
-
지원 제한 -- 지원 플랫폼과 운영 체계들이 훨씬 더 적다. 이는 그리드 환경에 설치하고자 하는 시스템에도 영향을 미칠 수 있다. 사용자에게 그리드 연결을 제공하기 위해서는 특화된 브리지 또는 하드웨어를 지원해야 한다.
지속적인 네트워크 관리 요구 사항들은 네트워크를 확장 및 업데이트 하는 방식에도 영향을 미친다. 그리드 내에서 작업의 실행을 모니터링 하는 방법, 그리드의 퍼포먼스와 기능을 평가하는 방법을 변화시키기 때문에 앞으로의 작업을 효과적으로 스케줄링 할 수 있다.
네트워크 구조와 하드웨어는 그리드의 핵심 환경이다. 따라서, 속도, 유연성, 확장성의 균형을 맞춘 네트워크 환경과, 전개 플랫폼을 지원하는 네트워크 환경을 전개해야 한다.
그리드 하드웨어
그리드에서 사용되는 하드웨어는, 네트워킹과 컴퓨팅 컴포넌트의 관점에서 볼 때 중요하고, 운영 체계, 애플리케이션 전개, 확장 플래닝, 비용에도 큰 영향을 미친다. 이들 각자는 매우 작은 고려 사항들이다. 하지만 이들이 결합되면, 그리드를 전개하고, 업데이트를 적용하고, 또는 새로운 하드웨어, 리소스, 기능들로 그리드를 확장 및 향상할 때 사용하는 방식과 모델에 큰 차이를 만들 수 있다.
일반적으로, 그리드 전개에 두 개의 핵심 하드웨어 모델이 있다:
-
개인화 하드웨어 -- 커스텀 하드웨어 슈트(특정한 make/model과 컴퓨팅 환경의 플랫폼)를 사용한다면 전개와 업그레이드 시, 큰 효과를 볼 수 있다. 일관된 하드웨어 환경에서는, 운영 체계, 애플리케이션, 그리드 애플리케이션을 “복제(clone)”할 수 있고, 네트워크 내 모든 컴퓨터에 복제된 디스크를 사용할 수 있다.
-
상용 하드웨어 -- 표준 상용 컴포넌트를 사용하면 저렴하고, 하드웨어 전개가 단순하지만, 운영 체계와 소프트웨어 설치가 더 복잡해지고, 각 머신이 개별적으로 다루어진다. 이로써, 관리 오버헤드가 늘어나고, 문제가 많은 장비로 더욱 쉽게 대체될 수 있다.
그리드 전개에 사용되는 하드웨어의 주요 고려 사항들은 다음과 같다:
-
플랫폼 -- 플랫폼의 핵심 하드웨어는 운영 체계에 영향을 미치고, 아울러 소프트웨어와 전개 환경에도 영향을 미친다. 여러분의 결정에 따라, 업데이트 같은 장기 관리 문제에도 영향을 주고, 다운타임과 관리를 처리하는 방법에도 영향을 미친다. 두 개의 선택권이 있다. 상용 하드웨어는 쉽고 편리한 하드웨어를 제공하지만 호환성과 안정성에 문제가 많다. 커스터마이징 하드웨어는 보다 안정적이지만, 업데이트와 확장이 더욱 복잡하다.
-
운영 체계 -- 하드웨어 마다 운영 체계에 대한 제한이 다르고, 이는 소프트웨어, 보안 문제, 업데이트와 향상의 가용성 등에 영향을 미친다.
-
설정 및 전개 -- 표준화된 환경이 전개 패키지를 단순화 시키기 때문에 커스터마이징 하드웨어는 설정과 전개가 쉽다. 상용 하드웨어의 경우, 각 머신을 개별적으로 설정하여, 그리드 환경에 설치하기 전에 올바른 드라이버들이 설치되었는지를 확인해야 한다.
-
업데이트 -- 업데이트는 스케줄링 되어야 하지만, 업데이트가 하드웨어에 미치는 영향에 대해서도 고려해야 한다. 운영 체계와 드라이버 업데이트는 커스터마이징 하드웨어에 전개 및 설치가 쉽다.
-
하드웨어 오류 -- 그리드에서의 오류는 피할 수 없는 일이고, 네트워크에서 하나의 노드 또는 노드 블록을 취해서 해결해야 한다. 중요한 하드웨어 오류가 있을 경우, 장비를 대체해야 한다. 상용 하드웨어의 경우, 소싱이 쉽지만, 설정과 지원은 많은 시간이 필요하다.
-
확장성 -- 그리드가 확장되면, 합당한 하드웨어를 찾아야 한다. 커스터마이징 또는 특화된 모델을 선택하면 하나의 벤더와 오랜 시간 연루되므로, 그리드를 효과적으로 확장시키기 어렵다. 상용 하드웨어는 획득하기 쉽지만, 추가 관리 오버헤드가 생긴다. 따라서, 상용 하드웨어의 경우, 새로운 머신들은 기존 장비 보다 더욱 빨라지기 때문에, 가용 리소스를 최대한 활용하기 위해서는 스케줄과 작업 분산의 관점에서 추가 관리가 필요하다.
그리드의 장기적 관리에는 위 모든 사항들을 지속적으로 관리하여, 관리가 쉽고, 확장 또는 오류 시 픽스, 업데이트 및 문제 해결을 수월하게 할 수 있도록 해야 한다. 정리하면 다음과 같다.
-
전용, 커스텀 하드웨어 -- 전개와 관리가 단순하지만, 확장과 하드웨어 오류에 문제가 많다.
-
상용 하드웨어 -- 관리/설정 오버헤드가 증가하지만, 상용 그리드는 지속적으로 갱신되기 때문에 확장이 매우 단순하다.
웹 서비스와 서비스 지향 인프라스트럭처(SOA)로 전향하면, 관리 프로세스에 큰 영향을 주지 않고, 상용 하드웨어로 기존 그리드 환경을 확장할 수 있다. 하지만, 통계와 매트릭스 정보를 분석할 때 하드웨어의 차이점을 고려해야 한다. 그리드 내에서 개별 리소스들의 기능상의 차이는 작업의 관리와 분산 방법에 영향을 미친다.
하드웨어 관점에서 볼 때, SOA와 웹 서비스도 고려 사항이 많다. SOA와 웹 서비스를 효과적으로 사용하려면, 기반 하드웨어는 그리드 애플리케이션 개발과 전개의 관점에서 생각해야 할 것들이 있다. 하지만, 다음 시리즈에서 보겠지만, 효과적인 작업 관리 결정을 하기 위해서는 그리드 환경에서 합리적은 통계를 얻을 수 있어야 하고, 하드웨어와 리소스 기능의 차이를 고려해야 한다.
효과적인 논리적 구조를 통해서 그리드의 컴포넌트를 규명하고, 나아가서 구분할 수 있게 된다.
논리적 구조
네트워크와 조직의 논리적 구조는 물리적 구조와 조직만큼 중요하다. 그리드가 완전히 내부에서 사용하는 것이든, WAN-/Internet 기반 그리드이든 상관 없이, 네트워크의 논리적 구조를 생각해야 한다. 개별 노드를 참조하는 방법, 개별 노드에 접근 하는 방법, 그리드 애플리케이션에 그 정보가 사용되어 그리드에 작업을 분산하는 방법 등을 고려해야 한다.
관리 관점에서 볼 때, 그리드 내에 개별 노드들을 규명하여, 매트릭스와 통계를 모니터링 하고, 애플리케이션의 설정과 전개를 관리하고, 개별 노드에서 작업할 수 있어야 한다.
단순한 네이밍 스킴을 포함하여 효과적인 논리적 네트워크 구조를 만드는 많은 방법들이 있다. 완전한 내부 그리드의 경우, 독자적 IP 서브넷을 사용하여 그리드 내의 모든 머신들을 규명해야 한다. 이 방법을 사용하려면, 선택된 서브넷이 충분히 큰 것인지를 확인하여 확장 계획을 세운다. 개별 서브넷을 사용하면 라우팅, 방화벽, 분리 시 네트워크 관리가 쉬워진다.
전용 또는 비전용 그리드에서, 네트워크에 대한 상당한 컨트롤을 갖고 있다면 핸들 하기가 더 쉬워진다. 분산 그리드에서, 진짜 IP 주소로 연결되는 개별 노드 또는 원격 노드들의 상세 콘택트를 규명할 수 있는 앨리어싱 스킴을 사용하는 것도 고려할 수 있다. 이렇게 하면, 광범위한 호스트 어레이를 통해 리포팅 메커니즘을 복잡하게 만들지 않고, 그리드를 보다 쉽게 모니터링 할 수 있다.
네트워크 보안
전용 내부 네트워크를 사용하든, 회사의 기존 리소스를 사용하든, 아니면, 광범위한 인트라넷에 걸쳐 그리드가 있든지 간에, 그리드 보안은 똑같이 중요하다.
보안은 개인의 인증과 권한부터, 그리드의 리소스가 권한이 부여되지 않은 사용자에게 노출되지 않도록 하는 것까지, 다양한 측면들이 포함된다. 후자의 경우, 비권한 액세스는 그리드 내에 저장된 정보에 해를 미칠 수 있다. 아니면, 손상된 컴퓨터가 그리드와 관련 없는 태스크들로 할당될 수 있다. 이렇게 되면 가용 리소스가 매우 낮아지게 되어, 그리드의 퍼포먼스와 가용성을 떨어뜨린다.
전용 그리드의 경우, 네트워크는 방화벽을 사용하여 고립되어야 한다. (그림 3)
그림 3. 방화벽을 사용하여 그리드 보호하기
리소스들이 내부에 있지만, 외부 머신들과 공유되는 그리드의 경우, 교환되는 데이터가 암호화된 데이터 교환이나 Internet Protocol Security (IPSec) 같은 시스템을 사용하여 보호되도록 해야 한다.
WAN 또는 인터넷 그리드의 경우, VPN 같은 암호화 되거나 권한을 부여 받은 솔루션을 사용하면, 네트워크 레벨에서 정보를 안전하게 교환할 수 있다.
맺음말
이 글에서, 그리드의 핵심적인 문제를 설명했다. 네트워크와 인프라스트럭처의 선택이 그리드 관리 방식에 영향을 미친다. 상용 하드웨어를 사용하는 것이 가장 쉬운 솔루션이고, 최상의 확장 옵션도 제공한다. 하드웨어의 변경이나 가용성에 대해서 걱정할 필요가 없다.
하지만, 상용 방식은 관리가 더 복잡하고, 하드웨어와 운영 체계를 개별적으로 관리해야 하기 때문에 관리 프로세스에 큰 오버헤드가 생긴다.
네트워크의 논리적 레이아웃 역시 중요하다. 네트워크를 보는 방식과 작업 방식을 변화시키기 때문이다. 마지막으로, 네트워크에서 사용되는 논리적 방식과 하드웨어 방식은 보안 적용 방식에도 영향을 준다. 보안과 관리 원칙은 Part 2에서 설명하도록 하겠다.
기사의 원문보기
참고자료
필자소개 | | | Martin Brown has been a professional writer for more than eight years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms -- Perl, Python, Java, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS, Mac OS X and more -- as well as Web programming, systems management and integration. He is a regular contributor to ServerWatch.com, LinuxToday.com and IBM developerWorks, and a regular blogger at Computerworld, The Apple Blog and other sites, as well as a Subject Matter Expert (SME) for Microsoft. |
기사에 대한 평가
| |
