Prácticas recomendadas en materia de redes para implementaciones grandes

Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 www.google.com

Número de pieza: NETBP_GAPPS_3.3 3 de octubre de 2012 © Copyright 2012 Google, Inc. Todos los derechos reservados. Google, el logotipo de Google, Google Apps, Google Apps Mail, Google Docs, Calendario de Google, Google Sites, Google Video, Google Talk, Gmail, Google Message Filtering, Google Message Security, Google Message Discovery, Postini y el logotipo de Postini son marcas comerciales, marcas comerciales registradas o marcas de servicios de Google, Inc. El resto de las marcas comerciales son propiedad de sus respectivos dueños. El uso de las soluciones de Google está regido por el acuerdo de licencia incluido en su contrato original. Los derechos de propiedad intelectual relacionados con los servicios de Google son y seguirán siendo propiedad exclusiva de Google, Inc. o sus subsidiarias ("Google"). No se puede descifrar, descompilar ni desarrollar el código fuente de ningún producto ni oferta de servicio de Google, ni permitir deliberadamente que otros lo hagan. La documentación de Google no podrá venderse ni revenderse, ni podrán otorgarse licencias ni sublicencias de esta ni tampoco podrá transferirse sin el previo consentimiento por escrito de Google. Su derecho a copiar el manual está limitado por la ley de derechos de autor. Hacer copias, adaptaciones o trabajos de compilación sin previa autorización escrita de Google está prohibido por ley y constituye una violación punible de esta. Ninguna parte de este manual podrá reproducirse en su totalidad ni en parte sin el consentimiento expreso por escrito de Google. Copyright © de Google, Inc. Google proporciona esta publicación en el estado en que se encuentra, y esta no posee ningún tipo de garantía, ya sea explícita o implícita, incluidas, sin limitarse a ellas, las garantías implícitas de comercialización o adaptación a un fin particular. Postini, Inc. puede, de tanto en tanto, hacer modificaciones en esta publicación sin previo aviso. Algunas jurisdicciones no permiten la renuncia de responsabilidad en relación con garantías explícitas o implícitas; por lo tanto, esta declaración puede no corresponder en su caso.

2

Prácticas recomendadas en materia de redes para implementaciones grandes

Contenido

Capítulo 1: Introducción.......................................................................................5 Acerca de esta guía.................................................................................................5 Público objetivo..................................................................................................5 Beneficios..........................................................................................................5 Esfuerzo requerido.............................................................................................6 Cómo sacar el máximo provecho de esta guía.......................................................6 Ciclo de vida de la implementación de Google Apps...............................................6 Documentación relacionada....................................................................................7 Renuncia de responsabilidad para la configuración de productos de terceros.......7 Capítulo 2: Lista de verificación de acciones de red.........................................9 Acerca de esta lista de verificación.........................................................................9 Evaluación de la red................................................................................................9 Configuración de la red.........................................................................................10 Enrutamiento de la red.....................................................................................10 Servidores proxy..............................................................................................10 Otros servicios................................................................................................. 11 Configuración del cliente.......................................................................................11 Acceso de clientes........................................................................................... 11 Autenticación................................................................................................... 11 Migración.........................................................................................................12 Monitoreo de la red................................................................................................12 Capítulo 3: Evaluación de la red........................................................................13 Resumen...............................................................................................................13 Pruebe su entorno de red......................................................................................13 Inventario de las ubicaciones de red...............................................................14 Prueba de la red..............................................................................................14 Herramientas de prueba de la red...................................................................16 Evaluación y medida de los servidores proxy........................................................16 Realice una evaluación comparativa de la carga de proxy por usuario...........16 Estime la cantidad esperada de recursos de proxy necesarios.......................17 Ejemplo............................................................................................................17 Capítulo 4: Configuración de la red...................................................................19 Resumen...............................................................................................................19

Contenido

3

Direccionamiento y protocolos de red...................................................................19 Direcciones IPv4 de Google............................................................................19 Protocolos de Google......................................................................................20 Google Talk Voice and Video y los Hangouts de Google+...............................21 Enrutamiento de la red..........................................................................................22 Optimización de la WAN..................................................................................22 Priorización del tráfico......................................................................................23 Peering.............................................................................................................23 Herramientas de enrutamiento de la red.........................................................24 Servidores proxy....................................................................................................24 Configuración de servidores proxy..................................................................24 Filtrar el tráfico de Google Apps mediante un proxy........................................25 Configuración de un archivo PAC de proxy.....................................................25 Inspección de SSL...........................................................................................26 Bloquear el acceso a los servicios para consumidores de Google..................27 Monitorear el filtrado de URI............................................................................27 Herramientas de configuración de proxy.........................................................28 Otros servicios de red............................................................................................28 Resolución de DNS..........................................................................................29 Configuración del firewall.................................................................................30 Enrutamiento del correo...................................................................................30 Capítulo 5: Configuración del cliente................................................................31 Resumen...............................................................................................................31 Acceso de clientes.................................................................................................31 Requisitos de los navegadores........................................................................31 Dispositivos móviles.........................................................................................32 Cliente Google Drive Sync...............................................................................34 Autenticación.........................................................................................................34 Inicio de sesión único.......................................................................................34 Herramientas de autenticación........................................................................36 Migración...............................................................................................................36 Migración del lado del servidor........................................................................37 Capítulo 6: Monitoreo de la red..........................................................................39 Resumen...............................................................................................................39 Herramientas de monitoreo...................................................................................39 Capturas de paquetes de red................................................................................40

4

Prácticas recomendadas en materia de redes para implementaciones grandes

Capítulo 1

Introducción

Acerca de esta guía Este documento trata acerca de las prácticas recomendadas para optimizar su red IP de gran escala para Google Apps for Business. Las recomendaciones y la información de esta guía son fruto de nuestro trabajo con una gran variedad de clientes y partners de muchos entornos de redes. Queremos agradecer a nuestros clientes y partners por compartir su información y sus experiencias.

Público objetivo Este documento está dirigido a clientes de Google Apps que poseen redes complejas, especialmente a aquellos que están dispersos en un área geográfica grande. En el caso de los administradores que trabajan con redes más pequeñas o redes que se encuentran en un solo lugar, parte de esta información puede resultarles útil, y pueden encontrar respuestas a preguntas específicas, pero algunos de los temas más importantes relativos a la prueba, la capacidad y el enrutamiento de la red pueden no resultar relevantes.

Beneficios La optimización de la configuración de su red lo ayudará a mejorar la implementación de Google Apps de las siguientes maneras: •

Mejore la capacidad de respuesta de Google Apps mediante la reducción de la latencia en su red IPv4.

•

Reduzca el consumo de ancho de banda mediante la optimización del enrutamiento y los servicios de red.

•

Prediga las necesidades de rendimiento y capacidad de su red mediante la recopilación de métricas de referencia de latencia, pérdida de paquetes y disponibilidad de la red antes de comenzar con la implementación de Google Apps.

•

Reduzca los tiempos de carga y descarga con Google Apps para archivos grandes, como los adjuntos y videos internos.

•

Migre a Google Apps la información de los servidores heredados existentes de manera eficiente. 5

Esfuerzo requerido El esfuerzo requerido para implementar las recomendaciones de esta guía dependerán de sus necesidades, su infraestructura actual y las habilidades del equipo que trabaja en su red. Los principios de diseño y las prácticas recomendadas de implementación de este documento no son específicos de un sector o una tecnología. Los principios de este documento no requieren experiencia técnica específica que vaya más allá de los conocimientos de ingeniería de redes y arquitectura de redes estándares de la industria.

Cómo sacar el máximo provecho de esta guía Esta guía incluye metodología de pruebas y planificación, respuestas a preguntas comunes sobre el impacto de Google Apps en redes IPv4 y resultados de estudios de campo sobre las prácticas recomendadas para integrar su red con Google Apps. La guía fue diseñada para utilizarse de las siguientes maneras: •

Como guía de referencia de las prácticas recomendadas en materia de redes, metodología y herramientas de red. La lista de verificación del próximo capítulo proporciona una referencia a cada tema sobre redes, así como también vínculos a información adicional útil. Consulte la sección "Lista de verificación de acciones de red" en la página 9.

•

Como debate en profundidad de una variedad de prácticas recomendadas en materia de redes y temas relacionados. Puede leer este documento en su totalidad para comprender en detalle todos los temas relativos a las redes y Google Apps.

•

Como guía de referencia para responder preguntas sobre temas específicos relativos a las prácticas recomendadas en materia de redes. Use el índice o la función de búsqueda para encontrar rápidamente los temas específicos que le interesen.

Ciclo de vida de la implementación de Google Apps La información incluida en esta guía está asociada a varios hitos de su implementación de Google Apps: 1. Evaluación de la red:Esta sección incluye información sobre la evaluación de su red actual antes de implementar Google Apps. Si bien esta información puede resultar útil después de haber implementado Google Apps for Business, verá mejores resultados si realiza estas evaluaciones y pruebas antes de los demás pasos. 2. Configuración de la red: Esta sección incluye notas e información sobre cómo configurar su red en pos de optimizar su trabajo con Google Apps. Contiene información sobre el enrutamiento de la red, las direcciones IPv4, los números de puertos y protocolos, la configuración de servidores proxy, la configuración de los sistemas de nombres de dominio (DNS), la configuración del firewall y la configuración del servidor de correo. 3. Configuración del cliente: Esta sección proporciona información sobre cómo configurar el entorno para sus usuarios. Esto incluye información del cliente, expectativas de la red móvil y migración. 4. Monitoreo de la red: Esta sección brinda información sobre el mantenimiento de su red y la solución de problemas si los incidentes ocurren después de completar la implementación.

6

Prácticas recomendadas en materia de redes para implementaciones grandes

Documentación relacionada Para obtener información adicional sobre las prácticas recomendadas en materia de redes y temas relacionados, consulte los siguientes recursos afines: •

Guía de transición técnica de Google Apps: Descripción general sobre cómo migrar su organización a Google Apps desde otra plataforma de mensajería.

