Descripción de varias configuraciones del rol del servidor en la planificación de capacidad

  • Artículo

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2016-11-28

Se aplican varias tendencias en hardware de servidor al margen de tiempo de Microsoft Exchange Server 2010. Una de ellas es el aumento considerable en rendimiento del procesador y un número creciente de núcleos del procesador instalados en un procesador físico. Esto significa que la implementación de un rol del servidor de Exchange único en un servidor de mercancía estándar con dos procesadores con varios núcleos podría dejar una gran parte de la CPU disponible sin uso pleno. Algunos clientes esperan que la virtualización de servidores use los recursos de la CPU del servidor de manera más eficaz. Otros clientes desean combinar roles del servidor de Exchange en el mismo servidor físico. Ambas son soluciones válidas.

Otra tendencia es la disponibilidad de modelos de servidor con procesadores con varios núcleos y de 10 a 16 discos internos. Si considera el número de buzones de correo que las transacciones de entrada/salida por segundos (IOPS) proporcionadas por 10 a 16 discos admiten, observará que, por lo general, el rol de servidor de buzón de correo en sí mismo no utiliza más de la mitad de los recursos de la CPU disponibles. El agregado de los roles de servidor Acceso de clientes y Transporte de concentradores en este servidor usará la capacidad del servidor con mayor eficacia.

Puede usar la información de este tema como guía para saber cuándo implementar configuraciones de varios roles del servidor y cómo planear correctamente esas configuraciones. Un ejemplo ilustra el proceso de determinación del tamaño de servidores con varios roles.

Contenido

Motivos para recomendar configuraciones de varios roles

Cuándo se recomiendan configuraciones de varios roles

Cuándo no se recomiendan las configuraciones de varios roles

Recomendaciones de hardware para servidores con varios roles

Implementación de un servidor con varios roles en un DAG

Ejemplo de determinación del tamaño para un escenario de varios roles de Exchange 2010

Motivos para recomendar configuraciones de varios roles

En primer lugar, el hardware que se adquiere hoy en día tiene procesadores extremadamente rápidos que producen entre 5000 y 6000 megaciclos, en comparación con nuestra configuración de procesador de línea de base. Esta configuración consiste en procesadores Intel Xeon x5470 a 3,33 GHz de 2 x 4 núcleos. (Puede consultar más información sobre nuestra configuración del procesador de línea de base en la sección en la que se presenta un ejemplo de planificación de la capacidad de un servidor de buzón en Planificación de la capacidad del procesador del servidor buzones de correo). Si tuviera que cambiar la arquitectura de procesadores de su entorno con procesadores que se encuentran en el mercado actual, y mantener al mismo tiempo los factores de entorno, observaría una disminución significativa del uso del procesador.

Para disminuir efectivamente el costo total de propiedad en los servidores que compra, debe garantizar un uso eficaz del sistema, lo que significa que este debe conseguir y mantener prácticamente un 80 por ciento de uso de la CPU durante el peor caso de modo de error en un momento de carga máxima. A continuación, indicamos cuatro formas de utilizar eficientemente los procesadores disponibles hoy:

  • Aumentar la carga de trabajo, implementando más buzones de correo activos por servidor.

  • Introducir una capa de virtualización e implementar el rol de buzón como máquina invitada, junto con máquinas invitadas adicionales.

  • Implementar roles de servidor de Exchange adicionales en el sistema.

  • Use una combinación de las metodologías anteriores para encontrar la configuración óptima que utiliza el hardware de la forma más eficiente posible.

