Configuration Manager le dimensioni del sito e le linee guida sulle prestazioni

  • Articolo

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

  1. Scaricare l'utilità Diskspd.

  2. 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.

  3. 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.dat

  4. Esaminare 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.

Vedere anche