•

Recursos de implementación de Google Apps: Centro de recursos para administradores de TI que deseen recabar información sobre la implementación de Google Apps. Está diseñado para organizaciones grandes.

•

Google Apps Partner Connect: Requiere acceso. Sitio con información útil para partners, que incluye otrasNotas del campo relacionadas.

Renuncia de responsabilidad respecto a la configuración de productos de terceros Esta guía describe cómo funcionan los productos de Google Apps con servidores comunes y las configuraciones que recomienda Google. Estas instrucciones están diseñadas para las situaciones más comunes. Los cambios en su configuración deben realizarse a discreción de sus administradores. Google no proporciona asistencia técnica para la configuración de productos de terceros. En caso de existir algún problema con estos productos, consulte al administrador de su red. GOOGLE NO SE RESPONSABILIZA POR PRODUCTOS DE TERCEROS. También puede ponerse en contacto con los Proveedores de soluciones de Google para obtener asesoramiento. Le proporcionamos vínculos a sitios web de terceros que pueden resultarle útiles. Los vínculos y su contenido pueden cambiar sin aviso. Consulte los sitios web de productos apropiados para obtener la información más reciente sobre asistencia y configuración.

Introducción 7

8

Prácticas recomendadas en materia de redes para implementaciones grandes

Capítulo 2

Lista de verificación de acciones de red

Acerca de esta lista de verificación Esta sección incluye una lista de verificación resumida con todas las acciones de esta guía. Si no tiene tiempo de revisar esta guía de principio a fin, le sugerimos que comience por revisar esta Lista de verificación de acciones de red. Cada tema se describe en detalle más adelante en esta guía.

Evaluación de la red Evalúe su red y su plan actuales para analizar las necesidades de capacidad. Para obtener los mejores resultados durante la prueba, utilice la siguiente metodología: F FHaga un inventario de todas sus ubicaciones de red, incluido el nombre de la ubicación, el tipo de acceso a Internet (p. ej., T1, VPN, DSL) y el ancho de banda de Internet disponible. F FPruebe la resolución del sistema de nombres de dominio (DNS) de todas las ubicaciones de red a Google Apps para asegurarse de que los clientes de su red puedan resolver los nombres de host de Google Apps. F FPruebe la conectividad del Protocolo de mensajes de control de Internet (ICMP) de todas las ubicaciones de red a Google Apps para asegurarse de que los clientes de su red puedan establecer conexión con los servidores de Google. F FPruebe la fiabilidad del protocolo TCP/UDP de todas las ubicaciones a Google Apps para asegurarse de que los clientes de su red puedan establecer y mantener una conexión con Google Apps de manera confiable. F FEvalúe el ancho de banda de la red de área amplia (WAN) entre su ubicación de salida de Internet y las ubicaciones de red que usan ese punto de salida. F FSi pretende que sus usuarios se conecten a Google Apps mediante un servidor proxy, cree un entorno de prueba y determine cuántas conexiones deben esperarse por usuario, de modo que pueda calcular la cantidad esperada de conexiones salientes en su servidor proxy. Para obtener más información sobre la evaluación de su red, consulte la sección "Pruebe su entorno de red" en la página 13 y la sección "Evaluación y medida de los servidores proxy" en la página 16.

9

Configuración de la red Las siguientes recomendaciones describen las configuraciones de red que lo ayudarán a proporcionar la mejor experiencia de Google Apps a sus usuarios. Estas recomendaciones incrementan la disponibilidad y el rendimiento de la red, y pueden reducir los costos al simplificar el equipamiento de red necesario para trabajar con Google Apps.

Enrutamiento de la red Para obtener el mejor rendimiento de las conexiones de red con Google Apps, haga lo siguiente: F FEnrute el tráfico de red a Internet lo más próximo posible al usuario final en lo que respecta a la geografía y la topología de la red. F FEnfóquese en abordar los problemas de latencia en los requisitos de ancho de banda. Por encima de un nivel mínimo de ancho de banda, las consideraciones sobre el ancho de banda son, por lo general, menos importantes para Google Apps. F FAbra sus firewall a los puertos que utilizan los servicios de Google Apps. Para obtener detalles, consulte la sección "Protocolos de Google" en la página 20. F FNo enrute su tráfico a direcciones IPv4 de Google específicas ya que estas pueden cambiar. Use, en cambio, nombres de dominio. Si no puede enrutar por nombres de dominio, utilice las direcciones IPv4 publicadas y verifique si hay actualizaciones con frecuencia. Consulte la sección "Direcciones IPv4 de Google" en la página 19. F FEn caso de utilizar una topología de red de tipo radial (hub-and-spoke) o si su red cuenta con varias ubicaciones con un único punto de salida de red, puede considerar la idea de priorizar el tráfico. F FSi configura la priorización del tráfico con direcciones IPv4 de Google, priorice solamente el tráfico HTTPS seguro para minimizar la priorización de algunos productos de consumo de Google. Para obtener más información sobre el enrutamiento de la red, consulte la sección "Direccionamiento y protocolos de red" en la página 19 y "Enrutamiento de la red" en la página 22.

Servidores proxy F FEvite enrutar datos de Google Apps mediante un proxy que inspeccione el contenido del tráfico HTTP porque esto reducirá el rendimiento, y gran parte del contenido de Google Apps es dinámico o está encriptado. F FUbique sus servidores proxy en un lugar que esté cerca de sus usuarios y su punto de salida de Internet, tanto en lo que respecta a la geografía como a la topología de red. F FSi necesita filtrar tráfico web por identificador uniforme de recursos (URI), considere utilizar un archivo de configuración .PAC en el escritorio del cliente, ya que los URI del tráfico HTTP encriptado no son visibles para el proxy. F FSi utiliza un servidor proxy compatible con las terminaciones SSL, puede configurar su servidor proxy para que inspeccione el contenido de Google Apps mientras releva la conexión segura. Para obtener más información sobre la configuración de los servidores proxy, consulte la sección "Servidores proxy" en la página 24. 10

Prácticas recomendadas en materia de redes para implementaciones grandes

Otros servicios F FUse un resolutor de DNS en una ubicación cercana a los usuarios en lo que respecta a la geografía y la topología de red. F FEvite utilizar resolutores de DNS instalados en ubicaciones de red remotas ya que esto disminuirá considerablemente la velocidad de las conexiones a Google Apps. F FUtilice los valores de TTL sugeridos para todos los tipos de registros de DNS. F FConfigure reglas de firewall para permitir un tráfico HTTPS saliente ilimitado a Google Apps. No necesita configurar reglas especiales para el tráfico entrante; Google Apps generalmente no inicia tráfico entrante hacia los usuarios. F FEvite enrutar el correo entrante y saliente a través de una puerta de enlace dentro de su red. Si se enruta correo entrante y saliente a una puerta de enlace dentro de su red, el tráfico de correo consumirá recursos de red innecesarios. Para obtener más información sobre los servicios de red, consulte la sección "Otros servicios de red" en la página 28.

Configuración del cliente Una vez que su red esté configurada, prepare su entorno de usuarios para que funcione con Google Apps. Esto puede incluir configurar clientes, la autenticación de inicio de sesión único (SSO) y la migración de la información de los usuarios.

Acceso de clientes Al realizar una planificación respecto de los clientes que se conectarán a Google Apps, tenga en cuenta lo siguiente: F FLos navegadores sugeridos incluyen Chrome, Firefox, Internet Explorer (versión 8 o superior) o Safari para sus usuarios de Google Apps. Si sus usuarios actualmente tienen navegadores heredados, instale y habilite uno de estos navegadores. Los navegadores modernos ofrecen una mejor experiencia de usuario porque mejoran la velocidad con la que se muestran las páginas web. F FConsidere utilizar dispositivos móviles Android o ActiveSync en lugar de dispositivos BlackBerry. Los servicios de BlackBerry Enterprise Services pueden consumir recursos de su red. Para obtener más información sobre cómo configurar entornos de clientes, consulte la sección "Acceso de clientes" en la página 31.

Autenticación Si planea configurar la autenticación de Inicio de sesión único (SSO), tenga en cuenta lo siguiente: F FInstale servidores de SSO en ubicaciones de red distribuidas en lugar de en una ubicación central. F FImplemente su servidor de SSO junto con sus servidores de red privada virtual (VPN) para evitar el enrutamiento del tráfico de autenticación de los usuarios de la VPN a una ubicación diferente. F FConfigure servidores de DNS internos para redireccionar el tráfico de SSO al servidor de SSO más cercano y asegúrese de instalar servidores de SSO alternativos para el servicio redundante en caso de que exista alguna interrupción del servicio que no permita a los usuarios acceder al servidor de SSO en una ubicación específica. Lista de verificación de acciones de red 11

Para obtener más información sobre la autenticación con SSO, consulte la sección "Autenticación" en la página 34.

Migración Las implementaciones de Google Apps pueden incluir el tráfico de la migración, ya sea de clientes locales, como Google Apps Migration for Microsoft Outlook, o de clientes del lado del servidor, como Google Apps Migration for Lotus Notes y Google Apps Migration for Microsoft Exchange. La migración de datos heredados a Google Apps es, por lo general, una actividad que requiere muchos recursos, pero que usualmente se realiza una sola vez. Si tiene pensado migrar datos de los usuarios, tenga en cuenta lo siguiente: F FAsegúrese de que los servidores de migración estén en la misma ubicación que los servidores de sus datos heredados o, al menos, de que la conectividad entre los servidores tenga latencia baja y un ancho de banda grande. F FEvite enrutar tráfico desde los servidores de migración a Google mediante servidores proxy para evitar reducir el rendimiento de la migración y una carga innecesaria en los servidores proxy. F FAntes de la migración, evalúe la capacidad de su red para determinar la cantidad máxima de información que puede migrar simultáneamente. Ajuste su plan de migración como corresponda. F FDurante la migración, algunas de las conexiones a los servidores de Google establecidas pueden permanecer abiertas durante un período de tiempo, según la herramienta de migración que utilice. Para evitar posibles errores de migración y reducir la necesidad de tener que volver a migrar datos, es importante mantener abiertas estas sesiones y no dejar que se cierren temprano porque se agotó el tiempo de espera del proxy o del firewall. Para obtener más información sobre la migración de datos, consulte la sección "Migración" en la página 36.

