Gracias por sus comentarios.
Límites de capacidad de usuario para servicios híbridos basados en Expressway
¿Comentarios?El servicio de llamadas híbridas en la arquitectura Call Connector ha terminado su vida útil (EOL), por lo que el servicio ya no cuenta con soporte oficial. El conector de llamadas no debe ser considerado para la futura planificación de la capacidad de las autovías para los servicios híbridos.
Este artículo no cubre la planificación de capacidad para la integración del servicio de calendario híbrido de Cisco TMS con Office 365 o la integración de Cisco TMS con Google Calendar. Para obtener información sobre la capacidad, consulte la Guía de implementación para el servicio de calendario Cisco Webex híbrido.
Proporcionamos este artículo para abordar sus preguntas de planificación de capacidad y explicar cómo calculamos la escala de usuario. Para modelar su escenario, pruebe la calculadora de capacidad de Hybrid Services.
Consideraciones de planificación
Cuando planifica la capacidad de Expressway para su población de usuarios de servicios híbridos, tenga en cuenta las siguientes preguntas:
-
¿Qué servicios híbridos necesita?
La autopista puede alojar conectores para el servicio de llamadas híbridas, el servicio de calendario híbrido y el servicio de mensajes híbridos.
-
¿Cuántos usuarios tiene, para cada servicio?
Cuantos más usuarios tenga para cada servicio, más probable es que quiera dedicar clústeres de Expressway a los servicios. Para poblaciones más pequeñas, ejecutar varios conectores en un clúster compartido (coresidencia) es una opción válida.
-
¿Sus necesidades van a cambiar?
Es posible que desee comenzar poco a poco, con un clúster de Expressway que brinde servicio a un grupo de usuarios tempranos en su organización y planificar el crecimiento para una implementación futura. Puede migrar de un modelo compartido a un modelo dedicado, o escalar su clúster existente, para satisfacer sus requisitos cambiantes.
Factores que contribuyen
Definimos la capacidad de un clúster en términos de las siguientes variables:
-
Tamaño de nodo: cada máquina virtual de Expressway tiene un “tamaño de máquina virtual” que se determina en el momento de la instalación por los recursos asignados a la máquina virtual. Las guías de instalación de Expressway describen esos requisitos. Si ya tiene una autopista, puede leer el tamaño de la máquina virtual en la página de la interfaz de Expressway.
-
Recuento de nodos: un clúster de Expressway puede tener entre uno y seis nodos. Deben tener el mismo tamaño de nodo y ejecutar la misma versión de software.
-
Estrategia de continuidad del servicio: los servicios utilizan estrategias para garantizar un servicio continuo a los usuarios. El servicio de calendario y el servicio de mensajes utilizan una estrategia de conmutación por error.
Las estrategias se detallan en la tabla Estrategias de continuidad del servicio y escala de clústeres dedicados.
-
Coresidencia: cuando los conectores comparten un clúster de Expressway, los recursos disponibles para cada servicio son significativamente más bajos en comparación con el clúster dedicado.
También puede haber otros servicios basados en Express en su host de conector, como llamadas de empresa a empresa (B2B) o móviles y Remote Access (MRA). En los escenarios limitados donde se admite este tipo de coresidencia, los números de escala que documentamos aquí están limitados a lo que hemos probado. Más allá de lo que se describe en este artículo, el clúster Expressway del host conector no debe compartirse con otros servicios; esto no es compatible.
-
Limitaciones específicas del servicio: por ejemplo, Calendar Connector está diseñado principalmente para Microsoft Exchange usuarios y admite un número limitado de usuarios de Office 365.
Cálculos para clústeres de autovías dedicadas
Establecemos un límite para la cantidad de usuarios de servicio que una sola autopista dedicada puede administrar (un “clúster de uno”), basado en la evidencia que recopilamos en pruebas y ensayos.
| Tamaño del nodo de la autopista | Escala de servicio de calendario híbrido | Escala de servicio de mensajes híbridos |
|---|---|---|
| 1. Pequeño | 5000 | 5000 |
| 2. Medio | 10000 | 6500 |
| 3. Grande | 15000 | 15000 |
Utilizamos los algoritmos de continuidad del servicio para extrapolar los números de nodo único a varios clústeres de nodos, como se explica en la siguiente tabla. Si quiere los resultados sin la explicación, vea:
|
Compare |
Servicio de calendario híbrido |
Servicio de Mensajes Híbrido |
|---|---|---|
|
1. Modelo |
Modelo de conmutación por error |
Modelo de conmutación por error |
|
2. Descripción |
Asignamos a cada usuario a un nodo en el clúster. Esto extiende a los usuarios a través de todos los nodos. Si un nodo se apaga, recreamos las asignaciones de usuario de ese nodo en los otros nodos. Cuando el nodo vuelve a activarse, reequilibramos las asignaciones de usuarios en todos los nodos activos. |
Asignamos a cada usuario a un nodo en el clúster. Esto extiende a los usuarios a través de todos los nodos. Si un nodo se apaga, recreamos las asignaciones de usuario de ese nodo en los otros nodos. Cuando el nodo vuelve a activarse, reequilibramos las asignaciones de usuarios en todos los nodos activos. |
|
3. Fórmula |
U CalN = (N-1) * U cal1 |
U MSGn = (N-1) * U msg1 |
|
4. Definiciones |
Dónde: U CalN es el clúster de capacidad N para usuarios de Calendar Service N es el número de nodos U cal1 es la capacidad de nodo único para los usuarios de Calendar Service |
Dónde: U msGn es el clúster de capacidad N para usuarios del servicio de mensajes N es el número de nodos U msg1 es la capacidad de nodo único para los usuarios del servicio de mensajes |
|
5. Notas |
Si N = 1, no hay conmutación por error. La conmutación por error es automática y obligatoria si N>1. Si N = 2, la capacidad es la misma que si N=1, con una mejor continuidad del servicio. Escale los beneficios de N>=3 o usando un tamaño de nodo más grande. |
Si N = 1, no hay conmutación por error. La conmutación por error es automática y obligatoria si N>1. Si N = 2, la capacidad es la misma que si N=1, con una mejor continuidad del servicio. Escale los beneficios de N>=3 o usando un tamaño de nodo más grande. |
Cálculos para clústeres de autovías compartidas
Nuestro algoritmo asume que los conectores coresidentes comparten proporcionalmente los recursos de un solo nodo. Este algoritmo establece de manera conservadora el límite para cada tipo de usuario en el nodo.
Por ejemplo, la siguiente tabla muestra el número máximo de usuarios para todos los casos dedicados y los casos de coresidencia en una sola autopista mediana.
| Propósito de la autopista | Usuarios del servicio de calendario | Usuarios del servicio de mensajes |
|---|---|---|
|
| ||
| Dedicado al servicio de calendario |
10,000 |
— |
|
Dedicado al servicio de mensajes |
— |
6,500 |
|
Compartido por el servicio de calendario y el servicio de mensajes |
4,000 |
4,000 |
|
Compartido por Calendario, Llamadas y Servicios de Mensajes |
2,300 |
2,300 |
No enumeramos exhaustivamente todos los estados de coresidencia para todos los tamaños de clúster. En su lugar, puede supervisar la capacidad de su implementación existente de servicios híbridos o usar la calculadora para planificar una nueva implementación.
La calculadora le permite elegir conectores, tamaño de nodo y número de nodos, para que pueda modelar su implementación. El resto de esta sección explica cómo calcula los números de usuario de su modelo.
Al igual que hicimos con la autopista dedicada, extrapolamos el algoritmo de las autopistas compartidas para determinar los números de usuario para múltiples nodos. La diferencia con respecto a los casos dedicados es que aplicamos el cálculo de continuidad del servicio adecuado para obtener la escala de usuario para un servicio particular en el clúster. No podemos calcular la escala de usuario para el clúster porque el clúster aloja estrategias de continuidad del servicio basadas en el usuario competidoras.
|
Propósito del clúster |
Usuarios del servicio de mensajes híbridos para 1,2 y 3 nodos | ||
|---|---|---|---|
|
Dedicado al servicio de mensajes |
6,500 |
6,500 |
13,000 |
Factores contribuyentes adicionales
Puede haber demandas competitivas en los recursos del clúster que disminuirán la capacidad del usuario. Estos son los ejemplos conocidos:
Servicio de calendario: el host del conector también puede dar servicio a los usuarios de O365. Los números y cálculos que se muestran aquí suponen que solo su infraestructura local de Exchange proporciona el servicio de calendario. Para obtener más información sobre el servicio de calendario 'híbrido', tenemos algunos números y gráficos en la sección Servicio de calendario de este artículo.
Procesamiento de llamadas: el host del conector también puede procesar la señalización de llamadas y los medios. Esto es efectivamente una integración de “empresa a empresa” entre su organización y la nube de Webex. Esto reduce la capacidad como se describe en Coresidencia con otras soluciones de autopista.
Puede usar Control Hub para ver un valor porcentual de la capacidad de usuario actual de cada uno de sus recursos de Hybrid Services Expressway. Una barra de color indica si la capacidad está dentro de los límites aceptables. Esta vista le permite evaluar el estado de sus implementaciones de servicios híbridos y le guía en cuanto a cuándo necesita más autopistas.
-
Verde: sus autopistas están dentro de los límites de capacidad aceptables. (1%–60%)
-
Amber —Tiene suficientes autopistas pero está cerca de alcanzar los límites de capacidad. (61%–90%)
-
Rojo: no tiene suficientes autopistas y debe agregar más. (91% y más)
Si sus autopistas están en un grupo de recursos, el indicador de capacidad aparece bajo una vista filtrada de los clústeres del grupo de recursos.
-
Para implementaciones sin grupos de recursos (predeterminado):
-
Desde la vista del cliente en https://admin.webex.com, vaya a y, a continuación, desplácese hasta las tarjetas de servicio híbridas para ver el porcentaje de capacidad utilizada en los recursos de Expressway para cada servicio.
-
-
Para implementaciones con grupos de recursos:
-
Si el valor de capacidad es N/A, elija un grupo de recursos de Filtro para revisar los grupos de recursos y la capacidad.
El valor se actualiza para mostrar el porcentaje de capacidad que se utiliza para los clústeres en ese grupo de recursos y la codificación por colores para indicar el estado.
-
Cosas a tener en cuenta
-
La capacidad del clúster varía según el tamaño del nodo, el número de nodos en el clúster de Expressway, la cantidad de servicios que se ejecutan en el clúster y la estrategia de alta disponibilidad o conmutación por error. Para obtener más información, consulte las secciones Calendario y Escala de mensajes individuales.
-
La coresidencia reduce la escala de usuarios para los servicios existentes; el algoritmo de capacidad asume que cada usuario está utilizando todos los servicios.
Recomendamos la coresidencia cuando está probando varios servicios, o si tiene una implementación a pequeña escala. Para los servicios en producción o para implementaciones a gran escala, le recomendamos que ejecute los diferentes servicios híbridos en clústeres Expressway dedicados.
Qué hacer a continuación
Para agregar más Expressways for Hybrid Services, utilice los pasos de la guía de implementación para registrar hosts de conectores en la nube y agregarlos a clústeres existentes:
La capacidad de un clúster de Expressway para dar servicio a los usuarios del servicio de calendario híbrido depende del tamaño de los nodos Expressway-C constituyentes, el número de nodos en el clúster de Expressway y la estrategia de continuidad del servicio.
La siguiente tabla muestra el número máximo de usuarios en una sola autopista dedicada a los diferentes entornos de calendario híbrido.
|
Entorno del calendario |
Autopista pequeña |
Autopista media |
Autopista grande |
|---|---|---|---|
|
Intercambio local solamente |
5.000 usuarios |
10.000 usuarios |
15.000 usuarios |
|
Office 365 únicamente* |
1.000 usuarios |
1.000 usuarios |
1.000 usuarios |
|
Exchange local y Office 365* (implementaciones de Exchange híbrido) |
Máximo de 1.000 usuarios de Office 365 de un total de 5.000 usuarios |
Máximo de 1.000 usuarios de Office 365 de un total de 10.000 usuarios |
Máximo de 1.000 usuarios de Office 365 de un total de 15.000 usuarios |
* Para evitar esta limitación de escala, le recomendamos que utilice el servicio de calendario basado en la nube en lugar del conector local. Para el calendario híbrido basado en Expressway, la limitación de la capacidad de usuarios de Office 365 a 1.000 por clúster es independiente del tamaño o número de nodos del clúster; esta limitación se deriva de la interacción con el servicio en la nube de Microsoft y no de la escala de la implementación de Expressway en las instalaciones.
Tenga en cuenta que la capacidad de usuario es la misma para un clúster de un nodo y para un clúster de dos nodos. Esto se debe a que Calendar Service utiliza la conmutación por error para mejorar la continuidad del servicio. Todos los usuarios se asignan a un nodo cuando hay dos nodos en el clúster; el otro nodo es un backup redundante. Consulte Planning Expressway Cluster Capacity para usuarios de servicios híbridos para obtener una explicación detallada.
La capacidad de un clúster de Expressway para los usuarios de Hybrid Calendar Service depende principalmente del tamaño y la cantidad de nodos del clúster y de la estrategia de continuidad del servicio. La siguiente tabla muestra la capacidad total máxima de usuario que puede manejar el clúster a medida que aumenta los nodos (o el tamaño de OVA del nodo) en un único clúster dedicado.
En un entorno híbrido de Exchange con usuarios de Office 365, hay un límite de 1.000 usuarios de Office 365 por clúster, independientemente del número o tamaño de nodos del clúster. El servicio basado en la nube es el método preferido para manejar a los usuarios de Office 365. Le recomendamos encarecidamente que aloje temporalmente a los usuarios de Office 365 en Expressway.
Esta limitación se deriva de la interacción con el servicio en la nube de Microsoft y no de la escala de la implementación de Expressway en las instalaciones. Por ejemplo, si tiene un único nodo Expressway pequeño, su capacidad está limitada a 1.000 usuarios de Office 365 y 4.000 Microsoft Exchange usuarios. Si tiene un clúster de 6 nodos pequeños, su capacidad está limitada a 1.000 usuarios de Office 365 más 24.000 Microsoft Exchange usuarios.
|
Tamaño del nodo de la autopista |
1 o 2 Nodos* |
3 Nodos |
4 Nodos |
5 Nodos |
6 Nodos |
|---|---|---|---|---|---|
|
1. Pequeño |
5K |
10K |
15K |
20K |
25K |
|
2. Medio |
10K |
20K |
30K |
40K |
50K |
|
3. Grande |
15K |
30K |
45K |
60K |
75K |
* Tenga en cuenta que la capacidad de usuario es la misma para un clúster de un nodo y para un clúster de dos nodos. Esto se debe a que Calendar Service utiliza la conmutación por error para mejorar la continuidad del servicio. Todos los usuarios se asignan a un nodo cuando hay dos nodos en el clúster; el otro nodo es un backup redundante. Consulte Planning Expressway Cluster Capacity para usuarios de servicios híbridos para obtener una explicación detallada.
Asignación de usuarios a través de hosts y clústeres
De forma predeterminada, el servicio de calendario híbrido asigna y distribuye automáticamente a los usuarios de manera uniforme en todos los conectores de calendario de un clúster. La asignación es dinámica en función de la disponibilidad y el administrador no tiene control sobre a qué nodo en particular está asignado un usuario individual.
En los casos en que una organización tiene más de un clúster, la distribución de usuarios se basa en múltiples factores, incluida la disponibilidad del clúster, la asignación actual (para reducir las oscilaciones durante la recuperación de errores) y un orden de clasificación basado en la preferencia de clúster más alta. El administrador también tiene la capacidad de asignar un usuario o grupo de usuarios a un grupo de recursos. Los grupos de recursos son específicos del clúster, por lo que permiten a los administradores restringir la asignación de conjuntos particulares de usuarios a un clúster específico.
Con esta comprensión básica de la asignación de usuarios y teniendo en cuenta los requisitos previos del conector de calendario de Expressway, un administrador puede implementar la capacidad adecuada a escala para su organización. Veamos un ejemplo de organización de 126.000 usuarios que se habilitarán para el servicio de calendario híbrido, dados los siguientes parámetros:
-
Clústeres de Expressway de 6 nodos que utilizan la plantilla OVA grande (límite de 15.000 usuarios por nodo)
-
No se requieren grupos de recursos
La fórmula de capacidad para un solo clúster, U CalN = (N-1) * U cal1 donde N=6 y U cal1 = 15.000 (usando la plantilla OVA grande) produce un máximo de 75.000 usuarios. Con un total de 126.000 usuarios en la implementación del servicio de calendario, se requieren varios clústeres de host de Calendar Connector. Los usuarios se distribuirían por igual como se muestra en la siguiente figura:
El servicio de calendario híbrido agrega usuarios al clúster A primero hasta que el clúster alcanza la capacidad de 75,000 usuarios y, a continuación, asigna los usuarios restantes al clúster B. Los usuarios se distribuyen de manera aleatoria e igualitaria en todos los nodos dentro del clúster. Este ejemplo muestra una distribución igual de nodos host de Calendar Connector (dentro de cada uno de los dos clústeres) en los centros de datos RTP y PDX. Cada nodo utiliza la misma plantilla OVA y sigue las pautas de alta disponibilidad de Expressway. El conector de calendario utiliza la lógica de agrupamiento de Expressway en un modelo de redundancia 5+1 para permitir escenarios de alta disponibilidad.
Con todos los usuarios asignados a un conector de calendario, examinemos ahora qué sucede cuando hay una falla en un clúster. La siguiente figura muestra un fallo de un solo nodo. Los usuarios asignados al nodo fallido, 5A en el clúster A, ahora han fallado en los nodos restantes de ese clúster. Una capacidad de nodo único permite hasta 15.000 usuarios y cada nodo restante en el clúster A agrega 2500 usuarios que fueron asignados originalmente en el nodo 5A. No hay ningún cambio o impacto en el clúster B o en los usuarios asignados en el clúster B.
El clúster A todavía está a su capacidad máxima y cada uno de los nodos operativos del clúster está ahora a su capacidad máxima, 15.000 usuarios/nodo. Por lo tanto, si otro nodo del clúster A deja de estar disponible, como el nodo 4A en la siguiente figura, el clúster B ahora será responsable de recoger la carga adicional del usuario. Los 15.000 usuarios del nodo 4A ahora se reasignan al clúster B y se distribuyen equitativamente entre todos los nodos dentro del clúster B.
Cuando los nodos 4A y 5A se recuperan, los usuarios del clúster A se redistribuirán entre los nodos del clúster. Los usuarios que fallaron en el clúster B permanecen en el clúster B durante esta fase de recuperación para evitar asignaciones de usuarios innecesarias entre clústeres, como se muestra en la siguiente figura.
Un elemento clave que debe tener en cuenta al planificar una implementación del servicio de calendario híbrido a gran escala es comprender el impacto de una falla si ocurriera en la implementación. Si usamos la misma implementación de 126.000 usuarios pero perdemos un centro de datos completo, existe la posibilidad de que los usuarios no se asignen a un nodo de Calendar Connector. Para evitar una interrupción del servicio en este tipo de escenario, el cliente necesitaría un tercer clúster para redistribuir y manejar a los usuarios afectados.
La capacidad de un clúster de Expressway para dar servicio a los usuarios de Hybrid Message depende del tamaño de los nodos de Expressway constituyentes, el número de nodos en el clúster y la estrategia de continuidad del servicio.
La siguiente tabla muestra el número máximo de usuarios en una sola autopista que se utiliza para el mensaje híbrido.
|
Autopista pequeña |
Autopista media |
Autopista grande |
|---|---|---|
|
5.000 usuarios |
6.500 usuarios |
15.000 usuarios |
Los números de usuario son los mismos para un clúster de un nodo y para un clúster de dos nodos. Esto se debe a que Message Service utiliza la conmutación por error para mejorar la continuidad del servicio. Los usuarios se distribuyen uniformemente entre los múltiples nodos del clúster: si un nodo falla, los usuarios de ese nodo se asignan a los otros nodos.
Este tema trata sobre cómo compartir un host de conector Expressway entre los conectores para varios servicios híbridos, incluidos el servicio de calendario y el servicio de mensajes. El host del conector no se comparte con otras soluciones basadas en Expresway, como MRA y B2B.
La capacidad del clúster host del conector depende del tamaño de los nodos Expressway constituyentes, el número de nodos, los conectores que se ejecutan en el clúster y la estrategia de continuidad del servicio. Consulte Planning Expressway Cluster Capacity para usuarios de servicios híbridos para obtener una explicación detallada de estos factores.
También hay una calculadora para que modele diferentes clústeres de host de conectores y vea cuántos usuarios de cada servicio puede soportar su clúster propuesto.
En general, recomendamos la coresidencia solo para implementaciones de menor tamaño de hasta dos nodos. Si su implementación excede la capacidad de un par de nodos, debe mover los conectores a clústeres de Expressway dedicados a cada servicio híbrido específico.
Ejemplo: Escala de host del conector con tres conectores coresidentes
La siguiente tabla muestra un ejemplo de escala y coresidencia. Proporciona el número máximo de usuarios por clúster, para cada servicio, con diferentes especificaciones del clúster host del conector. El clúster se comparte entre Hybrid Calendar (usando su Exchange local), llamada híbrida y servicio de mensajes híbrido.
|
Servicio |
Dos nodos pequeños |
Dos nodos medianos |
Dos nodos grandes |
|---|---|---|---|
|
Usuarios del servicio de calendario |
1,300 |
2,300 |
3,000 |
|
Usuarios del servicio de mensajes |
1,300 |
2,300 |
3,000 |
Introducción
Este tema trata sobre compartir un host de conector Expressway con otras soluciones basadas en Expressway. Cuando elige alojar conectores en una autopista que está utilizando para otros fines, se aplican las siguientes advertencias importantes:
-
No podemos admitir el modelo de escalabilidad que se aplica a un host de conector dedicado Expressway. Los números de usuario que obtenga al leer los otros temas de este artículo, o al usar la calculadora, no se aplican cuando el host del conector se comparte con otros servicios de Expressway.
-
Las combinaciones de servicios basados en Expresway y conectores de servicios híbridos descritos en este artículo, y los números de usuario asociados, son los únicos escenarios admitidos. No hemos probado otros escenarios y no puede esperar que funcionen en su entorno.
Servicio de calendario basado en ExpressWay con conector de llamadas y recorrido de servicio de llamadas
En este escenario, conectores de calendario híbrido de clúster de Expressway de dos nodos. El clúster también realiza el recorrido de llamadas para otras soluciones de llamadas de Cisco (señalización SIP y medios).
La tabla muestra los diferentes entornos de calendario que puede usar con el conector basado en ExpressWay. El conector de calendario basado en Expressway no es compatible con clústeres con más de dos nodos. Utilice el conector basado en la nube para una mayor escala con Office 365 (consulte Calendar Service Scale).
|
Servicio |
Clúster de dos nodos pequeños |
Clúster de dos nodos medianos |
Clúster de dos nodos grandes | |
|---|---|---|---|---|
|
Servicio de calendario |
Intercambio local |
500 usuarios |
1.000 usuarios |
1.000 usuarios |
|
Oficina 365 † |
500 usuarios |
1.000 usuarios |
1.000 usuarios | |
|
Exchange local y Office 365 (implementaciones de Exchange híbrido) |
Máximo 500 usuarios para ambos |
Máximo 1.000 usuarios para ambos |
Máximo 1.000 usuarios para ambos | |
|
Llame a Traversal |
200 sesiones de audio 100 sesiones de video |
200 sesiones de audio 100 sesiones de video |
1.000 sesiones de audio 500 sesiones de video | |
† Para evitar esta limitación de escala, le recomendamos que utilice el servicio de calendario basado en la nube en lugar del conector local. Para el calendario híbrido basado en Expressway, la limitación de la capacidad de usuarios de Office 365 a 1.000 por clúster es independiente del tamaño o número de nodos del clúster; esta limitación se deriva de la interacción con el servicio en la nube de Microsoft y no de la escala de la implementación de Expressway en las instalaciones.
Calendario con móvil y Remote Access
En este escenario, un clúster MRA de una o dos pequeñas máquinas virtuales Expressway alojan el conector de calendario. En este escenario se supone que el clúster solo se usa para MRA y los dos conectores. El clúster está limitado a uno o dos nodos pequeños.
|
Propósito de la autopista |
Grupo de un pequeño Expressway-C |
Grupo de dos Expressway-C pequeños |
|---|---|---|
|
Usuarios del servicio de calendario (conector local a Exchange) |
500 usuarios |
500 usuarios |
|
Móvil y Remote Access usuarios |
100 |
100 |
