Configuration Manager directrices de rendimiento y tamaño del sitio

Se aplica a: Configuration Manager (rama actual)

Configuration Manager lidera el sector en escala y rendimiento. En otra documentación se tratan los límites de escalado máximos admitidos y las directrices de hardware para ejecutar sitios en los tamaños de entorno más grandes. En este artículo se proporcionan instrucciones de rendimiento complementarias para entornos de todos los tamaños. Esta guía puede ayudarle a calcular con más precisión el hardware que necesita para implementar Configuration Manager.

Este artículo se centra en el mayor colaborador de Configuration Manager cuellos de botella de rendimiento: el subsistema de entrada y salida de disco o IOPS.

  • Presenta detalles y resultados de pruebas centrados en IOPS
  • Documentos sobre cómo reproducir las pruebas con sus propios entornos y hardware
  • Sugiere requisitos de IOPS de disco para varios entornos de tamaño

Metodología de pruebas de rendimiento

Puede implementar Configuration Manager de muchas maneras únicas, pero es importante comprender algunas variables en las discusiones de tamaño. Una variable es el intervalo de características, como un ciclo de inventario. Otra variable es el número de usuarios, implementaciones de software u otros objetos a los que el sistema hace referencia o implementa. Las pruebas de rendimiento aplican estas variables como parte de una carga. La carga genera objetos a una velocidad típica para los clientes empresariales que usan implementaciones de producción en entornos de tamaño diferente.

Nota:

Los datos de uso del cliente permiten probar las compilaciones de rama actuales con los escenarios, configuraciones y configuraciones más comunes para la mayoría de los clientes. Las recomendaciones de este artículo se basan en estos promedios. Las experiencias pueden variar en función del tamaño y la configuración del entorno. En general, Configuration Manager requiere sentido común cuando se trata de objetos e intervalos. El hecho de que pueda recopilar todos los archivos de un sistema o establecer el intervalo de un ciclo en un minuto no significa que deba hacerlo.

En las secciones siguientes se resaltan algunas configuraciones y configuraciones clave que se deben usar al probar y modelar las necesidades de procesamiento para grandes empresas. Estas directrices ayudan a establecer expectativas básicas de rendimiento del sistema para los tamaños de hardware sugeridos.

Configuración de intervalos de características

La mayoría de las pruebas deben usar intervalos predeterminados para los ciclos de clave del sistema. Por ejemplo, las pruebas de inventario de hardware se producen una vez por semana con un archivo .mof mayor que el predeterminado. Algunos intervalos de características periódicos, especialmente los ciclos de inventario de hardware y software, pueden tener efectos significativos en las características de rendimiento de un entorno. Los entornos que habilitan intervalos predeterminados agresivos para la recopilación de datos necesitan hardware de gran tamaño en proporción directa con el aumento de la actividad. Por ejemplo, supongamos que tiene 25 000 clientes de escritorio y quiere recopilar el inventario de hardware dos veces más rápido que el intervalo predeterminado. Empiece por ajustar el tamaño del hardware del sitio como si tuviera 50 000 clientes.

Objetos

Las pruebas deben usar el promedio superior de los objetos que las grandes empresas tienden a usar con el sistema. Los valores típicos son miles de colecciones y aplicaciones, que se implementan en cientos de miles de usuarios o sistemas. Las pruebas deben ejecutarse simultáneamente en todos los objetos del sistema en estos límites. Muchos clientes usan varias características, pero no suelen usar todas las características del producto en estos límites superiores. Las pruebas con todas las características del producto ayudan a garantizar el mejor rendimiento posible en todo el sistema y permiten un búfer para las características que algunos clientes pueden usar por encima de la media.

Cargas

Las pruebas también deben ejecutarse en cargas diarias mayores que el promedio estándar, mediante simulaciones que generan demandas máximas de uso en el sistema. Un ejemplo es simular implementaciones de Patch Tuesday para asegurarse de que el sistema puede devolver los datos de cumplimiento de actualizaciones rápidamente durante estos días de actividad máxima. Otro ejemplo es la simulación de la actividad del sitio durante un brote de malware generalizado, para garantizar que es posible una notificación y una respuesta oportunas. Aunque las máquinas implementadas del tamaño recomendado pueden estar infrautilizadas en un día determinado, las situaciones más extremas requieren algún búfer de procesamiento.