Monitoreo de la red Use herramientas de monitoreo para mantener y administrar una red IPv4 existente que ya funcione con Google Apps. F FHay varias herramientas de monitoreo de red disponibles que son apropiadas para monitorear el tráfico de Google Apps. Para obtener una lista de herramientas recomendadas de monitoreo de red, consulte la sección "Herramientas de monitoreo" en la página 39. F FLas Capturas de paquetes de red pueden ayudarlo a identificar posibles problemas de rendimiento durante la solución de problemas, o cuando trabaja con su proveedor de red o el equipo de asistencia de Google. Para obtener más información, consulte la sección "Capturas de paquetes de red" en la página 40.

12

Prácticas recomendadas en materia de redes para implementaciones grandes

Capítulo 3

Evaluación de la red

Resumen Al realizar la planificación de la implementación, obtendrá mejores resultados si primero hace un análisis de la capacidad actual de su red y la cantidad esperada de carga de red de Google Apps. La mejor forma de predecir la cantidad de carga que debe esperarse es evaluar el uso de ancho de banda en su red y crear un entorno de prueba para simular la cantidad de capacidad que necesitará cada usuario. Esta sección analiza en detalle los enfoques para probar su entorno de red. Si ya ha implementado Google Apps sin realizar pruebas y evaluaciones comparativas en su entorno, quizás aún le convenga hacerlo, ya que esto puede darle puntos de referencia para planificaciones y requisitos de capacidad futuros, y puede ayudarlo a identificar problemas potenciales antes de que estos afecten la experiencia de sus usuarios.

Pruebe su entorno de red Para obtener los mejores resultados, pruebe su entorno de red antes de implementar Google Apps a fin de descubrir la existencia de posibles errores. La prueba de la red previa a la implementación de Google Apps se centra principalmente en evaluar la capacidad y el rendimiento de los cuellos de botella de la red, los proxy de Internet y cualquier otro componente de red responsable de enrutar o monitorear el tráfico basado en Internet.

13

A continuación se ofrecen los pasos recomendados para evaluar y probar su red antes de implementar Google Apps. •

Haga un inventario de todas las ubicaciones de su red, incluido el nombre de la ubicación, el tipo de acceso a Internet (p. ej., T1, VPN, DSL) y el ancho de banda de Internet disponible.

•

Pruebe la resolución del sistema de nombres de dominio (DNS) de todas las ubicaciones de red a Google Apps para asegurarse de que los clientes de su red puedan resolver los hombres de host de Google Apps.

•

Pruebe la conectividad del Protocolo de mensajes de control de Internet (ICMP) de todas las ubicaciones de red a Google Apps para asegurarse de que los clientes de su red puedan establecer conexión con los servidores de Google.

•

Pruebe la fiabilidad del protocolo TCP/UDP de todas las ubicaciones a Google Apps para asegurarse de que los clientes de su red puedan establecer y mantener una conexión con Google Apps de manera confiable.

•

Evalúe el ancho de banda de la red de área amplia (WAN) entre su ubicación de salida de Internet y las ubicaciones de red que usan ese punto de salida.

Inventario de las ubicaciones de red Al realizar una planificación para la implementación de Google Apps, es importante crear un inventario de todas las ubicaciones desde las que los usuarios accederán a Google Apps. El objetivo de este inventario es reunir información sobre la conectividad y la capacidad de Internet de cada ubicación de la red. Al realizar un inventario, incluya la siguiente información sobre cada ubicación de red: •

El nombre de la ubicación y una descripción de su acceso a Internet. Ejemplo: "Oficina central, DS3".

•

La utilización pico y promedio del ancho de banda de Internet. Ejemplo: "50% de uso promedio y 70% de utilización pico".

•

La cantidad de servidores proxy, y la utilización pico y promedio actuales.

•

El número de aplicaciones de firewall, y la utilización pico y promedio actuales.

•

El número de servidores de DNS, y la utilización pico y promedio actuales.

Una vez que haya reunido esta información para cada ubicación de red, use estos datos para evaluar la capacidad actual y si se necesitan actualizaciones.

Prueba de la red Use la información que reunió al realizar el inventario de la red para probar cada ruta de la red, servidor de DNS y servidor proxy. Realice las siguientes pruebas para todas las conexiones de red relevantes en cada ubicación. Nota: El software de prueba de terceros descrito en esta sección está disponible para varios sistemas operativos, incluidos Linux, Unix, OS X y Windows.

Prueba de resolución de DNS Asegúrese de que los clientes de su red puedan resolver los identificadores uniformes de recursos (URI) y los nombres de host de Google Apps mediante la prueba de la resolución de DNS de todas las ubicaciones de red a los nombres de host de Google Apps; hágalo de la siguiente manera: 14

Prácticas recomendadas en materia de redes para implementaciones grandes

1. Abra el archivo de texto de la lista de ejemplos que está en el sitio de códigos de implementación de aplicaciones. (Tenga en cuenta que este es solo un ejemplo, no una lista completa). 2.Guarde el archivo .txt de ejemplo en el directorio donde usará los comandos de prueba: a.Haga clic en View raw file (Ver archivo de datos sin procesar). b.Haga clic con el botón derecho en Save As (Guardar como). 3.Ejecute el siguiente comando para probar la resolución de DNS: % dig +all +trace -f GoogleAppsDomains.txt

Prueba de conectividad del ICMP Asegúrese de que los clientes de su red puedan establecer conexión con el nombre de host mail.google.com mediante la prueba de la conectividad del ICMP de todas las ubicaciones de red a Google Apps. Pruebe que sus usuarios puedan establecer conexión con Google Apps, especialmente desde las redes de área local virtual (VLAN) de los usuarios. % ping -s 512 -c 400

-n mail.google.com

Si ve conexiones lentas o que fallaron en las solicitudes de ping, esto podría indicar la pérdida de conectividad. Investigue cada paso de su conexión para identificar la causa del problema.

Prueba de fiabilidad del protocolo TCP/UDP Asegúrese de que los clientes de su red puedan establecer y mantener una conexión con los servidores de Google Apps de manera fiable. Use la herramienta Hping para probar la fiabilidad del vínculo durante un período de tiempo. Ejecute el siguiente comando: % time hping3 -S mail.google.com

-p 443 --fast -c 1000

Si hay tiempo, ejecute esta prueba para cada dominio que aparece en el archivo GoogleAppsDomains.txt mencionado anteriormente. Nota:  Las pruebas de fiabilidad del protocolo TCP/UDP son intrusivas y pueden afectar el rendimiento de la red. Realice estas pruebas en momentos en que no haya actividad para recabar información causando el mínimo impacto posible en la red.

Evaluación del ancho de banda de la WAN disponible Use la herramienta iperf para evaluar la cantidad de ancho de banda disponible en cada ubicación en relación con su punto de salida de red. Esta prueba se realiza tanto en el punto de salida del cliente como en el de la red. Esta prueba tiene como objetivo evaluar el ancho de banda en su red WAN. No es apropiada para probar el ancho de banda entre su red y los servidores de Google Apps. En cada ubicación remota conectada mediante una red WAN, ejecute este comando: % iperf -c CLIENT IP ADDRESS -d

En la ubicación de salida de la red, ejecute este comando: % iperf -s

Evaluación de la red 15

Nota:  Las pruebas de ancho de banda de WAN son intrusivas y pueden afectar el rendimiento de la red. Realice estas pruebas en momentos en que no haya actividad para reunir información causando el menor impacto posible a la red. Si necesita realizar estas pruebas durante horas de trabajo, tenga cuidado con los posibles efectos que esta prueba puede tener en el rendimiento de la red.

Herramientas de prueba de la red Puede obtener las herramientas de las que hablamos anteriormente en los siguientes recursos en línea: •

Descargue la herramienta de análisis de paquetes Hping desde hping.org.

•

Descargue la herramienta de medida del rendimiento del ancho de banda iperf desde SourceForge.

Evaluación y medida de los servidores proxy En un entorno de computación en la nube, hay por lo general más solicitudes salientes para hosts externos que las generadas en un entorno heredado. Este incremento en las solicitudes salientes puede repercutir en el número de servidores proxy necesarios en su red. Si pretende que los usuarios se conecten a Google Apps mediante un servidor proxy, puede determinar qué carga de servidores proxy se debe esperar mediante la realización previa de estas pruebas. Use esta información para estimar si necesita incrementar la capacidad de los servidores proxy. Para evaluar las necesidades de los servidores proxy, siga estos pasos: 1.  Cree un entorno de prueba con cada plataforma y navegador que planee usar en su entorno de usuarios. 2.  Para cada navegador, determine el número de conexiones que tienen lugar durante la prueba, incluida la cantidad de conexiones mínima y máxima simultáneas, tanto para el uso inactivo como para el uso activo. 3.  Basándose en esta información y en el número de usuarios que estima que usarán el sistema, calcule el número esperado de conexiones para su servidor proxy. 4.  Use estos cálculos para determinar los cambios necesarios en la capacidad de los servidores proxy. Más adelante podrá obtener más información acerca de estos pasos.

Realice una evaluación comparativa de la carga de proxy por usuario Para hacer una evaluación comparativa de la cantidad de recursos de proxy utilizados por un usuario típico, establezca un entorno de prueba donde pueda probar los diversos navegadores y plataformas utilizados. Su entorno de prueba debe incluir máquinas de prueba en su red que puedan conectarse a Google Apps mediante las mismas rutas que piensa usar para sus usuarios. (Por ejemplo, si tiene pensado implementar usuarios con Microsoft Windows 7, Chrome 10 y Firefox 3.6 como su sistema operativo y navegadores estándar, use este mismo entorno al ejecutar las evaluaciones comparativas). Una vez que su entorno de prueba esté listo, direccione el tráfico a un proxy de prueba donde pueda determinar el número de conexiones.

