About DATABASE

지난 호에서는 용량 계획 테스트를 하기 위한 준비 작업과 WAS의 설정 방법, 그리고 이를 이용해 실제로 성능과 용량 테스트를 했다. 이번 호에는 성능 모니터를 통해 어떤 개체들에 어떤 카운터를 설정해야 하는지, 또 어떤 기준으로 데이터를 분석해야 하는지 알아보도록 하자.

우선적으로 성능 테스트 환경을 구성해 보자. 지난 연재에서 WAS 사용 방법에 대해 다뤘고 이제 WAS의 웹 브라우저 레코딩 방식을 사용할 것이다.

테스트 사이트에 실제로 접속자들이 홈페이지에 접속하고 회원 가입한 후 로그인하고, 여러 가지 물건을 살펴볼 것이다. 그리고 물건이 마음에 든다면 구매할 것이고, 혹은 게시판에 궁금한 사항을 문의할 수도 있다. 또한 테스트 사이트에서 내가 직접 사용자가 된 입장으로 웹사이트 여기저기를 방문해 볼 것이다. 전체적인 부분을 보려고 한다면 사이트의 모든 컨텐츠들을 기록해야 한다. 테스트 환경을 어떻게 소화하느냐는 전적으로 이 글을 읽는 독자들에게 달렸다. 한가지 아쉬운 점은 물건을 구매하고 그것이 결제가 이뤄지는 일련의 과정은 테스트가 불가능하다. 여러 가지 절차가 있는데, 이 절차를 만들기가 불가능하기 때문에 이 부분은 생략하도록 하겠다.

독자분들은 모든 프로덕트 환경을 만들고 그에 준하는 테스트 환경을 만들 수 있다. 여기서 WAS는 3대의 클라이언트에 동시 접속하는 환경을 만들 것이며, 각각의 클라이언트는 30초 간격으로 사용자들이 접속하는 것으로 설정하도록 하겠다. 클라이언트 환경은 이렇게 설정하고, 서버에서는 성능 모니터의 로그를 설정할 것이다.

성능 로그를 미리 생성해 놓고 클라이언트 접속 시점 바로 전부터 걸어도 되지만, 서버의 모든 설정을 끝내 놓고 평상시의 성능 로그를 분석할 필요도 있다. 보기 드문 경우지만 간혹 CPU와 메모리의 불량을 볼 수도 있기 때문이다.

이에 성능 모니터의 로그 결과물을 볼 수 있다. 이 결과물을 토대로 서버 용량의 한계가 어디까지인지, 어느 시점에서 메모리, CPU, 하드디스크 혹은 RAID 도입을 결정해야 하는지를 알아보도록 하자. 서버 교체 시점도 같이 파악하도록 할 것이다.

성능 모니터

성능 모니터는 관리자가 병목 문제나 장애 문제를 파악할 수 있는 가장 보기 좋은 도구다. 보기 좋다는 것은 이해하기 쉽다는 것이고, 프로그램으로 말한다면 고급 언어(High Level Language)인 셈이다. 그렇다면 저수준 언어(Low Level Language)에 해당하는 것도 있을까? 있다. 덤프(Dump)라고 많이 들어봤을 것이다. 이것이 어셈블리와 같이 서버에서 본다면 저 수준에 속한다.

사실 윈도우 서버의 성능 모니터 툴은 용량을 계획할 때 데이터를 추출할 수 있는 좋은 도구지만, 일반적으로는 서버의 장애나 병목을 파악할 때 사용하는 도구로 제작된다. 왜냐하면 성능 모니터의 카운터들이 문제 발생을 파악하는데 기준이 되기 때문이다.

성능 모니터는 컴퓨터→성능 개체→카운터→인스턴스 순으로 세부적으로 들어간다. 많은 카운터들이 병목을 판단하기 위한 자료가 되지만, 몇몇 카운터는 접속 현황이라든지 사용량을 나타내므로 이런 기준들을 잘 조합해서 용량 계획에 대한 데이터 기준을 만들어 낼 것이다.

예를 든다면 이 서버의 접속자가 몇 명이 될 때 서버의 한계가 될 것인가? 하는 기준을 제시한다. 성능 모니터에서 추가하는 개체가 어떻게 구성되고 동작하는지를 알면 조금 더 쉽게 접근할 수 있기 때문에 우선적으로 용량 계획이라는 관점보다 성능 모니터 도구 본연의 임무쪽으로 설명하도록 하겠다.

성능 모니터는 여러 가지 데이터가 복합적인 판단에 의해 결과가 나와야 한다. CPU가 몇  십분, 몇 시간 동안 계속해서 임계치 값이 70∼80% 이상 유지한다고 해서 'CPU가 병목이네'라고 판단하고 CPU를 싱글에서 듀얼로, 또는 4웨이로 확장한다고 해서 만족할만한 성능을 얻을 수 있는 것은 아니다. 

CPU 사용률이 임계치값 이상의 사용률을 보이고 있다면 그 원인을 파악해야 하고, 원인 파악은 다른 성능 개체를 통해서 이뤄진다. 하나의 개체가 병목이라고 해당 개체의 사이징(sizing)을 잡고 확장한다면 그것은 잘못된 판단이다. 이 부분은 애플리케이션을 수정해서 해결할 수도 있고, 메모리나 디스크를 교체해서 병목을 해결할 수도 있다. 계획적이고 올바른 사이징은 병목을 예방하는 하나의 방법임을 기억해 두길 바란다.

성능 모니터를 어떻게 설정하는 것이라는 방법론, 즉 툴을 다루는 법에 대해서는 언급하지 않겠다. 그렇게 어렵지 않은 부분이고 설정에 대한 부분은 마이크로소프트 기술 사이트나 여러 방법으로 쉽게 얻을 수가 있다. 어려운 것은 어떤 개체의 어떤 카운터를 설정하고, 어떤 기준으로 그 데이터를 분석할 것이냐 하는 것이다.

용량 테스트 전 성능 모니터 설정 사항

다시 한번 강조하지만 성능 모니터의 개체, 카운터 그리고 인스턴스는 WAS를 수행하기 전에 로그로 설정해 놔야 한다. 그래야 WAS 테스트 환경에서 접속에 대한 성능 로그를 볼 수가 있다. 개체에 대해서는 그 개체가 어떤 방법으로 동작하는지에 대해 설명할 것이다. 

개체가 어떻게 돌아가는 지를 알면 서버를 운영하는데도 많은 도움이 될 것이다. 카운터에서는 카운터가 어떤 것이며, 이 카운터의 임계치 값을 명시할 것이다. 용량 계획을 위한 카운터 값은 수집이 목적이지만 병목을 판단해야 하는 카운터 값은 임계치를 알아야 한다. 아무리 찾아봐도 그 카운터의 일반적인 임계치 값에 대해 명시가 안된 것이 있다. 이 부분은 결과물이 나온 후 어느 정도면 해당 카운터의 현재 임계치 값이 얼마인지를 제시한다. 웹서버는 INETINFO와 DLLHOST라는 프로세스가 분석 타겟이 된다. MS SQL은 MS SQL에 관련된 프로세스가 분석될 것이다. 그러면 개체와 카운터에 대해 알아보자.

가상메모리의 원리

일반적인 컴퓨터의 메모리를 지칭하면 보드의 메모리 뱅크에 꽂혀있는 물리적인 메모리, RAM을 지칭한다. 이런 RAM은 속도를 극복하려는 많은 변화가 있었으며, SIMM, DIMM에서 SDRAM 그리고 DDR 방식으로 핀수도 갈수록 많아졌다. 그러나 서버에서 메모리를 지칭할 때면 약간 다른 관점에서 봐야 한다. 물론 클라이언트들이 주로 쓰는 운영체제인 윈도우 프로페셔널이나 XP 같은 경우에도 가상 메모리라고 하는 것이 있지만 이런 운영체제에 대해 가상 메모리가 어떻게 동작을 하는지 사용자들은 별 관심이 없고 알 필요도 없다.

본인의 PC가 어느 순간 느려지거나 이상이 발생하면 그 피해는 자기 자신만 주어지지만 서버에서 그런 현상이 발생하면? 그 영향는 서버를 사용하는 모든 사용자들에게 돌아간다. 이런 이유로 그 서버를 관리하는 사람이면 메모리가 어떻게 운영되는지를 알아야 문제가 생겼을 때 문제 발생 원인과 해결책을 제시해 줄 수 있다. 윈도우 서버의 많은 장애 가 메모리에 기인하고 있는 이유는 애플리케이션 때문이다. 비율로 얘기를 한다면 80% 이상으로 말할 수 있다.

윈도우 서버에서 메모리를 모니터링할 때에는 RAM과 가상 메모리가 같이 모니터링되고 있음을 알아야 한다. RAM의 한 부분으로 운영되는 것이 가상 메모리(PAGING FILE)이고, 이것의 위치는 하드디스크에 있기 때문이다. 메모리의 문제가 생기면 대부분 애플리케이션에서 문제가 발생된다. 간혹 디스크만을 모니터링하고 있다면 디스크의 병목 현상도 볼 수 있다. 이것은 디스크의 성능 문제가 아니고 잘못된 애플리케이션으로 인해 페이지 폴트가 일어나기 때문에 디스크의 병목 현상으로 보이는 것이다.

시스템에 관련된 프로세스들은 주로 RAM에 상주한다. 중요하고 자주 쓰이기 때문에 빠른 처리 속도가 필요하기 때문이다. 그러나 애플리케이션들은 사용자의 필요에 의해 쓰이는 것이고 자주 쓰는 것이 아니기 때문에 RAM에 상주할 필요는 없다.

시스템을 재부팅하고 나서 바로 작업관리자를 띄워서 살펴보자. 자주 보는 그림이기 때문에 그림 삽입은 하지 않겠다. 메모리 사용 내용이라는 그래프 밑에 보면 네 개의 파트가 있다. 이중 실제 메모리라고 하는 것은 RAM을 나타내는 것이며, 부과 메모리라고 하는 것은 가상 메모리를 나타낸다. 메모리 사용 내용이라는 그래프는 부과 메모리라고 하는 가상 메모리의 변화량을 보여주고 있는 것이다.

참고적으로 가상 메모리는 c:에 위치하는 것이 기본이고(관리자에 의해서 C: 아니 다른 파티션으로 변경 가능), 가상 메모리의 크기는 RAM의 1.5배∼3배의 크기로 기본적으로 윈도우 서버가 설정을 하지만 관리자가 변경할 수는 있다. 그러나 권장 사항은 아니다. 가상 메모리를 늘리려면 RAM을 추가하라고 권장하고 싶다.

재미있는 예를 한번 들어보자. A와 B서버 두 대 있다. A서버의 RAM은 1GB이고, B 서버의 RAM은 8GB이다. A서버의 가상 메모리 크기는 1.5∼3배로 설정이 되므로 1.5G∼3G로 설정될까? 맞다. 그렇게 설정된다. B서버의 가상 메모리 크기도 역시 1.5∼3배로 설정이 되므로 12G∼24G로 가상 메모리가 설정이 될까? 아니다 틀린 답이다. 윈도우 서버의 RAM을 8G, 16G, 32G의 RAM을 설정한다고 해도 가상 메모리의 크기는 4G 이상을 못 넘어간다. 윈도우 서버에서는 가상 메모리의 최대 크기는 4G이고, 4G 중 커널용으로 2GB의 공간이 예약, 사용자 모드 프로세스용으로 2GB가 설계돼 있다.

