2012.01.13

기고 | 클라우드와 재난복구, 로드 밸런싱 데이터센터만으로는 부족

Gregory Machler | CSO
클라우드 벤더용 재난 복구 서비스와 관련해 핫-콜드(Hot-Cold) 데이터센터 대신 로드 밸런싱 데이터센터를 활용하는 트렌드가 증가하고 있다. 기업들이 재난에 대비하기 위해 데이터센터 간 로드 밸런싱 기능을 갖춘 프라이빗 클라우드를 설치하고 있는 것이다. 이럴 경우 한 데이터센터에 재난이 닥치더라도 다른 데이터센터를 통해 제한적이나마 운영할 수 있게 된다.

그러나 여전히 문제들이 있다. 특정 애플리케이션 인프라의 다양한 설정을 추적해 따라잡기가 아주 어렵다. 각 애플리케이션마다 서버 네임을 만들고, 개방 IP 주소를 선택하고, DNS 매핑을 어드레스하고, 물리 서버와 가상 서버를 규정하고, 방화벽 규칙을 만들고, SAN과 NAS 설정을 규정하고, 로드 밸런싱 규칙을 이행하고, 데이터베이스 클러스터를 규정하기 마련이다.

게다가 개발, 테스트, 생산 등 각 환경에 따라 애플리케이션마다 이런 작업을 해야 한다. 이런 애플리케이션 설정의 상당수는 여러 웹기반 애플리케이션들에 의해 관리된다. 유지보수 애플리케이션은 통합되어 있지 않으며, 따라서 메타데이터 애플리케이션 설정들은 중앙화되어 있지 않다. 또 긴급한 이유로 이행 시점에 제품에 관리상의 변경이 적용될 수 있다. 변화 관리 시스템에 포착되는 않는 SAN 하위시스템이 한 예다. 따라서 메타데이터가 제때 반영되지 못하는 경우가 많다.

따라서 특정 데이터 센터의 설정을, 부하를 나누고 있는 다른 데이터센터의 설정에 복제할 수 있는 툴이 있다면 좋을 것이다. 이를 위해서는 별개의 서버 네임과 새 IP 주소가 필요할 수 있다. 다른 데이터 센터의 애플리케이션 대칭을 모델화하는 방식이다. 다른 데이터 센터가 실패할 경우 필요한 기반을 여전히 제공하면서 말이다. 그러나 설정할 수 있는 제품의 유효한 경우의 수(valid permutation) 일체를 고려할 때, 이런 툴이나 마법사를 만든다는 것은 쉽지 않다.

따라서 인프라스트럭처 설정 메타데이터의 중앙화가 아주 중요하다. 패러미터의 중앙화와 버전화가 없다면, 배치한 애플리케이션과 지원 기반은 이후 표류하게 될 것이기 때문이다. 작은 설정상의 변경만으로 1차와 2차 로드 밸런싱 데이터 센터 모두에 문제가 초래될 수 있다. 설정 데이터를 버전화 하지 않았다면, 변경이 산출 오류를 초래할 때, 데이터 센터를 안정적인 상태로 환원하기가 어려울 수 있다.

이는 아키텍처의 핵심 요소들의 인증을 시사하기도 한다. 기업들은 데이터센터에 커널 소프트웨어나 운영 시스템의 가상화 장치 버전 같이 테스트를 마친 제품 설정만을 도입할 수 있도록 규정하는 정책을 확보해야 한다. 방화벽 하드웨어의 특정 버전만 다양한 데이터 센터에 배치될 수 있다.

또 다른 위험으로는 다양한 인프라스트럭처 구성요소에 대한 선택의 제약을 들 수 있다. 특정 단일 소프트웨어나 하드웨어만 고수하는 것을 예로 들 수 있다. 이런 하드웨어에 공통된 취약점이나 소프트웨어에 버그가 있다면 이는 여러 데이터센터 상에서 심각한 실패를 초래할 수 있다.

결론을 내리자면, 현재 기업들은 로드 밸런싱 아키텍처를 기반으로 애플리케이션을 배치해 재난 복구와 관련된 문제를 다루고 있다. 그러나 이런 해법이 인적 요소에서 비롯되는 실수, 특히 설정과 관련된 오류를 보호해주지는 못한다.

이를 해결하기 위해 기업들로서는 설정을 테스트하지 않거나, 설정 메타 데이터 버전화가 미흡해 초래되는 재난을 피하기 위해서 특정 가상 장치나 로드 밸런서 같이 인증된 구성요소를 도입할 수 있을 것이다. 또 설정 메타데이터를 중앙화 및 버전화 방식으로 보관할 수도 있다. 오류가 발생했을 때, 애플리케이션을 신뢰할 수 있는 설정으로 환원시킬 수 있도록 하기 위해서다. ciokr@idg.co.kr



