Consideraciones sobre el planeamiento de capacidad

El planeamiento básico de la capacidad comienza con algunos cálculos sencillos, pero hay factores que pueden complicar el proceso. Además de los números de uso actuales y previstos simples, también debe tener en cuenta las consideraciones siguientes:

• Límites y cuotas de servicio
• Limitaciones de costos
• Ineficacias de código y configuración
• Dependencias

En esta unidad, verá cómo estas consideraciones pueden afectar al planeamiento de la capacidad y cómo abordar cada una de ellas.

Límites y cuotas de servicio

Existe una tendencia a ver la informática en la nube como un recurso ilimitado. En comparación con los modelos tradicionales de servidor o centro de datos, la capacidad de la nube parece ser infinita. La nube ofrece un nuevo nivel de escala. Sin embargo, al igual que todo lo demás, tiene algunos límites. El planeamiento de la capacidad implica comprender cuándo alcanzará esos límites de servicio.

Al examinar el sistema y su arquitectura, debe comprender los límites de los servicios en la nube que usa. Por ejemplo, de forma predeterminada, puede tener un máximo de 200 máquinas virtuales por conjunto de disponibilidad de máquinas virtuales en Azure. Este límite puede parecer más que suficientes máquinas virtuales si acaba de empezar. Sin embargo, cuando alcanza ese límite, no puede aprovisionar más máquinas virtuales, lo que podría provocar una interrupción.

Del mismo modo, de forma predeterminada, puede tener 250 cuentas de almacenamiento por suscripción, por región. Estos límites son ejemplos de límites flexibles que se pueden aumentar. Pero algunos servicios tienen límites máximos, que puede encontrar en el siguiente vínculo.

Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure

Estos límites y cuotas son algo que debe tener en cuenta y supervisar. Echemos un vistazo a las formas de hacerlo.

Portal de Azure

Puede ver las cuotas de servicio y dónde está en relación con esos límites en la sección Uso y cuotas en Suscripciones:> configuración en el panel de navegación. Puede filtrar por categoría de servicio, como la red o el proceso, y la región de Azure. Muestra dónde se encuentra frente a los límites.

Mediante código

Puede usar el Usage - List punto de conexión de cualquier servicio de Azure para obtener la información de uso de recursos actual y los límites de los recursos de proceso en la suscripción, como se muestra en este ejemplo truncado.

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{ 
    "currentValue": 124,
    "/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
    "limit": 1000, 
    "name": { 
        "localizedValue": "Virtual Networks",
        "value": "VirtualNetworks" 
    }, 
    "unit": "Count" 
}

Puede ver que el número actual de redes virtuales de Azure que se usa es 124 en un límite de 1000. El aumento de un límite requiere una solicitud de soporte técnico, por lo que debe asegurarse de que sabe con antelación cuándo podría acercarse al umbral.

Limitaciones de costos

El escalado no consiste solo en iniciar más recursos en el problema. Es importante que su organización comprenda el costo de su entorno de nube y que agregar más recursos generalmente es igual a más costo. Tenga en cuenta este costo y trabaje con sus equipos financieros para asegurarse de que está de acuerdo con el gasto en la nube actual y proyectado.

Debe prever el costo tanto al diseñar inicialmente los sistemas como al realizar revisiones periódicas de los sistemas que ya están en ejecución. Azure ofrece herramientas que pueden ayudarle a:

• Planee el costo de un entorno mediante la calculadora de Azure.
• Revise el gasto mensual actual y previsto en Azure Portal.
• Configurar presupuestos en Microsoft Cost Management. Esta herramienta puede permitirle examinar los costos en distintos ámbitos, incluidos el grupo de administración, el grupo de recursos y la suscripción.

Ineficacias de código y configuración

A veces, dirigir más recursos puede resolver un problema, pero eso cuesta dinero. A veces, el escalado no es la solución o no es la solución completa. En algunos casos, puede ser que lo que parece ser una necesidad de escalado es realmente un problema causado por una codificación incorrecta o configuración.

Puede ahorrar dinero y tiempo buscando primero los errores antes de escalar horizontalmente los recursos. Algunos ejemplos de este enfoque son:

• Si tiene una base de datos mal diseñada con particiones activas, como usar solo una partición en una base de datos noSQL enorme, es lenta independientemente de cuánto escale.
• Si tiene consultas de base de datos ineficaces, haga que sean más eficaces antes de iniciar más recursos en la base de datos. A veces, simplemente agregar el índice correcto a una base de datos basada en consultas comunes puede reducir los costos de 100 veces.
• Si los tiempos de espera se establecen incorrectamente, las conexiones de base de datos pueden saturarse debido a reintentos de tiempos de espera incoherentes entre el servidor y la base de datos. En ese caso, debe corregir la configuración antes de escalar la base de datos.
• Si el código del desarrollador es ineficaz, ¿puede escribir código más eficaz para solucionar el problema? Quizás el código no libere memoria cuando pudiera, por lo que ha estado usando máquinas virtuales de memoria más grandes cuando no es necesario. Correcciones como las que pueden proporcionar ahorros de costos significativos.

Dependencias

Los cambios necesarios para solucionar algunos de los problemas descritos en este módulo suelen tener dependencias en los desarrolladores de la aplicación. Algunas de las soluciones y los procedimientos recomendados aquí, requieren la colaboración entre usted y aquellos desarrolladores para que esto suceda.

Es posible que no pueda implementar todas estas recomendaciones por su cuenta. Sin embargo, si comprende el sistema en la nube y sus funcionalidades y características, puede convertirse en un impulsor para mejorar los sistemas y su escalabilidad y confiabilidad.