[TechNET]Windows Server 2008

[퍼펙~!!]

Windows Server 2008 커널 변경 사항

Mark Russinovich

 

한 눈에 보기:

• 메모리 관리 및 SMB 2.0
• NTFS 자체 치유, Windows 하드웨어 오류 아키텍처 및 드라이버 확인 프로그램
• I/O 완료 포트, 스레드 풀 및 NUMA를 통한 확장성
• Hyper-V 가상화

Windows Server 2008은 Microsoft 서버 플랫폼의 최신 릴리스이며 여기에는 메모리 관리부터 스레드 예약, 네트워킹부터 보안에 이르는 운영 체제의 모든 기능 영역을 포괄하는

시스템 수준의 변경 사항이 포함됩니다.

Windows Server?? 2008은 Windows Vista?? SP1과 동일한 커널을 공유하기 때문에 필자의 이전 TechNet Magazine 기사인 "Windows Vista 커널 속으로" 1-3부(2007년 2월, 3월, 4월) 및 "Windows Vista 사용자 계정 컨트롤 들여다보기"(2007년 6월)에서 다룬, Vista의 향상된 기능 대부분이 Windows Server 2008에도 대부분 포함되어 있습니다. 이러한 기사에서 다룬 기능 중 SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot 및 MMCSS(Multimedia Class Scheduler Service)와 같은 일부 기능만 클라이언트 위주이고 Windows Server 2008에는 포함되어 있지 않습니다.

이 글에서는 I/O 우선 순위 지정, 새로운 부팅 아키텍처, BitLockerTM, 코드 무결성 및 필수 무결성 수준과 같이 Windows Vista에서 처음 적용되어 Windows Server 2008에도 포함된 중요한 커널 변경을 다시 살펴보는 것이 아니라 안정성, 성능, 확장성에 관련된 내용과 새로운 Microsoft 하이퍼바이저(hypervisor) 시스템 가상화 기술인 Hyper-VTM 같은, 이전 기사에서 다루지 않은 주요 변경 내용을 집중적으로 다룹니다.

또한 이전 기사와 마찬가지로, 이 기사의 범위는 운영 체제 커널인 Ntoskrnl.exe로 제한되며 시스템 구성 요소와 밀접한 관련이 있습니다. 예를 들어. 설치(WIM(Windows?? 이미징 형식) 및 구성 요소 기반 서비스), 관리(그룹 정책 및 Active Directory?? 향상 기능), 일반 진단 및 모니터링(Windows 진단 인프라), 핵심 네트워킹(새로운 방화벽 및 TCP/IP 구현), Server Core, 서비스 역할 등에 대한 변경 내용은 다루지 않습니다.

다중 프로세서 시스템 작업

시스템에 대한 저수준 변경 내용 중 하나는 Windows Server 2008에는 다중 프로세서 시스템에서 작동하도록 설계된 커널 버전만 포함된다는 점입니다. 과거 Windows에서는 다중 프로세서 환경에서만 필요한 동기화 코드를 생략함으로써 약간의 성능 향상을 얻을 수 있기 때문에 단일 CPU가 장착된 시스템의 단일 프로세서에 특정된 버전을 사용했습니다. 하드웨어 속도가 빨라짐에 따라 이러한 최적화로 인한 성능 이점은 무시해도 될 정도가 되었고 오늘날 서버 시스템에는 대부분 둘 이상의 프로세서가 장착되므로 단일 프로세서 버전이 필요 없게 되었습니다.

그림 1에서는 운영 체제가 디버그(Checked) 버전인지 정품 버전인지, 설치가 32비트인지 64비트(Itanium, Intel 64 또는 AMD64)인지, 32비트 설치인 경우에는 시스템에 4GB가 넘는 물리적 메모리가 있는지 또는 DEP(데이터 실행 방지)를 지원하는지 여부에 따라 시스템에서 사용되는 Windows Server 2008 커널 버전을 보여줍니다. Windows Server 2008은 32비트 버전이 제공되는 마지막 Windows Server 운영 체제가 될 것으로 예상됩니다.

 Figure 1 Windows Server 2008 커널 변형

커널	32비트	64비트
다중 프로세서	예	예
다중 프로세서 확인	예	예
다중 프로세서 PAE(물리적 주소 확장)	예	아니요
다중 프로세서 PAE 확인	예	아니요

Windows Server의 모든 릴리스는 파일 서비스, 네트워크 I/O 및 메모리 관리와 같은 주요 서버 시나리오의 성능 향상에 주력합니다. 또한 Windows Server 2008에는 새로운 하드웨어 아키텍처의 장점을 활용하고, 대기 시간이 긴 네트워크에 대처하고, 이전 버전 Windows에서 성능을 제한하는 병목 지점을 제거할 수 있는 몇 가지 변경 내용과 새로운 기능이 있습니다. 이 단원에서는 메모리 관리자, I/O 시스템의 향상된 기능과 새로 도입된 네트워크 파일 시스템인 SMB 2.0에 대해 살펴봅니다.

메모리 관리

실험: 대량 디스크 I/O 확인

TechNet Sysinternals Process Monitor(technet.microsoft.com/sysinternals/bb896645.aspx)와 같은 파일 시스템 모니터링 도구를 사용하여 Windows Server 2008 시스템의 대량 파일 I/O 작업을 살펴볼 수 있습니다.

