Domande frequenti su Archiviazione BLOB di Azure

La piattaforma esegue i criteri di gestione del ciclo di vita una volta al giorno. Dopo aver configurato un criterio, possono essere necessarie fino a 24 ore prima che venga applicato. Una volta applicati i criteri, il tempo impiegato per l'esecuzione delle azioni può variare a seconda delle dimensioni dell'account di archiviazione e delle operazioni eseguite.

In caso di aggiornamento dei criteri, saranno richieste fino a 24 ore prima che diventino effettivi. Una volta applicati i criteri, il tempo necessario per l'esecuzione delle azioni varia a seconda delle dimensioni dell'account di archiviazione e delle operazioni eseguite. Se l'aggiornamento consiste nel disabilitare o eliminare una regola ed è stato usato enableAutoTierToHotFromCool, la suddivisione automatica in livelli al livello di accesso frequente verrà comunque eseguita. Ad esempio, imposta una regola che include enableAutoTierToHotFromFromCool in base all'ultimo accesso. Se la regola viene disabilitata o eliminata e si effettua l’accesso a un BLOB attualmente nel livello di accesso sporadico o saltuario, questo verrà spostato di nuovo al livello di accesso frequente applicato agli accessi fuori dalla gestione del ciclo di vita. Il BLOB non verrà quindi spostato da accesso frequente ad accesso sporadico o saltuario, dato che la regola di gestione del ciclo di vita è stata disabilitata o eliminata. L'unico modo per impedire autoTierToHotFromCool è disattivare il rilevamento dell'ora dell'ultimo accesso.

A seconda delle dimensioni e del numero di oggetti presenti in un account di archiviazione, potrebbero essere necessarie più esecuzioni per elaborare tutti gli oggetti. Puoi anche controllare i log delle risorse di archiviazione per verificare se le operazioni vengono eseguite dai criteri di gestione del ciclo di vita.

Verifica se le funzionalità di protezione dati, ad esempio l'eliminazione temporanea o il controllo delle versioni, sono abilitate nell'account di archiviazione. Anche se i criteri eliminano i BLOB, questi potrebbero essere ancora presenti in uno stato di eliminazione temporanea o come versione precedente, a seconda della configurazione di queste funzionalità.

Se sono applicati criteri di gestione del ciclo di vita per l'account di archiviazione, la riattivazione di un BLOB tramite modifica del suo livello può portare a uno scenario in cui i criteri del ciclo di vita spostano nuovamente il BLOB nel livello archivio. Ciò può verificarsi se l'ora dell'ultima modifica, l'ora di creazione o l'ora dell'ultimo accesso superano la soglia impostata per il criterio. Esistono tre modi per evitare che accada:

• Aggiungere la condizione daysAfterLastTierChangeGreaterThan all'azione tierToArchive del criterio. Questa condizione si applica solo all'ora dell'ultima modifica. Vedi Utilizzo dei criteri di gestione del ciclo di vita per archiviare i BLOB.

• Disabilita la regola che ha temporaneamente effetto su questo BLOB per impedire che venga archiviato di nuovo. Riabilita la regola quando il BLOB può essere spostato di nuovo al livello archivio.

• Se il BLOB deve rimanere sempre al livello di accesso frequente, accesso sporadico o accesso saltuario, copia il BLOB in un'altra posizione dove non sono attivi i criteri di gestione del ciclo di vita.

Il campo per la corrispondenza del prefisso BLOB di un criterio è un percorso BLOB completo o parziale, usato per trovare la corrispondenza con i BLOB a cui si vogliono applicare le azioni dei criteri. Il percorso deve iniziare con il nome del contenitore. Se non viene specificata alcuna corrispondenza di prefisso, i criteri verranno applicati a tutti i BLOB nell'account di archiviazione. Il formato della stringa di corrispondenza prefisso è [container name]/[blob name].
Ricorda i punti seguenti relativi alla stringa di corrispondenza prefisso:

• Una stringa di corrispondenza prefisso come container1/ si applica a tutti i BLOB nel contenitore denominato container1. Una stringa di corrispondenza prefisso di container1, senza il carattere barra finale (/), si applica a tutti i BLOB in tutti i contenitori il cui nome inizia con la stringa container1. Il prefisso corrisponderà ai contenitori denominati container11, container1234, container1abe così via.
• Una stringa di corrispondenza prefisso di container1/sub1/ si applica a tutti i BLOB che iniziano con la stringa sub1/ nel contenitore denominato container1. Ad esempio, il prefisso corrisponderà ai BLOB denominati container1/sub1/test.txt o container1/sub1/sub2/test.txt.
• L’asterisco * è un carattere valido nel nome di un BLOB. Se il carattere asterisco viene usato in un prefisso, questo corrisponderà ai BLOB con un asterisco nel nome. L'asterisco non funziona come carattere jolly.
• Il punto interrogativo ? è un carattere valido nel nome di un BLOB. Se il carattere punto interrogativo viene usato in un prefisso, questo corrisponderà ai BLOB con un punto interrogativo nel nome. Il punto interrogativo non funziona come carattere jolly.
• La corrispondenza prefisso considera solo confronti logici positivi (=). I confronti logici negativi (!=) vengono ignorati.
• La corrispondenza dei prefissi opera in modo con distinzione tra maiuscole e minuscole.

