|
출처:
=================================================
Windows Media Technologies에 대한 유용한 정보
운영 체제
백서
요약
이 백서에서는 Microsoft Windows Media Technologies 구현을 위한 유용한 정보를 설명합니다. 프로토콜, 인코더 구성과 기술, 서버 구성과 조정, 멀티캐스트 배포 사용 및 로깅을 설명합니다.
 Microsoft Windows Media Technologies는 Windows 2000 운영 체제의 일부로서 배포됩니다. 이로서 스트리밍 미디어 파일을 작성, 배포 및 재생할 수 있습니다. IT 전문가의 경우 Windows 2000 Professional과 Windows 2000 Server를 모두 최적의 성능으로 구성하는 방법과 네트워크를 통해 파일을 배포하는 방법을 이해해야 합니다.
그림 1은 스트리밍 미디어 전송에 사용되는 구성 요소를 나타낸 것입니다.
그림 1 Windows Media Technologies 전송 구성 요소
이 백서는 네트워크를 통한 스트리밍 미디어의 인코딩, 서비스 제공 및 전송에 대한 구성 요소를 설명하며 다음과 같은 내용을 다룹니다. 다음과 같은 정보가 포함되어 있습니다.
이 백서에서는 독자가 기본적으로 WMT와 네트워킹 프로토콜을 알고 있다고 가정합니다.
> Windows Media Technologies는 Windows Media Server(MMS)라고 하는 응용 프로그램 수준의 프로토콜을 사용하여 인터넷과 인트라넷을 통해 ASF(Active Streaming Format) 파일을 전송합니다. 스트리밍 ASF 파일을 가리키는 URL에는 다음 예에서 볼 수 있는 것처럼 프로토콜로 사용하는 MMS가 포함됩니다.
mms://servername/filename.asf
MMS 프로토콜은 자동으로 다음과 같은 순서로 스트리밍 미디어를 위한 최적의 전송을 찾습니다.
UDP 프로토콜은 배달을 보장하지 않기 때문에 실시간 미디어에 이상적인, 연결 없는 전송 계층 프로토콜입니다. 이 표현이 장점이라기보다는 단점으로 들릴지 모르지만 스트리밍 미디어에는 특히 적합한 특성입니다. 전송 시간에 관계 없이 전체 내용이 배달되어야 하는 파일이나 전자 메일과 같은 데이터와 달리 스트리밍 미디어 데이터의 값은 시간의 제약을 받습니다. 비디오 프레임이 손실되면 정확한 시간 프레임 내에 도달하지 않으므로 쓸모가 없는 데이터가 됩니다. 이 데이터를 다시 전송한다는 것은 대역폭을 낭비하는 것입니다. 전송 프로토콜로 UDP만 사용하도록 지정할 수 있습니다. 이렇게 하려면 다음과 같은 구문을 사용하십시오.
mmsu://servername/filename.asf
UDP의 단점은 회사 방화벽을 통과하지 못할 수 있다는 것입니다. UDP를 통해 스트리밍 ASF 파일을 받아 들이도록 방화벽을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
MS DTC 방화벽 문제 해결
다음 선택인 TCP는 가장 많이 사용되는 인터넷 전송 프로토콜입니다. 데이터를 다시 전송하려 한다는 것과 이 프로토콜 역시 회사의 방화벽을 통과하지 못할 수 있다는 것이 TCP의 단점입니다. TCP와 방화벽에 대한 자세한 내용은 앞에서 설명한 기사를 참조하십시오. 전송 프로토콜로 TCP만 사용하도록 지정하는 구문은 mmst://servername/filename.asf입니다.
마지막 선택은 HTTP입니다. HTTP는 스트리밍 미디어를 위해 고안된 것이 아니며 전송 프로토콜이 아닌 응용 프로그램 계층 프로토콜이지만 방화벽을 통과할 수 있습니다. 웹을 탐색할 수 있는 모든 사람이 HTTP를 통해 스트리밍 파일을 받을 수 있습니다. HTTP만 사용하도록 지정하는 구문은 http://servername/filename.asf입니다.
ASX 파일 사용ASX 파일은 웹 페이지를 ASF 파일에 연결합니다. 웹 사이트에 액세스하는 모든 클라이언트가 Microsoft Internet Explorer를 실행하는 경우가 아니라면 HTML 페이지에서 직접 MMS 경로를 참조해서는 안됩니다. 다른 브라우저는 프로토콜을 이해하지 못하며 프로토콜이 발생해도 무시하기 때문입니다. 대신 스트리밍 미디어 파일을 가리키는 ASX 파일을 참조합니다.
다음은 간단한 ASX 파일의 예입니다.
<ASX version="3.0" > <Entry > <ref HREF=" mms://servernane/filename.asf "/> </Entry > </ASX > ASX 파일을 만든 다음 HTTP나 네트워크 서버에서 호스팅합니다. ASX 파일을 연결하려면 다음과 같이 HTML 페이지에서 표준 <A HREF> 태그를 사용합니다.
<a href="http://servername/path/asxname.asx">설명</a>
사용자가 ASX 파일에 대한 링크를 선택하면 브라우저에서 ASX 파일을 다운로드합니다. ASX 파일은 작습니다. 시스템은 파일 연결 테이블에서 ASX 확장명을 찾아 Windows Media Player를 시작합니다. 그 다음 Windows Media Player는 ASX 파일에서 ASF 파일의 위치를 찾은 다음 스트림을 시작합니다. ASX 파일 작성에 대한 자세한 내용은 MSDN Online Web Workshop  의 설명서를 참조하십시오.
Windows Media 인코더는 AVI, MP3 또는 WAV 형식일 수 있는 디지털 형식의 미디어 파일을 압축하여 Windows Media Player가 사용하는 ASF 형식으로 변환합니다. 인코더는 실시간 이벤트나 저장된 파일에 사용할 수 있습니다. 인코딩은 CPU를 많이 사용하는 작동이므로 Windows Media 서비스를 실행하는 컴퓨터가 아닌 별도의 컴퓨터에서 인코더를 사용하는 것이 좋습니다. 이 절에서는 인코더 사용과 관련된 다음과 같은 문제를 설명합니다.
컴퓨터 하드웨어 구성모든 상황에 적합한 단일 구성은 없습니다. 새 하드웨어를 구입하기 전에 고속 동작 비디오를 녹화할 것인지 또는 저속 동작 비디오를 녹화할 것인지 결정해야 합니다. 저속 동작의 예는 대화 중인 얼굴을 들 수 있습니다. 이 경우에는 처리 능력이 그렇게 많이 필요하지 않습니다. 고속 동작의 예는 뮤직 비디오와 같이 빠른 내용 변경이 많은 비디오를 들 수 있습니다. 이 경우에는 더 많은 처리 능력이 필요합니다.
CPU 선택일반적으로 하나의 Pentium II 프로세서가 모든 비디오를 최대 300Kpbs(경우에 따라 500Kbps)의 대역폭으로 실시간 인코딩을 수행할 수 있습니다. 최대 1Mbps의 대역폭에는 Pentium III나 동급의 프로세서를 사용해야 합니다. 더 높은 비트 속도가 필요한 경우(Microsoft CODEC은 실시간 인코딩을 최대 5Mbps까지 확장 가능)에는 프로세서를 하나 더 사용합니다. 일반적으로 새 장치를 구입한다면 Pentium III나 동급의 프로세서가 장착된 컴퓨터를 구입하도록 하십시오. 현재 그러한 처리 능력이 필요하지 않아도 앞으로 필요하게 될 것입니다.
메모리 추가보통 인코딩에는 64MB의 메모리가 최적의 용량입니다. 버퍼링이 발생하지 않으며 운영 체제와 응용 프로그램만 로딩하면 되므로 대용량 메모리는 필요하지 않습니다. 성능 도구를 사용하여 시스템이 디스크 페이징을 사용하지 않게 하십시오. 페이징을 사용하면 성능에 나쁜 영향을 미치게 됩니다. 성능 도구에 액세스하려면 시작 메뉴에서 프로그램을 가리키고 관리 도구를 가리킨 다음 성능을 누릅니다.
사용 가능한 메모리를 확인하려면 MemoryAvailable Bytes 카운터를 추가합니다. 발생하는 페이징 양을 확인하려면 MemoryPages/sec 카운터를 추가합니다. 두 카운터 모두 Memory 머리글 아래에 있습니다. 그림 2는 카운터 추가의 예를 나타낸 것입니다.
그림 2 Pages/sec 카운터 추가
그림 3은 이들 카운터와 함께 사용 중인 프로세서 시간 양을 나타낸 것입니다.
그림 3 성능 모니터의 예
MemoryAvailable Bytes 카운터는 현재 프로세서가 사용할 수 있는 메모리의 양을 바이트 단위로 나타냅니다. 이 숫자는 항상 4MB 이상이어야 합니다. MemoryPages/sec 카운터는 페이지 오류 때문에 디스크에서 검색되거나 공간을 늘리기 위해 디스크로 쓴 페이지 수를 나타냅니다. 성능 도구에 대한 자세한 내용은 해당 도움말 파일을 참조하십시오.
디스크 드라이브 추가디스크 드라이브는 데이터가 들어오는 즉시 캡처하고 저장해야 하기 때문에 병목 지점이 될 수 있습니다. 드라이브의 데이터 전송 속도가 너무 느리면 데이터가 손실되고 스트림의 품질이 떨어질 수 있습니다. 300Kbps에서 500Kbps까지의 인코딩 속도에는 SCSI 드라이브를 사용하십시오. 이보다 빠른 속도에 대해서는 RAID 레벨 0 디스크 배열을 고려하십시오.
운영 체제 선택Windows Media 인코더는 Windows 2000 Professional과 Windows 2000 Server에서 모두 실행할 수 있지만 포그라운드 응용 프로그램에 우선 순위가 부여되는 Professional을 사용하는 것이 좋습니다.
비디오 캡처 카드 선택Windows Media Technologies와 호환되는 비디오 캡처 카드의 목록을 보려면 다음 주소에서 "Windows Media Hardware Providers" 웹 페이지를 참조하십시오.
http://www.microsoft.com/Korea/windows/windowsmedia/serve/encoding.asp 
비디오 카드 중 일부만 두 운영 체제와 모두 호환되기 때문에 Windows 2000 운영 체제와 호환되는 카드 목록 대신 이 목록을 사용해야 합니다. 가장 많이 사용되는 비디오 캡처 카드는 Viewcast.com의 Osprey 100입니다. 이 카드는 오디오는 캡처하지 않지만 Osprey 100와 사운드 카드의 동기화에 있어 어떤 문제도 보고되지 않았습니다. 자세한 내용은 다음 웹 사이트를 참조하십시오.
http://www.vccsales.com/
사운드 카드 선택단일 오디오 스트림을 인코딩할 경우, Soundblaster Live와 같은 스테레오 사운드 카드를 선택합니다. 최소한 Soundblaster16이나 호환 카드를 사용해야 합니다. Windows 2000 운영 체제용으로 승인된 사운드 카드를 알고 싶으면 Windows 하드웨어 호환성 목록을 참조하십시오. Windows 2000과 호환되는 모든 사운드 카드는 Windows Media Technologies와 호환됩니다. 하드웨어 목록은 다음 웹 페이지를 참조하십시오.
http://www.microsoft.com/hcl/default.asp
이 절에서는 오디오와 비디오 인코딩 및 자동 인코딩 설정을 위한 기술을 설명합니다. 명백하게 알 수 있는 차이점 이외에 오디오와 비디오 인코딩 사이의 한 가지 차이점은 비디오 파일이 오디오 파일은 포함할 수 없는 다중 비트 전송률을 포함할 수 있다는 것입니다. 다중 비트 전송률을 사용하면 Windows Media Player가 사용자 네트워크 연결의 품질과 속도에 가장 적합한 비트 전송률을 선택하여 변화하는 네트워크 조건에 적응할 수 있습니다. 귀는 눈보다 훨씬 인식력이 높으며 눈이 비디오 스트림 대역폭 변화를 알아보는 것보다 귀가 오디오 스트림에 대한 변화를 쉽게 느낄 수 있으므로 이러한 것은 오디오 파일에서는 수행할 수 없습니다.
다중 오디오 스트림 인코딩여러 오디오 스트림을 동시에 인코딩하는 것은 일반적인 상황입니다. 대표적인 예는 온라인으로 방송하는 여러 라디오 방송을 인코딩하는 것입니다. 다중 오디오 스트림을 인코딩하려면 단일 시스템에서 동시에 여러 인코더를 사용하고 실행합니다. 인코더는 CPU를 많이 사용하기 때문에 가능하다면 Pentium III를 사용하십시오.
다중 오디오 스트림을 인코딩하기 위해 또 다른 중요한 고려 사항은 사운드 카드입니다. 단일 시스템에서 다수의 Soundblaster 카드를 사용할 때 문제를 경험한 고객이 많이 있습니다. 대신 슬롯은 하나지만 포트가 여러 개 있는 사운드 카드를 설치합니다.
다중 대역폭 비디오 스트림 인코딩Windows Media Technologies에는 네트워크 연결 속도를 검색하고 변화하는 네트워크 조건을 조정하며 자동으로 진행 중인 비디오 스트림 품질을 개선할 수 있는 지능적 스트리밍 기능이 있습니다. 현재의 Windows Media Technologies 버전 4.0에서 지능적 스트리밍은 다음과 같은 기능을 포함합니다.
자동 인코딩자동 인코딩은 시스템이 부팅되고 사용자가 로그온하면 자동으로 인코더가 시작하는 것을 의미합니다. 프로덕션 서비스가 온라인이고 지속적으로 실행되는 경우에 자주 사용됩니다. 자동 인코딩을 사용하려면 작업 표시줄 및 시작 메뉴 등록 정보 창을 사용하여 바로 가기를 만듭니다. 이 창을 열려면 시작 메뉴에서 설정을 가리키고 작업 표시줄 및 시작 메뉴를 누릅니다. 그림 4는 이 메뉴의 예를 나타낸 것입니다.
그림 4 작업 표시줄 및 시작 메뉴 등록 정보 창
추가를 누르고 바로 가기 만들기 텍스트 상자에 다음과 같이 입력합니다.
NsRex filename.asd /start
인코더 이름은 NsRex이며 filename은 인코더 구성을 저장하는 ASD(Advanced Stream Descriptor) 파일을 의미합니다. 여기에는 사용할 CODEC, 창의 크기, 비디오에 대한 프레임 속도와 I 프레임 수 등에 대한 정보가 포함됩니다. /start 옵션은 사용자가 로그온하면 인코딩이 시작된다는 것을 의미합니다. 이 프로세스를 완전히 자동화하려면 자동 로그온을 사용하여 이름이나 암호를 입력하지 않아도 되도록 만듭니다. 그림 5는 예를 나타낸 것입니다.
그림 5 프로그램을 위한 타이틀 선택
이 예제에서 인코더는 stereo28.8이라는 이름의 .asd 파일을 사용합니다.
이 절에서는 Windows Media 서비스를 실행하도록 컴퓨터를 구성하는 방법, 가장 뛰어난 성능을 활용할 수 있도록 서버를 조정하는 방법 그리고 서버의 보안을 유지하는 방법에 대해 설명합니다. 먼저 서버의 하드웨어 구성에 대해 설명합니다.
컴퓨터 하드웨어 구성CPU를 많이 사용하는 인코더와는 달리 서버는 I/O를 많이 사용합니다. 서버의 병목 지점은 네트워크 인터페이스 카드(NIC), 디스크 시스템의 순서로 발생합니다. CPU와 메모리는 3번째와 4번째의 병목 지점이지만 발생하는 경우는 거의 없습니다. 이 절에서는 Windows Media Server를 위한 최적의 하드웨어 구성에 대해 설명합니다.
CPU와 메모리 선택수천 개의 동시 연결을 처리하는 일반적인 Windows Media Server의 경우, Intel Pentium II 또는 동급의 프로세서를 사용하십시오. 서버가 2,000개 또는 3,000개의 동시 연결을 처리하지 않는 한 다중 프로세서는 필요하지 않습니다. 여기에서 각 연결은 20Kbps입니다. 비트 전송률이 높아지면 서버가 처리할 수 있는 동시 연결의 수가 적어집니다. 최대의 동시 연결을 처리하려면 다중 프로세서를 사용하십시오. 단일 프로세서 시스템의 경우, 256MB 메모리가 최적입니다. 다중 프로세서 시스템의 경우, 적어도 512MB를 사용합니다. 서버의 구성과 서버의 수요에 따라 메모리가 더 필요할 수 있습니다. 스트레스 상태의 서버 작동에 대해 알고 싶다면 이 백서의 뒷부분에서 설명하는 Windows Media Load Simulator를 사용합니다.
네트워크 인터페이스 카드 선택라이브 이벤트의 경우, 인코더와 서버 간을 고속으로 연결하는 것이 특히 중요합니다. 이 연결이 마스터 공급입니다. 충분한 대역폭을 사용할 수 없다면 마스터 신호의 품질이 떨어지고 그 결과 사용자는 낮은 품질을 전송 받게 될 것입니다. 네트워크 인터페이스 카드(NIC)의 경우, 고속 이더넷(100Mbps) 또는 10/100 교환 이더넷을 사용합니다. 교환 이더넷은 패킷을 10Mbps 공유 세그먼트에서 100Mbps로 실행되는 워크스테이션 또는 LAN 세그먼트로 전송합니다. 따라서 10Mbps에서 실행되는 다중 종단 스테이션이나 작업 그룹을 100Mbps에서 실행되는 서버에 연결할 수 있습니다.
T3 회선 용량 두 개를 모두 사용하는 4,000개의 동시 연결을 처리하려면 NIC를 하나 더 추가하여 인코더와 서버 사이에 별도의 연결을 만드는 것을 고려하십시오. 네트워크 연결이 모두 포화 상태인 경우에도 마스터 공급은 영향을 받지 않으며 성능이 저하되지 않습니다. 네트워크 카드는 데이터를 동시에 전송하고 수신할 수 있는 전이중으로 구성되어야 합니다.
디스크 드라이브 선택서버 성능이 좋으려면 빠른 디스크 드라이브가 필수적입니다. Windows Media Server의 확장성이 디스크 배열의 성능에 의해 제한되는 경우가 많습니다. 동시 연결의 수가 많은 경우에는 RAID 구성의 다중 하드 디스크를 사용하는 것이 좋습니다. 고속 데이터 전송 속도 때문에 SCSI, 파이버 채널(아래 내용 참조)과 같은 인터페이스를 고려해야 하지만 가장 적합한 구성을 결정하려면 선호하는 하드웨어 공급업체와 협의하십시오.
더 많은 파일이 사용되거나 사용할 수 있는 캐시가 적어지면(또는 두 경우 모두) 디스크 속도 요구 사항도 증가합니다. Windows Media Server는 캐싱을 사용하지 않는다는 것에 주의하십시오. 따라서 디스크 컨트롤러 자체에 캐싱이 있지 않는 한 데이터를 요구하는 각 읽기는 명시적으로 실제 디스크에서 데이터를 가져옵니다.
ASF 루트 디렉터리를 시스템 드라이브에 저장해서는 안됩니다. 그렇게 하면 시스템 드라이브에서 집중적인 작업과 디스크 스와핑이 발생할 수 있습니다. 또한 사용자가 여러 다른 경로를 통해 연결할 수 있도록 대단히 많이 사용되는 컨텐츠는 복제하여 여러 드라이브에 저장합니다. 경험에 의하면 하나의 디스크로 약 500개의 28.8Kbps 연결을 지원할 수 있습니다.
서버를 구성하였으면 성능 모니터와 함께 Windows Media Load Simulator를 사용하여 메모리 페이징과 프로세서 시간 등의 병목 상태를 검색할 수 있습니다. 서버가 로드를 처리하지 못할 경우, 하드웨어를 추가하거나 서버를 하나 더 추가합니다.
저장소 영역 네트워크고속 출력과 확장성이 중요한 대형 사이트를 관리하는 IT 관리자의 경우, 저장소 영역 네트워크(SAN)를 고려할 수도 있습니다. SAN은 저장소 전용 네트워크입니다. SAN은 RAID 디스크 배열, 디스크 드라이브 및 테이프 드라이브와 같은 저장 장치와 서버를 고속으로 상호 연결합니다. SAN은 높은 대역폭을 제공하는 것 이외에도 모든 저장 I/O를 네트워크의 별도 구역으로 격리하여 다른 네트워크 소통량이 I/O의 영향을 받지 않게 합니다.
SAN의 기본 네트워크 인프라를 Fibre Channel Arbitrated Loop(FC-AL)라고 합니다. 이 인프라는 양방향 지점간 직렬 데이터 채널을 위해 고안된 산업 표준 고속 인터페이스입니다. 이것은 100MB/s 이상의 속도로 최대 10km의 거리까지 시스템을 연결할 수 있습니다.
파이버 채널은 다중 프로토콜을 지원하여 동일한 케이블을 통해 TCP/IP 및 SCSI와 같은 프로토콜을 동시에 실행할 수 있습니다. 하나의 루프에 최대 126개의 노드를 연결할 수 있습니다. FC-AL 인터페이스를 지원하는 하드 드라이브의 예로는 Seagate의 Barracuda 및 Cheetah 드라이브가 있습니다. 이들 드라이브에 대한 자세한 내용은 아래의 웹 사이트를 참조하십시오.
http://www.seagate.com
서버 조정 성능서버의 성능을 개선할 수 있는 작업에는 다음과 같은 다양한 작업이 포함됩니다.
관련 없는 서비스 사용 안함서버에서 사용하지 않는 서비스를 실행하는 경우가 많습니다. 보통 이들 서비스는 시스템이 부팅되면 자동으로 시작됩니다. 이러한 서비스의 한 예로 응용 프로그램에 대한 고객 라이센스가 현재 유효한 것인지 확인하는 라이센스 로깅을 들 수 있습니다. 서버가 스트리밍 미디어 배포 전용으로 사용된다면 이 서비스를 계속 실행해야 할 이유가 없습니다. 또 다른 예로 인쇄 스풀러를 들 수 있습니다. 서버를 스풀러로 사용하지 않는다면 스풀러를 끕니다. 또한 고성능을 위해 Microsoft 인터넷 정보 서비스(IIS)와 Windows Media 서비스를 같은 서버에서 실행해서는 안됩니다. 서버를 Windows Media Server 전용으로 만듭니다. 같은 시스템에서 IIS를 실행한다면 컨텐츠 인덱스 작성기와 FTP 서비스는 사용하지 않는 것이 좋습니다. 인덱스 작성기는 상당한 양의 메모리와 디스크 공간을 요구하며 FTP 서비스는 대개 사용되지 않습니다. 일반적으로 꼭 필요한 서비스가 무엇인지 판단하고 필요하지 않은 서비스는 모두 중단합니다.
레지스트리 키 설정서버에 많은 로드가 걸릴 때 서버의 성능을 개선하기 위해 값을 조정할 수 있는 레지스트리 키에는 두 가지가 있습니다. 키가 없는 경우 키를 추가하거나 설정을 수정하려면 레지스트리 편집기를 사용합니다.
MaxConnectionPerSecondKeyMaxConnectionPerSecond 레지스트리 키는 보류 중인 요청을 유지하는 대기열의 크기를 설정하여 서버가 처리할 수 있는 초당 클라이언트 연결 요청의 수를 제어합니다. 클라이언트 연결 요청의 처리에는 시스템 리소스(CPU 주기 및 메모리)가 사용되며 컴퓨터 하드웨어 구성에 따라 클라이언트로 전달되는 미디어 스트림의 품질과 서버 성능에 나쁜 영향을 미칠 수 있습니다.
연결 요청이 클라이언트에서 Windows Media Server로 보내지면 요청은 연결 대기열에 배치되어 차례대로 처리됩니다. 서버에 연결하려는 클라이언트 시도가 이러한 연결 요청 처리를 위한 연결 속도를 초과한다면 대기열이 가득 차게 됩니다. 초당 처리되는 클라이언트 연결 요청 수에 대한 기본값은 Windows Media Server에 대한 최소 시스템 요구사항을 충족하는 컴퓨터가 연결된 클라이언트에 전달되는 스트림의 품질에 영향을 주지 않으면서 초당 25개의 연결 요청을 처리할 수 있기 때문에 25로 설정됩니다. 대기열에 있는 클라이언트 연결 요청의 수에 대한 값은 초당 클라이언트 연결 수의 20배와 같거나 기본적으로 500입니다. Windows Media Player가 장애 조치(failover) URL을 사용하여 연결을 시도하기 전에 20초 동안 대기하도록 설정되기 때문에 이 값은 연결 속도의 20배로 설정됩니다. 대기열의 모든 요청은 20초의 대기 시간 내에 처리됩니다.
서버는 대기열에 있는 클라이언트 수를 유지합니다. 대기열에 최대 허용 수만큼의 요청이 배치되면 서버는 연결 요청을 수신하는 것을 중지합니다. 연결을 시도하는 클라이언트는 즉시 서버를 사용할 수 없다는 메시지를 받게 됩니다. 이러한 상황이 발생할 때마다 오류 코드 503으로 Windows Media 로그 항목이 작성됩니다. Microsoft Windows 2000 Server 응용 프로그램 이벤트 로그에도 Windows Media 서비스가 %1의 최대 보류 연결에 도달했다는 내용의 메시지가 나타납니다.그러나 서버가 수신을 중지하고 로그 입력이 지난 1분 동안 이루어지지 않은 경우에만 이 항목이 작성됩니다. 여기에서 %1은 변수이며 표시되는 숫자는 대기열의 크기입니다. 그런 다음 서버는 2.5초마다 대기열이 꽉 찼는지 검사합니다. 클라이언트가 처리되어 대기열에서 제거되면 서버는 다시 연결 요청을 수신하기 시작합니다.
다중 프로세서가 있으며 메모리의 양이 큰 컴퓨터를 사용한다면 컴퓨터는 더 많은 수의 연결을 처리할 수 있을 것입니다. 그러나 이 값의 증가를 결정하기 전에 Windows Media Load Simulator를 사용하여 컴퓨터의 CPU와 메모리를 세심하게 평가하는 것이 좋습니다.
서버 연결 속도를 사용자 정의 값으로 설정하려면 변경해야 할 각 Windows Media Server 시스템 레지스트리를 편집합니다. 연결 속도가 특정 하드웨어 구성에 대해 너무 높거나 너무 낮다면 레지스트리 키 HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services nsunicast Parameters MaxConnectionsPerSecond를 사용자 정의 값으로 설정할 수 있습니다. 고성능 서버에서는 75, 심지어 100의 값을 사용할 수 있어야 합니다.
MaxUserPort기본적으로 아웃바운드 호출에 사용하기 위해 응용 프로그램이 시스템에서 소켓을 요청하는 경우, 시스템은 1024와 5000 사이의 값으로 포트를 공급합니다. MaxUserPort 매개 변수는 아웃바운드 연결에 사용할 수 있는 최상위 포트의 값을 설정합니다. Windows Media Server가 로드가 심한 상태에서 작동한다면 이 값을 올려야 할 것입니다. 이 값을 설정하려면 HKEY_LOCALMACHINE SYSTEM CurrentControlSet Services Tcpip Parameters를 탐색합니다. 아직 없다면 MaxUserPort 값을 추가하고 이 값을 0xFFFE로 설정합니다.
최신 NIC 드라이버 사용NIC 드라이브를 최신의 상태로 유지하는 것이 중요합니다. 드라이버를 구형 드라이버에서 최신 버전으로 업데이트하면 성능이 상당히 증가됩니다.
서버 포트 번호TCP/IP 기반 네트워크 컴퓨터에서 실행되는 응용 프로그램에는 포트 번호가 할당됩니다. 이 번호는 들어오는 데이터를 올바른 서비스에 연결합니다. 잘 알려진 포트는 모든 사람들이 사용하는 표준 포트 번호입니다. 예를 들어, 포트 80은 항상 HTTP 소통량(웹 소통량)에 사용됩니다. Windows Media Technologies는 다음과 같은 포트 번호를 사용합니다.
이러한 포트에서 소통량을 허용하도록 방화벽을 구성해야 할 수도 있습니다. 또한 잘 알려지지 않은 포트를 여는 것이 문제가 되는 사이트에 경우, Windows Media는 포트 80에서 HTTP를 통해 스트리밍할 수 있습니다.
포트 번호와 DCOMDCOM(Distributed COM)은 프로세스마다 하나의 포트를 동적으로 할당합니다. DCOM 프로세스에 할당할 포트의 수를 결정해야 합니다. 이 수는 방화벽을 통해 전달되는 동시적인 DCOM 프로세스 수와 같습니다. 또한 원격 프로시저 호출(RPC) 끝 점 매핑에 사용할 포트 135를 열어야 합니다. 또한 DCOM에서 예약된 포트를 알 수 있도록 레지스트리를 편집해야 합니다. 이러한 작업은 HKEY_LOCAL_MACHINES Software Microsoft Rpc Internet 레지스트리 키로 수행합니다. 이 키는 레지스트리 편집기를 사용하여 만들 수 있습니다.
아래의 예에서는 DCOM에게 포트 범위를 10포트로 제한할 것을 지시합니다.
Named Value: Ports Type: REG_MULTI_SZ Setting: 포트 범위. 다음과 같이 여러 행일 수 있습니다. 3001-3010 135 포트 번호, 방화벽 구성 및 DCOM에 대한 자세한 내용은 다음 웹 사이트를 참조하십시오.
http://www.microsoft.com/korea/Windows/windowsmedia/serve/firewall.asp
이 절에서는 Windows Media Server의 보안을 유지하고 컨텐트를 보호하는 방법을 설명합니다. 서버는 두 가지 인증 방법 중 하나를 사용하여 보안을 유지할 수 있습니다. 컨텐트는 Windows Media Rights Manager로 보호할 수 있습니다.
유니캐스트 전송으로 인증인증은 서버에 액세스하는 사용자의 신분을 확인하는 것을 의미합니다. 유니캐스트 전송은 클라이언트와 서버 사이에 지점간 연결이 존재하기 때문에 자동으로 인증됩니다. 클라이언트와 서버 사이에 직접 연결이 없는 멀티캐스트 전송은 여러 가지 문제를 발생시킵니다. 멀티캐스트 전송에 의한 인증은 이 백서의 뒷부분에서 설명합니다.
Windows Media Server에서는 다음과 같은 두 가지 인증 방법 중 하나를 사용할 수 있습니다.
이것은 Windows Media 관리자를 사용하여 서버 등록 정보 아래에서 선택합니다.
익명 인증이 옵션은 기본값인 인증을 선택하지 않음을 선택하여 선택됩니다. 네트워크 관리자는 익명 인증을 사용하여 익명 로그온 사용자 계정 이름을 지정하거나 Netshow Services라는 기본 사용자 이름을 받아들이고 계정의 암호를 입력합니다. 클라이언트의 웹 브라우저가 사용자 이름이나 암호를 제공하지 않고 URL을 요청한다면 서버는 익명 사용자 계정을 가장하고 리소스에 대한 액세스를 시도합니다.
익명 액세스를 사용하면 IT 관리자가 NetShowServices 사용자 이름을 받아들이지 않음으로써 특정 파일에 대한 액세스를 거부할 수 있습니다. 이렇게 하려면 파일에 대한 액세스 제어 목록(ACL)을 설정합니다. 이 백서의 뒷부분에 나오는 "액세스 제어 목록 사용" 절을 참조하십시오. 사용자가 익명으로 Windows Media 컨텐트에 액세스를 시도하고 NetShowServices 계정에 그 파일에 대한 읽기 권한이 없다면 사용자는 로그온해야 합니다. 로그온이 거부되면 파일에 대한 사용자 액세스가 거부됩니다.
기본 인증기본 인증을 사용하면 클라이언트는 일반 텍스트(암호화되지 않은) 사용자 이름과 암호를 입력해야 하며 사용자 이름과 암호는 Base64로 암호화되어 서버로 전달됩니다. 서버는 사용자 이름과 암호를 디렉터리 데이터베이스와 비교하고 사용자 이름과 암호가 정확한 경우에만 서버는 사용자를 가장하고 리소스에 대한 액세스를 시도합니다. 기본 인증은 계정 데이터베이스의 정보를 사용하거나 설치된 경우 Microsoft Site Server Membership 계정의 정보를 사용할 수 있습니다.
Base64 암호화는 암호화의 최소 형식입니다. 네트워크 소통량을 모니터링하는 사용자가 실제 사용자 이름과 암호를 볼 수 없더라도 암호 해독은 중요하지 않습니다. 소통량을 모니터링할 정도로 기술이 뛰어난 사람들은 거의 알고리즘을 연구하여 역 변환할 수 있어 웹 사이트 침입에 사용할 수 있는 일반 텍스트 사용자 이름과 암호를 알아낼 수 있습니다.
인증 패키지 적용인증 패키지를 적용하려면 프로그램을 가리키고 관리 도구를 가리킨 다음 Windows Media를 눌러 Windows Media 관리자를 엽니다.
인증 패키지를 적용하려면
액세스 제어 목록 사용인증 패키지가 활성화되면 Windows Media Server를 사용하여 액세스 제어 목록(ACL) 사용 확인 확인란을 선택하여 액세스 제어 목록(ACL)을 사용할 수 있습니다. 액세스 제어 목록은 폴더나 파일에 대한 액세스 권한이 있는 사용자와 그룹을 지정하는 파일이나 폴더에 관련된 항목 목록입니다. ACL이 없으면 모든 파일과 폴더에 인증이 필요합니다. ACL이 있으면 개별 파일과 폴더에 사용자별 권한을 설정할 수 있습니다.
ACL의 각 항목은 파일에 대한 다음과 같은 액세스 수준 중 하나 이상을 사용자나 그룹에 할당합니다.
유사한 사용 권한을 폴더에 대해서 설정할 수 있습니다.
자세한 내용은 Windows Media 관리자 도움말 파일에서 "Restricting access to ASF Streams" 페이지를 참조하십시오.
Windows Media Rights Manager컨텐트 작성자는 디지털 권한 관리 응용 프로그램인 Windows Media Rights Manager를 사용하여 패키지화된 암호화 파일 형식으로 인터넷을 통해 노래, 비디오 및 기타 미디어를 배포할 수 있습니다. 최종 사용자는 Windows Media Player로 재생하기 위해 파일의 암호를 해독하는 키가 있는 별도의 라이센스가 필요합니다.
Windows Media Rights Manager는 강력한 디지털 권한 관리 암호화 스키마를 사용합니다. 모든 파일은 Windows 운영 체제를 실행하는 각 PC에 고유한 암호화 형식으로 저장되므로 라이센스 보호에 대한 침입이나 파일의 복사가 매우 어려워집니다. 이 Windows 기반 PC별 암호화 스키마는 고객이 부주의하게 파일 보호를 위반하지 않도록 보호합니다. 또한 의도적인 해킹 행위의 저지책 역할도 합니다. Windows Media Rights Manager에 대한 자세한 내용은 다음 웹 페이지를 참조하십시오.
http://www.microsoft.com/windows/windowsmedia/support.asp
클라이언트에 대한 정보를 로깅하고 서버 성능을 평가하고 모니터링하는 여러 방법이 있습니다. 이 절에서는 다음과 같은 항목에 대한 개요를 설명합니다.
이 도구들에는 모두 자세한 자체 도움말이 있습니다. 자세한 내용은 각 도움말 파일을 참조하십시오.
Windows Media 관리자 로그Windows Media 관리자는 이벤트에 대한 정보와 유티캐스트 게시 지점에 연결된 클라이언트에 대한 정보를 로깅할 수 있습니다. 멀티캐스트 문제에 대한 정보 로깅은 더 어려운 문제이므로 멀티캐스트의 절에서 설명하기로 합니다. 기본적으로 로깅을 사용하지 않습니다. 로깅을 사용하려면 시작 메뉴에서 프로그램을 가리키고 관리 도구를 가리킨 다음 Windows Media를 눌러 Windows Media 관리자를 엽니다. 왼쪽의 메뉴에서 서버 등록 정보를 누르고 게시 지점 로깅 탭을 누릅니다. 그림 7은 예제 화면을 나타낸 것입니다.
그림 7 유니캐스트 로깅 사용
게시 지점 이벤트 로그는 클라이언트 작동의 날짜, 시간 및 설명을 표시합니다. 그림 8은 이 로그의 예를 나타낸 것입니다.
그림 8 Load Simulator 게시 지점 이벤트
Windows Media 관리자 게시 지점 클라이언트 로그는 다음과 같은 정보를 표시합니다.
그림 9는 게시 지점 클라이언트 대화 상자의 예를 나타낸 것입니다.
그림 9 게시 지점 클라이언트 로그 예제
이 경우에 Windows Media Load Simulator와 다중 클라이언트를 시뮬레이트하는 단일 컴퓨터를 사용하여 데이터를 수집했기 때문에 클라이언트 IP 주소가 모든 인스턴스에서 동일합니다. 각 클라이언트에는 임의로 할당된 별도의 포트 번호가 있습니다.
로그 파일 항목은 선택한 기간 동안 또는 파일이 지정한 크기에 도달할 때까지 저장됩니다. 파일은 W3C 표준 형식으로 저장됩니다. 파일은 메모장에서 볼 수 있으며 Windows Media SDK에는 로그 구문 분석을 위한 Windows Scripting Host 스크립트 예제가 수록되어 있습니다. 또한 로그 읽기와 해석에 사용할 수 있는 여러 가지 다른 공급업체 제품이 있습니다. 그러한 제품을 공급하는 회사는 다음과 같습니다.
Windows 2000 운영 체제는 관리 도구의 일부로 특별히 Windows Media Technologies 성능과 관련된 통계를 표시하는 모니터를 포함합니다. 이 도구를 액세스하려면 시작 메뉴에서 프로그램을 가리키고 관리 도구를 가리킨 다음 Windows Media 성능을 누릅니다.
그림 10은 이 도구를 나타낸 것입니다.
그림 10 Windows Media 성능 도구
이 도구는 보다 일반적인 성능 모니터와 비슷하지만 스트리밍 미디어에 관련된 카운터가 포함됩니다. 저장된 주문형 컨텐트에 있어 특히 중요한 통계는 Late Reads 카운터입니다. 이 숫자는 0이여야 합니다. 0이 아니라면 디스크 응답이 저하되고 있으며 요구를 따라가지 못한다는 것을 의미합니다. Late Reads는 정지 이미지와 웹 페이지 같은 정적 데이터 서비스를 제공할 때는 거의 문제가 되지 않지만 실시간 멀티미디어 컨텐트 서비스를 제공할 때는 데이터를 즉시 사용할 수 있어야 합니다.
Windows Media Load Simulator는 Windows 2000 리소스 키트에 포함됩니다. 또는 다음 웹 사이트에서 다운로드할 수도 있습니다.
http://www.microsoft.com/windows/windowsmedia/download/default.asp
이것은 클라이언트 시스템에서 실행되며 많은 수의 Windows Media Player 연결을 시뮬레이트하여 Windows Media Server에 대한 Windows Media 유니캐스트 서비스의 용량을 테스트합니다. 최고 로드와 스트레스에서 오프라인 서버를 모두 테스트합니다. 최고 로드는 정상적인 조건에서 최대 수의 클라이언트가 시스템을 사용하는 것 입니다. 스트레스 테스팅은 최고 로드 이상으로 클라이언트 수를 천천히 증가시키면서 수행합니다.
또한 Load Simulator는 온라인 Windows Media Server를 모니터링할 수 있으며 서버 성능이 저하되기 시작하거나 서버가 응답을 중지할 경우에 자동으로 관리자에게 알리도록 구성할 수 있습니다. 그림 11은 Load Simulator의 한 예를 나타낸 것입니다.
그림 11 Windows Media Load Simulator
다음과 같은 로그에는 Load Simulator를 사용하여 실행한 테스트 결과의 해석에 도움이 되는 정보가 수록됩니다.
또한 Windows Media 성능 모니터에는 Simulator와 함께 사용할 수 있는 정보가 수록됩니다. Load Simulator에 대한 자세한 내용은 다음 웹 사이트에서 "Checking Server Performance with Microsoft Windows Media Load Simulator" 기사를 참조하십시오.
멀티캐스팅은 데이터를 사용자 그룹으로 전송하는 일대다 형식의 전송입니다. 멀티캐스팅은 파일이 마지막 홉까지 단일 데이터 스트림으로 전송되기 때문에 네트워크 대역폭이 적게 사용됩니다. 이 경우 개별 스트림은 경로의 끝에 있는 라우터에 의해 대상 스테이션으로 전송됩니다.
Windows Media Technologies가 사용하는 용어 중 특히 멀티캐스트 세션에 적용되는 용어가 있습니다. 멀티캐스트를 사용하는 방법과 멀티캐스트 세션 문제 해결 방법을 설명하기 전에 이들 용어를 설명할 것입니다.
Windows Media Technologies 멀티캐스트 용어의 이해멀티캐스트 전송을 설정할 때 사용되는 용어에는 스테이션, 프로그램 및 스트림의 3가지가 있습니다.
스테이션은 멀티캐스트 전송을 통한 컨텐트 배포에 사용되며 게시 지점은 유니캐스트 전송에 사용됩니다. 스테이션은 텔레비전 방송국과 비슷합니다. 스테이션은 프로그램이라고 하는 컨텐트를 배포하며 프로그램은 보통 몇 가지 스트림으로 구성됩니다. 예를 들어, 프로그램은 중간에 광고가 삽입된 비디오 클립을 사용할 수도 있습니다. 멀티캐스트를 사용하고 멀티캐스트 스테이션을 만드는 방법에 대한 자세한 내용은 Windows Media 관리자 도움말 파일을 참조하십시오.
스테이션의 정의스테이션은 .nsc 파일로 정의됩니다. 이 파일은 멀티캐스트 전송의 가입에 필요한 IP 주소, 포트 번호 및 필요한 CODEC과 같은 모든 정보가 수록된 구성 파일입니다. Windows Media Server는 멀티캐스트 스테이션을 구성할 때 입력된 정보에서 .nsc 파일을 만듭니다.
사용자는 프로그램이 시작할 때 멀티캐스트 전송에 꼭 가입할 필요가 없으므로 .nsc 파일이 필요합니다. 사용자는 언제라도 멀티캐스트 그룹의 구성원이 될 수 있습니다. 즉, Windows Media Player는 전송에 대한 정보가 수록된 헤더 패킷이 없어도 즉시 스트리밍 데이터를 받기 시작합니다. Windows Media Player는 .nsc 파일을 사용하여 이 정보를 가져옵니다.
보통 관리자는 그룹에 가입할 수 있는 사용자에게 전자 메일로 전송하거나 웹 사이트에 게시하여 이 파일을 사용하게 만듭니다. 즉, Windows Media Server가 파일을 만드는 경우에도 Windows Media Server는 이 파일을 배포하지 않습니다. 관리자는 .nsc 파일의 배포를 제어함으로써 권한이 없는 사용자가 전송을 수신하는 것을 방지할 수 있습니다. 예를 들어, 관리자는 웹 사이트에 파일을 게시하여 정보에 대한 액세스를 허가하기 전에 인증을 요구할 수 있습니다.
.nsc 파일은 인코더 구성이 들어 있는 .asd 파일의 이름을 포함할 수 있습니다. 템플릿에서 Windows Media 인코더 기본값을 사용하지 않았다면 멀티캐스트 스테이션을 만들 때 이 파일을 지정해야 합니다. 기본값을 변경했다면 .asd 파일을 저장하고 서버에 복사한 다음 멀티캐스트 전송을 구성할 때 이 파일을 지정합니다. 스트림 형식 정보 지정 대화 상자에서 이러한 작업을 수행합니다. Windows Media 관리자는 정보를 .nsc 파일에 저장합니다.
멀티캐스트 스테이션 구성이 절에서는 멀티캐스트 세션을 위한 스테이션 구성 과정을 설명합니다.
멀티캐스트 세션을 위한 스테이션의 정의
사용자 정보 로깅멀티캐스트를 사용하면 서버와 사용자 사이에 직접적인 통신이 없습니다. 따라서 수신하는 사용자와 특정 클라이언트에 대한 네트워크 연결의 품질에 대한 정보를 수집하기 어렵습니다. 이 문제를 해결하기 위해 Windows Media Player에는 멀티캐스트 전송을 위한 로깅 기능이 포함됩니다. 이들은 IIS Service에서 실행되는 Nsiislog.dll이라는 ISAPI DLL로서 구현됩니다. 아래의 단계대로 수행하여 로깅을 사용합니다. 기본값은 사용 안함입니다.
로깅 사용에 대한 자세한 내용은 Windows Media 관리자 도움말 파일을 참조하십시오.
보통 통계는 전송 품질, 컨텐트 정보 및 클라이언트 정보의 세 가지 범주에 속합니다. 전송 품질 통계의 예는 다음과 같습니다.
컨텐트 정보의 예에는 다음이 포함됩니다.
포함된 URL은 포함된 Windows Media Player가 들어 있는 웹 페이지의 URL입니다. 이 URL을 알면 컨텐트를 사용하는 사용자를 알 수 있습니다.
클라이언트 정보의 예에는 다음이 포함됩니다.
기타 멀티캐스트 사용멀티캐스트는 .asf 파일 이외의 파일 배포에 사용할 수 있습니다. 데이터의 단일 스트림을 다중 사용자에게 전송해야 할 경우에는 멀티캐스트를 대역폭 절약의 한 방법으로 고려해야 합니다. 이 경우 네트워크가 멀티캐스트를 지원할 수 있다고 가정합니다. 예를 들어, 네트워크가 단일 LAN으로 구성된 경우 또는 라우터와 같은 네트워크 장치가 멀티캐스트를 지원하는 경우가 그러합니다. 보통 Windows Media Technologies 멀티캐스트는 네트워크를 통해 Microsoft PowerPoint 프레젠테이션을 전송하는데 사용되지만 다른 종류의 파일이나 파일 디렉터리에도 사용할 수 있습니다. 멀티캐스트 파일 전송을 구성하려면 Windows Media 관리자가 표시하는 멀티캐스트 파일 전송 옵션을 선택합니다. 설정할 수 있는 매개 변수에는 다음을 포함하여 여러 가지가 있습니다.
자세한 내용은 Windows Media 관리자 도움말 파일을 참조하십시오.
멀티캐스트 전송 문제 해결멀티캐스트 세션의 문제 해결을 위한 전체 지침은 이 백서의 범위를 벗어나는 것이지만 이 절에 작업을 쉽게 할 수 있는 몇 가지 제안이 포함됩니다. 또한 이 백서에서는 설명하지 않았지만 멀티캐스트에서처럼 유니캐스트에도 비슷한 통계가 있습니다. 로깅 기능에 대한 자세한 내용은 Windows Media 관리자 도움말 파일을 참조하십시오.
파일 검사먼저 asx 및 .nsc 파일에 액세스할 수 있고 파일에 오류가 없는지 확인합니다. 이 파일이 없으면 클라이언트는 멀티캐스트에 가입할 수 없습니다. 인코더를 위한 기본 템플릿이 사용되지 않거나 변경된 값이 있으면 .asd 파일을 지정해야 한다는 것을 기억하십시오. 멀티캐스트를 구성한 후 인코더가 변경되었다면 이 파일을 다시 지정하여 .nsc 파일을 최신 상태로 유지해야 합니다. 멀티캐스트를 구성한 후 서버 구성이 변경된 경우 .nsc 파일을 다시 내보냅니다. 이렇게 하려면 Windows Media 관리자의 멀티캐스트 스테이션을 선택한 다음 내보내기를 선택합니다.
통계 검사전송 중에 Windows Media Player를 사용하여 통계를 검사합니다. 이 작업을 하려면 Windows Media Player에서 마우스 오른쪽 단추를 누르고 통계를 누릅니다. 그림 26은 예제 화면을 나타낸 것입니다.
그림 26 Windows Media Player 통계
프로토콜이 멀티캐스트로 설정되었는지 확인합니다. 복구된 패킷과 손실된 패킷을 검사하여 데이터가 손실되는지 확인합니다. 복구된 패킷 카운트가 증가한다면 Windows Media Player가 손실된 패킷을 다시 구성하고 있는 것입니다. 이것은 네트워크에 문제가 있다는 표시일 수 있습니다. 이들 통계는 유니캐스트 브로드캐스트에서도 사용할 수 있습니다.
멀티캐스트 세션을 구성할 때 로깅을 사용한다면 세션이 종료된 후에 Nsiislog.dll 로그를 사용하여 더 많은 정보를 얻을 수 있습니다. 문제가 있는 단일 세그먼트에 얼마나 많은 사용자가 있는지 등의 경향을 확인합니다.
IGMP 버전의 지속적인 추적여러 가지 버전의 Windows 운영 체제에서 클라이언트가 멀티캐스트 세션에 가입하기 위해 사용하는 여러 가지 버전의 인터넷 그룹 관리 프로토콜(IGMP)을 구현한다는 것에 주의하십시오. 아래의 표에 Windows 버전에 따른 IGMP 버전이 요약되어 있습니다.
문제 확인단일 LAN을 통해 멀티캐스팅하지 않는 한 대개 멀티캐스팅은 다중 서브넷과 라우터를 포함합니다. 서버가 네트워크를 통해 홉 단위로 상주하고 이동하는 세그먼트에서 시작하여 문제를 확인합니다. 또한 TTL(Time-To-Live) 값이 패킷이 통과해야 하는 각 홉을 통해 패킷을 얻을 수 있을 만큼 큰지 확인합니다. 기본적으로 TTL은 홉의 수와 같아야 합니다. 이 숫자가 너무 낮으면 패킷은 네트워크 가장자리에 도달하기 전에 무시됩니다. 기본값은 5입니다. 홉의 숫자를 설정하려면 서버 구성을 누른 다음 편집할 스테이션을 누릅니다. 그림 27과 같이 서버 구성 – 스테이션 편집 대화 상자가 열립니다.
그림 27 TTL 매개 변수 변경
TTL 항목을 더 큰 값으로 변경합니다.
마지막으로 네트워크의 일부 세그먼트에 대한 전송을 차단하고 있을 수 있는 방화벽이나 비 멀티캐스트 사용 장치를 찾습니다. 패킷이 통과해야 하는 라우터나 스위치가 멀티캐스트를 이해하지 못한다면 패킷이 손실됩니다. 또한 앞에서 설명한 것처럼 많은 방화벽은 멀티캐스트 전송에 사용되는 전송인 UDP 패킷을 통과시키지 않습니다.
네트워크 문제 조사에 사용할 수 있는 많은 다른 공급업체의 모니터링 도구가 있으며 Windows 2000 운영 체제에도 몇 가지 유틸리티가 있습니다. 여기서는 네트워크 모니터와 tracert 유틸리티의 두 가지 도구를 간략하게 설명할 것입니다.
네트워크 모니터System Management Server와 같이 사용할 수 있으며 Windows 2000 Server의 생략 버전인 네트워크 모니터를 사용하면 네트워크에서 패킷을 볼 수 있습니다. 네트워크 모니터를 액세스하려면 시작 메뉴에서 프로그램을 가리키고 관리 도구를 가리킨 다음 네트워크 모니터를 누릅니다.
네트워크 모니터는 그림 28과 같습니다.
그림 28 네트워크 모니터
네트워크 모니터는 캡처하는 호스트의 NIC를 promiscuous 모드로 만들어 회선에서 볼 수 있는 모든 프레임을 추적 도구로 전달합니다. 캡처 필터는 분석을 위해 특정 프레임만 저장되도록 정의할 수 있습니다. 원본과 대상 NIC 주소, 원본과 대상 프로토콜 주소 및 패턴 일치에 기반하여 이 필터를 구성할 수 있습니다. 캡처를 구하면 디스플레이 필터를 사용하여 문제의 원인을 좁혀나갈 수 있습니다. 디스플레이 필터를 사용하면 특정 프로토콜도 선택할 수 있습니다. 네트워크 모니터 사용에 대한 자세한 내용은 도움말 파일을 참조하십시오.
Tracert 유틸리티tracert 유틸리티는 원하는 대상 컴퓨터의 IP 주소로 패킷 그룹을 계속 보내 작동합니다. 예를 들어, 시스템에서 whitehouse.gov까지의 경로를 추적하려면 tracert whitehouse.gov를 입력합니다. 경로를 따른 각 라우터는 추적을 시작한 시스템으로 정보를 반환하여 패킷을 수신한 시스템의 IP 주소와 각 패킷의 왕복 시간(밀리초)을 사용자에게 보여줍니다. 추적이 완료되면 패킷이 원본에서 대상으로 이동하기 위해 필요한 홉 수와 각 홉에 걸리는 시간을 알 수 있습니다.
tracert 작동의 중요한 구성 요소는 패킷의 TTL(Time-To-Live) 값입니다. Tracert는 증가하는 TTL 값으로 세 패킷 그룹을 연속적으로 보냅니다. 경로를 따라 각 라우터는 TTL 값을 1씩 줄인 후에 경로를 따라 다음 라우터로 전달합니다. 첫 번째 패킷 그룹은 1의 TTL로 보내집니다. 첫 번째 홉의 라우터는 값을 0으로 줄여 패킷을 만료시키고 만료 정보를 원래 시스템으로 다시 전송합니다. 그 다음 두 번째 그룹은 만료 정보를 먼저 반환하지 않고 두 번째 라우터로 2의 TTL과 함께 보내집니다. 이 과정은 최대 TTL 값에 도달하거나 대상 컴퓨터가 패킷을 수신할 때까지 계속됩니다. tracert 유틸리티는 최대 30의 기본 TTL 값이 갖습니다. 즉, 처음 30개의 홉을 보고할 수 있습니다. -h 옵션을 사용하여 이 값을 늘릴 수 있습니다. 옵션 목록을 보려면 명령줄에서 tracert만 입력합니다.
그림 23은 tracert 세션의 예를 나타낸 것입니다.
그림 29 tracert 세션 예
다음은 경험에 따른 응답 시간입니다.
tracert에 대한 자세한 내용은 Windows 2000 도움말 파일을 참조하십시오.
로드 균형 조정은 처리 로드를 서버 배열을 통해 분산하므로 어떤 서버에도 로드가 집중되지 않습니다. 또한 장애 조치(failover) 기능도 제공하여 오류가 발생한 서버의 로드를 제 기능을 발휘하는 서버로 전환할 수 있습니다. 로드 균형 조정을 구현하는 방법에는 다음과 같은 몇 가지가 있습니다.
DNS 라운드 로빈DNS 라운드 로빈 방법은 단일 IP 주소가 아닌 IP 주소 전체 목록으로 DNS 쿼리에 응답하여 작동합니다. 쿼리를 수행하는 Windows Media Player는 보통 첫째 IP 주소를 선택하고 연결 시간에 대해 그 서버를 참조합니다. 동일한 IP 주소가 반복하여 선택되지 않도록 목록이 순환하여 매번 목록의 상단에 다른 IP 주소가 나타나게 만듭니다.
예를 들어, 이름과 IP 주소가 다음과 같은 세 개의 서버가 있다고 가정합니다.
클라이언트 요청이 라운드 로빈을 통해 순환되도록 서버를 설정하면 다중 A 레코드를 사용합니다. 이들 DNS 레코드는 호스트를 IP 주소로 매핑합니다. 이 예에서 사이트에 액세스하는 모든 클라이언트가 example.microsoft.com이라는 이름을 사용하길 원하지만 그러한 요청을 3개의 서버에서 공유하는 상황을 가정해 봅니다. A 레코드를 다음과 같이 설정합니다.
앞에 붙은 슬래시가 없는 디렉터리 이름이 대개 현재 디렉터리에 상대적으로 해석되는 것처럼 뒤에 붙은 마침표가 없는 이름은 때로 루트 이외의 도메인에 상대적으로 해석되기 때문에 각 A 레코드에서 example.microsoft.com 이름 끝에는 마침표가 필수적입니다. 끝에 붙는 마침표는 도메인 이름이 절대값이라는 것을 나타냅니다. 즉, 루트에 상대적으로 작성된 것을 의미합니다. 이 예에서 TTL 필드는 이름 서버가 60초 후에 이름 캐시에서 이들 항목을 제거하도록 지시합니다. 이로서 라운드 로빈을 지원하지 않는 중간 이름 서버에서 레코드가 오랫동안 캐시되지 않도록 보장할 수 있습니다.
DNS 라운드 로빈의 이점과 제한DNS 라운드 로빈의 주요 이점은 단순하고 자유롭다는 것입니다. 소수의 레코드를 추가하여 실제로 요청이 풀의 모든 호스트 사이에서 순환할 때 서버의 풀이 단일 서버로 작동하는 것처럼 보이게 할 수 있습니다. 첫 번째 제한은 라운드 로빈이 실제로는 로드 공유 기술도 아니고 로드 균형 조정 기술도 아니라는 것입니다. 실제 로드 균형 조정 솔루션은 서버에서 로드를 측정하고 클라이언트 요청을 보낼 위치를 결정하여 작업을 균등하게 분산합니다. 라운드 로빈은 어떤 방식으로도 서버 로드를 측정하지 않습니다. 서버의 성능에 관계 없이 단순히 클라이언트 요청을 다중 호스트 사이에서 대체할 뿐입니다. 하나 이상의 호스트에는 다른 호스트보다 많은 작동을 하려는 경향이 있습니다. 두 번째 제한은 서버 중 하나가 가동 중단되어도 클라이언트의 요청이 이 IP 주소로 전송되어 이들 클라이언트가 적절한 응답을 수신하지 못한다는 것입니다.
Windows 로드 균형 조정 서비스Windows 로드 균형 조정 서비스(WLBS)를 사용하면 들어오는 IP 소통량을 동적으로 여러 서버에 분산시킬 수 있습니다. WLBS는 클라이언트 요청을 호스트에 투명하게 분산시키며 클라이언트는 하나 이상의 가상 IP 주소를 사용하여 풀에 액세스할 수 있습니다. 클라이언트의 관점에서 보면 풀은 이들 IP 주소에 응답하는 단일 서버로 보입니다. WLBS 또는 MSCS(Microsoft 클러스터 서비스) 중 어느 것을 Windows Media와 함께 사용해야 하는지 묻는 고객이 많습니다. 답은 WLBS를 사용하라는 것입니다. 아래에 설명하는 MSCS는 Microsoft SQL Server와 같이 데이터를 많이 사용하는 응용 프로그램입니다.
WLBS 서버는 다음과 같은 기능을 제공하기 위해 서로 통신합니다.
단일 선호도, 선호도 없음 또는 클래스 C를 사용하기 위해 필터링한 다중 서버에서 로드 균형 조정을 위해 WLBS를 구성할 수 있습니다. 상태 정보가 없는 응용 프로그램인 Windows Media Server 서버에 가장 좋은 방법은 단일 선호도입니다. 단일 선호도로 구성하면 WLBS 가상 IP 주소를 사용하여 들어오는 모든 패킷을 WLBS 클러스트의 특정 노드에 고정할 수 있습니다. 클러스터 IP 주소를 사용하여 클라이언트에서 수신하는 모든 패킷이 그 노드에 연결됩니다.
MSCS(Microsoft 클러스터 서비스)MSCS는 SQL Server와 Microsoft Exchange Server와 같은 데이터 집중형 응용 프로그램에 사용됩니다. Windows Media 서버의 로드 균형 조정용으로 사용하면 안됩니다. 그러나 WLBS와 MSCS 기술을 같이 사용하여 전체 사이트에 매우 높은 확장성과 가용성을 제공할 수 있습니다. 예를 들어, 데이터베이스 기반 사이트는 WLBS 클러스터 HTTP와 Windows Media 기반 서버가 액세스하는 MSCS 클러스터에 데이터베이스를 호스팅할 수 있습니다. 이 구성은 데이터베이스 수준에서 높은 수준의 가용성을 제공하며 웹/HTTP 수준에서 높은 수준의 확장성과 가용성을 모두 제공합니다.
Windows Media Player 실행 중 발생할 수 있는 네트워크 오류 메시지는 RFC 2038에서 정의한 표준 HTTP 1.1 상태 모드입니다. 다음을 참조하십시오.
ftp://ftp.isi.edu/in-notes/rfc2068.txt
가장 흔하게 볼 수 있는 코드는 5xx 범위에 있으며 서버에 오류가 발생했거나 요청을 처리할 수 없다는 신호를 보내는 경우를 나타내는 서버 오류 메시지입니다. 이들 코드는 아래와 같습니다.
Windows Media Technologies, 소프트웨어 다운로드에 대한 자세한 정보와 컨텐트 작성 및 배포에 대한 기사들에 대한 링크는 다음의 공식적인 Windows Media Technologies 웹 페이지를 참조하십시오.
http://www.microsoft.com/korea/windows/windowsmedia/default.asp
특정 기술 관련 질문에 대한 답은 다음의 Microsoft 기술 자료 사이트를 참조하십시오. 위치는 다음과 같습니다.
http://www.microsoft.com/support/kb.htm?RLD=32
또한 사용자가 가입할 수 있는 다음과 같은 몇 가지 공개 뉴스 그룹도 있습니다.
© 2000 Microsoft Corporation. All rights reserved.
이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft 측의 책임으로 해석해서는 안 되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보장하지 않습니다.
이 백서는 정보 제공 목적으로만 제공됩니다. Microsoft는 이 문서에서 명시적이든 묵시적이든 막론하고 여하한 보증도 하지 않습니다.
해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권에서의 권리와는 별도로, 이 설명서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법) 또는 목적으로도 복제되거나, 검색 시스템에 저장 또는 도입되거나, 전송될 수 없습니다.
Microsoft가 이 설명서 본안에 관련된 특허권, 상표권, 저작권, 또는 기타 지적 소유권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 마이크로소프트로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권, 또는 기타 지적 소유권 등에 대한 어떠한 사용권도 허여하지 않습니다.
Microsoft, PowerPoint, Windows, Windows 로고, Windows Media 및 Windows NT는 미국, 대한민국, 및/또는 기타 국가에서의 Microsoft Corporation의 등록 상표 또는 상표입니다.
여기에 인용된 실제 회사와 제품 이름은 해당 소유자의 상표일 수 있습니다.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
01/00
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
영삼넷
Categories
Recent Posts
Recent Comments
Statistics
- Total Visitors:
- 523270
- Today:
- 6841137
- Yesterday:
- 97512566
소개 