2013.03.22

테스트 안 했다고? 그럼 배치하지 마라

Paul Venezia | InfoWorld
IT 부문에서 새로운 인프라를 구축하고 이를 생성 시스템에 적용하는 것만큼 보람찬 일도 없겠지만, 그만큼 쉽지 않은 것도 사실이다.
 
요즘에는 가상화(Virtualization) 덕분에 예전보다 많이 용이해지긴 했지만 자신의 노력을 통해 탄탄하고 신뢰할 수 있는 하나의 자원이 만들어지는 모습을 볼 수 있는 것은 여전히 흥미로운 일이다. 세상이 완벽하고 모든 것이 완벽하게 모든 측면에서 계획한 대로 필요에 따라 정확하게 실행된다면 최종 결과물은 언제든지 즉시 업무에 적용할 수 있을 것이다.
 
하지만 실제로는 이렇게 말처럼 쉽지 않다는 것을 모두가 알고 있다.
 
이번 기사에서는 새로운 가상화 클러스터(Cluster)를 하나의 예로 들겠지만, 이는 네트워크 계층부터 애플리케이션 계층까지 거의 모든 IT에 적용된다.
 
구축하는데 기본적인 사항은 다소 정형화되어 있다. 자신이 선택한 서버, 스위치(Switch), 스토리지(Storage) 하드웨어를 한 곳에 모으고 모든 것을 연결하는 것이다.
 
구축을 진행하면서 예상하지 못한 드라이브 호환성 문제 또는 소프트웨어 스택(Stack)의 버그 등 불시의 문제가 발생하지 않고 본래의 디자인이 그대로 실현되기를 바랄 뿐이다. 심지어 모든 과정이 계획에 따라 진행되고 모든 것이 준비가 완료된 듯 보여도 아직 갈 길이 멀다. 이제 걸음마를 뗀 것이다.
 
왜냐하면 이제는 구축된 시스템에 대한 100% 확신이 들 때까지 사소한 문제들을 모두 해결해야 하기 때문이다. 그리고 절대로 100%를 확신할 수 없다.
 
긴 터널의 끝에 빛이 보인다면 걸음이 빨라지는 것이 인간의 본성이며, 여행이 끝나가거나 목표가 가까워질 때면 인간은 서두르게 마련이다. 처음에는 체계적이고 공을 들이지만, 끝이 다가오면 무해한 것으로 생각되거나 사소한 것들은 쉽게 지나치게 마련이다.
 
여기에 복병이 숨어 있다.
 
새로운 가상화 클러스터 구축을 예로 들어본다. 일반적으로 구형 클러스터를 더 크고 향상되고 빠른 클러스터로 대체해 1G에서 10G로 옮겨가며 상대적으로 느린 스토리지를 더욱 빠른 스토리지로 교체하고, 심지어 클로버타운(Clovertown)에서 샌디 브리지(Sandy Bridge)로 업그레이드 할 수 있다.
 
새로운 장비는 모든 것을 쉽게 빠르게 처리하며, 대부분은 이를 학수고대하고 있다. 포트(Port)에 배선을 연결하고 스위치를 설명하며 스토리지를 초기화하고 공유 및 LUN(Logical Unit Numbers)을 생성하는 등 현대적인 가상화 기술이 상대적으로 빠른 속도로 배치된다. 단, 쿠키용 틀처럼 그 디자인이 완벽할 때 얘기다.
 
소수의 테스트용 VM을 구축하면, 그 빠른 속도와 반응성으로 인해 기존의 VM은 무용지물이 되어 버린다. 겉으로 보기에는 완벽하게 작동하며, 간단한 테스트 결과도 믿음직하다. 이 때, 시스템을 본 서버에 투입하고 싶은 욕망이 살아나지만, 현명한 사람이라면 본 서버에 적용하기에 앞서 모든 요소에 대해 며칠 또는 몇 주간 포괄적인 테스트를 진행한다.
 
우선은 클러스터의 모든 호스트(Host)로부터 스토리지를 엄격하게 시험해봐야 한다. 다행히도 가상화의 경우는 이 작업이 매우 간단하다.
 
신속한 리눅스 VM 빌드와 보니++(Bonnie++)를 사용하는 스크립트 또는 심지어 dd로 루프(Loop)를 수행하고 전체 구조를 필요한 만큼 클론(Clone)하여 클러스터의 각 물리적 호스트에 상당한 부하를 가하고 스토리지에서 계획한 모든 LUN 또는 공유를 시험한다.
 
무작위 잠자기 시간을 통해 스트리밍 읽기와 쓰기의 무작위 작업부하를 생성하거나 또는 무작위 읽기와 쓰기를 통해 무작위 작업 부하를 생성하는 등 원하는 테스트를 실시한다.
 
스토리지 하부 시스템에 더 큰 부하를 가하고 싶다면, 몇 가지 좋은 방법이 있다. 며칠 동안 추이를 지켜보면서 네트워크 또는 스토리지 오류가 없음이 확인되면, 부하를 증가시켜야 한다.
 