Sfortunatamente, non è possibile tenere traccia dell’ora in cui i criteri verranno eseguiti, perché si tratta di un processo di pianificazione in background. Tuttavia, la piattaforma eseguirà i criteri una volta al giorno.

La regola di inventario giornaliero è progettata per essere eseguita una volta al giorno. Inoltre, è prevista una regola di inventario settimanale ogni domenica.

Anche se ci impegniamo a offrire un'esperienza coerente, non è possibile garantire l’ora esatta di ogni esecuzione. L’ora di esecuzione della regola di inventario può variare. Ad esempio, se i criteri di oggi sono pianificati per le 12:05, il giorno dopo potrebbero iniziare alle 12:07, alle 12:15 o a qualsiasi altra ora.

Il report di inventario BLOB produce tre tipi di file. Vedi File di inventario. Gli attuali clienti che usano l'inventario BLOB potrebbero riscontrare un numero diverso di file di inventario, da uno a più file. Attualmente c’è già un file manifesto che fornisce l'elenco dei file. Questo comportamento rimane invariato, quindi questi file vengono elencati nel file manifesto.

La modifica è stata implementata per migliorare le prestazioni dell'inventario BLOB, in particolare per gli account di archiviazione di grandi dimensioni che contengono oltre cinque milioni di oggetti. Ora i risultati vengono scritti in parallelo su più file, eliminando il collo di bottiglia dell'uso di un singolo file di inventario. Questa modifica è nata dal feedback dei clienti, che hanno segnalato difficoltà nell'apertura e nell'uso di un singolo file di inventario di dimensioni eccessive.

Questa modifica ha un impatto positivo sull'esperienza degli utenti con le esecuzioni dell'inventario BLOB. Si prevede che migliori le prestazioni e riduca il tempo di esecuzione complessivo. Tuttavia, per trarre pienamente vantaggio da questo miglioramento, è necessario assicurarsi che il codice venga aggiornato per elaborare più file di risultati invece di uno solo. Questa regolazione allinea il tuo codice al nuovo approccio e ottimizza la gestione dei dati di inventario.

No, i dati esistenti non sono interessati. Solo i nuovi risultati dell'inventario BLOB hanno più file di inventario.

No, la modifica avverrà senza interruzioni.

Le azioni da intraprendere dipendono dalla modalità attuale di elaborazione dei risultati dell'inventario BLOB:

• Se l'elaborazione attuale presuppone un singolo file di risultati di inventario dovrai modificare il codice per ospitarne più di uno.

• Tuttavia, se l'elaborazione attuale comporta la lettura dell'elenco dei file dei risultati dal file manifesto, non è necessario apportare modifiche al modo in cui elabori i risultati. L'approccio esistente continua a funzionare senza problemi con la funzionalità aggiornata.

Non è consigliato, ma è possibile. Rivolgiti ai canali di assistenza per chiedere di disattivare questa funzionalità.

Rivolgiti al team degli account e ai canali di assistenza.

Questa modifica inizierà a essere implementata gradualmente a partire dal 1° settembre 2023.

No. Calcolo di Azure supporta le metriche relative ai dischi. Per altre informazioni, vedere Per disk metrics for Managed and Unmanaged Disks (Metriche per dischi gestiti e non gestiti).

Alcuni grafici delle metriche di Azure, ad esempio quelli che visualizzano dati di disponibilità e latenza, usano una linea tratteggiata per indicare che manca un valore (noto anche come valore Null) tra due punti dati di intervallo noti. Ad esempio, se nel selettore di tempo è stata selezionata la granularità temporale 1 minute, ma la metrica è stata segnalata alle 07:26, 07:27, 07:29 e 07:30, una linea tratteggiata connette 07:27 e 07:29 perché c’è un intervallo in minuti tra questi due punti dati. Una linea continua collega tutti gli altri punti dati. La linea tratteggiata prosegue fino a zero quando la metrica usa l'aggregazione count e sum. Per le aggregazioni media, minima o massima, una linea tratteggiata collega i due punti dati noti più vicini. Inoltre, quando mancano i dati sul lato all'estrema destra o sinistra del grafico, la linea tratteggiata si espande nella direzione dei punti dati mancanti.

È possibile configurare un avviso di integrità delle risorse in base al servizio Integrità risorse di Azure per tenere traccia della disponibilità dell'account di archiviazione. Se non sono presenti transazioni nell'account, l'avviso segnala l'integrità del cluster di archiviazione in cui si trova l'account di archiviazione.