대량 I/O를 생성하는 방법에는 몇 가지가 있습니다. Windows Vista 서비스 팩 1 또는 Windows Server 2008을 실행하는 보조 시스템이 있는 경우에는 서버에서 Process Monitor를 실행하고 보조 시스템으로 파일을 복사하여 그 결과를 모니터링할 수 있습니다. 또한 메모리 사용량이 많은 프로그램을 실행하여 메모리 관리자가 페이지를 외부 페이징 파일에 쓰도록 하여 대량 페이징 파일 I/O를 생성할 수 있습니다.

그림 A에서는 Windows XP 시스템에서 Process Monitor의 Options 메뉴에서 Enable Advanced Output 옵션을 선택하고 페이징 파일인 pagefile.sys에 대한 쓰기만 표시되도록 필터를 설정한 상태에서, 메모리 사용량이 많은 프로그램을 실행한 결과를 보여줍니다. Detail 열에는 쓰기의 크기가 64KB로 표시됩니다.

그림 A  (더 크게 보려면 이미지를 클릭하십시오.)

동일한 단계를 Windows Server 2008에서 실행하면 대부분 쓰기의 크기가 약 1MB로 표시되는 그림 B와 같은 화면이 표시되는 경우가 많습니다.

 

  그림 B  (더 크게 보려면 이미지를 클릭하십시오.)

메모리 관리자에는 Windows Server 2008의 몇 가지 성능 개선 사항이 포함됩니다. 예를 들어 페이징 파일에서 데이터를 가져오거나 매핑된 파일에서 미리 읽기 I/O를 수행할 때 Windows Server 2003보다 훨씬 많은 데이터를 한 번에 가져와 실행 횟수를 줄이는 디스크 I/O를 수행합니다. 이러한 대량 파일 I/O는 Windows NT??가 처음 릴리스된 이후부터 존재하던 64KB I/O 크기 제한을 제거하는 I/O 시스템 변경으로 인해 가능해졌습니다.

또한 Windows Server 2008의 경우 캐시 관리자가 매핑된 파일에서 미리 읽기(예측 읽기)를 위해 수행하는 데이터 읽기의 크기가 일반적으로 Windows Server 2003보다 두 배 이상 크며, 데이터 읽기가 대기 목록(시스템의 코드 및 데이터 캐시)에서 직접 수행된다는 점도 알아두어야 합니다. 이 기능 개선 덕분에, 캐시 관리자가 더 이상 가상 메모리를 매핑하거나 데이터를 시스템의 작업 집합(메모리 관리자가 시스템에 할당한 메모리)을 통해 읽기 위해 다른 사용 중인 코드나 데이터를 작업 집합에서 제거할 필요가 없어집니다.

또한 메모리 관리자가 데이터를 페이징 파일에 쓸 때 훨씬 큰 단위로 I/O를 수행합니다. Windows Server 2003에서는 64KB 미만의 쓰기가 수행되는 경우가 많지만 Windows Server 2008에서는 메모리 관리자가 일반적으로 1MB의 쓰기를 실행합니다.

쓰기 단위가 크면 페이징 파일에 대한 쓰기 횟수가 줄어들어 성능이 향상될 뿐만 아니라 페이징 파일 내의 단편화도 줄어듭니다. 단편화가 줄어든다는 것은 페이징 파일이 인접할 가능성이 높아진다는 의미이므로 여러 페이지에서 읽어야 하는 디스크 찾기 및 읽기 횟수도 줄어듭니다.

메모리 관리자는 소유 프로세스의 주소 공간에 기록 중인 것과 가까운 다른 수정된 페이지도 쓰기를 시도하며, 다른 인접 페이지가 이미 있는 페이징 파일 영역을 대상으로 사용하려고 시도합니다. 이런 기능 역시 단편화를 최소화하며, 페이징 파일에 기록하려는 페이지가 이미 기록된 경우도 있으므로 성능이 향상될 수 있습니다. 또한 인접 프로세스 페이지 범위에서 가져오는 데 필요한 페이징 읽기의 수도 줄어듭니다. 메모리 관리자의 대량 I/O 사용에 대한 자세한 내용은 보충 기사 "실험: 대량 디스크 I/O 확인"을 참조하십시오.

SMB 2.0

CIFS(Common Internet File System)라고도 하는 서버 메시지 블록(SMB) 원격 파일 시스템 프로토콜은 Windows에 파일 서비스 기능이 도입된 이래 Windows 파일 서비스의 기본으로 사용되었습니다. 하지만 SMB의 설계 제한으로 인해 지난 몇 년 동안 Windows 파일 서비스 성능과 새로운 로컬 파일 시스템 기능의 장점을 이용할 수 있는 기회가 제한을 받아왔습니다. 단일 메시지에서 전송할 수 있는 최대 버퍼 크기가 약 60KB인 것과 SMB 1.0이 Windows Vista와 Windows Server 2008에 추가된 NTFS 클라이언트측 심볼 링크를 인식하지 못하는 것 등이 이러한 제한의 예입니다.

Windows Vista와 Windows Server 2008에는 클라이언트와 서버 모두가 지원할 때 Windows에서 사용하는 새로운 원격 파일 서비스 프로토콜인 SMB 2.0이 채택되었습니다. SMB 2.0은 클라이언측 심볼 링크와 기타 NTFS의 향상된 기능을 올바르게 처리할 뿐만 아니라 일괄 처리는 사용하여 클라이언트와 서버 사이에 교환되는 메시지 수를 최소화합니다. 일괄 처리를 사용하면 더 많은 데이터를 동시에 전송할 수 있으므로 WAN과 같은 대기 시간이 긴 네트워크에서 처리량을 향상시킬 수 있습니다.