Implementar Exchange 2010 con una arquitectura de varios roles ofrece varias ventajas:

  • La arquitectura de varios roles se convierte en una arquitectura basada en bloques de creación. Con la arquitectura de varios roles, todos los servidores del entorno de Exchange (excluida la mensajería unificada y el transporte perimetral) son exactamente iguales: el mismo hardware, la misma configuración, etc. Esta uniformidad simplifica la ordenación de hardware, así como el mantenimiento y la administración de los servidores.   

    • Desde el punto de vista de los costos, el objetivo general es garantizar que la arquitectura esté equilibrada, tanto desde la perspectiva de la CPU como desde una perspectiva de disco. Desplegar roles de servidor en máquinas diferentes puede ser costoso a largo plazo, ya que es posible que compre más CPU, discos y recursos de memoria de lo que realmente vaya a utilizar. Por ejemplo, tomemos el caso de un servidor que hospede únicamente el rol de servidor de acceso de cliente. Muchos servidores permiten agregar un número determinado de discos a un precio muy económico. Cuando se implementa este número de discos y, más importante aún, cuando se utilizan, el costo es prácticamente de cero. Sin embargo, si implementa un rol de servidor que utiliza mucho menos que el número de discos indicados, está pagando por un controlador de discos que está infrautilizado o simplemente no se utiliza.

  • En muchos casos, si usa una arquitectura de varios roles, podrá tener menos servidores de Exchange físicos en el entorno. Si tiene menos servidores físicos, los costos serán más bajos por una serie de razones:

    • Los gastos operacionales son casi siempre superiores a los gastos de capital. Cuesta más administrar la vida útil de un servidor que su compra.

    • Se compran menos licencias de servidor de Exchange. Un servidor con varios roles solamente necesita una licencia para un servidor de Exchange y un sistema operativo, mientras que si se desglosan los roles, se necesitan varias licencias de servidor de Exchange y, probablemente, varias licencias de sistema operativo. Para obtener más información, consulte Acerca de las licencias: licencias para entornos virtuales (probablemente en inglés).

    • La implementación de menos servidores repercute en el resto de la infraestructura. Por ejemplo, si se implementan menos servidores físicos, es posible que se reduzca el espacio de bastidor y de suelo total para la infraestructura de Exchange, lo que a su vez reduce los costos de energía y refrigeración.

  • Una arquitectura de varios roles acaba distribuyendo la carga entre un gran número de servidores, en vez de implementar servidores de rol único, ya que todos los servidores de buzones se convierten también en servidores de transporte de concentradores y servidores de acceso de cliente.  Esta arquitectura aporta dos ventajas:

    • Desde el punto de vista de la escalabilidad, la carga se distribuye entre un mayor número de máquinas físicas. En caso de producirse un evento de error, el aumento de la carga en los servidores restantes solamente será incremental, lo que garantiza que las demás funciones que está ejecutando el servidor no se vean afectadas negativamente.

    • Desde el punto de vista de la resistencia, la solución puede sobrevivir a un mayor número de errores de rol (o servicio) de acceso de cliente o de transporte de concentradores y seguir proporcionando servicio.

Por este motivo, en la mayoría de casos recomendamos que, para Exchange 2010, se implemente una estrategia de configuración de servidor con varios roles.

Cuándo se recomiendan configuraciones de varios roles

Las configuraciones de varios roles se recomiendan en la mayoría de casos por los siguientes motivos:

  • Unidad de escala sencilla   Las organizaciones que prevén un crecimiento regular de la cantidad de buzones de correo deben considerar la implementación de servidores con varios roles. Debido a que cada servidor con varios roles representa un bloque de creación, este modelo permite agregar fácilmente bloques de creación para sustentar la necesidad de mayor capacidad.

  • Implementaciones a gran escala que desean sacar provecho de los procesadores modernos   Según una prueba de escalabilidad efectuada antes de la versión RTM (solo para fabricante) de Exchange 2010, los servidores con varios roles pueden, de manera efectiva, usar procesadores de núcleo hexadecimal (o más) en un único servidor. Esta funcionalidad permite que las organizaciones grandes reduzcan la cantidad de servidores al combinar los roles de servidor Buzón de correo, Transporte de concentradores y Acceso de cliente en lugar de implementar estos roles de manera independiente en servidores con menos núcleos de procesador. Este enfoque saca provecho del modelo de bloques de creación descrito anteriormente para brindar una plataforma para implementaciones a gran escala mientras y, al mismo tiempo, reducir la cantidad total de servidores requeridos. La escalabilidad de la configuración de varios roles en sistemas de número de núcleos más grandes debería validarse con pruebas de laboratorio antes de la implementación de producción.

  • Implementaciones de servidor con almacenamiento interno   En la actualidad, existen muchos servidores disponibles con dos procesadores con varios núcleos físicos y de 10 a 16 discos internos. Varias mejoras en Exchange 2010 han reducido los requisitos de E/S, lo que convierte a estos servidores en una solución rentable. En función del perfil de usuario y del tipo de disco, estos servidores admitirán, en general, hasta 4000 buzones de correo. Se recomienda agregar roles de servidor Acceso de clientes y Transporte de concentradores a estos servidores a fin de usar la CPU adicional y convertir los servidores en bloques de creación independientes.

  • Escenarios de reducción de riesgos en los que se limita la cantidad de buzones de correo hospedados en el servidor de buzones de correo   Los servidores con varios roles son una solución para las implementaciones en las que las directivas de administración del riesgo limitan la cantidad de buzones de correo que se pueden implementar en un servidor de buzones de correo. Por ejemplo, una organización con 10000 buzones de correo tiene una directiva que indica que la interrupción de un único servidor no puede afectar a más del 25 por ciento de los buzones de correo del entorno. Este requisito limita la cantidad de buzones por servidor de buzones de correo a 2500. La capacidad adicional de ese servidor se podría usar para agregar los roles de servidor de acceso de clientes y de transporte de concentradores al servidor.

  • Implementaciones en sucursales y pequeñas organizaciones   Salvo lo indicado anteriormente, cuando se usa el equilibrio de carga de red de Windows, se recomienda una implementación de varios roles para las implementaciones en las que los principales objetivos son minimizar el número de servidores físicos, las instancias de sistema operativo y los servidores de Exchange que se desean administrar. La ejecución de los roles de servidor Acceso de clientes, Transporte de concentradores y Buzón de correo en el mismo servidor físico brinda la redundancia de roles necesaria con un requisito mínimo de dos o tres servidores físicos.

