Configuration Manager le dimensioni del sito e le linee guida sulle prestazioni
Si applica a: Configuration Manager (Current Branch)
Configuration Manager leader del settore in scala e prestazioni. Un'altra documentazione illustra i limiti massimi di scalabilità supportati e le linee guida hardware per l'esecuzione di siti con dimensioni di ambiente maggiori. Questo articolo fornisce indicazioni aggiuntive sulle prestazioni per ambienti di tutte le dimensioni. Queste indicazioni consentono di stimare in modo più accurato l'hardware necessario per distribuire Configuration Manager.
Questo articolo è incentrato sul maggiore collaboratore ai colli di bottiglia delle prestazioni Configuration Manager: il sottosistema di input/output del disco o le operazioni di I/O al secondo.
- Presenta i dettagli e i risultati dei test incentrati sulle operazioni di I/O al secondo
- Illustra come riprodurre i test con ambienti e hardware personalizzati
- Suggerisce i requisiti di operazioni di I/O al secondo del disco per ambienti di varie dimensioni
Metodologia di test delle prestazioni
È possibile distribuire Configuration Manager in molti modi univoci, ma è importante comprendere alcune variabili nelle discussioni di ridimensionamento. Una variabile è l'intervallo di funzionalità, ad esempio un ciclo di inventario. Un'altra variabile è il numero di utenti, distribuzioni software o altri oggetti a cui il sistema fa riferimento o distribuisce. Il test delle prestazioni applica queste variabili come parte di un carico. Il carico genera oggetti a una frequenza tipica per i clienti aziendali che usano distribuzioni di produzione in ambienti di dimensioni diverse.
Nota
I dati di utilizzo dei clienti consentono di testare le build current branch con gli scenari, le configurazioni e le impostazioni più comuni per la maggior parte dei clienti. Le raccomandazioni contenute in questo articolo si basano su queste medie. Le esperienze possono variare in base alle dimensioni e alla configurazione dell'ambiente. In generale, Configuration Manager richiede il buon senso quando si tratta di oggetti e intervalli. Solo perché è possibile raccogliere ogni file in un sistema o impostare l'intervallo per un ciclo su un minuto, non significa che si dovrebbe.
Le sezioni seguenti illustrano alcune impostazioni e configurazioni chiave da usare quando si testano e modellano le esigenze di elaborazione per le grandi aziende. Queste linee guida consentono di definire le aspettative di base per le prestazioni del sistema per le dimensioni dell'hardware suggerite.
Impostazioni degli intervalli di funzionalità
La maggior parte dei test deve usare gli intervalli predefiniti per i cicli chiave nel sistema. Ad esempio, i test dell'inventario hardware si verificano una volta alla settimana con un file con estensione mof più grande del predefinito. Alcuni intervalli di funzionalità ricorrenti, in particolare i cicli di inventario hardware e software, possono avere effetti significativi sulle caratteristiche delle prestazioni di un ambiente. Gli ambienti che consentono intervalli predefiniti aggressivi per la raccolta dei dati necessitano di hardware sovradimensionato in proporzione all'aumento dell'attività. Ad esempio, si supponga di avere 25.000 client desktop e di voler raccogliere l'inventario hardware due volte più velocemente rispetto all'intervallo predefinito. Per iniziare, ridimensionare l'hardware del sito come se si avessero 50.000 client.
Oggetti
I test devono usare la media superiore degli oggetti che le grandi aziende tendono a usare con il sistema. I valori tipici sono migliaia di raccolte e applicazioni, distribuite a centinaia di migliaia di utenti o sistemi. I test devono essere eseguiti contemporaneamente su tutti gli oggetti nel sistema in base a questi limiti. Molti clienti usano diverse funzionalità, ma in genere non usano tutte le funzionalità del prodotto a questi limiti massimi. Il test con tutte le funzionalità del prodotto consente di garantire le migliori prestazioni a livello di sistema e consente un buffer per le funzionalità che alcuni clienti possono usare al di sopra della media.
Carichi
I test devono essere eseguiti anche su carichi giornalieri superiori alla media standard, eseguendo simulazioni che generano picchi di utilizzo nel sistema. Un esempio è la simulazione delle implementazioni di Patch Tuesday, per assicurarsi che il sistema possa restituire tempestivamente i dati di conformità degli aggiornamenti durante questi giorni di attività di picco. Un altro esempio è la simulazione dell'attività del sito durante un'epidemia di malware diffusa, per garantire che siano possibili notifiche e risposte tempestive. Anche se i computer distribuiti con le dimensioni consigliate possono essere sottoutilizzabili in un determinato giorno, le situazioni più estreme richiedono un buffer di elaborazione.
Configurazioni
Eseguire test su una gamma di hardware fisico, Hyper-V e Azure, con una combinazione di sistemi operativi supportati e versioni di SQL Server. Convalidare sempre i casi peggiori per la configurazione supportata. In generale, Hyper-V e Azure restituiscono risultati di prestazioni confrontabili all'hardware fisico equivalente se configurati in modo analogo. I sistemi operativi server correnti tendono ad avere prestazioni uguali o migliori rispetto alle versioni precedenti del sistema operativo. Anche se tutte le piattaforme supportate soddisfano i requisiti minimi, in genere le versioni più recenti di prodotti di supporto come Windows e SQL Server producono prestazioni ancora migliori.
La variante più grande proviene dalle versioni SQL Server in uso. Per altre informazioni sulle versioni SQL Server, vedere Quale versione di SQL Server è consigliabile eseguire?.
Determinanti delle prestazioni principali
È possibile testare e misurare le prestazioni Configuration Manager con diversi tipi di impostazioni, in modi diversi e in diverse dimensioni del sito. Le impostazioni e gli oggetti seguenti possono influire notevolmente sulle prestazioni. Assicurarsi di considerarli durante il test e la modellazione delle prestazioni nell'ambiente.
Attenzione
Mentre alcuni aspetti di Configuration Manager hanno valori massimi ufficiali o limiti dell'interfaccia utente che impediscono un utilizzo eccessivo, andare oltre le linee guida può avere effetti negativi significativi sulle prestazioni di un sito. Il superamento dei livelli consigliati o l'esclusione delle linee guida per il ridimensionamento richiede in genere hardware più grande e può rendere l'ambiente non gestibile fino a ridurre la frequenza o il numero di vari oggetti.
Inventario hardware
Per testare le prestazioni di base, impostare la raccolta dell'inventario hardware su una volta alla settimana, con le dimensioni predefinite del file con estensione mof più circa il 20% di altre proprietà. Non abilitare tutte le proprietà e raccogliere solo le proprietà effettivamente necessarie. Prestare particolare attenzione durante la raccolta di proprietà, ad esempio la memoria virtuale disponibile, che cambierà sempre con ogni ciclo di inventario. La raccolta di queste proprietà può causare una varianza eccessiva in ogni ciclo di inventario da ogni client.
Inventario software
Per testare le prestazioni di base, impostare la raccolta dell'inventario software su una volta alla settimana, con solo i dettagli del prodotto . La raccolta di molti file può mettere a dura prova il sottosistema di inventario. Evitare di specificare filtri che potrebbero finire per raccogliere migliaia di file in molti client, ad *.exe esempio o *.dll.
Raccolte
I test delle prestazioni di base possono includere diverse migliaia di raccolte con diversi tipi di ambito, dimensioni, complessità e impostazioni di aggiornamento. Le prestazioni del sito non sono una funzione diretta del numero elevato di raccolte in un sito. Le prestazioni sono anche un prodotto incrociato della complessità delle query delle raccolte, degli aggiornamenti completi e incrementali e della frequenza delle modifiche, delle dipendenze tra le raccolte e del numero di client nelle raccolte.
Laddove possibile, ridurre al minimo le raccolte con query sulle regole dinamiche costose o complesse. Per le raccolte che richiedono questi tipi di regole, impostare intervalli di aggiornamento appropriati e tempi di aggiornamento per ridurre al minimo l'effetto della rivalutazione della raccolta nel sistema. Ad esempio, eseguire l'aggiornamento a mezzanotte anziché alle 8:00.
L'abilitazione di aggiornamenti incrementali nelle raccolte garantisce aggiornamenti rapidi e tempestivi per l'appartenenza alla raccolta. Ma anche se gli aggiornamenti incrementali sono efficienti, continuano a caricare il sistema. Bilanciare la frequenza di modifica prevista con la necessità di aggiornamenti quasi in tempo reale sull'appartenenza. Ad esempio, si supponga di aspettarsi una varianza elevata nei membri della raccolta, ma che non siano necessari aggiornamenti quasi in tempo reale dell'appartenenza. È più efficiente e produce meno carico sul sistema per aggiornare la raccolta con un aggiornamento completo pianificato a un certo intervallo, piuttosto che abilitare gli aggiornamenti incrementali.
Quando si abilitano gli aggiornamenti incrementali, ridurre tutti gli aggiornamenti completi pianificati nelle stesse raccolte. Si tratta solo di un metodo di backup di valutazione, poiché gli aggiornamenti incrementali devono mantenere l'appartenenza alla raccolta aggiornata quasi in tempo reale. Le procedure consigliate per le raccolte consigliano un numero massimo di raccolte totali per gli aggiornamenti incrementali, ma, come indicato nell'articolo, l'esperienza può variare in base a molti fattori.
Le raccolte con solo regole di appartenenza diretta e con una raccolta di limitazione che non esegue aggiornamenti incrementali non richiedono aggiornamenti completi pianificati. Disabilitare le pianificazioni di aggiornamento per questi tipi di raccolte per impedire il caricamento non necessario nel sistema. Se la raccolta di limitazione usa aggiornamenti incrementali, le raccolte con solo regole di appartenenza diretta potrebbero non riflettere gli aggiornamenti dell'appartenenza per un massimo di 24 ore o fino a quando non viene eseguito un aggiornamento pianificato.
Anche se non è una procedura consigliata, alcune organizzazioni creano centinaia o addirittura migliaia di raccolte come parte di vari processi aziendali. Se si usa l'automazione per creare raccolte, è importante abilitare correttamente gli aggiornamenti incrementali necessari. Ridurre al minimo e distribuire eventuali pianificazioni di aggiornamento complete per evitare punti critici della valutazione della raccolta durante un singolo periodo di tempo. Stabilire un normale processo di pulitura per eliminare le raccolte inutilizzate, soprattutto se si creano automaticamente raccolte che non sono più necessarie dopo un certo periodo di tempo.
Tenere presente che Configuration Manager crea criteri per tutti gli oggetti nelle raccolte quando si assegnano ad attività come le distribuzioni. Le modifiche all'appartenenza, tramite aggiornamenti pianificati o incrementali, possono creare molto più lavoro per l'intero sistema. Le build current branch più recenti hanno ottimizzazioni speciali dei criteri per le raccolte Tutti i sistemi e Tutti gli utenti. Quando si ha come destinazione l'intera organizzazione, usare le raccolte predefinite anziché un clone di queste raccolte predefinite.
Per analizzare ulteriormente le prestazioni della raccolta, visualizzare la valutazione della raccolta nella console. Per altre informazioni, vedere Come visualizzare la valutazione della raccolta.
Metodi di individuazione
Per i test delle prestazioni di base, eseguire metodi di individuazione basati su server una volta alla settimana, abilitando l'individuazione differenziale in base alle esigenze per mantenere aggiornati i dati durante la settimana. I test devono individuare una quantità di oggetti proporzionale alle dimensioni aziendali simulate. Il test di base delle prestazioni per l'individuazione dell'heartbeat deve essere eseguito anche una volta alla settimana.
I dati di individuazione sono dati globali. Un problema comune correlato alle prestazioni consiste nel configurare erroneamente i metodi di individuazione basati su server in una gerarchia, causando l'individuazione duplicata delle stesse risorse da più siti primari. Configurare con attenzione i metodi di individuazione per ottimizzare la comunicazione con il servizio di destinazione, ad esempio i controller di dominio Active Directory, evitando la duplicazione dello stesso ambito di individuazione in più siti primari.
Linee guida generali per il ridimensionamento
In base alla metodologia di test delle prestazioni precedente, la tabella seguente fornisce linee guida generali sui requisiti hardware minimi per un numero specifico di client gestiti. Questi valori devono consentire alla maggior parte dei clienti con il numero specificato di client di elaborare gli oggetti in modo sufficientemente veloce da amministrare il sito specificato. La potenza di calcolo continua a diminuire di prezzo ogni anno e alcuni dei requisiti seguenti sono limitati per le moderne configurazioni hardware del server. L'hardware che supera le linee guida seguenti aumenta proporzionalmente le prestazioni per i siti che richiedono una maggiore potenza di elaborazione o hanno modelli di utilizzo del prodotto speciali.
| Client desktop | Tipo di sito/ruolo | Nota core 1 | Memoria (GB) | SQL Server l'allocazione della memoria Nota 2 | Operazioni di I/O al secondo: posta in arrivo Nota 3 | Operazioni di I/O al secondo: SQL Server Nota 3 | Spazio di archiviazione necessario (GB) Nota 4 |
|---|---|---|---|---|---|---|---|
| 25.000 | Primario o CAS con ruolo del sito del database nello stesso server | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25.000 | Primario o CAS | 4 | 8 | 600 | 100 | ||
| SQL Server remoto | 4 | 16 | 70% | 1700 | 250 | ||
| 50.000 | Primario o CAS con ruolo del sito del database nello stesso server | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50.000 | Primario o CAS | 4 | 8 | 1200 | 200 | ||
| SQL Server remoto | 8 | 24 | 70% | 2800 | 400 | ||
| 100.000 | Primario o CAS con ruolo del sito del database nello stesso server | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100.000 | Primario o CAS | 6 | 12 | 1200 | 300 | ||
| SQL Server remoto | 12 | 48 | 80% | 5000 | 800 | ||
| 150.000 | Primario o CAS con ruolo del sito del database nello stesso server | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150.000 | Primario o CAS | 8 | 16 | 1800 | 400 | ||
| SQL Server remoto | 16 | 72 | 90% | 7400 | 1200 | ||
| 700.000 | CAS con ruolo del sito del database nello stesso server | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700.000 | Cas | 8+ | 16+ | 1800+ | 500+ | ||
| SQL Server remoto | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5k | Sito secondario | 4 | 8 | 500 | - | 200 | |
| 15.000 | Sito secondario | 8 | 16 | 500 | - | 300 |
Note sulle linee guida generali per il dimensionamento
Nota 1: Core
Configuration Manager esegue molti processi simultanei, quindi richiede un determinato numero minimo di core CPU per varie dimensioni del sito. Anche se i core sono più veloci ogni anno, è importante assicurarsi che un determinato numero minimo di core funzioni in parallelo. In generale, qualsiasi CPU a livello di server prodotta dopo il 2015 soddisfa le esigenze di prestazioni di base per i core specificati nella tabella. Configuration Manager sfrutta altri core oltre alle raccomandazioni. Dopo aver suggerito i core minimi, assegnare priorità all'investimento delle risorse della CPU per aumentare la velocità dei core esistenti. Non aggiungere altri core più lenti. Ad esempio, Configuration Manager offre prestazioni migliori per le attività di elaborazione chiave con 16 core veloci rispetto a 24 core più lenti. Queste prestazioni presuppongono che siano presenti risorse di sistema sufficienti, ad esempio operazioni di I/O al secondo su disco.
Anche la relazione tra core e memoria è importante. In generale, avere meno di 3-4 GB di RAM per core riduce la funzionalità di elaborazione totale nei server SQL. È necessaria più RAM per core quando SQL Server viene collegato con i componenti del server del sito.
Nota
Tutti i test impostano le combinazioni per il risparmio di energia del computer per consentire il massimo consumo di energia e prestazioni della CPU.
Nota 2: SQL Server allocazione di memoria
Usare questo valore per configurare la memoria massima del server (in MB) nelle proprietà del SQL Server. Si tratta della percentuale della quantità totale di memoria disponibile nel server.
Non configurare gli stessi valori minimo e massimo. Questa guida è specifica per la memoria massima che è necessario consentire SQL Server allocare.
Nota 3: Operazioni di I/O al secondo: Posta in arrivo e operazioni di I/O al secondo: SQL
Questi valori fanno riferimento alle esigenze di I/O al secondo per le unità logiche Configuration Manager e SQL Server. La colonna IOPS: Posta in arrivo mostra i requisiti di I/O al secondo per l'unità logica con le directory di posta in arrivo Configuration Manager. La colonna IOPS: SQL mostra le operazioni di I/O al secondo totali necessarie per le unità logiche usate dai vari file SQL Server. Queste colonne sono diverse perché le due unità devono avere una formattazione diversa. Per altre informazioni ed esempi sulle configurazioni consigliate per SQL Server dischi e sulle procedure consigliate per i file, inclusi i dettagli sulla suddivisione dei file tra più volumi, vedere Domande frequenti sul ridimensionamento del sito e sulle prestazioni.
Entrambe queste colonne di operazioni di I/O al secondo usano i dati dello strumento standard del settore , Diskspd. Per istruzioni sulla duplicazione di queste misurazioni, vedere Come misurare le prestazioni del disco . In generale, dopo aver soddisfatto i requisiti di cpu e memoria di base, il sottosistema di archiviazione ha il maggiore impatto sulle prestazioni del sito e i miglioramenti in questo caso restituirà il maggior ritorno sugli investimenti.
Nota 4: Spazio di archiviazione necessario
Questi valori reali possono essere diversi da altri consigli documentati. Questi numeri vengono forniti solo come linee guida generali; requisiti individuali potrebbero variare notevolmente. Pianificare attentamente le esigenze di spazio su disco prima dell'installazione del sito. Si supponga che una certa quantità di spazio di archiviazione rimanga come spazio libero su disco per la maggior parte del tempo. È possibile usare questo spazio buffer in uno scenario di ripristino o per scenari di aggiornamento che richiedono spazio libero su disco per l'espansione del pacchetto di installazione. Il sito potrebbe richiedere più spazio di archiviazione per grandi quantità di raccolta dati, periodi più lunghi di conservazione dei dati e grandi quantità di contenuto di distribuzione software. È anche possibile archiviare questi elementi in volumi a velocità effettiva inferiore separati.
Come misurare le prestazioni del disco
È possibile usare lo strumento standard del settore Diskspd per fornire suggerimenti standardizzati per le operazioni di I/O al secondo richieste da ambienti di Configuration Manager di varie dimensioni. Anche se non esaustivi, i passaggi di test e le righe di comando seguenti offrono un modo semplice e riproducibile per stimare la velocità effettiva del sottosistema del disco dei server. È possibile confrontare i risultati con le operazioni di I/O al secondo minime consigliate nella tabella delle linee guida per il ridimensionamento generale .
Per i risultati dei test di diversi tipi di configurazioni hardware negli ambienti lab, vedere Configurazioni del disco di esempio. È possibile usare i dati per un punto di partenza approssimativo durante la progettazione del sottosistema di archiviazione per un nuovo ambiente da zero.
Come testare le operazioni di I/O al secondo su disco
Scaricare l'utilità Diskspd.
Assicurarsi di avere almeno 100 GB di spazio libero su disco. Disabilitare le app che potrebbero interferire o causare un carico aggiuntivo sul disco, ad esempio l'analisi antivirus attiva della directory, SQL o SMSExec.
Eseguire Diskspd da un prompt dei comandi con privilegi elevati.
Eseguire lo strumento due volte in sequenza per il volume da testare. Il primo test con dimensioni di 64.000 con operazioni di scrittura casuali per un minuto. Questo test convalida il caricamento della cache del controller e l'allocazione dello spazio su disco, nel caso in cui il volume si stia espandendo in modo dinamico. Rimuovere i risultati del primo test. Il secondo test deve seguire immediatamente il primo test ed eseguire lo stesso carico per cinque minuti.
Usare, ad esempio, le righe di comando specifiche seguenti per testare il
G:volume.DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.datEsaminare l'output del secondo test per trovare il numero totale di operazioni di I/O al secondo nella colonna I/O per s . Nell'esempio seguente le operazioni di I/O al secondo totali sono 3929,18.
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
Configurazioni del disco di esempio
Le tabelle seguenti mostrano i risultati dell'esecuzione dei passaggi di test in Come misurare le prestazioni del disco con varie configurazioni del lab di test. Usare questi dati per un punto di partenza approssimativo durante la progettazione del sottosistema di archiviazione per un nuovo ambiente da zero.
Computer fisici e Hyper-V
L'hardware è sempre in miglioramento. Si prevede che le nuove generazioni di hardware e combinazioni hardware diverse, ad esempio SSD e SAN, superino le prestazioni indicate di seguito. Questi risultati sono un punto di partenza di base da considerare quando si progetta un server o si discute con il fornitore dell'hardware.
La tabella seguente mostra i risultati dei test in vari sottosistemi del disco, inclusi i dischi rigidi basati su spindle e SSD, in varie configurazioni del lab di test. Tutte le configurazioni formattano i dischi con cluster da 64k e li collegano a un controller di disco di classe enterprise. Oltre al numero di dischi dell'array RAID, ognuno di essi ha almeno un disco di riserva.
| Tipo di disco | Numero di dischi, escluso +1 disco di riserva | RAID | Operazioni di I/O al secondo misurate |
|---|---|---|---|
| 15.000 sas | 2 | 1 | 620 |
| 15.000 sas | 4 | 10 | 1206 |
| 15.000 sas | 6 | 10 | 1751 |
| 15.000 sas | 8 | 10 | 2322 |
| 15.000 sas | 10 | 10 | 2882 |
| 15.000 sas | 12 | 10 | 3476 |
| 15.000 sas | 16 | 10 | 4236 |
| 15.000 sas | 20 | 10 | 5148 |
| 15.000 sas | 30 | 10 | 7398 |
| 15.000 sas | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| Firma di accesso condiviso SSD | 2 | 1 | 7539 |
| Firma di accesso condiviso SSD | 4 | 10 | 14346 |
| Firma di accesso condiviso SSD | 6 | 10 | 15607 |
Nella tabella seguente sono elencati i dispositivi specifici usati in questo esempio. Queste informazioni non sono una raccomandazione per un modello hardware o un produttore specifico.
| Tipo di disco | Modello | Controller RAID | Memoria e configurazione della cache |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | Smart Array P822 | 2 GB, 20% lettura/80% scrittura |
| SSD SATA | ATA MK0200GCTYV | Smart Array P420i | 1 GB, 20% lettura/80% scrittura |
| Firma di accesso condiviso SSD | HP MO0800 JEFPB | Smart Array P420i | 1 GB, 20% lettura/80% scrittura |
Prestazioni di computer e dischi di Azure
Le prestazioni dei dischi di Azure dipendono da diversi fattori, ad esempio le dimensioni della macchina virtuale di Azure e il numero e il tipo di dischi usati. Azure aggiunge inoltre costantemente nuovi tipi di computer e velocità del disco diversi dal grafico seguente. Per altre informazioni sui Configuration Manager in esecuzione in Azure e altre informazioni sulla comprensione dell'I/O su disco in Azure, vedere Configuration Manager domande frequenti su Azure.
Tutti i dischi sono formattati con dimensione cluster NTFS 64k e le righe con più dischi vengono configurate come volumi con striping tramite l'utilità Gestione dischi di Windows.
| Macchina virtuale di Azure | Disco di Azure | Numero di dischi | Spazio disponibile | Operazioni di I/O al secondo misurate | Fattore di limitazione |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 GB | 965 | Dimensioni della macchina virtuale di Azure |
| DS2/DS11 | P20 | 2 | 1024 GB | 996 | Dimensioni della macchina virtuale di Azure |
| DS2/DS11 | P30 | 1 | 1024 GB | 996 | Dimensioni della macchina virtuale di Azure |
| DS2/DS11 | P30 | 2 | 2048 GB | 996 | Dimensioni della macchina virtuale di Azure |
| DS3/DS12/F4S | P20 | 1 | 512 GB | 1994 | Dimensioni della macchina virtuale di Azure |
| DS3/DS12/F4S | P20 | 2 | 1024 GB | 1992 | Dimensioni della macchina virtuale di Azure |
| DS3/DS12/F4S | P30 | 1 | 1024 GB | 1993 | Dimensioni della macchina virtuale di Azure |
| DS3/DS12/F4S | P30 | 2 | 2048 GB | 1992 | Dimensioni della macchina virtuale di Azure |
| DS4/DS13/F8S | P20 | 1 | 512 GB | 2334 | Disco P20 |
| DS4/DS13/F8S | P20 | 2 | 1024 GB | 3984 | Dimensioni della macchina virtuale di Azure |
| DS4/DS13/F8S | P20 | 3 | 1536 GB | 3984 | Dimensioni della macchina virtuale di Azure |
| DS4/DS13/F8S | P30 | 1 | 1024 GB | 3112 | Disco P30 |
| DS4/DS13/F8S | P30 | 2 | 2048 GB | 3984 | Dimensioni della macchina virtuale di Azure |
| DS4/DS13/F8S | P30 | 3 | 3072 GB | 3996 | Dimensioni della macchina virtuale di Azure |
| DS5/DS14/F16S | P20 | 1 | 512 GB | 2335 | Disco P20 |
| DS5/DS14/F16S | P20 | 2 | 1024 GB | 4639 | Disco P20 |
| DS5/DS14/F16S | P20 | 3 | 1536 GB | 6913 | Disco P20 |
| DS5/DS14/F16S | P20 | 4 | 2048 GB | 7966 | Dimensioni della macchina virtuale di Azure |
| DS5/DS14/F16S | P30 | 1 | 1024 GB | 3112 | Disco P30 |
| DS5/DS14/F16S | P30 | 2 | 2048 GB | 6182 | Disco P30 |
| DS5/DS14/F16S | P30 | 3 | 3072 GB | 7963 | Dimensioni della macchina virtuale di Azure |
| DS5/DS14/F16S | P30 | 4 | 4096 GB | 7968 | Dimensioni della macchina virtuale di Azure |
| DS15 | P30 | 1 | 1024 GB | 3113 | Disco P30 |
| DS15 | P30 | 2 | 2048 GB | 6184 | Disco P30 |
| DS15 | P30 | 3 | 3072 GB | 9225 | Disco P30 |
| DS15 | P30 | 4 | 4096 GB | 10200 | Dimensioni della macchina virtuale di Azure |
Per altre informazioni sui dischi attualmente disponibili, vedere Selezionare un tipo di disco per le macchine virtuali IaaS di Azure.