IIS

implementación de IIS 7.0

Fergus Strachan

De un vistazo:

• Implementación de IIS 7.0 en un entorno de granja de servidores web
• Mejoras en la seguridad y el rendimiento
• Migración de aplicaciones web ASP.NET de IIS 6.0 a IIS 7.0
• Migración de aplicaciones web PHP a IIS 7.0

Contenido

Preparado, listo, prueba
Configuración de la prueba
Mejoras importantes para los administradores de TI
Arquitectura de IIS
Modos integrado y clásico
Módulos y funcionalidad
Migración de aplicaciones web
Conclusión

El equipo de IIS en Microsoft comunica que Internet Information Services (IIS) 7.0 es el lanzamiento más importante en la historia de IIS. En esta versión, se establecen nuevos estándares, se ofrecen mejoras fundamentales y

se presentan nuevas capacidades para la consolidación de entornos web. Microsoft.com ya usa IIS 7.0, que está incluido en Windows Server® 2008 y Windows Vista® SP1, y varias empresas de hospedaje web ya han empezado a ofrecer servicios con IIS 7.0 a diseñadores y desarrolladores web que deseen trasladar sus aplicaciones web existentes a la nueva plataforma de servidor web.

En este artículo, trataremos las mejoras clave de IIS 7.0 más importantes para los profesionales de TI y profundizaremos en la migración de aplicaciones web ASP.NET y PHP. Sin embargo, en primer lugar, me gustaría describir un laboratorio de pruebas que se parezca a un entorno de producción básico.

Este es un paso importante. Antes de implementar IIS 7.0 en los servidores de producción, necesitará pasar un tiempo realizando pruebas exhaustivas en un entorno de laboratorio para asegurarse de que sus aplicaciones web se ejecutan correctamente en el nuevo servidor web.

Preparado, listo, prueba

Mi laboratorio de pruebas incluye los sistemas que ejecutan Windows Server 2003 e IIS 6.0, que hospedan aplicaciones ASP.NET, y servidores que ejecutan Ubuntu 7.10 (distribución Linux) y Apache HTTP Server 2.2, que hospedan las aplicaciones web basadas en PHP. Mi objetivo final es la implementación de Windows Server 2008 en los sistemas provisionales y de producción, así como la transición de aplicaciones web complejas para sustituir versiones de IIS 6.0 y de Apache por IIS 7.0.

Tengo dos aplicaciones web clave: DotNetNuke 4.7 y osCommerce 3.0a4. DotNetNuke es un marco de aplicación web basado en ASP.NET 2.0 y Microsoft® SQL Server®. La otra aplicación, osCommerce, es la versión alfa más reciente de una solución de comercio electrónico con funciones completas creada en PHP y MySQL. Usemos estas aplicaciones avanzadas con IIS 7.0.

Me gustaría dejar claro que mi intención no es comparar versiones, productos o plataformas de software. No obstante, hay una gran cantidad de ventajas relacionadas con la estandarización en Windows Server 2008 e IIS 7.0 que debería destacar. En particular, se reduce la complejidad administrativa y se puede minimizar el número total de servidores web en ejecución.

En la Figura 1, puede ver información general acerca del laboratorio de pruebas que estoy usando para este artículo. Si desea seguir mis explicaciones en su propio entorno de pruebas, puede encontrar los vínculos a los componentes de software necesarios, así como instrucciones de instalación paso a paso en el material complementario incluido en la sección de descarga de códigos del sitio web de TechNet Magazine en .com.

Figura 1 Entorno de prueba para la implementación de IIS 7.0 (haga clic en la imagen para ampliarla)

Observe que, aproximadamente al mismo tiempo que me encontraba terminando este artículo, Microsoft lanzó una herramienta de línea de comandos (MSDeploy.exe) para ayudar a los clientes durante la implementación, la sincronización y la migración de aplicaciones web a IIS 6.0 y 7.0. Recomiendo que pruebe esta herramienta. Puede encontrar información detallada en el blog del equipo Microsoft Web Deployment en go.microsoft.com/fwlink/?LinkId=118272.

