제가 꽤 오랜 기간 (약 6개월 이상)을 고생했던 사항이 있습니다.
제 노트북은 레노버 T400 이고 그래픽 카드는 NDIVIA와 인텔 2개를 사용하고 있습니다.

문제는 CPU의 가상화 기능을 키고 Hyper-v 서비스를 시작하게 되면 성능 문제가 극심하게 발생한다는 점입니다.
예를 들어 스타크래프트2를 거의 하기 힘든 상황이 온다거나 단일 Display 상태에서 모니터를 연결하면 잠시 컴퓨터가 행이 걸린듯한 모습이 된다거나 하는 점들이죠.

확인결과 이미 알려진 이슈였습니다.

[현상]
Windows 2008 이상의 Hyper-V 및 Accelerated display adapter가 설치된 머신의 그래픽 성능이 저하될 수 있다.
예) 성능 저하의 예
1. CTRL+ALT+DELETE 를 통한 화면 전환 시
2. 듀얼 모니터 연결 시
3. 3D 게임 실행시

[원인]
고성능 그래픽 카드는 고성능의 기능을 사용하기 위해 TLB를 이용하게 되는데, Hyper-V를 이용 하게 될 경우 TLB가 Hyper-V 상에서 가상화 되게 되어 해당 기능을 빈번하게 이용하는 디바이스 드라이버에서 성능 이슈가 발생하게 됩니다.

- 부연 설명 : 일반적으로 가상메모리에서 실제메모리를 찾아가기 위해서는 Paging 기법을 이용하지만 고 성능이 필요한 일부의 경우 TLB 즉 가상메모리를 실제메모리로 맵핑 시킨 블럭을 이용하는 경우도 있습니다.

[해결방안]
앞으로 개인용 Desktop 즉 그래픽 작업에 대한 부하가 큰 컴퓨터에는 꼭 Windows 7 을 이용하도록 합시다.
이는 Hyper-V의 기본 기능이기 때문에 해당 그래픽 디바이스를 제거하는 것 외에는 방법이 없습니다.

[출처]
http://support.microsoft.com/kb/961661/en-us

다운로드 : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=89d80c15-0082-4fef-a4fc-fefa463bed08

Windows 2008 서버에서 Windows Phone Developer Tools 를 설치를 시도하는 경우 아래와 같은 에러와 함께 설치가 실패하게 됩니다.

그래서 Windows 2008에 Windows Phone Developer Tools 를 설치하는 방법을 공유해 드립니다.

1. Windows Phone Developer Tools 를 다운로드 받습니다.
다운로드 : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=04704acf-a63a-4f97-952c-8b51b34b00ce

2. 설치 파일인 wm_web.exe에 /x 스위치를 이용하여 해당 파일의 압축을 원하는 위치에 풉니다.

3. 압축을 푼 폴더의 baseline.dat 를 notepad 에서 엽니다.

4. 아래와 같은 내용을 확인 하고 편집합니다.

InstallOnLHS와 InstallOnWin7Server의 값을 0으로 편집한 후 저장합니다.
 

5. setup.exe /web 을 통해 설치를 진행 합니다.

출처 : http://blogs.msdn.com/b/astebner/archive/2010/05/02/10005980.aspx

제가 최근에 클러스터와 연계된 이슈를 해결하다가 보니 Failover Cluster Virtual Adapter에 IP가 할당된 것을 발견했습니다. 왜 일까? 고민하다가 좋은 글을 찾아서 공유해 봅니다.
배경 지식이 없으니 조금 힘드네요… 역시 언제나 그렇지만 제 번역은 항상 Poor 합니다… ; )
원문 : http://blogs.technet.com/b/askcore/archive/2009/02/13/what-is-a-microsoft-failover-cluster-virtual-adapter-anyway.aspx

종종 “Microsoft Failover Cluster Virtual Adapter 가 무엇이고, 우리는 그것을 통해 무엇을 할 수 있나요?” 란 질문을 받곤 합니다. 보통 정확한 대답은 “그냥 두세요 혼자서 알아서 당신을 위해 일하게 두시면 됩니다.” 입니다. 대부분의 사람들은 이런 대답에 충분히 만족 합니다. 하지만 일부는 더 알고 싶어합니다. 내 본 내용은 그 분들을 위한 내용입니다.