MS DOS를 기억하는 분들이 많을 것이다. 실제 메모리 한계를 640KB로 제한돼서 설계가 됐다. 그때 설계한 사람이 설마 애플리케이션들의 덩치가 그렇게 커질지 간과한 것이다. 새로운 애플리케이션들이 쏟아지면서 메모리 크기가 심각한 문제가 됐다. 그래서 확장 메모리(Extended Memory)를 config와 autoexec에 설정해서 사용했다.

참고적으로 가상 메모리의 사용 크기를 사용자 모드 프로세스용으로 더 할당하고 싶다면 c:boot.ini의 /3GB라는 플래그를 사용하면 커널용으로 1GB, 사용자 모드 프로세스용을 3GB가 할당되고, 이와 같은 설정은 MS SQL, 익스체인지에서 효과를 볼 수 있다. 웹서버는 추천하고 싶지 않다.

이제 가상 메모리가 어떻게 동작하는지 간단하게 살펴보자. 애플리케이션이 로드되면 사용자 파일을 실행하고 난 후 필요한 데이터만 RAM에 남고 나머지는 가상 메모리에 상주한다. 이렇게 구분하는 역할을 담당하는 것이 커널단의 메모리 관리자가 하는 작업이다.

메모리 관리자는 가상 메모리에서 어떤 것이 중요하고 중요하지 않은가를 어떻게 판단할까? 중요하지 않은 것을 버려야 할 상황도 발생할 수 있다. 이럴 때 어떤 기준을 가지고 처리할까? 이 부분은 아래 'Basic algorithm of the Memory'를 참고하면 되겠다.

가상 메모리에 영원하게 상주하느냐? 그건 아니다. 가상 메모리에서 필요한 데이터가 있다면 RAM으로 이동해야 하는데, 이럴 때는 어떻게 처리될까? 프로세스가 '몇 번지(0x80000000)에 있는 데이터가 필요해'라고 메모리 관리자에게 요청을 했는데, RAM의 해당 번지에 데이터가 없다면 이 주소의 데이터는 메모리 관리자에 의해 가상 메모리로 이동한다. 그렇기 때문에 메모리 관리자는 페이지 오류라는 알고리즘을 통해 재빨리 해당 데이터를 프로세스가 요청한 주소로 옮겨 놓는다. 프로세스 입장에서 보면 자기가 요청한 데이터를 RAM에서 가져오는 것으로 보이지만, 실제적으로는 하드디스크에 있는 가상 메모리에서 데이터가 옮겨져 왔다는 것을 여러분은 알 것이다.

컴퓨터의 속도를 비교하면 보통 CPU>RAM>HDD의 순서로 그 속도가 구분된다. 느린 하드디스크에서 데이터를 끌어온다는 것은 컴퓨터의 속도 면에서 아주 손실이 많은 부분이다. 서버를 운영하면서 가상 메모리에서 RAM으로 이동(페이징) 작업을 피할 수는 없지만 그 횟수를 줄인다면 서버 성능의 향상 효과를 크게 볼 수가 있다. 잘못 제작된 ASP나 COM+ 등 기타 애플리케이션이 서버를 다운시키는 것을 자주 봤다. 그 실제의 예를 성능 모니터의 마지막 부분에서 보여주도록 하겠다.

※ Basic algorithm of the Memory

① FIFO(First-In-First-Out) : FIFO는 먼저 들어온 것이 먼저 나간다라는 알고리즘이다. X86 기반의 멀티프로세서 시스템에 적용되는데, 최근에 사용된 시기와 상관없이 RAM에 가장 오래 있던 데이터가 페이징 파일로 이동한다는 것이다.

② LRU(Least Recently Used)와 MRU(Most Recently Used) : LRU는 최근에 사용된 데이터에 사용된 시기를 분석해 한동안 사용되지 않은 데이터를 페이징으로 이동시키는 알고리즘이고, MRU는 가장 많이 사용하는 메모리 영역이다. X86 기반의 단일 프로세서 시스템에 적용된다.

이 두 알고리즘을 통해 최근에 가장 많이 사용하는 RAM 데이터나 최근에 사용된 데이터는 RAM에 존재하고, 그 이외의 메모리 페이지들은 가상 메모리로 이동한다.

메모리 개체 카운터 설정

① Available Bytes(임계값 : 전체 메모리 크기의 5% 이하일 때)
실행중인 프로세스의 작업 설정과 캐시에서 필요로 하는 정보를 취한 다음 남아있는 RAM의 크기를 말한다. 쉽게 말하면 사용 가능한 RAM이 얼만큼 남았는지 알 수 있는 카운터다. 일반적으로 Available Bytes가 적고 메모리/pages/sec가 높다면 메모리를 추가해야 한다. 이 말은 RAM이 사용할 수 있는 공간이 적기 때문에 RAM의 데이터를 가상 메모리로 보내고 프로세스가 호출한 메모리의 페이지를 가상 메모리에서 불러왔기 때문이다. 실제로 사용할 수 있는 RAM의 공간은 0으로, 채워져 있거나 비워있거나 대기중인 메모리 목록에 있는 공간을 합쳐 계산한다. 빈 메모리는 사용할 준비가 된 메모리고, 0으로 채워진 메모리는 다음 프로세스가 이전 프로세스에서 사용된 데이터를 보지 못하도록 0으로 채워진 메모리 페이지다. 대기 메모리는 프로세스 작업 집합(실제 메모리)에서 제거돼 디스크로 라우트됐지만, 다시 호출돼 사용될 수 있는 메모리를 말한다.

② Committed Bytes(임계값 : Committed Bytes In use%로 판단)
RAM에 제휴된 가상 메모리의 크기를 나타낸다. 이 말은 프로세스는 RAM에만 존재하는 것이 아니고 가상 메모리에도 존재한다. 즉 데이터가 디스크로 페이징돼야 하는 경우, 페이징 파일에서 필요한 공간인 RAM의 양을 기록한다. 이 말은 사용중인 메모리이며 다른 프로세스는 사용할 수 없고 고정됐으며 사용되는 메모리량이다. Available Bytes가 크면 Committed Bytes가 작아지고, 반대로 Available Bytes가 작으면 Committed Bytes가 커진다.

③ Page/sec(임계값 : 80 이상)
RAM에서 사용할 수 없는 애플리케이션과 RAM에 다른 페이지 공간을 만들기 위해 하드디스크에서 읽거나 기록해야 하는 애플리케이션을 실행하기 위해 요청된 메모리의 페이지 수를 말한다. Page Faults/sec을 보면 쉽게 이해할 수가 있다. 한번 더 강조한다면 프로세스가 RAM에서 관련 주소를 호출했다. 이것이 RAM에 없다면 가상 메모리에 있기 때문에 메모리 관리자는 가상 메모리가 있는 디스크로 액세스해야 한다. 이 말은 페이징 파일을 사용했다는 말과도 같다. 즉, 초당 페이징 파일을 몇 번 사용했느냐 또는 가상 메모리에서 RAM으로 몇 번 올라오느냐를 말한다. 일반적으로 이 수치는 초당 30이 넘으면 과부하가 온다고 한다. 그러나 이것 하나만 놓고 본다면 잘못된 판단을 불러올 수 있다. CPU의 사용량과 Available Bytes와 연계해 볼 필요가 있다. Available Bytes는 많이 있는데 Page/sec가 많다면 이것은 실제 메모리가 부족한 것이 아니고 애플리케이션이 메모리를 잘못 관리하는 경우라고 볼 수 있다.

④ Page faults/sec(임계값 : 일반적으로 200 이상, 웹서버인 경우 180~300 이상)
프로세스에서 작업 설정의 일부인 RAM을 사용하려고 하지만 찾을 수가 없는 경우, 메모리 관리자는 페이지 오류를 발생시키고 디스크의 가상 메모리에서 다시 불러들이는 경우를 나타낸다. 페이지 오류는 크게 하드 폴트(가상 메모리 액세스를 필요로 하는 경우), 소프트 폴트(RAM에 폴트된 페이지가 있는 위치) 등이 있고 자세한 폴트의 내용은 다음과 같다.

- 메모리에 상주하는 페이지가 아니라 디스크의 페이지 파일 또는 맵파일에 액세스하는 경우
- 대기 중이거나 수정목록에 있는 페이지에 액세스하는 경우
- 커밋되지 않은 페이지에 액세스하는 경우
- 커널 모드에서만 액세스 될수 있는 페이지에 사용자 모드로부터 액세스하는 경우
- 읽기 전용인 페이지에 쓰는 경우

폴트라고 하면 실수를 말하는데, 대부분의 프로세서가 별무리 없이 많은 수의 소프트 폴트를 처리할 수 있다. 그러나 디스크를 액세스하는 하드 폴트의 경우는 심각한 성능 문제를 일으킬 수 있다. 즉, CPU와 메모리의 처리 속도와 CPU와 하드디스크의 속도는 엄청나게 차이가 난다. 하드 폴트가 많이 일어나 디스크의 병목 현상이 일어나고, 이로 인해 CPU가 대기 상태에 놓일 수도 있다.
일반적으로 이 수치가 20이 넘으면 과부하라고 판단해도 된다. 웹서버인 경우에는 180∼300 정도는 안정적인 수치다. 그러나 역시 다른 개체와 연동해서 봐야한다. 페이지란 디스크에 존재하기 때문에 디스크의 입출력에 대한 개체와 같이 연동해서 봐야 한다. 개별적으로 봐서 수치가 4∼5000 단위 이상이면 이것은 메모리 불량으로 봐도 된다. 서버의 모든 구성을 마치고 서비스를 시작하기 직전에 이 카운터값만 돌려서 천 단위 이상이 나온다면 이것은 메모리의 불량이다. 메모리의 불량이라고 해서 시스템이 부팅이 안되는 정도는 아니다. 시스템 운영상에는 전혀 문제가 없어 보이지만 패리티가 깨졌거나 노이즈가 있는 경우에도 가능하다.

⑤ Pool Nonpaged Bytes(임계값 : 4MB 이상)
Pool이란 쉽게 수영장을 생각하면 되겠다. 여기서 풀이란 어떤 공간을 만들어 놓고 사용하기 위한 곳이며 재사용도 가능하다. Nonpaged란 페이지가 되지 않은 메모리 즉 RAM에 존재하는 것이다. 이 말은 가상 메모리로 액세스하지 않고 캐시라는 공간으로(실제적으로는 RAM에 존재함)의 액세스를 말한다. 캐시가 사용되는 이유는 굉장히 급하고 반복적으로 사용되는 케이스고, 이런 것은 가상 메모리 관리자(VMM)가 관리한다. 풀링(Pooling,캐시와 RAM으로의 입력)이 많다면 프로세스의 과부하며 애플리케이션의 수행에 문제가 있다고 볼 수 있다. 일반적으로 윈도우 2000이 설치되면 파일서버 용도로 메모리 구성이 디폴트로 이뤄진다. 이럴 경우 캐시가 메모리 크기의 25%를 사용하기 때문에 물리적인 메모리가 많이 손해본다. 이런 부분은 메모리 구성 조정을 통해 캐시의 크기를 줄일 수가 있다.

⑥ Pool Paged Bytes(임계값 : 사용량 파악)
디스크에 있는 가상 메모리를 페이징 파일이라고도 부른다. 페이지됐다는 얘기는 RAM과 가상 메모리를 이동할 수 있다는 얘기다. 앞서 설명한 Pool Nonpaged Bytes는 고정돼 사용된다는 것이고, Pool Paged Bytes는 페이지로 사용되지 않고 있을 때 메모리 관리자에 의해 디스크에 쓸 수 있는 개체에 대한 시스템 메모리(운영 체제가 사용하는 실제 메모리) 영역을 말한다.