Configuraciones

Ejecute pruebas en una amplia gama de hardware físico, Hyper-V y Azure, con una combinación de sistemas operativos compatibles y versiones de SQL Server. Valide siempre los peores casos de la configuración admitida. En general, Hyper-V y Azure devuelven resultados de rendimiento comparables al hardware físico equivalente cuando se configuran de forma similar. Los sistemas operativos de servidor actuales tienden a tener un rendimiento igual o mejor que las versiones anteriores del sistema operativo. Aunque todas las plataformas admitidas cumplen los requisitos mínimos, normalmente las versiones más recientes de productos auxiliares como Windows y SQL Server producen un rendimiento aún mejor.

La variación más grande procede de las versiones de SQL Server en uso. Para obtener más información sobre SQL Server versiones, consulte ¿Qué versión de SQL Server debo ejecutar?.

Determinantes clave del rendimiento

Puede probar y medir Configuration Manager rendimiento con diferentes tipos de configuración, de diferentes maneras y en diferentes tamaños de sitio. La configuración y los objetos siguientes pueden afectar considerablemente al rendimiento. Asegúrese de tenerlas en cuenta al probar y modelar el rendimiento en su entorno.

Precaución

Aunque algunos aspectos de Configuration Manager tienen máximos oficiales o límites de interfaz de usuario que impiden un uso excesivo, ir más allá de las directrices puede tener efectos adversos significativos en el rendimiento de un sitio. Superar los niveles recomendados o omitir la guía de ajuste de tamaño normalmente requiere hardware más grande y puede hacer que el entorno no sea inmaintenible hasta que se reduzca la frecuencia o el recuento de varios objetos.

Inventario de hardware

Para probar el rendimiento de la línea base, establezca la recopilación de inventario de hardware en una vez por semana, con el tamaño de archivo .mof predeterminado más aproximadamente el 20 % de otras propiedades. No habilite todas las propiedades y recopile solo las propiedades que realmente necesita. Preste especial atención al recopilar propiedades, como la memoria virtual disponible, que siempre cambiará con cada ciclo de inventario. La recopilación de estas propiedades puede provocar una renovación excesiva en cada ciclo de inventario de cada cliente.

Inventario de software

Para probar el rendimiento de la línea base, establezca la recopilación de inventario de software en una vez por semana, solo con detalles del producto . La recopilación de muchos archivos puede suponer una presión significativa en el subsistema de inventario. Evite especificar filtros que podrían terminar recopilando miles de archivos en muchos clientes, como *.exe o *.dll.

Colecciones

Las pruebas de rendimiento de línea base pueden incluir varios miles de colecciones con diferentes tipos de ámbito, tamaño, complejidad y configuración de actualización. El rendimiento del sitio no es una función directa del gran número de colecciones de un sitio. El rendimiento también es un producto cruzado de la complejidad de las consultas de las colecciones, las actualizaciones completas e incrementales y la frecuencia de cambio, las dependencias entre colecciones y el número de clientes de las colecciones.

Siempre que sea posible, minimice las colecciones que tienen consultas de reglas dinámicas costosas o complicadas. En el caso de las colecciones que requieren estos tipos de reglas, establezca los intervalos de actualización y los tiempos de actualización adecuados para minimizar el efecto de la reevaluación de recopilación en el sistema. Por ejemplo, actualice a medianoche en lugar de a las 8:00 a.m.

La habilitación de actualizaciones incrementales en colecciones garantiza actualizaciones rápidas y oportunas de la pertenencia a la recopilación. Pero aunque las actualizaciones incrementales son eficaces, siguen cargando el sistema. Equilibre la frecuencia de cambio que espera con la necesidad de actualizaciones casi en tiempo real sobre la pertenencia. Por ejemplo, supongamos que espera una gran renovación en los miembros de la colección, pero no necesita actualizaciones de pertenencia casi en tiempo real. Es más eficaz y genera menos carga en el sistema para actualizar la colección con una actualización completa programada en algún intervalo, que para habilitar las actualizaciones incrementales.

