APC들은 사용자 프로그램과 시스템 코드가 특정한 사용자 스레드 (특정 프로세스 주소공간)의 컨텍스트에서 실행되는 방법을 제공하는 인터럽트 이다.

APC의 대기열은 스레드에 한정되어 있다. 전에 다른 적이 있지만 스레드는 커널 모드와 사용자 모드에서 실행 된다.  APC들은 APC 개체라고 부르는 커널 제어 개체를 통해 설명되는데, 실행을 기다리는 APC들은 커널이 관리하는 APC 대기열에 상주한다.

즉 APC는 스레드가 같은 하나의 수행할 job에 대한 대기열로 볼수 있고, 커널이 이 APC 루틴을 수행한다. 즉 스레드의 실행은 APC의 실행으로 보면 된다.

먼저 실행부 (Process 나 메모리 스레드 I/O 보안 등을 관리 ntoskernl.exe)는 커널 모드 APC들을 사용하여 운영체제 작업이 특정 스레드의 컨텍스트에 있는 주소 공간 내에서 완료 되도록 수행된다. 즉 인터럽트를 일으킬 수 있는 시스템 서비스의 실행 정지 및 스레드간 메모리상에서 비동기 I/O지원 등을 제공한다.

장치드라이버들은 I/O 작업을 위해서 사용한다.

사용자 모드 APC는 패시브 모드에서 실행된다.

Windows 의 NLB는 L4처럼 동작하는 것 처럼 보이지만 실제로는 브로드케스팅을 통해 모든 Node에 트레픽을 전달 하고, 해당 노드에서 NLB 규칙에 따라 해당 트레픽을 드랍 또는 처리하는 방식이므로 L4와 비교하면 않되고, 기능상 L4와 같이 사용할 때만 쓰셔야 합니다.

또한 WNLB는 서로 브로드 케스트를 통해 헬스 체크를 합니다. 즉 서버의 Network이 완전 단절 되는 상태 즉 응답 불능의 경우 Fail over를 지원하지만 단순 서비스 장애는 확인이 불가능 합니다.

NLB 를 구성할때는 Cluster 메뉴의 New를 클릭해서 만들어 주면 됩니다.
중요한게 NLB 구성 화면에서 클러스터 작업 모드를 유니캐스트로 해주시면 않됩니다. 그렇게 되면 클러스터의 노드간 통신이 않됩니다.

아시다시피 무엇보다 해당 서버 네트워크 속성에서 Network Load Balancing 부분의 Check가 선행 되어야 합니다.