⑦ Commited Bytes In Use(임계값 : 70 이상)
가상 메모리의 사용량 한계를 살펴볼 목적으로 이 개체를 추가하면 된다. 가상 메모리가 한계에 다다르면 윈도우 서버는 가상 메모리 공간이 부족하니 확장하라는 경고 메시지가 뜬다. 이런 사용량 파악이 목적이며 Commit Limit에 대한 Commited Bytes의 비율이다. Commit Limit가 1000이고 Commited Bytes가 300이면 30%를 사용하고 있다고 표시된다. 일반적으로 페이징 파일의 크기는 RAM의 1.5배가 권장사항이다. 그러므로 가상 메모리가 이 크기에 다다르면 메모리 확장을 고려해야 한다.

⑧ 캐시 Faults/sec(임계값 : 100 이상)
컴퓨터를 접하다 보면 버퍼(buffer)와 캐시(cache)라는 용어를 많이 접하게 된다. 버퍼는 말 그대로 완충기 역할을 한다. 캐시가 속도를 빠르게 하는 목적이라면 버퍼는 속도를 떨어뜨리지 않고 유지할 수 있게 하는 역할을 하는 것이다. 버퍼는 하드웨어와 프로그램 양쪽에 모두 존재하며, 속도가 다른 하드웨어 장치들, 우선 순위가 다른 프로그램의 프로세스들에 의해 공유되는 데이터 저장소를 말한다. 버퍼는 각 장치나 프로세스가 상대방에 의해 정체되지 않고 잘 동작할 수 있도록 해주는 역할을 맡는다. 캐시는 데이터를 임시로 저장해두는 장소를 말한다. 프로그램적으로는 불가능하며 하드웨어적으로 존재한다. L2, L3 캐시 메모리라는 것을 들어보고 직접 보기도 했을 것이다. RAM에서 데이터를 하드디스크에서 가져오려고 하면, 서로의 속도 차이 때문에 캐시가 RAM 안에 존재한다. 여기에 해당 데이터가 존재한다면 가지고 올 수 있다. CPU에 캐시 메모리라는 것이 있는데 RAM까지 가기 바쁘니 캐시 메모리에 있다면 여기서 가지고 올 수 있다. 이런 이유로 캐시라는 것이 존재하고 이에 대한 성능 카운터가 윈도우 서버에 존재하는 것이다.
캐시 Faults/sec은 찾아본 페이지가 파일 시스템 캐시에 없고, 메모리에 있거나(soft fault) 디스크에 있었던(hard fault) 오류 수를 나타낸다. 파일 시스템 캐시는 애플리케이션이 최근에 사용한 데이터를 저장해두는 실제 메모리의 일부 영역이므로 잘못된 애플리케이션은 이 카운터 값을 높일 것이다. 이 카운터에 대한 임계치 값은 없다. 그러나 Available bytes 5% 이하이고, page faults/sec이 임계치 값이 높고 cache faults/sec이 평상시보다 높게 수치가 기록되면 100% 메모리 부족이나 애플리케이션의 오류라고 적용해도 된다. 서두에서도 설명했지만 윈도우 서버 성능 모니터는 복합하게 볼 필요가 있다고 한 것을 기억하자.

⑨ 캐시 Bytes(임계값 : 사용량 파악이 목적)
이제 캐시가 무엇을 하는지 알 것이다. 그러나 성능 모니터에서의 캐시를 본다면 이 카운터가 실제로 시스템 캐시 작업 세트를 나타내지 않는다는 것이다. 즉, 카운터 한 개가 시스템 캐시의 크기를 나타내는 것이 아니고, 4개의 카운터가 합쳐져서 캐시 Bytes라는 카운터 값을 나타내는 것이고 4개의 카운터 중 한 개가 우리가 일반적으로 말하는 RAM의 캐시를 얘기를 한다. 4개의 카운터는 다음과 같다.

- System Cache Resident Bytes : 이 카운터가 4개 중 한 개의 카운터, 실제 메모리에 있는 파일 시스템 캐시로부터의 바이트 수를 말한다.
- System Driver Resident Bytes : 장치 드라이버가 현재 사용하고 있는 페이지로 나눌 수 있는 실제 메모리의 바이트 수를 나타낸다. 이것은 드라이버의 작업 집합(RAM 영역)이다.
- System Code Resident Bytes : 사용하지 않을 때 디스크에 쓸 수 있는, 실제 메모리에 현재 있는 운영체제 코드의 바이트 수를 나타낸다.
- Pool Paged Resident Bytes : 페이지된 풀의 현재 크기를 바이트로 나타낸다. 페이지된 풀은 사용되지 않고 있을 때 디스크에 쓸 수 있는 개체에 대한 시스템 메모리(운영 체제가 사용하는 실제 RAM) 영역이다.

캐시를 이루는 카운터가 어떤 것인지 간단하게 설명했다. 설명하는 동안 작업 세트(working set)라는 말을 몇 번 언급했다. 이는 물리적(RAM)으로 정착된 프로세스의 가상 주소 공간의 부분 집합으로, RAM에 상주하는 가상 페이지의 하위집합을 설명하기 위해 사용하는 용어다. Page Faults/sec을 설명을 하면서 페이지 폴트가 왜 일어나는지를 설명했다. 디스크의 가상 메모리를 액세스하는 것이 메모리 관리자가 한다고 했지만 엄밀하게 얘기하면 작업 세트 관리자가 수행하는 것이다. 작업 세트 관리자가 가상 메모리의 주소 공간을 가지고 있기 때문에 작업 세트 관리자를 통해 가상 메모리에서 RAM으로 데이터가 이동할 수 있는 것이다.

⑩ Page Read/sec(임계값 : 5 이상)
이 카운터는 하드 페이지 폴트를 해결하기 위해 디스크가 읽혀진 횟수를 나타낸다. Page Faults/sec이 소프트 폴트와 하드 폴트 두 가지를 다 포함하기 때문에 이 카운터로 하드 페이지 폴트의 비율을 알 수 있다. 만약 이 수치들이 낮을 경우 웹서버는 request에 대해 빠르게 응답할 것이고, asp queued에도 2 이상의 수를 기록하지 않을 것이다. Page Faults/sec이 높다고 무조건 애플리케이션에 잘못이 있는 것은 아니다. 하드 폴트가 많은 것이 성능을 저하시키는 것이고, 이것은 잘못 설계되거나 수행되는 애플리케이션 때문이다. 애플리케이션에서의 문제가 아니라고 판단이 되면 RAM을 증설해야 한다.

⑪ Page Input/sec(임계값 : 5 이상)
이 카운터는 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽어들이는 페이지들의 총 개수를 나타낸다. Page Faults/sec과 Page Read/sec을 참고하면 된다.

CPU 카운터에 대한 설명

시스템 성능 모니터의 CPU 카운터를 보면 어디서나 늘 임계치는 70∼80% 이상으로 잡고 있다. 이 말은 프로세스 하나가 계속적으로(어떤 일정한 시간은 없지만 10초 이상으로 봐도 된다) CPU 사용율을 70∼80% 이상 사용하고 있다는 말이다. 이때의 해결책은 메모리에서와 마찬가지지만 우선 어떤 프로세스가 CPU 사용률이 많은지 파악해야 하고, 다른 카운터와의 연관관계(디스크 입출력 문제, 페이징 발생 문제 등)를 따져서 이것이 정말 CPU의 병목 현상인지, 아니면 다른 애플리케이션으로 인한 CPU의 병목 현상인지 파악해야한다. 종종 백도어나 웜 등으로 인해 시스템의 장애 현상을 겪는 경우도 있다. 여기서 원인 파악을 제대로 못하고 단지 CPU의 병목이기 때문에 CPU를 듀얼로 확장한다거나 4웨이로 확장 작업을 마쳤다고 하더라도 원하는 만큼의 성능 결과를 얻지 못할 것이다. 수치적으로 환산해서 얘기한다면 100%의 만족감에서 5% 정도의 만족감을 얻을 수도 있다.
그래서 어디가 잘못된 것인가를 파악하는 게 가장 중요한 포인트고, 문제는 주로 원인이 되는 프로세스가 어떤 폴링 작업을 하고 있거나, 루프에 빠져서 허덕이면서 헤어나오지 못하는 현상이 다반사다. 현재 이 연재의 주제는 용량 계획이기 때문에 이런 부분도 같이 다뤄야 한다는 점을 충분히 고려해야 한다.

대부분의 성능 모니터 관련 글을 보면 높은 CPU 사용률에 포커스를 맞춰 정보를 알려 주고 있으나 낮은 CPU의 사용률도 성능 모니터의 대상이 된다는 것을 알아두자. MS SQL의 경우 잠금 경합이 발생하는 경우, 생산적인 작업이 발생하지 않는다면 시스템 CPU 사용량이 0%에 이를 수가 있다. 매우 낮은 전체 성능과 낮은 CPU 사용량을 보이고 있다면 이것 또한 애플리케이션의 어디에선가 병목현상을 보이고 있는 것이고 이것을 찾아서 해결해야 한다. 다만 이는 웹 접속자나 MS SQL의 접속자가 많다는 가정하에서다. 접속자가 없거나 애플리케이션이 쓰이지 않는다면 그것은 당연히 CPU 사용률이 0이어야 한다. 높아도 안되고 낮아도 안된다고 하니 혼란스러울 수도 있으나, 그래도 하다보면 재미가 솔솔 붙을 것이다.

※ IIS가 사용하는 CPU의 개수는?

윈도우 2000의 IIS5.0은 2∼4개까지의 프로세서를 사용하도록 설계돼있다. 그럼 MS SQL은? 운영체제가 지원하는 만큼 사용할 수 있다. 데이터센터가 얼마나 많은 CPU를 지원하는지 알아보면 그것이 한계라고 보면 된다. MS SQL이 엔터프라이즈 버전이어야만 한다.

① %Processor Time (임계값 : 70∼80 이상)
시스템이 사용하는 전체적인 CPU 양을 나타낸다. 일반적으로 70% 이상이 사용되고 있다면 과부하라고 판단된다. 멀티 프로세서가 장착된 컴퓨터에서 불균형 현상을 찾아내기 위해 %Processor Time 카운터의 인스턴스를 전체로 하지말고 0, 1을 따로 설정한다면 CPU 사용률을 각각 볼 수 있다.

② %User Time(임계값 : 80 이상)
수행되고 있는 애플리케이션이 사용하고 있는 CPU 사용률

③ %Privileged Time(임계값 : 80 이상)
시스템이 사용하고 있는 CPU 사용률

이 세 가지 설명된 값은 전부 CPU의 사용량과 관계가 있다. 하나는 시스템의 전체적인 사용량이고 그 전체적인 사용량에서 시스템이 사용하느냐, 애플리케이션이 사용하느냐의 세부 분석이 있다. 이 값을 볼 때는 서로 관계를 지어서 봐야 하는데, 예를 들어서 Processor Time이 30을 기록하고 있다. 이때 User Time이 50을 기록했다면 이것은 Processor의 30에 대한 50을 얘기하는 것이다. 이 말은 Privileged Time과 User Time은 Processor Time의 값을 전체 100으로 놓고 구분한 값이다.

