Dominar la Asignación de Recursos en SAS Viya: Guía Experta de Contextos de Lanzador

En una arquitectura moderna basada en Kubernetes como SAS^© Viya^™, la gestión de recursos (CPU y RAM) ya no es estática. Se vuelve dinámica y granular. Una de las claves para optimizar los costos de infraestructura mientras se garantiza el rendimiento de los procesos críticos es salir del modelo "talla única" (one-size-fits-all).

Este artículo detalla la metodología para implementar una estrategia de contextos diferenciados (Pequeño, Mediano, Grande) utilizando los Contextos de Lanzador, una funcionalidad potente pero a menudo subexplotada de SAS^© Viya^™.

1. Fundamentos Técnicos: La Mecánica de Kubernetes

Para configurar correctamente SAS^© Viya^™, es imperativo comprender cómo el motor subyacente (Kubernetes) asigna los recursos a los pods (los contenedores que ejecutan sus sesiones de SAS^© Compute, Connect o Batch).

Cada pod se define por dos métricas distintas para la CPU y la Memoria. Comprender la distinción entre Request y Limit es crucial para evitar inestabilidades.

El concepto de "Request" (La Garantía)

La Request es la cantidad de recursos que Kubernetes reserva al iniciar el pod.

Función: Sirve para el scheduling (planificación). Kubernetes busca un nodo con al menos esta capacidad disponible.
Implicación: Si fija una request demasiado alta, sus pods permanecerán en estado "Pending" por falta de espacio, incluso si el pod no utiliza realmente esos recursos.

El concepto de "Limit" (El Límite)

La Limit es la barrera infranqueable impuesta al pod una vez que está en funcionamiento.

Comportamiento de la CPU: Si un proceso SAS^© intenta consumir más CPU de su límite, no se detiene, sino que se estrángula (CPU Throttling). El rendimiento disminuye, pero el procesamiento continúa.
Comportamiento de la Memoria (Peligro): Si un proceso excede su límite de RAM, el kernel de Linux interviene brutalmente a través del OOM Killer (Out of Memory Killer) y termina el proceso. La sesión SAS^© falla inmediatamente.

Nota de arquitectura: Cuando SAS^© Workload Orchestrator está activado (que es el caso por defecto), añade una capa de gestión adicional (colas, prioridades) por encima de estos mecanismos nativos de Kubernetes.

2. La Estrategia: Definir Perfiles de Servicio

En lugar de dejar a todos los usuarios con los límites predeterminados (a menudo conservadores, ej: 2 vCPU), el objetivo es crear perfiles adaptados a los usos:

Perfil	Tipo de Uso	Configuración Objetivo (Ejemplo)
Extra Pequeño	Desarrollo simple, exploración de tablas ligeras.	Límite de CPU: 1 / Límite de RAM: 1Gi
Estándar	Uso diario, Data Step clásico.	Límite de CPU: 2 / Límite de RAM: 4Gi
Grande	Procedimientos analíticos pesados (Model Studio), Procesos críticos por lotes.	Límite de CPU: 8 / Límite de RAM: 16Gi+

3. Implementación Técnica (Paso a Paso)

La configuración se realiza en dos etapas en SAS^© Environment Manager. Primero hay que eliminar las barreras globales antes de crear los contextos específicos.

Paso A: Desbloquear los Límites Globales (`sas^©.launcher.max`)

Por seguridad, SAS^© Viya^™ impone límites máximos globales. No puede crear un contexto "Grande" (ej: 8 CPU) si el límite global está fijado en 2 CPU.

Acceda a SAS^© Environment Manager > Configuración.
Busque el servicio Launcher service.
Edite la instancia de configuración sas^©.launcher.max.

Como se ilustra en las capturas de configuración, debe aumentar el valor cpu.limit.

Acción: Cambie cpu.limit del valor predeterminado (a menudo 2) a un valor superior (ej: 8 o más, según sus nodos físicos).
Consejo: No modifique las cpu.request globales si no tiene problemas de colocación de pods. Manténgalas bajas (ej: 100m) para facilitar el inicio de los pods.

Paso B: Crear el Contexto de Lanzador "Grande"

Una vez que se ha aumentado el límite global, puede crear el contexto específico.

Vaya a Contextos > Vista Contextos de Lanzador.
Abra la pestaña Avanzado.

Es aquí donde anula los valores predeterminados.

Límite de CPU: Ingrese 8 (para 8 vCPU).
Límite de Memoria: Puede dejarlo en blanco (para usar el valor predeterminado) o aumentar el valor (ej: 8Gi).
Requests: A menudo es aconsejable dejar los campos "Request" vacíos o con valores bajos (ej: 50m para la CPU, 300M para la RAM) para asegurar que el pod pueda iniciarse fácilmente en el clúster, incluso si luego consume más (hasta el límite) (mecanismo de burst).

Importante: Cualquier valor dejado en blanco en esta pantalla heredará los valores definidos en sas^©.launcher.default.

4. La Experiencia del Usuario Final

Una vez creados estos Contextos de Lanzador (ej: Extra Pequeño, Pequeño, Grande), no son directamente visibles para el usuario final. Debe asociarlos con Contextos de Cómputo.

Al seleccionar "Grande", su sesión será instanciada por el Contexto de Lanzador configurado con 8 CPU.

Esto empodera a los usuarios: pueden usar un contexto "Estándar" económico para codificar, y cambiar a un contexto "Grande" solo para ejecutar el procesamiento final.