기존의 TLB Flushing과 성능에 대한 이슈는 알려진것과 같습니다.
“High performance graphic driver 를 이용하는 경우 성능이슈가 발생 할 수 있다” http://support.microsoft.com/kb/961661

참고) TLB는 CPU에서 빠른 메모리 접근을 하기 위하여 사용하는 Virtual Address와 Physical Address를 mapping한 Table 입니다.

하지만 Nehalem CPU의 경우 VPID(Virtual Processor ID) 를 통해 TLB Cache에 대한 Overhead를 꽤 줄인것 같습니다. (내용은 아래와 같음)
Remote FX와 TLB 성능에 대하여 아래와 같이 추론해 봅니다.

아래 내용이 정확한지는 무책임하게도 저도 모릅니다.

기존에는 “Hyper-v 를 이용하는 경우 context switching 이 발생하면 TLB 역시 Flushing 되며 이를 사용하는 경우 성능이슈가 나타난다.” 였습니다. 하지만 Nehalem 이후의 CPU의 경우 이러한 TLB에 Virtual Processor 에 대한 ID를 달수 있고, 이를 통해 Merom 대비 약 40%의 성능 향상이 있었다. 그리고 이를 사용하기 위해서는 SLAT 기능은 Enable 해야 한다???

SLAP는 GVM > GPA > SPA 로의 변환을 Hyper-V 가 담당 했었는데, 이걸 그냥 새로운 CPU에서 Cover 하고 있는 기능입니다.

Back Data
출처 : 어코딩투 재프~ (울회사 가상화팀)
For virtualizing desktops using RemoteFX, SLAT hardware is REQUIRED. The use of SLAT capable hardware offers significant performance improvements across the board and is especially important when using RemoteFX. These technologies are an extension to the traditional TLB that allow Hyper-V to use the hardware to handle multiple TLBs – one for each virtual machine. This is fundamental requirement for RemoteFX.
- Intel refers to this a Extended Page Tables (EPT).
- AMD refers to this as Nested Page Tables (NPT) or Rapid Virtualization Indexing (RVI).
If there are BIOS option to enable these features (they’re usually on by default), these options should be enabled.

출처 : http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=8
Nehalem’s TLB entries have also changed subtly by introducing a “Virtual Processor ID” or VPID. Every TLB entry caches a virtual to physical address translation for a page in memory, and that translation is specific to a given process and virtual machine. Intel’s older CPUs would flush the TLBs whenever the processor switched between the virtualized guest and the host instance, to ensure that processes only accessed memory they were allowed to touch. The VPID tracks which VM a given translation entry in the TLB is associated with, so that when a VM exit and re-entry occurs, the TLBs do not have to be flushed for safety. Instead if a process tries to access a translation that it is not associated with, it will simply miss in the TLB, rather than making an illegal access to the page tables. The VPID is helpful for virtualization performance by lowering the overhead of VM transitions; Intel estimates that the latency of a round trip VM transition in Nehalem is 40% compared to Merom (i.e. the 65nm Core 2) and about a third lower than the 45nm Penryn.

오랫만에 글을 올리는군요… : )

목적 : Page Size와 Lock Pages in Memory
(작은 머리가 폭발할 지경 / 어떤 문서는 Page Size를 무슨 4M니 2M니 이야기 해서 그냥 AMD 문서로 통일함)

