Una vez haya publicado los servicios SIG, es recomendable supervisarlos, por ejemplo, visualizando las estadísticas de uso del servicio, entender los patrones de uso y tener una idea de cómo ajustar los recursos en función del tráfico que observe. A medida que cambian los patrones de tráfico y las demandas de usuario de sus servicios, puede responder en consecuencia de varias formas. Para satisfacer las expectativas de demanda y rendimiento, tenga en cuenta las siguientes formas de optimizar los recursos de servicio:
- Ajuste el modo de servicio para maximizar los recursos dedicados para un servicio.
- Escale manualmente los servicios especificando el número de pods que se asignarán para un servicio.
- Habilite el escalado automático especificando un umbral en el que se asignarán pods automáticamente para un servicio.
Cuando determine qué opción elegir, considere estos escenarios.
Tipo de escalados
Puede escalar los servicios manualmente, o bien automáticamente utilizando la entidad de escalado automático. En ambos casos, el método por el cual se escalan los servicios se caracteriza como escalado horizontal (hacia adentro o hacia afuera) o escalado vertical (hacia arriba y abajo). Los servicios se pueden escalar independientemente del modo en que estén configurados, independientemente de si son compartidos o dedicados.
- Escalado horizontal: agrega más pods a una implementación de servicio. Por ejemplo, escalar de un pod a muchos. Compatible con el escalado manual y automático.
- Escalado vertical: agrega CPU o memoria al conjunto actual de pods de una implementación. Compatible con escalado manual.
Si aumenta el número de pods disponibles para un servicio, el clúster de Kubernetes genera réplicas adicionales de los pods existentes en la implementación del servicio, incluida la configuración y las instancias del servicio en los pods.
El escalado también aumenta la disponibilidad y el rendimiento total de las instancias del servicio, así como la memoria y el consumo de CPU del servicio. Puesto que está escalando su infraestructura de Kubernetes, esta opción es tolerante a fallos: los pods que fallan se restauran automáticamente sin afectar al resto de pods. También permite el escalado independiente y aislado sin afectar a otros servicios ni a otros componentes del sistema.
Nota:
El clúster de Kubernetes en el que se implementa su organización presenta un número finito de nodos de equipo. Si escala muchos servicios SIG manual o automáticamente, es posible que su organización llegue al límite de recursos de equipo asignados a ArcGIS Enterprise en Kubernetes. Si esto sucede, trabaje con su administrador de TI para agregar más nodos a su clúster de Kubernetes. Considere la posibilidad de usar el escalado automático de clúster como solución para ello en su entorno.
Escalado horizontal
El escalado horizontal agrega más pods a una implementación de servicio. Por ejemplo, escalar de un pod a muchos. Se admite tanto para el escalado manual como para el escalado automático.
El ejemplo anterior ilustra el escalado horizontal para un servicio de geoprocesamiento que se ejecuta en modo dedicado. A medida que se necesitan más pods, la implementación del servicio se ajusta en consecuencia, ya sea manual o automáticamente. En este ejemplo, se agrega una réplica adicional de un pod a la implementación del servicio.
En el siguiente ejemplo, la implementación de un servicio de entidades compartido se escala horizontalmente agregando réplicas de pod a la implementación. En el conjunto inicial de recursos compartidos, hay tres servicios de entidades admitidos por cuatro pods. A medida que la demanda constante ha aumentado, los pods de la implementación de servicio han aumentado a ocho.
Escalado vertical
El escalado vertical agrega CPU o memoria al conjunto actual de pods en una implementación y se admite para el escalado manual.
El ejemplo anterior ilustra el escalado vertical para un servicio de imágenes que se ejecuta en modo dedicado. Dado que se requiere capacidad adicional, los pods o pods dedicadas se pueden ajustar en consecuencia, ya sea manual o automáticamente. En este caso, un aumento de los recursos —CPU, memoria o ambos— se asignan al pod.
En otro ejemplo, cuando un servicio de mapas en modo dedicado ya no requiere recursos adicionales, sus recursos se escalan verticalmente.
En el siguiente ejemplo, el escalado vertical se utiliza para una implementación de servicio de mapas compartido. Dado que se requiere CPU o memoria, los pods dedicadas se pueden ajustar en consecuencia. En este caso, se asignan mayores recursos de CPU o de memoria a los tres pods participantes.
Escenarios
Para cumplir las exigencias de rendimiento y, además, preservar los recursos utilizados por su organización, es importante comprender cuándo y cómo escalar los recursos disponibles para sus servicios. Los siguientes ejemplos son escenarios hipotéticos que los administradores de organizaciones deben tener en cuenta a la hora de escalar sus recursos:
- Un mapa web de una organización pública recibe de repente mucho tráfico y los usuarios están experimentando retrasos de rendimiento. El administrador de la organización consulta los registros del sistema y determina que un servicio de mapas que utiliza el mapa web está sobrecargado. Primero, es posible que cambie el modo de servicio para que deje de usar recursos compartidos y pase a usar recursos dedicados. A continuación, puede aumentar las réplicas de pod para la implementación de ese servicio. Al proporcionar recursos dedicados para el servicio de mapas, el administrador se asegura de que el elevado tráfico del servicio se gestione sin problemas de rendimiento.
- Una empresa de agrimensura ha acumulado cientos de servicios de entidades en su organización. Todos ellos están configurados para el modo compartido, de modo que hay una sola implementación de servicio que los respalde. Ningún servicio recibe un tráfico especialmente elevado, pero el uso general del contenido SIG de la organización está sobrecargando la implementación del servicio. El administrador de la organización decide escalar manualmente el servicio incrementando el número de réplicas de pods en la implementación del servicio. Al tener en marcha más instancias compartidas, el tráfico a los numerosos servicios de entidades de la organización se gestiona correctamente.
- Durante un proyecto de migración de contenido, la organización SIG de un gobierno municipal vuelve a publicar muchos mapas web y capas web en su organización. Debido a las restricciones de tiempo, desean completarlo rápidamente. Puesto que la publicación de los servicios subyacentes a los mapas y capas web la realiza el servicio de utilidades PublishingTools, los recursos de equipo disponibles para ese servicio de utilidades determinan la rapidez con la que puede realizarse la publicación. El administrador de la organización aumenta temporalmente las réplicas de pods en la implementación del servicio PublishingTools para mejorar la eficiencia de publicación durante el proyecto. Una vez completado el proyecto, disminuyen las réplicas de pods en la implementación del servicio para preservar los recursos del equipo.
Al revisar los dos primeros escenarios anteriores donde existe un servicio de mapas sobrecargado o el uso simultáneo de un gran número de servicios de entidades que dan como resultado un sistema sobrecargado, puede que la escala manual del servicio de mapas dedicado o las implementaciones del servicio de entidades compartido no sea el método más factible. La escala manual requiere una supervisión constante de la carga y comprender los patrones de carga para determinar el número de pods a los que se escala. Si una carga es intermitente e impredecible, la adición manual de un gran número de pods se traducirá en recursos perdidos cuando no haya mucha carga en el sistema. Por el contrario, usted desea que el sistema pueda escalar a medida que se requieran más pods para las cargas más pesadas.
Este puede ser un caso óptimo para que un administrador aproveche el escalado automático. El escalado automático permite mantener un número mínimo de pods y establecer un número máximo de pods a los que el sistema puede escalar en función de los umbrales de CPU establecidos. Este método ofrece detección automática para cuándo aumentar o disminuir pods como respuesta a cambios en la carga. Ello suprime la necesidad de supervisar constantemente un sistema y permite que el sistema conserve los recursos.
Ajustar el modo de servicio
Si un servicio de entidades o mapas que utiliza recursos compartidos está recibiendo tráfico constante, puede ajustar el modo de servicio para que utilice recursos dedicados. De esta forma, se abre un nuevo grupo de recursos de servicios dedicados para ese servicio.
Escalado manual
Cuando la demanda de servicios es predecible o constante, puede escalar manualmente una implementación de servicio especificando la cantidad de pods asignados a un servicio o aumentando los recursos (CPU/memoria) disponibles para el servicio. Esta opción resulta útil si la cantidad de recursos dedicados que atienden al servicio no es adecuada y los usuarios experimentan retrasos de rendimiento.
Si después de supervisar el servicio ve que la demanda ha aumentado o si se notifican problemas de rendimiento para el servicio, puede aumentar el número de pods según sea necesario. Puede disminuir el número de pods siempre y cuando la demanda comience a disminuir.
Escalado automático
Cuando la demanda de servicio es impredecible o intermitente, puede habilitar el escalado automático para maximizar la eficiencia en todos los recursos del sistema.
Cuando habilita el escalado automático en un servicio, las réplicas de pods de una implementación de servicio aumentarán o disminuirán automáticamente para satisfacer la demanda. La implementación del servicio utilizará sus criterios predefinidos, como CPU o memoria, para calcular la demanda de más o menos pods y se ajustará en consecuencia.
Rol de las instancias de servicio
Las implementaciones de servicios que no están alojadas, como mapas, imágenes, geoprocesamiento o geocodificación, contienen instancias de servicio que se ejecutan en cada pod de la implementación de un servicio. Estos representan la capacidad de cada pod y son los procesos subyacentes que se utilizan para procesar las solicitudes a cualquiera de estos servicios. Se admite el ajuste y el escalado de estos procesos; sin embargo, se recomienda ajustar y escalar a nivel pod para aprovechar las ventajas de Kubernetes (tolerancia de fallos, aislamiento, resiliencia, escalado automático, etc.).