16

Prácticas recomendadas en materia de redes para implementaciones grandes

Reúna la siguiente información en cada entorno mientras usa los servicios de Google Apps disponibles en su dominio. Por ejemplo, abra Gmail, Google Talk, Google Docs y Calendario de Google. •

Conexiones promedio/segundo

•

Conexiones pico/segundo

•

Conexiones no pico/segundo

Además, como ocurre en el caso de muchas aplicaciones basadas en la Web que se ejecutan en la nube, Google Apps mantiene varias conexiones abiertas al servidor remoto para obtener información nueva. Para evaluar la carga causada por estas conexiones abiertas, determine lo siguiente en su entorno de prueba. •

Cantidad mínima de conexiones que un usuario inactivo tiene con su plataforma de navegador

•

Cantidad máxima de conexiones que un usuario inactivo tiene con su plataforma de navegador

Una vez que haya reunido esta información, puede compilarla para estimar la carga que puede experimentar, dado su entorno único.

Estime la cantidad esperada de recursos de proxy necesarios Para estimar la cantidad de carga que puede esperarse durante la implementación de Google Apps, multiplique el número de conexiones para cada entorno de prueba por el número de usuarios esperado para ese entorno. Use los siguientes cálculos: Carga promedio estimada = Suma (carga promedio de cada entorno de máquinas de prueba X número estimado de usuarios que usarán ese entorno) Carga pico estimada = Suma (carga pico de cada entorno de máquinas de prueba X número estimado de usuarios que usarán ese entorno) Carga en modo inactivo estimada = Suma (carga en modo inactivo de cada entorno de máquinas de prueba X número estimado de usuarios que usarán ese entorno)

Si la carga promedio estimada sumada al tráfico adicional que sus proxy administrarán excede su capacidad actual, haga planes para expandir la capacidad de los servidores proxy o cambie la implementación de servidores proxy, de modo que estos no se hagan cargo de las solicitudes que los usuarios harán a Google Apps.

Ejemplo En el siguiente ejemplo, una empresa grande planea implementar lo siguiente: •

5.000 usuarios que ejecuten Chrome en Windows 7

•

3.000 usuarios que ejecuten Firefox en Windows 7

Durante las evaluaciones comparativas, las pruebas muestran los siguientes números de ejemplo de conexiones simultáneas a través del servidor proxy. (Nota: Estos solo sirven de ejemplo. Su entorno variará).

Evaluación de la red 17

•

Chrome en Windows 7 Conexiones al ingresar URI: 1 Conexiones durante la carga inicial: 3 Conexiones al acceder: 6 Conexiones después de unos minutos de inactividad: 4 Conexiones al abrir Calendario y Docs: 4 Conexiones al abrir un documento: 6 Carga promedio: 3,6 conexiones Carga pico: 6 conexiones Carga en inactividad: 3,1 conexiones

•

Firefox en Windows Conexiones al ingresar URI: 1 Conexiones durante la carga inicial: 4 Conexiones al acceder: 9 Conexiones después de unos minutos de inactividad: 3 Conexiones al abrir Calendario y Docs: 11 Conexiones al cargar un documento: 17 Carga promedio: 4,1 conexiones Carga pico: 17 conexiones Carga en inactividad: 3,8 conexiones

Según estos datos, la carga esperada es: •

Promedio: (5.000 x 3,6) + (3.000 x 4,1) = 30.300 conexiones

•

Pico: (5.000 x 6) + (3.000 x 17) = 81.000 conexiones

•

Inactivo: (5.000 x 3,1) + (3.000 x 3,8) = 26.900 conexiones

Según estas estimaciones, el entorno de proxy necesita poder admitir al menos 30.000 conexiones, pero posiblemente más para evitar problemas durante los períodos de uso pico o si se espera algún tipo de crecimiento. Si el entorno de proxy actual está funcionando al 50% con 20.000 conexiones, esto es señal de que será necesario implementar una cantidad significativamente mayor de servidores proxy o enrutar el tráfico de Google Apps, de modo que "evite" el servidor proxy.

18

Prácticas recomendadas en materia de redes para implementaciones grandes

Capítulo 4

Configuración de la red

Resumen Esta sección incluye detalles acerca de cómo optimizar su red para Google Apps for Business. Esto incluye información sobre las direcciones IPv4 de Google, los protocolos utilizados, sugerencias de enrutamiento, opciones de configuración de servidores proxy y la configuración del sistema de nombres de dominio (DNS). Use esta información como guía al configurar su red y como referencia para los tipos de solicitudes que los clientes de Google Apps harán a los servidores de Google Apps.

Direccionamiento y protocolos de red Direcciones IPv4 de Google Google Apps existe en un entorno de servidores multicliente que incluye tanto cuentas de Google Apps como cuentas para consumidores. Por lo tanto, Google Apps comparte el mismo espacio de direcciones IPv4 que los servicios para consumidores de Google. Por ejemplo, los servidores de Google Docs podrían usar el mismo espacio de direcciones IPv4 que Picasa Web. Además, una dirección IPv4 específica para un nombre de host de Google como, por ejemplo, mail.google.com o docs.google.com, podría servir tanto a los usuarios de Google Apps como a los consumidores al mismo tiempo. Para los nombres de host de Google, como mail.google.com o docs.google.com, la dirección IPv4 de Google no es estática y es válida solo para el valor de tiempo de vida (TTL) mostrado en la búsqueda de DNS del nombre de host. Por ejemplo, si hacemos una consulta del registro A para mail.google.com, se mostrarán varios resultados:

% dig a mail.google.com +ttl ;; ANSWER SECTION: mail.google.com. 68665 IN googlemail.l.google.com. 152 IN googlemail.l.google.com. 152 IN googlemail.l.google.com. 152 IN

CNAME A A A

googlemail.l.google.com. 74.125.225.86 74.125.225.87 74.125.225.85

19

La segunda columna en el conjunto de resultados es el TTL para los registros en segundos. Según estos resultados de ejemplo, podemos determinar que las direcciones IPv4 son válidas por apenas unos 2,5 minutos. Debido a que las direcciones IPv4 de Google cambian con el tiempo, no configure direcciones específicas de este tipo en aplicaciones, firewall ni servidores de su red, ni en otros equipos de enrutamiento, a menos que incluya todo el espacio de direcciones IPv4 de Google y lo supervise para ver si hay cambios, de la siguiente manera: Google publica dos conjuntos de direcciones IPv4 de Google Apps en un tipo de registro .txt de DNS denominado _netblocks.google.com. Para reunir esta información o verificar si hay cambios, use la herramienta dig desde un intérprete de comandos, como se muestra a continuación. Si ejecuta este comando: % dig txt _netblocks.google.com +short @8.8.8.8

Verá un resultado con este formato: “v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all”

Si ejecuta este comando: % dig txt _spf.google.com +short

Verá un resultado con el siguiente formato: “v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20S ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all”

Si necesita hacer un cambio para aceptar correo de Google en su entorno, para una pasarela de correo, incluya todas las subredes del registro _spf.google.com. Si necesita hacer un cambio en las reglas de firewall salientes para admitir el acceso de los usuarios a los servicios de Google Apps, use todas las subredes del registro _netblocks.google.com. Si hace una consulta de estos registros, verá la información más actualizada acerca de las direcciones IPv4 de Google. Si no puede usar nombres de dominio de Google Apps y necesita usar direcciones IPv4 de Google, configure un programa para verificar si hay cambios en estas direcciones regularmente. Puede usar herramientas como dnd-rr-monitor (consulte la sección "Herramientas de monitoreo" en la página 39) para monitorear los cambios.

Protocolos de Google Los servicios de Google Apps están, en su mayoría, basados en la Web o en API. La siguiente tabla muestra servicios comunes de Google Apps y los protocolos utilizados para cada uno de ellos. Como se muestra en la tabla, los diagramas de datos que usa Google están basados casi siempre en TCP, excepto cuando se indica lo contrario. Aplicación

20

Protocolo

Puerto

Correo electrónico, Calendario, Docs, Google Sites

TCP

443

Google Apps Sync for Microsoft Office

TCP

443

Google Apps Connector for BlackBerry Enterprise Server

TCP

443

Prácticas recomendadas en materia de redes para implementaciones grandes

Aplicación

Protocolo

Puerto

Google Talk (versión web)

TCP

443

Google Talk (cliente de escritorio)

TCP (XMPP)

5.222 o 443

Google Talk (Voice and Video)

Especial; vea abajo

Especial; vea abajo

Hangouts de Google+

Especial; vea abajo

Especial; vea abajo

Google Apps Migration for Microsoft Exchange

TCP (API)

443

Google Apps Migration for Lotus Notes

TCP (API)

443

Google Talk Voice and Video y los Hangouts de Google+ Google Talk Voice and Video Durante una llamada de voz o video, el complemento Google Talk Voice and Video intenta establecer una conexión entre quien llama y la persona que recibe la llamada (para obtener detalles, consulte la Ayuda de Google Code). El complemento prueba diferentes protocolos y métodos de transporte, según el tipo de conexión al momento de la llamada. Google Talk Voice and Video intenta establecer una conexión con uno de los siguientes protocolos y puntos finales de conexión, en el siguiente orden de preferencia: 1. Conexión UDP directa entre quien llama y la persona a quien se llama, por medio del protocolo STUN, en puertos al azar. 2.  Conexión UDP entre quien llama y la persona a quien se llama con NAT traversal, por medio del protocolo STUN, en puertos al azar. 3.  Conexión UDP entre quien llama y la persona que recibe la llamada mediante un servidor Google Relay, por medio del protocolo STUN, en puertos al azar. (Esta conexión funciona para NAT simétrico). 4. Conexión TCP directa entre quien llama y la persona a quien se llama. 5.  Conexión TCP entre quien llama y la persona a quien se llama mediante un servidor Google Relay. 6.  Conexión SSL por TCP entre quien llama y la persona que recibe la llamada mediante un servidor Google Relay en el puerto 443. Hangouts de Google+ Los Hangouts de Google+ intentan establecer una conexión entre un participante y un servidor de Google mediante un método similar al de Google Talk Voice and video. Para obtener detalles, consulte el Centro de ayuda para administradores. Configuraciones de firewall Para proporcionar a los usuarios todas las funciones (voz, video y texto) de Google Talk Voice and Video y los Hangouts de Google+, permita la salida de UDP de los clientes de su red a los hosts IPv4 en Google, en los puertos 4893, 19295, 19302, 19305-19309. Para obtener información acerca de las direcciones IPv4 de Google, consulte "Direcciones IPv4 de Google" en la página 19. Configuración de la red 21