Windows Server 2008 Failover Clustring 의 네트워크 모델을 새로운 기능을 충족시키기 위해서 다시 작성되었습니다. (DHCP 서버로부터 IP을 할당 받는 기능 및 네트워크 적으로 분리된 즉 서로 다른 서브넷에 클러스터 노드들을 위치시키는 것) 추가적으로 이전 통신의 경우 UDP 브로드케스트를 이용했지만 현재는 약간의 TCP 통신이 가미된 UDP 유니케스트를 이용하여 통신하게 됐습니다. 이 모든 추가 기능들은 클러스터 내의 좀 더 신뢰성 있고 견고한 Communication connectivity 를 제공합니다. 클러스터 노드가 어디에 위치하고 있는지는 이제 신경 쓰지 않아도 됩니다. 더 이상 클러스터의 노드들이 같은 데이터 센터의 같은 서버 랙에 있는지 아니면 다른 OC3 WAN Connection 으로 연결된 원격 데이터 센터의 서버 랙에 있는지 신경 쓸 필요가 없습니다. 이를 통해 Cluster는 단일 지점 오류로부터 좀 더 자유롭게 되었습니다, e.g.. 네트워크 인터페이스 카드 (NIC) 카드 (그리고 이러한 새로운 디라이버의 이름은 “Network Fault-Tolerant or NetFT.sys” 입니다.). 실제로 유일한 최소 요구 사항은 클러스터 상의 모든 노드들 간에 2개 이상의 redundant communication conectivity 을 제공하는 것입니다. 이렇기 때문에 Cluster network driver (NETFT.SYS)는 클러스터에서 서비스 되는 어플리케이션과 서비스가 highly available 할 수 있도록 완벽한 라우팅 구조를 만들 수 있으며, 이와 동시에 Redudant communication connectivity 를 제공합니다.

Note : 클러스터 통신을 위해 적어도 2개 이상의 네트워크를 갖지 못한 경우 Cluster validation process 중에 Warning (Best practice 위반)으로 표시되게 됩니다. 이 내용은 하드웨어 요구사항의 Network Adpters and cable 섹션에서 표시됩니다.

새로운 기능에 대한 몇 가지 예를 제공하기 위해서 (물론 아직 새로운 네트워킹 모델에 대해 깊이 파해지친 못했지만), 전 클러스터 노드로 부터 클러스터 로그를 생성하여 클러스터 시작 시 어떻게 이 새로운 네트워크 모델이 반영되고 있는지 설명하고자 합니다. 클러스터 로그의 몇몇 엔트리들은 NETFT와 연관되어 있습니다. 한정 지을 순 없지만 이와 관련된 몇몇에 대해 설명은 아래와 같습니다.

NETFT – Network Fault-Tolerant
TM – Topology Manager (Cluster Netowrk topology에 대한 검색 및 관리. 네트워크 및 NIC의 오류를 보고. Microsoft Failover Cluster Virtual Adapter의 설정)
IM – Interface Manager (어떤 NIC 라도 모두 클러스터 구성의 일부로써의 책임을 짐)
NETFTAPI – NETFT Application Programming Interface (API)
FTI – Fault-Tolerant Interface

클러스터가 시작될 때, 이 이벤트들은 등록된 Indicating NETFT는 클러스터 아키텍처의 다른 부분들과의 통신을 준비합니다. (느낌은 오는데 해석이 않되네요… 죄송합니다. 아래의 로그들은 이벤트 처리처리를 위해 준비하는 내용입니다.)
As the cluster service starts, there are events registered indicating NETFT is preparing for communications with other pieces of the cluster architecture

00000784.000007cc::2009/01/30-14:26:38.199 INFO [NETFT] FTI NetFT event handler ready for events.
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] Starting NetFT eventing for TM
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] TM NetFT event handler ready for events.
00000784.000007b0::2009/01/30-14:26:39.369 INFO [CS] Starting IM
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] Starting NetFT eventing for IM
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] IM NetFT event handler ready for events.