토스 넷퍼프(Toss Netperf) 또는 유사한 네트워크 스트레스 툴로 가상머신(VM)을 테스트하고 VM 사이의 테스트 시간을 달리해 다양한 크기와 부하로 TCP 트래픽을 무작위 발생시키는 간단한 스크립트를 작성하며 같은 방식으로 루프를 실시한다. 이를 스토리지 작업부하와 동시에 진행한다.
 
여기에 몇 가지 더 추가하고 싶다면, 가상화 CPU와 RAM이 많은 VM을 추가로 생성하고 CPU 및 RAM 스트레스 테스트를 실시하면 된다. 이 때, CPU부터 스토리지까지 그리고 RAM부터 네트워크까지 클러스터의 모든 측면을 시험할 수 있어야 한다. 무엇인가 문제가 발생하면, 이론적으로는 이런 곳에서 문제가 발생해야 한다.
 
테스트는 실제로 문제가 쉽게 발생할 것 같은 부분부터 시작하면 된다. 호스트의 전원을 차단해 적절한 정전 조치가 실시되는 지도 확인한다. 자동화된 호스트 업그레이드 프로세스를 구동하고 면밀히 살핀다. 네트워크 케이블을 잡아 당겨보거나 관련된 스위치 포트를 끊어 결합 및 시스템 대체작동 네트워크 연결이 제대로 작동하는지 확인한다.
 
또한 이 모든 것이 부하 테스트 가운데 제대로 이뤄지는지 확인하는 것이 가장 중요하다.
 
새로운 장비를 시험해 약점과 구멍을 찾아내는데 있어서는 이것만큼 좋은 방법이 없다. 누구나 이 방법을 사용해서 장점을 취할 수 있다. 우선, 이를 통해 생산 작업부하로 전환하더라도 마음의 여유를 얻을 수 있으며, 초기에 잡지 못한 문제로 인해 생산에 차질이 생겨 문제를 해결하는 것보다 훨씬 쉽다.
 
그래서 테스트는 많이 할수록 좋은 것이다. 모든 하부 시스템과 구성요소에 스트레스를 가하는 창의적인 방법을 고안하고 합리적인 시험 기간이 지난 후 모든 것을 생산에 투입하는 것이 좋다.
 
빛은 터널 끝에 도착할 때까지 기다릴 것이며, 이전보다 더욱 밝고 따뜻할 것이다. editor@itworld.co.kr



2013.03.22

테스트 안 했다고? 그럼 배치하지 마라

Paul Venezia | InfoWorld
IT 부문에서 새로운 인프라를 구축하고 이를 생성 시스템에 적용하는 것만큼 보람찬 일도 없겠지만, 그만큼 쉽지 않은 것도 사실이다.
 
요즘에는 가상화(Virtualization) 덕분에 예전보다 많이 용이해지긴 했지만 자신의 노력을 통해 탄탄하고 신뢰할 수 있는 하나의 자원이 만들어지는 모습을 볼 수 있는 것은 여전히 흥미로운 일이다. 세상이 완벽하고 모든 것이 완벽하게 모든 측면에서 계획한 대로 필요에 따라 정확하게 실행된다면 최종 결과물은 언제든지 즉시 업무에 적용할 수 있을 것이다.
 
하지만 실제로는 이렇게 말처럼 쉽지 않다는 것을 모두가 알고 있다.
 
이번 기사에서는 새로운 가상화 클러스터(Cluster)를 하나의 예로 들겠지만, 이는 네트워크 계층부터 애플리케이션 계층까지 거의 모든 IT에 적용된다.
 
구축하는데 기본적인 사항은 다소 정형화되어 있다. 자신이 선택한 서버, 스위치(Switch), 스토리지(Storage) 하드웨어를 한 곳에 모으고 모든 것을 연결하는 것이다.
 
구축을 진행하면서 예상하지 못한 드라이브 호환성 문제 또는 소프트웨어 스택(Stack)의 버그 등 불시의 문제가 발생하지 않고 본래의 디자인이 그대로 실현되기를 바랄 뿐이다. 심지어 모든 과정이 계획에 따라 진행되고 모든 것이 준비가 완료된 듯 보여도 아직 갈 길이 멀다. 이제 걸음마를 뗀 것이다.
 
왜냐하면 이제는 구축된 시스템에 대한 100% 확신이 들 때까지 사소한 문제들을 모두 해결해야 하기 때문이다. 그리고 절대로 100%를 확신할 수 없다.
 
긴 터널의 끝에 빛이 보인다면 걸음이 빨라지는 것이 인간의 본성이며, 여행이 끝나가거나 목표가 가까워질 때면 인간은 서두르게 마련이다. 처음에는 체계적이고 공을 들이지만, 끝이 다가오면 무해한 것으로 생각되거나 사소한 것들은 쉽게 지나치게 마련이다.
 
여기에 복병이 숨어 있다.
 