Configuración de la prueba

Cuando escribí esto, Windows Server 2008 aún era una versión preliminar, por lo que no sustituí Windows Server 2003 en los servidores de controladores de dominio ni de bases de datos. Con el lanzamiento oficial de Windows Server 2008, tal vez desee considerar también la migración de su infraestructura de Active Directory®. La migración de bases de datos de SQL Server® 2005 y MySQL a SQL Server 2008 tampoco se encuentra dentro del alcance de este artículo.

El principal motivo por el que implementé SQL Server 2008 en mi servidor provisional es que requiere menos esfuerzo que la instalación de SQL Server 2005 con Service Pack 2. DotNetNuke podía ejecutarse sin problemas con una base de datos de SQL Server 2008. La instalación de MySQL 5.0 en Windows Server 2008 también resultaba muy sencilla.

Aunque IIS 7.0 está disponible en Server Core, no usé una instalación de Server Core debido a ciertos requisitos para mi prueba. Mi servidor provisional requería la instalación completa, ya que era mi sistema de prueba principal. Además, Microsoft .NET Framework no está disponible en Server Core.

PHP funciona correctamente en Server Core, pero mi objetivo es consolidar las aplicaciones ASP.NET y PHP, por lo que Server Core no es una opción. Hasta que .NET Framework no sea compatible con Server Core, deberá realizar una instalación completa para que se acepte el uso de aplicaciones ASP.NET. Si desea obtener instrucciones detalladas paso a paso para la instalación del entorno de prueba, consulte el archivo 01_install_testlab.htm del material complementario.

Opté por realizar una instalación limpia de Windows Server 2008 (en lugar de actualizar servidores existentes). Entre otras cosas, la instalación limpia facilita la implementación de un escenario de migración de ensayo como el que aparece en la Figura 2. La estrategia subyacente consiste en conservar las granjas de servidores web existentes en ejecución hasta que todos los componentes de aplicaciones web relevantes se hayan probado correctamente en el servidor provisional y se hayan trasladado a la nueva granja de servidores web de IIS 7.0.

Figura 2 Preparación del conmutador a IIS 7.0 (haga clic en la imagen para ampliarla)

Puede mover todas las aplicaciones web existentes a la vez o de forma gradual, en función de la complejidad de su entorno. Una vez que lleve a cabo una prueba de aceptación en la nueva granja de servidores web para todas las aplicaciones y los sitios web, puede realizar el cambio mediante la modificación de los registros DNS de interés con el fin de dirigir a los exploradores a la nueva granja de servidores web de IIS 7.0. De esta forma, se minimizan el tiempo de inactividad y las interrupciones.

Mejoras importantes para los administradores de TI

MSDN® Magazine cuenta con un excelente artículo de Mike Volodarsky titulado "Explore el servidor web de Windows Vista y más allá" (disponible en msdn2.microsoft.com/magazine/cc163453.aspx), donde puede encontrar información acerca de las mejoras en IIS 7.0.

Otra buena lectura es una publicación en el blog del equipo de Microsoft.com, llamada "The Tasty Morsels Found in Dogfood" (disponible, en inglés, en go.microsoft.com/fwlink/?LinkId=117436). En ella, se resumen las experiencias iniciales con IIS 7.0 de los miembros del equipo. En pocas palabras, según ellos, las principales mejoras son:

1. Instalación simplificada.
2. Gran compatibilidad.
3. No hacen falta metabases.
4. La configuración centralizada se lleva a cabo a través del archivo applicationHost.config que se encuentra en el recurso compartido de UNC.
5. Configuración delegada mediante archivos web.config en los directorios de aplicación
6. Herramientas de administración mejoradas.
7. Seguimiento de solicitudes con error.
8. Solicitud de filtrado sin necesidad de URLScan.
9. Disponibilidad de sincronización de contenido simplificado mediante recursos compartidos de UNC.

10. Almacenamiento en la memoria caché de resultados de contenido dinámico.