다른 노드와 연결이 되게 되면 라우팅 경로가 추가 됩니다.

00000784.00000648::2009/01/30-14:26:39.744 INFO [NETFT] Added route <struct mscs::FaultTolerantRoute>
00000784.00000648::2009/01/30-14:26:39.744 INFO <realLocal>172.16.0.181:~3343~</realLocal>
00000784.00000648::2009/01/30-14:26:39.744 INFO <realRemote>172.16.0.182:~3343~</realRemote>
00000784.00000648::2009/01/30-14:26:39.744 INFO <virtualLocal>fe80::2474:73f1:4b12:8096:~3343~</virtualLocal> 00000784.00000648::2009/01/30-14:26:39.744 INFO <virtualRemote>fe80::8b6:30ea:caa3:8da7:~3343~</virtualRemote>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Delay>1000</Delay>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Threshold>5</Threshold>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Priority>99</Priority>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Attributes>1</Attributes>
00000784.00000648::2009/01/30-14:26:39.744 INFO </struct mscs::FaultTolerantRoute>

라우트 경로를 통해 노드들에 ‘도달할 수 있는’ 경로들에 대한 추가적인 이벤트들이 등록됩니다.

00000784.0000039c::2009/01/30-14:26:39.759 DBG [NETFTAPI] Signaled NetftRemoteReachable event, local address 172.16.0.181:003853 remote address 172.16.0.182:003853
00000784.0000039c::2009/01/30-14:26:39.759 DBG [NETFTAPI] Signaled NetftRemoteReachable event, local address 172.16.0.181:003853 remote address 172.16.0.182:003853
00000784.0000039c::2009/01/30-14:26:39.759 DBG [NETFTAPI] Signaled NetftRemoteReachable event, local address 172.16.0.181:003853 remote address 172.16.0.182:003853
00000784.000004f4::2009/01/30-14:26:39.759 INFO [FTI] Got remote route reachable from netft evm. Setting state to Up for route from 172.16.0.181:~3343~ to 172.16.0.182:~3343~.
00000784.000002f4::2009/01/30-14:26:39.759 INFO [IM] got event: Remote endpoint 172.16.0.182:~3343~ reachable from 172.16.0.181:~3343~
00000784.000002f4::2009/01/30-14:26:39.759 INFO [IM] Marking Route from 172.16.0.181:~3343~ to 172.16.0.182:~3343~ as up
00000784.000001f8::2009/01/30-14:26:39.759 INFO [TM] got event: Remote endpoint 172.16.0.182:~3343~ reachable from 172.16.0.181:~3343~
00000784.00000648::2009/01/30-14:26:39.759 INFO [FTW] NetFT is ready after 0 msecs wait.
00000784.00000648::2009/01/30-14:26:39.759 INFO [FTI] Route is up and NetFT is ready. Connecting to node W2K8-CL2 on virtual IP fe80::8b6:30ea:caa3:8da7%15:~3343~
00000784.0000061c::2009/01/30-14:26:39.759 INFO [CONNECT] fe80::8b6:30ea:caa3:8da7%15:~3343~: Established connection to remote endpoint fe80::8b6:30ea:caa3:8da7%15:~3343~.

이러한 변화들의 결과로 Cluster Networking 모델은 그 자체로써 실제 Cluster network driver 가 되었습니다. 물론 숨겨진 장치입니다만 어쨌든 어뎁터 입니다.

장치관리자의 기본 뷰에서는 숨긴 장치로 표시되지만, (숨김 장치 표시를 선택해야만 해당 장치를 볼 수 있습니다.) ipconfig /all 커멘드를 통해 클러스터 노드의 네트워크 설정에 대한 조회를 통해 쉽게 볼 확인 할 수 있습니다.

