Scalabilità automatica per l'API di Azure per FHIR

L'API di Azure per FHIR, come servizio gestito, consente ai clienti di mantenere i dati sanitari conformi a Fast Healthcare Interoperability Resources (FHIR®) e di scambiarli in modo sicuro tramite l'API del servizio. Per supportare carichi di lavoro delle transazioni diversi, i clienti possono usare la scalabilità manuale o la scalabilità automatica.

L'API di Azure per FHIR offre funzionalità di ridimensionamento a livello di database e calcolo.

Scalabilità automatica a livello di database

Per impostazione predefinita, l'API di Azure per FHIR è impostata su manuale per il ridimensionamento del database. Questa opzione funziona bene quando i carichi di lavoro delle transazioni sono noti e coerenti. I clienti possono modificare la velocità effettiva RU/s tramite il portale fino a 100.000 e inviare una richiesta per aumentare il limite.

La funzionalità di scalabilità automatica è progettata per ridimensionare le risorse di Azure, inclusa la velocità effettiva del database automaticamente in base ai carichi di lavoro, eliminando i possibili colli di bottiglia nel livello dati.

Consente di comprendere come abilitare la scalabilità automatica a livello di database con le sezioni successive

Linee guida per abilitare la scalabilità automatica

In generale, i clienti devono prendere in considerazione la scalabilità automatica quando i carichi di lavoro variano in modo significativo e sono imprevedibili.

Per abilitare la funzionalità di scalabilità automatica, il cliente deve creare un ticket di supporto monouso per richiederlo tramite portale di Azure. Il team di supporto microsoft abilita la funzionalità di scalabilità automatica in base alla priorità di supporto.

Nota

La funzionalità di scalabilità automatica non è disponibile nel portale di Azure.

Scalabilità automatica per UR/sec

Quando la scalabilità automatica è abilitata, il sistema calcola e imposta il valore iniziale Tmax . La scalabilità è disciplinata dal valore massimo di velocità effettiva, o Tmaxe viene ridimensionata tra 0.1 *Tmax (o il 10% Tmax) e Tmax RU/s.RU/s Aumenta Tmax automaticamente man mano che le dimensioni totali dei dati aumentano. Per garantire la massima scalabilità, il Tmax valore deve essere mantenuto così come è. Tuttavia, i clienti possono richiedere che il valore venga modificato in un valore compreso tra il 10% e il 100% del Tmax valore.

È possibile aumentare il valore massimo RU/s o Tmax e passare al livello massimo supportato dal servizio. Quando il servizio è occupato, la velocità effettiva RU/s viene ridimensionata fino al Tmax valore . Quando il servizio è inattivo, la velocità effettiva RU/s viene ridotta al 10% Tmax del valore.

È anche possibile ridurre il valore massimo RU/s o Tmax . Quando si riduce il valore massimo RU/s, il valore minimo su cui è possibile impostare è : MAX (4000, highest max RU/s ever provisioned / 10, current storage in GB * 400), arrotondato al più vicino 1000 RU/s.

• Esempio 1: sono presenti dati da 1 GB e il provisioning RU/s massimo è 10.000. Il valore minimo è Max (4000, 10.000/10, 1x400) = 4000. Viene utilizzato il primo numero 4000.
• Esempio 2: si dispone di dati da 20 GB e il provisioning RU/s massimo è 100.000. Il valore minimo è Max (4000, 100.000/10, 20x400) = 10.000. Viene usato il secondo numero, 100.000/10 =10.000.
• Esempio 3: sono presenti dati da 80 GB e il numero massimo di UR/sec con provisioning è 300.000. Il valore minimo è Max (4000, 300.000/10, 80x400) = 32.000. Viene usato il terzo numero, 80x400=32.000.

È possibile modificare il valore massimo RU/s o Tmax tramite il portale se è un numero valido e non è maggiore di 100.000 RU/s. È possibile creare un ticket di supporto per richiedere Tmax un valore maggiore di 100.000.