④ Interrupts/sec(임계값 : 7000 이상)
프로세스가 매 초마다 받아 처리한 하드웨어 인터럽트의 평균 수를 나타낸다. 인터럽트가 많다는 것은 애플리케이션의 CPU 사용률이 그만큼 높다는 것이고 CPU의 대기가 그만큼 많아진다는 것이다. 하드웨어적인 측면에서 본다면 아주 과도한 인터럽트가 발생하는 경우는 잘못된 장치 드라이버를 사용하고 있는 경우에도 발생한다. 프로세스가 매 초마다 받아 처리한 하드웨어 인터럽트 평균수를 표시한다. 여기에 DPCs는 포함되지 않고 따로 계산되고, 이 값은 시스템 클럭, 디스크 드라이버, 데이터 통신 회선, 네트워크 인터페이스 카드, 기타 주변 장치 등 인터럽트를 만드는 장치의 활동을 표시한다.

⑤ %Interrupt Time(임계값 : 5 이상)
프로세스가 하드웨어 인터럽트를 받아 처리하는 데 소모한 시간의 백분율을 나타낸다. 이 값은 시스템 클럭, 디스크 드라이버, 데이터 통신 회선, 네트워크 인터페이스 카드, 기타 주변 장치 등 인터럽트를 만드는 장치 활동의 간접 표시기이다. 이런 장치는 일반적으로 작업을 완료하거나 주의를 요할 때 프로세서를 인터럽트한다. 인터럽트 동안 일반 스레드 실행은 잠시 중단된다. 대부분의 시스템 클럭은 백그라운드 인터럽트 활동을 만들면서 매 10 밀리초마다 프로세서를 인터럽트한다.

⑥ %DPC(Deffered Procedure Calls) Time(임계값 : 사용량 참고)
% DPC(표준 인터럽트보다 낮은 우선 순위로 실행되는 인터럽트) Time은 샘플 간격 동안 유예된 프로시저 호출(DPCs)을 받아 처리하는 데 소비한 시간을 나타낸다. DPC는 특권 모드에서 실행되므로 % DPC Time은 % Privileged Time의 구성 요소다. Interrupts/sec과 %DPC Time 카운터를 계산하면, 인터럽트와 연기된 프로시저 콜 즉, DPC에 대해 프로세서가 얼마나 많은 시간을 소비했는지를 나타낸다.

작성자 : 이인석 | 프리랜서

[서버용량계획하기 4] 윈도우 서버 용량 계획하기

지난 호에서는 성능 모니터를 통해 메모리와 CPU에 어떤 카운터를 설정해야 하는지, 또 어떤 기준으로 데이터를 분석해야 하는지 알아보았다. 이번 호에는 지난 호에 이어 메모리와 CPU 외에 다른 개체들의 카운트 설정 방법도 알아보도록 하자.

지난 연재에 이어 성능 테스트 환경을 통한 성능 모니터의 로그 결과물을 토대로 서버 용량의 한계가 어디까지인지, 어느 시점에서 메모리와 CPU, 하드디스크, 혹은 RAID 도입을 결정해야하는 지 알아보자. 우선 메모리와 CPU의 카운트 설정 방법에 이어, 여러 개체의 성능 카운터 설정에 대해 설명하도록 하겠다.

PhsicalDisk

디스크에서 가장 중요한 것은 디스크의 I/O다. 기본적인 서버의 데이터 입출력과 윈도우 서버(기타 다른 서버 운영체제)는 가상 메모리(Paging File)를 가지고 있는데, 가상 메모리는 하드 디스크에 위치를 해야하기 때문에 디스크의 입출력 문제가 중요하다.

그럼 왜 서버 운영체제는 가상 메모리를 디스크에 두고 있는지 궁금할 것이다. 윈도우 서버의 애플리케이션 프로세스가 모두 RAM에 상주한다면 비용도 비용이지만 수용하지 못할 것이다.

현재 테스트 서버로 준비된 서버는 하는 일이 없다. 앞으로의 결전(?)을 대비해 숨고르기를 하고 있는 중이다. 이럴 때 가상 메모리는 얼마 사용하지 않게 된다. 현재 약 100MB 정도 사용 중이고 최고 한도는 약 1.2GB, 최소 크기는 768MB가 잡혀 있다. 이 가상 메모리의 최대가 1.2GB로, 이 크기는 늘어날 수 있지만 늘리는 것을 권장하고 있지 않다. 윈도우가 가상 메모리를 늘려서 사용하면 CPU의 컴퓨팅 사용량을 많이 차지하기 때문에 추천하지 않고, 이럴 때는 메모리를 늘리라고 권장한다. 이렇게 최대 한도까지 다다른다면 그것은 한마디로 디스크의 입출력이 빈번하게 일어나서 디스크의 병목 현상도 같이 야기하게 된다는 것이다. 이것은 잘못된 페이징 작업으로 디스크에서 RAM으로 데이터가 올라오는 하드 페이지 폴트 오류 때문에 발생할 수가 있는데, 이것을 단지 디스크의 병목으로만 판단해 디스크를 좀더 빠르게, 그리고 가상 메모리도 완전히 다른 물리적 디스크에 독단적으로 쓴다해도 CPU와 같이 개선된 성능을 기대하기는 힘들다.

역시 애플리케이션을 수정한 후 그래도 원하는 성능이 안나온다면 한 개의 디스크를 가상 메모리를 위해 사용하면 보다 개선된 성능을 기대할 수가 있다. 그 이외의 카운터는 이런 병목 현상을 판단하거나 용량 계획에 대한 기초 자료가 될 수 있다.

디스크 성능 카운터를 다루다 보면 DISKPERF라는 명령어를 볼 수 있다. 이 명령어를 통해 시스템 성능 모니터를 사용해 볼 수 있는 카운터의 종류를 제어할 수 있다. DOS 창에서 'DISKPERF /?'라고 입력하거나 '윈도우 서버 도움말 → 색인'에서 찾아보면 쉽게 그 명령어를 이해할 수 있다.

DISKPERF 명령어를 적용하기 전에 성능 카운터를 열어 성능 개체를 보게 되면 PhysicalDisk라는 개체는 보이지만 LogicalDisk라는 개체는 볼 수 없다. 윈도우 서버를 설치하고 나서 디폴트로 올라오는 개체 값이 PhysicalDisk 개체다. DISKPERF 명령을 통해 LogicalDisk를 추가할 수가 있다. 여러 가지 명령어가 있겠지만 'DISKPERF /Y'라고 하면 재부팅 후 적용된다는 메시지가 나오고, 재부팅을 하고 난 후 성능 모니터의 성능 개체를 보면 LogicalDisk라는 개체가 생긴 것을 알 수 있다.

사실 PhysicalDisk 개체와 LogicalDisk의 성능 개체 각 각의 카운터 값은 틀린 것이 없다. 단지 인스턴스를 나타내는 방식이 틀리다는 것이다. PhsicalDisk의 구조는 두개의 디스크를 갖고 있다. 물리적 ID 0번 디스크에 C:\ 와 F:\가 할당됐고, 물리적 ID 1번 디스크에 D:\와 E:\가 할당돼 있다는 것을 나타낸다. 적용 후의 LogicalDisk를 보면 번호는 C:\, D:\, E:\, F:\가 나란히 배열돼 있다. 순수하게 논리적인 구조 관점으로 바라 본 것이다. 사실 PhysicalDisk로 어느 정도의 디스크 병목이 어디서 일어나는지 판단할 수 있지만, 보다 세밀하고 정확하게 적용하고 그 병목이 어느 파티션에서 일어나고 있는지 파악하고 싶다면 LogicalDisk 개체의 카운터를 같이 설정해 놓으면 보다 정확하게 알 수 있다.

필자가 경험했던 디스크 성능 문제를 간단히 소개하겠다. E업체로부터 현재 웹 서버에서 이미지의 로딩이 느리다는 문의가 들어 왔다. 이미지는 웹 서버 로컬에 저장된 것을 로딩하는 것이 아니고 다른 이미지 서버에서 가져 오는 것이다. 해당 웹사이트를 열어 이미지를 로딩해 봤더니 많은 양의 이미지가 있지만 이미지가 위에서부터 아래 방향으로 순차적으로 하나 두개씩 로딩되고 있는 병목 현상이 눈으로 보이고 있다.

이런 것이 눈으로 확인될 정도라면 서버에서는 엄청난 성능 저하가 일어나고 있는 경우다. 또 하나 조금 특별한 상황이라면 로컬에서 로딩하는 것이 아니고 네트워크를 통해 로딩하는 것이기 때문에 네트워크 문제도 고려해야 한다. 네트워크 쪽으로는 패킷 손실이 일어나지 않나 불필요한 트래픽이 실리지 않나를 점검했고, 성능 모니터에서 네트워크에 대한 부분도 예의 주시했다. 여러 가지 성능 개체를 걸어 놓고 판별한 결과, 이미지가 저장돼 있는 디스크의 병목현상으로 확연하게 나타났다.
따 라서 필자는 두 가지 대안을 제시했다. 디스크 어레이를 사용해 데이터의 안정화와 성능향상을 꽤하는 것과 서버를 한대 더 준비해 분산 환경을 사용하라고 제안했다. 고객사는 RAID를 선택했고 레벨은 0+1을 선택했다. 디스크 재구성이기 때문에 재설치는 불가피하다. 재설치 후 웹서버의 이미지 로딩이 원하는 만큼 나왔고, 이미지 서버의 성능도 크게 향상됐다. 사실 직감만으로 이런 작업을 하는 것은 도박과 같다. 성공하면 쾌감을 느끼고 직감에 대해서 신뢰가 가겠지만 만약 실패한다면 처음부터 다시 시작해야 한다.

① %Disk Time(임계값 : 90 이상)
현재 디스크 전송량(읽기+쓰기)을 시간으로 나타낸다. 디스크의 전송속도는 bps이기 때문에 속도 단위를 8로 나눠야 한다. Disk Time이 높고(임계값 이상) Current Queue Length도 높다면 디스크의 I/O 문제로 봐야 한다. 가상 메모리가 위치해 있는 물리적 디스크에 대한 값도 주의 깊게 모니터링한다. 이 값이 증가하면 가상메모리의 용도를 점검하고 메모리를 추가하도록 한다. 임계값 이상이면 과부하며, 별도의 디스크를 구입해 시스템 데이터, 사용자 데이터, 가상 메모리 데이터를 물리적으로 구분하거나 RAID 도입을 고려해야 한다.

② Current Disk Queue Length(임계값 : 2 이상)
디스크를 읽기 위해 대기열에 대기하고 있는 내용들의 수를 나타낸다. 디스크 병목을 판단하는데 중요한 모니터링 자료가 된다.

③ Disk Bytes/sec(임계값 : 사용량 파악)
쓰기 또는 읽기 작업 동안 디스크로(또는 디스크에서) 전송되는 양으로, 얼마나 많은 디스크의 입출력이 발생하는 지를 나타낸다. 이 값은 초당 얼마나 많은 데이터가 디스크로 입출력하는지 기준이 되는 모니터링 자료다.

④ Avg. Disk Bytes/Transfer(임계값 : 사용량 파악)
Avg. Disk Bytes/Transfer는 읽기 또는 쓰기 작업 동안 디스크로(또는 디스크에서) 전송되는 평균 바이트 수를 나타낸다. Disk Bytes/sec가 초당 전송률을 나타낸다면 이것은 평균값이다.

