深入了解 Windows Server 2008 内核变化

概览:
内存管理和 SMB 2.0
NTFS 自修复功能、Windows 硬件错误报告体系和驱动程序验证程序
I/O 完成端口、线程池和 NUMA 的可伸缩性
Hyper-V 虚拟化
Windows Server 2008 是最新版本的 Microsoft 服务器平台，它包含许多系统级更改，这些更改涉及操作系统的所有功能领域：从内存管理
到线程调度，从网络连接到安全（这里只列出了少数几个）。
由于 Windows Server 2008 和 Windows Vista SP1 的内核相同，因此它包含许多我曾经在之前的《TechNet 杂志》文章：“深入了解 Windows Vista 内核”第 1-3 部分（2007 年 2 月、3 月和 4 月）和“深入了解 Windows Vista 用户帐户控制”（2007 年 6 月）中介绍过的增强功能。只有其中的少数功能仅特定于客户端且并未包含在 Windows Server 2008 中，如 SuperFetch、ReadyBoost、ReadyDrive、ReadyBoot 和多媒体类计划程序服务 (MMCSS)。
因此，我将不再重复介绍 Windows Vista 中已介绍过且 Windows Server 2008 中同样包含的重要内核变化，如 I/O 优先级排列、新的引导体系结构 BitLockerTM、代码完整性和强制完整性级别。我将重点介绍之前这些文章中未涉及到的关键变化，包括与可靠性、性能、可伸缩性以及新的 Microsoft 管理程序计算机虚拟化技术 Hyper-VTM 相关的变化。
同样，与之前的文章一样，本文的范围仅限于操作系统内核 Ntoskrnl.exe 以及与其紧密关联的系统组件的变化。例如，本文不会介绍安装（WIM 或 Windows 映像格式和基于组件的服务）、管理（组策略和 Active Directory 改进）、常规诊断和监控（Windows 诊断基础结构）、核心网络（新的防火墙和 TCP/IP 实现）、Server Core 或服务器角色的变化。
用于多处理器系统
系统的其中一项底层变化是 Windows Server 2008 仅提供设计用于多处理器系统的内核版本。过去，Windows 拥有专门针对单 CPU 计算机上的单处理器的版本，因为该版本可通过忽略仅在多处理器环境下需要的同步代码来获得稍好一点的性能。随着硬件速度变得越来越快，由优化带来的性能提高几乎可忽略不计，并且如今的大多数服务器系统都包含多个处理器，所以已不再需要单处理器的内核版本。
图 1 显示了 Windows Server 2008 内核的各个版本，系统中具体使用哪个版本取决于操作系统是调试版本（Checked 版本）还是零售版本、安装为 32 位还是 64 位（Itanium、Intel 64 或 AMD64），以及如果是 32 位安装，系统的物理内存是否超过 4GB 或支持数据执行保护 (DEP)。Windows Server 2008 还可能是最后一个提供 32 位版本的 Windows Server 操作系统。

内核
32 位
64 位

多处理器
Y
Y

多处理器 Checked 版本
Y
Y

多处理器物理地址扩展 (PAE)
Y
N

多处理器 PAE Checked 版本
Y
N

Windows Server 的每个版本均注重改善服务器主要应用场合（如文件服务、网络 I/O 和内存管理）的性能。此外，Windows Server 2008 还包含许多变化和新功能，以使 Windows 能更好地利用新的硬件体系结构，适应高延迟网络并消除之前的 Windows 版本中限制性能的瓶颈。本部分将回顾内存管理器、I/O 系统方面的增强功能，并介绍新的网络文件系统 SMB 2.0。
内存管理
Windows Server 2008 中的内存管理器包含多项性能增强功能。例如，与 Windows Server 2003 相比，从分页文件提取数据或对映射文件执行预读 I/O 时，它将使用数量更少但规模更大的磁盘 I/O。I/O 系统中的变化是促成更大规模的文件 I/O 的前提，它去除了自 Windows NT 的第一个版本以来一直存在的 64KB 的 I/O 大小限制。
并且，必须注意：与 Windows Server 2003 相比，使用 Windows Server 2008 时，Cache Manager 从映射文件进行预读（猜测性读取）的数据读取通常要大两倍，并且将直接进入待机列表（系统的代码和数据缓存）。这种行为取代了 Cache Manager 映射虚拟内存并将数据读入系统工作集（由内存管理器为系统分配的内存）的需要，而这种需要可能导致其他使用中的代码或数据被不必要地驱出工作集。
当把数据写入分页文件时，内存管理器也会执行更大规模的 I/O。尽管 Windows Server 2003 常常执行比 64KB 还小的写入操作，但在 Windows Server 2008 中，内存管理器通常使用 1MB 的写入操作。
除通过减少写入分页文件的次数来提高性能外，较大规模的写入操作还可减少分页文件中的碎片。而它又反过来减少了读回多个页面所需的读取次数和磁盘寻道次数，因为如果不相邻，读取和寻道次数都会多得多。
内存管理器还会尝试写出其他已修改页面（这些页面与将要写出到所拥有进程的地址空间中的页面相邻），并且会将分页文件放到已包含其他相邻页面的区域中。这种方法也可尽量减少碎片并提高性能，因为那些可能会最终写出到分页文件中的页面均已被写入。此外，它还减少了引入大量相邻进程页面所需的分页读取次数。查看侧栏“试验：查看大规模的磁盘 I/O 操作”了解有关内存管理器使用大规模的 I/O 方面的更多信息。
SMB 2.0
自从文件服务功能被引入到 Windows 中以来，服务器消息块 (SMB) 远程文件系统协议（也称为通用 Internet 文件系统 (CIFS)）就已成为 Windows 文件服务的基础。在过去的几年中，SMB 的设计限制制约了 Windows 文件服务的性能和利用新的本地文件系统功能的能力。例如，单个消息能传输的最大缓冲区大小为约 60KB，并且 SMB 1.0 无法识别 Windows Vista 和 Windows Server 2008 中新增的 NTFS 客户端符号链接。
Windows Vista 和 Windows Server 2008 引入了 SMB 2.0，它是客户端和服务器都支持时 Windows 所使用的一种新型远程文件服务协议。除能正确处理客户端符号链接和其他 NTFS 增强功能外，SMB 2.0 还使用批处理来最小化客户端和服务器之间的信息交换数量。批处理可提高广域网 (WAN) 之类高延迟网络的吞吐量，因为它允许同时传输更多数据。
SMB 1.0 针对单个文件按顺序执行 I/O，而 SMB 2.0 则实现了 I/O 管道，从而可针对同一文件执行多个并发 I/O。它通过衡量客户端用于未完成 I/O 的服务器内存数量来决定管道的深度。
由于 Windows I/O 内存管理器和 I/O 系统以及 TCP/IP 接收窗口自动调节方面的变化和文件复制引擎的改进，SMB 2.0 显著提高了吞吐量并减少了大型传输的文件复制时间。由于两种操作系统都实现了 SMB 2.0，所以部署 Windows Server 2008 文件服务器和 Windows Vista 客户端即可使用 SMB 2.0 并实现这些性能优点。

