En igualdad de condiciones, ¿cómo cambiaría el rendimiento IOPS de una matriz de almacenamiento si se usaran discos más grandes?
Por ejemplo, tome una matriz con discos de 10 X 100GB.
Mida IOPS para escrituras de bloque secuenciales de 256 kb (o cualquier métrica de IOPS)
Supongamos que el IOPS medido resultante es 1000 IOPS.
Cambie la matriz por una con discos de 10 X 200GB. Formato con la misma configuración RAID, mismo tamaño de bloque, etc.
¿Se esperaría que el IOPS permanezca igual, aumente o disminuya? ¿El cambio sería más o menos lineal? es decir, aumentar en 2X o disminuir en 2X (ya que he aumentado la capacidad del disco en 2X)
Repita estas preguntas con discos de 10 X 50 GB.
Editar: más contexto
Esta pregunta resultó como una conversación entre mi equipo de Sysadmin que no conoce bien el almacenamiento. (Cómodo con muchos aspectos del almacenamiento, pero no con los detalles de administrar una SAN o lo que sea). Estamos recibiendo una gran cantidad de nuevas bandejas de Netapp que tienen mayor capacidad de disco por disco (capacidad doble) que nuestras bandejas existentes. Surgió el comentario de que los IOPS de las nuevas bandejas serían más bajos solo porque los discos eran más grandes. Entonces surgió una analogía del automóvil para explicar esto. Ninguno de los comentarios se sentó bien conmigo, así que quería enviarlo a The Team, es decir, Stack-Exchange-land.
La analogía del auto era algo acerca de dos autos, con diferente aceleración, la misma velocidad máxima y corriendo un cuarto de milla. Luego cambie la distancia a media milla. En realidad, no recuerdo la analogía exacta, pero como encontré otra en el interwebz que era similar, pensé que probablemente era una analogía común de IOPS.
De alguna manera, la respuesta real a la pregunta no me importa mucho, ya que no estamos utilizando esta información para evaluar una compra. Pero necesitamos evaluar la mejor manera de unir las bandejas a un cabezal existente, y la mejor manera de tallar agregados y volúmenes.
Respuestas:
Para responder a su pregunta directamente: todas las demás cosas son iguales = sin cambio alguno cuando GB cambia.
No mides IOPS con GB. Usas el tiempo de búsqueda y la latencia.
Podría reescribirlo todo aquí, pero estos ejemplos a continuación ya hacen todo eso y simplemente lo repetiría:
https://ryanfrantz.com/posts/calculating-disk-iops.html
http://www.big-data-storage.co.uk/how-to-calculate-iops/
http://www.wmarow.com/strcalc/
http://www.thecloudcalculator.com/calculators/disk-raid-and-iops.html
fuente
Sé que esta es probablemente una pregunta hipotética ... Pero el mundo de TI realmente no funciona de esa manera. Hay restricciones realistas a considerar, además de otras cosas que pueden influir en IOPS ...
Los discos de 50 GB y 100 GB ya no existen. Piense más: 72, 146, 300, 450, 600, 900, 1200 GB en discos empresariales y 500, 1000, 2000, 3000, 4000, 6000 GB en medios de almacenamiento masivo de línea cercana / media.
Hay tanta abstracción en el almacenamiento moderno; almacenamiento en caché de disco, almacenamiento en caché del controlador, descarga de SSD, etc., que cualquier diferencia sería difícil de discernir.
Debe tener en cuenta diferentes factores de forma de unidad, interfaces y velocidades de rotación. Los discos SATA tienen un perfil de rendimiento diferente que SAS o SAS nearline . Los discos de 7,200 RPM se comportan de manera diferente a 10,000 RPM o 15,000 RPM. Y la disponibilidad de varias velocidades de rotación se limita a ciertas capacidades.
Diseño del controlador físico. Los expansores SAS, los controladores RAID / SAS pueden influir en IOPS, dependiendo del diseño del disco, las tasas de exceso de suscripción, si la conectividad es interna al servidor o en un gabinete externo. Gran cantidad de discos SATA funcionan mal en los expansores y durante las condiciones de error de la unidad .
Algo de esto puede verse influenciado por la fragmentación, la capacidad utilizada en la matriz de discos.
¿Has oído hablar de golpes cortos ?
RAID de software versus hardware, captación previa, perfiles adaptativos ...
¿Qué te lleva a creer que la capacidad tendría algún impacto en el rendimiento en primer lugar? ¿Puedes proporcionar más contexto?
Editar:
Si el tipo de disco, el factor de forma, la interfaz y la capacidad utilizada son los mismos, entonces no debería haber una diferencia apreciable en IOPS. Digamos que estaba pasando de 300 GB a 600 GB de discos SAS 10k empresariales. Con el mismo número de husos, no debería ver ninguna diferencia de rendimiento ...
Sin embargo, si las estanterías de disco de NetApp que menciona emplean planos posteriores SAS de 6 Gbps o 12 Gbps frente a 3Gbps heredados, es posible que vea un cambio en el rendimiento al ir a equipos más nuevos.
fuente
Un lugar donde no es una relación directa entre el tamaño del disco y IOPS está en la nube de AWS Amazon y otros servicios "nublados". Dos tipos de servicios de AWS ( Elastic Block Store y Relational Database Service ) proporcionan IOPS más altos para discos de mayor tamaño.
Tenga en cuenta que esta es una restricción artificial impuesta por Amazon en sus servicios. No hay ninguna razón relacionada con el hardware para que este sea el caso. Sin embargo, he visto tipos de DevOps que no están familiarizados con el hardware no virtualizado y creen que esta restricción es apropiada también para sistemas de escritorio y similares. La relación tamaño de disco / IOPS es una restricción de marketing en la nube, no una restricción de hardware.
fuente
Debo señalar que los IOPS no son una gran medida de velocidad en escrituras secuenciales, pero vamos con eso.
Sospecho que los tiempos de búsqueda y escritura de los cabezales de los discos son bastante consistentes a pesar del tamaño de los discos. Hace 20 años, todos usamos discos de 60GB con (aproximadamente, ciertamente no linealmente) las mismas velocidades de lectura / escritura.
Estoy haciendo una suposición educada, pero no creo que la densidad del disco se relacione linealmente con el rendimiento del disco.
Okay
Probablemente sigan siendo aproximadamente equivalentes entre sí.
La historia de los medios rotativos me dice que probablemente no hay relación.
De nuevo, más o menos equivalente.
Su velocidad, en todos estos casos, proviene del hecho de que el RAID actúa como un solo disco con diez cabezales de escritura, por lo que puede enviar 1/10 del trabajo en paralelo a cada disco.
Si bien no tengo números difíciles de mostrar, mi experiencia pasada me dice que aumentar el rendimiento de sus discos no es tan simple como obtener más capacidad.
A pesar de lo que la gente de marketing dicen que es la innovación, antes del inicio de barato (er) discos de estado sólido ha habido un desarrollo poco significativo en el rendimiento de hacer girar los medios de comunicación en los últimos 20 años, probablemente hay solamente por lo tanto se puede salir de la roya y solo tan rápido podemos lograr que nuestros modelos actuales de cabezales de disco funcionen.
fuente
El rendimiento agregado a las escalas de almacenamiento con cada huso agregado. La velocidad de rotación de la unidad es el factor más importante, por lo que agregar una unidad de 10k RPM dará más rendimiento (en términos de E / S en E / S al azar o MB / s en transmisión de E / S) que una unidad de 7.2k RPM. El tamaño de la unidad no tiene prácticamente ningún efecto.
La gente dice que las unidades pequeñas van más rápido simplemente porque necesita más husillos por TB utilizable. Aumentar el tamaño de la unidad de esos husillos no disminuirá el rendimiento, pero le permitirá ajustar más datos en los discos, lo que puede resultar en una mayor carga de trabajo.
fuente
Si supone que todo lo demás es igual, las características de rendimiento de los discos de mayor capacidad no cambian mucho. Una unidad de 10K RPM FC tiene características muy similares, independientemente de si se trata de 300 GB o 3 TB. Los platos giran a la misma velocidad, y las cabezas buscan a la misma velocidad.
Rendimiento sostenido del mismo modo, no hay mucha diferencia. Sin embargo, esta es la raíz de muchos de los problemas de rendimiento, ya que en muchos casos, las personas compran terabytes, no compran IOP o MB / seg.
Y tomará 10 veces más tiempo reconstruir / copiar una unidad de 3 TB que una unidad de 300 GB.
Como resultado, hemos tenido que considerar un exceso de capacidad sustancial para los proyectos de almacenamiento: los tamaños de las unidades siguen creciendo, pero su capacidad de rendimiento no es demasiado. Entonces, en al menos un caso, hemos comprado ~ 400 TB de almacenamiento para cumplir con un requisito de 100 TB, porque necesitamos los husillos.
fuente
Si está girando discos (no SSD), entonces todo lo demás es igual, la velocidad de transferencia es mayor si usa las pistas externas del disco. Eso sucedería automáticamente si usa un disco que está parcialmente lleno. Al mismo tiempo, si un disco se llena solo parcialmente, el movimiento promedio de la cabeza sería menor y el número de movimientos de la cabeza sería menor porque hay más datos por pista.
Eso es cierto si usa un solo disco o una unidad RAID.
Ahora, si está comparando discos de 100GB y 2000GB, puede estar seguro de que todo lo demás no es igual. Pero si el mismo fabricante ofrece unidades de 500GB, 1TB, 1.5TB y 2TB con uno, dos, tres y cuatro platos, entonces es probable que todo lo demás sea igual, y 10 x 500GB será más lento que 10 x 2TB para almacenar 4TB de datos (no habrá diferencia si almacena solo 100 GB, porque las unidades de 500 GB también estarán casi vacías).
Pero para las unidades RAID, no estará tan limitado por la velocidad de transferencia, sino por la latencia rotacional. Por lo tanto, mayores RPM serán más importantes. Y a menudo encontrará mayores RPM junto con menor capacidad. Por otro lado, si vas con altas RPM / baja capacidad, entonces también podrías mirar unidades SSD.
fuente