⑤ %Idle Time(임계값 : 10이하)
idle의 영어적인 뜻은 '쓰이고 있지 않는'이다. 작업관리자에 봐도 system idle process라는 것이 있고 서버가 쓰이고 있지 않고 한가하다면 이 값은 늘 높게 마련이다. 모니터링 간격동안 디스크의 유휴(쓰이고 있지 않는) 상태의 값을 나타낸다.

⑥ %Disk Read Time(임계값 : 사용량 파악)
% Disk Read Time은 선택한 디스크 드라이브가 읽기 요청을 처리하는데 사용된 시간의 백분율을 나타낸다. Read와 Write를 조합을 해서 %Disk Time와 함께 살펴보면 답이 나온다.

⑦ % Disk Write Time(임계값 : 사용량 파악)
% Disk Write Time은 선택한 디스크 드라이브가 쓰기 요청을 처리하는데 사용된 시간의 백분율을 나타낸다.

⑧ Avg. Disk sec/Read(임계값 : 사용량 파악)
읽기 작업에 소요된 평균 시간(밀리초)을 나타낸다. 오래 지연되는 읽기 작업은 디스크가 과다하게 사용된다는 것을 나타낸다.

⑨ Avg. Disk sec/Write(임계값 : 사용량 파악)
읽기 작업에 소요된 평균 시간(밀리초)을 나타낸다. 오래 지연되는 쓰기 작업은 디스크가 과다하게 사용된다는 것을 나타낸다.

※ %Free Space 카운터
카운터의 이름에서 보다시피 여유 공간을 체크하고 있는 카운터이다. 간혹 디스크의 공간이 모자라 장애를 일으키는 경우가 있는데 이 카운터를 설정을 해놓고 여유 공간을 체크하면 도움이 될 것이다.

네트워크 인터페이스

IT 분야에서 네트워크가 가장 큰 규모가 아닐까 한다. 네트워크 → 서버 → 응용 프로그램 순으로 동작한다고 봐도 네트워크는 큰 범위다. 예전에 한국에서 IT 붐이 일고 시스코 장비 관리자들이 많은 연봉을 받으며 일했다고 들은 적이 있다. 현재는 워낙 공급이 많아서 예전 같지 않다고 한다. 님다 바이러스(Nimda Virus) 이후 네트워크 관리자들의 보안에 대한 인식도 한층 높아진 것 같다. 네트워크 관리자만 그럴까? 서버 관리자도 마찬가지다. 바이러스, 웜, 백도어(예전에는 바이러스라는 것으로 통일 됐지만)가 그 방법이 갈수록 악랄해지고 있다. 윈도우98 시절 CIH 바이러스가 PC의 하드디스크를 통째로 포맷을 한다고 해서 뉴스에도 나온 것으로 기억한다. 예전 바이러스는 감염되고 자기 자신만 피해를 줬지만 님다 이후로는 개인 뿐만 아니라 네트워크 대역을 스캔해 가며 감염시켰고, 님다를 치료하려면 일단 네트워크를 단절해야 한다. LAN을 연결 시켜놓고 치료해도 소용이 없었다. 이렇게 서버 투 서버로 전파가 되던 것이 이제는 패킷을 무작위로 날려 라우터를 죽이려고 덤벼든다. 기발한 발상이다. 네트워크가 단절되면 서버가 무슨 소용이랴. 무작위로 패킷을 보내 라우터의 CPU나 메모리 사용률을 높여 라우터를 다운시키려고 하는 것이다. 이제 이런 것들은 파이어월이나 플로우스캔, MRTG를 통해 패킷의 움직임이나 성향을 파악해 바로 조치 할 수 있다.
윈도우 서버 성능 모니터링에서 네트워크 모니터링 부분은 사용량을 파악하기 위한 것이지 패킷 분석은 아니다. 패킷을 들여다보고 싶다면 윈도우 서버에 내장된 네트워크 모니터 도구나 이더리얼 등의 제품을 설치해 사용해야 한다. 프로토콜의 기본, 네트워크 구성 등 기본적인 네트워크를 알면 서버를 운영하는데 틀림없이 도움이 된다.

여러 개의 LAN 카드를 쓰고 있는 멀티홈 환경이라면, 해당 LAN 카드에 대해 모니터링을 걸어놔야 할 것이다. 네트워크 인터페이스의 카운터는 사용량을 파악하기 위한 것이기 때문에 임계값은 없다. 임계값이라면 LAN 카드가 지원하는 최고속도의 80% 정도로 생각하면 된다.

① Bytes Total/sec
이 카운터는 해당 서버의 LAN 카드의 모든 네트워크 프로토콜의 송수신 바이트를 초당 사용량으로 나타낸다. 접속자가 많지 않은데 이 사용량이 높다면 웜을 의심해 보기 바란다. 네트워크의 병목을 판단하려면 이 카운터 값과 Current Bandwidth를 비교해 판단해야 한다. 일반적으로 네트워크의 증가분을 고려해 50% 정도의 여유분을 갖고 있어야 한다. CPU, 메모리가 여유있음에도 네트워크 사용량이 많다면 커넥션쪽의 문제를 파악해야 한다. 여기서 주의할 점은 네트워크에서는 비트 단위이고 성능 모니터에서는 바이트이기 때문에 네트워크 어댑터의 대역폭을 바이트로 표시하기 위해서는 8로 나눠야 한다.

② Bytes Sent/sec
초당 서버에서 외부로 나간 전송량을 나타낸다. Bytes Total에서 Bytes Sent를 빼면 Bytes Received/sec가 나온다. Bytes Received/sec 추가 여부는 독자들에게 맡긴다.

③ Current Bandwidth
Current Bandwidth는 LAN 카드의 현재 대역폭을 각 초당 비트(BPS)로 추정한 값이다. 대역폭이 다양하지 않거나 값을 정확히 추정할 수 없는 인터페이스일 경우, 이 값은 명목상의 대역폭을 나타낸다. 이 카운터 값과 Bytes Total/sec 값을 비교한다면 여유분의 네트워크 사용량을 파악할 수 있다.

Acitve Server Page

ASP가 사람들에게 윈도우 서버를 많이 알게 하는데 공헌한 점이 있다고 생각한다. 그러나 ASP에서 늘 문제가 되는 DB 연결, 잘못된 LOOP는 한방에 서버를 가볍게 죽인다. 아주 잘 설계된 ASP 코드는 비싼 서버 10대가 부럽지 않다. 닷넷이 아무리 훌륭하다고 할지라도 기본 설계 방침을 벗어난다면 이름값 못하는 것처럼 말이다.

① Request Queued(임계값 : 40 이상)
큐에서 서비스를 기다리는 중인 요청의 수를 나타낸다. 이 수치가 5 이상 오르면 일단 병목으로 의심해 본다. Web services\Current Connection이 500 이상이고 이 수치가 몇 십을 기록하면 ASP 코드가 무겁다고 판단된다. 또한 커넥션에 상관없이 큐가 40 이상이면 ASP가 무겁다고 판단된다.

② Request/sce(임계값 : 사용량 파악)
초당 ASP가 실행되는 수를 나타낸다. 이 수치가 아무리 많아도 Request Queued에 쌓이지 않는다면 별 무리가 없다. 이 말은 ASP 코드가 바로 수행돼 대기열이 없기 때문이다. 만약 이 카운터가 서버의 트래픽이나 접속자가 많은 시간에 낮은 수치를 보인다면 애플리케이션은 병목 현상을 초래하고 있는 것이다.

③ Request Excution Time(임계값 : 사용량 파악)
가장 최근 ASP 요청을 실행하는 데 걸리는 시간(단위:밀리초)을 나타낸다. ASP의 수행 시간을 판단하는 자료가 된다.

④ Request Excuting(임계값 : 1 이상)
현재 실행 중인 ASP 요청의 수를 나타낸다

⑤Session Current(임계값 : 사용량 파악)
서비스 받고 있는 현재 세션의 수를 나타낸다.

⑥Errors/sec(임계값 : 5 이상)
초 단위 당 발생한 오류의 수를 나타낸다.

⑦ Request Wait Time(임계값 : 1 이상)
가장 최근 요청이 큐에서 대기하는 시간을 나타낸다.

⑧Request Not Authorized(임계값 : 5 이상)
액세스 권한이 불충분해 실패한 요청의 수를 나타낸다. 액세스 권한이 없다면 그것은 IIS에서 권한 설정과 폴더에서의 권한 설정을 점검해야 할 것이다. 자료를 업로드해야 한다면 업로드 프로그램을 이용해 해당 폴더와 IIS 사이트에서 쓰기 권한이 있어야 파일이 서버로 업로드될 것이다. 이런 실패가 있다면 기록될 것이다.

⑨ Request Not Found(임계값 : 5이상)
찾지 못한 파일에 대한 요청의 수를 나타낸다. 이 부분은 ASP에 문제가 있는지 없는지를 간접적으로 판단할 수가 있다. 이 카운터 값이 기록되면 웹로그를 이용해 해당 연결이 어떻게 잘못됐는지를 찾아내야 한다.

⑩ Request Rejected(임계값 : 5이상)
요청을 처리하기에 리소스가 충분하지 않아서 실행되지 않은 총 요청의 수다. 500/sever too busy라는 메시지를 본적이 있을 것이다. 이런 현상이 발견하면 나타나는 카운터값이다.

⑪ Session Timed Out(임계값 : 5이상)
시간이 초과한 세션의 수를 나타낸다. 소스에서 세션 값을 늘일 수도 있고 IIS에서도 늘일 수 있다. 이에 해당하는 카운터 값들이다.

⑫ Transaction Pending
처리 중인 트랜잭션의 수를 나타낸다. 이 트랜잭션 처리의 데이터를 기준으로 용량 계획에 대한 데이터가 나오게 된다.

웹 서비스

① Current Connections(임계값 : 사용량 파악)
이 카운터값은 현재 웹 서비스를 사용해 연결된 수를 나타낸다. 중요한 것은 이 카운터값과 함께 ASP에 대한 사항을 같이 봐야 한다는 것이다. 서로 밀접한 관계가 있기 때문이다. 또한 웹 서버로 이용한다면 접속자가 몇 명이고 서버의 여러 가지 환경을 고려해 몇 명의 사용자가 접속하고 있을 때 한계인지 기준이 될 것이다. 역시 이 카운터 하나만으로 데이터를 산출하는 것이 아니고 CPU, RAM, 하드디스크의 카운터 값과 조합해야 한다.
 
② Connection Attempt/sec(임계값 : 사용량 파악)
웹 서비스를 사용해 연결을 시도하는 비율을 나타낸다. 용량 계획에 필요한 데이터다.

③ Get Requests/sec(임계값 : 사용량 파악)
이 카운터와 Post Requests/sec의 값은 서버의 두 가지 HTTP 요청이 수행되는 속도를 나타낸다. Post 요청은 일반적으로 폼에서 사용되며 ISAPI(ASP 포함) 또는 CGI로 전송되고 Get 요청은 거의 모든 브라우저의 요청을 나타내고 정적파일, ASP 및 기타 ISAPI, CGI 요청 등을 포함한다. 이 카운터값은 사이트의 알반 로드 특성을 이해하는데 많은 도움이 된다.

④ Not Found Errors/sec(임계값 : 10 이상)
요청한 문서를 찾지 못해 서버를 만족시킬 수 없는 요청 때문에 생긴 오류 비율을 나타낸다. 일반적으로 HTTP 404 Not found 오류 코드로 클라이언트에게 보고된다.