단일 파일에 대한 I/O를 순차적으로 실행하는 SMB 1.0과 달리, SMB 2.0에서는 I/O 파이프라인을 구현함으로써 같은 파일에 대한 여러 개의 동시 I/O를 실행할 수 있습니다. 또한 SMB 2.0은 클라이언트에서 사용하는 서버 메모리의 양을 측정하여 I/O를 향상시킬 수 있는 파이프라인 처리 수준을 결정합니다.

Windows I/O 메모리 관리자와 I/O 시스템의 변경, TCP/IP 수신 창 자동 조정, 파일 복사 엔진 기능 향상 등으로, SMB 2.0을 사용하면 대규모 전송에서 처리량이 크게 향상되고 파일 복사 시간이 단축됩니다. Windows Server 2008과 Windows Vista 운영 체제 모두 SMB 2.0을 지원하기 때문에 Windows Server 2008 파일 서버와 Windows Vista 클라이언트를 함께 배포하면 SMB 2.0을 사용하여 이러한 성능 이점을 현실화할 수 있습니다.

NTFS 자체 치유를 통한 안정성

안정성은 핵심적인 서버 특성입니다. Windows Server 2008에는 관리자가 서버를 원활하게 실행할 수 있도록 돕는 온라인 NTFS 일관성 복구, 새로운 하드웨어 오류 보고 인프라, 드라이버 확인 프로그램 확장 기능 등을 비롯한 다양한 향상된 기능이 제공됩니다.

오늘날에는 수 테라바이트에 달하는 저장 장치가 사용되므로 일관성 검사를 위해 볼륨을 오프라인으로 전환하면 몇 시간의 서비스 중단이 발생할 수 있습니다. 대부분의 디스크 손상은 단일 파일 또는 메타데이터의 일부로 국한되는 경우가 많기 때문에 Windows Server 2008에서는 볼륨을 온라인 상태로 유지하면서 손상을 복구하는 새로운 NTFS 자체 치유 기능을 구현합니다.

NTFS에서는 손상 감지 시 손상된 파일에 대한 액세스를 차단하고 Chkdsk와 같은 방식으로 손상된 데이터 구조를 수정하는 시스템 작업자 스레드를 만듭니다. 이 작업이 끝나면 복구된 파일에 액세스할 수 있습니다. 이 작업 도중에도 다른 파일에는 계속 액세스할 수 있으므로 서비스 중단이 최소화됩니다.

WHEA 인프라

Windows Server 2008에 포함된 Windows 하드웨어 오류 아키텍처(WHEA) 인프라는 하드웨어 오류 관리를 단순화하고 중대하지 않은 오류에 대한 예방적 대응을 가능하게 합니다. 서버에는 엄격한 가동 시간이 보장되어야 하는 경우가 많으므로 서버 시스템에서 오류를 시기적절하게 식별하고 조치하는 것은 매우 중요합니다.

OCA(Online Crash Analysis)를 통해 Microsoft에 제출된 충돌을 분석해 보면 운영 체제 충돌 중 약 10퍼센트는 하드웨어 실패로 인한 것이지만 충돌 시 캡처할 수 있는 하드웨어 제공 오류 정보가 충분하지 않기 때문에 이러한 충돌의 근본 원인을 파악하는 것이 어렵거나 불가능했습니다. 또한 Windows Server 2008 이전에는 Windows에서 장치 상태의 모니터링을 기본적으로 지원하지 않았으며 긴급한 실패의 해결이나 알림을 구현하지 않았습니다. 이러한 문제의 원인은 하드웨어 장치가 공통 오류 형식을 사용하지 않으며 오류 관리 소프트웨어에 대한 지원을 제공하지 않는다는 것에 있습니다.

WHEA는 프로세서, 메모리, 캐시 및 PCI나 PCI Express 등의 버스를 포함하여 플랫폼 장치에 대한 오류 원인 검색 및 보고를 위한 통일된 메커니즘을 제공합니다. 이를 위해 그림 2와 같은 아키텍처를 구현하며, 여기서 핵심은 오류 출처가 오류를 보고하기 위해 호출하는 커널 API입니다. 이 API는 모든 오류를 공통된 형식으로 보고하도록 요구하며, Windows용 이벤트 추적(ETW) 이벤트를 사용하여 오류를 기록합니다(심각한 오류는 다시 부팅한 후 기록됨).

 

 

그림 2 WHEA 오류 보고 인프라 (더 크게 보려면 이미지를 클릭하십시오.)

ETW는 Windows 2000에서 도입되었으며 ETW에서 WHEA를 사용함에 따라 하드웨어 제조업체와 소프트웨어 공급업체에서 WHEA 이벤트를 사용하는 장치 진단 관리 응용 프로그램을 쉽게 개발할 수 있게 되었습니다. 시스템 작동을 중단시킬 정도로 심각한 이벤트의 경우 WHEA는 관리자가 작동 중단의 근본 원인을 파악할 수 있도록 오류 기록을 크래시 덤프 파일에 저장합니다.