Al habilitar las actualizaciones incrementales, reduzca las actualizaciones completas programadas en las mismas colecciones. Solo son un método de copia de seguridad de evaluación, ya que las actualizaciones incrementales deben mantener actualizada la pertenencia a la colección casi en tiempo real. Los procedimientos recomendados para colecciones recomiendan un número máximo de colecciones totales para las actualizaciones incrementales, pero, como señala el artículo, la experiencia puede variar en función de muchos factores.

Las colecciones con solo reglas de pertenencia directa y con una colección limitante que no realiza actualizaciones incrementales no necesitan actualizaciones completas programadas. Deshabilite las programaciones de actualización de estos tipos de colecciones para evitar la carga innecesaria en el sistema. Si la recopilación de limitación usa actualizaciones incrementales, es posible que las recopilaciones con solo reglas de pertenencia directa no reflejen las actualizaciones de pertenencia durante un máximo de 24 horas o hasta que se produzca una actualización programada.

Aunque no es un procedimiento recomendado, algunas organizaciones crean cientos o incluso miles de colecciones como parte de varios procesos empresariales. Si usa la automatización para crear colecciones, es importante habilitar correctamente las actualizaciones incrementales necesarias. Minimice y distribuya todas las programaciones de actualización completas para evitar puntos frecuentes de evaluación de recopilación durante un único período de tiempo. Establezca un proceso de limpieza normal para eliminar colecciones no utilizadas, especialmente si crea automáticamente colecciones que ya no necesita después de algún tiempo.

Recuerde que Configuration Manager crea directivas para todos los objetos de las colecciones cuando tiene como destino tareas como las implementaciones en ellas. Los cambios de pertenencia, ya sea a través de actualizaciones programadas o incrementales, pueden crear mucho más trabajo para todo el sistema. Las compilaciones de rama actuales más recientes tienen optimizaciones de directivas especiales para las colecciones Todos los sistemas y Todos los usuarios. Al dirigirse a toda la empresa, use las colecciones integradas en lugar de un clon de estas colecciones integradas.

Para investigar aún más el rendimiento de la recopilación, vea la evaluación de recopilación en la consola. Para obtener más información, vea How to view collection evaluation (Cómo ver la evaluación de recopilación).

Métodos de detección

Para las pruebas de rendimiento de línea base, ejecute métodos de detección basados en servidor una vez por semana, lo que permite la detección diferencial según corresponda para mantener los datos actualizados durante la semana. Las pruebas deben detectar una cantidad de objeto proporcional al tamaño de empresa simulado. La prueba de línea base de rendimiento para la detección de latidos también debe ejecutarse una vez a la semana.

Los datos de detección son datos globales. Un problema común relacionado con el rendimiento consiste en configurar erróneamente métodos de detección basados en servidor en una jerarquía, lo que provoca la detección duplicada de los mismos recursos de varios sitios primarios. Configure cuidadosamente los métodos de detección para optimizar la comunicación con el servicio de destino, como los controladores de dominio de Active Directory, a la vez que evita la duplicación del mismo ámbito de detección en varios sitios primarios.

Directrices generales de ajuste de tamaño

En función de la metodología de prueba de rendimiento anterior, en la tabla siguiente se proporcionan directrices generales de requisitos mínimos de hardware para números específicos de clientes administrados. Estos valores deben permitir que la mayoría de los clientes con el número especificado de clientes procesen objetos lo suficientemente rápido como para administrar el sitio especificado. La potencia informática sigue disminuyendo en el precio cada año y algunos de los requisitos siguientes son pequeños para las configuraciones de hardware de servidor modernas. El hardware que supera las siguientes directrices aumenta proporcionalmente el rendimiento de los sitios que requieren más potencia de procesamiento o tienen patrones de uso de productos especiales.

