Cobertura especial: Windows Server 2008
Cambios del kernel de Windows Server 2008
Mark Russinovich
Resumen:
- Administración de la memoria y SMB 2.0
- Recuperación automática de NTFS, arquitectura de errores de hardware de Windows y el comprobador de controladores
- Escalabilidad con puertos de terminación de E/S, grupos de subprocesos y NUMA
- Virtualización Hyper-V
Windows Server 2008 es la última versión de la plataforma de servidor de Microsoft, e incluye cambios al nivel de sistema que abarcan todas las áreas funcionales del sistema operativo, desde la administración de la memoria
hasta la programación de subprocesos, desde las funciones de red hasta la seguridad, por nombrar algunas.
Debido a que Windows Server® 2008 comparte el kernel de Windows Vista® SP1, incluye muchas de las mejoras que vimos en mis artículos anteriores de TechNet Magazine: "Dentro del kernel de Windows Vista", partes 1-3 (febrero, marzo y abril de 2007) y "Estudio del Control de cuentas de usuario de Windows Vista" (junio de 2007). Sólo algunas de las características que describí en estos artículos se centran exclusivamente en el cliente y no se incluyen en Windows Server 2008, como SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot y el Servicio Programador de aplicaciones multimedia (MMCSS).
En lugar de repetir el alcance de los cambios importantes del kernel introducidos en Windows Vista que se encuentran también en Windows Server 2008, como el establecimiento de prioridades de E/S, la nueva arquitectura de arranque, BitLockerTM, la integridad del código y los niveles obligatorios de integridad, me voy a centrar en los cambios clave que no cubrí en dichos artículos, incluidos los relacionados con la confiabilidad, el rendimiento, la escalabilidad y la nueva tecnología de virtualización de equipos de hipervisor de Microsoft, Hyper-VTM.
Además, como en los artículos anteriores, el ámbito de este queda restringido al kernel del sistema operativo, Ntoskrnl.exe, y a los componentes del sistema asociados estrechamente. No cubre los cambios en la instalación (WIM, o formato Windows® Imaging, y el Modelo de servicio basado en componentes), la administración (mejoras en Active Directory® y la directiva de grupo), diagnósticos y supervisión generales (Infraestructura de diagnóstico de Windows), funciones de red básicas (el nuevo firewall y la implementación TCP/IP), Server Core ni las funciones de servidor, por ejemplo.
Uso de sistemas multiprocesador
Uno de los cambios de bajo nivel en el sistema es que Windows Server 2008 sólo incluye una versión del kernel diseñada para funcionar en sistemas multiprocesador. En el pasado, Windows usaba una versión específica a monoprocesadores en equipos con una sola CPU porque esta versión podía lograr un rendimiento ligeramente superior al omitir el código de sincronización necesario sólo en entornos de multiprocesador. Con la aceleración del hardware, las ventajas de rendimiento de las optimizaciones se vuelven insignificantes, y la mayoría de los sistemas de servidor actuales incluyen más de un procesador, lo que convierte en innecesaria una versión monoprocesadora.
La Figura 1 muestra las variantes del kernel de Windows Server 2008, donde la versión usada en un sistema depende de si es la versión depurada (comprobada) o la versión a la venta del sistema operativo, si la instalación es de 32 bits o de 64 bits (Itanium, Intel 64 o AMD64) y, si es una instalación de 32 bits, si el sistema tiene más de 4 GB de memoria física o es compatible con la Prevención de ejecución de datos (DEP). Windows Server 2008 es también el último sistema operativo de Windows Server que ofrecerá una versión de 32 bits.
Figure 1 Variantes del kernel de Windows Server 2008
| Kernel | 32 bits | 64 bits |
| Multiprocesador | Sí | Sí |
| Multiprocesador comprobado | Sí | Sí |
| Multiprocesador con extensión de dirección física (PAE) | Sí | No |
| Multiprocesador PAE comprobado | Sí | No |
Cada lanzamiento de Windows Server se centra en mejorar el rendimiento de escenarios de servidor clave, como el servicio de archivos, E/S de red y la administración de memoria. Además, Windows Server 2008 tiene varios cambios y características nuevas que permiten a Windows aprovechar las arquitecturas de hardware nuevas, adaptarse a redes de alta latencia y eliminar los cuellos de botella que limitaban el rendimiento en versiones anteriores de Windows. Esta sección revisa las mejoras en el administrador de memoria, el sistema de E/S y la introducción del nuevo Network File System, SMB 2.0.
Administración de memoria
Experimento: Detección de E/S de disco grandes
Puede usar una herramienta de supervisión del sistema de archivos como el monitor de procesos de Sysinternals de TechNet (technet.microsoft.com/sysinternals/bb896645.aspx) para buscar operaciones de E/S de archivo grandes en un sistema con Windows Server 2008.
Hay varias maneras de generar E/S grandes. Si tiene un segundo sistema que ejecuta Windows Vista Service Pack 1 o Windows Server 2008, puede ejecutar el monitor de procesos en el servidor y supervisar las copias de archivo en el segundo sistema. Generalmente, también es posible generar E/S de archivo de paginación grandes con la ejecución de un programa que hace un uso intensivo de la memoria y lleva al administrador de memoria a escribir páginas en el archivo de paginación.
La Figura A muestra el monitor de procesos después de ejecutar un programa que hace un uso intensivo de la memoria en un sistema con Windows XP, con la opción Habilitar resultados avanzados activada en el menú de opciones del monitor de procesos y un filtro establecido para mostrar sólo las escrituras en el archivo de paginación, pagefile.sys. La columna Detalle muestra que las escrituras son de un tamaño de 64 KB.
Figura A (Hacer clic en la imagen para ampliarla)
Al ejecutar los mismos pasos en Windows Server 2008, es muy probable que vea algo semejante a lo que muestra la Figura B, donde la mayoría de las escrituras son de aproximadamente 1 MB.
Figura B (Hacer clic en la imagen para ampliarla)
El administrador de memoria incluye varias mejoras de rendimiento en Windows Server 2008. Por ejemplo, produce menos E/S de disco a un tamaño superior que en Windows Server 2003 al capturar datos del archivo de paginación o realizar E/S de lectura anticipada en archivos asignados. Las E/S de archivo más grandes son el resultado de cambios en el sistema de E/S que eliminan el límite de tamaño de E/S de 64 KB presente desde la primera versión de Windows NT®.
También es importante tener en cuenta que las lecturas de datos para lecturas anticipadas (lecturas especulativas) de archivos asignados por el administrador de caché suelen ser dos veces más grandes en Windows Server 2008 que en Windows Server 2003 y van directamente a la lista de elementos en espera (la memoria caché de datos y el código del sistema). Este comportamiento se da en lugar de requerir al administrador de caché que asigne memoria virtual y lea los datos en el espacio de trabajo del sistema (memoria asignada al sistema por el administrador de memoria), lo que podría provocar que otros datos o código en uso queden expulsados innecesariamente del espacio de trabajo.
El administrador de memoria realiza también E/S más grandes al escribir datos en el archivo de paginación. Mientras que Windows Server 2003 a menudo realizaba escrituras incluso inferiores a 64 KB, en Windows Server 2008, el administrador de memoria produce comúnmente escrituras de 1 MB.
Además de mejorar el rendimiento al reducir el número de escrituras en el archivo de paginación, las escrituras más grandes reducen la fragmentación dentro del archivo. Esto, a su vez, causa una reducción en el número de lecturas y búsquedas en disco que se requieren para leer varias páginas, ya que, la mayoría de las veces, no se encuentran en ubicaciones adyacentes.
El administrador de memoria trata también de escribir otras páginas modificadas que están cerca de la que se está escribiendo en el espacio de direcciones del proceso propietario, y toma como objetivo el área del archivo de paginación donde ya residen otras páginas próximas. Esto minimiza también la fragmentación y puede mejorar el rendimiento porque las páginas que podrían acabar por escribirse en el archivo de paginación ya se han escrito. Además, reduce el número de lecturas de paginación requeridas para extraer un intervalo de páginas de proceso adyacentes. Vea la barra lateral "Experimento: Detección de E/S de disco grandes" para obtener más información sobre el uso de E/S grandes por parte del administrador de memoria.
SMB 2.0
El protocolo de sistema de archivos remoto SMB (Bloque de mensajes del servidor), también conocido como Sistema de archivos de Internet común (CIFS), ha sido la base del servicio de archivos de Windows desde la introducción de la funcionalidad de servicio de archivos en Windows. Durante los últimos años, las limitaciones de diseño de SMB han restringido el rendimiento del servicio de archivos de Windows y la capacidad de aprovechar características nuevas del sistema de archivos local. Por ejemplo, el tamaño máximo de búfer que se puede transmitir en un solo mensaje es aproximadamente de 60 KB, y SMB 1.0 no reconocía los vínculos simbólicos NTFS del lado cliente incluidos en Windows Vista y Windows Server 2008.
Windows Vista y Windows Server 2008 introducen SMB 2.0, que es un nuevo protocolo de servicio de archivos remoto que Windows usa cuando el cliente y el servidor lo permiten. Además de procesar correctamente los vínculos simbólicos del lado cliente y otras mejoras de NTFS, SMB 2.0 recurre al procesamiento por lotes para minimizar el número de mensajes que intercambian el cliente y el servidor. El procesamiento por lotes puede mejorar la capacidad de proceso en redes de alta latencia, como redes de área ancha (WAN), porque permite que haya más datos en movimiento al mismo tiempo.
Mientras que SMB 1.0 producía E/S para un solo archivo secuencialmente, SMB 2.0 hace uso de canalizaciones de E/S con el fin de producir varias E/S simultáneas para el mismo archivo. Mide la cantidad de memoria de servidor usada por un cliente para E/S pendientes con el fin de determinar el alcance necesario de las canalizaciones.
Como resultado de los cambios en el sistema de E/S y el administrador de memoria de E/S de Windows, el ajuste automático de la ventana de recepción de TCP/IP y las mejoras en el motor de copia de archivos, SMB 2.0 ofrece mejoras de capacidad de proceso considerables y una reducción en tiempos de copia de archivos para transferencias grandes. Como ambos sistemas operativos implementan SMB 2.0, la implantación de servidores de archivos Windows Server 2008 con clientes de Windows Vista posibilita el uso de SMB 2.0 y la realización de estas ventajas de rendimiento.
Confiabilidad con la recuperación automática de NTFS
La confiabilidad es un atributo clave de servidor, y Windows Server 2008 proporciona varias mejoras que ayudan a los administradores a mantener el funcionamiento óptimo de su servidor, entre ellas, la reparación en línea de la coherencia de NTFS, una infraestructura nueva para la generación de informes de errores de hardware y extensiones del comprobador de controladores.
Con los dispositivos de almacenamiento de varios terabytes actuales, la desconexión de un volumen para comprobar la coherencia puede tener como resultado una interrupción del servicio de varias horas. Con el reconocimiento de que muchos daños en disco se encuentran en un solo archivo o en una parte de los metadatos, Windows Server 2008 implementa una característica nueva de recuperación automática de NTFS para reparar daños mientras el volumen permanece en línea.
Cuando NTFS detecta los daños, impide el acceso a los archivos dañados y crea un subproceso de trabajo del sistema que ejecuta correcciones de tipo Chkdsk en las estructuras de datos dañadas, y permite el acceso a los archivos reparados al terminar. El acceso a otros archivos continúa normalmente durante esta operación, lo que minimiza la interrupción de servicio.
Infraestructura WHEA
La Arquitectura de errores de hardware de Windows (WHEA) incluida en Windows Server 2008 promete simplificar la administración de errores de hardware y habilitar la respuesta proactiva a errores no irrecuperables. A menudo, los servidores tienen severas garantías de tiempo activo, de forma que la identificación y la solución de errores de manera oportuna en dichos sistemas es crítica.
El análisis de bloqueos enviados a Microsoft a través del Análisis de bloqueos en línea (OCA) muestra que aproximadamente un diez por ciento de los bloqueos de sistema operativo vienen ocasionados por errores de hardware, pero determinar la causa raíz de estos bloqueos ha sido difícil o imposible porque la información sobre los errores proporcionada por el hardware para la captura durante los bloqueos es insuficiente. Además, antes de Windows Server 2008, Windows no ofrecía compatibilidad integrada con la supervisión del estado de los dispositivos ni implementaba la notificación o la corrección de errores inminentes. La razón es que los dispositivos de hardware no usan un formato de error común y no ofrecen compatibilidad con software de administración de errores.
WHEA ofrece un mecanismo unificado de detección del origen de errores y generación de informes asociados para dispositivos de plataforma, incluidos procesadores, memoria, cachés y buses como PCI y PCI Express. Esto se consigue mediante la implementación de la arquitectura mostrada en la Figura 2, donde el núcleo es una API del kernel a la que llaman los orígenes de errores para informar de los errores. La API requiere que todos los errores tengan un formato determinado, y registra los errores mediante el Seguimiento de eventos para Windows (ETW). Los errores irrecuperables se registran después del reinicio.
Figura 2** Infraestructura WHEA para la generación de informes de errores **(Hacer clic en la imagen para ampliarla)
ETW se introdujo en Windows 2000, y el uso de WHEA por parte de ETW permite a los fabricantes de hardware y los proveedores de software desarrollar aplicaciones de administración de diagnósticos de dispositivos que consumen eventos de WHEA. Si un evento es tan grave como para provocar el bloqueo del sistema, WHEA garantiza que el registro del error irrecuperable queda almacenado en el archivo de volcado del bloqueo para que los administradores puedan determinar la causa raíz del bloqueo.
Otra pieza clave de WHEA es el Controlador de errores de hardware específicos de la plataforma (PSHED) incluido en %Systemroot%\System32\Pshed.dll. El kernel se conecta a PSHED, e interacciona con el hardware de plataforma y firmware, de forma que, esencialmente, sirve de nivel de traducción entre las notificaciones de error y la API de WHEA para la generación de informes de errores. Hay un PSHED suministrado por Microsoft para cada arquitectura de plataforma (x86, x64, Itanium), y PSHED presenta un modelo de complemento para que los fabricantes y los proveedores de hardware puedan omitir los comportamientos predeterminados con los específicos para su plataforma.
Finalmente, los componentes del sistema que interactúan con otros orígenes de errores, incluidos controladores de dispositivos, la capa de abstracción de hardware (HAL) y el kernel, pueden implementar controladores de errores de hardware de bajo nivel (LLHEL) que, inicialmente, se ocupan de las condiciones de error. El cometido de un LLHEL es extraer información de errores del dispositivo, notificar a PSHED para que reúna información adicional de errores de plataforma y, después, llamar a la API de WHEA del kernel para la generación de informes de errores.
Comprobador de controladores
El comprobador de controladores, una herramienta eficaz para localizar controladores de dispositivos con errores y hardware con problemas, se ha incluido en cada copia de Windows a partir de Windows 2000. Los administradores configuran comúnmente el comprobador de controladores (%Systemroot%\System32\Verifier.exe) para supervisar en profundidad el comportamiento de controladores de dispositivos que parecen causar bloqueos de sistema. El comprobador de controladores filtra operaciones no válidas de controlador para que los archivos de volcado de los bloqueos señalen directamente a la parte culpable.
Un inconveniente de implementaciones anteriores del comprobador de controladores es que la mayoría de los cambios de configuración requerían el reinicio del sistema, algo que es obviamente indeseable en un servidor de producción. La implementación del comprobador de controladores en Windows Server 2008 mejora este proceso al eliminar el requisito de reinicio para las comprobaciones más útiles, lo que permite solucionar problemas en un servidor sin tener que reiniciarlo.
Además, el comprobador de controladores introduce tres comprobaciones nuevas, como muestra la Figura 3. Las comprobaciones de seguridad garantizan que los controladores de dispositivos establezcan permisos seguros en los objetos que usan para interactuar con aplicaciones. Al exigir las solicitudes de E/S pendientes, se comprueba la resistencia de un controlador ante operaciones asincrónicas de E/S que se completan inmediatamente en lugar de hacerlo tras una demora. Y otras comprobaciones varias se ocupan de buscar controladores que liberan incorrectamente recursos en uso, hacen un uso inapropiado de las API de registro del Instrumental de administración de Windows (WMI) y permiten la pérdida de identificadores de recursos.
Figura 3** El comprobador de controladores con opciones activadas de Windows Server 2008 **(Hacer clic en la imagen para ampliarla)
Escalabilidad
La escalabilidad se refiere a la capacidad de un sistema operativo o una aplicación para utilizar de forma eficaz varios procesadores y grandes cantidades de memoria. Cada versión de Windows mejora la escalabilidad al minimizar o eliminar el uso de bloqueos que reducen el paralelismo en multiprocesadores, y Windows Server 2008 no es una excepción a esta tendencia.
Una mejora relativamente pequeña pero importante está en el código que ejecuta la expiración de temporizadores, que ya no adquiere el bloqueo de distribuidor, un bloqueo de programador en todo el sistema utilizado por todas las operaciones de sincronización de bajo nivel. La reducción resultante en la carga de sincronización de CPU permite a sistemas de Terminal Server de Windows Server 2008 admitir un 30 por ciento de usuarios simultáneos más que Windows Server 2003.
Otras mejoras de escalabilidad en Windows Server 2008 incluyen mejoras de puertos de terminación, una implementación nueva de grupos de subprocesos, un uso más eficiente de hardware de acceso a memoria no uniforme (NUMA) y la partición dinámica de sistemas.
Administración mejorada de puertos de terminación de E/S
La mayoría de las aplicaciones de servidor escalables de Windows, incluidas IIS, SQL Server® y Exchange Server, dependen de una API de sincronización de Windows denominada puerto de terminación para minimizar el cambio de subproceso de ejecución al ejecutar operaciones de E/S. Esto se consigue al asociar primero las notificaciones de llegadas de solicitud nuevas, como conexiones de cliente de servidor web, con un puerto de terminación y dedicar un grupo de subprocesos a la espera de las notificaciones. Cuando llega una solicitud, Windows programa un subproceso que, a continuación, suele ejecutar otras operaciones de E/S, como leer una página web del disco y enviarla al cliente para completar la solicitud.
Para que el mismo subproceso pueda volver al estado de espera de solicitudes de cliente adicionales tan rápidamente como sea posible, el subproceso produce E/S asincrónicamente y asocia terminaciones de E/S con el puerto de terminación. Seguidamente, el subproceso vuelve a la espera en el puerto de terminación, que programará el subproceso cuando llegue una solicitud nueva o se complete una de las E/S. De este modo, el mismo subproceso permanece activo en una CPU: alterna entre el procesamiento de solicitudes de cliente y la espera en el puerto de terminación.
Un inconveniente de la implementación de puertos de terminación en versiones previas de Windows es que, cuando se completaba una E/S, el sistema de E/S hacía que el subproceso que producía el E/S realizara inmediatamente un pequeño bit de procesamiento de terminación, independientemente de cualquier otra cosa que estuviera haciendo. Si había otros subprocesos activos, a menudo esto provocaba que el programador llevara a cabo el cambio de un subproceso activo y el cambio de contexto al emisor.
Windows Server 2008 evita estos cambios de contexto al aplazar el procesamiento de terminación al subproceso siguiente para esperar en el puerto de terminación asociado con la E/S. Así, aunque un subproceso diferente sea el siguiente para pasar a la espera en el puerto de terminación, realizará el procesamiento de terminación antes de ejecutar otro código, y el programador no necesita cambiar al subproceso emisor. Esta reducción de cambios de contexto puede mejorar dramáticamente la escalabilidad de aplicaciones de servidor de uso intensivo.
Grupos de subprocesos más eficientes
La escritura de aplicaciones que aprovechen varias CPU puede ser difícil, así que Windows XP introdujo grupos de subproceso de trabajo, una infraestructura y API asociadas que abstraen los detalles de ejecución de unidades pequeñas de trabajo en las CPU. Una aplicación especifica los elementos de trabajo a la API de grupos de subprocesos que, seguidamente, los ejecuta en uno de varios subprocesos que crea y administra para cada CPU en el sistema.
El objetivo del grupo de subprocesos es minimizar los cambios de contexto al usar los mismos subprocesos para ejecutar varios elementos de trabajo en sucesión. Cuando esto no resulta posible porque uno de los subprocesos está ocupado con otro trabajo, ejecuta el elemento de trabajo mediante un subproceso diferente en una CPU distinta.
La implementación de grupos de subprocesos en Windows Server 2008 hace un uso más eficaz de CPU indirectamente porque se beneficia de las mejoras en puertos de terminación y directamente al optimizar la administración de subprocesos de forma que los subprocesos de trabajo van y vienen dinámicamente cuando se necesita que se ocupen de las cargas de trabajo de las aplicaciones. Es más, el núcleo de la infraestructura ha pasado al modo de kernel, lo que reduce al mínimo el número de llamadas de sistema por parte de las aplicaciones que usan la API. Finalmente, la API nueva permite a las aplicaciones realizar ciertas operaciones de forma más sencilla, por ejemplo, anular las unidades de trabajo en cola durante el cierre de las aplicaciones.
Optimizaciones de NUMA
Windows Server 2003 introdujo optimizaciones para equipos NUMA en el programador de subprocesos y el administrador de memoria, pero Windows Server 2008 agrega optimizaciones de NUMA en el administrador de E/S y amplía las optimizaciones de NUMA del administrador de memoria.
Los sistemas NUMA suelen ser sistemas multiprocesador en los que la memoria tiene una latencia diferente según el procesador que obtiene acceso a ella (consulte la Figura 4). La memoria se divide en nodos, donde las latencias entre las CPU y los nodos pueden variar, y cada CPU se considera parte de un nodo al que tiene acceso rápido de forma preferente.
Figura 4** Ejemplo de sistema NUMA **(Hacer clic en la imagen para ampliarla)
Los sistemas NUMA, especialmente aquellos con más de ocho CPU, a menudo son más eficaces en cuanto a rendimiento y rentabilidad que los sistemas de acceso uniforme a la memoria. Un sistema de acceso uniforme a la memoria debe distribuir memoria equitativamente a todas las CPU, mientras que un sistema NUMA puede implementar interconexiones de alta velocidad para memoria directamente conectada a una CPU, y conexiones más económicas de alta latencia para CPU y memoria con mayor separación.
Para escalar de forma eficaz en un sistema NUMA, el sistema operativo o la aplicación deben reconocer la topología de nodos para que el procesamiento se ejecute cerca de la memoria que contiene los datos y el código del procesamiento. Por ejemplo, el programador de Windows asigna a cada subproceso un "procesador ideal", que es la CPU en la que el programador intenta siempre ejecutar el subproceso. Así, es más probable que los datos que el subproceso coloca en la memoria caché de la CPU estarán disponibles para el subproceso cada vez que se ejecuta.
En Windows Server 2003, el programador amplía este concepto al considerar el nodo que contiene el procesador ideal como nodo ideal del subproceso, y trata de programar el subproceso de otra CPU en el nodo ideal cuando el procesador ideal está ocupado con la ejecución de un subproceso diferente. El administrador de memoria de Windows Server 2003 acabó también por ofrecer compatibilidad con NUMA y, siempre que es posible, dirige las asignaciones de memoria del subproceso a la memoria del nodo en que se ejecuta el subproceso.
En Windows Server 2008, el administrador de memoria divide los búferes de memoria no paginados del kernel (memoria usada por el kernel y los controladores de dispositivos para almacenar datos que permanecen en RAM) entre los nodos para que las asignaciones provengan de la memoria en el nodo en que se origina la asignación. Las entradas de la tabla de páginas del sistema (PTE) se asignan desde el nodo en que se origina la asignación, si la asignación requiere una tabla de páginas nueva, en lugar de asignarse desde cualquier nodo, como ocurre en Windows Server 2003.
En Windows Server 2003, cuando un subproceso realiza una asignación de memoria, el administrador de memoria preferiría el nodo en que se ejecuta el subproceso en el momento de la asignación. Si el subproceso se programó momentáneamente en un nodo no ideal, cualquier asignación realizada durante este tiempo vendría del nodo no ideal. Así, cuando el subproceso se ejecuta finalmente en su nodo ideal, no estará tan próximo a los datos o al código almacenados en la memoria asignada.
Para resolver esta situación, el administrador de memoria de Windows Server 2008 prefiere el nodo ideal de los subprocesos para todas las asignaciones de un subproceso, incluso cuando el subproceso se ejecuta cerca de un nodo diferente. El administrador de memoria también entiende automáticamente las latencias entre procesadores y nodos, de forma que, si el nodo ideal no tiene memoria disponible, pasa a comprobar el nodo más cercano al nodo ideal. Además, el administrador de memoria migra páginas en su lista de elementos en espera al nodo ideal de un subproceso cuando el subproceso hace referencia al código o a los datos.
Las aplicaciones que desean controlar la localidad de sus asignaciones puede usar nuevas API de memoria de NUMA con el fin de especificar el nodo preferido para asignaciones de memoria, vistas de asignación de archivos y objetos de asignación de archivos. Para asignaciones relacionadas con asignaciones de archivos, el administrador de memoria comprueba si la operación de asignación especifica un nodo. Seguidamente, comprueba si el objeto de asignación de archivos especifica uno y, finalmente, acude al nodo ideal del subproceso si es necesario.
Antes de Windows Server 2008, la interrupción y la llamada a procedimiento diferida (DPC) asociada para una E/S de almacenamiento o de red podían ejecutarse en cualquier CPU, incluidas aquellas de un nodo diferente a aquel en que se inició la E/S, lo que posiblemente hacía que los datos leídos o escritos en la operación de E/S se encontrasen en la memoria de un nodo diferente al nodo que ofrece acceso a los datos.
Para evitar esto, el sistema de E/S de Windows Server 2008 dirige la ejecución de DPC a una CPU en el nodo que inició la E/S, y los sistemas que tienen dispositivos compatibles con el bus PCI MSI-X (una extensión al estándar MSI) pueden localizar aún más la terminación de E/S al usar controladores de dispositivos que aprovechan las API de Windows Server 2008 para dirigir una interrupción de E/S al procesador que inició la E/S.
Partición dinámica
Una de las maneras en que un sistema puede ser más escalable es ofrecer compatibilidad con la partición dinámica de recursos de hardware, como CPU y memoria. Esta misma compatibilidad puede incrementar también la disponibilidad del sistema cuando los recursos se pueden reemplazar sin requerir el reinicio.
Windows Server 2003 posibilitaba la ampliación de memoria en caliente, lo que permitía a servidores con compatibilidad de memoria dinámica usar RAM al tiempo que el administrador agrega este tipo de memoria. Windows Server 2008 amplía la compatibilidad con memoria dinámica al permitir el reemplazo de memoria.
La memoria RAM con mayor dependencia de correcciones ECC presenta el riesgo de que podría dejar de funcionar por completo, así que, en un servidor que admite el reemplazo en caliente, Windows Server 2008 puede migrar datos transparentemente de los bancos de memoria con errores a bancos de reemplazo. Para ello, primero migra los datos bajo el control del sistema operativo; luego, apaga de forma eficaz los dispositivos de hardware al colocarlos en un estado de baja potencia, migra el resto de los datos de la memoria y vuelve a activar los dispositivos para reanudar el funcionamiento normal.
Windows Server 2008 también permite agregar y reemplazar procesadores en caliente. Para un reemplazo en caliente, el hardware debe ser compatible con el concepto de CPU de reserva, que se pueden colocar en línea o agregar dinámicamente cuando una CPU existente genera indicaciones de errores, algo que actualmente sólo es posible en sistemas avanzados. El programador de Windows Server 2008 reduce la actividad en la CPU con errores y migra el trabajo a la unidad de reemplazo. Así, se puede quitar la CPU con errores para reemplazarla por una unidad de reserva.
Como Windows Server 2008 permite agregar procesadores en caliente, el administrador puede actualizar las capacidades de procesamiento de un servidor sin tiempo de inactividad. Sin embargo, el programador y los sistemas de E/S sólo ofrecerán una CPU nueva como disponible a controladores de dispositivos y aplicaciones que solicitan la notificación de llegada de CPU a través de API nuevas porque algunas aplicaciones dan por hecho que el número de CPU está fijado para una sesión de arranque. Por ejemplo, una aplicación podría asignar una matriz de colas de trabajo correspondiente a cada CPU, donde un subproceso usa la cola asociada con la CPU en que se ejecuta. Si el programador colocase uno de los subprocesos de la aplicación en una CPU nueva, intentaría hacer referencia a una cola inexistente, lo que posiblemente causaría daños en los datos de la aplicación y el bloqueo de la misma.
Las aplicaciones basadas en servidor de Microsoft, como SQL Server y Exchange Server, permiten agregar CPU, al igual que varios procesos básicos de Windows, por ejemplo, el proceso del sistema, el administrador de sesiones (%SystemRoot%\System32\Smss.exe) y procesos de hospedaje de servicio genérico (%Systemroot%\System32\Svchost.exe). Otros procesos pueden solicitar también la notificación de la llegada de CPU nueva con una API de Windows. Cuando llega una CPU nueva, Windows envía una notificación sobre la llegada inminente a los controladores de dispositivos, inicia la CPU y, seguidamente, solicita a los controladores de dispositivos y las aplicaciones que usen las CPU para asignar estructuras de datos con el fin de realizar el seguimiento de la actividad en la CPU nueva, si fuera necesario.
Virtualización de equipos
Antes de Windows Server 2008, los productos de virtualización de Microsoft, incluido Virtual Server 2005, se implementaban mediante la virtualización hospedada, como muestra la Figura 5. En la virtualización hospedada, las máquinas virtuales vienen implementadas por un Monitor de equipo virtual (VMM) que se ejecuta junto al sistema operativo host, normalmente como controlador de dispositivos. El VMM depende de los controladores de dispositivos y la administración de recursos del sistema operativo host y, cuando el sistema operativo host lo programa para la ejecución, distribuye el tiempo de la CPU entre máquinas virtuales (VM) activas.
Figura 5** Virtualización hospedada de equipos **(Hacer clic en la imagen para ampliarla)
Hyper-V, anteriormente "Viridian", se implementa mediante la virtualización de hipervisor. El hipervisor tiene el control total de todos los recursos de hardware, e incluso el sistema operativo Windows Server 2008, que arranca el sistema y a través del cual el usuario controla las VM, se ejecuta esencialmente en una máquina virtual, como vemos en la Figura 6.
Figura 6** Arquitectura Hyper-V **(Hacer clic en la imagen para ampliarla)
El hipervisor puede dividir el sistema en varias VM y trata la versión de arranque de Windows Server 2008 como partición maestra, o raíz, lo que le ofrece acceso directo a dispositivos de hardware, como el disco, los adaptadores de red y el procesador de gráficos. El hipervisor espera que la raíz realice la administración de la energía y responda a eventos Plug and Play de hardware. Intercepta E/S de dispositivos de hardware iniciadas en particiones secundarias y las dirige a la raíz, que usa controladores de dispositivos de Windows Server 2008 estándar para obtener acceso al hardware. De este modo, los servidores que ejecutan Hyper-V pueden sacar el máximo partido de la compatibilidad de Windows con dispositivos de hardware.
Al configurar Windows Server 2008 con la función de servidor Hyper-V, Windows establece la Base de datos de configuración de arranque (BCD) hypervisorimagelaunchtypeboot en auto y configura el controlador de dispositivos Hvboot.sys para entrar en funcionamiento con prontitud durante el proceso de arranque. Si la opción está configurada, Hvboot.sys prepara el sistema para la virtualización y carga %Systemroot%\System32\Hvax64.exe o %Systemroot%\System32\Hvix64.exe en la memoria, según si el sistema implementa extensiones de virtualización de CPU AMD-V o Intel VT, respectivamente.
Una vez que se ha cargado, el hipervisor usa las extensiones de virtualización para insertarse debajo de Windows Server 2008. Las aplicaciones de modo de usuario usan el nivel de privilegios Anillo 3 del procesador x64 y el código de modo kernel se ejecuta al nivel Anillo 0, así que el hipervisor opera al nivel de privilegios conceptual Anillo menos 1, ya que puede controlar el entorno de ejecución de código que se ejecuta al nivel Anillo 0.
Al usar la consola de administración de Hyper-V para crear o iniciar una partición secundaria, se comunica con el hipervisor que usa el controlador %Systemroot%\System32\Drivers\Winhv.sys, que, a su vez, usa la API de hiperllamadas documentada públicamente para dirigir el hipervisor a la creación de una partición nueva de tamaño de memoria física y características de ejecución particulares. El servicio de VM (%Systemroot%\System32\Vmms.exe) en la raíz se encarga de crear un proceso de trabajo de VM (%Systemroot%\System32\Vmwp.exe) para cada partición secundaria con el fin de administrar el estado de las mismas.
Una forma en que Windows mejora el rendimiento de sistemas operativos de VM secundarios es que ambos Windows Server 2008 y Windows Vista implementan mejoras de código en forma de secuencias de código que se activan sólo cuando el sistema operativo se ejecuta en un hipervisor que implementa la API de hiperllamadas de Microsoft. Al solicitar directamente los servicios del hipervisor, la VM secundaria evita la sobrecarga de código de virtualización que resultaría si el hipervisor tuviera que adivinar la intención del sistema operativo secundario.
Por ejemplo, un sistema operativo invitado que no implementa mejoras de código para bloqueos por bucle, que ejecutan sincronización de multiprocesadores de bajo nivel, giraría simplemente en un bucle cerrado en espera de un bloqueo por bucle enviado por otro procesador virtual. El giro podría ocupar a una de las CPU de hardware hasta la programación del segundo procesador virtual por parte del hipervisor. En sistemas operativos mejorados con código, el código de bloqueo por bucle indica al hipervisor el momento en que giraría normalmente a través de una hiperllamada. De este modo, el hipervisor puede programar inmediatamente otro procesador virtual y evitar el desperdicio de uso de CPU.
Otra manera en que Windows Server 2008 mejora el rendimiento de VM viene dada por la aceleración del acceso de VM a los dispositivos. El rendimiento queda mejorado al instalar una colección de componentes, denominados colectivamente "componentes de integración de VM", en el sistema operativo secundario.
Si ejecuta una VM sin instalar los componentes de integración, el sistema operativo secundario configurará los controladores de dispositivos de hardware para los dispositivos emulados que le presente el hipervisor. El hipervisor debe intervenir cuando un controlador de dispositivos intenta tocar un recurso de hardware para informar a la partición raíz, que realiza E/S de dispositivos mediante controladores de dispositivos estándar de Windows en nombre del sistema operativo de la VM secundaria. Debido a que una sola operación de E/S de alto nivel, como una lectura de disco, puede implicar muchos accesos discretos de hardware, podría causar muchas transiciones, llamadas intercepciones, en el hipervisor y en la partición raíz.
Windows Server 2008 minimiza las intercepciones con tres componentes: el controlador de bus de máquina virtual (%Systemroot%\System32\Drivers\Vmbus.sys), clientes de servicio virtual (VSC) y proveedores de servicios virtuales (VSP). Al instalar componentes de integración en una VM con un sistema operativo compatible, los VSC adquieren la función de controladores de dispositivos y usan los servicios del controlador Vmbus.sys en la VM secundaria para enviar solicitudes de E/S de alto nivel al controlador de bus de máquina virtual en la partición raíz a través de los servicios de hiperllamada y uso compartido de memoria del hipervisor. En la partición raíz, Vmbus.sys reenvía la solicitud al VSP correspondiente, que inicia las solicitudes de E/S estándar de Windows a través de los controladores de dispositivos de la raíz.
Como puede ver, Windows Server 2008 juega una función clave en la estrategia de virtualización de equipos de Microsoft con su introducción de la virtualización basada en hipervisor Hyper-V. Encontrará más información sobre esta y otras características en la próxima edición de mi libro, Microsoft Windows Internals, programado para la publicación más adelante este mismo año.
Mark Russinovich es empleado técnico de Microsoft en la división de servicios y plataformas. Es coautor de Microsoft Windows Internals (Microsoft Press, 2004) y ponente habitual en conferencias de TI y desarrolladores, incluidos Microsoft TechEd y el PDC. Entró a formar parte de Microsoft con la reciente adquisición de la empresa que cofundó él mismo, Winternals Software. También creó Sysinternals, donde publicó muchas utilidades muy conocidas, como Process Explorer, Filemon y Regmon.
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.