WHEA의 다른 핵심 부분은 플랫폼 관련 하드웨어 오류 드라이버(PSHED)인 %Systemroot%\System32\Pshed.dll. 커널은 PSHED와 연결되고, PSHED는 플랫폼 및 펌웨어 하드웨어에 인터페이스를 제공하여 오류 알림과 WHEA 오류 보고 API 사이의 전송 계층 역할을 합니다. 각 플랫폼 아키텍처(x86, x64, Itanium)별로 Microsoft 제공 PSHED가 있으며, PSHED는 하드웨어 공급업체 및 제조업체에서 자사의 플랫폼에 특정한 동작으로 기본 동작을 다시 정의할 수 있도록 플러그 인 모델을 제공합니다.

마지막으로 장치 드라이버, 하드웨어 추상화 계층(HAL) 및 커널을 비롯한 기타 오류 출처의 인터페이스를 제공하는 시스템 구성 요소는 초기에 오류 조건을 처리하는 LLHEL(Low-Level Hardware Error Handlers)을 구현할 수 있습니다. LLHEL의 역할은 장치에서 오류 정보를 추출하고, PSHED가 추가적인 플랫폼 오류 정보를 수집할 수 있도록 이를 알린 다음 커널의 WHEA 오류 보고 API를 호출하는 것입니다.

드라이버 확인 프로그램

Windows 2000 이후의 모든 Windows에는 버그가 있는 장치 드라이버와 결함이 발생한 하드웨어를 추적하기 위한 강력한 도구인 드라이버 확인 프로그램이 포함되어 있습니다. 일반적으로, 시스템 작동 중단의 원인인 것으로 의심되는 장치 드라이버의 동작을 자세히 모니터링하기 위해 관리자가 드라이버 확인 프로그램(%Systemroot%\System32\Verifier.exe)을 구성합니다. 드라이버 확인 프로그램은 문제가 있는 드라이버 동작을 기록하므로 크래시 덤프 파일에 문제가 발생한 부분이 직접 표시됩니다.

이전 드라이버 확인 프로그램 구현의 약점은 구성을 변경할 경우 대부분 시스템을 다시 시작해야 한다는 점입니다. 이것은 프로덕션 서버에서 바람직하지 않습니다. 하지만, Windows Server 2008의 드라이버 확인 프로그램 구현에서는 대부분의 유용한 확인 구성에서 시스템을 다시 시작할 필요가 없기 때문에 서버를 다시 시작하지 않고도 문제를 해결할 수 있게 되었습니다.

또한 드라이버 확인 프로그램에 그림 3에서 볼 수 있는 새로운 확인 기능이 도입되었습니다. Security checks(보안 확인)에서는 장치 드라이버가 응용 프로그램에 인터페이스를 제공하기 위해 사용하는 개체에 보안 권한을 설정했는지 확인합니다. Force pending I/O requests(강제 보류 I/O 요청)에서는 지연 후 완료되는 것이 아니라 즉시 완료되는 비동기식 I/O 작업에 대한 드라이버의 탄력성을 테스트합니다. 또한 Miscellaneous checks(기타 확인)에서는 사용 중인 리소스를 부적절하게 해제하거나, WMI(Windows Management Instrumentation) 등록 API를 부적절한 사용하거나, 리소스 핸들 누수가 발생하는 드라이버를 찾습니다.

 

 

그림 3 Windows Server 2008 옵션이 선택된 드라이버 확인 프로그램 (더 크게 보려면 이미지를 클릭하십시오.)

확장성

확장성은 운영 체제 또는 응용 프로그램이 여러 프로세스와 대용량 메모리를 효과적으로 이용할 수 있는 능력을 가리킵니다. Windows는 릴리스될 때마다 다중 프로세서의 병렬 처리 능력을 감소시키는 잠금 사용을 최소화하거나 제거하여 확장성을 향상시켜 왔으며 Windows Server 2008도 예외는 아닙니다.

타이머 만료를 실행하는 코드에서 상대적으로 소규모이지만 중요한 기능이 향상되었습니다. 즉, 모든 저수준 동기화 작업에 사용되는 발송자 잠금, 시스템 전체 스케줄러 잠금을 더 이상 요구하지 않게 되었습니다. 그 결과 CPU 동기화 오버헤드가 감소되어 Windows Server 2008 터미널 서버 시스템에서는 Windows Server 2003에 비해 약 30퍼센트 많은 동시 사용자를 지원합니다.

Windows Server 2008의 다른 확장성 향상 기능에는 완료 포트 향상, 새로운 스레드 풀 구현, NUMA(Non-Uniform Memory Access) 하드웨어의 보다 효율적인 활용, 동적 시스템 분할 등이 포함됩니다.

향상된 I/O 완료 포트 처리

IIS, SQL Server?? 및 Exchange Server를 비롯한 대부분의 확장 가능한 Windows 서버 응용 프로그램은 I/O 작업 실행 시 여러 실행 스레드 간의 전환을 최소화하기 위해 완료 포트라고 하는 Windows 동기화 API를 사용합니다. 이를 위해 우선 웹 서버 클라이언트 연결과 같은 새 요청의 수신 알림을 완료 포트와 연결하고 알림을 대기할 전용 스레드 풀을 지정합니다. 요청이 수신되면 Windows에서는 스레드를 예약하고 그런 다음 일반적으로 디스크에서 웹 페이지 읽기와 같은 다른 I/O 작업을 실행하여 이를 클라이언트로 전송하여 요청을 완료합니다.