Por supuesto que la instalación simplificada está en mi lista. En su publicación en el blog, el equipo de Microsoft.com muestra cómo implementar todas las características de IIS 7.0 (o, claro está, sólo las características que desee) con una única línea de comandos. Adopté este enfoque en mis instrucciones de instalación del laboratorio de prueba, con la línea de comandos que aparece en la Figura 3.

Hay que reconocer que el comando es bastante largo. Si desea copiar este comando, le recomiendo que lo copie y lo pegue del sitio web de TechNet Magazine, en lugar de escribirlo a mano. Aunque este comando coloca todos los módulos disponibles en el equipo con IIS 7.0, no incluye PHP. IIS 7.0 no incluye PHP, y la descarga y la instalación de los paquetes de Debian por Internet es un concepto extraño para Windows® Package Manager (pkgmgr.exe). Aquí es donde entra el Kit de instalación automatizada (AIK) de Windows.

Figura 3 Implementación de las características de IIS 7.0 con una línea de comandos sencilla

start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-­WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (<a href=\"https://blogs.technet.com/mscom\" xmlns=\"http://www.w3.org/1999/xhtml\">blogs.technet.com/mscom</a>).

Con AIK, puede crear un DVD de instalación personalizada para Windows Server 2008 que incluya IIS 7.0 y PHP 5. También puede incluir MySQL, archivos de aplicación web y cualquier otro componente necesario para la implementación. Todos los componentes pueden ser parte del programa de instalación de Windows Server 2008, lo que permite aplicar las personalizaciones de forma coherente en todos los servidores web. No es necesario modificar las líneas de comandos ni los archivos de configuración.

Puede, incluso, crear un DVD personalizado para instalaciones completamente desatendidas. El AIK incluye documentación y herramientas para crear un archivo AutoUnattend.xml, que puede colocar en la carpeta raíz del DVD. El archivo Custom Image Deployment.htm del material complementario proporciona instrucciones paso a paso.

Muchos administradores también están de acuerdo en que la compatibilidad es una mejora clave. A medida que avanzaba, esperaba encontrarme una serie de problemas de compatibilidad con DotNetNuke y osCommerce, pero la transición a IIS 7.0 fue bastante sencilla, a pesar de que estas aplicaciones web incluyesen características avanzadas, como la autenticación de formularios y las direcciones URL de uso fácil con motores de búsqueda.

Con DotNetNuke, no encontré ningún problema hasta que pasé a un escenario de granja de servidores web compleja con contenido UNC compartido en una plataforma de 64 bits. No obstante, este problema apenas tenía ninguna gravedad. En última instancia, esta compatibilidad mejorada implica que se necesita menos tiempo para conseguir la ejecución de las aplicaciones web en IIS 7.0.

Si se encontrase algún problema de compatibilidad con sus aplicaciones web, la capacidad integrada de diagnóstico y seguimiento pasará a ser una de sus características nuevas favoritas rápidamente. La información de diagnóstico detallada es muy significativa y las rutas de solución sugeridas son útiles y funcionan de verdad.

En la Figura 4, puede ver la información de diagnóstico que recibe al ejecutar DotNetNuke 4.7 en IIS 7.0 en modo integrado. En este ejemplo, aparecen tres opciones (incluidas en la sección "Cosas que puede hacer"). La modificación de la aplicación para que admita el modo integrado probablemente sea la mejor elección para los desarrolladores de DotNetNuke. Por el contrario, hacer caso omiso del error podría ser mala idea. Yo prefiero la tercera opción, habilitar el modo clásico mediante el paso de la aplicación web a Classic .NET AppPool, ya que deseo ejecutar DotNetNuke 4.7 sin modificar en IIS 7.0.

Figura 4 Información de diagnóstico para DotNetNuke durante la ejecución en modo integrado (haga clic en la imagen para ampliarla)

Arquitectura IIS

Tal vez se pregunte qué son los modos integrado y clásico, y por qué afectan a la aplicación ASP.NET (DotNetNuke), pero no a la aplicación PHP (osCommerce). Para comprenderlo mejor, debe echar un vistazo en primer lugar a la arquitectura de IIS 7.0. Las versiones anteriores integran el tiempo de ejecución de ASP.NET en el servidor web principal, fundamentalmente, mediante una extensión ISAPI (aspnet_isapi.dll). IIS 7.0, por otro lado, permite a los módulos de ASP.NET conectarse directamente al servidor web principal a través de un módulo HTTP de nivel global llamado ManagedEngine, que carga el archivo DLL de compatibilidad con ASP.NET (webengine.dll) en la canalización de procesamiento de solicitudes de IIS 7.0.

Los módulos nativos usan la API principal de servidor web IIS para registrarse en eventos concretos de la canalización, como BeginRequest, Authenticate­Request, AuthorizeRequest y Execute­RequestHandler. ManagedEngine también ofrece la compatibilidad necesaria para integrar los módulos de ASP.NET en la canalización de solicitudes. Mediante esta nueva arquitectura, IIS 7.0 puede invocar módulos nativos y de ASP.NET en cualquier etapa del procesamiento de solicitudes, con independencia del tipo de contenido solicitado.

A modo de ejemplo, tomemos la autenticación de usuario de ASP.NET. En IIS 6.0, un módulo HTTP basado en ASP.NET puede registrarse en eventos On­Authenticate (como Forms­Authentication.OnAuthenticate y Win­dows­Authentication.OnAuthenticate) para establecer la identidad del usuario en el HttpContext actual. Esto es de gran utilidad en el tiempo de ejecución de ASP.NET, pero no puede usar el código ASP.NET para proteger los recursos expuestos a través de una aplicación web basada en PHP.

Según su configuración de mapa de scripts, IIS 6.0 reenvía las solicitudes para los tipos de contenido de ASP.NET a aspnet_isapi.dll, pero no reenvía las solicitudes para los tipos de contenido de PHP a la extensión de ISAPI para ASP.NET. Después de todo, ASP.NET no procesa el código PHP, pero también significa que el código de autenticación ASP.NET no se ejecuta si se solicita una página de PHP. De este modo, con IIS 6.0, necesita duplicar la lógica de autenticación, ya que las aplicaciones PHP deben implementar sus propios mecanismos de autenticación.

IIS 7.0 usa un modelo de procesamiento controlado por eventos que permite mezclar y hacer coincidir módulos individuales en la canalización de solicitudes. Entre otros componentes, IIS 7.0 incluye los módulos administrados WindowsAuthentication y FormsAuthentication que producen eventos OnAuthenticate cuando la canalización de solicitudes desencadena el evento AuthenticateRequest. Ahora dispone de un módulo nativo, como Request­FilteringModule o IpRestrictionModule, controla el evento BeginRequest para rechazar solicitudes críticas lo antes posible, ejecuta un código de autenticación de ASP.NET personalizado en el evento AuthenticateRequest y hace que FastCgiModule ejecute el motor de scripting de PHP (php-cgi.exe) en el evento Execute­RequestHandler para procesar páginas de PHP.

El resultado de esta arquitectura integrada es que los desarrolladores web no tienen que duplicar el código para implementar la lógica empresarial común. Puede proteger todos sus recursos de IIS, incluidas las aplicaciones PHP, mediante un código de autenticación personalizado de ASP.NET. Puede realizar otras tareas previas y posteriores al procesamiento a través de módulos de ASP.NET, como la reconfiguración de direcciones URL, el seguimiento personalizado y el registro de errores.

Modos integrado y clásico

El efecto secundario que provoca esta nueva arquitectura es que las aplicaciones ASP.NET existentes pueden necesitar cambios en el código y en la configuración que deberían realizar los desarrolladores de aplicaciones para asegurar que los cambios no provocan conflictos de módulos en la canalización de la solicitud. Si no puede trasladar inmediatamente una aplicación web existente, puede habilitar el modelo clásico en el conjunto de aplicaciones que el proceso de trabajo usa para ejecutar la aplicación web. IIS 7.0 no carga ManagedEngine en los procesos de trabajo en modo clásico, lo que implica en este caso que la canalización de solicitud no puede resolver o invocar módulos de ASP.NET. En lugar de eso, IIS 7.0 activa una serie de controladores de ISAPI, que están basados en IsapiModule (aspnet_isapi.dll), para procesar tipos de contenido de ASP.NET similares a IIS 6.0. Puede comprobarlo si analiza la sección de controladores en system.web­Server en el archivo applicationHost.config, que puede encontrar de forma predeterminada en la carpeta %WinDir%\­System32\InetSrv\Config.

Busque la cadena aspx a modo de ejemplo y encontrará una entrada que señala a PageHandlerFactory-Integrated (cargado en los procesos de trabajo de grupo de aplicaciones en modo integrado según el parámetro preCondition="integratedMode") y otras entradas que señalan a PageHandlerFactory-ISAPI-2.0 y a PageHandlerFactory-ISAPI-2.0-64 (cargados en los procesos de trabajo de grupo de aplicaciones en modo clásico según el parámetro preCondition="classicMode").

Ya que el modo de canalización se establece a nivel de grupo de aplicaciones, IIS 7.0 puede ejecutar aplicaciones web en los modos integrado y clásico a la vez. Los procesos de trabajo sólo necesitan ejecutarse en diferentes grupos de aplicaciones, pero se pueden hospedar en el mismo servidor.

Recuerde que los modos integrado y clásico sólo afectan a la forma en que IIS 7.0 integra ASP.NET en la canalización de solicitudes. Estos modos de canalización no afectan a las aplicaciones PHP de forma directa. FastCgiModule y el resto de los módulos nativos se cargan sin condiciones previas relacionadas con el modo de canalización en los modos integrado y clásico. FastCGI es la interfaz preferida para ejecutar el motor de scripting PHP en IIS 7.0. En lugar de usar FastCGI, puede crear también una asignación de controlador para el motor de scripting PHP mediante CGI, o puede usar IsapiModule junto con PHP-ISAPI (php4isapi.dll).

No obstante, en mi opinión, estas alternativas de configuración al estilo de IIS 6.0 han quedado desfasadas ahora que FastCGI rendimiento y estabilidad muy superiores. CGI es más lento, ya que IIS debe inicializar un nuevo proceso CGI para cada solicitud HTTP, mientras que FastCGI usa repetidamente los procesos de CGI para varias solicitudes. ISAPI necesita una compilación de PHP seguro para subprocesos, que implica una sobrecarga mayor que la ejecución de PHP no seguro para subprocesos.

Probablemente sea más importante todavía el hecho de que no todas las extensiones PHP están disponibles en una versión segura para subprocesos, y que no es recomendable la ejecución de extensiones no seguras para subprocesos con ISAPI, ya que puede provocar problemas de estabilidad en el servidor. FastCGI, por otro lado, es un entorno de concurrencia única, como CGI. Se usa para ejecutar versiones de PHP no seguras para subprocesos. FastCGI es estable, rápido e ideal para PHP 5 en IIS 7.0. También está disponible en IIS 6.0 si no está listo aún para el cambio a IIS 7.0.

Módulos y funcionalidad

IIS 7.0 dispone de una arquitectura altamente modularizada (o, desde el punto de vista de los desarrolladores de IIS, de un conjunto de características formado por componentes). Esto es algo positivo para los administradores web, que desean mantener la superficie de memoria y la superficie de ataque de IIS 7.0 tan pequeñas como se pueda. Al habilitar diferentes módulos, o incluso sustituir los módulos estándares con módulos personalizados, puede obtener control total sobre las características de IIS 7.0 de los servidores web.

Si desea ejecutar ASP.NET en modo integrado o clásico, así como aplicaciones PHP en el mismo servidor, deberá instalar, como mínimo, la función de servidor web y los módulos principales para admitir el procesamiento de solicitudes, la configuración de servidores, ASP.NET, ISAPI y CGI (que incluye el módulo FastCGI). Esto se puede conseguir mediante la siguiente línea de comandos:

start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI

Generalmente, prefiero instalar IIS 7.0 con todas las opciones disponibles en el servidor provisional con el fin de asegurarme de que todos los componentes y las herramientas administrativas están disponibles para hacer que mis aplicaciones web estén listas lo antes posible. Mi estrategia consiste en asegurarme de que todo funciona correctamente y, a continuación, limito la configuración mediante la desinstalación de servicios de función y la deshabilitación de módulos. Cuando una aplicación web empieza a dar problemas, agrego de nuevo los servicios de función o los módulos que eliminé.

También puede usar Package Manager (pkgmgr.exe) o la herramienta de línea de comandos de IIS 7.0 (appcmd.exe), o modificar la sección globalModules en el archivo applicationHost.config directamente, pero creo que las herramientas gráficas son muy útiles. Recuerde que algunos módulos, como RequestFilteringModule y StaticCompressionModule, son bastante útiles, incluso aunque no son, en sentido estricto, necesarios para la ejecución de las aplicaciones web. Al desinstalar un módulo necesario para un grupo de aplicaciones, recibirá un error HTTP al tratar de obtener acceso a la aplicación web, como se muestra en la Figura 5.

Figura 5 Una aplicación ASP.NET no se ejecutará en modo clásico si no puede encontrar IsapiModule (haga clic en la imagen para ampliarla)

Nota: a modo de práctica recomendada, asegúrese de que el mismo grupo de módulos está instalado y habilitado para todos los servidores de IIS 7.0. Si desea consultar los componentes instalados, visite HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\y compruebe las claves del Registro. Un valor REG_DWORD de 0000 0001 para una clave del Registro, por ejemplo, para NetFxEnvironment o CGI, muestra que el componente correspondiente está instalado.

Migración de aplicaciones web

Ya vale de teoría; llegó la hora de ponerse en acción y mover algunas aplicaciones web a IIS 7.0. Como ya dije anteriormente, mi servidor provisional ejecuta IIS 7.0 con todos los componentes disponibles y la versión PHP 5 no segura para subprocesos registrada con FastCGI. Antes de empezar, necesito hacer un par de preguntas básicas:

• ¿Necesita la aplicación web un sistema de administración de bases de datos, como SQL Server o MySQL?
• ¿Necesito instalar o configurar componentes adicionales, como conexiones ODBC, objetos COM o certificados SSL?
• ¿Necesita la aplicación web cuentas de servicio especiales y permisos locales o de acceso remoto elevados para el acceso a recursos compartidos de archivos, entre otros?
• ¿Hay alguna dependencia en las características específicas de plataforma que no están disponibles en IIS 7.0, como dependencias en el módulo Apache para la reconfiguración de direcciones URL (mod_rewrite)?

Preguntas como estas le permitirán conseguir que sus aplicaciones web se ejecuten correctamente en IIS 7.0 con mayor rapidez. Por ejemplo, al intentar la migración de una aplicación PHP de Apache 2.2 que use mod_rewrite (por ejemplo, para facilitar el uso de motores de búsqueda o para evitar el robo de ancho de banda mediante imágenes vinculadas en línea), experimentará problemas hasta que implemente una solución de reconfiguración de direcciones URL personalizada compatible en IIS 7.0. Por suerte, osCommerce no necesita la funcionalidad de mod_rewrite en IIS 7.0, pero tal vez algunos paquetes de optimización de motores de búsqueda lo hagan.

Ahora que he determinado e instalado los componentes adicionales necesarios en el servidor provisional, ya puedo poner en funcionamiento mis aplicaciones web. Una vez más, me hago a mí mismo algunas preguntas:

• ¿Cuál es la configuración más simple que puedo usar para tener compatibilidad con la aplicación web?
• ¿Qué configuración se usa actualmente en el entorno de producción?
• ¿Puedo optimizar la configuración de la aplicación web en la nueva plataforma?
• ¿Cuál es el conjunto mínimo de servicios y módulos de función que necesita la aplicación web para funcionar con la configuración deseada?

La ejecución de la aplicación web con la configuración más sencilla constituye la forma más rápida de asegurarse de que realmente funciona. Si todo parece correcto, es el momento de aplicar una configuración parecida al entorno de producción existente e importar datos de producción en bases de datos de prueba. Por supuesto, puede que algunos problemas sólo surjan en las configuraciones avanzadas.

También puede observar oportunidades para introducir mejoras al reflejar la configuración de producción en un laboratorio de pruebas. La colocación del archivo applicationHost.config en un recurso compartido de UNC es una gran forma de centralizar la configuración de varios servidores web. Para aumentar la tolerancia a errores mediante la redundancia y la sincronización de contenido, considere la implementación de la replicación del sistema de archivos distribuido (DFS), que consiste en un motor de replicación con varios maestros basado en estados y está disponible con Windows Server 2003 R2 y Windows Server 2008. Además, puede reducir los requisitos de almacenamiento en los clientes web si coloca los archivos de contenido de sus aplicaciones web en recursos compartidos de UNC.

Otras posibles optimizaciones pueden suponer seguridad o almacenamiento dinámico en caché. Las optimizaciones de seguridad y de rendimiento no estaban entre los objetivos de mi laboratorio de pruebas, ya que no se encuentran dentro del alcance de este artículo. Tampoco configuré DFS para evitar la instalación de otros servidores. Las instrucciones paso a paso del material complementario ofrecen un ejemplo simplificado de cómo hospedar un archivo applicationHost.config y contenido web en recursos compartidos de UNC. La Figura 6 muestra cómo implementar una granja de servidores web basada en UNC con DFS.

Figura 6 Implementación de granjas de servidores web con un archivo applicationHost.config y contenido web en recursos compartidos de UNC (haga clic en la imagen para ampliarla)

Conclusión

IIS 7.0 es una plataforma de servidor web impresionante. Incluye una arquitectura de núcleo rediseñada a la vez que conserva casi el 100% de la compatibilidad con IIS 6.0. Debería ser capaz de ejecutar la mayoría de las aplicaciones web ASP.NET existentes sin necesidad de realizar cambios. No obstante, dada la amplitud de los cambios arquitecturales, no puede dar por hecho que no encontrará problemas de compatibilidad.

Tanto si está migrando aplicaciones web ASP.NET como PHP a IIS 7.0, es mejor adoptar un enfoque organizado y probado con énfasis en operaciones adecuadas de planeación, preparación, pruebas y documentación de código y cambios de configuración.

IIS 7.0 merece la pena. Hay muchas mejoras en áreas como la seguridad, el rendimiento, la facilidad de configuración y la flexibilidad. Haría falta un libro entero para hablar de todas ellas. La configuración centralizada y el uso compartido de contenido con base a los recursos compartidos de UNC, la configuración delegada a través de archivos web.config en directorios de aplicaciones, las herramientas de administración mejoradas, la información de diagnóstico detallada, el seguimiento de solicitudes con error y el almacenamiento dinámico en caché de resultados son formas infalibles de ganarse el afecto de los administradores web.

La capacidad de combinar módulos nativos y administrados en la canalización de procesamiento de solicitudes beneficia a los desarrolladores de ASP.NET. Las mejoras de rendimiento y estabilidad que se incluyen con FastCGI en IIS 7.0 son noticias fantásticas para los desarrolladores de aplicaciones PHP.

Hay otro aspecto importante que ayuda a los profesionales de TI a triunfar con IIS 7.0: el portal de la comunidad Microsoft IIS (www.iis.net). Aquí encontrará toda la información que necesita, incluidos artículos detallados acerca de la nueva arquitectura, código fuente para los desarrolladores de C++ y ASP.NET que muestra cómo crear módulos de IIS 7.0 e instrucciones paso a paso para poner en funcionamiento las aplicaciones PHP. Definitivamente, debería visitar este sitio. Es un buen sitio para obtener las respuestas a sus preguntas relacionadas con IIS.

Fergus Strachan es fundador y director de Maestra Ltd London, una empresa de asesoría especializada en el diseño de infraestructura de TI y el apoyo a la administración de proyectos, que ofrece servicios a bancos internacionales e instituciones educativas en el Reino Unido. Escribe artículos acerca de la tecnología de servidores de Microsoft y es autor de Integrating ISA Server 2006 with Microsoft Exchange 2007. También es coautor de Microsoft Exchange Server 2003 Resource Kit.

© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.