오랜만에 Windows Kernel에 대한 블로그가 올라와서 정리를 해 보았습니다.

One Windows Kernel

https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/One-Windows-Kernel/ba-p/267142

Windows는 x86, x64, ARM, ARM64를 지원하고 예전에는 Itanium, PowerPC, DEC Alpha, MIPS를 지원할 정도로 다양한 하드웨어를 지원하고 Data center, Laptop, xbox, phone, IOT device를 지원할 정도로 다양한 SKU를 가지고 있습니다.

아래 이미지는 896 코어에 1792 개의 logical processor와 2TB RAM을 지원하는 Windows DataCenter 버전의 작업 관리자 이미지 입니다. (저도 이렇게 큰 장비를 본 적은 없습니다. 대형 장비 이지만 Windows 10을 쓰는 방법과 거의 유사하게 시스템을 관리할 수 있어 금방 적응할 수 있습니다.)

Windows refactoring 에 대해서 먼저 이야기 하고 있습니다. 다양한 SKU의 Windows을 동일한 DLL로 지원을 하지만 일부 코드를 다르게 구현할 수 있도록 API set (https://docs.microsoft.com/en-us/windows/desktop/apiindex/windows-apisets) 이라는 것을 만들었습니다. 예를 들면 kernel32.dll을 그대로 사용하면서 실제 구현은 다른 DLL에 되어 있는 것입니다. (저도 API set을 자세히 분석해 본 적은 아직 없어서 자세한 내용은 나중에 정리해 봐야 할것 같습니다.)

Kernel Components

Windows NT는 마이크로 커널 유형으로 되어 있습니다. (완전한 마이크로 커널은 아닙니다.) 코어 커널 모듈이 있고 실행부라는 영역이 커널에 존재 합니다. 커널은 스레드 디스패칭, 멀티프로세서 동기화, 하드웨어 예외 핸들링 등을 처리 하고 실행부에서는 IO, 객체 관리, 메모리 관리, 프로세스 서브 시스템 등을 담당합니다.

윈도우 컴포넌트의 크기를 코드수로 보면 아래와 같습니다. 역시 메모리가 가장 많은 코드를 가지고 있고 커널 순으로 이어집니다. 좀 더 자세한 내용을 학고 싶으면 Windows Internals 책을 구입해서 읽어보면 됩니다. 

Scheduler

스레드는 프로그램 코드가 실행되는 가장 기본 유닛으로 Windows 스케줄러가 스케줄 합니다. 윈도우 스케줄러는 스레드 우선순위에 따라서 높은 우선순위를 가진 스레드 부터 스케줄링 합니다. 스레드는 주어진 시간 (Quantum time) 동안 실행되고 다음 스레드가 실행됩니다. 만약 높은 우선순위를 가지고 있는 스레드가 계속 실행되고 있어서 낮은 우선 순위를 가지는 스레드가 실행될 기회를 얻지 못한다면 낮은 우선순위를 가진 스레드의 우선순위가 올라가게 됩니다. 

최초에 Windows 스케줄러는 하나의 레디큐를 가지고 있었습니다. 하지만 많은 프로세서를 지원하기 시작하면서 하나의 레디큐가 병목현상을 보이게 되었고 Windows Server 2003 에서 프로세서마다 하나의 레디큐를 가지게 디자인이 변경 되었습니다. 하나의 레디큐를 사용하면서 발생했던 글로벌 락 문제가 사라졌습니다. 가장 높은 우선순위를 가지는 스레드가 실행되는 것은 보장할 수 있지만 N 개의 core를 가지는 시스템에서 최대 N 개의 높은 우선순위를 가지는 스레드가 실행된다고 말 할 수는 없습니다. (현재 실행되는 스레드보다 높은 스레드가 다른 코어에 대기 상태로 있을 수 있습니다.) Windows가 laptop 이나 태블릿 같은 CPU 파워가 낮은 시스템에 적용되면서 UI가 느려지는 현상등이 발생하게 되었습니다. 그래서 Windows 8.1 에서 스케줄러가 프로세서당 레디큐를 가지는 것과 프로세서간 공유하는 레디큐를 가지는 하디브리드 형태로 변경 되었습니다. 다른 아키텍처의 변경이 있었기 때문에 스케줄로 변경으로 인한 성능 향상이 크게 보이지는 않았습니다.

Windows 7 에서 동적인 공정 공유 스케줄러 (Dynamic Fair Share Scheduler)가 도입되었습니다. 이 기능은 터미널 서버를 위해서 도입되었습니다. 하나의 터미널 세션이 과도한 CPU 자원을 사용해서 다른 터미널 세션에 영향을 주는 것을 방지하기 위해 도입 되었습니다. 기존의 스케줄링은 세션을 고려하지 않고 스레드 우선순위만 고려해서 스케줄링 했는데 이 기능이 도입 되어 다른 세션에 영향을 주지 않게 되었습니다. Linux의 Completely Fair Scheduler와 유사한 것 입니다. Windows 8 에서 이 개념이 스케줄러 그룹으로 일반화 되었고 각 세션마다 윈도우 스케줄러가 사용됩니다. 스케줄러 그룹은 스레드 우선순위에서도 2차 인덱스 역할을 해서 어떤 스레드가 다음에 실행될지를 결정 합니다. 터미널 세션에서 모든 스케줄러 그룹은 동일한 양의 스케줄링을 받게 됩니다. 그리고 Job 오브젝트가 향상되어 CPU rate control (https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_jobobject_cpu_rate_control_information) 기능을 지원하게되어 프로세스가 사용할 수 있는 CPU 양의 hard cap과 soft cap을 제한할수 있습니다. 이 기능은 리눅스의 cgroups 과 유사 합니다.

Windows 7 이후 부터 Windows 서버는 64개 이상의 프로세서를 지원하게 됩니다. 많은 프로세서를 지원하기 위해 프로세서 그룹 이라는 개념이 도입되었습니다. 프로세서 그룹은 최대 64개 까지의 프로세서를 하나의 그룹으로 묶어서 하나의 스케줄링 단위로 만드는 것으로 부팅하는 시점에 커널에서 어떤 프로세서가 어떤 그룹에 설정될지를 결정 합니다. (64개 이하의 코어를 가질 경우 프로세서 그룹은 적합하지 않습니다.) 단일 프로세스 (SQL Server)는 프로세서 그룹에 확장될 수 있으나 개별 스레드는 하나의스케줄링 그룹에서만 실행될 수 있습니다. (응용 프로그램이 프로세서 그룹이나 NUMA에 적합하지 않을 경우 BIOS에서 프로세서를 하나의 그룹으로 인식 시킬 수 있습니다.)

64개 이상의 코어를 가지는 시스템에서 코어 수를 늘렸을 때 SQL server와 같은 제품에서 성능 향상이 많이 일어나지 않는 것이 확인 되었습니다. 코어 수가 늘어나면 디스패처 락 문제 때문에 성능 향상에 문제가 있는 것이 확인 되었습니다. 디스패처 락은 디스패치가 되는 오브젝트를 보호하는 락으로 스레드, 타이머, I/O 완료 포트, 동기화 객체 등을 보호 합니다. Windows 7 에서 디스패처 락을 제거하고 객체 별 락을 도입하였고 290%의 성능 향상을 보였습니다. 

Windows 10 (Windows Server 2016)에서는 CPU Sets이 추가 되었습니다. CPU Set은 프로세스가 시스템을 나눠서 프로세스가 특정 프로세서 그룹을 사용할 수 있게하고 다른 프로세스나 시스템이 할당된 프로세서 그룹을 사용하지 못하게 하는 것 입니다. 프로세서가 CPU set으로 설정되면 디바이스의 코드도 실행되지 않습니다. Windows 10의 Game Mode가 이 기능을 사용한다고 합니다. (https://www.windowscentral.com/windows-10-game-mode)

그 외에도 ARM 관련 내용이 일부 있습니다. 

Scheduler 라는 것이 일반 사용자나 개발자 모두에게 잘 보여지지 않는 내용인데 블로그를 통해서 간단하게나마 소개가 되었습니다. 하지만 깊이 있는 내용은 문서를 찾기 힘들고 이해 하기가 힘들기 때문에 이정도에서 마무리 하려고 합니다.

최근에 VMware 제품인 ESXi를 공부해야할 필요가 생겨서 공부를 하면서 정리를 해 보았습니다. 이제 공부를 처음 시작하는 것이기 때문에 어떤 내용들을 정리할 수 있을지 정하지는 않았지만 최대한 많이 자료를 접하면 정리가 될 것 같습니다.

VMware world TA8245-ESXi Internals - Better Understanding for Better Management and Troubleshooting

https://www.youtube.com/watch?v=Qq3H3yIh5UQ&list=WL&index=6&t=0s

자료가 VMworld 2010 자료라 현재는 내용이 달라졌을 수 있습니다. 큰 그림은 바뀌지 않았으리라 생각하고 정리해 봅니다.

Olivier Cremel 이라는 VMware의 Principal Engineer가 발표를 하는데 Linkedin을 보니 Google로 갔다가 다시 VMware로 컴백을 했습니다.

Files & Filesystems

어떤 부트 디바이스일 경우에도 단일 부팅 이미지로 되어 있고 모든 내용이 메모리로 로드가 된다고 합니다. 그래서 부트 디바이스에 문제가 발생 하더라도 운영에 문제가 없다고 합니다. Windows의 경우에는 일부 시스템 이미지가 로드 되지 않은 상태이고 페이지 아웃 까지 가능해서 부팅 디바이스가 문제가 생가면 1분 안에 시스템이 크래시 됩니다. 아무래도 가상화 부분만 담당하기 때문에 좀더 안정적으로 만들 수 있었던것 같습니다. 

ESXi의 베이스 이미지는 압축되어 있고 메모리에 압축이 해제되어 로드가 됩니다. VIB (VMware Installation Bundles) 파일은 압축이 해제되지 않고 Tardisks 라는 방식으로 Mount 됩니다. (https://blogs.vmware.com/vsphere/2011/09/whats-in-a-vib.html)

/etc 디렉토리에 있는 파일들은 persisted state files 로 (esx.conf, inetd.conf) tardisk에 위치라며 sticky로 설정된다. /var/spool/cron/root/cronjobs 와 같은 파일등은 running state가 유지되지 않는다. persisted state file 들은 root filesystem에 마운트되고 메모리에서 유지 관리 됩니다.

Persistence 파일들을 변경 하려면 rebuild를 하고 부트 디바이스에 저장을 해야 합니다.

Diskless, Stateless가 가능 합니다. Diskless는 부팅 한 후 부트 디바이스를 사용하지 않는 것이고 Stateless는 state 정보가 ESXi 로 부터 얻어지지 않습니다.

Archive 에서 Tardsk로 파일이 올라갑니다. VisorFS에 대한 상세한 기술 문서는 VMware lab에 있는데 다음번에 정리를 해보고자 합니다. (https://labs.vmware.com/vmtj/visorfs-a-special-purpose-file-system-for-efficient-handling-of-system-images)

vdf, vdu 명령으로 tardisk 의 사용률을 볼 수 있습니다.

state file은 /etc/vmware/esx.conf 파일에 있고 기본 환경에서 실행한 명령은 /tmp.cmd.log, /var/run/cmd.pid 에 있고 로그 파일은 /var/log/vmkernel.log에 있습니다.

Ramdisk 는 32MB 정도의 크기를 가지는데 90~95% 정도의 사용률을 보입니다. 버그나 비정상적인 상황(TSM에서 큰 파일을 다운받기)를 하지 않는 경우 디스크가 full 되는 일은 없는데 Ramdisk가 full 되면 시스템이 불안정한 상태가 됩니다. 이 경우 문제점을 찾은 후 조치를 취하거나 /var/log 파일을 삭제 하거나 Ramdisk 크기를 조절해서 조치해야 합니다. (https://kb.vmware.com/s/article/2001550)

컴포넌트를 live system에 설치 하는 것은 Ramdisk를 마운트 하고 tardisk 이미지를 Ramdisk에 다운로드하고 tardisk를 마운트 하는 작업으로 적절한 크기의 메모리가 있어야 하며 overcommitted 된 시스템에서는 해서는 안된다고 합니다.

Esxi의 디스크와 Filesystem 구조는 다음과 같습니다.

Agents & Execution environment

코어 실행 모듈은 vmkernel 이고 코어 익스텐션은 kernel 모듈, 드라이버가 있습니다. Idle, helper, Driver 는 시스템 권한으로 실행됩니다. 유저 레벨 프로세스도 있는데 여기서 유저 레벨은 End user를 의미하는 것이 아니라 실행 권한이 시스템 레벨이 아니라는 것입니다.

Userworld에는 어떤 일이 있을 수 있을까요?

Out of memory가 발생하면 random 으로 userworld 프로세스를 종료 합니다.

메모리 부족 현상이 발생하면 ENOMEM이나 NULL이 되고 Exception 핸들러가 없이 크래시되거나 행이 됩니다.

다른 Userworld에는 영향이 없으며 리소소를 많이 사용한 모듈이 종료 됩니다.

CPU 부족 현상이 발생하면 Userworld가 느려 집니다.

Remote CLI나 PowerShell CLI의 첫 엔트리 포인트는 hostd 입니다. hostd가 응답하지 않을 경우 DCUI를 사용하여 네트워크, 에이전트 등을 확인합니다. 이마저도 동작하지 않은다면 VMware support에 연락을 하고 TSM을 Enable 한 후 문제 해결을 합니다.

Ramdisk를 파일을 저장하는 용도로 사용하지 않아야 합니다. root filesystem에서 변경한 내용은 재부팅이 되면 삭제 됩니다.

Userworld 의 리소스 풀에는 제약이 있어서 너무 많은 명령을 실행하면 에러가 발생할 수 있고 CPU를 많이 사용하는 명령은 CPU 제한 때문에 행 상태로 보일 수 있습니다.

Userworld 는 일반적인 용도를 위한 것이 아닙니다. ps 결과는 vmkernel 월드의 결과를 보여주고 vsortfs 는 vdf와 vdu를 사용해서 사용률을 확인해야 합니다. Debug VID를 설치해서 추가적인 Troubleshooting command를 실행할 수 있습니다.

OS internals: Technical deep-dive into operating system innovations - BRK3365

Microsoft Ignite 2018에서 OS internals를 설명하는 과정에서 DTrace 가 추가된다는 것이 발표 되었습니다. 아래 내용은 동영상 내용을 정리해본 것인데 기술적으로 자세히 다루지는 않았지만 많은 변경 사항을 보여준 것 같습니다.

12:23 - Dtrace on Windows, FreeBSD에서 포팅을 했다고 합니다. FBT, SYSCall, ETW를 사용하는 것으로 보입니다.

13:09 - traceext.sys, Dtrace.sys 드라이버가 캡처를 담당하는 것으로 보입니다. 현재는 커널 디버거가 필요 합니다.

17:40 - Dtrace를 사용해서 NamedPipe를 연결하지 못하는 문제를 Trace 합니다. MRxSmbFsdDispatch 에서 0xc0000033 가 발생했습니다.

20:00 - Dtrace를 사용해서 Process의 Profile, IO 등을 확인할 수 있습니다.

23:30 - GVFS를 사용해서 Git on Windows repository의 속도를 많이 향상할 수 있었습니다.

25:00 - WSL에 대해서 설명하고 있습니다.

31:00 - WSL의 코어인 lxcore.sys 드라이버에 대해서 설명 합니다. 커널 디버깅을 해서 fork가 어떻게 실행되는지 보여 줍니다.

37:00 - Hyper-V Container에 대해서 설명하고 있습니다. Lightweight VM의 Memory, Storage 에 대해서 설명 합니다.

45:38: - Container 프로세스의 Memory를 담당하는 vmmem 프로세스를 디버깅해서 자세히 설명 합니다.

47:50 - Container 프로세스의 이미지 파일이 VSMB를 통해서 매핑 되어 있는 것을 디버깅을 사용해서 설명 합니다.

54:28 - Virtualization Based Security 라는 가상화 기술을 이용한 보안 기법을 설명하고 있습니다.

1:05:28 - NVMe Storage에 대해서 설명하고 있습니다. Para-virtualized storage에 대해서 설명 합니다. 

1:08:00 - NVMe Direct 기술을 사용해서 Storage 성능을 올렸습니다. Intel의 APICv 기술이 사용되었다고 합니다.