Clientes de escritorio Tipo de sitio o rol Nota de núcleos 1 Memoria (GB) SQL Server nota 2 de asignación de memoria IOPS: Bandejas de entrada Nota 3 IOPS: SQL Server nota 3 Espacio de almacenamiento necesario (GB) Nota 4
25 000 Principal o CAS con rol de sitio de base de datos en el mismo servidor 6 24 65% 600 1700 350
25 000 Principal o CAS 4 8 600 100
SQL Server remota 4 16 70% 1700 250
50 000 Principal o CAS con rol de sitio de base de datos en el mismo servidor 8 32 70% 1200 2800 600
50 000 Principal o CAS 4 8 1200 200
SQL Server remota 8 24 70% 2800 400
100 000 Principal o CAS con rol de sitio de base de datos en el mismo servidor 12 64 70% 1200 5000 1100
100 000 Principal o CAS 6 12 1200 300
SQL Server remota 12 48 80% 5000 800
150 000 Principal o CAS con rol de sitio de base de datos en el mismo servidor 16 96 70% 1800 7400 1600
150 000 Principal o CAS 8 16 1800 400
SQL Server remota 16 72 90 % 7400 1200
700 000 CAS con rol de sitio de base de datos en el mismo servidor 20+ 128+ 80% 1800+ 9000+ 5000+
700 000 Cas 8+ 16+ 1800+ 500+
SQL Server remota 16+ 96+ 90 % 9000+ 4500+
5 000 Sitio secundario 4 8 500 - 200
15 000 Sitio secundario 8 16 500 - 300

Notas sobre las directrices generales de ajuste de tamaño

Nota 1: Núcleos

Configuration Manager ejecuta muchos procesos simultáneos, por lo que necesita un número mínimo determinado de núcleos de CPU para varios tamaños de sitio. Aunque los núcleos se aceleran cada año, es importante asegurarse de que un determinado número mínimo de núcleos funcione en paralelo. En general, cualquier CPU de nivel de servidor generada después de 2015 satisface las necesidades básicas de rendimiento de los núcleos especificados en la tabla. Configuration Manager aprovecha otros núcleos más allá de las recomendaciones. Una vez que tenga los núcleos mínimos sugeridos, priorice la inversión en recursos de CPU para aumentar la velocidad de los núcleos existentes. No agregue más núcleos más lentos. Por ejemplo, Configuration Manager tiene un mejor rendimiento en las tareas de procesamiento de claves con 16 núcleos rápidos que con 24 núcleos más lentos. Este rendimiento supone que hay suficientes otros recursos del sistema, como IOPS de disco.

La relación entre los núcleos y la memoria también es importante. En general, tener menos de 3-4 GB de RAM por núcleo reduce la capacidad de procesamiento total en los servidores SQL Server. Necesita más RAM por núcleo cuando SQL Server se coloca con los componentes del servidor de sitio.

Nota:

Todas las pruebas establecen planes de energía de máquina para permitir el máximo consumo y rendimiento de la CPU.

Nota 2: asignación de memoria SQL Server

Use este valor para configurar la memoria máxima del servidor (en MB) en las propiedades de la SQL Server. Es el porcentaje de la cantidad total de memoria disponible en el servidor.

No configure los valores mínimo y máximo del mismo modo. Esta guía es específicamente para la memoria máxima que debe permitir que SQL Server asigne.

Nota 3: IOPS: Bandejas de entrada e IOPS: SQL

Estos valores hacen referencia a las necesidades de IOPS para las unidades lógicas Configuration Manager y SQL Server. La columna IOPS: Bandejas de entrada muestra los requisitos de IOPS para la unidad lógica con los directorios de bandeja de entrada de Configuration Manager. La columna IOPS: SQL muestra las necesidades totales de IOPS para las unidades lógicas que usan varios archivos SQL Server. Estas columnas son diferentes porque las dos unidades deben tener un formato diferente. Para obtener más información y ejemplos sobre las configuraciones de disco SQL Server sugeridas y los procedimientos recomendados para archivos, incluidos los detalles sobre la división de archivos en varios volúmenes, consulte las preguntas más frecuentes sobre el tamaño y el rendimiento del sitio.