I log di analisi includono record di tutte le operazioni di lettura, scrittura, elenco ed eliminazione con richieste riuscite e non riuscite per tutte le operazioni. I log di analisi sono a massimo sforzo e non è garantito alcun ordinamento.

Il feed di modifiche è una soluzione che fornisce un log delle transazioni di mutazioni o modifiche riuscite all'account, ad esempio la creazione, la modifica e le eliminazioni dei BLOB. Il feed di modifiche garantisce che tutti gli eventi vengano registrati e visualizzati secondo le modifiche riuscite per ogni BLOB, pertanto non è necessario escludere le voci non significative da un volume elevato di operazioni di lettura o richieste non riuscite. Il feed di modifiche è fondamentalmente progettato e ottimizzato per lo sviluppo di applicazioni che richiede determinate garanzie.

Puoi sfruttare entrambe le funzionalità poiché il feed di modifiche e gli eventi di archiviazione BLOB forniscono le stesse informazioni con la stessa garanzia di affidabilità del recapito; la differenza principale è data da latenza, ordinamento e archiviazione dei record di eventi. Il feed di modifiche pubblica i record nel log entro pochi minuti dalla modifica e garantisce anche l'ordine delle operazioni di modifica per BLOB. Gli eventi di archiviazione vengono sottoposti a push in tempo reale e potrebbero non essere ordinati. Gli eventi del feed di modifiche vengono archiviati in modo permanente all'interno dell'account di archiviazione come log stabili di sola lettura con la conservazione dei dati definita, mentre gli eventi di archiviazione sono temporanei e possono essere utilizzati dal gestore dell'evento, a meno che non vengano archiviati in modo esplicito. Con il feed di modifiche, qualsiasi numero di applicazioni può usare i log in modo pratico usando API o SDK BLOB.

Sì. Le regole di sicurezza di rete dell'account di archiviazione, inclusi i firewall basati su IP e della rete virtuale, sono supportate per l'endpoint del sito Web statico e possono essere usate per proteggere il sito Web.

No. Un sito Web statico supporta solo l'accesso in lettura pubblico anonimo per i file nel contenitore $web.

È possibile configurare un dominio personalizzato con un sito Web statico usando la rete per la distribuzione di contenuti di Azure (rete CDN di Azure). La rete CDN di Azure offre latenze basse coerenti per il sito Web in qualsiasi parte del mondo.

È possibile configurare un certificato SSL personalizzato con un sito Web statico usando la Rete di distribuzione dei contenuti di Microsoft Azure. La rete CDN di Azure offre latenze basse coerenti per il sito Web in qualsiasi parte del mondo.

È possibile configurare l'intestazione host per un sito Web statico usando Rete CDN di Azure - Verizon Premium. I feedback degli utenti possono essere inseriti qui.

Un errore 404 può verificarsi se fai riferimento a un nome di file usando maiuscole/minuscole non corrette. Ad esempio, Index.html anziché index.html. I nomi dei file e le estensioni nell'URL di un sito Web statico fanno distinzione tra maiuscole e minuscole anche se sono serviti tramite HTTP. Questo problema può verificarsi anche se non hai ancora effettuato il provisioning dell'endpoint della rete CDN di Azure. Aspetta 90 minuti dopo il provisioning di una nuova Rete CDN di Azure affinché la propagazione venga completata.

Nel portale di Azure aprire la pagina di configurazione del sito Web statico dell'account e individuare il nome e l'estensione impostati nel campo Nome del documento di indice. Assicurarsi che questo nome corrisponda esattamente al nome del file che si trova nel contenitore $web dell'account di archiviazione. I nomi dei file e le estensioni nell'URL di un sito Web statico fanno distinzione tra maiuscole e minuscole anche se sono serviti tramite HTTP.

No, se devi eseguire ricerche all'interno dei dati BLOB, usa l'accelerazione delle query o la ricerca di Azure.

I tag indice BLOB supportano solo i tipi di dati stringa e l'esecuzione di query restituisce i risultati in ordine lessicografico. Per i numeri, aggiungi uno zero prima. Per date e ore, archiviale come formato conforme a ISO 8601.

No, i tag di Resource Manager consentono di organizzare le risorse del piano di controllo, ad esempio sottoscrizioni, gruppi di risorse e account di archiviazione. I tag indice forniscono la gestione e l'individuazione dei BLOB nel piano dati.

La capacità di archiviazione è fatturata in unità della quantità media giornaliera di dati archiviati in gigabyte (GB) su un periodo mensile. Se, ad esempio, sono stati usati 10 GB di spazio di archiviazione nella prima metà del mese e nessuno nella seconda, verrà addebitato un utilizzo medio di 5 GB di spazio di archiviazione.

Passaggi successivi

Per altre informazioni su Archiviazione BLOB di Azure, visitare i seguenti collegamenti:

• Introduzione ad Archiviazione di Azure
• Che cos'è Archiviazione BLOB di Azure