Nota

Con l'aumentare dell'archiviazione dei dati, il sistema aumenterà automaticamente la velocità effettiva massima fino al numero massimo di UR/sec successivo in grado di supportare tale livello di archiviazione.

Scalabilità automatica a livello di calcolo

I criteri di scalabilità automatica definiti per il livello di calcolo del servizio FHIR sono:

• Trigger di ridimensionamento

Trigger di ridimensionamento descrive quando verrà eseguita la scalabilità del servizio. Le condizioni definite nel trigger vengono controllate periodicamente per determinare se un servizio deve essere ridimensionato. Tutti i trigger attualmente supportati sono Average CPU, Max Worker Thread, Average LogWrite, Average Data I/O.

• Meccanismo di ridimensionamento

Il meccanismo di ridimensionamento viene applicato se il controllo del trigger determina che il ridimensionamento è necessario. Inoltre, il trigger di ridimensionamento non verrà valutato di nuovo fino alla scadenza dell'intervallo di ridimensionamento, impostato su un minuto per l'API di Azure per FHIR.

Per garantire il miglior risultato possibile, è consigliabile che i clienti aumentino gradualmente la frequenza delle richieste in modo che corrisponda alla velocità di push prevista, anziché eseguire il push di tutte le richieste contemporaneamente.

Domande frequenti

Come stimare le UR/sec di velocità effettiva necessarie?

Le dimensioni dei dati sono uno dei diversi fattori usati per calcolare le UR/sec di velocità effettiva totali necessarie per la scalabilità manuale e la scalabilità automatica. È possibile trovare le dimensioni dei dati usando l'opzione di menu Metriche in Monitoraggio. Avviare un nuovo grafico e selezionare Dimensioni raccolta Cosmos DB nella casella a discesa Metrica e Max nella casella "Aggregazione".

Dovrebbe essere possibile visualizzare le dimensioni massime della raccolta dati nel periodo di tempo selezionato. Se necessario, modificare l'intervallo di tempo, ad esempio da "Ultimi 30 minuti" a "Ultime 48 ore".

Usare la formula per calcolare le UR/sec necessarie.

• Scalabilità manuale: archiviazione in GB * 40
• Scalabilità automatica: archiviazione in GB * 400

Tenere presente che si tratta solo di una stima basata sulle dimensioni dei dati e che esistono altri fattori che influiscono sulle UR/sec necessarie.

È stata abilitata la scalabilità automatica come è possibile eseguire la migrazione al ridimensionamento manualmente?

È necessario un ticket di supporto per modificare la scalabilità automatica su scalabilità manuale e specificare le UR/sec di velocità effettiva. Il valore minimo per la scalabilità manuale su cui è possibile impostarlo è : MAX (400, highest max RU/s ever provisioned / 100, current storage in GB * 40), arrotondato al più vicino 1000 RU/s. I numeri usati qui sono diversi da quelli usati nella scalabilità automatica.

Una volta completata la modifica, le nuove tariffe di fatturazione sono basate sulla scalabilità manuale.

Qual è l'impatto sui costi della scalabilità automatica?

La funzionalità di scalabilità automatica comporta costi a causa della gestione automatica delle unità elaborate di cui è stato effettuato il provisioning. I costi effettivi dipendono dall'utilizzo orario, ma tenere presente che sono previsti costi minimi del 10% per Tmax le UR/sec di velocità effettiva riservate. Tuttavia, questo aumento dei costi non si applica ai costi di archiviazione e runtime. Per informazioni sui prezzi, vedere Prezzi dell'API di Azure per FHIR.

Passaggi successivi

In questo documento è stata illustrata la funzionalità di scalabilità automatica per l'API di Azure per FHIR. Per una panoramica dell'API di Azure per FHIR, vedere

Informazioni sull'API di Azure per FHIR

FHIR® è un marchio registrato di HL7 e viene usato con l'autorizzazione di HL7.