따라서 한 스레드가 최대한 빠르게 반환되어 더 많은 클라이언트 요청을 대기하게 되며 스레드는 I/O를 비동기적으로 실행하고 I/O 완료를 완료 포트와 연결합니다. 그런 다음 스레드가 완료 포트에서 대기하는 상태로 반환되어 새 요청이 수신되거나 I/O 중 하나가 완료될 때 해당 스레드가 예약됩니다. 이 방법을 통해 동일한 스레드가 CPU에서 활성 상태를 유지하면서 클라이언트 요청 처리와 완료 포트 대기를 교대로 수행할 수 있습니다.

이전 Windows 릴리스의 완료 포트 구현에 있어 단점은, I/O 완료 시 I/O 시스템에서 스레드의 작업 종류에 관계없이 I/O를 실행한 스레드가 즉시 소규모의 완료 처리를 수행해야 한다는 것입니다. 이 때문에 다른 스레드가 활성화되어 있으면 스케줄러가 활성 스레드를 선점하고 발행자에게 컨텍스트를 전환하는 경우가 많았습니다.

Windows Server 2008에서는 완료 처리를 I/O가 연결된 완료 포트에서 대기 중인 다음 스레드로 연기하여 이러한 컨텍스트 전환을 방지합니다. 따라서 다른 스레드가 완료 포트에서 대기 중이더라도 다른 코드를 실행하기 전에 완료 처리를 수행할 수 있으며 스케줄러가 실행 스레드로 전환할 필요가 없습니다. 이렇게 컨텍스트 전환이 최소화되므로 작업 부하가 큰 서버 응용 프로그램의 확장성을 크게 향상시킬 수 있습니다.

더 효율적인 스레드 풀

다중 CPU를 활용하는 응용 프로그램을 작성하는 것이 어려울 수 있기 때문에 Windows XP에서는 작은 단위의 여러 작업을 여러 CPU에서 실행하는 세부 과정을 추상화하는 관련 API와 인프라인 작업자 스레드 풀을 도입했습니다. 응용 프로그램은 스레드 풀 API에 작업 항목을 지정한 다음, 시스템의 각 CPU별로 생성하고 관리하는 스레드 중 하나에서 이를 실행합니다.

스레드 풀의 목표는 동일한 스레드를 사용하여 여러 작업 항목을 연속적으로 실행함으로써 컨텍스트 전환을 최소화하는 것입니다. 스레드 중 하나가 이미 다른 작업을 수행 중이어서 이런 실행이 불가능한 경우에는 다른 CPU의 다른 스레드를 사용하여 작업 항목을 실행합니다.

Windows Server 2008 스레드 풀 구현에서는 완료 포트 향상에서 발생하는 간접적인 기능 개선과 스레드 관리를 최적화하여 응용 프로그램의 작업 부하를 처리해야 할 때 작업자 스레드를 동적으로 가져와 실행할 수 있다는 직접적인 기능 개선을 통해 CPU를 더 효율적으로 이용합니다. 또한 인프라의 코어가 커널 모드로 이동되었기 때문에 API를 사용하는 응용 프로그램의 시스템 호출 수가 최소화됩니다. 마지막으로, 새로운 API를 사용하면 응용 프로그램에서 응용 프로그램 종료 중 대기열에 있는 작업 단위의 취소와 같은 특정 작업을 더 쉽게 수행할 수 있습니다.

NUMA 최적화

Windows Server 2003에서 처음 스레드 스케줄러와 메모리 관리자의 NUMA 시스템이 최적화되었습니다. Windows Server 2008에서는 I/O 관리자에 NUMA 최적화가 추가되었으며 메모리 관리자의 NUMA 최적화가 확장되었습니다.

NUMA 시스템은 일반적으로 메모리에 액세스하는 프로세스에 따라 각 메모리의 대기 시간이 달라지는 다중 프로세서 시스템입니다(그림 4 참조). 메모리는 노드로 나뉩니다. CPU와 노드 간 대기 시간은 다를 수 있고 각 CPU는 가장 빠르게 액세스할 수 있는 노드로 간주됩니다.

 

그림 4 예제 NUMA 시스템 (더 크게 보려면 이미지를 클릭하십시오.)

NUMA 시스템, 특히 8개 이상의 CPU가 장착된 시스템은 균일한 메모리 액세스 시스템보다 비용 및 성능 면에서 더 효율적인 경우가 많습니다. 균일 메모리 액세스 시스템에서는 모든 CPU가 동등에게 메모리를 사용할 수 있어야 하지만 NUMA 시스템에서는 CPU에 직접 연결되는 메모리에 대해서는 고속 상호 연결을 구현할 수 있으며 CPU와 간접적으로 연결되는 메모리에 대해서는 더 높은 대기 시간을 가지지만 더 저렴한 연결을 구현할 수 있습니다.

NUMA 시스템에서 효율적인 확장을 위해서는, 계산에 사용되는 데이터 및 코드가 포함된 메모리 근처에서 계산이 실행될 수 있도록 운영 체제나 응용 프로그램에 노드 토폴로지를 인식하는 기능이 있어야 합니다. 예를 들어 Windows 스케줄러는 스케줄러가 항상 스레드 실행을 시도하는 CPU인 소위 말하는 이상적인 프로세서에 각 스레드를 할당합니다. 이렇게 하면 스레드가 CPU의 캐시에 넣는 데이터를 스레드가 실행될 때마다 사용할 수 있게 될 가능성이 높아집니다.

Windows Server 2003에서 스케줄러는 이상적 프로세서가 포함된 노드를 스레드의 이상적 노드로 간주함으로써 이 개념을 확장하고 이상적 프로세서가 다른 스레드를 실행 중인 경우 이상적 노드의 다른 CPU에서 스레드를 예약하려고 시도합니다. Windows Server 2003 메모리 관리자도 NUMA를 인식하고 가능한 경우 스레드의 메모리 할당을 스레드가 실행 중인 노드의 메모리로 전달합니다.