Si no quiere permitir la salida de UDP de los clientes de su red, permita la salida de TCP de los clientes de su red a los hosts IPv4 en Google, en los puertos 19.294, 19.305-19.309. De todos modos, recuerde que exigir una conexión TCP para los servicios como la voz y el video creará una experiencia lenta y de baja calidad para los usuarios; por lo tanto, recomendamos permitir el uso de UDP saliente de su red. Para obtener información sobre las direcciones IPv4 de Google, consulte la sección "Direcciones IPv4 de Google" en la página 19. Google Talk negocia y establece llamas de voz y video por medio de la biblioteca de código abierto libjingle. Para obtener más información, consulte la Página del proyecto Google Code de libjingle. En el gráfico de red de Libjingle se ofrece un gráfico del comportamiento de red de la biblioteca de libjingle.

Enrutamiento de la red Al enrutar a Google Apps, el enrutamiento de red más simple generalmente proporciona el mejor rendimiento. Reduzca la complejidad y el enrutamiento de red innecesario de las ubicaciones de los usuarios a los centros de datos de Google. Uno de los objetivos del diseño de su red debe ser reducir el tiempo de ida y vuelta total de su red a Google. Si ve problemas de rendimiento, aborde los problemas de latencia antes de incrementar el ancho de banda. Para obtener el mejor rendimiento con las conexiones a Google Apps: •

Enrute el tráfico de red a Internet lo más cerca posible del usuario final en lo que respecta a la geografía y la topología de red.

•

Enfóquese en abordar los problemas de latencia antes que en los requisitos de ancho de banda. Por encima de un nivel mínimo de ancho de banda, las consideraciones sobre el ancho de banda son, por lo general, menos importantes para Google Apps.

•

Abra sus firewall a los puertos que utilizan los servicios de Google Apps.

•

No enrute su tráfico a direcciones IPv4 de Google ya que estas pueden cambiar. Use, en cambio, nombres de dominio. Si no puede enrutar por nombres de dominio, utilice las direcciones IPv4 publicadas y verifique si hay actualizaciones con frecuencia.

•

En caso de utilizar una topología de red de tipo radial (hub-and-spoke) o si su red cuenta con varias ubicaciones con un único punto de salida de red, puede considerar la idea de priorizar el tráfico.

•

Si configura la priorización del tráfico con direcciones IPv4 de Google, priorice solamente el tráfico HTTPS seguro para minimizar la priorización de algunos productos para consumidores de Google.

Optimización de la WAN Al planificar la estrategia de nube de su red, intente reducir la latencia y el tiempo de ida y vuelta. Los usuarios en oficinas remotas experimentarán un rendimiento más bajo si el tráfico de la red de área amplia (WAN) debe recorrer áreas geográficas grandes para llegar a Internet. Implemente puntos de salida de red lo más cerca posible geográficamente al usuario, ya que el tráfico de su WAN causa más congestión en algunos de sus vínculos con más uso de bits. Partes de esta optimización pueden lograrse mediante cambios en la resolución de DNS. Para obtener más información, consulte la sección "Resolución de DNS" en la página 29.

22

Prácticas recomendadas en materia de redes para implementaciones grandes

Priorización de tráfico Puede mejorar el rendimiento de Google Apps con la priorización del tráfico, dándole prioridad al tráfico de Google Apps sobre otro tráfico de la red para reducir la latencia de la red durante una congestión. La priorización de tráfico es posible en la capa de vínculo de datos y la capa de red; consulte las siguientes secciones para obtener información. Puede considerar la priorización de tráfico para reducir la latencia potencial si tiene alguno de los siguientes entornos: •

Topologías de red de tipo radial (hub-and-spoke)

•

Varias ubicaciones con un solo punto de salida de red

Priorización de la capa de red (Capa 3) Google Apps usa el mismo conjunto de direcciones IPv4 que el que usan otros productos de Google, incluidos los productos para consumidores como Gmail y Picasa. No es posible distinguir el tráfico a los diferentes productos. •

Si necesita una priorización de la capa de red, le sugerimos que realice una o más de las siguientes acciones: Priorice solo el tráfico HTTPS de Google a todos los bloques de red IPv4 de Google. Al priorizar solo el tráfico seguro HTTPS, puede minimizar la priorización de aplicaciones para consumidores.

•

Cree un archivo PAC de proxy que dirija todos los identificadores uniformes de recursos (URI) de Google Apps a un proxy que enrute solo el tráfico de Google Apps. Para obtener más información, consulte la sección "Configuración de un archivo PAC de proxy" en la página 25.

•

Configure su equipo de red para que priorice la interfaz de su red de proxy.

•

Distribuya los proxy para evitar la creación de una topología de red de tipo radial (huband-spoke).

Para obtener información sobre las direcciones IPv4 de Google y el uso del puerto TCP, consulte la sección "Direcciones IPv4 de Google" en la página 19.

Peering Peering es la interconexión directa de su red a la red de Google. Esto reduce la latencia y mejora la fiabilidad de la conexión entre su red y Google. Para la mayoría de los clientes de Apps, la mejor forma de hacerlo es elegir un proveedor de servicios de Internet (ISP) o un proveedor de red que ya tenga una interconexión de este tipo con Google. Google tiene una relación de peering con muchos proveedores de servicios de Internet en muchos lugares de todo el mundo. Esta es la forma más fácil y rápida de beneficiarse con una relación de peering cercana a Google. Póngase en contacto con su proveedor de servicios de Internet si este tiene una relación de peering con Google. En el caso de las redes empresariales más grandes, quizás sea posible establecer una relación de peering con Google de forma directa. Hay varios requisitos para establecer una relación de peering con Google. En general, si no tiene una relación de peering con otras redes, es más apropiado dejar que su proveedor de red de entrada maneje las relaciones de peering. Para obtener información sobre los requisitos de peering de Google, cuáles corresponden a los proveedores de servicios de Internet, los operadores de red y las redes corporativas, consulte la entrada de Google en PeeringDB. PeeringDB también incluye una lista de los puntos neutros y otras ubicaciones donde Google puede tener relaciones de peering. Configuración de la red 23

Si usted o su proveedor de servicios de Internet califica para el peering conforme a los requisitos de peering de Google, analice una relación de peering con el administrador de cuentas técnico de Google, un miembro del equipo de implementación o un representante de asistencia de Google Enterprise.

Herramientas de enrutamiento de la red •

Hay una serie de herramientas útiles disponibles para generar información detallada sobre el rendimiento de su conexión a Internet en el sitio web externo Measurement Lab. Puede utilizar estas herramientas para medir el rendimiento general del acceso a Internet.

•

El sitio PeeringDB es una base de datos de gran tamaño que está disponible para todo el mundo e incluye información sobre el peering.

Servidores proxy Al planificar la configuración de sus servidores proxy para los usuarios de Google Apps, tenga en cuenta las siguientes prácticas recomendadas: •

Evite enrutar datos de Google Apps mediante un proxy que inspeccione el contenido del tráfico HTTP, ya que esto reducirá el rendimiento, y gran parte del contenido de Google es dinámico o está encriptado.

•

Ubique sus servidores proxy en un lugar que esté cerca de sus usuarios y su punto de salida de Internet, tanto en lo que respecta a la geografía como a la topología de red.

•

Si necesita filtrar tráfico web por identificador uniforme de recursos (URI), considere utilizar un archivo de configuración PAC en el escritorio del cliente, ya que los URI del tráfico HTTP encriptado no son visibles para el proxy.

•

Si utiliza un servidor proxy compatible con las terminaciones SSL, puede configurar su servidor proxy para que inspeccione el contenido de Google Apps mientras releva la conexión segura.

Configuración de servidores proxy Le recomendamos no enrutar el tráfico de Google Apps mediante un servidor proxy. Si decide enviar tráfico de Google Apps mediante su proxy, busque parámetros de configuración en su servidor proxy que puedan afectar el tráfico de Google Apps. Busque configuraciones y parámetros de configuración que incluyan las siguientes condiciones: •

Filtros de contenido que puedan marcar el tráfico relacionado a Google como prohibido

•

Parámetros de configuración que puedan disminuir el número de conexiones simultáneas/ segundo por cliente

•

Tiempos de espera de SSL excesivamente largos o cortos (recomendamos la configuración predeterminada)

•

Versiones de firmware desactualizadas

•

Inspección de SSL sin aceleración de hardware

24

Prácticas recomendadas en materia de redes para implementaciones grandes

Si decide utilizar un servidor proxy en conjunto con Google Apps, mantenga su servidor proxy lo más cerca posible del cliente en lo que respecta a la geografía y la topología de red. Sus usuarios tendrán una mejor experiencia si minimiza tanto el número de saltos de red, como el tiempo de ida y vuelta entre los usuarios, el servidor proxy e Internet.

Inspección del contenido Evite la inspección de contenido en su servidor proxy. Cuando Google Apps está configurado para ejecutarse con HTTPS (una práctica común y que se recomienda), los servidores proxy no pueden inspeccionar el contenido ni restringir el acceso sin una configuración de proxy especial.

Filtrar el tráfico de Google Apps mediante un proxy La mayor parte del tráfico que va de los usuarios a los servidores de Google Apps consiste en transacciones HTTPS. Se prefiere este tipo de tráfico porque es seguro y fiable. Aunque la interrupción del tráfico a Google Apps para el filtrado es posible, puede disminuir la seguridad y reducir la experiencia general de los usuarios. Tenga en mente lo siguiente al planificar el filtrado de tráfico HTTPS a Google Apps. •