Large Page Size는 x64 CPU인 Westmere 부터는 1G까지 지원됩니다. 하지만 AMD의 문서를 보니 보통 2M씩 쓰는게 일반적이라고 합니다. (http://blogs.amd.com/developer/2009/02/23/huge-pages-and-numa-on-windows-operating-systems/)

하지만 실제로 Page Size가 2M로 증가하는 것은 아니고 4K짜리 512개를 모아서 2M인 것처럼 할당을 해주는거라고 합니다. 그래서 TLB에서만 이 효과를 볼 수 있다는 말인건지… 좀 햇갈립니다.

The JVM or other application makes a VirtualAlloc request to allocate a chunk of memory with a flag to map it to huge pages.  The OS really deals in terms of 4K pages.  To return a 2MB page it must find 512 contiguous 4K pages and those will then be locked in memory (they are not candidates for paging out).  By default, it will look for such a 2MB block in the memory that is local to the requesting processor.  If the OS cannot find a free 2MB page in local memory, it will search in memory from other nodes in the system.

아무튼 위와 같기 때문에 이 설정이 Lock Pages in Memory였던 거군요…
어쨌든 W2k8에서는 기본으로 지원한다는것은 사실이고, 가장 큰 장점은 TLB 를 자알 쓸 수 있다 입니다. (성능차이는 약 20% 정도라고 함)

· Windows Server 2008/2008 R2 have Large Memory Pages enabled by default
· Windows Vista/7 have Large Memory Pages enabled by default
· Windows Server 2008 R2 Hyper-V added support for Large Memory Pages (surprise!) and is one of many new performance improvements in R2

(예를 들어 1M의 메모리를 할당하는 Application이 해당 메모리를 자주쓰는 경우 TLB는 256개가 필요합니다. 하지만 2M짜리 Page Size를 이용하는 경우1~ 2번이면 가능하겠죠….)

Large Page를 사용함으로 얻는 이익 : http://developer.amd.com/documentation/articles/Pages/2142006111.aspx
(주로 TLB와 관련된 성능 향상을 이야기 하고 있음)

JVM 이 Large Page Size를 사용하는 방법 : http://developer.amd.com/documentation/Articles/Pages/322006145.aspx

(Lock Pages in memory 정책을 통한 설정에 추가적으로 튜닝 포인트를 언급)
마지막으로 개발할때 고려사항은http://msdn.microsoft.com/en-us/library/aa366720(VS.85).aspx 을 참고하시면 될꺼 같습니다.

그냥 Dummy Hub를 들고 가서 패킷 캡쳐 하면 되겠죠?
그리고 Promiscuous mode : )

* IP Head의 ID 값을 확인 하면 2 End Point 간의 Packet의 동일 여부를 확인 할 수 있다.
* Disk Free Size의 값을 확인 한 후 수집을 중지 시킬 수 있다.
* tcp.npl : tcp에 대한 Parsor로써 예를 들어 80과 8080은 Netmon에서 HTTP로 확인 되는데 다른 포트를 HTTP로 이용하고 있을 경우 추가로 Parsor에 넣어 주고 컴파일해주면 된다.
* SMB Command에서 OpLock을 확인 할 수 있으며 걸거나 끄는데 레지스트리 값을 통해 진행 (SMB일때 Contains 필터를 통해 File name으로 필터링을 걸 수 있다.)
* Wifi-monitoring mode : AP에 대한 Packet을 다 캡쳐 할 수 있으나, AP를 이용하여 인터넷은 못한다.
* TCP의 Seq 번호와 Ack 번호를 통해서 패킷 검증 가능 (Ack 할때 마다 1씩 증가함으로 해당 값을 보면 됨 / 하지만 초기 값은 랜덤하게 생성)
* 139, 445를 이용하는 SMB는 2000 이후 부터는 445부터 연결 시도
* Receiver가 Sender에 Windows Size를 알려주면 그에 맞춰 주기도 하고 Sliding Windows Side를 이용하여는 방법도 있고~ 다시 Ack 없이 받을 수 있는 크기?
* Stateful inspection : Connection이 들어 와서 Source가 Ramdom 하게 되어 있지만, 그냥 처리해주는 Firewall 동작

Installing and Configuring MPIO
http://technet.microsoft.com/en-us/library/ee619752(WS.10).aspx

Intel Advanced Networking Services

- Teaming Modes
Adapter Fault Tolerance
Switch Fault Tolerance
Adaptive Load Balancing/Receive Load Balancing
Static Link Aggregation
IEEE 802.3ad Dynamic Link Aggregation