Ambas columnas de IOPS usan datos de la herramienta estándar del sector, Diskspd. Consulte Cómo medir el rendimiento del disco para obtener instrucciones sobre cómo duplicar estas medidas. En general, una vez que cumpla los requisitos básicos de CPU y memoria, el subsistema de almacenamiento tendrá el mayor impacto en el rendimiento del sitio y las mejoras aquí proporcionarán la mayor rentabilidad de la inversión.

Nota 4: Espacio de almacenamiento necesario

Estos valores reales pueden diferir de otras recomendaciones documentadas. Proporcionamos estos números solo como una guía general; los requisitos individuales pueden variar ampliamente. Planee cuidadosamente las necesidades de espacio en disco antes de la instalación del sitio. Supongamos que parte de este almacenamiento permanece como espacio libre en disco la mayor parte del tiempo. Puede usar este espacio de búfer en un escenario de recuperación o para escenarios de actualización que necesiten espacio libre en disco para la expansión del paquete de instalación. Su sitio puede requerir más almacenamiento para grandes cantidades de recopilación de datos, períodos más largos de retención de datos y grandes cantidades de contenido de distribución de software. También puede almacenar estos elementos en volúmenes independientes de menor rendimiento.

Cómo medir el rendimiento del disco

Puede usar la herramienta estándar del sector Diskspd para proporcionar sugerencias estandarizadas para las IOPS que requieren varios entornos de Configuration Manager de tamaño. Aunque no es exhaustiva, los siguientes pasos de prueba y las líneas de comandos proporcionan una manera sencilla y reproducible de calcular el rendimiento del subsistema de disco de los servidores. Puede comparar los resultados con las IOPS recomendadas mínimas en la tabla general de directrices de ajuste de tamaño .

Para obtener resultados de pruebas de diferentes tipos de configuraciones de hardware en entornos de laboratorio, consulte Configuraciones de disco de ejemplo. Puede usar los datos para un punto inicial aproximado al diseñar el subsistema de almacenamiento para un nuevo entorno desde cero.

Prueba de IOPS de disco

  1. Descargue la utilidad Diskspd.

  2. Asegúrese de que tiene al menos 100 GB de espacio libre en disco. Deshabilite las aplicaciones que puedan interferir o provocar una carga adicional en el disco, como el examen antivirus activo del directorio, SQL o SMSExec.

  3. Ejecute Diskspd desde un símbolo del sistema con privilegios elevados.

    Ejecute la herramienta dos veces en secuencia para el volumen que desea probar. La primera prueba con un tamaño de 64 k con operaciones de escritura aleatorias durante un minuto. Esta prueba valida la carga de la memoria caché del controlador y la asignación de espacio en disco, en caso de que el volumen se expanda dinámicamente. Descarte los resultados de la primera prueba. La segunda prueba debe seguir inmediatamente la primera prueba y realizar la misma carga durante cinco minutos.

    Por ejemplo, use las siguientes líneas de comandos específicas para probar el G: volumen.

    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. Revise la salida de la segunda prueba para buscar el total de IOPS en la columna E/S por s . En el ejemplo siguiente, el total de IOPS es de 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    |
    

Configuraciones de disco de ejemplo

En las tablas siguientes se muestran los resultados de la ejecución de los pasos de prueba en Cómo medir el rendimiento del disco con varias configuraciones de laboratorio de pruebas. Use estos datos para un punto inicial aproximado al diseñar el subsistema de almacenamiento para un nuevo entorno desde cero.

Máquinas físicas e Hyper-V

El hardware siempre mejora. Espere que las generaciones más recientes de hardware y diferentes combinaciones de hardware, como SSD y SAN, superen el rendimiento indicado a continuación. Estos resultados son un punto de partida básico que se debe tener en cuenta al diseñar un servidor o discutir con el proveedor de hardware.

En la tabla siguiente se muestran los resultados de las pruebas en varios subsistemas de disco, incluidos los discos duros basados en SSD y husillo, en varias configuraciones de laboratorio de pruebas. Todas las configuraciones dan formato a los discos con clústeres de 64 000 y los asocian a un controlador de disco de clase empresarial. Además del recuento de discos de matriz RAID, cada uno de ellos tiene al menos un disco de reserva.