En los navegadores y protocolos que admiten la extensión del Identificador de nombre de servidor (SNI) para TLS, verá la solicitud para el nombre de host en el saludo inicial (HELLO) del cliente, en los registros de su proxy. En la siguiente página de Wikipedia hay una lista de esos navegadores. Consulte la documentación de su navegador para obtener información acerca de la compatibilidad con el SNI.

•

En versiones más antiguas de navegadores y SSL que no admiten la extensión del SNI para TLS, no verá la solicitud para el nombre de host en la página de saludo inicial del cliente, en los registros de su proxy. En este caso, sus usuarios generalmente ven un error de discordancia de certificado debido a la naturaleza del alojamiento virtual de Google Apps y servicios web similares. Asegúrese de usar un navegador que admita la extensión del SNI para TLS.

Después de la solicitud de saludo inicial entre el cliente/servidor, y una vez que la conexión TLS se haya establecido, se encripta todo el tráfico, incluida la ruta del URI después del nombre de host. Si necesita filtrar el tráfico de sus usuarios, hay dos formas recomendadas de hacerlo: •  Filtrar el tráfico de los usuarios con un archivo PAC de proxy al nivel del navegador antes de la encriptación es más fácil y menos costoso para implementar. Consulte la sección "Configuración de un archivo PAC de proxy" en la página 25. •  Realizar una intercepción e inspección de SSL después de la encriptación es más seguro, pero más difícil y costoso para implementar. Consulte la sección "Inspección de SSL" en la página 26.

Configuración de un archivo PAC de proxy Un archivo PAC de proxy es una manera rentable de filtrar tráfico porque la evaluación del URI e IPv4 se realiza en la máquina del cliente antes de la encriptación. Un archivo PAC de proxy es un conjunto de comandos JavaScript que el navegador usa para hacer una evaluación de acuerdo con las solicitudes de URI que se recibieron del usuario. El siguiente script de ejemplo incluye código para probar si un URI coincide con el formato https://*.google.com/*.

Configuración de la red 25

// If the URI matches https://*.google.com/* then route traffic // directly to the Internet. if (isPlainHostName(host) || shExpMatch(url,”https://*.google.com/*”) || return “DIRECT”; // All other URI requests should be routed through the proxy. else return “PROXY corporateproxy.domain.com:8080”;

Puede encontrar más ejemplos para desarrollar un archivo PAC de proxy en el sitio web externo FindProxyForURL.

Probar un archivo PAC de proxy Implementar un archivo PAC de proxy funcional requiere una prueba minuciosa. Use una herramienta de prueba de archivos PAC, como pactester, para probar las diferentes funciones de JavaScript. Un examinador de archivos PAC le permitirá pasar un nombre de host y un URI, y ver qué ruta tomará el navegador según el archivo PAC. Descargue pactester del sitio del proyecto pactest de Google Code.

Inspección de SSL En lo posible, evite la inspección de SSL. La inspección de SSL es efectivamente un “ataque de intermediario” de SSL en sus propios usuarios para examinar el contenido del tráfico HTTPS. Con las terminaciones SSL, los usuarios se conectan a un proxy como punto final. El proxy luego finaliza la conexión SSL e inspecciona el tráfico, y luego establece una nueva conexión al servidor de destino reenviando el tráfico. Esto puede causar un incremento significativo de carga en los proxy tradicionales que realizan estas operaciones en software, en lugar de en dispositivos de red. Hay muchos proveedores de dispositivos comerciales y servidores proxy de software que pueden realizar una inspección de SSL. Generalmente, esto requiere una configuración de proxy adicional. Cada configuración de inspección de SSL de servidores proxy es diferente, pero los pasos, por lo general, son los siguientes: 1. Autofirme un certificado con un nombre de host interno, como mail.example.com. 2. Instale el certificado de mail.example.com en el servidor proxy. 3. Escriba reglas de proxy personalizadas. Por ejemplo, reescriba conexiones de https:// mail.example.com/ a https://mail.google.com/a/example.com/. 4. Rechace conexiones con un encabezado de host que contenga mail.google.com. Nota:  Algunos proxy permitirán mantener el nombre de host y utilizar un certificado incorporado. Esto requiere que el navegador del usuario confíe en el certificado; de los contrario, los usuarios recibirán un error de certificado. Para obtener información sobre cómo resolver estos problemas relacionados con la inspección de SSL, consulte al proveedor de su servidor proxy y la documentación correspondiente.

26

Prácticas recomendadas en materia de redes para implementaciones grandes

Bloquear el acceso a los servicios para consumidores de Google Como administrador, puede impedir que los usuarios accedan a un servicio de Google utilizando una cuenta para consumidores en lugar de una cuenta de Google Apps for Business que les haya proporcionado. Por ejemplo, quizás no quiera que usen sus cuentas personales de Gmail. Además, puede impedirles que accedan a una cuenta de Google Apps de otro dominio. Una forma común de bloquear el acceso a servicios web es utilizar un servidor proxy web para filtrar tráfico dirigido a URI o nombres de host particulares. Este enfoque no es efectivo en este caso porque todos los URI a los que se accede entre cuentas para consumidores y de Google Apps for Business son iguales. Para permitir que los usuarios accedan solamente a servicios de Google utilizando cuentas de Google específicas de su dominio, necesita que el servidor proxy web agregue un encabezado HTTP al tráfico dirigido a *google.com; el encabezado identifica los dominios cuyos usuarios pueden acceder a los servicios de Google. Debido a que la mayor parte del tráfico de Google Apps se encripta, su servidor proxy también debe admitir la intercepción de SSL. (Consulte este artículo para obtener una lista de los servidores proxy que admiten tanto la intercepción SSL como la inserción de un encabezado HTTP). Para evitar que los usuarios accedan a los servicios de Google utilizando cuentas de Google que no sean aquellas que usted especificó de forma explícita, haga lo siguiente: 1. Enrute todo el tráfico saliente a google.com mediante su(s) servidor(es) proxy web. 2. Habilite la intercepción de SSL en el servidor proxy. Debido a que interceptará las solicitudes de SSL, probablemente le convenga administrar los certificados de cliente en cada dispositivo que utilice el proxy, de modo que el navegador del usuario no muestre advertencias para las solicitudes. 3. Para cada solicitud de google.com:

a. Intercepte la solicitud.



b. Agregue el encabezado HTTP X-GoogApps-Allowed-Domains, cuyo valor es una lista de valores separados por coma con nombres de dominio permitidos. Incluya el dominio que registró en Google Apps y los dominios secundarios que haya agregado.

Por ejemplo, permita que los usuarios accedan utilizando cuentas que finalicen en @ altostrat.com y tenorstrat.com, cree el siguiente encabezado con los nombres de dominio admitidos:

X-GoogApps-Allowed-Domains = altostrat.com,tenorstrat.com

4. Opcionalmente, cree una política de proxy para evitar que los usuarios inserten sus propios encabezados.

Monitorear el filtrado de URI En lo posible, evite filtrar URI con la inspección de SSL. Si usa filtros de URI, configure una política para supervisar los URI en los registros de proxy. Busque los URI que fueron bloqueados o admitidos de manera incorrecta. Estos cambios en los URI a los que se accedió pueden hacer que Google Apps se cargue parcialmente, lentamente o que no se cargue. Para evitar problemas con el filtrado de URI, si filtra sus servidores proxy, configure una política para realizar una supervisión constante de la carga de proxy y esté preparado para ajustar las reglas si es necesario. Para ayudar a descubrir qué podrían ser estos nuevos URI, pruebe los nuevos servicios y funciones de Google Apps en un entorno de prueba antes de autorizar su uso en producción. Para hacerlo, puede instalar una herramienta como HttpWatch o HttpFox. Configuración de la red 27

Herramientas de configuración de proxy Descargue las siguientes herramientas, que pueden ser útiles al configurar servidores proxy: •

Use pactester o una herramienta similar para validar los archivos PAC para los diferentes URI. Descargue pactester desde el sitio de Google Code.

•

Descargue HttpWatch o HttpFox (extensión de Firefox) para ayudar a ver qué URI solicita el navegador antes de la encriptación.

Otros servicios de red Google ejecuta un sistema de balanceo de carga sofisticado para garantizar la mejor experiencia a los usuarios. Un factor en este tipo de sistemas es la forma en que Google responde a las solicitudes de DNS para algunos servicios. Google intenta determinar la ubicación geográfica de un usuario, en parte mediante la ubicación de la dirección IPv4 del solicitante de DNS. Para garantizar la mejor experiencia a sus usuarios: •

Use un resolutor de DNS en una ubicación que esté cerca del usuario en lo que respecta a la geografía y la topología de red.

•

Evite utilizar resolutores de DNS instalados en ubicaciones de red remotas ya que esto disminuirá considerablemente la velocidad de las conexiones a Google Apps.

•

Utilice los valores de TTL sugeridos para todos los tipos de registros de DNS.

•

Configure reglas de firewall para permitir un tráfico HTTPS saliente ilimitado a Google Apps. No necesita configurar reglas especiales para el tráfico entrante; Google Apps generalmente no inicia tráfico entrante hacia los usuarios.

•

Evite enrutar el correo entrante y saliente a través de una pasarela dentro de su red. Si se enruta correo entrante y saliente a una pasarela dentro de su red, el tráfico de correo consumirá recursos de red innecesarios.

28

Prácticas recomendadas en materia de redes para implementaciones grandes

Resolución de DNS El siguiente gráfico muestra una resolución de DNS típica para un usuario de Google Apps en una red empresarial.