⑤ Maximun Connections(임계값 : 사용량 파악)
최대 연결은 웹 서비스를 사용해 동시에 연결할 수 있는 최대 연결 수를 나타낸다. 용량 계획에 필요한 데이터다.

시스템

①Processor Queue Length(임계값 : 2 이상)
이 카운터값은 CPU가 연산하기 위해 대기열에 대기하고 있는 수치를 나타낸다. 일반적으로 이 값이 2 이상이면 과부하로 본다. 이 값을 볼 때에는 Processor Time과 같이 연동해 본다. 이 값이 높고 CPU 사용량도 70 이상이면 이것은 CPU 업그레이드를 고려해야 하지만, CPU 사용량이 부하인 70% 이상이라도 Queue Length가 낮다면 괜찮다. 이는 CPU 수행속도가 기다림 없이 원할하게 이뤄진다는 말과 같다.

② Context Switches/sec(임계값 : 사용량 파악)
이 카운터는 초당 발생하는 쓰레드 전환 개수를 표시한다. 쓰레드의 개수를 증가시키는 것은 성능을 감소시키는 시점까지 컨텍스트 스위치의 개수를 증가시킬 수 있다. 리퀘스트당 10개 혹은 그 이상의 컨텍스트 스위치는 매우 높은 것으로서 만약 이 수치가 나타난다면 쓰레드의 크기를 감소시키는 것이 바람직하다.
커넥션이나 리퀘스트에 의해 측정된 전체적인 성능을 통해 쓰레드의 균형을 잡기란 매우 어려우며 쓰레드를 조정할 때 이에 따른 성능의 증가와 감소 여부를 결정하기 위해 전체적인 성능 모니터링을 병행해야 한다.
만 약 쓰레드 카운트를 적용시키고자 한다면 전체 프로세서 타임에서 프로세스 내의 각각의 쓰레드에 대한 프로세서 타임과 쓰레드의 개수를 비교해 봐야 한다. 만약 쓰레드가 계속 바쁘고 완전하게 프로세서 타임을 사용하고 있지 않다면 쓰레드를 더 많이 생성함으로서 성능을 향상시킬 수 있다. 그렇지만 모든 쓰레드가 바쁘고 프로세서가 자신의 최고 수용력에 가깝다면 개수를 증가시키기 보다는 서버의 개수를 늘여 작업을 분산시키는 것이 바람직하다.

프로세스

① %User Time(임계값 : 사용량 파악)
프로세스의 쓰레드가 사용자 모드에서 코드를 실행하는데 걸린 시간의 백분율이다. 즉 프로세스가 CPU를 사용한 양을 나타내며 이 카운터값을 설정할 때에는 인스턴스를 잘 선택해야 한다. 웹 서버를 운영한다면 인스턴스에서 inetinfo와 dllhost를 선택해 이 프로세스가 얼마나 CPU를 사용하고 있는지 체크해야 한다. 만일 COM+용으로 개발했다면 메모리 운영 방식에서 차이가 있겠지만 dllhost 인스턴스가 두 개 이상이 된다. 모든 dllhost를 관찰하도록 하자.

② Virtual Bytes(임계값 : 사용량 파악)
Virtual Bytes는 프로세스가 사용하고 있는 가상 주소 공간의 바이트 수를 나타낸다. 가상 주소 공간의 사용이 해당 디스크 또는 주 메모리 페이지를 반드시 사용함을 뜻하지는 않는다. 그러나 가상 공간이 한정돼 있으므로 너무 많이 사용하면 프로세스가 라이브러리를 로드하는데 제한받을 수 있다. 메모리 관련 카운터와 조합해서 살펴보도록 해야 한다.
 
③ Thread Count(임계값 : 사용량 파악)
쓰레드란 프로세스안에 실행 가능한 존재를 말한다. 이 카운터값은 프로세스에서 현재 활성화된 쓰레드 수를 나타낸다. 명령은 프로세서에서 기본 실행 단위이고, 쓰레드는 명령을 실행하는 개체다. 모든 실행 프로세스 적어도 하나의 쓰레드를 포함하고 있다. 윈도우 2000에서는 보통 20개 정도가 적당하고 자동적으로 증가한다.

④ Working Set(임계값 : 사용량 파악)
프로세스가 데이터를 저장하기 위해 사용중인 RAM의 양을 나타낸다. 아무런 서비스를 하지 않는데 Working Set의 값이 시간에 지남에 따라 증가하면 프로세스는 메모리 누수 현상을 불러온다. 해당 애플리케이션을 점검해 봐야 한다.

⑤ Private Bytes(임계값 : 사용량 파악)
해당 프로세스에 적용되는 가상 메모리를 기록한다. 즉 해당 프로세스가 사용하는 가상 메모리의 양을 나타낸다. 이 카운터 역시 인스턴스를 잘 선택해야하고 웹 서비스와 관련된 인스턴스를 선택하도록 하자.

⑥ %Processor Time(임계값 : 사용량 파악)
모니터링 대상으로 선택된 프로세스가 시스템에서 사용한 프로세서 시간의 백분율을 나타낸다. 어떤 프로세스가 어느 정도의 CPU 사용률을 기록하는지 파악할 수가 있다.

⑦ Elapased Time(임계값 : 사용량 파악)
프로세스 인스턴스가 수행한 시간(초단위)이 카운터는 오랜 기간 동안의 활동 경향을 추적하는데 유용하며, 또한 What if 시나리오에서 유용하다. 만약 더 많은 애플리케이션 사용자를 추가한다면 CPU 사용량에 어떤 일이 발생할지 볼 수 있다.

⑧ I/O Data Operations/sec(임계값 : 사용량 파악)
프로세스 인스턴스가 생성한 읽기와 쓰기 작업의 수를 나타낸다. 이 카운터는 사용자 생성 I/O 활동에 집중해 What if 시나리오를 분석하고, 애플리케이션 유형들에 대해 I/O 활동량을 추적하는데 유용하다.

⑨ Page Files Bytes(임계값 : 사용량 파악)
Page File Bytes는 이 프로세스가 가상 메모리에 사용한 현재 바이트 수를 나타낸다. 가상 메모리는 다른 파일에 들어있지 않은 프로세스가 사용한 메모리 페이지를 저장하는데 사용된다. 가상 메모리는 모든 프로세스가 공유하므로, 가상 메모리에 공간이 부족하면 다른 프로세스들이 메모리 할당을 할 수 없게 된다. 메모리의 %Committed Bytes In Use와 Committed Bytes와 비교해서 가상 메모리가 부족하지 않은가 판단해야 한다.

⑩ Page Faults/sec(임계값 : 사용량 파악)
메모리 개체에서 전체적으로 페이지 폴트가 일어나는 것을 관찰을 했다면 Process 개체에서는 어떤 프로세스가 그렇게 페이지 폴트를 일으키는지 명확하게 볼 수가 있다. 선택한 인스턴스 중 높은 사용률을 보이는 것을 찾자. 그 프로세스에 해당하는 애플리케이션이 잘못된 것이다.

