일정 경력 이상의 Engineer라면 Network Device에 대한 시험을 한 경험이 있었을 것입니다. 물론 지금 이 순간에도 TEST할 장비를 앞에 두고 머리를 감싸 쥐고 있는 분도 있겠구요.^^; 엔지니어라면 장비를 구입하는 입장에서 자사의 네트웍 환경과 요구수준에 일치하는 성능을 갖고 있는 지를 시험하기 위한 BMT(BenchMark Test)를 하는 경우도 있고, 네트웍 장비 개발 제조사에 몸 담고 있는 경우에는 자사가 개발한 장비의 완성도와 생산가능성 등을 염두해 두고 시험을 하게 됩니다.
삼척동자도 아는 얘기지만 ‘좋은 장비’ = ‘값 싸고, 안정적이고, 성능 좋은 장비’라는 공식이 있습니다. 쉬운 얘기 같지만 장비의 가격은 안정성과 성능에 반비례하는 경우도 있고, 뛰어난 성능을 가졌음에도 불구하고 안정적으로 가동되지 않아 운영에 누를 끼치는 장비도 있다 보니 딱히 ‘100% 좋은 장비다.’ 라고 할 수 있는 장비가 그리 흔치 않습니다.
이러한 이유로 구입측이나 개발/제조사 측에서도 여러 가지의 테스트가 있게 됩니다. 간혹 제게 이러한 시험에서 염두 해야 할 것이 무어냐고 물어보신다면 저는 아래 세 가지를 말씀 드리고 싶습니다.
- Reliability
믿을 수 있는 장비? 장비의 안정성을 신뢰할 수 있는가 로 생각하면 되겠습니다. 아무리 좋은 성능을 갖고 있는 장비라도 자주 hang-up 되거나 이유 없는 reset이 반복된다면 차라리 기능이 좀 떨어지더라도 안정적인 장비를 선택 하는 게 낳습니다. 이러한 Reliability Test를 위해서는 장시간 장비를 동작시켜 보는 Aging Test나 많은 Data Traffic이나 Error packet등을 발생시킨 가운데 장비의 상태를 살펴보는 Stress Test를 수행해 보는 것이 좋습니다. - Availability
기능과 성능에 대한 테스트입니다. 장비의 평균적인 성능, 최대한 낼 수 있는 성능, 기능의 정상적인 동작 여부 등을 시험하는 것입니다. 과연 이 Switch가 Main Switch로 12대 이상의 Workgroup을 연결하여 사용할 수 있는가? 과연 이 ADSL 모뎀은 전송 한계거리에서 계속적인 Negotiation loop를 하는가? 아니면 link out이 될 것인가? 장비의 성능 한계와 기능확인이 되지 않은 상태로 네트웍에 투입된 후에는 해결하기 어려운 문제들이 많기 때문에 사전에 시험해 볼 항목입니다. 물론 제조/개발사에서도 고객에게 신뢰를 줄 수 있는 Specification 공개를 위해서 꼭 해봐야 할 자체 테스트입니다. - Serviceability
‘사용하기 좋은가?’에 대한 테스트 입니다. 더 구체적으로 관리자가 Software적으로 관리하기 위한 User Interface는 편리한가? 외관 상의 접속 Interface가 불편하지는 않은가? 새로운 프로토콜의 적용 시 Hardware의 교체 없이 Software만 upgrade해서 사용할 수 있는가? 등의 시각으로 시험해 보는 것입니다.
장비의 외부 인터페이스의 편리성, 내구도 지원하고 있는 Software의 종류와 User Interface의 편리성 등을 집중적으로 시험해 보는 것입니다. 만일 어떤 Router의 CLI가 저장을 할 때 마다 무조건 Reboot을 하게 설계되어 있다면 그 Router를 사용하고 싶은 엔지니어가 있을까요? ^^;
시험 기준에 대한 이야기를 잠시 언급했습니다만 대부분의 네트웍 장비 시험은 기본과 원칙이 중요합니다. 시험 결과에 대한 신뢰도를 높이기 위해 애매모호함과 잘못된 시험방식을 배제 시켜야 하는데 이를 위해서는 수 차례에 따른 시행착오가 없이는 갖기 힘든 노하우입니다. 오늘은 네트웍 Tool에 대한 소개를 좀더 하고 다음 기회에 다시 한번 시험방법론에 대한 주제를 갖고 이야기하는 시간을 갖겠습니다.
(2) Netperf
지난 시간에 살펴본 Vital Agent의 경우 Client의 입장에서 송수신되는 Packet을 분석하여 performance를 측정하는 tool이었습니다. 오늘 소개하는 netperf의 경우 Server와 Client 측에 Demon과 Agent를 Active 시켜서 측정하는 방식입니다. Netperf의 경우 TCP와 UDP등 다양한 Packet 형태로 시험할 수 있다는 특징이 있습니다. 이외에도 source가 공개되어 있으므로 기본 사용 환경이 Uinx로 되어 있으나 손쉽게 Windows 환경에서도 사용할 수 있도록 porting하여 사용할 수 있습니다.(netperf windows용은 만들어지지 않았으며 사용하는 사람의 필요에 의해 본인이 porting해야 합니다. ^^;)
자세한 사용법은 아래 URL을 참고하셔서 사용하시기 바랍니다.
간혹 사이트 검색이 안되거나 Windows 기반의 프로그램이 필요하신 분을 위해 제가 Windows환경에 맞게 Win32s Compiling한 프로그램을 함께 올려드립니다. Visual C++에서 작업하며 여러 가지 Warning을 무시했으나 --; 사용에 큰 무리는 없을 것입니다. ^^;
(압축 파일을 풀면 netperf의 source 파일과 실행화일인 Netperf2.exe와 netserver.exe가 함께 들어 있습니다. Windows 환경 에서 사용하실 분은 Server로 사용할 PC에 netserver를 실행하여 Listen 상태로 만들고 Client 측에서 netperf2.exe 파일을 실행시키는 형태로 사용하시면 됩니다.)
{{ 첨부화일을 참고해 주시기 바랍니다. }}
[그림 1. netperf로 TCP Streaming test를 실행한 화면, 10초간 서버인 172.16.0.3과 TCP streaming Test를 수행한 성능 결과는 5.86 Mbps]
(3) Chariot
NetIQ사의 제품으로 여러 가지 Packet 테스트 이외에도 최근에는 VOIP 관련 시험 기능까지 추가된 Tool입니다. Software는 Console과 endpoint로 구성되며 Console에서 지시한 Tset를 endpoint가 수행 한 후 test 결과를 Console에게 제공하여 Console이 보고서 형태(화면, 파일)로 출력합니다.
여러 대의 장비에서 Concurrent test를 수행할 수 있으므로 Switch나 IP Based DSLAM의 성능시험 등에 많이 사용합니다. 사용하기 쉬운 인터페이스와 보고서가 잘 정리되어 만들어지므로 최근 Network 성능 시험 기관에서 많이 선호하고 있습니다.
이 tool의 경우 상용 S/W이며 Trial이 제공되고 있습니다. 관련된 세부 정보는 아래 URL을 통해 확인하시기 바랍니다.
[그림 2. chariot을 이용한 시험 결과 화면, 시험 측정결과 도표]
[그림 3. chariot을 이용한 시험 결과 화면, 시험 측정결과의 graph]
(4) MRTG (Multi Router Traffic Grapher)
엄밀하게 말하면 성능측정 tool이기도 하지만 장기간의 Data gathering을 통한 Monitoring Tool이라고 보는 게 맞겠습니다. 그러나 전용회선의 traffic을 관리하고 분석하는데 유용한 Tool이므로 이번 기회에 알아 보겠습니다.
일단 일반적인 전용회선 사용율의 공식을 알아보면 아래와 같습니다.
Leased Line Utilization = (Interface In Octets + Interface Out Octets) / Interface Capacity
공식은 간단하지만 1달, 30일, 24시간, 60분,… 지속적으로 관리자 눈으로 매번 확인할 수도 없는 것이고 매 번의 상황이 틀리므로 한 번의 측정결과 만으로 ‘전용회선 사용율이 이것이다.’ 라고 할수 없으니 신뢰할 정도의 Data를 꾸준히 모아두었다가 평균적인 값들을 살펴 보는 게 필요합니다. MRTG가 이러한 취지에 맞다 보니 광범위하게 많이 사용되고 있습니다. 물론 공짜이다 보니… ^^;
실제 Linux에 Install하여 사용하는 MRTG의 동작 방식을 살펴보면 cron Job에 일정 간격(5분 정도)으로 Router와 SNMP Request를 통해 필요 data(IfInOctets, IfOutOctets,…) 를 저장해 놓은 뒤 사용자의 Graph 출력요구가 있을 때마다 이 데이터를 httpd를 통해 html로 보여주는 방식입니다.
가끔 MRTG로 Switch나 DSLAM의 각 Port별 Performance를 보시는 분들이 있는데 이런 분들은 감점 50점입니다. --+ Tool 마다 특성이 있고 필요한 목적에 따라 사용해야 하는 법인데, MRTG보다는 SNMP manager 등의 Graph를 활용 하는 게 낳습니다. 하긴 회계 쪽에 일하시는 분 중엔 excel로 보고서 쓰는 분도 있고, 디자이너 중에는 Photoshop으로 발표자료 만드는 분도 있더군요? ^__^
[그림 4. MRTG로 본 전용회선 사용율의 Daily graph]
MRTG를 구하시는 분들은 아래 site를 참고해 주시기 바랍니다.
가끔 Linux에서 MRTG Install이 힘드시다는 분들이 있는데 대부분 Platform으로 깔려 있어야 할 C compiler나 gdlib 같은 library가 깔리지 않은 상태에서 install 하지 않아서 인 경우가 많았습니다. 차근차근 gnuzip에서부터 Install 해 보시면 Linux에 대한 이해도 높아지고 잘 해결할 수 있으니 네트웍 관리자라면 꼭 한 번 해보시길 권합니다. (MRTG의 경우 Windows Server O.S를 지원하는 것도 있습니다. 희소식?! --;)
MRTG를 이야기 하다 보니 전용회선의 적정 사용율에 대한 얘기를 안하고 넘어갈 수 가 없군요. 네트웍 업계에 종사하며 필자가 가장 많은 질문을 받았던 것이 아마도’E1 전용회선을 백본으로 사용할 때 과연 몇 가입자를 수용할 수 있나요?’ 였던 것 같습니다. 이러한 질문을 하는 사람들에게 그들이 원했던 것처럼 ‘50명이요, 70명이요’ 하고 대답을 못해주는 것이 참 안타까웠지만 굶주리는 이에게는 생선을 주는 것 보다는 생선을 잡는 법을 알려주는 것이 옳은 일이 아닌가. 싶어서 주절주절 설명을 했던 게 기억나는군요.
이 질문에는 서로가 만족시킬 수 없는 두 가지의 반비례 요소가 있습니다. 하나는 통신사업자(운영측)의 투자,운영비 측면이고 다른 하나는 고객(내부)의 서비스 만족도입니다. 전용회선 비용의 부담을 줄이기 위해 가입자를 늘려가다 보면 고객에게 만족할만한 대역폭을 제공할 수 없고 서비스 품질만을 생각해서 전용회선의 수를 무한정 늘리거나 그때마다 속도를 업그레이드 하기에는 서비스 제공자의 비용 부담이 큰 게 현실입니다.
따라서 백본 당 가장 적절한 수의 사용자를 수용하는 것이 옳을 것입니다. 그렇다면 이 적절한 수의 사용자는 어떻게 산출해야 하는가? 그리고 이러한 산출이 모든 사이트에 적용 가능한가? 물론 모든 사이트에 이러한 기준을 적용하기는 불가능합니다. 각 사이트 마다 그 기준이 틀려질 것이기 때문입니다. 예를 들어 자사의 홈페이지가 운영되고 있는 본사와 단순히 대리점의 업무를 위해 전용회선이 설치된 지방지사의 경우는 전용회선 사용경향이 많이 틀리겠지요?
백본 당 사용자의 적절한 가입자 수용 용량 산정의 첫번째 기준은 동시 사용 율 입니다. 총 가입자 중 몇 %의 가입자가 동시에 백본을 사용하는 지와 이러한 사용시 백본의 사용률이 100%대로 도달하여 지속되는 시간을 정확하게 파악하여야 합니다. 이러한 분석을 위해 MRTG(Multi Router Traffic Grapher)나 Cisco사의 Cisco works와 같은 Router 제조업체의 운영/분석 Tool을 사용하는 것이 효과적이겠습니다.
또한 위와 같은 분석은 지속적으로 진행되어야 하며 이를 기반으로 회선의 증설, Multi Link Protocol을 이용한 여러 개의 물리적 회선의 논리적인 대역폭 증설, Cache 서버의 적용 등의 다양한 솔루션을 적용하여 서비스를 개선 할 때 서비스 사업자는 적절한 투자비로 고객의 만족도를 이끌어 낼 수 있습니다.
그래도 굳이 몇 명이냐는 질문을 하시는 분들을 위해 전용회선 관리자들의 경험적인 기준을 말하자면 회선 투자비를 최소화하기 위한 기준에서는 한달간 평균 사용율이 33%를 넘어섰을 때 회선 증설을 하고, 서비스 품질 강화를 기준으로 회선 증설을 시행할 때는 한달간 평균 사용률이 15%를 상회하고 100%의 사용이 일주일 이상 나타났을 때를 기준으로 하는 경우가 많음을 귀뜸 해 둡니다
댓글 없음:
댓글 쓰기