ISA Server 2004를 위한 실 환경에서의 성능 지침
ISA Server 2004를 위한 실 환경에서의 성능 지침
Microsoft ISA(Internet Security and Acceleration) Server 2004
이 페이지에서
 |
소개 |
|
요약 내용 |
|
ISA Server 용량 계획 |
|
성능 최적화 지침 |
|
시나리오 |
|
ISA Server 확장 |
|
구성 저장소 서버 크기 조정 |
|
크기 조정 참조 및 예 |
|
추가 정보 |
소개
Microsoft ISA(Internet Security and Acceleration) Server 2004는 네트워크 간 제어된 보안 접속을 제공하며 고속 웹 응답 및 오프로드 기능을 제공하는 웹 캐시 프록시로 사용되는 제품입니다. ISA Server의 다중 계층 구조와 고급 정책 엔진은 필요한 보안 수준과 필요한 리소스 사이의 균형을 세부적으로 제어할 수 있는 기능을 제공합니다. 많은 네트워크에 연결되는 최 전방 서버인 ISA Server는 조직 내 다른 서버에 비해 대량의 트래픽을 처리합니다. 이러한 이유로 ISA Server는 고성능 사양으로 구성해야 합니다. 본 문서에서는 최상의 성능과 적절한 용량을 갖춘 ISA Server를 배포하기 위한 지침을 제공합니다.
요약 내용
대부분의 경우, 사용 가능한 네트워크 대역폭(특히 인터넷 연결 대역폭)에 비례하여 계산된 최저 사양 하드웨어에서 실행되는 ISA Server를 통해 보안을 유지할 수 있습니다. HTTP(Hyper Text Transfer Protocol) 트래픽에 대한 웹 접속을 보호하는 ISA Server의 일반적인 기본 배포에는 사용하는 인터넷 대역폭에 따라 필요한 하드웨어 구성이 결정 됩니다. 다음 표는 이러한 하드웨어 구성을 보여 줍니다. (자세한 내용은 이 문서의 웹 프록시 시나리오를 참조하십시오.)
| 인터넷 연결 대역폭 | 최대 5 T1 (7.5Mbps) | 최대 25Mbps | 최대 T3 (45Mbps) |
|
프로세서 |
1 |
1 |
2 |
|
프로세서 유형 |
Pentium III 550MHz 이상 |
Pentium 4 2.0–3.0GHz |
Xeon 2.0–3.0GHz |
|
메모리 |
256MB |
512MB |
1GB |
|
디스크 공간 |
150MB |
2.5GB |
5GB |
|
네트워크 어댑터 |
10/100Mbps |
10/100Mbps |
100/1000Mbps |
|
동시 VPN(Virtual Private Network) 원격 액세스 연결 수 |
150 |
700 |
850 |
HTTP 필터링 대신에 L3기반 포트 필터링을 사용하면 동일 트래픽 패턴에 대한 CPU 사용률이 1/10로 줄어듭니다. L3기반 포트 필터링과 응용 프로그램 필터링을 함께 병렬로 사용하면 성능을 보다 세부적으로 제어할 수 있습니다.
ISA Server 용량 계획
용량 요구 사항과 관련하여 고려해야 할 첫 번째 단계는 ISA Server 를 통한 서비스를 결정하는 일입니다. 다양한 배포시나리오를 위한 여러 가지 사례가 마련되어 있으며, 일반적으로 다음과 같은 고려사항이 있을 수 있습니다.
| • |
ISA Server 컴퓨터에 연결되는 모든 네트워크의 사용 가능한 대역폭 및 실제 대역폭 |
| • |
조직의 사용자 수 |
| • |
다양한 응용 프로그램별 고려사항 (예: 메일 서버의 평균 사서함 크기) |
실제 네트워크 대역폭은 ISA Server 용량의 가장 중요한 고려사항입니다. 네트워크 대역폭(특히 인터넷 연결 대역폭)에 따라 ISA Server 용량을 결정하는 경우가 대부분입니다.
사용자 수는 사용자 요구와 조직의 네트워크 정책에 따른 사용자별 사용 패턴이 다르기 때문에 용량에 그다지 큰 영향을 미치지 않습니다. 경우에 따라, 사용자 수뿐만 아니라 응용 프로그램별 고려사항도 네트워크 트래픽을 예상하는 데 유용할 수 있습니다.
ISA Server 용량 계획은 다음 두 가지중 하나의 경우로 나눌 수 있습니다.
| • |
최저 사양의 단일 ISA Server 컴퓨터를 통해 모든 네트워크 대역폭이 제공되는 경우 : 자세한 내용은 이 문서의 단일 최저 사양 컴퓨터를 참조하십시오. |
| • |
네트워크 대역폭이 단일 컴퓨터에서 제공할 수 있는 크기보다 더 크고, ISA Server를 엔터프라이즈 규모의 응용 프로그램 보안에 사용하는 경우 : 자세한 내용은 이 문서의 엔터프라이즈 규모를 참조하십시오. |
단일 최저 사양 컴퓨터
대부분의 경우, 단일 컴퓨터는 표준 인터넷 연결을 통해 전송되는 트래픽을 보안할 수 있는 충분한 처리 성능을 갖추고 있습니다. 인터넷 사용에 대한 시장 조사 보고서에 따르면 대부분의 기업 인터넷 연결 대역폭은 2Mbps ~ 20Mbps라고 합니다. 따라서 단일 또는 듀얼 프로세서를 장착한 최저 사양의 컴퓨터로도 대부분의 ISA Server를 충분히 배포할 수 있음을 알 수 있습니다.
외부 방화벽 테스트 결과에 따라, 단일 Pentium 4 2.4GHz 프로세서에서 실행하는 ISA Server는 75%의 CPU 사용률에서 약 25Mbps의 처리량을 제공할 수 있습니다. 다시 말해서, 각 T1 인터넷 링크(1.5Mbps)에 대해 Microsoft 방화벽 서비스는 CPU 리소스의 4.5%만 사용합니다. 듀얼 Xeon 2.4GHz 프로세서는 모든 T1에 대해 2.5% CPU사용으로 처리 할 수 있으며, 45Mbps인 T3의 경우 75% CPU사용으로 커버가 가능합니다.
또한 지점의 단일 최저 사양 컴퓨터는 위의 단락에서 설명한 대역폭 제한 하에서 독립적인 WAN(광역 네트워크) 인터넷 연결을 통해 기업 리소스에 연결될 수 있습니다.
엔터프라이즈 규모
500명 이상의 사용자를 포함하는 엔터프라이즈 규모의 대형 사이트의 경우에는 좀 더 복잡한 환경을 가집니다. 이 경우에는 인터넷 대역폭이 매우 커서 시스템 CPU의 사용량 계산보다 정교한 계획이 필요합니다.
인터넷 연결 대역폭으로 인해 연결을 완벽하게 사용할 수 있는 컴퓨터 수는 제한되지만, 이 최대값은 대부분의 예상 용량으로 충분히 서비스가 가능합니다 용량 요구 사항은 시간이 지남에 따라 증가하므로 처음에는 최대 네트워크 용량에 대한 계획이 대략적인 형태일 수 있습니다. 향후 확장을 수용하려면 처리 성능에 대한 업그레이드도 계획해야 합니다. 하드웨어 확장 기술, 성능 특성 및 기타 확장 이점에 대한 설명은 이 문서의 ISA Server 확장을 참조하십시오.
성능 최적화 지침
요구에 맞는 시스템을 결정하고 나서 다음에 할 일은 성능을 극대화할 수 있도록 설정하는 것입니다. 엔터프라이즈 규모의 ISA Server에서 성능 최적화란 시스템이 CPU 사용을 최대화하여 최적화 서비스를 제공하기 위해 충분한 양의 하드웨어 리소스를 디자인하는 것을 의미합니다. 단일 최저 사양의 ISA Server 컴퓨터의 경우에는 선택하는 프로세서가 보다는 인터넷 대역폭이 병목의 원인이 됩니다.
하드웨어 최적화를 통한 CPU 사용률 극대화
ISA Server의 용량은 CPU, 메모리, 네트워크 및 디스크 하드웨어 리소스에 따라 다릅니다. 리소스마다 용량 제한이 있으며, 모든 리소스가 제한을 초과하지 않는 한 시스템이 전체적으로 올바르게 작동하며 성능 목표를 달성할 수 있습니다. 이러한 제한 중 하나에 도달할 경우 병목 현상이 발생하며 성능이 크게 저하됩니다. 이러한 경우, 시스템이 해당 리소스에 바인딩되어 있다고 말합니다. 병목으로 인해 나타나는 전체적인 시스템 성능상의 증상을 통해 용량이 부족한 리소스를 찾아낼 수 있습니다. 병목을 찾은 후에는 용량이 부족한 리소스에 더 많은 용량을 추가하여 병목을 제거할 수 있습니다.
비용 관점에서 보면 시스템이 CPU 리소스에 바인딩되도록 디자인하는 것이 가장 효율적입니다. 그 이유는 CPU가 업그레이드하는 데 가장 비용이 많이 드는 리소스이기 때문입니다. 다른 리소스의 경우에는 리소스 부족 상태를 해결하는 데 그다지 많은 비용이 들지 않습니다. 다른 디스크 또는 다른 네트워크 어댑터를 추가하거나, 메모리를 추가하기만 하면 됩니다. CPU 사용률을 극대화하려면 시스템의 하드웨어를 조정하는 것이 좋습니다. 최대 CPU 사용률에 도달하기 전에 시스템에 성능 병목 상태가 없도록 해야 합니다. CPU 처리 성능이 예상 로드를 지탱할 수 있는 경우에는 병목이 발생하지 않습니다. 그러기 위해서는 다른 모든 리소스의 용량이 충분해야 합니다. 다음 섹션에서는 각 리소스의 용량이 충분한 CPU 극대화 시스템을 디자인하는 방법, 각 리소스를 모니터링하는 방법 및 각 리소스의 병목 문제를 해결하는 방법에 대해 설명합니다.
CPU 및 시스템 아키텍처 용량 결정
다양한 클라이언트 요청을 처리하는 대부분의 서버 응용 프로그램과 마찬가지로, ISA Server도 보다 빠른 CPU 속도, 더 큰 프로세서 캐시 및 향상된 시스템 아키텍처를 위해 보다 뛰어난 성능을 제공합니다.
| • |
CPU 속도 대부분의 응용 프로그램에서와 마찬가지로 ISA Server도 CPU 속도가 빠르면 더 나은 성능을 제공합니다. 하지만 CPU 속도가 더 빠르다고 해서 성능이 정비례하여 향상되지는 않습니다. 메모리 액세스가 많고 자주 발생할 경우 CPU 속도가 높으면 CPU 주기를 기다릴 때 유휴 메모리 낭비가 더 많을 수도 있습니다. |
| • |
L2/L3 캐시 크기 많은 양의 데이터를 처리하는 경우에는 메모리 액세스 빈도가 높아집니다. L2/L3 캐시는 대규모 메모리 반입에 대비하여 성능을 향상시킵니다. |
| • |
시스템 아키텍처 ISA Server는 네트워크 장치, 메모리 및 CPU 간에 대규모 데이터 로드를 전송하므로 CPU 주변 시스템 요소도 ISA Server 성능에 영향을 미칩니다. 메모리 프런트 사이드 버스와 I/O 버스 속도가 빠르면 전체적인 성능이 향상됩니다. |
CPU 병목은 네트워크 어댑터와 디스크 I/O가 제한 용량을 초과하지 않는 상태에서
\Processor\% Processor Time
성능 카운터 값이 높은 경우입니다. 이 경우, 이상적인 CPU 극대화 시스템이라면 100%에 도달할 경우 보다 빠른 CPU로 업그레이드하거나 다른 프로세서를 추가하여 CPU 처리 성능을 높여야 합니다. CPU 확장 옵션에 대한 자세한 내용은 이 문서의 ISA Server 확장을 참조하십시오. ISA Server에서 응답 시간이 높고 CPU 사용률이 낮은 상태가 지속될 경우 병목 지점은 CPU가 아닌 다른 지점에 있습니다.
하이퍼 스레딩 기능도 CPU 사용량이 60% 이하일 경우 CPU 사용 수준을 낮추는 데 도움이 됩니다. CPU 사용 수준이 높아지면 하이퍼 스레딩 기능의 활성화 여부와 상관없이 동일한 처리 성능이 사용됩니다.
메모리 용량 결정
ISA Server 메모리는 다음 목적으로 사용됩니다.
| • |
네트워크 소켓(대부분 비페이징 풀에서) 저장 |
| • |
내부 데이터 구조 |
| • |
보류 중인 요청 개체 |
웹 프록시 캐시 시나리오에서 메모리는 다음 목적으로 사용됩니다.
| • |
디스크 캐시 디렉터리 구조 |
| • |
메모리 캐시 |
ISA Server는 시스템 비페이징 메모리를 필요로 하는 많은 수의 동시 연결을 처리하기 때문에 메모리 제한 요소는 총 메모리 크기에 포함된 비페이징 풀의 크기입니다. 다음 표는 Microsoft Windows Server 2003 및 Windows 2000 Server에서 비페이징 풀 크기의 최소값 및 최대값을 보여 줍니다.
|
실제 메모리(MB) |
128 |
256 |
512 |
1,024 |
2,048 |
4,096 |
|
최소 비페이징 |
4 |
8 |
16 |
32 |
64 |
128 |
|
최대 비페이징 |
50 |
100 |
200 |
256 |
256 |
256 |
웹 캐시를 사용하지 않는 경우 단일 컴퓨터 프로세서에서는 경우 512MB면 충분하고, 듀얼 프로세서 컴퓨터에서는 1,024MB면 충분합니다. 이 양은 전체 메모리 작업 집향 용량을 저장할 수도 있습니다.
메모리가 올바르게 조정되어 있지 않음을 나타내는 가장 중요한 증거는 최대 로드 시 \Memory\Pages/sec(초당 하드 페이지 오류 수 측정)이 10 이상인 경우입니다. 이와 같은 상황이 발생했을 때 가장 먼저 해야 할 일은 웹 캐시 사용 여부에 따라 다릅니다.
웹 캐시를 사용하지 않는 경우에는 시스템의 모든 프로세스에서 사용하는 메모리를 모니터링하여 실제 메모리가 더 필요한지 여부를 판단해야 합니다. 다음 성능 카운터는 이러한 판단에 도움이 됩니다.
\Memory\Pages/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes
\Process(*)\Working Set
웹 캐시를 사용하는 경우에는 먼저 메모리 캐시 크기를 실제 메모리의 10% 크기로 낮춰 보십시오. 그래도 하드 페이지 오류가 계속 발생하면 1단계를 진행합니다.
네트워크 용량 결정
연결과 관련된 모든 네트워크 장치마다 용량 제한이 따릅니다. 여기에는 클라이언트 및 서버 네트워크 어댑터, 라우터, 스위치, 그리고 이러한 장치를 서로 연결하는 허브가 포함됩니다. 적절한 네트워크 용량이란 이러한 모든 네트워크 장치를 여유롭게 유지할 수 있는 용량을 말합니다. 네트워크 모니터링 작업은 모든 네트워크 장치에 대한 실제 로드가 최대 용량을 초과하지 않도록 유지하는 데 필수적입니다.
네트워크 용량이 ISA Server 성능에 영향을 미치는 일반적인 경우에는 두 가지가 있습니다.
| • |
ISA Server가 WAN 연결을 사용하여 인터넷에 연결되는 경우 대부분의 환경에서 인터넷 연결 대역폭은 트래픽 양에 대한 제한을 설정합니다. 최대 트래픽 시간 중에 성능이 저하되는 원인은 아마도 인터넷 연결을 과도하게 사용하기 때문일 것입니다. |
| • |
ISA Server가 LAN에만 연결되는 경우 이 경우에는 최대 트래픽 요구 사항을 지원할 수 있는 인프라를 갖추는 것이 중요합니다. 그러나, 대부분의 환경에서 100Mbps 및 1Gbps LAN을 저렴한 가격으로 사용할 수 있기 때문에 이 경우는 문제가 되지 않습니다. |
네트워크 작업을 모니터링하려면 성능 카운터를 사용합니다.
\Network Interface(*)\Bytes Total/sec
값이 네트워크 인터페이스 최대 대역폭의 75% 이상이면 네트워크 인프라의 대역폭이 충분하지 않으므로 대역폭을 늘리는 방안을 고려해야 합니다.
디스크 저장소 용량 결정
ISA Server에서 하드디스크 혹은 스토리지는 다음 목적으로 사용됩니다.
| • |
방화벽 작업 로깅 |
| • |
웹 캐시 |
두 가지 모두 사용하지 않거나 트래픽이 없는 경우에는 ISA Server에서 디스크 I/O 작업을 수행하지 않습니다. ISA Server의 기본 설정에서는 로깅이 활성화되고 Microsoft SQL Server 2000 Desktop Engine(MSDE 2000) 로깅을 사용하도록 구성됩니다. 대부분의 배포에서는 디스크 하나면 최대 로깅 속도를 제공하기에 충분합니다. 웹 캐시를 사용하는 경우에는 이 문서의 웹 캐시 섹션에서 설명한 바와 같이 디스크 저장소 용량을 신중하게 계획해야 합니다.
디스크 저장소 시스템의 제한 요소는 초당 물리적 디스크 액세스 횟수입니다. 이 값은 액세스가 얼마나 임의적으로 발생하는지 또는 물리적 디스크의 회전 속도가 얼마나 빠른지에 따라 다릅니다. 대체로 이 값은 초당 100 ~200입니다. 디스크 액세스 비율을 모니터링하는 데 사용할 성능 카운터는 다음과 같습니다.
\PhysicalDisk(*)\Disk Transfers/sec
일정한 시간 동안 이 제한에 도달해 있으면 시스템이 느려져 시스템 응답 시간이 증가하게 됩니다. 이 병목을 제거하기 위한 즉각적인 해결 방법은 다른 물리적 디스크를 추가하여 디스크 액세스 횟수를 낮추는 것입니다.
높은 디스크 액세스 비율의 또 다른 원인은 하드 페이지 오류입니다. 이 문제의 해결에 대한 자세한 내용은 이 문서의 웹 캐시를 참조하십시오.
응용 프로그램 및 웹 필터
ISA Server는 응용 프로그램 필터를 사용하여 응용 프로그램 수준의 보안 검사를 수행합니다. 응용 프로그램 필터는 특정 프로토콜 포트에 등록되는 DLL(동적 연결 라이브러리)입니다. 프로토콜 포트로 전송된 패킷은 응용 프로그램 필터로 전달됩니다. 그러면 응용 프로그램 필터는 응용 프로그램 논리에 따라 패킷을 검사하고 정책에 따라 수행할 작업을 결정합니다. 프로토콜에 할당되어 있는 응용 프로그램 필터가 없는 경우에는 데이터에 대해 TCP 상태 저장 필터링이 수행됩니다. 이 수준에서 ISA Server는 TCP/IP 헤더 정보만 검사합니다.
일반적으로 몇 가지 이유에서 응용 프로그램 수준 필터링에는 TCP 상태 저장 필터링보다 더 많은 처리가 필요합니다.
| • |
응용 프로그램 필터는 데이터 페이로드를 검사하며, TCP 상태 저장 필터링은 TCP/IP 헤더 정보만 확인합니다. 응용 프로그램 필터는 데이터를 확인한 후 차단하거나 응용 프로그램 논리에 따라 내용을 변경하는 등 데이터 페이로드를 사용하여 여러 작업을 수행할 수 있습니다. |
| • |
응용 프로그램 필터는 사용자 모드 공간에서 작동합니다. 전송 수준 필터링은 커널 모드에서 작동합니다. 다시 말해서 전체 운영 체제 네트워킹 스택을 통해 데이터를 전달해야 하므로 추가적인 처리 오버헤드가 발생합니다. |
응용 프로그램 필터는 방화벽 처리 확장기이므로 성능에 영향을 미칠 수 있습니다. 다음 작업을 권장합니다.
| • |
사용하는 필터에 대한 성능 정보를 얻어서 가능한 효율적으로 필터를 조정합니다. 예를 들면, HTTP 페이로드를 검사하고 특정 서명을 검색하도록 HTTP 웹 필터를 구성할 수 있습니다. 이 기능을 사용하면 ISA Server 컴퓨터에 대한 요구를 줄일 수 있습니다. |
| • |
해당되는 경우, 필터 대신에 ISA Server 규칙의 사용을 고려해 보십시오. 예를 들면, 액세스 규칙 대상 집합을 사용하여 사이트를 차단할 경우 웹 필터를 사용하여 사이트를 차단할 때보다 훨씬 효율적일 수 있습니다. |
| • |
필터를 개발하는 경우 성능이 극대화되도록 최적화합니다. 이 작업은 모든 소프트웨어, 특히 업무 수행에 핵심적인 방화벽 또는 프록시 서버에 권장합니다. |
| • |
ISA Server에서는 소스 및 대상 네트워크에 따라 동일한 응용 프로그램 포트에 대해 응용 프로그램 필터링 및 보다 낮은 수준의 TCP 상태 저장 필터링을 사용할 수 있습니다. 예를 들어, 응용 프로그램 수준에서 인터넷 트래픽을 필터링하면서, 동시에 다른 모든 네트워크 간 트래픽에 대해 전송 필터링 보호를 사용할 수 있습니다. |
로깅
ISA Server는 방화벽 작업 로깅 방법으로 두 가지 주요 방법을 제공합니다.
| • |
MSDE 로깅 이 방법은 방화벽 및 웹 작업의 기본 로깅 방법입니다. ISA Server는 로그 레코드를 MSDE 데이터베이스에 직접 기록하므로 기록된 데이터에 대해 정교한 온라인 쿼리를 실행할 수 있습니다. |
| • |
파일 로깅 이 방법을 사용하는 경우에는 ISA Server가 로그 레코드를 텍스트 파일에 순차적인 방식으로 기록합니다. |
두 가지 방법을 비교해 볼 때, MSDE가 더 많은 기능을 제공하는 대신 시스템 리소스가 많이 사용됩니다. 특히, MSDE에서 파일 로깅으로 전환하는 경우에는 프로세서 사용률이 전체적으로 10-20% 향상됩니다.
MSDE 로깅에는 디스크 저장소 리소스도 더 많이 사용됩니다. MSDE 로깅은 1메가비트마다 약 두 번의 디스크 접속을 수행합니다. 파일 로깅의 경우에는 10메가비트마다 같은 양의 디스크 접속을 수행합니다. ISA Server 성능을 향상시키는 한 가지 방법은 MSDE에서 파일 로깅으로 전환하는 것입니다. 이 방법은 포화 상태에 있는 프로세서 또는 디스크 액세스로 인해 성능 문제가 있는 경우에만 권장합니다.
ISA Server 2004 Enterprise Edition은 원격 SQL 로깅도 제공하는데, 이 로깅을 사용하면 모든 레코드를 중앙에서 관리되는 SQL 데이터베이스에 기록할 수 있습니다. 원격 SQL 로깅은 MSDE 로깅과 파일 로깅에서 사용하는 양의 중간 정도에 해당하는 양만큼 CPU 리소스를 사용하며, 디스크 I/O는 거의 사용하지 않습니다. 그러나, 모든 로그 데이터가 중앙 원격 데이터베이스에 기록되기 때문에 원격 SQL 로깅 사용 시 다른 용량 요구 사항을 고려해야 합니다.
| • |
ISA Server 컴퓨터와 원격 SQL 데이터베이스 간 네트워크 연결에서는 전용 기가비트 대역폭을 사용해야만 로그 트래픽 용량을 수용할 수 있습니다. | |||||||||||||||
| • |
ISA Server 컴퓨터와 원격 SQL 데이터베이스 간 네트워크 연결은 IPsec(Internet Protocol Security)를 사용하여 원격 SQL 데이터베이스로 전송될 때 로그 레코드를 보안해야 합니다. | |||||||||||||||
| • |
ISA Server 컴퓨터 몇 대의 로깅율을 지원하기에 충분한 RAID(Redundant Array of Independent Disks) 하드웨어가 있어야 합니다. 다음 표는 세 가지 인터넷 연결 대역폭의 트랜잭션 속도와 로그 대역폭의 예상값을 제공합니다.
대역폭이 큰 경우에는 위 표의 값이 그만큼 증가합니다. |
시나리오
ISA Server는 다양한 배포 및 응용 프로그램 시나리오를 지원합니다. 다음 섹션에서는 주요 시나리오와 성능 특성을 설명합니다.
배포 시나리오
배포 시나리오는 기업 인트라넷 내부 ISA Server 컴퓨터의 위치를 나타냅니다. 보안 및 성능 고려 사항으로 인해 수년 동안 몇 가지 시나리오가 발전하였으며, 다음 섹션에서는 성능 및 용량 관점에서 각각의 시나리오를 설명합니다.
인터넷 최 전방 방화벽
엔터프라이즈 규모의 용량 요구 사항을 가진 조직은 ISA Server 컴퓨터를 모든 기업 클라이언트에 대해 보안 인터넷 게이트웨이로 작동하는 전용 인터넷 최 전방 방화벽으로 배포하는 것을 고려할 수 있습니다. 인터넷 네트워크와 인터넷 연결 간에 수백 Mbps의 높은 처리량을 유지하기 위해 패킷 수준 및 상태 저장 전송 계층 필터링만 제공하도록 ISA Server를 구성할 수 있습니다.
ISA Server가 제공하는 고급 응용 프로그램 수준 필터링은 두 번째 방어 계층에서 활성화되며, 이 계층은 백 엔드 방화벽 ISA Server 컴퓨터로 구성됩니다.
부서 또는 백 엔드 방화벽
엔터프라이즈 규모 조직의 다음 방어선에는 LAN환경에서 오가는 트래픽 접속제어를 제공하는 부서 또는 백 엔드 네트워크 방화벽으로 배포되는 몇 대의 ISA Server 컴퓨터가 포함됩니다. 기존 방화벽 인프라를 사용하는 조직은 인터넷 최 전방에서 현재의 고성능 방화벽을 유지하면서 LAN 최 전방에서 ISA Server 컴퓨터에 정교한 응용 프로그램 계층 필터링을 오프로드할 수 있습니다. 따라서 조직내부에서는 ISA Server 2004 응용 프로그램 계층 필터링 기능이 제공하는 고유의 보호 수준을 활용하면서 현재의 고속 인터넷 연결을 사용할 수 있습니다.
성능 관점에서 볼 때, 부서 방화벽은 전체 트래픽에서 최 전방 방화벽을 통과하는 부분만을 유지하는 데 필요하므로 응용 프로그램 필터와 같은 리소스를 많이 사용하는 다른 보안 기능을 실행하는 것이 적합합니다.
지점 방화벽
ISA Server를 사용하면 사이트 간 VPN(Virtual Private Network) 연결을 사용하여 지점 네트워크를 본사로 안전하게 연결할 수 있습니다. 이 배포에서는 ISA Server가 지점에 배치되어, 지점 네트워크를 본사 네트워크에 연결하는 VPN 게이트웨이로서 역할과 지점 네트워크를 보호하는 방화벽으로서 역할을 모두 수행합니다.
일반적으로 전송 계층에서 필터링되는 사이트 간 VPN은 응용 프로그램 수준에서 필터링되는 인터넷 액세스에 필요한 트래픽 단위당 25%의 처리 성능만 사용합니다.
참고
전송 계층에서 필터링되는 사이트 간 VPN에서 터널을 통과하는 트래픽은 응용 프로그램 수준 필터에서 검사되지 않습니다. 또한 다른 트래픽과 마찬가지로, 사이트 간 VPN 트래픽에 대한 응용 프로그램 수준 필터링은 프로토콜별로 활성화됩니다.
웹 프록시 시나리오
오늘날의 기업 네트워크 내부와 인터넷의 트래픽 중 대부분은 HTTP를 사용합니다. 많은 프로토콜의 트래픽 패턴을 분석해 보면 네트워크 성능에 대한 HTTP의 요구가 높음을 알 수 있습니다. 따라서, 일반적인 웹 트래픽 작업 부하 시뮬레이션은 모든 방화벽의 용량 및 성능 특성을 측정하는 데 실질적으로 많은 도움이 됩니다.
참고
네트워크 성능의 유효성을 검사하기 위한 일반적인 고려사항 중 하나는 TCP 연결마다 교환되는 트랜잭션의 양입니다. HTTP의 일반적인 값(평균 3 ~ 5)은 다른 프로토콜과 비교할 때 낮은 편입니다.
다음 표는 인터넷 연결 대역폭에 따라 세 가지 일반 단일 컴퓨터 배포에서 HTTP 트래픽 지원을 위한 하드웨어 권장 사항을 요약한 것입니다.
|
인터넷 연결 대역폭 |
최대 5 T1 |
최대 25Mbps |
최대 T3 |
|
프로세서 |
1 |
1 |
2 |
|
프로세서 유형 |
Pentium III |
Pentium 4 |
Xeon |
|
메모리 |
256MB |
512MB |
1GB |
|
디스크 공간 |
150MB |
2.5GB |
5GB |
|
네트워크 인터페이스 |
10/100Mbps |
10/100Mbps |
100/1000Mbps |
위 표의 요구 사항은 기본 ISA Server 2004의 설치를 위한 것으로, 수백 가지 규칙을 포함하는 정책 구성입니다. 여기에는 모든 기본 응용 프로그램, 웹 필터링 및 MSDE 로깅도 포함됩니다. 다음은 위의 표에 적용됩니다.
| • |
인터넷 연결 대역폭 대역폭 수치는 전체 HTTP 응용 프로그램 계층 필터링과 함께 ISA Server 2004를 투명한 웹 프록시로 사용하는 요구가 많은 작업 부하에 적용됩니다. 정방향 또는 역방향 웹 프록시로 사용되는 ISA Server는 처리량이 두 배가 될 수 있습니다. 다시 말해서 하나의 T3 대역폭의 최소 권장 컴퓨터는 단일 Pentium 4 프로세서이고 T3 연결이 두 개일 경우 최소 권장 컴퓨터는 듀얼 프로세서 컴퓨터입니다. 다양한 웹 프록시 시나리오 간 성능 차이에 대한 자세한 내용은 이 문서의 프록시 시나리오를 참조하십시오. 보다 높은 수준의 응용 프로그램 필터링이 필요하지 않고 상태 저장 필터링만을 필요로 하는 배포에서는 권장 하드웨어가 LAN 선 속도에 도달합니다. 자세한 내용은 이 문서의 상태 저장 필터링을 참조하십시오. 웹 캐싱을 사용하는 경우 바이트 적중률에 따라 20-30% 정도 인터넷 연결 대역폭을 낮출 수 있습니다. 자세한 내용은 이 문서의 웹 캐시를 참조하십시오. |
| • |
프로세서 이 수치는 수천 개의 IP 주소에 대해 HTTP 트래픽을 시뮬레이션하여 얻은 것으로 ISA Server 프로세서를 70~80% 사용 되었을 때를 기준하였습니다. |
| • |
프로세서 유형 필적할 만한 성능을 가지고 있으며 IA-32 명령어 집합을 에뮬레이트하는 다른 프로세서도 고려해 볼 수 있습니다. |
| • |
메모리 메모리 요구 사항에서 웹 캐시용 메모리 공간은 고려되지 않습니다. 웹 캐시용 추가 메모리에 대한 자세한 내용은 이 문서의 웹 캐시를 참조하십시오. |
| • |
디스크 공간 디스크 공간 요구 사항은 ISA Server 로그에 권장되는 사용 가능한 디스크 공간의 양을 나타냅니다. 웹 캐시 디스크 공간 요구 사항 계획에 대한 자세한 내용은 이 문서의 웹 캐시를 참조하십시오. |
| • |
네트워크 인터페이스 네트워크 인터페이스 요구 사항은 인터넷에 연결되지 않은 내부 네트워크에 대한 요구 사항입니다. |
ISA Server는 기본 제공 웹 프록시 응용 프로그램 필터를 사용하여 HTTP 트래픽 보안을 유지합니다. 이 응용 프로그램 필터는 정방향 프록시, 기업 사용자용 인터넷 아웃바운드 액세스 보호를 위한 투명 프록시, 그리고 내부 사용자의 내부 웹 사이트 인바운드 액세스 보호를 위한 역방향 프록시라는 세 가지 시나리오를 지원합니다. 다음 섹션에서는 성능 관점에서 이러한 각각의 시나리오를 설명하고 어떠한 캐시 방법을 사용하여 성능을 향상시킬 수 있는지에 대해 설명합니다.
프록시 시나리오
이 섹션에서는 정방향 프록시, 투명 프록시 및 역방향 프록시에 대한 시나리오를 제공합니다.
정방향 프록시
정방향 프록시에서는 클라이언트 웹 브라우저가 프록시의 존재 여부를 인식합니다. 예를 들어, Internet Explorer에서는 인터넷 옵션에서 프록시 사용 또는 자동으로 설정 검색을 설정하여 프록시를 인식할 수 있습니다. 프록시를 인식하는 웹 클라이언트에서는 프록시에 대해 직접적으로 연결을 열고 인터넷에서 위치 프록시 요청을 전송합니다. 예를 들어, Internet Explorer는 HTTP 1.1 요청을 전송할 때 프록시에 대해 두 개 연결을 엽니다. ISA Server는 서버에 대한 요청을 받으면 해당 서버에 대한 연결을 열고 이 연결을 다른 클라이언트에서 동일한 서버로 들어오는 다른 요청에도 다시 사용합니다. 따라서 별 모양의 연결 토폴로지가 형성됩니다.
이 시나리오의 성능 이점은 연결 재사용률이 높아서 열려 있는 연결 수와 연결 속도를 모두 최소화한다는 점입니다.
투명 프록시
투명 프록시에서는 클라이언트 웹 브라우저가 프록시의 존재 여부를 인식하지 못합니다. 클라이언트 웹 브라우저는 중간 에이전트 없이 인터넷에서 서버로 직접 라우팅되는 것으로 인식합니다. 특히, 웹 클라이언트는 대상 웹 사이트와의 연결을 열어서 인터넷 서버에 직접 액세스합니다. 이 경우에는 사용자가 새 서버의 페이지를 요청한 후 웹 브라우저가 현재 웹 서버와의 연결을 종료하고 새 웹 서버와의 새 연결을 열기 때문에 연결 속도가 크게 증가합니다. 이러한 동작은 투명 프록시의 전형적인 형태로서 ISA Server 성능에 영향을 미칩니다. 일반적으로 투명 프록시의 클라이언트 쪽 연결 속도는 정방향 프록시의 세 배 가량 높으며, 요청당 프로세서 주기의 약 두 배를 사용합니다.
투명 프록시는 배포하기가 쉽기 때문에 널리 사용되는 시나리오입니다. 특히 다른 유형의 클라이언트를 포함하는 ISP(인터넷 서비스 공급자)의 경우에 많이 사용합니다. 따라서, 이 시나리오에는 고려해야 할 성능 향상 부분이 있습니다.
일반적으로 ISA Server는 정방향 프록시와 비교할 때 투명 프록시에 대해 두 배의 CPU 리소스를 필요로 합니다.
역방향 프록시
역방향 프록시 또는 웹 게시는 정방향 프록시와 동일한 방식으로 작동하지만 방향이 아웃바운드가 아닌 인바운드입니다. 이 시나리오에서 ISA Server는 인터넷의 클라이언트가 액세스하는 웹 사이트로 작동합니다. 클라이언트는 클라이언트에서 액세스하려 하는 웹 사이트가 실제로는 프록시임을 알지 못합니다. 정방향 프록시와 마찬가지로, 연결을 효율적으로 재사용할 수 있으므로 연결 수와 연결 속도는 최소 수준입니다. 역방향 프록시는 Microsoft 인터넷 정보 서비스(IIS), Microsoft Office Outlook Web Access 2003, Microsoft SharePoint Portal Server 등 웹 서버의 보안 게시에 사용됩니다.
성능 관점에서 역방향 프록시는 정방향 프록시와 비슷한 특징을 가지고 있습니다. 주된 차이점은 트래픽의 대부분이 ISA Server에서 인터넷 사용자로 전송되므로 많은 인터넷 연결이 필요하다는 점입니다. 다음 섹션에서 설명하는 바와 같이, 정방향 프록시 및 역방향 프록시는 웹 캐시 사용 시 서로 다른 성능 영향을 미칩니다.
웹 캐시
웹 캐시는 모든 웹 프록시 시나리오에서 ISA Server 성능을 향상시키기 위한 기능입니다. 그러나 성능 향상의 결과는 아웃바운드 시나리오(정방향 및 투명 프록시)에 대해 캐시를 사용할 때와 인바운드 역방향 프록시 시나리오에 대해 캐시를 사용할 때 서로 다르게 나타납니다.
정방향(투명) 캐시와 역방향 캐시의 주된 차이점은 캐시의 용도입니다. 정방향 및 투명 캐시는 사용자 부근에 자주 캐시할 수 있는 콘텐츠를 배치하여 응답 시간을 줄이고 인터넷 대역폭 비용을 절감하는 것입니다. 역방향 캐시는 백 엔드 웹 서버 오프로드에 사용됩니다. 역방향 캐시는 응답 시간에 아무런 영향을 미치지 않으며 캐시되지 않는 개체의 경우에는 오히려 대기 시간이 증가됩니다.
대역폭 비용 절감 차원에서 보면 정방향 캐시는 액세스 시도를 캐시에서 제공함으로써 필요한 인터넷 연결 대역폭을 낮추어 인터넷에서 웹 서버에 대한 액세스 시도를 줄입니다. 예를 들어, 캐시 바이트 적중률이 20%이고 인터넷 연결의 최대 처리량이 10Mbps일 경우 인터넷 연결의 최고 처리량은 8Mbps에 불과합니다.
참고
캐시 개체 적중률은 프록시가 제공하는 총 개체 중 캐시에서 제공하는 개체의 비율입니다. 마찬가지로, 캐시 바이트 적중률은 프록시가 제공하는 총 바이트 중 캐시에서 제공되는 바이트의 비율입니다. 개체 적중률과 바이트 적중률의 일반적인 평균 값은 각각 약 35%와 약 20%입니다.
역방향 캐시는 하드웨어 비용과 관리 비용이 모두 절감되므로 웹 서버를 통합하는 데 도움이 됩니다. 예를 들어, 웹 사이트의 데이터 중 80%가 캐시 가능한 정적 데이터이며 정적 개체에 비해 동적 개체에 네 배의 CPU 주기가 필요한 경우, 역방향 프록시를 사용하면 웹 서버 수가 100% 감소됩니다.
참고
정적 개체에 X CPU 주기가 필요하다고 가정할 경우 동적 개체에는 4X 주기가 필요합니다. 100개의 요청 중 80개가 정적이면 100개의 요청에 필요한 총 주기 수는 80X + (100-80)4X = 160X이며, 이 중 50%가 ISA Server 캐시에서 제공되는 정적 콘텐츠에 사용됩니다.
정방향 캐시와 역방향 캐시의 또 다른 차이점은 캐시되는 작업 집합의 크기입니다. 역방향 캐시에서 클라이언트 공간의 크기는 무제한이지만 서버 공간에는 몇 개의 웹 사이트와 상대적으로 매우 작은 개체만 포함되어 있습니다. 대부분의 경우, 호스트된 모든 캐시 가능 콘텐츠를 캐시에 저장할 수 있을 만큼의 충분한 메모리와 디스크 공간으로 ISA Server를 디자인할 수 있으므로 캐시 불가능한 동적 콘텐츠만 호스트된 웹 서버로 지정됩니다. 오히려 모든 캐시를 유지하며 메모리에서 제공할 수 있습니다.
정방향 캐시에서 서버 공간에는 무제한의 웹 사이트 및 웹 개체가 포함되므로 캐시 작업 집합의 크기가 무제한입니다. 이러한 대규모 작업 집합을 유지하기 위해서는 대형 디스크 캐시를 정의해야 합니다. 다음 섹션에서는 정방향 및 역방향 캐시에 맞게 웹 캐시 용량을 계획하고 조정하는 방법을 설명합니다.
정향 캐시 메모리 및 디스크 조정
정방향 캐시에서 개체 적중률과 최대 HTTP 요청률은 다음 공식에 따라 필요한 디스크 수를 결정하는 데 사용됩니다.
예를 들어, 최대 요청률이 초당 900개이고 개체 적중률이 35%인 경우에는 네 개의 디스크가 필요합니다.
참고
앞의 공식에서 100이란 값은 평균 실행 속도의 물리적 디스크(분당 10,000번 회전)가 초당 100번의 I/O 작업을 처리할 수 있음을 의미하는 경험치입니다. 분당 15,000번을 회전하는 고속 디스크의 경우에는 초당 130-140번의 I/O 작업을 수행할 수 있습니다.
가급한 한 동일한 유형 및 용량의 전용 디스크를 사용하는 것이 좋습니다. RAID 저장소 하위 시스템을 사용하는 경우에는 내결함성이 없는 RAID 0으로 구성해야 합니다. 또한 40GB 이하의 용량이 작은 디스크를 사용하는 것이 좋습니다.
캐시 메모리 조정은 좀 더 복잡합니다. 캐시 시나리오에서 메모리는 다음 목적으로 사용됩니다.
| • |
보류 중인 요청 개체 보류 중인 요청 개체 수는 ISA Server 컴퓨터에 대한 클라이언트 연결 수에 비례합니다. 대부분의 경우 클라이언트 연결의 50% 이하입니다. 각 보류 중인 요청에는 약 15KB가 필요합니다. 동시 연결 수가 10,000개인 경우 보류 중인 요청 개체에 대해 |
| • |
캐시 디렉터리 각 캐시된 개체에 대해 32바이트 항목을 포함하는 디렉터리입니다. 캐시 디렉터리의 크기는 캐시 크기와 평균 응답 크기에 의해 직접 결정됩니다. 예를 들어, 각 개체에 대해 평균 약 7KB가 사용된다고 가정할 때 7,000,000개의 개체를 포함하는 50GB의 캐시에는 32 x 7,000,000 = 224MB가 필요합니다. |
| • |
메모리 캐시 메모리 캐시의 용도는 자주 캐시되는 개체에 대한 요청을 메모리에서 직접 처리하여 디스크 캐시 반입을 줄이는 것입니다. 하지만 정방향 캐시에서는 캐시 가능 콘텐츠에 대한 제한이 없기 때문에 메모리 캐시 크기가 성능에 미치는 영향이 제한적입니다. |
기본적으로 메모리 캐시는 총 실제 메모리의 10%이며 원하는 값으로 구성할 수 있습니다. 일반적으로 하드 페이지 오류가 발생하지 않을 경우 기본 설정을 사용하는 것이 좋습니다. 하드 페이지 오류는 성능을 크게 저하시킵니다. 캐시를 사용할 때 이 문제를 해결할 수 있는 가장 쉬운 방법은 메모리 캐시의 크기를 줄이는 것입니다.
이 점을 고려하여 캐시 메모리 크기 조정 시 다음 프로세스를 수행하십시오.
|
1. |
앞의 섹션에서 설명한 대로 디스크 캐시 크기를 조정합니다. | ||||||||||
|
2. |
다음 크기의 합을 필요한 예상 메모리 양으로 설정합니다.
| ||||||||||
|
3. |
메모리 사용을 모니터링하면서 그에 따라 메모리 캐시 크기를 변경합니다. 유용한 성능 카운터는 다음과 같습니다. |
역방향 캐시 메모리 및 디스크 조정
정방향 캐시와 비교할 때 역방향 캐시의 작업 집합 크기가 매우 작으므로 메모리에 모든 캐시를 포함할 수 있을 것입니다. 작업 집합의 크기는 캐시가 호스트하는 웹 사이트의 전체 캐시 가능 개체 양입니다. 디스크 및 메모리 캐시의 크기는 디스크 할당 조각화 및 캐시 새로 고침 정책을 고려하여 모든 캐시 가능 개체를 포함하도록 작업 집합 크기의 약 두 배가 되도록 설정하는 것이 좋습니다. 예를 들면, 작업 집합이 500MB일 경우 메모리 캐시 크기를 66%로 설정할 때 1,000MB의 디스크 캐시와 1,500MB의 메모리가 필요합니다.
대부분의 캐시 반입이 메모리 캐시에서 제공되므로 디스크 I/O 비율이 낮습니다. 또한 대부분의 경우 물리적 디스크 하나만으로도 충분하며 병목 현상이 발생하지 않습니다.
/3GB Boot.ini 스위치 사용
메모리가 2GB 이상인 대형 시스템의 경우, Windows Server 2003 및 Windows 2000 Advanced Server는 4GT RAM 조정 기능을 제공합니다. 이 기능은 프로세스 메모리 공간을 3GB와 1GB로 나누어 각각 응용 프로그램 메모리와 시스템 메모리에 할당하는 것입니다. 이 기능을 사용하면 프로세스가 사용자 공간에서 2GB 이상의 RAM을 사용할 수 있으며, 이 기능을 사용하려면 /3GB 스위치를 Boot.ini 파일에 추가하면 됩니다. 자세한 내용은 Microsoft 기술 자료에서 문서 Q171793, “응용 프로그램의 4GT RAM 조정 기능 사용에 대한 정보”를 참조하십시오.
이 기능은 ISA Server(특히 대규모 웹 사이트를 호스트하는 역방향 캐시용)에 유용할 수 있습니다. 그러나, 이 기능을 사용하면 최대 동시 TCP 연결 수를 의미하는 비페이징 풀의 최대 크기가 256MB가 아닌 128MB로 줄어듭니다.
웹 인증
웹 인증을 수행할 수 있는 방법에는 여러 가지가 있으며 방법마다 성능에 미치는 영향이 다릅니다. 다음 표는 각 방법의 장/단점을 요약한 것입니다.
| 인증 방법 | 강도 | 인증 수행 기준 | 요청당 오버헤드 | 일괄 처리당 오버헤드 |
|
기본 |
낮음 |
요청별 |
낮음 |
없음 |
|
다이제스트 |
중간 |
시간/개수별 |
없음 |
높음 |
|
NTLM |
중간 |
연결별 |
없음 |
높음 |
|
NTLMv2 |
높음 |
연결별 |
없음 |
높음 |
|
Kerberos |
높음 |
연결별 |
없음 |
중간 |
|
SecurID |
높음 |
브라우저 |
없음 |
보통 |
|
요청별 |
높음 |
요청별 |
높음 |
없음 |
|
세션별 |
중간 |
한 번만 |
없음 |
낮음 |
성능 관점에서 보면 인증 방법은 요청별 오버헤드가 없고 일괄 처리별 오버헤드가 낮을 때 최상의 수행 결과를 나타냅니다. 사용할 인증 방법은 강도와 인프라에 따라 결정됩니다.
또한, 웹 프록시 수신기 수준이나 규칙 수준에 대해 웹 프록시 인증을 구성할 수도 있습니다. 인증이 모든 웹 액세스에 필요한 경우에만 수신기 수준을 선택하십시오. 그렇지 않은 경우에는 규칙에 따라 필요할 때만 인증이 수행되는 규칙 수준을 선택하십시오.
웹 필터
응용 프로그램 필터와 마찬가지로, 웹 필터도 필터 기능에 따라 성능에 영향을 미칠 수 있습니다. ISA Server는 지정된 작업을 수행하는 몇 개의 웹 필터가 통합되어 있습니다. 이 중 CPU를 가장 많이 사용하는 필터는 HTTP 필터와 연결 변환 필터입니다.
HTTP 필터는 모든 일반 웹 요청 및 응답을 검사하여 일반 HTTP 프로토콜 용법과 맞는지 확인합니다. HTTP 필터는 기본적으로 사용되며 기본 구성은 HTTP 헤더 및 URL에 대한 크기 제한을 제공합니다. 기타 사용 가능한 기능에는 방법, 확장명, 헤더 및 HTTP 페이로드 서명에 따른 차단이 포함됩니다. 10%의 CPU 사이클이 추가로 필요한 서명 차단을 제외한 나머지 기능의 경우에는 선택해도 성능에 영향이 미치지 않습니다. 웹 트래픽을 보호하려는 경우 HTTP 필터를 사용하는 것이 좋습니다.
웹 게시 시나리오에서는 특별히 연결 변환이 사용됩니다. 연결 변환은 HTML 응답 본문에서 절대 하이퍼링크를 검색하여 ISA Server 컴퓨터를 가리키도록 변경합니다. 기본적으로 연결 변환은 HTTP 헤더만 검사하고 응답 본문을 검사하지 않으므로 성능에 큰 영향을 미치지 않습니다. 또한 본문 검사를 사용하는 경우 기본적으로 HTML 콘텐츠만 검사하므로 전체 CPU 사용량이 5%만 증가됩니다.
보안 웹 게시
SSL(Secure Sockets Layer)을 사용하면 ISA Server에서 웹 콘텐츠에 대한 보안 게시가 향상됩니다. SSL와 ISA Server를 함께 사용하면 게시된 웹 사이트에 대한 개인 접속을 수행할 수 있으며, 기업 사용자의 경우, 전자 메일, 공유 웹 사이트, 터미널 서비스 등 다양한 내부 네트워크 리소스에 보다 안전하게 액세스할 수 있습니다.
SSL은 포트 443을 사용하는 TCP 프로토콜입니다. SSL은 HTTP 콘텐츠에 대한 보안 래핑, 인증 및 암호화를 정의하므로 HTTPS(Secure HTTP)라고도 합니다.
성능 관점에서 SSL 암호화와 해독에는 일반 HTTP 처리 외에 추가 처리 계층이 필요합니다. 이 계층에는 CPU 사용이 많은 다음의 두 가지 주요 단계가 포함됩니다.
| • |
SSL 핸드셰이크 TCP 연결을 설정한 후 SSL은 PKI(공개 키 인프라)를 사용하여 끝점 사이에 보안 컨텍스트를 만듭니다. 이를 SSL 핸드셰이크라고 합니다. 전체 네트워크 트래픽 면에서 SSL 핸드셰이크는 연결 속도(초당 연결 수)에 비례하는 처리 성능을 사용합니다. |
| • |
암호화 보안 컨텍스트가 설정되고 나면 끝점에서는 보안 컨텍스트를 사용하여 대칭 암호화를 통해 HTTP 콘텐츠를 암호화하거나 해독합니다. 이 처리는 각각의 HTTP 데이터 바이트에 대해 수행됩니다. 따라서, 전체 네트워크 처리량(Mbps)에 비례하는 프로세서 주기가 사용됩니다. |
전체 처리량과 연결 속도의 비율은 각 연결에 대해 처리되는 평균 비트 수를 결정합니다. 이 비율은 연결당 비트 수로 정의되며 실제로는 모든 응용 프로그램마다 이 비율에 대한 특정 값이 지정되어 있습니다.
다음은 몇 가지 예입니다.
Outlook Web Access
Outlook Web Access Exchange Server 프런트 엔드 서버에 연결된 웹 클라이언트는 사서함에 현재 있는 메시지의 헤더와 사용자 인터페이스 아이콘을 포함하는 Outlook 웹 페이지를 로드합니다. 그리고 나서 사용자가 열기, 보내기 또는 폴더로 이동과 같은 작업을 수행하면 평균 10-20KB를 전송하는 새 HTTP 연결이 생성됩니다. 여러 사용자의 Outlook Web Access 작동을 종합해 볼 때 웹 클라이언트는 일반적으로 매우 작은 연결당 비트 수 값(연결당 100킬로비트)을 생성합니다.
Outlook 2003의 캐시된 Exchange 모드에서 RPC over HTTP 사용
RPC(원격 프로시저 호출) over HTTP는 Outlook 2003 클라이언트가 인터넷에서 기업 내부 네트워크에 있는 Exchange 서버에 액세스할 수 있도록 해 주는 Microsoft Exchange Server 2003의 기능입니다. Exchange Server에 연결하는 경우 캐시된 Exchange 모드에서 작동하는 Outlook 2003 클라이언트는 일반적으로 로컬 캐시 파일과 사서함 콘텐츠의 동기화부터 시작합니다. 동기화가 완료된 후에는 간헐적인 연결이 발생하고 이 연결을 통해 새 메시지가 전송됩니다. 자주 사용되는 프로필을 사용하는 지식 근로자의 경우, 동기화 작업은 적은 연결 수에서 많은 데이터 바이트를 전송하므로 전체적인 특정 연결당 비트 수 값은 연결당 500킬로비트에 이르는 등 오히려 높은 편입니다.
웹 사이트
웹 사이트를 디자인하고 구현하는 방법에는 여러 가지가 있습니다. 따라서 웹 사이트의 경우에는 일반적인 연결당 비트 수 값이 없습니다. 하지만 웹 사이트가 요청을 처리한 후 연결당 전체 비트 수를 측정할 수 있습니다. 실제로 웹 사이트는 중간 수준(연결당 100킬로비트 ~ 500킬로비트)의 연결당 비트 수 값을 나타냅니다.
SSL 브리징
보안 웹 게시를 사용하여 ISA Server를 배포하는 경우 외부 네트워크의 보안 웹 클라이언트는 SSL 포트에 연결할 수 있습니다. SSL 브리징은 ISA Server에서 게시된 백 엔드 웹 서버와 통신하는 방법을 지정할 수 있도록 해 주는 ISA Server의 기능입니다. 이 기능을 사용하면 다음 두 가지 유형의 브리징 중에서 선택할 수 있습니다.
| • |
SSL 간 브리징 이 브리징 유형에서는 ISA Server가 SSL을 사용하여 백 엔드 서버에 액세스합니다. ISA Server는 백 엔드 서버와 별도의 SSL 핸드셰이크를 수행하며 백 엔드 서버에서 받거나 백 엔드 서버로 보내는 모든 패킷에 대해 암호화를 사용해야 합니다. |
| • |
SSL과 HTTP 간 브리징 이 브리징 유형에서는 ISA Server가 암호화되지 않은 일반 HTTP에서 백 엔드 서버에 액세스합니다. |
SSL 간 브리징은 인터넷 네트워크 보안을 강화하지만 ISA Server와 백 엔드 서버 간에 전송되는 모든 패킷을 이중으로 암호화하기 때문에 처리 비용이 가중됩니다. SSL 간 브리징에는 SSL과 HTTP 간 브리징보다 약 20-30%의 비용이 더 듭니다.
SSL 용량 결정
최대 네트워크 트래픽 로드를 지원하기 위한 ISA Server 컴퓨터의 크기를 결정하려면 먼저 네트워크 트래픽의 일반적인 연결당 킬로비트를 측정하고 나서 전체 트래픽을 측정해야 합니다. 다음 절차에 따라 결정하십시오.
|
1. |
시스템 성능 모니터 도구를 사용하여 서버 작업이 가장 많은 두 시간 동안 각 응용 프로그램 서버의 네트워크 트래픽을 모니터링합니다. 또한 다음 카운터를 수집합니다.
| ||||||||||||||||||||
|
2. |
연결당 총 평균 킬로비트를 각 응용 프로그램 서버의 가중치가 적용된 연결당 평균 킬로비트로 계산합니다. 각 서버의 가중치는 해당 서버의 처리량을 모든 서버의 전체 처리량으로 나눈 값입니다. | ||||||||||||||||||||
|
3. |
각 서버에 대해 측정되는 트래픽을 더하여 전체 트래픽을 계산합니다. | ||||||||||||||||||||
|
4. |
다음 표를 사용하여 2단계에서 측정한 연결당 킬로비트에 따라 ISA Server에서 처리하는 SSL 트래픽 각 비트에 필요한 메가사이클 수를 계산합니다.
| ||||||||||||||||||||
|
5. |
4단계의 표에 나와 있는 메가비트당 메가사이클에 3단계에 계산한 전체 처리량을 곱하여 전체 트래픽을 지원하는 데 필요한 프로세서 속도를 계산합니다. 참고 |
예를 들어, 2단계에서 계산한 연결당 킬로비트가 200이고 총 처리량이 15메가비트이며 ISA Server에서 SSL 간 브리징을 수행해야 한다고 가정해 보겠습니다. 앞의 표에서 단일 프로세서는 메가비트당 96 메가사이클을 필요로 하거나
15Mbps에 대해 96 × 15 = 1440메가사이클을 필요로 합니다. 2.4GHz에서 실행되는 단일 Intel Pentium 4 프로세서면 충분히 이 로드를 처리할 수 있으며 처리량이 최대일 때 1440/2400 = 60%를 사용합니다. 두 개의 Intel 2.4GHz Pentium 4 프로세서가 장착된 듀얼 프로세서 컴퓨터의 경우에는 메가비트당 120메가사이클이 필요하거나 15Mbps에 대해 120 × 15 = 1800메가사이클이 필요하며 처리량이 최대일 때 1800 / (2 × 2400) = 38%를 사용합니다.
다음 표는 최대 권장 사용률(80%)에서 2.4GHz 프로세서가 처리할 수 있는 트래픽 양(메가비트)을 보여 줍니다.
| 연결당 킬로비트 | 100 | 200 | 500 |
|
프로세서 1개, SSL과 HTTP 간 |
21 |
25 |
28 |
|
프로세서 1개, SSL 간 |
16 |
20 |
23 |
|
프로세서 2개, SSL과 HTTP 간 |
30 |
37 |
42 |
|
프로세서 2개, SSL 간 |
27 |
32 |
37 |
이 표는 특별히 ISA Server가 SSL 트래픽에만 사용되는 배포용으로 제공됩니다. SSL과 암호화되지 않은 HTTP 트래픽에 대해 모두 ISA Server를 배포하려는 경우에는 다음 표에서처럼 각 시나리오에 대한 트래픽 양에 메가비트당 메가사이클을 곱한 값에 따라 가중치가 적용된 평균 메가사이클을 계산하여 필요한 처리 성능을 예상할 수 있습니다.
| 시나리오 | 투명 프록시 | 정방향 프록시 | SSL 터널링 |
|
프로세서 1개 |
74 |
37 |
30 |
|
프로세서 2개 |
86 |
43 |
35 |
예를 들어, 초당 20메가비트의 최대 트래픽 중 40%가 투명 프록시이고, 35%가 정방향 프록시이며, 25%가 연결당 200킬로비트인 SSL 간 브리징인 최 전방 방화벽 시나리오에 ISA Server를 배포하려 한다고 가정해 보겠습니다. 단일 프로세서 컴퓨터의 ISA Server에서 이 트래픽을 처리하는 데 필요한 총 메가사이클 양은 다음과 같습니다.
메가사이클 = 20Mbps × (74 × 40% + 37 × 35% + 96 × 25%) = 1331
2.4GHz Intel Pentium 4 프로세서 하나면 이 로드를 충분히 처리할 수 있으며
처리량이 최대일 때 1331 / 2400 = 55%를 사용합니다. 듀얼 프로세서 컴퓨터의 경우에는
20 × (86 × 40% + 43 × 35% + 120 × 25%) = 1589메가사이클이 필요하며,
처리량이 최대일 때 두 개의 2.4GHz Intel Pentium 4 프로세서의 1589 / (2400 × 2) = 33%를 사용합니다.
상태 저장 필터링
상태 저장 필터링은 전송 수준에서 데이터를 검사하며 ISA Server 방화벽 패킷 엔진 커널 모드 드라이버에서 구현됩니다. 상태 저장 필터링은 소스 및 대상 IP 주소, TCP/UDP 플래그 포트 번호, ICMP(Internet Control Message Protocol) 형식 및 코드를 평가합니다. 상태 저장 필터링은 이 정보를 사용하여 연결 상태를 확인하며 이 상태에 맞는 패킷을 허용하고 이 상태에 맞지 않는 패킷을 거부합니다.
응용 프로그램 수준 필터링에 비해 상태 저장 필터링에는 매우 작은 양의 리소스만 필요합니다. 같은 양의 HTTP 트래픽에 대해 웹 프록시 필터링을 적용할 경우 CPU 처리 성능의 75%가 사용되지만 상태 저장 필터링을 적용하면 CPU 처리 성능의 8%만 사용됩니다. 즉, 성능이 10배 가량 향상되는 것입니다.
VPN
VPN(Virtual Private Network)은 원격 액세스 VPN과 사이트 간 VPN이라는 두 가지 기본 시나리오로 이루어집니다. 두 가지 시나리오 모두 몇 개의 프로토콜을 사용하며 응용 프로그램 필터링이나 상태 저장 필터링과 함께 사용됩니다. IPsec(Internet Protocol security) 기반 프로토콜은 많은 네트워크 어댑터에서 사용할 수 있는 하드웨어 오프로드 기능을 사용하여 전체적인 프로토콜 사용률을 향상시킬 수도 있습니다. 일부 프로토콜은 처리량 향상 또는 대역폭 절감을 위해 압축 시 사용할 수 있습니다. 이러한 모든 기능은 다음 섹션에서 설명하는 바와 같이 성능에 영향을 미칩니다.
원격 액세스 VPN
인터넷에서의 원격 클라이언트 전화 접속은 VPN 원격 접속을 사용하여 기업 네트워크에 액세스합니다. 원격 액세스에 사용되는 프로토콜은 IPsec(Internet Protocol security)을 통한 계층 2 터널링 프로토콜(L2TP) 및 지점간 터널링 프로토콜(PPTP)입니다. 이 두 가지 프로토콜 모두 압축을 지원하며, 암호화에 필요한 처리 성능과 대역폭의 절감을 위해 압축을 사용하는 것이 좋습니다.
ISA Server VPN 서버에 적절한 용량을 결정하려면 먼저 ISA Server 컴퓨터에서 지원해야 하는 최대 동시 원격 연결 수를 평가해야 합니다. 예를 들어, 회사의 직원 중 5% 이하만 원격 연결을 동시에 설정할 수 있도록 하며 회사의 직원 수가 5,000명인 경우 250명의 동시 VPN 원격 액세스 연결 수가 필요한 용량입니다.
다음 표는 각 하드웨어 플랫폼에서 지원하는 최대 동시 VPN 원격 액세스 연결 수를 나타냅니다. 이 수치는 IPsec 프로토콜을 통한 L2TP와 PPTP 모두에 대해 웹 프록시 필터링, MSDE 로깅 및 압축이 통합된 즉시 사용할 수 있는 ISA Server 설정을 전제로 합니다.
| 프로토콜 | 연결 수 및 대역폭 | 단일 Pentium III 550MHz 프로세서 | 단일 Pentium 43GHz 프로세서 | 듀얼 Xeon 3GHz 프로세서 |
|
PPTP |
연결 수 |
150 |
600 |
760 |
|
대역폭 |
2.25Mbps |
9Mbps |
11.4Mbps | |
|
IPsec을 통한 L2TP |
연결 수 |
150 |
700 |
850 |
|
대역폭 |
2.25Mbps |
10.5Mbps |
12.75Mbps |
다음은 위의 표에 적용됩니다.
| • |
대역폭 수치는 필요한 인터넷 링크 대역폭을 말합니다. 압축되어 있기 때문에 실제 대역폭은 위 표에 표시된 양의 두 배입니다. |
| • |
대역폭 수치는 56KB 전화 접속 연결에 맞먹는 30Kbps의 평균 처리량을 전제로 합니다. |
VPN 클라이언트에 대한 신뢰도가 보다 높은 배포에서는 응용 프로그램 수준 필터링이 사용되지 않아 전체 용량이 향상되는 대신에 보안 수준이 낮아질 수도 있습니다. 다음 표는 웹 프록시 필터를 사용하지 않는 경우의 수치를 보여 줍니다.
| 프로토콜 | 연결 수 및 대역폭 | Pentium 3, 550MHz | Pentium 4, 3GHz, Standard Edition | 듀얼 Pentium 4, 3GHz, Enterprise Edition |
|
PPTP |
연결 수 |
375 |
1,000 |
2,500 |
|
대역폭 |
5.6Mbps |
15Mbps |
38Mbps | |
|
IPsec을 통한 L2TP |
연결 수 |
330 |
1,000 |
2,320 |
|
대역폭 |
5Mbps |
15Mbps |
35Mbps |
다음은 위의 표에 적용됩니다.
| • |
ISA Server 2004 Standard Edition에서 단일 Pentium 4 3GHz 프로세서의 최대 동시 연결 수는 1000입니다. ISA Server 2004 Enterprise Edition에는 이러한 제한이 없습니다. |
| • |
많은 네트워크 인터페이스 어댑터에서 사용할 수 있는 IPsec 오프로드 하드웨어는 처리량 값을 20% ~ 25% 증가시킬 수 있습니다. |
사이트 간 VPN
사이트 간 VPN에서는 성능 및 용량 관점에서 두 가지 주요 옵션 중 하나를 선택할 수 있습니다. 하나는 IPsec을 통한 L2TP 또는 PPTP를 사용하는 것입니다. 이러한 프로로토콜은 사이트 간 연결을 통해 전송할 수 있는 처리량을 두 배로 증가시키는 응용 프로그램 트래픽 압축을 제공합니다. 예를 들어, PPTP 또는 L2TP 터널을 통해 2MB 파일을 전송할 경우 실제로는 1MB만 전달됩니다. 또 하나는 압축이 통합되지 않는 IPsec 터널링을 사용하는 것입니다. IPsec 터널링과 비교할 때 IPsec을 통한 L2TP와 PPTP는 사이트 간 처리량을 50% 절감합니다.
웹 프록시 필터링을 사용하지 않는 경우 IPsec을 통한 L2TP에서는 15Mbps 응용 프로그램 트래픽에 대해 하나의 Pentium III 550MHz 프로세서가 필요합니다. 이 트래픽을 한 방향으로 전달하는 데는 트래픽이 압축되기 때문에 7.5Mbps 연결 용량만 필요합니다. 하나의 Pentium 4 3GHz 프로세서에서 T3 연결 용량(45Mbps)을 필요로 하는 최대 90Mbps의 응용 프로그램 트래픽을 처리할 수 있습니다. 웹 프록시 필터링을 사용하는 경우 하나의 Pentium III 550MHz 프로세서에서는 3.5Mbps 인터넷 연결 대역폭을 필요로 하는 7Mbps 응용 프로그램 트래픽을 처리할 수 있으며, 하나의 Pentium 4 3GHz 프로세서에서는 17Mbps 인터넷 대역폭에 해당하는 34Mbps 응용 프로그램 트래픽을 처리합니다. 듀얼 Xeon 3-GHz 프로세서는 26.5Mbps 인터넷 연결 대역폭을 필요로 하는 53Mbps 응용 프로그램 트래픽을 처리할 수 있습니다. PPTP는 동일한 CPU 사용량에 대해 처리량의 약 15-20%를 더 처리할 수 있습니다.
두 번째 옵션은 압축을 지원하지 않는 IPsec 터널링을 사용하는 것입니다. 이 경우에는 인터넷 연결 트래픽이 응용 프로그램 트래픽과 같습니다. 웹 프록시 필터를 사용하지 않고 상태 저장 필터링과 함께 사용하는 경우 IPsec 터널링은 단일 Pentium III 550MHz 프로세서에서 10Mbps를 처리할 수 있으며 단일 Pentium 4 3GHz 프로세서에서 52Mbps를 처리할 수 있습니다. 웹 프록시 필터링을 사용하는 경우에는 처리량 수치가 단일 Pentium 3, 단일 Pentium 4 및 듀얼 Xeon 플랫폼에서 각각 4Mbps, 18Mbps 및 30Mbps입니다.
다음 표는 이러한 결과로서 75% CPU 사용률에서 지원되는 실제 Mbps를 요약한 것입니다. 괄호 안에 있는 값은 압축되지 않은 트래픽 볼륨을 나타냅니다.
| 사이트 간 VPN 방법 | 필터링 | Pentium 3, 550MHz | Pentium 4, 3GHz | 듀얼 Pentium 4, 3GHz |
|
IPsec을 통한 L2TP(압축됨) |
사용 안 함 |
7.5(15) |
45(90) |
71(142) |
|
사용 |
3.5(7) |
17(34) |
27(53) | |
|
IPsec을 통한 PPTP(압축됨) |
사용 안 함 |
8.5(17) |
52(104) |
81(162) |
|
사용 |
4(8) |
20(39) |
31(61) | |
|
IPsec 터널링 |
사용 안 함 |
10 |
52 |
87 |
|
사용 |
4 |
18 |
30 |
많은 네트워크 인터페이스 어댑터에서 사용할 수 있는 IPsec 오프로드 하드웨어는 처리량 값을 20% ~ 25% 증가시킬 수 있습니다.
ISA Server 확장
ISA Server 시스템을 확장하는 방법에는 몇 가지가 있습니다.
| • |
고급 네트워크 전환 하드웨어 도구 사용 이러한 스위치는 서로 다른 네트워크 계층에서 사용할 수 있는 다양한 정보에 따라 전환 기능을 제공하므로 흔히 L3, L4 또는 L7 스위치(계층 3, 계층 4 또는 계층 7)라고도 합니다. L3 전환은 패킷 계층 정보(IP)에 기반을 두고 있으며, L4는 전송 계층 정보(TCP)를 기반으로 하고, L7은 응용 프로그램 데이터(HTTP 헤더)를 기반으로 하여 전환을 수행합니다. 이러한 수준에서 사용할 수 있는 정보는 IP 소스 또는 대상 주소, TCP 소스 또는 대상 포트, URL 및 콘텐츠 유형에 따라 정교한 로그 균형 조정을 제공할 수 있습니다. 이 스위치는 하드웨어 장치로 구현되기 때문에 높은 처리량을 제공하며 가용성과 신뢰성이 높은 반면 가격이 비쌉니다. 대부분의 스위치는 서버의 다운 상태를 감지하여 내결함성을 제공할 수 있습니다. |
| • |
DNS 라운드 로빈 이름 확인 사용 DNS(Domain Name System)에서 서버 클러스터에 동일한 이름을 할당할 수 있습니다. DNS는 목록의 항목을 차례대로 살펴보며 해당 이름에 대한 쿼리에 응답합니다. 이 방법은 비용이 들지 않는 저렴한 솔루션이지만 단점이 있습니다. 한 가지 문제는 로드가 클러스터 내 서버 사이에 고르게 분산되지 않는다는 점입니다. 또 다른 문제는 내결함성을 제공하지 않는다는 점입니다. |
| • |
Windows 네트워크 로드 균형 조정 사용 네트워크 로드 균형 조정(NLB)은 클러스터 내의 모든 서버와 IP 주소를 공유함으로써 수행되기 때문에 IP 주소로 전송된 모든 데이터를 모든 서버에서 볼 수 있습니다. 그러나 각 패킷은 특정 공유 해시 함수에 따라 하나의 서버에서만 처리됩니다. NLB는 운영 체제 수준에서 구현되며, 고르게 분산된 로드 균형 조정을 제공하고 내결함성을 지원합니다. 클러스터 내의 다른 서버는 작동하지 않는 서버를 찾아내서 서버 서로 간에 로드를 분산시킬 수 있습니다. 그러나 CPU 처리 오버헤드(일반 ISA Server 시나리오의 경우 약 10-15%)가 들고 클러스터 내의 구성원 수에 제한(권장 최대 구성원 수는 대략 컴퓨터 8대)이 있습니다. NLB 배포 방법에 대한 자세한 내용은 the ISA Server 2004 Enterprise Edition Network Load Balancing Guide (영문)(http://www.microsoft.com)를 참조하십시오. |
| • |
Cache Array Routing Protocol 사용 캐시 시나리오의 경우, ISA Server에서 이 프로토콜은 캐시 로드 균형 조정 프로토콜인 CARP(Cache Array Routing Protocol)를 지원합니다. 이 시나리오에서는 서버 간에 로드만 배포하는 것이 아니라 캐시된 콘텐츠도 배포합니다. 각 요청이 클러스터의 특정 컴퓨터로 전송되므로 후속 적중이 해당 컴퓨터에서 처리됩니다. |
ISA Server가 톡화하는 각 스트림에 대한 상태를 유지하기 때문에 모든 확장 방법은 모든 데이터가 ISA Server 컴퓨터를 통과하도록 고정성을 지원해야 합니다.
확장은 시스템 용량을 증가시키는 데 사용됩니다. 각 확장 방법마다 장점과 단점이 있으며 ISA Server의 경우 시나리오에 따라서도 달라집니다. 사용할 확장 방법을 결정할 때 다음 사항을 고려하십시오.
| • |
성능 인수 배열의 컴퓨터 수를 두 배로 하는 경우 추가되는 처리량의 증가 인수 |
| • |
시스템 비용 시스템 소유 비용이 아니라 시스템 초기 구입 비용 |
| • |
시스템 관리 시스템 관리 복잡성 수준. 이 항목은 시스템 소유 비용에 직접적인 영향을 미칩니다. |
| • |
내결함성 높은 가용성과 신뢰성을 제공하기 위해 시스템에서 사용하는 방법 |
| • |
시스템 증가 시스템의 처리 성능을 증가시키는 데 사용되는 방법. 업그레이드 비용도 중요한 고려 사항입니다. |
다음은 확장을 결정할 때 상호 간에 적절한 균형을 유지해야 할 몇 가지 항목입니다.
| • |
단일 실패점과 내결함성 단일 컴퓨터 배포의 가용성은 다중 컴퓨터 클러스터보다 하드웨어 장애에 더 취약합니다. 시스템 보드 또는 디스크 컨트롤러가 고장 나면 전체 시스템이 작동하지 않게 되어 수리해야 합니다. 이는 오류가 발생한 하드웨어 로드 균형 조정 기능에도 적용됩니다. |
| • |
증가 하나의 프로세서에서 두 개 프로세서로 단일 컴퓨터 솔루션을 업그레이드하려면 컴퓨터에 빈 프로세서 슬롯 또는 하드웨어 로드 균형 조정 스위치에 사용 가능한 포트가 있어야 합니다. 다중 컴퓨터 클러스터에서 다른 컴퓨터를 추가하는 일은 좀 더 복잡합니다. |
다음 표는 확장 방법을 요약한 것입니다.
| 기능 | 하드웨어 스위치 | Windows NLB | DNS 라운드 로빈 | CARP |
|
배율 |
2 |
웹 트래픽의 경우에는 1.75, SSL 및 VPN 원격 액세스의 경우에는 1.9 |
2 |
1.5에서 시작하여 점진적으로 2에 접근 |
|
시스템 비용 |
높음 |
추가 비용 없음 |
추가 비용 없음 |
추가 비용 없음 |
|
내결함성 |
스위치에 따라(대체로 작동하지 않는 컴퓨터를 찾아내고 다른 컴퓨터를 로드함) |
작동하지 않는 컴퓨터에 대한 상호 검색을 통해 |
없음 |
작동하지 않는 컴퓨터의 상호 검색을 통해 |
|
시나리오 |
모두 |
모두 |
모두 |
정방향 캐시만 |
다음은 위의 표에 적용됩니다.
| • |
NLB를 사용하는 경우에는 15%의 성능 오버헤드가 추가됩니다. 구성원이 하나인 NLB 배열은 NLB를 사용하지 않는 같은 배열보다 15% 덜 사용됩니다. 따라서, NLB 확장 사용 관련 용량을 추정하는 경우 먼저 단일 컴퓨터의 처리량 값을 약 15% 낮추고 나서 배율을 적용해야 합니다. |
| • |
웹 트래픽에 대한 NLB 배율에서는 배열에 두 개 이상의 NLB 클러스터를 구성할 때 양방향 선호도 구성이라고 가정합니다. 대부분의 경우 단일 선호도면 웹 트래픽에 충분하며, 이 경우 배율은 1.9입니다. |
| • |
NLB와 사이트 간 VPN을 사용하는 경우에는 몇 개의 배열 구성원에 대해 두 사이트를 연결하는 몇 개 터널의 로드 균형을 조정할 수 없습니다. 이 경우에는 NLB에서 내결함성만 제공합니다. NLB 배열의 사이트 하나를 여러 사이트에 연결하는 경우 ISA Server는 모든 배열 구성원 간에 터널을 분산시킵니다. |
구성 저장소 서버 크기 조정
구성 저장소 서버 구성 요소는 ISA Server 2004 Enterprise Edition에 추가된 서버 구성 요소 중 하나입니다. 구성 저장소 서버는 엔터프라이즈의 각 ISA Server에 대한 구성이며 엔터프라이즈 레이아웃 리포지토리입니다. 이 리포지토리는 ADAM(Active Directory Application Mode)의 인스턴스입니다. 각 ISA Server 컴퓨터는 서버의 구성 복제본인 구성의 논리적 복사본을 가지고 있는데, 이 복사본은 구성 저장소 서버에 있습니다.
단일 구성 저장소 서버에 연결할 수 있는 권장 ISA Server 컴퓨터 수는 40이며 최대 권장 수는 60입니다. 이 값은 약 6MB의 XML(Extensible Markup Language) 파일로 된 수천 가지 정책 개체 참조와 수백 가지 규칙을 포함하는 대규모 확장 정책을 가져옴으로써 구성 저장소 서버에서 리소스 사용이 가장 많은 작업의 성능 측정치에서 추정한 것입니다. 이 시나리오에서 구성 저장소 서버는 XML 파일을 가져오며 새 구성은 만듭니다. 구성 저장소 서버가 새 구성 데이터를 디스크에 쓰자 마자 연결된 모든 ISA Server 컴퓨터가 동시에 이 구성을 페치하기 시작하므로 구성 저장소 서버에 상당한 CPU, 네트워크 및 디스크 I/O 로드가 발생하게 됩니다. 구성 저장소 서버의 실제 메모리가 512MB인 듀얼 2.0GHz Intel Pentium 4 프로세서를 사용하는 경우 구성 저장소 서버는 초당 2,600개 수준의 LDAP(Lightweight Directory Access Protocol) 요청을 받을 수 있습니다. 대규모 확장 정책 가져오기 작업과의 완전 동기화에 필요한 ISA Server 컴퓨터별 총 LDAP 요청 수는 7,000입니다. 이 수치는 다음 공식에 따라 구성 저장소 서버에서 대규모 확장 정책 XML 파일을 가져온 후 모든 ISA Server 컴퓨터의 완전 동기화에 필요한 시간으로 변환됩니다.
총 가져오기 시간 = XML 가져오기에 소요되는 시간 + 구성을 디스크에 쓰는 데 소요되는 시간 + 모든 ISA Server 컴퓨터에 의한 구성 동기화에 소요되는 시간
여기서,
XML 가져오기에 소요되는 시간 = 120초
구성을 디스크에 쓰는 데 소요되는 시간 = 120초
N대의 ISA Server 컴퓨터에 의한 구성 동기화에 소요되는 시간 = N × 7000 / 2600 = 2.7 × N초
다음 표는 이러한 결과를 요약한 것입니다.
|
구성 저장소 서버당 ISA Server 컴퓨터 수 |
20 |
40 |
60 |
|
총 가져오기 시간 |
300초 |
350초 |
400초 |
|
동기화에 소요되는 시간 |
60초 |
110초 |
160초 |
|
동기화 중 CPU 사용률(%) |
90% |
90% |
92% |
처음 두 단계(XML 가져오기와 디스크에 구성 쓰기)의 경우 CPU 사용률 수준은 약 50%입니다. 그 이유는 이 작업이 듀얼 프로세서 컴퓨터의 처리 성능 중 50% 이상을 사용할 수 없는 단일 스레드에서 수행되기 때문입니다. 단일 프로세서 컴퓨터의 경우 CPU 사용량이 이러한 단계에서 100%에 이르며, 이러한 상황이 발생하지 않도록 해야 합니다. 따라서, 구성 저장소 서버의 경우 듀얼 프로세서 컴퓨터를 배포하거나 단일 프로세서 컴퓨터에서 하이퍼 스레딩을 사용하는 것이 좋습니다.
ISA Server 구성 저장소 서버에 대한 자세한 내용은 ISA Server 2004 Enterprise Edition Deployment Guidelines (영문)(http://www.microsoft.com)를 참조하십시오.
크기 조정 참조 및 예
이 섹션에서는 ISA Server 2004 Standard Edition 및 Enterprise Edition 크기 조정에 대한 중앙 참조 및 요약을 제공합니다. 첫 번째 표는 웹 프록시, SSL, VPN 및 상태 저장 필터링 시나리오에 대한 메가비트당 메가사이클을 제공합니다.
| 시나리오 | 단일 Pentium 4 | 듀얼 Xeon | ||
|
투명 웹 프록시 |
74 |
86 | ||
|
정방향 웹 프록시 |
37 |
43 | ||
|
상태 저장 필터링 |
8 |
10 | ||
|
SSL |
SSL과 HTTP 간 |
Outlook Web Access |
91 |
128 |
|
웹 |
77 |
104 | ||
|
RPC over HTTP |
69 |
91 | ||
|
SSL 간 |
Outlook Web Access |
120 |
142 | |
|
웹 |
96 |
120 | ||
|
RPC over HTTP |
83 |
104 | ||
|
SSL 터널링 |
30 |
35 | ||
|
VPN 원격 액세스 |
웹 필터 사용 |
IPsec을 통한 L2TP |
214(107) |
353(177) |
|
PPTP |
250(125) |
395(198) | ||
|
웹 필터 사용 안 함 |
IPsec을 통한 L2TP |
80(40) |
128(64) | |
|
PPTP |
75(38) |
118(59) | ||
|
VPN |
웹 필터 사용 |
IPsec을 통한 L2TP |
132(66) |
167(84) |
|
PPTP |
113(57) |
145 (73) | ||
|
IPsec 터널링 |
125 |
150 | ||
|
웹 필터 사용 |
IPsec을 통한 L2TP |
50(25) |
63(32) | |
|
PPTP |
43(22) |
56(28) | ||
|
IPsec 터널링 |
43 |
52 |
다음은 위의 표에 적용됩니다.
| • |
웹 게시의 경우, 정방향 웹 프록시에 제공된 값을 사용하지만, 실제 로드 및 용량은 예상값과 크게 다를 수도 있습니다. |
| • |
VPN의 경우에는 적용할 수 있는 값이 두 가지입니다. 첫 번째 값 집합은 실제 압축된 메가비트당 메가사이클을 나타냅니다. 괄호 안에 지정된 두 번째 값 집합은 압축되지 않은 응용 프로그램 메가비트당 메가사이클을 나타냅니다. 유선 대역폭에서 트래픽을 측정하는 경우에는 압축된 트래픽의 값을 사용하고, 압축되지 않은 응용 프로그램을 추정하거나 더 쉽게 측정할 수 있는 경우에는 응용 프로그램 트래픽에 압축되지 않은 트래픽의 값을 사용하십시오. |
위 표의 값은 다음을 전제로 합니다.
| • |
MSDE 로깅을 사용합니다. |
| • |
웹 인증이 수행되지 않습니다. |
| • |
기본 설정이 적용된 HTTP 웹 필터를 사용합니다. |
| • |
ISA Server에 특정 웹 트래픽이 로드됩니다. |
| • |
ISA Server 하드웨어가 이 문서의 CPU 사용률을 극대화하기 위한 하드웨어 조정에서 설명한 대로 조정되어 있습니다. |
다음 표는 증가된 용량에 대해 NLB 확장을 적용할 때 사용할 NLB 배율을 제공합니다.
| NLB 배열 구성원 수 | |||||||
|
배율 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
1.9 |
1.053 |
1.085 |
1.108 |
1.126 |
1.142 |
1.155 |
1.166 |
|
1.75 |
1.143 |
1.236 |
1.306 |
1.363 |
1.412 |
1.455 |
1.493 |
다음은 위의 표에 적용됩니다.
| • |
처음에 적용되는 15% 추가는 NLB를 적용할 때 첫 번째 표의 모든 값에 대해 적용해야 합니다. |
| • |
양방향 선호도를 사용하는 경우와 같이 배열에 대해 두 개 이상의 NLB 클러스터를 구성할 때와 웹 프록시 시나리오(투명 프록시, 정방향 프록시, 웹 게시 및 SSL 터널링) 및 상태 저장 필터링에만 배율 1.75를 사용합니다. 그 밖의 경우에는 배율 1.9를 사용합니다. |
다음 예는 위의 표를 사용하여 특정 트래픽 요구 사항을 지원하는 데 필요한 하드웨어를 평가하는 방법을 보여 줍니다.
대규모 사이트의 경우에는 최대 사용 시간에 80Mbps의 인터넷 연결 대여폭이 최대로 사용된다고 가정합니다. 이 시간 동안에는 원격 VPN 액세스(웹 필터과 IPsec을 통한 L2TP 사용)에 유선 트래픽의 10%가 사용되며 Outlook Web Access에 20%(SSL과 HTTP 간 브리징)이 사용되고 70%는 아웃바운드 웹 검색(50%는 투명 프록시에, 50%는 정방향 프록시에 사용)에 사용됩니다. 로드 균형 조정 없이 단일 듀얼 Xeon 컴퓨터 배포를 사용한다고 가정할 때, 이 트래픽에 필요한 메가사이클을 계산하려면 먼저 메가비트당 가중치가 적용된 메가사이클을 계산합니다.
메가사이클/메가비트 = 353 × 10% + 128 × 20% + 86 × 35% + 43 × 35% = 107
80Bps에 필요한 초당 총 메가사이클 수는 80 × 107 = 8560입니다.
하나의 듀얼 프로세서 3GHz 컴퓨터는 75% 사용 시 2 × 3000 × 75% = 4500메가사이클만을 제공하므로 충분하지 않습니다. 따라서 컴퓨터를 더 추가하여 확장해야 합니다. 이 때 정확히 얼마나 필요한지는 명확히 알 수 없지만 아마도 두 대나 세 대가 필요할 것입니다. 배율이 적용된 메가비트당 필요한 메가사이클 수을 계산하려면 각 트래픽 유형에 대해 메가비트당 메가사이클 수에 해당 배율을 곱합니다. 이 때 +15%를 반드시 적용해야 합니다. 배열의 두 구성원의 경우 웹 트래픽(브로드캐스트 드라이버 아키텍처라고 가정할 때)에 1.143을 사용하고 VPN 및 SSL 트래픽에는 1.053을 사용하며 결과는 다음과 같습니다.
구성원이 두 개인 배열이라고 가정할 때 배율이 적용된 메가사이클/메가비트는 다음과 같습니다.
115% × (353 × 10% × 1.053 +
128 × 20% × 1.053 +
86 × 35% × 1.143 +
49 × 35% × 1.143) = 133
따라서 필요한 초당 총 메가사이클 수는 80 × 133 = 10640입니다. 이 값은 처리해야 할 구성원이 둘인 경우에는 너무 큽니다. 듀얼 프로세서 3GHz 컴퓨터 두 개는 초당 2 × 4500 = 9000메가사이클만 지원합니다. 컴퓨터가 세 대면 아마도 이 로드를 지원하기에 충분한 처리 성능을 제공할 것입니다. 계산 결과는 다음과 같습니다.
구성원이 세 개인 배열이라고 가정할 때 배율이 적용된 메가사이클/메가비트 =
115% × (353 × 10% × 1.085 +
128 × 20% × 1.085 +
86 × 35% × 1.236 +
49 × 35% × 1.236) = 140
따라서 필요한 초당 총 메가사이클 수는 80 × 140 = 11200입니다. 듀얼 프로세서 3GHz 컴퓨터 세 대는 75%의 프로세서 사용률에서 초당 13500메가사이클을 제공합니다. 이 정도면 이 로드를 지원하기에 충분하며 어느 정도의 확장 공간도 제공합니다.
추가 정보
추가 정보는 다음을 참조하십시오.
| • |
Bandwidth Needs of Enterprises, SMBs and Teleworkers Through 2006, Gartner Report R-18-3617, September 30, 2002 |
| • |
ISA Server 2004 Enterprise Edition Deployment Guide (영문), (http://www.microsoft.com) |
| • |
ISA Server 2004 Enterprise Edition Network Load Balancing (영문), (http://www.microsoft.com) |
이 문서에 대한 의견이 있으시면 이 주소로 보내 주십시오.
원문URL:
http://www.microsoft.com/korea/technet/prodtechnol/isa/2004/plan/bestpractices.mspx