Tipo de disco Recuento de discos, sin incluir +1 disco de reserva RAID IOPS medidas
SAS de 15 000 2 1 620
SAS de 15 000 4 10 1206
SAS de 15 000 6 10 1751
SAS de 15 000 8 10 2322
SAS de 15 000 10 10 2882
SAS de 15 000 12 10 3476
SAS de 15 000 16 10 4236
SAS de 15 000 20 10 5148
SAS de 15 000 30 10 7398
SAS de 15 000 40 10 9913
SSD SATA 2 1 3300
SSD SATA 4 10 5542
SSD SATA 6 10 7201
SSD SAS 2 1 7539
SSD SAS 4 10 14346
SSD SAS 6 10 15607

En la tabla siguiente se enumeran los dispositivos específicos usados en este ejemplo. Esta información no es una recomendación para ningún fabricante o modelo de hardware específico.

Tipo de disco Model Controlador RAID Almacenamiento en caché de memoria y configuración
15 000 RPM SAS HD HP EH0300JDYTH Matriz inteligente P822 2 GB, 20 % de lectura / 80 % de escritura
SSD SATA ATA MK0200GCTYV Matriz inteligente P420i 1 GB, 20 % de lectura / 80 % de escritura
SSD SAS HP MO0800 JEFPB Matriz inteligente P420i 1 GB, 20 % de lectura / 80 % de escritura

Rendimiento de máquinas y discos de Azure

El rendimiento del disco de Azure depende de varios factores, como el tamaño de la máquina virtual de Azure y el número y el tipo de discos que usa. Azure también agrega constantemente nuevos tipos de máquina y velocidades de disco que son diferentes del gráfico siguiente. Para obtener más información sobre Configuration Manager que se ejecutan en Azure e información adicional sobre cómo comprender la E/S de disco en Azure, consulte Configuration Manager en Las preguntas más frecuentes sobre Azure.

Todos los discos tienen formato de clúster NTFS 64k y las filas con más de un disco se configuran como volúmenes seccionados a través de la utilidad Administración de discos de Windows.

Máquina virtual de Azure Disco de Azure Recuento de discos Espacio disponible IOPS medidas Factor de limitación
DS2/DS11 P20 1 512 GB 965 Tamaño de máquina virtual de Azure
DS2/DS11 P20 2 1024 GB 996 Tamaño de máquina virtual de Azure
DS2/DS11 P30 1 1024 GB 996 Tamaño de máquina virtual de Azure
DS2/DS11 P30 2 2048 GB 996 Tamaño de máquina virtual de Azure
DS3/DS12/F4S P20 1 512 GB 1994 Tamaño de máquina virtual de Azure
DS3/DS12/F4S P20 2 1024 GB 1992 Tamaño de máquina virtual de Azure
DS3/DS12/F4S P30 1 1024 GB 1993 Tamaño de máquina virtual de Azure
DS3/DS12/F4S P30 2 2048 GB 1992 Tamaño de máquina virtual de Azure
DS4/DS13/F8S P20 1 512 GB 2334 Disco P20
DS4/DS13/F8S P20 2 1024 GB 3984 Tamaño de máquina virtual de Azure
DS4/DS13/F8S P20 3 1536 GB 3984 Tamaño de máquina virtual de Azure
DS4/DS13/F8S P30 1 1024 GB 3112 Disco P30
DS4/DS13/F8S P30 2 2048 GB 3984 Tamaño de máquina virtual de Azure
DS4/DS13/F8S P30 3 3072 GB 3996 Tamaño de máquina virtual de 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 Tamaño de máquina virtual de 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 Tamaño de máquina virtual de Azure
DS5/DS14/F16S P30 4 4096 GB 7968 Tamaño de máquina virtual de 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 Tamaño de máquina virtual de Azure

Para obtener más información sobre los discos disponibles actualmente, consulte Selección de un tipo de disco para máquinas virtuales IaaS de Azure.

Vea también