새로운 가상화 클러스터 구축을 예로 들어본다. 일반적으로 구형 클러스터를 더 크고 향상되고 빠른 클러스터로 대체해 1G에서 10G로 옮겨가며 상대적으로 느린 스토리지를 더욱 빠른 스토리지로 교체하고, 심지어 클로버타운(Clovertown)에서 샌디 브리지(Sandy Bridge)로 업그레이드 할 수 있다.
 
새로운 장비는 모든 것을 쉽게 빠르게 처리하며, 대부분은 이를 학수고대하고 있다. 포트(Port)에 배선을 연결하고 스위치를 설명하며 스토리지를 초기화하고 공유 및 LUN(Logical Unit Numbers)을 생성하는 등 현대적인 가상화 기술이 상대적으로 빠른 속도로 배치된다. 단, 쿠키용 틀처럼 그 디자인이 완벽할 때 얘기다.
 
소수의 테스트용 VM을 구축하면, 그 빠른 속도와 반응성으로 인해 기존의 VM은 무용지물이 되어 버린다. 겉으로 보기에는 완벽하게 작동하며, 간단한 테스트 결과도 믿음직하다. 이 때, 시스템을 본 서버에 투입하고 싶은 욕망이 살아나지만, 현명한 사람이라면 본 서버에 적용하기에 앞서 모든 요소에 대해 며칠 또는 몇 주간 포괄적인 테스트를 진행한다.
 
우선은 클러스터의 모든 호스트(Host)로부터 스토리지를 엄격하게 시험해봐야 한다. 다행히도 가상화의 경우는 이 작업이 매우 간단하다.
 
신속한 리눅스 VM 빌드와 보니++(Bonnie++)를 사용하는 스크립트 또는 심지어 dd로 루프(Loop)를 수행하고 전체 구조를 필요한 만큼 클론(Clone)하여 클러스터의 각 물리적 호스트에 상당한 부하를 가하고 스토리지에서 계획한 모든 LUN 또는 공유를 시험한다.
 
무작위 잠자기 시간을 통해 스트리밍 읽기와 쓰기의 무작위 작업부하를 생성하거나 또는 무작위 읽기와 쓰기를 통해 무작위 작업 부하를 생성하는 등 원하는 테스트를 실시한다.
 
스토리지 하부 시스템에 더 큰 부하를 가하고 싶다면, 몇 가지 좋은 방법이 있다. 며칠 동안 추이를 지켜보면서 네트워크 또는 스토리지 오류가 없음이 확인되면, 부하를 증가시켜야 한다.
 
토스 넷퍼프(Toss Netperf) 또는 유사한 네트워크 스트레스 툴로 가상머신(VM)을 테스트하고 VM 사이의 테스트 시간을 달리해 다양한 크기와 부하로 TCP 트래픽을 무작위 발생시키는 간단한 스크립트를 작성하며 같은 방식으로 루프를 실시한다. 이를 스토리지 작업부하와 동시에 진행한다.
 
여기에 몇 가지 더 추가하고 싶다면, 가상화 CPU와 RAM이 많은 VM을 추가로 생성하고 CPU 및 RAM 스트레스 테스트를 실시하면 된다. 이 때, CPU부터 스토리지까지 그리고 RAM부터 네트워크까지 클러스터의 모든 측면을 시험할 수 있어야 한다. 무엇인가 문제가 발생하면, 이론적으로는 이런 곳에서 문제가 발생해야 한다.
 
테스트는 실제로 문제가 쉽게 발생할 것 같은 부분부터 시작하면 된다. 호스트의 전원을 차단해 적절한 정전 조치가 실시되는 지도 확인한다. 자동화된 호스트 업그레이드 프로세스를 구동하고 면밀히 살핀다. 네트워크 케이블을 잡아 당겨보거나 관련된 스위치 포트를 끊어 결합 및 시스템 대체작동 네트워크 연결이 제대로 작동하는지 확인한다.
 
또한 이 모든 것이 부하 테스트 가운데 제대로 이뤄지는지 확인하는 것이 가장 중요하다.
 
새로운 장비를 시험해 약점과 구멍을 찾아내는데 있어서는 이것만큼 좋은 방법이 없다. 누구나 이 방법을 사용해서 장점을 취할 수 있다. 우선, 이를 통해 생산 작업부하로 전환하더라도 마음의 여유를 얻을 수 있으며, 초기에 잡지 못한 문제로 인해 생산에 차질이 생겨 문제를 해결하는 것보다 훨씬 쉽다.
 
그래서 테스트는 많이 할수록 좋은 것이다. 모든 하부 시스템과 구성요소에 스트레스를 가하는 창의적인 방법을 고안하고 합리적인 시험 기간이 지난 후 모든 것을 생산에 투입하는 것이 좋다.
 
빛은 터널 끝에 도착할 때까지 기다릴 것이며, 이전보다 더욱 밝고 따뜻할 것이다. editor@itworld.co.kr

X