Windows Server 2008에서는 메모리 관리자가 커널의 비페이징 메모리 버퍼(RAM에 유지되어야 하는 데이터를 저장하기 위해 커널 및 장치 드라이버에서 사용하는 메모리)를 여러 노드에 분산시켜 할당을 요청한 노드의 메모리에서 할당이 이루어지도록 합니다. 할당에서 새 페이지 테이블 페이지를 필요로 하는 경우 Windows Server 2003에서처럼 할당이 임의의 노드에서 이루어지는 것이 아니라 할당이 요청된 노드에서 시스템 PTE(페이지 테이블 항목)가 할당됩니다.

Windows Server 2003에서 스레드가 메모리를 할당할 때 메모리 관리자는 할당 시 스레드가 실행 중인 노드를 우선적으로 사용합니다. 스레드가 일시적으로 비이상적인 노드로 예약된 경우에는 해당 시간 동안 수행된 모든 할당은 비이상적인 노드에서 이루어집니다. 따라서 그 이후에 스레드가 스레드의 이상적인 노드에서 실행되어도 노드가 할당된 메모리에 저장된 데이터나 코드에 가깝지 않게 됩니다.

이를 해결하기 위해 Windows Server 2008 메모리 관리자는 스레드가 다른 노드에 가깝게 실행되더라도 모든 스레드의 할당에 대한 스레드의 이상적 노드를 우선적으로 사용합니다. 또한 메모리 관리자는 프로세서와 노드 사이의 대기 시간을 자동으로 인식하기 때문에 이상적인 노드에 가용 메모리가 없으면 다음으로 이상적인 노드에 가장 가까운 노드를 검사합니다. 메모리 관리자는 스레드가 코드 또는 데이터를 참조할 때 대기 목록의 페이지를 스레드의 이상적인 노드로 마이그레이션합니다.

할당의 지역성을 제한하고자 하는 응용 프로그램에서는 메모리 할당, 파일 매핑 보기 및 파일 매핑 개체에 대한 기본 노드를 지정할 수 있도록 해주는 새 NUMA 메모리 API를 사용할 수 있습니다. 파일 매핑에 관련된 할당의 경우 메모리 관리자는 매핑 작업이 노드를 지정하는지 검사한 다음 파일 매핑 개체가 이를 지정하는지 검사하고, 마지막으로 둘 모두에 해당하지 않으면 스레드의 이상적인 노드를 사용합니다.

Windows Server 2008 이전에는 저장소 또는 네트워크 I/O에 대한 인터럽트 및 관련 DPC(지연 프로시저 호출)는 I/O가 시작된 CPU와 다른 노드에 있는 CPU를 비롯한 모든 CPU에서 실행될 수 있으므로 I/O 작업에서 읽거나 쓴 데이터가 해당 데이터를 액세스한 것과 다른 노드의 메모리에 위치할 가능성이 있습니다.

이를 피하기 위해 Windows Server 2008 I/O 시스템에서는 DPC 실행을 I/O를 시작한 노드의 CPU로 전달하고, PCI 버스 MSI-X(Message Signaled Interrupt 표준의 확장)를 지원하는 장치가 있는 시스템은 Windows Server 2008 API의 장점을 이용하여 I/O의 인터럽트를 I/O를 시작한 프로세스로 전달하는 장치 드라이버를 사용하여 I/O 완료를 더 지역화할 수 있습니다.

동적 분할

시스템의 확장성을 높일 수 있는 한 가지 방법은 CPU와 메모리 등의 하드웨어의 동적 추가를 지원하는 것입니다. 또한 이러한 리소스를 시스템을 다시 부팅하지 않고 교체할 수 있다면 시스템 가용성을 더 높일 수 있습니다.

Windows Server 2003에는 상시 메모리 추가 기능이 포함되어 있으므로 동적 메모리를 지원하는 서버에 관리자가 RAM을 추가하면 이를 사용할 수 있습니다. Windows Server 2008에서는 메모리 교체도 허용함으로써 동적 메모리 지원이 더욱 확장됩니다.

RAM에서 ECC(오류 보정 코드) 보정 의존도가 높아질수록 오류가 발생할 위험성도 커지기 때문에, 상시 교체가 지원되는 서버의 경우 Windows Server 2008에서는 오류가 발생한 메모리 뱅크의 데이터를 서버에 영향을 주지 않고 교체 메모리로 마이그레이션할 수 있도록 지원합니다. 이를 위해 운영 체제의 제어 하에 있는 데이터를 먼저 마이그레이션한 다음 하드웨어 장치를 저전력 상태로 전환하여 실제로 하드웨어 장치를 종료한 다음 나머지 메모리 데이터를 마이그레이션하고 장치에 다시 전원을 공급하여 정상 작동하도록 합니다.

Windows Server 2008에서는 프로세서의 상시 추가 및 상시 교체도 지원합니다. 상시 교체를 사용하려면 기존 CPU에서 오류가 발생할 경우 온라인 상태로 만들거나 동적으로 추가할 수 있는 예비 CPU 기능을 지원하는 하드웨어가 있어야 합니다. 현재 이러한 하드웨어는 고급 시스템에서만 사용할 수 있습니다. Windows Server 2008 스케줄러는 오류가 발생한 CPU의 활동을 늦추고 작업을 교체 CPU로 마이그레이션합니다. 그런 다음에는 오류가 발생한 CPU를 제거하고 새 예비 CPU로 교체합니다.