Motivos para recomendar configuraciones de varios roles

Cuándo no se recomiendan las configuraciones de varios roles

Las configuraciones de varios roles no se recomiendan en los escenarios siguientes:

  • Implementaciones en organizaciones pequeñas o sucursales que deseen utilizar el equilibrio de carga de red de Windows (NLB)   Es posible que los servidores con varios roles no funcionen bien en implementaciones pequeñas en las que se implementan dos o tres servidores con varios roles como miembros de un grupo de disponibilidad de base de datos (DAG). Para obtener más información acerca de los DAG, consulte Administración de grupos de disponibilidad de base de datos. El componente de clúster que se agrega a los servidores de buzones de correo que son miembros de un DAG impide la instalación de NLB en ese servidor. Para obtener más información acerca de las recomendaciones de equilibrio de carga, consulte Descripción del equilibrio de carga en Exchange 2010. Sin embargo, aún existe un requisito para equilibrar la carga del tráfico entrante en los servidores de acceso de cliente. En este caso, existen dos opciones principales:

    • Adquirir un dispositivo de equilibrio de carga de hardware. Aunque existen algunos dispositivos de NLB básicos, esta opción puede resultar costosa, en especial para entornos pequeños.

    • Virtualizar los roles del servidor de Exchange. En algunos entornos en los que se dispone de un número limitado de servidores, es preciso implementar controladores de dominio, servidores de archivo e impresión, y otras aplicaciones en el mismo hardware físico que los servidores de Exchange 2010. Se recomienda la implementación de servidores físicos como servidores host y el aislamiento de las aplicaciones dentro de un entorno virtual. Con este aislamiento, puede ejecutar NLB en los servidores de acceso de cliente que se ejecutan en máquinas virtuales.

  • Virtualización   El número máximo de servidores activos que una máquina virtual puede albergar se puede reducir en función de la combinación de perfil de mensaje y ejecución en una configuración de varios roles. Si los usuarios utilizan la mensajería de vez en cuando, poner roles de servidor en una máquina virtual puede tener sentido. No obstante, si los usuarios utilizan con frecuencia la mensajería, es posible que los recursos estén limitados en la máquina virtual y, por consiguiente, tenga que reducir el número de buzones por máquina virtual de buzones o dividir los roles entre varias máquinas virtuales diferentes. En estos casos, es posible que sea más eficaz implementar un único rol del servidor de Exchange en cada máquina virtual o implementar una máquina virtual con roles de acceso de cliente y de transporte de concentradores combinados para cada máquina virtual de servidor de buzones.

    Nota

    No se puede instalar un rol de servidor de Exchange en el servidor host de hypervisor. En los servidores host, solo se puede implementar software de administración (por ejemplo, software antivirus, software de copia de seguridad o software de administración de máquinas virtuales). No se debe instalar ninguna otra aplicación basada en servidor (por ejemplo, Exchange, Microsoft SQL Server o Active Directory) en el servidor host. Los servidores host se deben destinar a la ejecución de máquinas virtuales invitadas.