使用 NTFS 自修复功能提高可靠性
可靠性是一个关键服务器属性，Windows Server 2008 提供各种改进来帮助管理员顺畅运行其服务器（包括在线 NTFS 一致性修复、新的硬件错误报告体系以及对驱动程序验证程序的扩展）。
由于现在使用的存储设备一般都以 TB 为单位，因此对某个卷进行脱机一致性检查可能会使服务中断数小时。鉴于许多磁盘损坏都局限于单个文件或部分元数据，Windows Server 2008 实现了新的 NTFS 自修复功能，即可在卷保持联机的情况下修复损坏。
当 NTFS 检测到损坏时，它将阻止访问受损的文件并创建一个系统工作线程，该线程将对受损数据结构执行类似 Chkdsk 的修复，完成后再允许访问修复后的文件。在此操作期间仍然可以正常访问其他文件，因而最小化服务中断。
WHEA 基础结构
Windows Server 2008 中包含有 Windows 硬件错误报告体系 (WHEA) 基础结构，它可以简化硬件故障管理并主动响应非致命错误。服务器通常都有严格的正常工作时间保证，因此及时确定并响应此类系统中的错误至关重要。
通过对利用在线崩溃分析 (OCA) 提交到 Microsoft 的崩溃进行分析表明：约 10% 的操作系统崩溃是源于硬件故障，但确定此类崩溃的根本原因却非常困难甚至于不可能，因为崩溃时所获取的硬件错误信息非常少。此外，在 Windows Server 2008 之前，Windows 并不内置支持监控设备的运行状况，也未实现故障前的修复或通知。其原因在于硬件设备并未使用一种通用的错误格式并且不支持错误管理软件。
WHEA 为各种平台设备（包括处理器、内存、缓存和类似 PCI 和 PCI Express 之类的总线）提供了统一的错误源发现和报告机制。其原理是实现图 2 中所示的体系结构，其中核心是错误源调用来报告错误的内核 API。此 API 要求所有错误都以同一方法进行格式化，然后使用 Windows 事件跟踪 (ETW) 事件来记录错误（严重错误则在重启后再记录）。

ETW 早在 Windows 2000 中就已引入，而当 ETW 使用 WHEA 后，硬件制造商和软件供应商就可轻松地开发利用 WHEA 事件的设备诊断管理应用程序。如果某事件已严重到足以导致系统崩溃，WHEA 会确保将该致命错误记录存储到崩溃转储文件中，这样管理员就可确定崩溃的根本原因。
WHEA 的另一关键部分是位于 %Systemroot%\System32\Pshed.dll 中的平台特定的硬件错误驱动程序 (PSHED)。内核与 PSHED 链接，而它与平台和固件硬件连接，实质上是用作错误通知和 WHEA 错误报告 API 之间的转换层。Microsoft 为每种平台体系结构（x86、x64、Itanium）提供有一种 PSHED 并且 PSHED 公开了插件模型，所以硬件供应商和制造商可使用特定于其平台的行为来覆盖默认行为。
最后，与其他错误源相连的系统组件 — 包括设备驱动程序、硬件抽象层 (HAL) 和内核 — 可实现底层硬件错误处理程序 (LLHEL)（它将首先处理错误状况）。LLHEL 的工作是从设备中提取错误信息，通知 PSHED 允许其收集其他平台错误信息，然后调用内核的 WHEA 错误报告 API。
[ 本帖最后由 云杉上的蝴蝶 于 2008-10-9 02:15 编辑 ]