Windows Server 2008에서는 상시 프로세서 추가를 지원하기 때문에 관리자는 중단 시간 없이 서버의 처리 성능을 업그레이드할 수 있습니다. 하지만 일부 응용 프로그램은 CPU의 수가 부팅 세션에 고정되어 있다는 가정 하에 빌드되기 때문에, 스케줄러 및 I/O 시스템에서는 새 API를 통해 CPU 추가 알림을 받을 수 있는 장치 드라이버와 응용 프로그램에서만 새 CPU를 사용할 수 있게 만듭니다. 예를 들어 응용 프로그램이 각 CPU에 해당하는 작업 대기열 배열을 할당하고, 스레드는 실행 중인 CPU와 연결된 대기열을 사용할 수 있습니다. 스케줄러가 응용 프로그램의 스레드 중 하나를 새 CPU에 할당하면 응용 프로그램에서 존재하지 않는 대기열을 시도하고 참조하게 되어 데이터가 손상되고 응용 프로그램이 중단될 수 있습니다.

SQL Server 및 Exchange Server와 같은 Microsoft 서버 기반 응용 프로그램은 시스템 프로세스, 세션 관리자(%SystemRoot%\System32\Smss.exe) 및 Generic Service Hosting 프로세스(%Systemroot%\System32\Svchost.exe)를 포함한 몇 가지 핵심 Windows 프로세스와 마찬가지로 CPU 추가 기능을 지원합니다. 다른 프로세스 역시 Windows API를 사용하여 새 CPU 추가 알림을 요청할 수 있습니다. 새 CPU가 추가되면 Windows는 장치 드라이버에 예정된 추가를 알리고, CPU를 시작하고, 새 CPU의 장점을 활용하도록 작성된 응용 프로그램과 장치 드라이버에 이를 알려서 필요한 경우에 데이터 구조를 새 CPU의 추적 활동에 추가하도록 합니다.

시스템 가상화

Windows Server 2008 이전에는 Virtual Server 2005를 포함한 Microsoft 가상화 제품이 그림 5와 같은 호스팅 기반 가상화를 사용하여 구현되었습니다. 호스팅 기반 환경에서 가상 컴퓨터는 호스트 운영 체제와 함께 실행되는 VMM(Virtual Machine Monitor)에 의해 구현되었으며, 이 VMM은 대개 장치 드라이버로 동작합니다. VMM은 호스트 운영 체제의 리소스 관리 및 장치 드라이버에 의존하며 호스트 운영 체제에서 실행이 예약된 경우 시분할을 통해 활성 VM(가상 컴퓨터) 간에 CPU를 제공합니다.

 

그림 5 호스팅 기반 컴퓨터 가상화 (더 크게 보려면 이미지를 클릭하십시오.)

이전 코드명이 "Viridian"이었던 Hyper-V는 하이퍼바이저 가상화를 사용하여 구현됩니다. 하이퍼바이저는 그림 6에서처럼 모든 하드웨어 리소스에 대한 전체 제어권을 가지며, 시스템을 부팅하고 VM을 제어하는 Windows Server 2008 운영 체제도 기본적으로 가상 컴퓨터에서 실행됩니다.

 

 

그림 6 Hyper-V 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)

 

하이퍼바이저는 시스템을 여러 VM으로 나누고 Windows Server 2008의 부팅 인스턴스를 마스터 또는 루트 파티션으로 취급하므로 디스크, 네트워킹 어댑터 및 그래픽 프로세서 등의 하드웨어 장치에 직접 액세스할 수 있습니다. 하이퍼바이저는 루트에서 전원 관리를 수행하고 하드웨어 플러그 앤 플레이 이벤트에 응답한다고 가정합니다. 하이퍼바이저는 자식 파티션에서 시작된 하드웨어 장치 I/O를 가로채어 루트로 라우팅하며, 루트에서는 표준 Windows Server 2008 장치 드라이버를 사용하여 하드웨어 액세스를 수행합니다. Hyper-V를 실행하는 서버는 이런 방식으로 Windows의 하드웨어 장치 지원을 완벽하게 이용할 수 있습니다.

Windows Server 2008을 Hyper-V 서버 역할로 구성하면 Windows에서 hypervisorimagelaunchtypeboot BCD(부팅 구성 데이터베이스) 설정을 auto로 설정하고 Hvboot.sys 장치 드라이버가 부팅 프로세스의 초기 단계에 시작되도록 구성합니다. 옵션을 구성하면 Hvboot.sys는 가상화에 적합하게 시스템을 준비한 다음 시스템이 AMD-V 또는 Intel VT CPU 가상화 확장 중 무엇을 구현하는지에 따라 각각 %Systemroot%\System32\Hvax64.exe 또는 %Systemroot%\System32\Hvix64.exe를 메모리로 로드합니다.

로드된 후에는 하이퍼바이저가 가상화 확장을 사용하여 자신을 Windows Server 2008 아래에 삽입합니다. 사용자 모드 응용 프로그램은 x64 프로세서의 Ring 3 권한 수준을 사용하고 커널 모드 코드는 Ring 0 권한 수준에서 실행되므로, 개념적으로 하이퍼바이저는 -1 Ring 권한 수준에서 작동하며 이를 통해 Ring 0에서 실행 중인 코드의 실행 환경을 제어할 수 있습니다.