⑪ Pool Paged Bytes(Instance:Inetinfo) / Pool Nonpaged Bytes(Instance:Inetinfo)
 Pool Paged Bytes(Instance:dllhost#n) / Pool Nonpaged Bytes(Instance:dllhost#n)
위 의 카운터들은 IIS나 Inetinfo 프로세스, 서버내의 인스턴스된 dllhost에 의해 직접 사용되는 풀(Pool) 공간을 모니터하기 위한 것이다. 여기서 주의할 점은 서버 내의 모든 dllhost의 인스턴스에 대한 카운터를 모니터해야 한다는 것이다. 그렇지 않으면 IIS에 의해 사용된 정확한 수치를 얻을 수 없게 된다. 시스템 메모리의 풀은 애플리케이션이나 운영체제에 의해 생성되고 사용되는 객체를 포함하고 있다. 메모리 풀의 컨텐츠들은 오직 우선권이 적용된 모드에서만 접근 가능하다. 즉, 운영체제의 커널만이 직접 메모리 풀을 사용할 수 있다는 의미로 사용자 프로세스는 메모리 풀을 사용할 수 없다. IIS를 구동시키는 서버에는 커넥션을 제공하는 쓰레드는 서비스에 의해 사용되는 다른 객체와 함께 Nonpaged Pool에 저장된다. 메모리의 성능을 향상시키기 위해 무조건 RAM을 증설하는 것보다 다음의 방법을 시도해 보자. 이렇게 해도 메모리와 관련된 성능의 향상이 없다면 RAM을 증설하자.

임계값은 사용량을 파악하는 것이 목적이다.
1. CGI APP를 ISAPI나 ASP로 전환한다.
2. IIS 5.0의 파일 캐시를 재조정한다.
3. 디스크의 속도 향상을 위해 RAID를 고려한다.

※ 이같은 프로세스 값은 전부 애플리케이션과 관계가 있다. 실질적으로 로그를 걸어 놓은 서버는 특별한 애플리케이션이 없이 IIS에 ASP가 실행되는 서버라 해당 카운터값의 inetinfo라는 인스턴스를 체크했다. 특별히 개발해서 운영한다면 그것에 맞춰 보는 것이 바람직하다.

Redirector

① Network Errors/sec(임계값 : 1 이상)
Network Errors/sec는 일반적으로 리디렉터와 하나 이상의 서버에 심각한 통신 문제가 있다는 것을 뜻하는, 예상 밖의 심각한 오류를 나타낸다. 예를 들면, SMB(Server Message Block) 프로토콜 오류가 일으키는 네트워크 에러 등이다. 이는 시스템 이벤트 로그에 항목을 추가하므로 이 파일에서 세부 내용을 참조할 수 있다.

② Server Reconnects(임계값 : 1 이상)
Server Reconnects는 새 활성 요청을 완료하기 위해 리디렉터가 서버에 다시 연결해야 하는 수를 파악한다. 오랫동안 비활성 상태를 유지할 경우, 서버가 연결을 끊을 수 있다. 원격 파일이 로컬로 닫혀 있을 경우에도 리디렉터는 10분 동안(명목상으로) 연결을 그대로 유지한다. 이같은 비활성 상태의 연결을 휴면 연결이라고 하는데, 다시 연결하려면 시간이 많이 소모된다.
 
※ 두 카운터는 파일 서버에서 성능 모니터링을 할 때 필요한 카운터들이다. 참고적으로 알아 본 것이니 웹 서버에서는 그렇게 신경을 안써도 되는 카운터들이다.

서버

① Pool Nonpaged Failure(임계값 : 5 이상)
비페이지 풀에서 할당받지 못한 횟수를 나타낸다. 컴퓨터의 실제 메모리가 너무 작음을 나타낸다.

② Bytes Total/sec(임계값 : 사용량 파악)
서버가 네트워크 데이터를 송수신하는 속도를 보고, 초당 서버 안팎으로 이동하는 총 바이트 수는 서버가 어느 정도 바쁜지를 알 수 있는 좋은 지표가 된다. 서버 로드를 변경하기 위해 어떤 작업을 하는 경우(예를 들면 네트워크에 같은 종류의 서버나 로드 밸런싱을 추가하는 것) 이 값을 모니터링해 변경이 실제로 도움이 되는지 알 수 있다.

③ pool paged Failure(임계값 : 5 이상)
페이지 풀에서 할당받지 못한 횟수를 나타낸다. 컴퓨터의 실제 메모리 또는 페이지 파일이 너무 작음을 나타낸다.

Paging File

① %Usage(임계값 : 90 이상)
현재 사용중인 가상 메모리의 백분율을 나타낸다. 이 값이 90% 이상이 되면 그 원인을 잘 파악해야 한다. 급하면 RAM을 추가해도 된다. 윈도우 서버는 필요하다면 가상 메모리를 더 크게 만들지만 가상 메모리의 크기를 늘리는 것은 권장 사항이 아니므로 RAM 확장을 고려해야 한다.

② %Usage Peak(임계값 : 90 이상)
가상 메모리의 최대 크기를 기록한다. 이 값이 가상 메모리 파일의 최대값에 근접하면 RAM을 더 추가해야 한다. 값이 높으면 가상 메모리가 모든 데이터를 포함할 수 있을 정도로 크지 않다는 것을 의미한다.

Internet Information Services Global

① File Cache Hits%(임계값 : 80% 이상)
이 카운터는 총 캐시 request에 대한 캐시의 히트 비율을 나타내는 것으로 IIS의 파일 캐시의 조정이 잘 작동하는 지를 알 수 있다. 정적인 페이지들로 구성된 웹사이트의 경우 80% 또는 그 이상의 캐시 히트가 일어나야만 좋은 성능을 발휘할 수 있다.

② File Cache Hits
이 카운터는 파일 캐시에 성공한 총 횟수를 나타내며 File Cache Flushes와 로그를 비교해 보면 적절한 비율로 캐시로부터 객체들을 플러쉬 시키는지 알아볼 수 있다.

③ File Cache Flushes
이 카운터는 서버를 시작한 이후로 파일 캐시를 지우는 카운터를 표시하는 것으로 만약 플러쉬가 너무 빠르게 일어난다면 필요 이상으로 객체가 캐시로부터 플러쉬되는 것이고, 반대로 플러쉬가 너무 천천히 일어난다면 메모리의 낭비가 일어난다고 볼 수 있다.

이것으로 윈도우 서버와 IIS에 관련된 성능 카운터는 모든 설정을 한 셈이다. 다음 호에서는 SQL 서버의 성능 카운터를 설정하고, WAS를 실행시키고 성능 모니터의 로그와 SQL 서버의 Profiler와 필요하다면 인덱스 튜닝 마법사를 가지고 분석한 후 사후 용량 계획을 잡도록 하겠다.

작성자 : 이인석 | 프리랜서

네트워크로드 밸런싱 개요

잔여 객실의 수치가 증가하는 경우는 TCP / IP가 응용 프로그램을 제공하기 위해 필요한 네트워크로드 (NLB를) 균형, Windows 2000 및 Windows Server 2003에 포함된 데 사용할 수있습니다. Windows Server 2003의 모든 버전 NLB가 포함됩니다. NLB를 자동으로 설치하는 동안, 그것을 활성화되어 있지 않습니다. a NLB 클러스터, 클라이언트 요청하는로드 서버를 NLB 클러스터에 거주하는 사이에 매개 변수로 구성된로드 밸런싱에 의해 지정된 균형 있음. 서버가 클라이언트 요청의 처리를 공유하도록 구성할 수있습니다. NLB를 또 실패 NLB 클러스터 서버로 전송하는 모든 요청을 선택할지 결정하실 수있습니다.

네트워크로드 (NLB를) 균형은 일반적으로 인터넷 애플 리케이션을위한 높은 수준의 가용성을 제공하는 데 사용됩니다. 때문에 트래픽이 NLB를 잘 작동하는 응용 프로그램을위한 기반 클러스터링 기술이있다. 한 NLB 클러스터 최대 32 대의 서버를 호스팅할 수있습니다. a NLB 클러스터에있는 서버 호스트라고합니다. 클러스터에있는 각 호스트에 동일한 응용 프로그램의 복사본을 실행합니다. 로 클라이언트 NLB 클러스터에 액세스하려고 시도,이 클러스터는 하나의 실체로 표현되고있다. 이 가능한 가상 네트워크 어댑터는 클러스터에있는 각 호스트에 창조에 의해 만들어졌다. 각 가상 네트워크 어댑터에 고유한 IP 주소와 MAC 주소를했다. 때 클라이언트 응용 프로그램이 요청을 보냅니다 클러스터, 클러스터의 IP 주소, 그리고 각각의 특정 호스트의 IP 주소가 사용됩니다. 클러스터에서 클라이언트 요청을받은 때, 클러스터에있는 각 호스트는 요청을 받는다. 각 호스트에서 실행되는 서비스는 네트워크로드 균형 조정 요청을 처리한다 클러스터에있는 호스트를 결정합니다.

이 NLB를 서버가 요청을 처리한다 NLB를 서버를 식별하려면 들어오는 패킷에 대한 호스트 우선 순위를 결정하는 통계 매핑을 사용합니다. NLB를 서버가 발견되면 패킷, NLB 클러스터에있는 서버의 나머지 패킷을 버립니다. 당신은 할 수 있지만 전용 IP 주소를 구성하는 네트워크 트래픽에 대한 특정 클러스터 서버로 라우팅되어야합니다. the NLB 클러스터에있는 각 서버를 이용하고, 클러스터의 상태를 식별하는 심장 박동이 메시지를 전송합니다. 하트 비트 메시지, 그리고 클러스터 구성 및 관련 포트 규칙은 클러스터의 상태에 대한 정보를 보유하고있다.

a NLB 클러스터에있는 서버로 이전에 언급했듯이, 호스트라고합니다. 각 NLB 클러스터의 기본 호스트있다.의 기본 호스트는 우선 순위가 가장 높은 클러스터의 서버입니다. 우선은 고유 번호 NLB 클러스터에있는 각 호스트에 할당됩니다. 우선순위는 특별히 포트 규칙에 따라 균형로드되지 않은 모든 요청에 대한 처리 우선 순위를 결정합니다. 고유 호스트 또한 NLB 클러스터에있는 각 호스트를 식별하는 ID입니다.

체중 부하 요인 NLB 클러스터에있는 호스트 사이에서 클라이언트 요청을 배포하는 데 사용할 수있습니다. 강력한 서버를 구성할 수 있으며로드가 심한 경우, 그리고 큰 프로세싱 파워를 가지고하지 않는 서버에 불을 로드할을 구성했다. 체중 부하가없는 경우에는 정의된 다음 NLB 클러스터의 모든 서버 부하 동등한 무게가있다. 할당할 수있는 최저 무게를 0, 그리고 최고가 100입니다.

트래픽 분배 용어 NLB 클러스터에 배포하는 방법을 클라이언트의 요청을 참조하는 데 사용됩니다. 한 NLB 클러스터에있는 각 서버는 다음과 IP 주소는 :

* 클라이언트 요청이 클러스터의 지시에 대한 클러스터 IP 주소입니다.

* 예약됨 트래픽에 대한 IP 주소를 명시하도록 지시했다.

앞에서 언급했듯이, 모든 클라이언트의 요청에 클러스터 IP 주소로 전송하는 NLB 클러스터에있는 각 호스트에 의해 수신됩니다. 이 NLB를 드라이버 네트워크 어댑터와 TCP / IP 프로토콜 사이의 클러스터 기능에있는 각 서버에 대해 구성되어있다. 드라이버 관리 및 NLB 클러스터 포트 규칙에 따라 지정된 서버에 클라이언트 요청을 할당합니다. 클러스터에서 특정 호스트에 특정 포트에 포트 규칙을 직접 트래픽.

a NLB 클러스터에있는 서버 클러스터의 상태를 확인하는 심장 박동이 메시지를 보낼 수있습니다. 각 심장 박동이 메시지는 다음 정보가 포함되어있습니다 :

* 정보 NLB 클러스터의 상태에있다.

* 정보는 클러스터의 구성에있습니다.

* 정보 포트 규칙에있다.

서버 또는 제거할 때마다 한 NLB 클러스터, 컨버전스 과정에서 추가 발생으로 알려져있다. 컨버전스를 재구성은 구성 자체가 너무 서버 (들를 포함시킬 수있습니다) 추가 또는 제거 NLB 클러스터 수있습니다. 또한 컨버전스 때 클러스터에서 서버를 5 초 이내에 심장 박동이 메시지를 보내지 않습니다 일어난 일입니다. 융합 과정에서, 모든 클라이언트 요청은 여전히 NLB 클러스터에 의해 처리됩니다.

컨버전스 동안 발생하는 이벤트는 여기에 나열되어있습니다 :

* 이는 NLB 클러스터에 속하는 서버가 결정됩니다.

* 기본 호스트가 결정됩니다.

* 체중 부하 요인이 계산됩니다.

NLB를 클러스터의 장점은 여기에 나열되어있습니다 :

* 이 NLB 클러스터 서버가 실패하면 자동으로 하나, 그리고 다음은 클러스터의 다른 서버를 검색할 수있는 온라인하는 트래픽을 요청 reroutes. 이 임무를 위해 향상된 고가용 성과로드 밸런싱 - 크리티컬한 애플 리케이션에있다.

* 때문에 클라이언트 요청을 여러 서버 사이의 NLB 클러스터에 분산되어있는 애플 리케이션의 성능을 조정하실 수있습니다.

* 로 네트워크를 확장 당신은 쉽게 NLB 클러스터에 추가 서버를 추가할 수있습니다. 클러스터에서 서버를 추가하거나 제거를 폐쇄해야하는 NLB 클러스터가없습니다.

* the NLB 클러스터를 클라이언트 요청로드, 처리 구성에 대해 지정된 클러스터를 기반으로 균형을하고있다. 또한 포트 규칙을 구성하는 구체적인 요청을 처리할 수있는 서버를 지정해야합니다.

이해 포트 규칙

포트 규칙 구성을 통해 클라이언트의 요청을 어떻게 NLB 클러스터에있는 서버에 의해 처리됩니다 지정할 수있습니다. 포트 규칙을 기본적으로 행위를 특정 포트 (시내에있는 필터). 당신과 필터링 모드를 구성할 수있는 매개 변수를 지정하는 방식 프로토콜 트래픽되어야로드 서버 간의 균형 NLB 클러스터에있다.

프로토콜 프로토콜은 특정 포트 범위에있는 매개 변수를 필터링해야한다을 지정하는 데 사용됩니다. 매개 변수에 지정된 요청 프로토콜 프로토콜 포트 규칙에 의해, 그리고 영향을받는 다른 모든 요청을 누른 다음 기본 모드는 호스트 우선 순위 설정에 정의된 필터링에 의해 처리됩니다.

포트 범위의 포트를 정의하는 일련의 포트 또는 포트의 규칙에 대한 적용하는 데 사용됩니다. 2 포트 범위가 중복은 허용되지 않습니다.

각 포트 규칙을하는 방법으로 클라이언트 요청 NLB 클러스터 호스트가 클러스터에 거주하여 처리하는 필터링 모드를 나타냅니다.

다음 필터링 모드 옵션을 구성할 수있습니다 :

* 장애;, 그리고 트래픽 포트 범위에서 지정된 IP 주소, 프로토콜과 일치하는 블록을 사용하는 NLB 클러스터에 접수되고있다.

* 단일 호스트; 트래픽에 클러스터 IP 주소, 프로토콜 및 포트 범위 검색은 NLB 클러스터에서 단일 호스트에 의해 처리됩니다.

* 여러 호스트; 트래픽에 클러스터 IP 주소, 프로토콜 및 포트 범위와 일치하는 여러 호스트에 NLB 클러스터 내에 배포됩니다. 로드 무게를 설정하고 선호도를 설정하는 클라이언트 요청을 처리하는 특정 호스트를 확인하는 데 사용됩니다. 동질 같은 클라이언트에서 호스트 사이에 얼마나 많은 요청에 관한 클러스터에 배포됩니다. 당신과 그 사이에 선택할 수있는 옵션이있습니다 선호도 :

o 없음; 나타냅니다는 클라이언트의 요청을 처리할 수있는 포트 규칙에 일치하는 클러스터에있는 호스트.

o 단일; 그 NLB 클러스터에 하나의 호스트가 동일한 클라이언트 로부터의 트래픽을 처리할 수있는 것을 나타냅니다. 요청을 할 때마다 기본적으로 동일한 호스트에 IP 주소를 읽습니다 NLB를 전송됩니다.

o 클래스 C, 클래스 C는 동일한 IP 서브넷에서 모든 클라이언트의 요청을 NLB 클러스터에 동일한 호스트로 전송을 나타냅니다. 아니로드 밸런싱이 가맹 옵션이 활성화되어 수행됩니다.

NLB 클러스터 구축 계획

NLB를 설치 요건과 당신이 고려해야 할 몇 가지 요소의 수를 여기에 나열되어있습니다 :

* 윈도우 2000 Advanced Server 또는 모든 Windows Server 2003의 에디션.

* TCP / IP 프로토콜.

* 섬유 분산 데이터 인터페이스 (FDDI), 이더넷 또는 기가 비트 이더넷

* 1.5 MB의 사용 가능한 하드 디스크 공간

* 4메가바이트 - 2백50킬로바이트의 RAM

* 각 클러스터 호스트에 대한 두 개의 네트워크 어댑터가 있어야합니다.

* NLB 클러스터에있는 호스트가 동일한 실제 서브넷에 존재한다 거주하고있다.

* 당신은 NLB 클러스터에 추가하는 TCP 또는 UDP 포트를 사용하여 애플 리케이션의 기능이 있어야합니다 계획.

* NLB 클러스터를 사용하는 클라이언트는 TCP / IP를 연결할 수 있어야합니다.

* 당신은 당신은 NLB 클러스터에 추가할 계획이 애플 리케이션의 유형에 따라 서버 용량을 계획해야한다.

* 당신은 NLB 클러스터 예상 클라이언트의 요청을 로드할 때까지 클러스터에 의해 수정 되 어질 수있는 서버를 추가한다. 과부하 안 클러스터를 조심해라.

* 당신은 그 NLB 클러스터에있는 서버에 호스팅 애플 리케이션을 지원할 수 있도록 그들에게 필요합니다. 그들은 호스트 애플 리케이션 서버가 제대로 실행되도록 구성해야한다. NLB를 가지고, 모든 애플 리케이션에 적합한 포트와 TCP / IP를 사용하는로드 밸런싱을 위해 구성할 수있습니다 구성할 수있습니다. NLB 클러스터에서 지원되는 애플 리케이션의 FTP, TFTP를, SMTP, HTTP와,와 HTTPS 등이있다.

당신은 그 때 NLB 클러스터의 가용성을 높이기 기어드하는 요소를 포함해야하며 NLB 클러스터 계획 :

* 실패의 가능성이 점을 모두 제거합니다.

* 무정전 전원 공급 장치를 사용합니다.

* 는 WAN에 이중화 액세스를 보장합니다.

* 로드 균형에만 적합한 애플 리케이션.

* 서버를 올바르게 구성하는 애플 리케이션을 실행하도록에서 호스팅됩니다.

전에 여기에 나와있는 NLB 클러스터를 구현할 수 있는지 판단하는 데 필요한 몇 가지 요소 :

* 클러스터에 대한 IP 주소와 서브넷 마스크를 확인합니다.

* 클러스터에 대한 인터넷 이름을 확인합니다.

* 클러스터가 멀티 캐스트 모드에서 작동 여부 또는 유니 캐스트 모드로가는가를 결정합니다.

* 각 호스트에 대한 NLB 클러스터로, 자사의 우선 순위 결정이 추가됩니다.

* 원격 수술을 위해 비밀 번호를 결정할 수있습니다.

* 처리 우선 순위를 결정합니다.

* 그리고 당신이 가고있는 포트 범위를 사용하는 귀하의 포트 규칙을 확인합니다.

* 필터링 모드를 결정합니다.

* 프로토콜을 결정합니다.

* 당신이 사용되며 선호도 옵션을 확인합니다.

한 NLB 클러스터 확보

한 NLB 클러스터 확보를위한 몇 가지 전략이 여기에 나열되어있습니다 :

* 물리적으로 클러스터의 서버를 확보했다.

* 클러스터 인프라에 대한 물리적인 액세스를 제한합니다.

* 모든 미션 크리티컬 서버 클러스터 방화벽 뒤에 위치해야합니다.

* 그 클러스터로 연결되는 방화벽 구성 트래픽을 제어하는 데 사용합니다.

* 애플 리케이션의 보안 기능은 NLB 클러스터에서 NLB 클러스터 더 확보하는 데 사용해야합니다 호스팅.

* 각 개별 클러스터 관리를 위해 고유 계정을 사용해야합니다. 하나의 계정이있다면 손실이 크다 즉, 모든 클러스터에 사용되지 않을 수 있도록했다.

* 정기적으로 NLB 클러스터에 활동을 감사해야한다.

NLB 클러스터를 만드는 방법

1. 시작을 누르고, 관리 도구를 누른 다음 네트워크로드 균형 조정 관리자.

2. 클러스터를 클릭하여 메뉴 항목을 누른 다음 New를 선택합니다.

3. 클러스터 매개 변수 대화 상자의 클러스터 IP 구성 영역에서 새로운 NLB 클러스터에 대한 IP 주소, 서브넷 마스크 및 전체 인터넷 이름을 지정합니다.

4. 클러스터 매개 변수 대화 상자의 클러스터 작업 모드 섹션의 영역에서 클러스터에 대한 모드를 선택합니다.

5. 로드하면 - 잔액이 여러 IP 주소를 원하는 클러스터 IP 주소 대화 상자에서 추가 단추를 누릅니다. 다음을 클릭합니다.

6. 포트 규칙 대화 상자에서 기본 포트 규칙이 표시됩니다. 포트 규칙 구성을 클릭하고 편집 버튼을 클릭하십시오.

7. 추가 / 수정 포트 규칙 대화 상자가 열립니다. 당신을 추가할 수 있으며 포트 규칙을 제거합니다.

8. 포트 규칙 대화 상자에서 다음을 클릭합니다.

9. 연결 대화 상자에서 다음 연결 버튼을 클릭하고 호스트 필드에 호스트의 이름을 제공합니다.

10. 이는 분산되어야 네트워크 인터페이스를 지정합니다. 다음을 클릭합니다.

11. 호스트 매개 변수 대화 상자에서 우선 순위, 전용 IP 주소와 서브넷 마스크가 호스트에 대한 정보를 지정할 수있습니다.

12. 기본 상태 시작하는 호스트의 설정합니다.

13. 마침을 누릅니다.

14. 네트워크로드 균형 조정 관리자, 새로운 클러스터를 표시 열립니다.

NLB를 클러스터 문제 해결

당신은 네트워크로드 로그 항목은 NLB 클러스터의 활동에 의해 만들어보기로 균형 조정 관리자를 사용할 수있습니다.

이 NLB를 로그 항목은 다음과 같은 정보를 제공합니다 :

* NLB 클러스터의 구성을 변경했다.

* 귀하의 NLB 클러스터에 거주하는 호스트의 잘못된 구성 설정 오류로 인한.

NLB를 클러스터 문제 해결을위한 몇 가지 전략을 아래에 요약하고있다 :

* NLB가 설치되어있는 경우에는 IP 주소가 충돌 후 :

o 그 같은 기본 IP 주소를 각 호스트는 NLB 클러스터에 포함된 구성되어 있는지 확인합니다.

o 경우 유니 캐스트 모드에서하는지 여부를 확인하는 네트워크 어댑터의 네트워크 주소가 변경되었습니다 NLB를 실행하고있습니다. 멀티 캐스트 모드로 변경하거나 기존의 네트워크 어댑터를 변경해야 할 수도있습니다.

* 응용 프로그램이 올바르게 작동하지 않는 경우에는 클러스터 호스트에서 실행해야 문제가 응용 프로그램을로드 균형되는 포트 (s)로 예정이다. 귀하의 포트 규칙은 분산 애플 리케이션들만 포함되어야합니다.

* 만약 기본 클러스터 호스트, 포트를 사용하는 응용 프로그램에 의해 포트 규칙에 반드시 포함되도록 모든 클라이언트 요청을 처리하는있습니다. NLB를 가지고, 모든 트래픽은 포트 규칙에 의해, 기본 클러스터 호스트에 결국 영향을하지 않습니다.

* 제대로 작동하지 않는 경우로드 균형되고 응용 프로그램 구성 :

o 그 문제가 응용 프로그램에 거주하는 모든 NLB 클러스터 호스트에서 실행되고 있는지 확인합니다. 응용 프로그램을 수동으로 시작되고있다.

o 그 응용 프로그램이 실제로로드 균형이 될 수 있는지 확인하십시오.

o 그런 응용 프로그램은 TCP / IP 프로토콜을 사용하도록 구성되어 있는지 확인합니다.

o 모든 포트를 사용하는 응용 프로그램에 의해 분산되어 있는지 확인합니다.

o 그 정의는 응용 프로그램에서 사용하는 포트 규칙을 각 포트에 포함되어 있는지 확인하십시오.

o 그 선호도가 활성화되어 있는지 확인하고 옵션 중 하나를 단일 또는 클래스 C 옵션으로 지정되었습니다.

애플 리케이션이 될 NLB 클러스터에서로드 밸런스, 응용 프로그램은 다음의 요건을 충족하고있다 :

o TCP 포트 또는 UDP 포트 애플 리케이션을 사용해야합니다.

o 응용 프로그램의 여러 인스턴스를 동시에 실행하는 능력이 있어야합니다.

o 클라이언트는 TCP를 통해 연결해야합니다 / IP를.

o 선호도, 다음 옵션 중 하나와 함께 사용하도록 설정해야합니다 : 단일 옵션이나 클래스 C 옵션을 선택합니다.

* 클러스터에있는 경우 호스트 모이다을 시작했지만 실패 과정을 완료하려면 :

o 그 포트 규칙과 호환되는지 확인합니다.

o 그 같은 포트 규칙은 클러스터의 모든 호스트에 존재하는지 확인합니다.

* NLB를 융합하는 경우 프로세스, 후 하나 이상의 기본 호스트는 NLB 클러스터에 존재 :

o 그 기본 IP 주소가 동일 NLB 클러스터 내의 각 호스트에 구성되어 있는지 확인합니다.

o 그 클러스터의 주 IP 주소에 지정되어있는 TCP / IP 속성을 확인합니다.

o 또한 호스트로 인해 수도 문제는 네트워크에, 일반적으로 그들은 서로 다른 서브넷에 위치하고 있기 때문에 액세스할 수있다.

* NLB 클러스터에서 호스트하는 경우에는 원격 명령에 응답하지 않습니다 :

o 그런 다음 원격 컴퓨터의 올바른 서브넷에 있는지 확인합니다.

o 은 UDP를 조절 포트는 방화벽 구성에 의해 차단되지 않고 있는지 확인합니다.

o 그 명령은 클러스터의 주 IP 주소로 발송되었는지 확인합니다.