Google realiza consultas de registros A al DNS de forma dinámica para asegurarse de que los usuarios tengan la mejor experiencia al momento de realizar solicitudes. Para garantizar que esto suceda de forma apropiada, configure los resolutores de almacenamiento en memoria caché de DNS para que utilicen los valores de TTL especificados con cada registro. Utilizar el resultado almacenado en memoria caché más allá del valor de TTL en el registro de DNS puede tener como resultado una mala experiencia para el usuario. Eso sucede porque el registro de DNS almacenado en memoria caché puede dirigir a los usuarios a una dirección IPv4 no tan buena. A continuación se ofrece un ejemplo de los valores de TTL correspondientes a www.l.google.com: %dig +ttl www.l.google.com

Para esta consulta, podría ver los siguientes resultados: ; <<>> DiG 9.4.3-P3 <<>> +ttl www.l.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54488 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;www.l.google.com. IN A ;; ANSWER SECTION: www.l.google.com. 184 IN A 209.85.225.104 www.l.google.com. 184 IN A 209.85.225.99 www.l.google.com. 184 IN A 209.85.225.103 www.l.google.com. 184 IN A 209.85.225.105 www.l.google.com. 184 IN A 209.85.225.147 www.l.google.com. 184 IN A 209.85.225.106

En este ejemplo, el valor de TTL es 184 segundos, lo que equivale a 3 minutos. Asegúrese de que los servidores de DNS utilicen este valor al almacenar resultados en memoria caché. Configuración de la red 29

Si utiliza un servidor de DNS central para las ubicaciones remotas, los usuarios no tendrán la mejor experiencia; esto se debe a la forma en que Google Apps decide qué dirección IPv4 proporcionar al cliente que solicita el nombre de host. Una memoria caché de DNS local ayudará con estos problemas, pero si las solicitudes de DNS aún se enrutan mediante un servidor central para resolver los hosts de Internet, los usuarios pueden no conectarse a los servidores de Google Apps más cercanos. Para obtener más información acerca del enrutamiento y el rendimiento de DNS, consulte el documento RFC 2181, Clarifications to the DNS Specification (Aclaraciones de la especificación de DNS).

Configuración del firewall Con Google Apps y otras aplicaciones en la nube, los usuarios buscan recursos fuera de su red. Esto causa un cambio de recursos internos a externos en las conexiones HTTP. Debido a este cambio, los firewall salientes que previamente tenían una medida adecuada en su red podrían sobrecargarse. Tenga cuidado con este posible incremento en la congestión del firewall saliente. Las conexiones promedio, pico y en momentos sin actividad de las evaluaciones comparativas de la carga de los servidores proxy son una buena estimación de la carga de conexión que debe esperarse en su firewall saliente. Las únicas conexiones que no verá en su firewall saliente son aquellas que su servidor proxy impide. Para obtener más información sobre cómo reunir y utilizar estos datos, consulte la sección "Evaluación y medida de los servidores proxy" en la página 16.

Reglas del firewall saliente Para garantizar la mejor experiencia posible para los usuarios de Google Apps y proporcionar una conexión de latencia baja a nuestros sistemas, recomendamos dejar las reglas de firewall saliente tan abiertas como sea posible en los puertos 80/443 correspondientes al tráfico TCP/IP.

Reglas de firewall entrante Google Apps no inicia conexiones de los centros de datos de Google a su red. Todo el tráfico es iniciado por los clientes que están dentro de la red a Google. La única excepción es el video en Google Talk, en determinadas circunstancias. Para obtener más información, consulte la sección "Google Talk Voice and Video y los Hangouts de Google+" en la página 21.

Enrutamiento del correo Después de cambiar sus registros MX para enrutar el tráfico de correo a Google Apps, su correo electrónico no se entregará más a sus servidores por medio del protocolo SMTP. En cambio, el correo electrónico entrante se dirigirá a los servidores de Google Apps. Esto esencialmente elimina el tráfico de correo SMTP entrante en su red.

Conexiones de correo saliente Según sus necesidades, es posible que tenga tráfico de correo saliente que quiera enviar desde su propia red, como, por ejemplo, las comunicaciones en lote o automatizadas de las aplicaciones de su sistema. Para enrutar y filtrar su correo saliente de forma segura, puede usar Postini Services. Si no puede enviar correo saliente de aplicaciones a través de Postini, también puede enviar correo mediante Google Apps como usuario autenticado de Google Apps a través de SSL.

30

Prácticas recomendadas en materia de redes para implementaciones grandes

Capítulo 5

Configuración del cliente

Resumen Es importante entender los efectos que los diferentes clientes pueden tener en el rendimiento de Google Apps. Esta sección trata los elementos del entorno del cliente que pueden afectar el rendimiento de Google Apps, ofrece sugerencias para configurar la autenticación para el uso con Google Apps, así como también consejos para migrar los datos de los usuarios de un servidor existente a Google Apps.

Acceso de clientes Al realizar planes sobre los clientes que los usuarios utilizarán para acceder a Google Apps, considere lo siguiente: •

Para Google Apps, admitimos la última versión de Google Chrome (que se actualiza automáticamente cuando detecta la existencia de una nueva versión del navegador). También admitimos la versión actual y algunas anteriores de Mozilla Firefox, Microsoft Internet Explorer y Apple Safari. Consulte el Centro de ayuda para administradores para obtener más información acerca de las versiones admitidas de los navegadores.

•

Las versiones más actualizadas de los navegadores compatibles probablemente ofrezcan el mejor rendimiento en pruebas de velocidad con implementaciones grandes de Google Apps.

•

Considere utilizar dispositivos móviles Android o ActiveSync en lugar de dispositivos BlackBerry. Los servicios de BlackBerry Enterprise Services pueden consumir recursos de su red.

Requisitos de los navegadores Los usuarios tendrán una mejor experiencia con Google si usan un navegador moderno que muestre el contenido de Google Apps rápido y no consuma más recursos de procesamiento y memoria que los necesarios. Los navegadores que pueden enviar varias solicitudes en paralelo al mismo host incrementan considerablemente el rendimiento de Google Apps y mejoran la experiencia de los usuarios al usar este producto.

31

En Internet pueden encontrarse varios estudios independientes de rendimiento de los navegadores. Consulte estos estudios de velocidad para comprender mejor qué navegadores y versiones de navegadores ofrecen el mejor poder de procesamiento para el contenido HTML y JavaScript, mientras consumen la menor cantidad de recursos posible. Para Google Apps, los navegadores web recomendados son Google Chrome, Mozilla Firefox, la versión 8 (u otra superior) de Microsoft Internet Explorer y Apple Safari. Estos navegadores han mostrado el mejor rendimiento en pruebas de velocidad y en implementaciones grandes de Google Apps.

Acceso sin conexión El acceso sin conexión puede afectar el ancho de banda general de la red de manera considerable. Este tipo de acceso hace que el comportamiento de la red para el correo electrónico y otras aplicaciones sea similar a otros clientes de correo electrónico tradicionales, ya que el acceso sin conexión usa la sincronización de datos en lugar del acceso directo inmediato. Este comportamiento puede causar problemas de carga si todos los usuarios tienen habilitado el acceso sin conexión. En lo posible, habilite el acceso sin conexión en Google Apps solamente para los usuarios que lo necesiten.

Dispositivos móviles En la mayoría de los casos, los clientes para dispositivos móviles afectan muy poco la carga de la red. Esto varía según la solución para dispositivos móviles que utilice. Consulte las siguientes secciones para obtener detalles.

Android, iOS y Windows Phone Los dispositivos Android (que usan el protocolo Google Sync), y los dispositivos Windows Phone y Apple iOS (que usan el protocolo ActiveSync) se comunican directamente con los servidores de Google sin utilizar los recursos de su red. Consulte el siguiente gráfico para comprender mejor.

Estos dispositivos no acceden a su red al utilizar Google Apps. Con ActiveSync o Google Sync, Google Apps entrega este correo directamente al dispositivo del usuario. 32

Prácticas recomendadas en materia de redes para implementaciones grandes

Google Apps Connector for BlackBerry Enterprise Server A diferencia de los dispositivos Android y ActiveSync, los usuarios de BlackBerry Enterprise consumen recursos de la red al recibir correo de Google Apps y al enviar datos a la red de RIM y el dispositivo BlackBerry del usuario. Google Apps Connector for BlackBerry Enterprise Server actúa como un puente entre Google Apps y la red de RIM. Los servidores que ejecutan Google Apps Connector for BlackBerry Enterprise Server no necesitan estar en una ubicación cercana a los usuarios, ya que estos reciben sus mensajes desde la red de RIM en lugar de hacerlo desde el servidor. La comunicación entre el dispositivo de mano BlackBerry y el servidor de BlackBerry es similar a un servidor de BlackBerry configurado para Microsoft Exchange o Lotus Notes. Consulte el siguiente gráfico para comprender mejor.

Espere una carga de servidor y de red adicional cuando el dispositivo BlackBerry se active por primera vez. El servidor enviará los datos del usuario desde el servidor de BlackBerry que ejecuta el conector de Google Apps al dispositivo de mano del cliente a través de la red de RIM.

Configuración del cliente 33

La cantidad más grande de tráfico entre Google Apps y Google Apps Connector for BlackBerry Enterprise Server tiene lugar cuando se agrega un usuario al sistema BlackBerry a través del panel de administración de BlackBerry. Cuando se agrega un usuario al sistema, el software del conector crea una memoria caché local del correo electrónico, el calendario y los contactos del usuario. La memoria caché local puede tener un tamaño de varios cientos de megabytes porque contiene todos los datos del usuario del pasado reciente (30 días de forma predeterminada). Supervise el uso del ancho de banda al agregar varios usuarios al mismo tiempo.

Cliente Google Drive Sync Google Drive incluye una carpeta en línea Mi unidad y un cliente local; ambos usan HTTPS por TCP para sincronizar archivos entre sí. Esta sincronización de doble vía funciona aun en caso de que el dominio de Google Apps del usuario use el inicio de sesión único (SSO). El cliente Google Drive determina qué debe sincronizar según la configuración del usuario. De manera predeterminada, todo lo incluido en la carpeta en línea Mi unidad se sincroniza con la carpeta de Google Drive local del usuario. La información de archivo que se sincroniza depende de si el archivo es un documento de Google u otro tipo de archivo, como un PDF o un archivo de gráficos: •