Hyper-V 관리 콘솔을 사용하여 자식 파티션을 만들거나 시작하면, 해당 파티션은 %Systemroot%\System32\Drivers\Winhv.sys 드라이버를 사용하여 하이퍼바이저와 통신합니다. 이 드라이버는 문서화되어 공개된 Hypercall API를 사용하여 하이퍼바이저가 지정된 물리적 메모리 크기 및 실행 특성을 가지는 새 파티션을 만들도록 지시합니다. 루트 안의 VM 서비스(%Systemroot%\System32\Vmms.exe)가 각 자식 파티션에 대한 VM 작업자 프로세스(%Systemroot%\System32\Vmwp.exe)를 만들어서 자식의 상태를 관리합니다.

Windows에서 자식 VM 운영 체제의 성능을 높이는 방법 중 한 가지는, 운영 체제가 Microsoft Hypercall API를 구현하는 하이퍼바이저를 통해서 실행 중일 때에만 활성화되는 코드 시퀀스를 Windows Server 2008과 Windows Vista 모두에서 구현하여 하이퍼바이저를 인식할 수 있도록 개선(이러한 자각 기능을 enlightment라고 함)하는 것입니다. 자식 VM은 하이퍼바이저의 서비스를 직접 요청함으로써 하이퍼바이저가 자식 운영 체제의 의도를 추측해야 할 경우 발생할 수 있는 가상화 코드 오버헤드를 방지합니다.

예를 들어 저수준 다중 프로세스 동기화를 실행하는 스핀록(spinlock)을 인식하기 위한 기능을 구현하지 않은 게스트 운영 체제는 다른 가상 프로세서에 의해 스핀록이 해제될 때까지 조밀한 루프에서 대기 상태로 스핀합니다. 이러한 스핀은 하이퍼바이저가 두 번째 가상 프로세서를 예약할 때까지 하드웨어 CPU 중 하나를 묶어둘 수 있습니다. 자각 기능이 구현된 운영 체제의 경우 스핀록 코드는 스핀이 발생할 수 있을 때 Hypercall을 통해 하이퍼바이저에 통보하여 하이퍼바이저가 즉시 다른 가상 프로세서를 예약하고 불필요한 CPU 사용을 줄일 수 있도록 합니다.

Windows Server 2008에서 VM 성능을 향상시키는 다른 방법은 장치에 대한 VM 액세스를 가속화하는 것입니다. 통틀어 "VM 통합 구성 요소"라고 하는 구성 요소 모음을 자식 운영 체제에 설치하여 성능을 향상시킵니다.

통합 구성 요소를 설치하지 않고 VM을 실행하면 자식 운영 체제는 하이퍼바이저가 제시하는 에뮬레이션된 장치에 대한 하드웨어 장치 드라이버를 구성합니다. 자식 VM의 운영 체제 대신 표준 Windows 장치 드라이버를 사용하여 장치 I/O를 수행하는 루트 파티션에 알리기 위해서는 장치 드라이버가 하드웨어 리소스에 접촉하려고 할 때 하이퍼바이저가 개입해야 합니다. 디스크 읽기와 같은 단일 고수준 I/O 작업에는 많은 별도의 하드웨어 액세스가 관여할 수 있기 때문에 하이퍼바이저와 루트 파티션에 인터셉트라고 하는 전환이 여러 개 발생할 수 있습니다.

Windows Server 2008에서는 가상 컴퓨터 버스 드라이버(%Systemroot%\System32\Drivers\Vmbus.sys), 가상 서비스 클라이언트(VSC) 및 가상 서비스 공급자(VSP)의 세 구성 요소를 사용하여 인터셉트를 최소화합니다. 지원 운영 체제의 VM에 통합 구성 요소를 설치하면 VSC가 장치 드라이버의 역할을 넘겨받고 자식 VM에서 Vmbus.sys 드라이버의 서비스를 사용하여 하이퍼바이저의 Hypercall 및 메모리 공유 서비스를 통해 루트 파티션에 있는 가상 컴퓨터 버스 드라이버로 고수준 I/O 요청을 전송합니다. 루트 파티션에서는 Vmbus.sys가 요청을 해당 VSP로 전달하며 그런 다음 루트의 장치 드라이버를 통해 표준 Windows I/O 요청이 초기화됩니다.

여기서 볼 수 있듯이 Windows Server 2008에는 Hyper-V 하이퍼바이저 기반 가상화가 도입되어 Microsoft 시스템 가상화 전략에서 핵심적 역할을 합니다. 이 주제와 다른 기능에 대한 자세한 내용은 올해 말 출간 예정인 필자의 책 Microsoft Windows Internals 개정판을 참조하십시오.

Mark Russinovich는 Microsoft 플랫폼 및 서비스 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 Microsoft TechEd, Professional Developer's Conference 등의 IT 및 개발자 컨퍼런스에서 단골 연설자로 활동하고 있습니다. Mark Russinovich는 Microsoft에서 인수한 Winternals Software의 공동 설립자이며 Process Explorer, Filemon 및 Regmon 유틸리티와 같은 많은 유명 유틸리티를 배포한 Sysinternals를 설립하기도 했습니다.

 

출처 : http://technet.microsoft.com/ko-kr/magazine/cc194386.aspx

[SES]

허걱....우선은 길다...ㅡㅡ;;;; 나중에 시간내서 천천히 읽어볼꼐요...^^