다른 어뎁터들과 마찮가지로 Microsoft Failover Cluster Virtual Adapter 역시 자신의 MAC 주소와 IPv4 및 IPv6 주소를 가지고 있습니다. IPv4 주소는 Automatic Private Internet Protocol Addressing (APIPA) address 이고 IPv6는 라우팅이 될 수 없는 Link-Local address 입니다, 하지만 이는 크게 중요하지 않습니다. 왜냐하면 모든 클러스터 상의 Communication은 실제 NIC 상에서 터널링을 통해 진행 되게 됩니다. 그리고 이 NIC 상의 통신 경로는 위에서 설명한 것과 같이 Cluster 서비스의 시작 시 해당 경로를 얻게 됩니다.

Microsoft Failover Cluster Virtual Adapter 의 MAC 주소는 실제 NIC의 MAC 주소를 기반으로 합니다.

Cluster network driver(netft.sys)는 커널 모드 드라이버로 Cluster 서비스에 의해 시작되고, 중지 될 수 있습니다.

Cluster network driver는 HKLM\System\CurrentControlSet\Services 밑에 entry를 가지고 있습니다.

추가로 아래는 클러스터 각 노드의 Microsoft Failover Cluster Virtual Adapter 라우팅 테이블 entry 입니다. 아래는 클러스터 노드에서 route print 커멘드를 실행하여 얻은 3자기 섹션의 output 입니다. 첫번째 파트는 해당 노드의 모든 인터페이스를 보여줍니다. 인터페이스 15번이 Microsoft Failover Cluster Virtual Adapter 입니다.

다음 화면은 IPv4의 라우팅 테이블 입니다. Microsoft Failover Cluster Virtual Adapter의 3개의 entry를 반영 하고 있습니다.

마지막은 IPv6의 라우팅 테이블 입니다.

자 우리는 어떤 경우에 문제를 겪게 될까요? 아래는 문제가 발생하는 몇 가지 경우입니다.

1. Microsoft Failover Cluster Virtual Adapter 의 Disable
2. Windows 2008 Failover Cluster가 설치된 상태에서 Sysprep 를 통해 초기화를 시도하는 경우 이경우 Cluster Validation 과정에서 문제가 될 수 있습니다.
3. 어뎁터의 정보를 수정한 경우

Hopefully, this gives you a better feel for this new functionality in Windows Server 2008 Failover Clusters, and like I stated at the beginning of the blog, the correct answer is to not do anything to the adapter - just let it work for you. Thanks and we hope this has been helpful.

Chuck Timon and John Marlin
Senior Support Escalation Engineers
Microsoft Enterprise Platforms Support

Exchange 2007 SP1 에서 추가된 Move-TransportDatabase.ps1 스크립트를 이용하여 Exchange Queue Database을 이동 시킬 수 있습니다.

아래는 Q:\Exchsrvr\TransportRoles\data\Queue 로 Queue Database 및 Log를 이동하는 방법입니다.

Move-TransportDatabase.ps1 -QueueDatabasePath: Q:\Exchsrvr\TransportRoles\data\Queue -QueueDatabaseLoggingPath: Q:\Exchsrvr\TransportRoles\data\Queue

그러나 이 기능들이 활성화 되어 있으면 Exchange 2007의 CCR 에서 문제를 겪을 수 있습니다.

Windows 2008에는 기본적으로 해당 기능을 사용할 수 있으며, 만약 Windows 2003에서 해당 기능을 이용하고 싶다면 아래의 패치 (http://support.microsoft.com/kb/912222/ko) 을 설치하시면 됩니다.
지금부터 하는 애기는 아마도 H/W (NIC) 에서 지원이 되어야 쓸 수 있습니다… :)

TCP Chimney Offload
이전에는 CPU가 통신에 대한 모든 부분에 대한 Workload 를 담당했다면 이제는 NIC가 이 짐을 일부 덜어주게 하는 기능 입니다. 물론 NIC에서 해당 기능을 지원해야 합니다.
아래 표를 통해 해당 기능 사용 여부를 결정 하시기 바랍니다.

Receive Side Scaling (RSS)
수신 데이터에 대한 처리를 여러 CPU로 분산하는 기능입니다.
문서를 읽어 봤는데 원래 인터럽트 처리가 중요한 놈은 높은 우선 순위로 처리되고, 좀 덜 중요한 녀석들이 DPC로 묶여서 높은 우선 순위 이후에 처리하게 되어 있는데, 멀티 코어 환경에서 이 DPC 처리를 다른 CPU에 할당하는 기술을 말하는 거 같습니다.

