Cuando estamos planteando migrar a Office 365, hay un aspecto que resulta fundamental, y es la conexión a Internet que tenemos.
Parece obvio que si vamos a pasar a tener todo nuestro sistema de correo fuera de la red local de la empresa, los requisitos de conectividad serán más elevados, pero a menudo vemos proyectos donde eso no se ha tenido en cuenta.
Esto no es tan inmediato como parece, ya que hay que tener en cuenta que el patrón de tráfico cambia radicalmente.
Lo vemos con un ejemplo sencillo: Si nuestro correo está albergado en un Exchange local, cuando envío un correo a diez compañeros de trabajo, ese correo no circula por Internet, y los compañeros se lo descargarán de forma local principalmente. En cambio, si nuestro servidor está alojado en la nube, el contenido del correo tendrá que salir a través de nuestra conexión a Internet, para posteriormente ser descargado al menos una vez por cada destinatario. Si es sólo texto puede que no sea un problema, pero con la tendencia actual de adjuntar documentos cada vez más grandes, podemos encontrarnos que nuestro correo se ralentice hasta la desesperación, o bien que llegue a saturar el ancho de banda.
Así pues, parece claro que necesitamos dimensionar con seguridad ese enlace.
Hemos visto casos donde aparentemente el cliente iba sobrado, pero que en un análisis más en profundidad hubiera resultado en un desastre de implantación de haberla llevado a cabo sin cambios.
Para evitar problemas durante o después de la migración, vamos a explicar cómo calcular nuestras necesidades de ancho de banda.
En otros artículos, hablaremos del resto de las cosas que hay que tener en cuenta a nivel de red para asegurar el éxito de la implantación, que no son pocas.
Paso 1: Analizar patrón actual de uso
No hay dos empresas iguales, ni todas hacen uso de la plataforma de correo de la misma manera. Puede que tengamos una idea aproximada del uso que se hace, pero a menudo no se tiene nada de eso. Por eso es imprescindible un análisis de nuestro uso actual de la plataforma de correo apoyado en datos y estadísticas.
Esto nos permitirá conocer de primera mano datos en bruto, como por ejemplo cuál es la media de tamaño de los correos que se envían, tamaño de los adjuntos, cuántos destinatarios suele haber, cuántos correos se reciben o envían al día… etc. Seguramente los resultados nos sorprendan.
¿Cómo hacemos ese estudio?
Dependerá del sistema de correo de origen que tengamos.
Si estamos con Exchange 2003 o Exchange 2007, podemos usar el Exchange Server Profile Analyzer (EPA)
Esta herramienta nos permitirá analizar un periodo de tiempo determinado y nos sacará las estadísticas que necesitamos para hacer los cálculos posteriores.
En el caso de que nuestro origen sea Exchange 2010 o posterior, tendremos que usar Powershell, como se describe en éste artículo.
Veamos un ejemplo de un caso real, una infraestructura de Exchange 2003 con unos 250 buzones. Después de ejecutar el EPA, obtenemos una serie de estadísticas interesantes, de las cuales mostramos un ejemplo:
Como vemos, tenemos datos suficientes como para que nuestras estimaciones no sean una invención, y en un momento dado incluso podremos sacar estadísticas de cada buzón individual, si lo necesitamos.
Sólo tendremos que tener en cuenta que a la hora de seleccionar el rango de fechas para el que queremos hacer el análisis tendremos que escoger un periodo de tiempo que sea representativo. Por ejemplo, hacerlo en agosto donde mucha gente está de vacaciones, o en una semana de puente, nos dará estadísticas potencialmente falsas.
Una vez recopilados los datos, ya estamos listos para ir a la segunda parte.
Paso 2: Uso de la calculadora de ancho de banda
Una vez que tengamos los datos básicos de uso, descargaremos la calculadora de ancho de banda de Exchange Online desde éste enlace.
Puede que nos sorprenda que no haya sido actualizada en mucho tiempo, pero nos sirve igualmente porque de lo que se trata es de dar unas estimaciones generales, no afinar hasta el último Kb de ancho de banda. De hecho, si vemos la siguiente gráfica comparativa, vemos que los consumos de ancho de banda son casi idénticos entre las versiones más modernas y las recogidas en la calculadora. Supuestamente una versión actualizada saldrá cualquier día de estos, pero de momento nos sirve la que hay.
Vamos a ver cómo se utiliza.
En primer lugar, después de abrirla con Excel, tenemos que ir a la pestaña de la izquierda, llamada “Input”.
Es en este lugar donde le diremos el perfil de uso de nuestros usuarios.
Hay unos cuantos parámetros que conviene comentar:
- Bandwidth Headroom: Es el margen de seguridad que nos queremos dar. En este caso es un 100%, lo que significa que estamos dimensionando asumiendo que nuestras necesidades pueden ser el doble. Quizás penséis que es innecesario, y podéis ajustar este valor, pero tened en cuenta también que el ancho de banda del que solemos disponer no está dedicado en exclusiva al correo, por lo que ese margen nos puede venir bien en caso de picos. En cualquier caso, Microsoft recomienda dejar este valor en el 100%.
- OST Resync per Month: Este valor indica qué porcentaje de nuestros clientes van a necesitar descargarse el archivo de cache completo (*.OST) al mes, e influye muchísimo en el resultado final. Dependiendo del método de migración elegido, es muy posible que haya que volver a descargar el buzón para todos los usuarios, por lo que este factor puede incluso subirse para reflejar el consumo que se va a hacer durante el período de migración. Una vez terminado el proceso, se puede bajar a un porcentaje más realista, por ejemplo un 5%.
El resto de los parámetros son bastante evidentes, y si necesitamos una aclaración podemos ver los comentarios en cada celda.
Llegado a este punto tenemos que dar de alta los distintos perfiles de usuario que tenemos en la empresa:
Cada uno de esos perfiles representa una tipología distinta de usuario, etiquetado como Light, Heavy, etc. En realidad podemos hacer la división bajo los parámetros que veamos conveniente. Por ejemplo, podemos usar el tipo Light para definir a nuestro usuario estándar, y el tipo Heavy para aquel que tendrá un buzón más grande. O también usar estas tipologías para poner los usuarios que usan mucho el correo frente a los que son más pasivos, que tienen que tener email corporativo pero lo usan poco. O usuarios tipo Kiosco frente a los normales de oficina, por poner otro ejemplo más.
En cualquier caso, los parámetros que nos pregunta los debemos tener ya del paso anterior, como el tamaño de los correos o el número de los que envía o recibe al día.
Un detalle a tener en cuenta es que a la hora de poner el tamaño del buzón deberíamos valorar si ponemos el tamaño actual o el tamaño futuro, pues el escenario variará mucho en cada caso. Con Microsoft ofreciendo buzones de 50 GB, es muy probable que los buzones de los usuarios crezcan rápidamente, y más si aprovechamos para importar archivos PST históricos que teníamos en local. En ese caso, no nos interesa que el ancho de banda necesario esté infradimensionado y que seis meses después tengamos un problema, por lo que lo recomendable será hacer el cálculo con unos tamaños realistas a unos meses vista.
Cuando hayamos hecho los perfiles que queramos tener, pasamos a la siguiente pestaña, “Client Mix”.
Es aquí donde vamos a hacer el desglose por tipología de usuario, tipo de acceso y zona horaria.
En este caso, nosotros hemos definido dos perfiles, llamados Light y Medium para comparar dos posibilidades de tamaño de buzón, y para cada uno de ellos hemos puesto el método que usarán para conectar:
Ya hemos comentado que no está actualizada la lista de sistemas cliente, pero en general utilizar las de Outlook 2010 Cached, de OWA 2010 y Windows Phone para representar clientes Outlook modernos, OWA y dispositivos Activesync respectivamente.
Otro punto interesante es que si estamos trabajando en una empresa multinacional, es muy posible que los horarios de los distintos países hagan que el uso no se solape. De ahí que podamos establecer una zona horaria para ver cómo se reparten las conexiones a lo largo de un periodo de 24 horas.
Al final, después de todo este proceso, encontramos en la zona verde el dato que nos interesa para las dos variantes que estábamos viendo:
Ya tenemos el ancho de banda necesario tanto de subida como de bajada, y el número de conexiones TCP que serán necesarias. Este último dato puede ser relevante en empresas algo más grande, por lo que hablaremos de él en el siguiente artículo.
Paso 3: ¿Fin?
Si hemos llegado hasta aquí, puede que estemos tentados a dar el proceso por terminado. Pero, ¡cuidado!, porque los cálculos que hemos hecho son sobre todo para un sistema ya migrado y en explotación.
¿Qué ocurrirá durante el proceso de transición o migración al Office 365?
Es muy probable que nuestras necesidades de ancho de banda sean mucho mayores, por lo que habrá que tener esto en cuenta.
Estos son algunos de los factores que influyen:
- Si hemos configurado un escenario de coexistencia, es muy probable que todo el correo llegue al sistema local, para ser reenviado a los destinatarios que ya estén migrados a Office 365. Ni que decir tiene que el ancho de banda necesario puede ser considerable, e irá creciendo conforme más usuarios estén migrados. No es extraño invertir el flujo de correo para que se reciba en Office 365 cuando ya se han migrado más de la mitad de los usuarios, precisamente para evitar estos problemas.
- Durante el proceso de migración, será necesario copiar el contenido de los buzones desde las cuentas de Exchange local a las de Office 365. Esto significa copiar gigas y gigas, al mismo tiempo que se mantienen las operaciones del día a día y el flujo de correo habitual.
- Salvo que estemos haciendo una migración híbrida, a cada usuario habrá que volverle a configurar el Outlook, lo que provocará que se vuelva a resincronizar todo el buzón. Es decir, vuelta a descargar todo el contenido que acabamos de subir a la nube.
- Es muy habitual que en entornos de Exchange los usuarios tengan diversos archivos PST locales, por ejemplo porque tuvieran que liberar espacio en el buzón de Exchange. Frecuentemente esos PST contienen datos importantes, por lo que es muy posible que se quiera aprovechar la alta capacidad de buzón ofrecida por Microsoft en Exchange Online para almacenar en él los PST. Esto puede hacerse de varias formas, pero quizás la más habitual es que el usuario importe el PST sobre su propio buzón en Outlook. Esto provocará que el contenido se copie al OST local, que a su vez sincronizará todos esos cambios con el buzón de Office 365, lo que nuevamente consume ancho de banda.
Por todo esto, es muy importante tener esto en cuenta, pues si no la migración de Office 365 puede convertirse en una pesadilla. Imaginémonos a decenas de usuarios sin correo, todos intentando a la vez sincronizar su buzón, mientras que la conexión a Internet está caída por saturación… No es una imagen que nos guste en nuestros proyectos.
Sabiendo esto, al final habrá que adaptar el ritmo de migración a la disponibilidad de ancho de banda, entre otros factores, y hacer cálculos tanto para después de la migración como durante la migración.
Esperemos que estas recomendaciones que os hemos dado os sean útiles. Conocemos casos de empresas (algunas muuuuy grandes), que tuvieron que dar marcha atrás en sus despliegues por no haber tenido en cuenta esto.
Si os pasa, ya no tenéis excusa 
Deja tu comentario