이러한 설정이 모두 끝났다면 구현을 해봅니다.
주요 파라메터에 대한 설명은 다음 링크를 참조 하세요. (NLB 주요 파라메터 설명 : http://www.serverinfo.pe.kr/TipnTech.aspx?Seq=192)

주요 발생 에러
1. TCP/IP 속성에 클러스터의 Virtual IP 가 등록 됐음에도 등록이 않됐다고 에러가 발생한다.
- 저는 간단하게 해당 서버만 재 부팅했습니다. 보통 발생하는 에러고 에러로 보면 않됩니다.

2. Router 넘어 단에서 해당 WNLN 서비스 IP 및 DNS Name으로 접근이 않된다.
- 라우터에서 멀티캐스트를 지원하는지 확인을 해봐야 하며, 지원하지 않는 다면 라우터에 정적ARP를 추가해 주어야 합니다.

주요 NLB 관련 Trouble Shooting 방법 은 다음 링크를 참조 합니다.
(http://technet2.microsoft.com/windowsserver/en/library/8d2e0b4f-4dfd-4893-9505-124ddf4fc2f01033.mspx?mfr=true)

WMS... 굉장히 생소하다. (나민 그런가...) 아무튼 일때문에 WMS를 구현해야하는데, 너무 간단하네요...;;; Windows 쵝오~~~

Windows 2003
구성 요소 마법사에서 추가합니다.
. R2의 경우 2번째 미디어가 필요합니다.


 

Windows 2008
모듈 설치 후 서버 역활을 추가해야 합니다.

일단 Windows 2008에서 가장 크게 변경된 사항은 기본적으로 WMS Cache 및 Proxy를 지원한다는 점입니다.

일단 본 블로그에서는 2003의 설치 사항을 확인 하기 위한 것 입니다.
설치 후 설치 여부를 확인 하기 위해서

의 푸른 버튼을 클릭하면 간단하게 제대로 설치 됐는지 TEST가 가능합니다.

자 설치가 완벽하네요...^^
먼저 주문형 게시 지점을 만듭니다.
 
마법사가 실행 됩니다.
 

모든 미디어를 지원 하기 위해서 Content Type 은 Files로 하겠습니다.
 

게시 지점 형식은 주문형 게시 지점으로 하겠습니다.

미디어의 게시지점을 지정해 줍니다.

게시지점을 만든 후 미리 해당 WMI를 TEST 해볼 수 있게 마법사가 뜹니다.

웹페이지를 만들어 간단히 TEST 해보겠습니다.
<embed src="mms://서버주소/게시지점 명/encoder_ad.wmv">
<embed src="http://서버주소/게시지점 명/encoder_ad.wmv">

추가로 모두 미디어 스트리밍 서비스를 받기 위해서 는 익명인증을 사용해야 겠죠...^^

오랫만에 경어를 사용했더니... 기분이... ㅋ

추가로 Windows 2003에서 다양한 방법으로 광고를 추가 할 수 있었다면 2008에서는 해당 광고에 과금을 위해 로깅도 할 수 있고 또한 사용자의 상태에 따른 Web2.0식 광고도 제공됩니다.

인터럽트나 Exception이 발생하면 커널은 기존 처리 중 이던 Thread를 커널 스텍에 Trap Frame을 만들어 상태를 처리하고, Trap Handler를 호출하여 해당 Trap을 처리한다. ( 알수 없거나 처리 할 수 없을 경우 KeBugCheckEx를 호출 하고 정지 )

덤프 미 생성시 블러스터 웜/ Disk Array Controller / CPU / Memory / 메인 보드 를 확인 해야 한다.

하드웨어 인터럽트 처리

이전 포스트들을 잘 읽어 봤다면, 용어에 대하여 별도로 설명할 필요는 없을꺼 같다.하드웨어 인터럽트가 발생하면 위와 같은 순서로 처리된다. 또한 CPU는 여러 ISR에 대하여, 개별 적으로 처리가 가능하다.

PIC
http://maystyle.tistory.com/entry/Programmable-Interrupt-Controller
IDT
http://maystyle.tistory.com/entry/IDT-살펴-보기

Windows 에서 인터럽트의 처리 (IRQL)

IRQL에 대해서는 이전 포스트(http://maystyle.tistory.com/entry/IRQL)에서 다뤘다 시피 인터럽트에 대한 처리 우선 순이라 할 수 있다. 즉 더 높은 순위의 인터럽트는 낮은 순위의 인터럽트를 마스크(블럭 시키고 자기가 실행 된다.) 한다. 높은 인터럽트가 발생하면 기 실행 Thread는 저장되고 해당 인터럽트와 연결된 Dispatcher들을 실행 한다.

인터럽트가 발생 > CPU의 IRQL을 높힘 > CPU에서 인터럽트 처리 > CPU의 IRQL을 원상 복귀 시킴
(현재 IRQL 확인 : http://maystyle.tistory.com/entry/현재-CPU의-IRQL을-살펴보자)

중요한건 IRQL을 통해서 PIC와 통신 비용을 줄일 수 있다는 거다. (이 부분은 나만의 유추다) 일단 PIC는 3개의 레지스터를 가지고 인터럽트 프로세스를 진행한다.
IRR - Interrupt Request Register
ISR - Interrupt Service Register
IMR - Interrupt Mase Register
로직은 IRR에서 인터럽트를 요구 할때 IMR와 IRR 값을 비교하여 처리되어야 한다면 ISR 단계로 넘어가게 된다. 그런데, 문제는 HAL에서 IMR을 설정하는 작업이 굉장이 느리다는 것다. (H/W의 인터럽트는 HAL이 IRQL에 Mapping 한다.)그래서 굳이 PIC까지 가서 IMR을 설정하지 않고, IRQL을 만들어 놓고, HAL 단에서 IRQL만 건들여서 우선 순위를 설정하게 된다.

커널 모드 스레드는 자신이 실행하려는 작업에 따라 IRQL을 높히게 된다. 그래서 장치 인터럽트시  커널 및 장치 드라이버는 왠만하면 Passive 수준을 유지하여, 인터럽트를 빠르게 처리하려 한다.

방금 언급한 것 처럼 PIC에서 정의된 IRQ와 IRQL은 다르다. 솔직히 Windows는 IRQ와 별계로 IRQL을 통해 서비스 우선 순위를 결정한다. 그렇다면 어떻게 누가 결정할까? 바로 HAL에서 HalpGetSystemInterruptVector를 호출하여 매핑한다. 이전 포스트를 참고 하자. http://maystyle.tistory.com/entry/인터럽트를-IRQL에-매핑하기

DPC 계층 이상에서 코드가 실행 중일 경우 CPU는 다른 스케줄러를 실행 할 수 없다. 없는데 그런 경우가 생기니깐 장애가 생기는 것이다. DPC는 이전 포스트를 참고 하자. (http://maystyle.tistory.com/entry/DPC-Deferred-Procedure-call)

원문을 참고 하자.
One important restriction  on code running at DPC/dispatch level or above is that it can't wait for an object  if doing so would necessitate the scheduler to select another thread to execute , which is an illegal operation / because the scheduler synchronizes its data structures at DPC/ dispatch level and cannot therefore be invoked to perform a reschedule. Another restriction is that only nonpaged memory can be accessed at IRQL DPC/dispatch level or higher. / This rule is actually a side-effect of the first restriction because attempting to access memory that isn't resident results in a page fault. When a page fault occurs, the memory manager initiates a disk I/O and then needs to wait for the file system driver to read the page in from disk. This wait would in turn require the scheduler to perform a context switch (perhaps to the idle thread if no user thread is waiting to run), thus violating the rule that the scheduler can't be invoked (because the IRQL is still DPC/dispatch level or higher at the time of the disk read). If either of these two restrictions is violated, the system crashes with an IRQL_NOT_LESS_OR_EQUAL crash code. (See Chapter 4 for a thorough discussion of system crashes.) Violating these restrictions is a common bug in device drivers. The Windows Driver Verifier, explained in the section "Driver Verifier" in Chapter 7, has an option you can set to assist in finding this particular type of bug.

본문의 예를 들자면 DPC/디스패치 수준은 무조건 Nonpaged Memory에서 수행되는 것이다.  즉 DPC의 오브젝트들은 메모리에 저장이 되는데, 만약 Page Fault가 발생하게 되면 어떻게 될까? 그렇게 되면 분명 Disk에서 해당 object를 읽어 와야 하고, 또 다시 인터럽트들이 발생하게 된다. 그러면 다시 컨텍스트 전환이 일어나게 되며, 이는 on code running at DPC/dispatch level or above is that it can't wait for an object  를 어기게 된다. 이때 충돌 코드가 IRQL_NOT_LESS_OR_EQUAL이다. 순환 큐가 아닌 이상... 큐에 들어간 DPC는 수행되야 하며, 이에 컨텍스트 스위칭이 일어날 수 없다.

자 마지막으로 인터럽트 개체는 무엇일까?
다음 포스트를 참고하자 (http://maystyle.tistory.com/entry/인터럽트-개체)

(출처 : Windows internals)
Interrupt Objects The kernel provides a portable mechanism—a kernel control object called an interrupt object—that allows device drivers to register ISRs for their devices. An interrupt object contains all the information the kernel needs to associate a device ISR with a particular level of interrupt, including the address of the ISR, the IRQL at which the device interrupts, and the entry in the kernel's IDT with which the ISR should be associated. When an interrupt object is initialized, a few instructions of assembly language code, called the dispatch code, are copied from an interrupt handling template, KiInterruptTemplate, and stored in the object. When an interrupt occurs, this code is executed.

This interrupt-object resident code calls the real interrupt dispatcher, which is typically either the kernel's KiInterruptDispatch or KiChainedDispatch routine, passing it a pointer to the interrupt object. KiInterruptDispatch is the routine used for interrupt vectors for which only one interrupt object is registered, and KiChainedDispatch is for vectors shared among multiple interrupt objects. The interrupt object contains information this second dispatcher routine needs to locate and properly call the ISR the device driver provides. The interrupt object also stores the IRQL associated with the interrupt so that KiInterruptDispatch or KiChainedDispatch can raise the IRQL to the correct level before calling the ISR and then lower the IRQL after the ISR has returned. This two-step process is required because there's no way to pass a pointer to the interrupt object (or any other argument for that matter) on the initial dispatch because the initial dispatch is done by hardware. On a multiprocessor system, the kernel allocates and initializes an interrupt object for each CPU, enabling the local APIC on that CPU to accept the particular interrupt.

커널은 장치 드라이버가 장치에 대한 ISR을 등록할 수 있도록 "인터럽트 개체"를 제공한다. 인터럽트 개체에는 ISR의 주소/ 장치IRQL / ISR이 연결되는 IDT 항목 및 필요한 모든 정보를 가지고 있다.

ISR과 특정 인터럽트 수준을 연결하는 것을 "인터럽트 개체 연결하기"라 하고 IDT 항목으로 부터 ISR의 연결을 끊는 것을 "인터럽트 개체 연결 끊기"라고 부른다. 드라이버를 시스템에 로드할 때 장치 드라이버가 ISR을 켜짐 상태로 만들고 드라이버가 언로드 될때 ISR을 꺼짐 상태로 만든다.

인터럽트 객체를 이용하면 커널이 하드웨어를 다룰 필요가 없음은 물론이고, 데이터 공유가 가능한 다른 장치 드라이버의 다른 부분과 ISR의 실행을 동기화 할 수 있다.
게다가 다중 장치 드라이버들을 하나의 IDT 항목에 연결해서 인터럽트 디스패처가 각 루틴을 차례로 실행하게 할 수 있다. (http://maystyle.tistory.com/entry/IDT-살펴-보기 의 0x83 번 루틴을 보면 알 수 있따.) 이를 Daisy-Chain 구성이라 한다. 이러한 구성은 모든 동일한 인터럽트를 사용하기 원하는 장치 드라이버가 그들의 인터럽트를 공유할 수 있도록 커널에 지시할때만 허가되고, 그렇지 않을때는 PNP가 인터럽트 할당을 재 구성한다.
(출처 : Windows internals)

위의 명령어 (dt nt!_kinterrupt) 는 ISR의 규정된 인터럽트 개체를 직접 보기위한 명령어 이다.

디스패칭은 종종 한 스레드의 실행이 너무 길어져서 스케줄링을 다시해야하는데, 자발적인 대기상태 전환이나 종료가 않되는 경우 사용한다.

DPC란 하드웨어 인터럽트 서비스를 적절하게 제공하기 위해서 함께 동작하는 장치 인터럽트들을 제어할때 사용한다. IRQL이 높은 인터럽트가 발생하게 되면, CPU는 현재 Thread를 저장하고, 해당 인터럽트를 실행한다.

그런대 이 인터럽트도 여러 Thread로 나뉠 수 있다. 그리고 계중에는 중요하거나 우선 처리 않되도 되는 경우가 있을 수 있다. 이럴 경우 DPC를 이용하게 된다.

자 DPC가 어떻게 수행되는지 확인해 보자.

1. 먼저 인터럽트가 발생한다.
2. 1에서 발생한 인터럽트가 IRQL이 높은 경우 현 상태를 저장하고, IDT를 참조하여 ISR을 실행한다.
3. ISR이 동작하면서 CPU의 IRQL을 올린다
4. 만약 실행 되는 Thread가 덜 중요할 경우 해당 Thread를 DPC 큐에 넣는다.
5. ISR이 종료되면 IRQL이 DPC 레벨로 낮아 진다.
6, 7, 8, 9 DPC의 인터럽트들을 실행하고, 큐의 모든 object를 실행한 다음 원래 Thread로 복귀한다.

물론 특정 CPU를 대상으로 하는 "Targeted DPC"도 있다. DPC가 낮은 또는 중간의 우선순위라면 커널은 보통 대기열의 끝에 DPC를 두고 DPC가 높은 우선 순위를 가진다면 커널은 대기열 앞에 DPC를 넣는다.

먼저 !irql 을 통해 프로세서의 IRQL 상태를 알 수있다. 위의 경우 lazy irql을 지원하지 않기 때문에 이 필드는 0이다. 아무튼 필자가 가지고 있는 덤프는 위와 같고, 여튼 간에 !pcr을 통해서 IDT에 대한 포인터 현재 실행 스레드와 앞으로 실행할 스래드의 주소를 알 수 있다.

PCR(Process Control Region) 과 PRCB(Processor Control Block)의 구조체는 DDK 의 Ntddk.h에 정의 되어 있다.