Planificación de la geografía
En este tema se tratan las ventajas y desventajas de los servidores de Sametime en toda una geografía e incluye consideraciones como, por ejemplo, los husos horarios, los efectos del uso simultáneo en el rendimiento, el impacto en la red y el coste del hardware.
Si la suya es una organización transcontinental, deberá pedir si desea despliegues regionales o centralizados del servidor de comunidades de Sametime.
Muchas compañías dividen las agrupaciones o los usuarios por geografía. No obstante, para ello, cada geografía tendría que alojar un conjunto de servidores conectados a los que los usuarios pudiesen entrar mediante distintos URL. Por ejemplo, si la empresa Acme Company dividió a sus usuarios geográficamente entre EE.UU. y Asia Pacífico, tendrían dos URL, por ejemplo, us.acme.com y ap.acme.com. Esto requeriría actualizaciones de cliente en los clientes de Sametime de todo el mundo para ir al nombre de servidor correcto. También significaría un aumento en el coste del hardware. Cuando los servidores están distribuidos por geografías, el impacto sobre la red es menor, y podrá utilizar el principio de "seguimiento del sol" (ininterrumpido) para determinar el máximo de usuarios simultáneos a los que debe suministrar.
Cuando todos los servidores se encuentran en una ubicación, puede sacar provecho de los distintos husos horarios de modo que no sean necesarios muchos servidores. Puede decidir dejar que los diferentes husos horarios trabajen a su favor. Por ejemplo, digamos que tiene 300.000 usuarios. Para configurar los servidores de la geografía Asia Pacífico, tendría que tener suficientes servidores para manejar una carga de 150.000 usuarios simultáneamente, o suficientes servidores de EE.UU. como para manejar los 150.000 usuarios simultáneos. Como los servidores están ubicados de manera central, puede tener suficientes servidores para manejar una carga máxima de 225.000 usuarios y mantenerlos funcionando en todo momento. Para este despliegue, probablemente necesitaría tres servidores para aproximadamente 225.000 usuarios simultáneos al día.
Si todos los servidores están en una ubicación, puede sacar el máximo provecho a todos los servidores de manera ininterrumpida. Algunas compañías permiten que los distintos husos horarios actúen a su favor. En lugar de tener algunos servidores bajo mucha carga algo de tiempo debido a los diferentes grupos de todo el mundo, la población de usuarios se divide de manera relativamente uniforme entre todos los servidores/agrupaciones de modo que los servidores puedan mantener un uso y un estado más coherente en todo momento. Los usuarios se ordenan en diferentes servidores y/o agrupaciones mediante un atributo Servidor asignado establecido en su registro de personas LDAP.
Despliegue de Sametime en IBM
El despliegue de Sametime en IBM® tiene todos los servidores en una única ubicación. La población de Sametime de la empresa es de aproximadamente 425.000 usuarios. IBM decidió permitir que los husos horarios actuasen a su favor. IBM no utilizó este método para identificar el servidor asignado del usuario porque el servidor de Sametime utiliza un LDAP compartido que el equipo de despliegue de Sametime no controlaba. Agregar y rellenar un campo para todos los registros de usuarios de IBM no era factible. IBM determinó que tres agrupaciones cada una de ellas con tres servidores era el número óptimo para aproximadamente 225.000 usuarios simultáneos al día. Consulte Despliegue de Sametime en IBM para obtener más información.
Una comunidad y tres bases de datos vpuserinfo.nsf
Normalmente, la mayoría de los administradores dividirán sus usuarios en agrupaciones. Disponer de una agrupación en IBM significa que la base de datos de lista de contactos vpuserinfo.nsf será demasiado grande. Cada acción como, por ejemplo, buscar, cargar, etc. llevaría demasiado tiempo. IBM tuvo la idea de dividir la información del usuario en tres archivos, uno para cada agrupación. Cada agrupación tendría su propia vpuserinfo.nsf. Todos los servidores de una agrupación comparten información sobre los usuarios como, por ejemplo, listas de contactos, listas de privacidad y alertas. Toda esa información del usuario está incluida en una única base de datos denominada vpuserinfo.nsf. Al utilizar tres agrupaciones, pudimos reducir el tamaño de un único archivo vpuserinfo.nsf a un tercio de su tamaño original. Para reducir el archivo vpuserinfo.nsf, el equipo de desarrollo de Sametime creó una herramienta que tomó el archivo único vpuserinfo.nsf y desglosó toda la información de usuarios en el número necesario de agrupaciones en función del algoritmo que se utilizaba para sus inicios de sesión. Esto nos permitió tomar un vpuserinfo.nsf de aproximadamente 15 GB y dividirlo en 3 archivos vpuserinfo.nsf de unos 5 GB cada uno.
Cálculo del servidor asignado de un usuario
Cuando un usuario inicia sesión, el usuario es dirigido a una agrupación y a uno de los tres servidores de la agrupación. Si los datos de un usuario están en la agrupación 2, el usuario deberá iniciar sesión en la agrupación 2. El usuario solo necesita iniciar sesión en un servidor de la agrupación. A través de un algoritmo que calcula el nombre del usuario, Sametime siempre sabe a qué servidor pertenece el usuario. Los desarrolladores de Sametime hallaron el modo que permite establecer el campo del servidor asignado en la capa del servidor para determinar, mediante un algoritmo, la agrupación y el servidor a los que son enviados los usuarios cuando inician sesión. Tras el primer inicio de sesión, los usuarios siempre son enviados a la misma agrupación. Esto sucede gracias a un archivo de clase personalizado especificado en los valores LDAP de la base de datos de configuración de Sametime (stconfig.nsf). Los archivos de clase personalizados de los valores LDAP de stconfig.nsf se han usado en Sametime durante muchos años. Para obtener más información sobre archivos de clase personalizados, consulte la sección titulada "Usar clases Java para personalizar búsquedas de directorio LDAP" en la documentación del producto de Sametime. Cuando un usuario inicia sesión en la agrupación, la información de dicho usuario ya se habrá replicado en los servidores de la agrupación.