Para obtener más información, consulte Descripción de las configuraciones combinadas de los roles Acceso de cliente y Transporte de concentradores en la planificación de capacidad.

Motivos para recomendar configuraciones de varios roles

Recomendaciones de hardware para servidores con varios roles

Como regla general, se debe determinar el tamaño de un servidor con varios roles de manera que use la mitad de los núcleos del procesador disponibles para el rol de servidor de buzones y la mitad restante para los roles de servidor de acceso de clientes y transporte de concentradores. Microsoft no especifica una cantidad máxima de núcleos de procesador recomendados para servidores con varios roles. En cambio, se proporciona un número máximo de sockets de procesador rellenados. Esto se refiere a la cantidad de sockets de procesador en la placa base en la que están conectados los procesadores con varios núcleos. Para obtener más información, consulte Descripción de configuraciones de procesador y rendimiento de Exchange.

Además de determinar el tamaño de la arquitectura de procesador, es preciso que el tamaño de la memoria sea correcto para implementar una configuración de varios roles. Para obtener más información, consulte Descripción de configuraciones de memoria y rendimiento de Exchange.

Implementación de un servidor con varios roles en un DAG

Cuando se implementan servidores de buzones de correo de un rol en un DAG, es necesario tener en cuenta la planificación de capacidad para errores de un único o varios servidor en relación a la carga del servidor de buzones de correo. Si dispone de cuatro servidores de buzón de correo en un DAG, determine el tamaño de los servidores de buzones de correo en 50 por ciento de la capacidad para que puedan hospedar el doble de usuarios activos en caso de un error simultáneo de dos servidores de buzón de correo. Debido a que los servidores de transporte de concentradores y de acceso de cliente se encuentran en servidores físicos distintos, la pérdida de uno o dos servidores de buzón de correo no afecta demasiado la carga de esos servidores.

Cuando se implementan servidores con varios roles en un DAG, es necesario tener en cuenta la planificación de capacidad para la carga de los servidores de acceso de cliente, de transporte de concentradores y de buzones. Si dispone de cuatro servidores con varios roles en un DAG, asegúrese de contar con capacidad suficiente para hospedar una posible duplicación de la carga de los servidores de transporte de concentradores y de acceso de cliente. Debido a que la configuración de varios roles se alinea con las proporciones de núcleo de procesador recomendadas para los roles de servidor, si ha determinado correctamente el tamaño de las bases de datos activas máximas del rol del servidor de buzones, los servidores de transporte de concentradores y de acceso de cliente deberían cumplir con los objetivos de rendimiento de este escenario.

Motivos para recomendar configuraciones de varios roles

Ejemplo de determinación del tamaño para un escenario de varios roles de Exchange 2010

En el ejemplo siguiente se muestra el proceso de determinación del tamaño de servidores con varios roles. En el ejemplo se consideran los siguientes supuestos de diseño:

  • Número total de buzones   24.000

  • Perfil de buzones   100 mensajes por día (por ejemplo, 20 enviados y 80 recibidos)

  • Caché de la base de datos por buzón de correo   6 MB (en función de un perfil de 100 mensajes por día)

  • Requisitos de disponibilidad   Resistencia de buzón de correo en un sitio único; protección contra errores simultáneos de tres copias de base de datos y dos servidores

  • Requisitos de la base de datos   120 bases de datos en el DAG, 200 buzones de correo por base de datos

  • Plataforma del servidor   Servidor (X5650) basado en un procesador a 2,26 gigahercios (GHz) de 2 x 6 núcleos (12 núcleos)