- Virtual Machine Load Balancing
Only Available For Hyper-V Virtual Machines
Provides Send/Receive Load Balancing Across All VM’s Connected Through The Teamed Interface
Provides Fault Tolerance For Switch, Cable or Adapter Failures

EX ) 벤더별 Network Teaming 지원 스팩

1. HP ProLiant Network Teaming Software
Network Fault Tolerance Only (NFT)
Transmit Load Balancing w/Fault Tolerance (TLB)
Switch-assisted Load Balancing
IEEE 803.3ad Dynamic Link Aggregation
Automatic – Selects Best Option Based On Hardware/Network Typology

2. Broadcom Advanced Control Suite
Teaming Modes
Smart Load Balancing and Failover
IEEE 803.3ad Dynamic Link Aggregation
Generic Trunking (FEC/GEC)/802.3ad-Draft Static
Smart Load Balancing (Auto-Fallback Disabled)

Hyper-V 권장 가상 프로세서 구성

성능 최적화를 위해서 Physical Processor: Virtual Processor Ratio는 SQL은 1:1, Exchange는 1:2 를 넘지 않게 설정할 것을 권장하고 있습니다.  (각 워크로드 별 성능 가이드를 따라서 해당 비율을 조정할 것을 권장함. )

VDI시나리오도 일반적으로는 1:3 또는 1:4 로 권고되고 있으나 실제 구축된 사례에서는 통상 물리적인 Logical Processor (Hyper Thread 를 포함함 CPU 갯수) 당 2개의 VM 정도의 비율로 구성을 합니다.
(참고로 기술적으로만 봤을 경우, Hyper-V R2가 현재 지원하는 최대 논리적 프로세서 수는 64개이고, 최대 지원 가능한 Virtual Processor 수는 512이므로 일반 Application Server의 경우 수치 상으로는 1:8까지 지원 가능하다고 하며, VDI의 경우 1:12까지 Functional Level의 TEST가 완료 됐다고 합니다.)

하지만 중요한 점은 고객사의 Work Load에 맞춰 설계하는 것이겠죠?

For more performance

- Close VMConnect
- Avoid using snapshot
- Disable floppy, optical drive, etc…

Process의 Handle은 분명 32bit 값이여야 하는데 왜? 위에 그림 처럼 4Bit를 다른 용도로 사용하고 있을까?
Lock : 어차피 커널 오브젝트는 8XXX,XXXX 번지 이 후 임으로 굳이 8을 넣어 줄 필요가 없다.
A,I,P : 커널 오브젝트는 8Byte 단위로 Allocate 됨으로 역시 굳이 넣어 줄 필요가 없다.

