Predicción de ancho de banda de cliente de Exchange: el problema de la zona horaria
Artículo original publicado el miércoles 20 de junio de 2012
Actualización del 22/06/12 Este artículo y la descarga que lo acompaña se han actualizado.
La última actualización de la Calculadora del ancho de banda de red de cliente de Exchange incluye varias actualizaciones, pero puede que la más significativa sea el soporte técnico de zona horaria. Llevo planteándome cómo tratar el problema de la zona horaria los últimos 12 meses y me ha llevado mi tiempo encontrar una solución práctica. Pero estoy adelantando acontecimientos, así que primero veamos en qué consiste realmente el problema de la zona horaria.
¿En qué consiste el problema de la zona horaria?
Daré por supuesto que todo el mundo sabe lo que son las zonas horarias y por qué existen, pero para aquellos que deseen obtener más información al respecto, recomiendo el artículo de Wikipedia siguiente:
https://en.wikipedia.org/wiki/Time_zone
Desde una perspectiva de predicción de ancho de banda de red, el problema con las zonas horarias se presenta cuando se trata de modelar cargas de trabajo de usuarios de diferentes partes del mundo que comparten o la misma conexión de red o el mismo servicio de cliente web. Esto supone un problema, ya que las hora punta de uso para la mayor parte de los clientes depende de su zona horaria local.
Por ejemplo, si analizamos un día laborable normal en una organización media de 1000 usuarios, se observan dos picos típicos: uno por la mañana, alrededor de las 10.00, que dura 2 horas, y otro posterior, por la tarde, alrededor, de las 14.00, que dura 4 horas. Cuando se traza esto, tiene el siguiente aspecto:
Ahora imaginemos que se están modelando los requisitos para 5 ubicaciones diferentes de todo el mundo, cada una de ellas con 1000 usuarios que con acceso a un recurso compartido de Nueva York. Llegados a este punto, asumamos que el recurso compartido es un equilibrador de carga local con Exchange 2010 (he optado por escoger un ejemplo local, para variar)
- Londres (GMT) = 1000 usuarios
- Varsovia (GMT+1) = 1000 usuarios
- Yakarta (GMT+7) = 1000 usuarios
- Redmond (GMT-8) = 1000 usuarios
- Nueva York (GMT-5) = 1000 usuarios
Si modelamos esto usando la técnica heredada para predecir el pico para cada conjunto de usuarios y juntarlos a todos, llegamos a lo siguiente:
Lo que muestra este gráfico es que cada sitio de 1000 usuarios solo necesitó aproximadamente 1,56Mbits/seg. de ancho de banda en su pico diario, de modo que cuando los juntamos a todos para representar a todos los usuarios que comparten el equilibrador de carga de Nueva York, obtenemos un requisito de pico de 7,81Mbits/seg. Así es como hemos trabajado siempre con la planificación de ancho de banda para usuarios distribuidos: se predicen sus requisitos de pico y después se incluyen todos en una tabla y se agrupan.
El problema aquí es que los usuarios de Europa se estarán yendo a casa cuando los usuarios de Redmond se estén despertando y los de Yakarta estén todavía arropados en sus camas.
Si tomamos en consideración la zona horaria de estos sitios, el gráfico cambia considerablemente:
Este gráfico muestra cómo se combinarían realmente las cargas de trabajo para formar un perfil de uso muy distinto del que siempre se había planeado. Lo verdaderamente interesante de este aspecto es que el pico de la carga de trabajo es ahora muy inferior, solo de 3,78Mbits/seg. (la predicción original era de 7,81Mbits/seg.). El perfil de uso también difiere mucho del que se había predicho en un principio.
¿Cómo puede afrontarse este problema?
Como habrá podido deducir de los gráficos anteriores, se ha extendido la calculadora de red para permitirle incluir la información de zona horaria.
Lo que se hizo en realidad para lograr esto fue abandonar la idea de predecir solo un pico de carga de trabajo y predecir en su lugar el uso de ancho de banda por hora del día basándose en los patrones de uso proporcionados, como el pico de la mañana, el pico de la tarde, etc. Esto permite a la calculadora no solo saber cuándo se producirá su pico de uso, sino también cuál será el uso durante el resto del día. Una vez se conoce esta curva, se hace posible agrupar los datos relativos a las zonas horarias.
¿Se lleva a cabo realmente esta consolidación unificada?
La respuesta más sencilla a esta pregunta es que sí: muchas organizaciones consolidan las cargas de trabajo en la mayor medida posible. Esto necesita que los equipos de diseño planifiquen cargas de trabajo de servicio de usuarios muy distribuidos, a menudo con diferentes perfiles y en diferentes zonas horarias. Esto es especialmente habitual en lugares en los que la carga de trabajo se mueve a la nube, ya que Office 365 solo proporciona ubicaciones de inquilinos regionales unificadas. Así, una organización internacional que usa Office 365 tendrá que planificar que una gran proporción de sus usuarios obtenga acceso al servicio en regiones y zonas horarias totalmente distintas, normalmente con una infraestructura compartida.
Muchos de mis clientes están consolidando también multitud de centros de datos más pequeños a centros de datos inferiores en cantidad pero de mayor tamaño. Es recomendable que estos sitios consolidados puedan manejar la carga de trabajo de los usuarios previamente distribuidos. A menudo, estos usuarios estarán en diferentes zonas horarias, de modo que, cuando se trata de acomodar su carga de trabajo, se necesita un modo de averiguar cómo se combinarán con otras cargas de trabajo distribuidas.
Evidentemente, si todos los usuarios están en la misma zona horaria, no tendrá por qué preocuparse de todo esto y podrá usar la calculadora normalmente.
Uso de la nueva función de zona horaria
Vale, pongamos que su escenario necesita soporte técnico de zona horaria: ¿cómo diablos se usa esta nueva función?
Lo primero es lo primero: se ha de configurar la tabla TimeZone en la hoja de entrada. Los parámetros introducidos aquí controlan la forma de la curva de uso que combina las cargas de trabajo. Los valores han de reflejar los patrones de uso medio de su organización, Para hacer esto, yo suelo echar un vistazo a los datos de rendimiento de los servidores Exchange en ejecución, además de preguntarle al cliente cómo cree que trabajan sus usuarios y cuáles son sus horas de máxima actividad.
Una vez completada la hoja de entrada, pasamos a la hoja de composición del cliente, en la que hay dos áreas más para configurar los datos de zona horaria.
En primer lugar está la Zona horaria modelo, que representa la zona horaria del recurso para el que estamos realizando la planificación, es decir, el vínculo de red o el equilibrador de carga. En el ejemplo anterior se puede apreciar que se ha establecido la zona horaria modelo sea GMT-5 para Nueva York, que es donde estaba nuestro equilibrador de carga.
En segundo lugar tenemos una columna nueva llamada TimeZone. Representa la zona horaria de cada sitio individual relativo a la hora GMT (nótese que yo soy británico y aquí he usado GMT, pero en el futuro podría cambiarla a UMC si recibo suficientes quejas).
La predicción resultante se muestra en un gráfico bajo la tabla de composición del cliente, tal como se ha expuesto anteriormente. Los valores de esta tabla son Mbits/seg. y representan el uso de red predicho a cada hora del día.
Una ventaja añadida
Otra función útil es que la calculadora proporcionará una tabla que puede copiarse a la Calculadora de rol del buzón para facilitar la predicción de replicación de red de DAG.
Si se sitúa a la derecha del gráfico de predicción (Hoja de composición del cliente) de la Calculadora de red verá una tabla con tantos por ciento de cambios por hora del día. Si copia esto en su portapapeles ocurrirá lo siguiente:
Ahora vaya al final de la Hoja de entrada de la Calculadora de rol del servidor del buzón; ahí encontrará una tabla para la Configuración de la replicación del registro. Pegue las cifras de la Calculadora de red en esta tabla.
Ya lo tiene: la Calculadora de rol del servidor ya está lista para predecir los requisitos de ancho de banda para la replicación de DAG teniendo en cuenta tanto los datos de su organización como la configuración de zona horaria.
Conclusión
Espero que esta nueva función facilite una predicción más exacta de los requisitos de ancho de banda. No es necesaria para todas las implementaciones, pero espero que sea de ayuda para todos los arquitectos de grandes empresas que estén teniendo dificultades con el problema de la zona horaria.
Continúe proporcionando sus valiosos comentarios, tanto positivos como negativos, a la dirección netcalc@microsoft.com. Nos encanta leer sus comentarios.
Neil Johnson
Consultor sénior, MCS UK
Esta entrada de blog es una traducción. Puede encontrar el artículo original en Exchange Client Bandwidth Prediction – the time zone problem…