Considerazioni sulla pianificazione della capacità
La pianificazione della capacità di base inizia con alcuni semplici calcoli, ma alcuni fattori possono complicare il processo. Oltre ai semplici valori relativi all'utilizzo corrente e stimato, è necessario includere anche le considerazioni seguenti:
- Limiti e quote di servizio
- Limitazioni dei costi
- Inefficienze di codice e configurazione
- Dipendenze
In questa unità viene illustrato l'effetto di queste considerazioni sulla pianificazione della capacità e verrà spiegato come gestirli.
Limiti e quote di servizio
Si tende a considerare il cloud computing come una risorsa illimitata. Rispetto ai modelli tradizionali basati su server/data center la capacità del cloud sembra essere infinita. Il cloud offre un livello di scalabilità completamente nuovo. Tuttavia, come qualsiasi altro modello, presenta alcuni limiti. Per pianificare la capacità è necessario sapere quando si stanno per raggiungere tali limiti di servizio.
Quando si esaminano il sistema e la relativa architettura, è necessario conoscere i limiti previsti per i servizi cloud in uso. Per impostazione predefinita, ad esempio, è possibile avere un massimo di 200 macchine virtuali per ogni set di disponibilità di VM in Azure. Questo limite può sembrare più che sufficiente se si è appena iniziato. Tuttavia, quando si raggiunge questo limite, non sarà possibile effettuare il provisioning di altre macchine virtuali, il che potrebbe causare un'interruzione del servizio.
Analogamente, per impostazione predefinita è possibile avere 250 account di archiviazione per ogni sottoscrizione e per ogni area. Questi sono entrambi esempi di limiti flessibili che è possibile incrementare. Alcuni servizi prevedono, però, limiti massimi, come descritto nell'articolo seguente.
Sottoscrizione di Azure e limiti, quote e vincoli dei servizi
Questi limiti e quote sono qualcosa di cui tenere conto e monitorare. Esaminiamo ora alcuni modi per farlo.
Azure portal
È possibile visualizzare le quote del servizio e il livello di utilizzo raggiunto in relazione a tali limiti nella sezione Utilizzo e quote in Sottoscrizioni -> Impostazioni nel riquadro di spostamento. È possibile filtrare in base a una categoria di servizi, ad esempio rete/calcolo, oltre che all'area di Azure. Verrà visualizzato il livello raggiunto in relazione ai limiti.
Tramite codice
È possibile usare l'endpoint Usage - List per qualsiasi servizio di Azure per recuperare le informazioni correnti sull'utilizzo delle risorse e i limiti relativi alle risorse di calcolo nella sottoscrizione, come illustrato in questo esempio troncato.
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"
}
È possibile notare che il numero corrente di reti virtuali di Azure usato è 124 rispetto a un limite di 1000. Per aumentare il limite, è necessario inviare una richiesta di supporto. È quindi opportuno sapere quanto prima quando si ci avvicina alla soglia.
Limitazioni dei costi
La scalabilità non implica solo un aumento delle risorse per far fronte al problema. È importante che l'organizzazione sia consapevole dei costi dell'ambiente cloud e sappia che l'aggiunta di risorse implica in genere un incremento dei costi. Tenere in considerazione questo costo e collaborare con i team finanziari per concordare la spesa per il cloud corrente e prevista.
È opportuno prevedere i costi sia durante la progettazione iniziale dei sistemi sia quando si eseguono revisioni a intervalli regolari dei sistemi già in esecuzione. Azure offre strumenti che consentono di:
- Pianificare il costo di un ambiente usando il calcolatore di Azure.
- Esaminare la spesa mensile corrente e prevista nel portale di Azure.
- Configurare i budget in Gestione costi di Microsoft. Questo strumento consente di esaminare i costi in ambiti diversi, tra cui gruppo di gestione, gruppo di risorse e sottoscrizione.
Inefficienze di codice e configurazione
In alcuni casi, l'indirizzamento di più risorse può risolvere un problema, ma avrà un costo economico. A volte la scalabilità non consente o consente di risolvere solo parzialmente il problema. In alcuni casi, una situazione che sembra richiedere un aumento delle risorse è in realtà un problema causato da codice o da una configurazione non corretta.
Prima di aumentare le risorse, è possibile provare a verificare la presenza di bug per risparmiare tempo e denaro. Gli esempi di questo approccio includono:
- Un database non progettato correttamente con partizioni a caldo, che ad esempio usa una sola partizione in un database noSQL di grandi dimensioni, risulterà lento anche se si aumenta considerevolmente il numero delle risorse.
- Se si hanno query inefficienti sul database, migliorarne le prestazioni prima di aumentare il numero di risorse a livello di database. In alcuni casi basta aggiungere il giusto indice a un database sulla base di query comuni per ridurre di 100 volte i costi.
- Se i timeout non sono impostati correttamente e le connessioni di database si stanno saturando in seguito ai tentativi ripetuti causati da timeout incoerenti tra server e database, è necessario correggere le impostazioni prima di aumentare le risorse per il database.
- Se il codice dello sviluppatore è inefficiente, è possibile scrivere codice più efficiente per risolvere il problema? È probabile che il codice non liberi la memoria quando potrebbe, di conseguenza si stanno usando macchine virtuali con una quantità di memoria superiore al necessario. Correzioni di questo tipo possono tradursi in un notevole risparmio sui costi.
Dipendenze
Le modifiche necessarie per risolvere alcuni dei problemi descritti in questo modulo dipendono spesso dagli sviluppatori dell'applicazione. Per implementare alcune soluzioni e procedure consigliate illustrate in questo articolo, è richiesta la collaborazione con gli sviluppatori.
Si potrebbe non essere in grado di implementare tutte queste raccomandazioni interamente da soli. Tuttavia, con una buona comprensione del sistema cloud e delle relative caratteristiche e funzionalità, è possibile diventare un fautore del cambiamento migliorando i sistemi e la loro scalabilità e affidabilità.