AD DS의 Physical Structure (http://maystyle.tistory.com/544) 에 이어 작성 했습니다.
개인적으로는 이전에 언급한 Physical Structure와 함께 AD 이해를 위해 가장 필수적인 요소가 아닐까 합니다.

AD DS Partitions

이전 챕터에서 언급한 것과 같이 AD DS 데이터베이스는 각 도메인 컨트롤러의 하드 디스크에 단일 파일로써 저장됩니다.

저장되는 정보는 몇개의 논리적인 파티션으로 구분되는데, 이 각각의 파티션은 각기 다른 타입의 정보를 저장합니다. AD DS 파티선은 소위 Naming contexts로 불립니다. AD DS의 파티션은 Ldp.exe 및 ADSI Edit 와 같은 툴을 통해 확인 할 수 있습니다.

Domain Directory Partition

도메인 디렉토리 파티션은 도메인의 모든 정보(유저, 그룹, 컴퓨터, Contact)를 담고 있습니다. 기본적으로 확인 하고 싶은 어떤 정보던지 ADS.msc 를 통해 확인 할 수 있습니다.

Configuration Directory Partition

Configuration 디렉토리 파티션은 전체 포레스트의 설정 정보를 담고 있습니다. 예를 들어 사이트에 대한 모든 정보 및 사이트 링크 복제 커넥션이 이 Configuration 디렉토리 파티션에 저장됩니다. 또한 특정 어플리케이션 또한 이 파티션을 이용하게 되는데, Exchange는 자신의 모든 설정 정보를 자신의 디렉토리 서비스를 이용하기 보다는 이 Configuration 파티션을 이용하여 저장합니다.

왜냐하면 이 Configuration 디렉토리 파티션은 전체 포레스트에 대한 정보이면서 전체 포레스트에 복제가 되기 때문입니다. 각각의 도메인 컨트롤러는 쓰기 가능한 Configuration 디렉토리 파티션을 가지고 있으며, 어느 도메인 컨트롤러든 해당 데이터를 변경 할 수 있습니다. 이는 Configuration 정보가 모든 도메인 컨트롤러사이에서 복제가 되게 되며, 또한 모든 도메인 컨트롤러사이에서 Configuration 정보가 복제 되게 되면 모든 도메인 컨트롤러는 같은 Configuration 정보를 지니게 됩니다.

Schema Directory Partition

스키마 디렉토리 파티션은 전체 포레스트에 대한 스키마 정보를 담고 있습니다.
스키마는 AD DS상에서 어떤 타입의 오브젝트가 생성될 수 있는가와 함께 각각의 오브젝트 타입에 대한 룰 을 기술한 룰들의 집합니다.

스키마 디렉토리 파티션역시 전체 포레스트에 복제가 되나, 스키마 마스터의 룰을 가진 하나의 도메인 컨트롤러에서만전체 포레스트에서 쓰기 가능한 스키마 디렉토리 파티션의 복제본을 갖습니다.모든 변경은 스키마 마스터에서만 가능하며 전체 포레스트에 복제 되게 됩니다.

Global Catalog Partition

글로벌 카탈로그 파티션은 이전의 파티션과는 다른 센스로 봐야하는 파티션 입니다. 글로벌 카탈로그 파티션 역시 데이터베이스 파일에 저장되기는 하나 관리자는 해당 파티션의 정보에 대한 직접 접근을 할 수 없습니다. 글로벌 카탈로그 파티션의 모든 글로벌 카탈로그 서버상에 저장되는 읽기 전용 파티션이며, 이 정보는 도메인 데이터베이스의 일부 정보를 통해 생성됩니다. 각 어트리뷰트에는 isMemberOfPartialAttributeSet 이라는 불린값이 있는데 이 값이 True인 경우 해당 어트리뷰트는 글로벌 카탈로그 정보로써 복제 되게 됩니다.

Application Directory Partition

AD DS의 마지막 파티션은 Application Directory Partition 또는 Non-Domain Naming Context (NDAC) 입니다. 어플리케이션 디렉토리 파티션은 Application-specific 정보를 저장하는데 사용됩니다. 어플리케이션 디렉토리 파티션을 이용하는 이점 중 하나는 이 파티션의 리플리케이션 범위를 조정할 수 있다는 점입니다. 즉 특정 도메인컨트롤러들을 어플리케이션 디렉토리 파티션의 복제본을 갖도록 정의함으로서 복제 트레픽을 조정할 수 있습니다. 그리고 어플리케이션 디렉토리 파티션의 복제본에 대한 복제의 범위는 해당 포레스트의 도메인이 될수도 사이트가 될수도 있습니다.

최초에는 기본적으로 어떤 어플리케이션 디렉토리도 생성 되지 않습니다. 하지만 만약 DNS 설치를 선택한 경우 해당 도메인 컨트롤러는 2개의 어플리케이션 디렉토리 (ForestDnsZone, DomainDnsZone)이 DNS 서비스를 위하여 생성되게 됩니다.

기본값은 백업 대상과 백업 위치가 같은 위치일 경우 Backup이 실패하게 되는 것 입니다. 하지만 C:\에 시스템 상태 백업을 하고 싶다면 아래와 같이 해보세요.

- Workaround
HKLM\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\
Name : AllowSSBToAnyVolume
Type : DWORD
Value : 1

P2V 를 하게되면 Physical Server 의 MAC Address 까지 똑같이 복제된답니다.