2012.01.13

기고 | 클라우드와 재난복구, 로드 밸런싱 데이터센터만으로는 부족

Gregory Machler | CSO
클라우드 벤더용 재난 복구 서비스와 관련해 핫-콜드(Hot-Cold) 데이터센터 대신 로드 밸런싱 데이터센터를 활용하는 트렌드가 증가하고 있다. 기업들이 재난에 대비하기 위해 데이터센터 간 로드 밸런싱 기능을 갖춘 프라이빗 클라우드를 설치하고 있는 것이다. 이럴 경우 한 데이터센터에 재난이 닥치더라도 다른 데이터센터를 통해 제한적이나마 운영할 수 있게 된다.

그러나 여전히 문제들이 있다. 특정 애플리케이션 인프라의 다양한 설정을 추적해 따라잡기가 아주 어렵다. 각 애플리케이션마다 서버 네임을 만들고, 개방 IP 주소를 선택하고, DNS 매핑을 어드레스하고, 물리 서버와 가상 서버를 규정하고, 방화벽 규칙을 만들고, SAN과 NAS 설정을 규정하고, 로드 밸런싱 규칙을 이행하고, 데이터베이스 클러스터를 규정하기 마련이다.

게다가 개발, 테스트, 생산 등 각 환경에 따라 애플리케이션마다 이런 작업을 해야 한다. 이런 애플리케이션 설정의 상당수는 여러 웹기반 애플리케이션들에 의해 관리된다. 유지보수 애플리케이션은 통합되어 있지 않으며, 따라서 메타데이터 애플리케이션 설정들은 중앙화되어 있지 않다. 또 긴급한 이유로 이행 시점에 제품에 관리상의 변경이 적용될 수 있다. 변화 관리 시스템에 포착되는 않는 SAN 하위시스템이 한 예다. 따라서 메타데이터가 제때 반영되지 못하는 경우가 많다.

따라서 특정 데이터 센터의 설정을, 부하를 나누고 있는 다른 데이터센터의 설정에 복제할 수 있는 툴이 있다면 좋을 것이다. 이를 위해서는 별개의 서버 네임과 새 IP 주소가 필요할 수 있다. 다른 데이터 센터의 애플리케이션 대칭을 모델화하는 방식이다. 다른 데이터 센터가 실패할 경우 필요한 기반을 여전히 제공하면서 말이다. 그러나 설정할 수 있는 제품의 유효한 경우의 수(valid permutation) 일체를 고려할 때, 이런 툴이나 마법사를 만든다는 것은 쉽지 않다.

따라서 인프라스트럭처 설정 메타데이터의 중앙화가 아주 중요하다. 패러미터의 중앙화와 버전화가 없다면, 배치한 애플리케이션과 지원 기반은 이후 표류하게 될 것이기 때문이다. 작은 설정상의 변경만으로 1차와 2차 로드 밸런싱 데이터 센터 모두에 문제가 초래될 수 있다. 설정 데이터를 버전화 하지 않았다면, 변경이 산출 오류를 초래할 때, 데이터 센터를 안정적인 상태로 환원하기가 어려울 수 있다.

이는 아키텍처의 핵심 요소들의 인증을 시사하기도 한다. 기업들은 데이터센터에 커널 소프트웨어나 운영 시스템의 가상화 장치 버전 같이 테스트를 마친 제품 설정만을 도입할 수 있도록 규정하는 정책을 확보해야 한다. 방화벽 하드웨어의 특정 버전만 다양한 데이터 센터에 배치될 수 있다.

또 다른 위험으로는 다양한 인프라스트럭처 구성요소에 대한 선택의 제약을 들 수 있다. 특정 단일 소프트웨어나 하드웨어만 고수하는 것을 예로 들 수 있다. 이런 하드웨어에 공통된 취약점이나 소프트웨어에 버그가 있다면 이는 여러 데이터센터 상에서 심각한 실패를 초래할 수 있다.

결론을 내리자면, 현재 기업들은 로드 밸런싱 아키텍처를 기반으로 애플리케이션을 배치해 재난 복구와 관련된 문제를 다루고 있다. 그러나 이런 해법이 인적 요소에서 비롯되는 실수, 특히 설정과 관련된 오류를 보호해주지는 못한다.

이를 해결하기 위해 기업들로서는 설정을 테스트하지 않거나, 설정 메타 데이터 버전화가 미흡해 초래되는 재난을 피하기 위해서 특정 가상 장치나 로드 밸런서 같이 인증된 구성요소를 도입할 수 있을 것이다. 또 설정 메타데이터를 중앙화 및 버전화 방식으로 보관할 수도 있다. 오류가 발생했을 때, 애플리케이션을 신뢰할 수 있는 설정으로 환원시킬 수 있도록 하기 위해서다. ciokr@idg.co.kr

X