Tipos de archivos que no son documentos de Google: Cuando un usuario sube un archivo a Google Drive o cambia la ubicación o el nombre de un archivo, Google Drive envía una notificación push al cliente Google Drive, que luego sincroniza todo el archivo. Si un usuario hace cambios en el contenido, el nombre del archivo o la ubicación de la copia local de un archivo, el cliente Google Drive detecta esto inmediatamente y envía de forma automática todo el archivo actualizado a Google Drive.

•

Tipo de archivos de Google Docs: El cliente almacena solamente los metadatos (el título y la ubicación de la carpeta) de forma local en la máquina del usuario. Por lo tanto, el cliente Google Drive consume menos ancho de banda durante la sincronización con el archivo en línea.

Recomendamos que los administradores alienten a los usuarios a convertir los documentos binarios en documentos de Google una vez que los hayan subido a Google Drive para aprovechar la colaboración incorporada en Google Drive. Además, si los usuarios utilizan Google Drive para editar y compartir sus documentos, el cliente Google Drive no necesitará sincronizar archivos binarios más grandes con la carpeta Mi unidad.

Autenticación Los usuarios pueden autenticarse en el servicio de Google Apps de dos formas: •

Mediante su propio servicio de Inicio de sesión único

•

Mediante la Autenticación de Google

Las organizaciones grandes generalmente usan un sistema de Inicio de sesión único para autenticar a los usuarios. También hay opciones para sistemas de Inicio de sesión único basados en la nube para organizaciones más pequeñas.

Inicio de sesión único Google Apps admite la autenticación basada en SAML 2.0 para todos los servicios de Google Apps. Las aplicaciones del lado del cliente, como es el caso de Google Apps Sync for Microsoft Outlook, también admiten el Inicio de sesión único. 34

Prácticas recomendadas en materia de redes para implementaciones grandes

Si planea configurar la autenticación de Inicio de sesión único, tenga en cuenta las siguientes recomendaciones: •

Configure los servidores de Inicio de sesión único en ubicaciones de red distribuidas, en lugar de hacerlo en una ubicación central.

•

Configure servidores de DNS internos para redireccionar el tráfico de SSO al servidor de SSO más cercano y asegúrese de instalar servidores de SSO alternativos para el servicio redundante en caso de que exista alguna interrupción del servicio que no permita a los usuarios acceder al servidor de SSO en una ubicación específica.

Proceso de inicio de sesión único Cuando un usuario no autenticado accede a Google Apps y se configura un identificador uniforme de recursos (URI) de SSO para el dominio, la autenticación implica varios pasos. Vea el siguiente gráfico.

El proceso de Autenticación de SSO es el siguiente: 1. El usuario hace una solicitud de un servicio de Google Apps. 2. El sistema de Autenticación de Google Apps redirige al navegador del usuario al URI configurado para el sistema de SSO. Si el servidor de SSO/SAML no está disponible, el usuario no puede autenticarse en el servicio. 3. El navegador se redirige al URI de acceso. 4. El servidor de SSO muestra una pantalla de acceso. 5. El usuario ingresa las credenciales de acceso y se autentica en el sistema de SSO. 6. El sistema de SSO pasa un token de autorización al navegador del usuario. 7. El navegador del usuario envía las credenciales de autorización al servicio de Google Apps. 8. El usuario recibe permiso para acceder al servicio de Google Apps. Configuración del cliente 35

Inicio de sesión único para ubicaciones de red seleccionadas Se puede crear un sistema de SSO condicional para sus usuarios basado en la máscara de subred de una red. Esto puede configurarse en el panel de control de Google Apps, en Herramientas avanzadas -> Configurar inicio de sesión único (SSO). Este tipo de configuración es recomendable ya que se puede ajustar para controlar si los usuarios que no pertenecen a la red usan el sistema de SSO. Recomendamos configurar Google Apps de modo que solo los usuarios que pertenezcan a la red requieran la autenticación con SSO. Los usuarios que no pertenecen a la red pueden, en cambio, utilizar el sistema de autenticación de Google. Esto garantiza que los usuarios que no pueden conectarse a la red privada virtual (VPN) puedan acceder igualmente a los servicios de correo básicos y reduce la carga en sus servicios de VPN. Este tipo de configuración requiere que los usuarios que acceden a Google Apps sin usar el sistema de SSO utilicen una contraseña almacenada en Google Apps. Nota:  Google no puede obligar a usar conexiones SSL cuando se utilizan gadgets de terceros, aplicaciones de Google Apps Marketplace y otros servicios. Póngase en contacto con los proveedores indicados de estos servicios para obtener información detallada sobre el nivel de uso de la autenticación segura.

Herramientas de autenticación Los programas de depuración de errores de SAML 2.0 son una herramienta útil para resolver errores relacionados con SAML durante el proceso de autenticación. Uno de ellos es SAML 2.0 Debugger.

Migración Las implementaciones de Google Apps suelen conllevar tráfico de la migración de los datos de los usuarios, ya sea mediante clientes locales, como Google Apps Migration for Microsoft Outlook, o clientes del lado del servidor, como Google Apps Migration for Lotus Notes o Google Apps Migration for Microsoft Exchange. Si migra los datos de los usuarios como parte de la implementación de Google Apps, puede esperar una carga de datos significativa, según la cantidad de información que quiera migrar. Para limitar el impacto en su red, recomendamos las siguientes prácticas: •

Asegúrese de que sus servidores de migración estén en la misma ubicación que los servidores de datos heredados o, al menos, de que la conectividad entre los servidores tenga latencia baja y un ancho de banda grande.

•

Evite enrutar tráfico de los servidores de migración a Google mediante servidores proxy para mejorar el rendimiento de la migración y evitar una carga innecesaria en los servidores proxy.

•

Antes de la migración, evalúe la capacidad de su red para determinar la cantidad máxima de información que puede migrar simultáneamente. Ajuste su plan de migración como corresponda.

•

Durante la migración, algunas de las conexiones establecidas con los servidores de Google pueden permanecer abiertas durante un período de tiempo, según la herramienta de migración que utilice. Para evitar posibles errores de migración y reducir la necesidad de tener que volver a migrar datos, es importante mantener abiertas estas sesiones y no dejar que se cierren temprano porque se agotó el tiempo de espera del proxy o del firewall.

36

Prácticas recomendadas en materia de redes para implementaciones grandes

Migración del lado del servidor Sus servidores de migración deben tener latencia baja y una conexión de ancho de banda grande a su servidor de correo electrónico. La migración implica mucho tráfico y consume mucho ancho de banda, así que puede esperar una carga de red significativa entre el servidor de correo electrónico y el servidor de migración. Nota: No instale el software de migración en las máquinas que manejan el correo de su dominio ya que eso consumirá una cantidad significativa de recursos del sistema.

Configuración del cliente 37

38

Prácticas recomendadas en materia de redes para implementaciones grandes

Capítulo 6

Monitoreo de la red

Resumen Una vez que su red esté configurada para funcionar con Google Apps y los usuarios estén habilitados, puede mantener la calidad de la experiencia de sus usuarios mediante el monitoreo del estado de su red. Para garantizar la mejor experiencia de los usuarios, siga estas sugerencias sobre herramientas de monitoreo y trazas de red.

Herramientas de monitoreo Hay varias herramientas comerciales y de código abierto para monitorear varios aspectos de su red. En el sitio SLAC Network Monitoring Tools (Herramientas de monitoreo de red del SLAC) hay un directorio completo de herramientas de monitoreo de red. En la siguiente tabla se recomiendan herramientas específicas. Tipo de monitoreo

Herramienta

Descripción

Monitoreo de dispositivos

mrtg

Cambios de DNS

dns-rr-monitor Monitorea un registro de recursos específico y le avisa sobre cambios.

Monitoreo de hosts

smokeping

Monitorea y planifica los tiempos de ida y vuelta a varios destinos. Es sumamente configurable.

Servidor espejo

Lista de ejemplo 1

Un servidor espejo proporciona una vista de solo lectura de la información de enrutamiento del operador de una red (esto incluye las conexiones, la latencia y otros factores) en un punto remoto de otra red.

Lista de ejemplo 2 red

pingplotter

Monitorea y grafica varios aspectos relativos a los dispositivos de red.

Ayuda a monitorear la latencia y el tiempo de actividad de la red, así como también los cambios en las rutas.

39

Tipo de monitoreo

Red

Herramienta

multiping

Descripción

Ayuda a monitorear la latencia y el tiempo de actividad de la red, y también cambios en las rutas.

Captura de paquetes Wireshark

Realiza capturas de paquetes.

Latencia del tiempo de ida y vuelta

wbox

Intenta medir el tiempo de ida y vuelta de la latencia de las aplicaciones web mediante la latencia HTTP/TCP.

Rastreo

tcptrace

Similar a traceroute, pero usa paquetes TCP en lugar de paquetes ICMP.

Capturas de paquetes de red Una captura de paquetes de red puede ayudarlo a descubrir problemas que podrían afectar negativamente el tiempo de ida y vuelta o la latencia general de los usuarios de Google Apps, como, por ejemplo: •

Diferentes tipos de problemas de saturación de la red (ARP, TCP, UDP, IP, etc.)

•

Incompatibilidad de la unidad máxima de transferencia (MTU) para Ethernet

•

Tráfico malicioso en su red

Las capturas de paquetes son útiles, aunque Google Apps generalmente usa conexiones HTTPS. Las capturas de paquetes mostrarán igualmente paquetes caídos, retransmisiones, cambios de tamaño de ventanas y evidencia de vínculos saturados. Una forma de reunir este tipo de datos es habilitar el puerto espejo, que permite capturar el tráfico de un determinado puerto o VLAN, y desviarlo a otro puerto donde un servicio escuche y registre todo el tráfico. Otra forma es utilizar tecnologías como Wireshark para capturar información sobre una máquina a fin de realizar un análisis posterior.

40

Prácticas recomendadas en materia de redes para implementaciones grandes