Se aplica el proceso siguiente:

  1. Cálculo del número de servidores   Se necesita un DAG de cuatro nodos como protección contra el error simultáneo de dos servidores. No obstante, el cliente ha decidido implementar seis servidores para controlar la cantidad máxima de buzones activos durante un evento de error de servidor doble. Por lo tanto, el diseño empieza con seis servidores de correo dentro del DAG.

  2. Cálculo de la cantidad máxima de buzones activos por servidor basado en el modelo de activación   Presuponiendo que las bases de datos activas están distribuidas homogéneamente entre los nodos, cada servidor puede albergar en el mejor de los casos, 4000 buzones activos (24000 ÷ 6). Para calcular la cantidad de buzones activos después de un error de doble nodo (basado en este ejemplo), se divide la cantidad de buzones por los cuatro nodos restantes, lo que da 6000 buzones activos por nodo (24000 ÷ 4).

    En este ejemplo, el parámetro MaximumActiveDatabases en el cmdlet Set-MailboxServer se ha configurado en 30 para asegurar que no más del 40 por ciento de las bases de datos pasen a estar activas en un solo servidor.

  3. Calcule los requisitos de CPU del buzón de correo activo   Multiplique el número máximo de buzones de correo activos en un servidor por los megaciclos por buzón de correo activo (6.000 × 2 megaciclos = 12.000 megaciclos), según la tabla IOPS estimadas por buzón de correo según la actividad de mensajes y la memoria caché de base de datos del buzón de correo en Descripción de la memoria caché de la base de datos de buzones. Multiplique este valor por 10 por ciento para cada copia adicional de la base de datos.

    En este ejemplo, hay una sola copia activa y tres copias pasivas para cada base de datos, por lo cual los 12000 megaciclos aumentan en 30 por ciento (12000 × 1,3 = 15600 megaciclos). Para obtener más información, consulte "Métrica de la memoria caché de base de datos" en Descripción de la memoria caché de la base de datos de buzones.

  4. Calcule los requisitos de CPU del buzón de correo pasivo   Multiplique el número de buzones de correo pasivos (cuando un servidor hospeda el número máximo de buzones de correo activos) por los megaciclos por buzón pasivo (10.000 × 0,3 megaciclos = 3.000 megaciclos), según la tabla IOPS estimadas por buzón de correo según la actividad de mensajes y la memoria caché de base de datos del buzón de correo en Descripción de la memoria caché de la base de datos de buzones. Para obtener más información, consulte "Métrica de la memoria caché de base de datos" en Descripción de la memoria caché de la base de datos de buzones.

  5. Suma de los requisitos de CPU activos y pasivos para obtener los requisitos de CPU totales   En este ejemplo, 15.600 megaciclos de buzón de correo activo + 3.000 megaciclos de buzón de correo pasivo = 18.600 megaciclos de requisitos de CPU totales.

  6. Aplicación de los requisitos de CPU de buzón a la plataforma de hardware   En este ejemplo se usa un servidor (x5650) basado en un procesador a 2,26 GHz de 2 x 6 núcleos. Basándose en la orientación de Planificación de la capacidad del procesador del servidor buzones de correo, esto equivale a 60083 megaciclos. Divida los megaciclos requeridos por los megaciclos disponibles basándose en la plataforma de servidor para estimar la utilización de la CPU en el período de pico después de un error de doble nodo (18600 ÷ 60,083 = 31 (predicción del uso de la CPU)).

    Se recomienda que la parte del rol de servidor de buzones de configuraciones de varios roles disponga de un diseño que no supere el 40 por ciento de uso durante los períodos pico (por ejemplo, error simultáneo de dos nodos). Este diseño permite espacio suficiente para ajustar el uso de la CPU de los roles de servidor de acceso de clientes y de transporte de concentradores, al tiempo que se mantiene el uso total de la CPU por parte del servidor en menos del 80 por ciento durante los períodos pico (por ejemplo, el error simultáneo de dos nodos).

  7. Cálculo de los requisitos de memoria para los buzones de correo activos   Multiplique el número de buzones de correo activos por la memoria caché de la base de datos necesaria por buzón de correo. En este ejemplo, con un error de servidor doble, los servidores restantes albergarán 6000 buzones activos (6000 x 6 MB) ÷ 1024 = 35,1 GB. Los requisitos de memoria caché de la base de datos se basan en el perfil del buzón de correo. Para obtener más información, consulte "Métrica de la memoria caché de base de datos" en Descripción de la memoria caché de la base de datos de buzones.

  8. Aplicación de los requisitos de memoria total en la plataforma de hardware   La memoria total requerida se basa en los requisitos de la memoria caché de base de datos y el diseño del servidor (exclusivo o de varios roles). Para obtener más información, consulte la tabla Tamaños predeterminados de la memoria caché de base de datos del buzón de correo en Descripción de la memoria caché de la base de datos de buzones. Los requisitos de memoria total para el servidor con varios roles de este ejemplo son de 52,2 GB ((4 GB + 35,1 GB) ÷ 0,75). Como 52,2 GB no es una configuración de memoria estándar, redondee a 64 GB o a la configuración de memoria más cercana que admita el servidor.

    Motivos para recomendar configuraciones de varios roles

 © 2010 Microsoft Corporation. Reservados todos los derechos.