Network Direct Memory Access
말 그대로 네트워크에서 바로 메모리에 접근하는 기술 입니다. 원래는 네트워크에서 수신한 데이터는 메모리에 저장하고 이를 다시 어플리케이션에서 사용하기 위하여 어플리케이션 버퍼로 옮겨 줘야 하는데 이 과정을 하나로 줄여 성능을 향상 시킵니다.

설정 확인 : netsh int tcp show global
설정 Disable : netsh int tcp set global rss=disabled chimney=disabled
NetDMA 활성화 및 비활성화 방법

1. Click Start, click Run, type regedit, and then click OK.
2. Locate the following registry subkey, and then click it:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Double-click the EnableTCPA registry entry.
   Note If this registry entry does not exist, right-click Parameters, point to New, click DWORD Value, type EnableTCPA, and then press ENTER.
4. To enable NetDMA, type 1 in the Value data box, and then click OK.
5. To disable NetDMA, type 0 in the Value data box, and then click OK.
6. If the EnableTCPA registry entry does not exist, enable the NetDMA functionality.

출처 : http://support.microsoft.com/kb/951037/en-us / Mcirosoft 이경화 차장님

PS. 한번은 이 기능들을 정리해야 할 꺼 같아서 정리해 봅니다.

최근에 흥미로운 일을 좀 진행 했습니다.
http://blogs.msdn.com/b/tess/archive/2008/09/02/outofmemoryexceptions-while-remoting-very-large-datasets.aspx

위의 문서에서 보듯이 .net Remoting을 통해 100M 정도의 데이터 셋을 Serialization을 하는데는 1G의 공간이 필요하다고 합니다. 물론 XML 타입으로 Serialization을 했기 때문이죠.

원래 XML은 Stateful 과 StateLess 타입이 있다고 합니다. 변경과 관련된 관리 정보를 저장하기 위해서죠. ( Anyway 기본적으로 XML 타입으로 Serialization을 하게 되면 Stuteful 이 됩니다. 그렇게 되면 데이터의 크기가 더 커지겠죠. 그리고 그와 더불어 이 XML 타입을 사용하는 경우 내부적으로 많은 Short lived 객체들을 사용하게 된다 던지 하는 등의 성능에 좋지 못한 영향을 끼칠 수 있는 문제들을 많이 발생 시킨다고 합니다. 이는 XML을 사용해서 문제가 되는 것이 아니라 XML 타입을 사용하지 않아도 되는 곳에 XML 타입을 사용했기 때문에 문제가 되는 것 입니다.
출처 : http://msdn.microsoft.com/en-us/magazine/cc163911.aspx

결론적으로 .net remoting을 통해 단순히 DB 조회 데이터를 가져온다면 Binary Type을 이용하는 것이 훨씬 효과적이라는 것입니다.

Binary 타입으로 Serialization을 하기 위해서는 Dataset을 리턴 하기 전에 한 줄만 추가해 주면 된다고 하네요.
ds.RemotingFormat = SerializationFormat.Binary;

그리고 한 가지 더 OOM은 물론 해당 프로세스의 메모리 사용량이 많아 졌을 때도 발생하지만 필요한 메모리를 할당하지 못했을 때 즉 Serialization을 하기 위해서는 1개의 큰 메모리 공간이 필요한데, 이미 다른 이유로 인해 메모리 단편화가 많이 발생하거나 32bit의 한계인 2G를 초과하는 메모리 할당이 필요 했다면 역시 OOM이 발생 합니다.

후자의 예만 잠시 들자면 VM 사이즈가 1.4G인 프로세스에서 100M의 dataset을 Serialization 하기 위해서는 약 1G의 메모리 공간이 필요합니다. 하지만 이렇게 1G의 메모리 공간을 추가로 할당하게 되면 VM 사이즈가 2G를 넘어서기 때문에 할당에 실패할 수 밖에 없습니다. 이 경우 OOM이 발생하게 되는 것이죠,