Al especificar servidores, como (supongo) que muchos ingenieros que no son expertos en almacenamiento, generalmente lo haré de forma segura (y tal vez seré esclavo del marketing) al estandarizar un mínimo de unidades SAS de 10k (y por lo tanto son " Enterprise "-grade con un ciclo de trabajo 24x7, etc.) para datos de" sistema "(generalmente SO y, a veces, aplicaciones), y reserva el uso de unidades de 7.2k de línea media / cercana para el almacenamiento de datos que no son del sistema donde el rendimiento no es significativo factor. Todo esto supone que los discos de 2.5 "(SFF), ya que los discos de 3.5" (LFF) solo son realmente relevantes para los requisitos de alta capacidad y bajos IOP.
En situaciones donde no hay una gran cantidad de datos que no son del sistema, generalmente los colocaré en los mismos discos / matrices que los datos del sistema, lo que significa que el servidor solo tiene 10k unidades SAS (generalmente un tipo "One Big RAID10" de configuración en estos días). Solo si el tamaño de los datos que no son del sistema es significativo, por lo general, considero colocarlo en una matriz separada de 7.2k discos de línea media / cercana para mantener el costo / GB bajo.
Esto me ha llevado a preguntarme: en algunas situaciones, ¿podrían esos discos de 10k en la matriz RAID10 haber sido reemplazados por discos de 7.2k sin ninguna consecuencia negativa significativa? En otras palabras, ¿a veces estoy sobreespecificando (y manteniendo contentos a los vendedores de hardware) al apegarme a un mínimo de 10k discos de grado "empresarial", o hay una buena razón para mantenerlo siempre como mínimo?
Por ejemplo, tome un servidor que actúa como un hipervisor con un par de máquinas virtuales para una pequeña empresa típica (por ejemplo, 50 usuarios). La compañía tiene patrones promedio de E / S sin requisitos especiales. Típico 9-5, oficina de lunes a viernes, con copias de seguridad ejecutándose durante un par de horas por noche. Las máquinas virtuales tal vez podrían ser un DC y un servidor de archivos / impresión / aplicación. El servidor tiene una matriz RAID10 con 6 discos para almacenar todos los datos (datos del sistema y no del sistema). Para mi ojo no experto, parece que los discos de línea media / cercana pueden funcionar bien. Tomando discos HP como ejemplo:
- Carga de trabajo: los discos de la línea media están clasificados para <40% de carga de trabajo. Con la oficina abierta solo durante 9 horas al día y la E / S promedio durante ese período es poco probable que se acerque al máximo, parece que la carga de trabajo no superará el 40%. Incluso con un par de horas de E / S intensa por la noche para realizar copias de seguridad, supongo que aún estaría por debajo del 40%
- Velocidad: aunque los discos son solo 7.2k, el rendimiento mejora al distribuirlo en seis discos
Entonces, mi pregunta: ¿es sensato pegar un mínimo de unidades SAS de 10k, o los discos de línea media / línea cercana a 7.2k son realmente más que adecuados en muchas situaciones? Si es así, ¿cómo calculo dónde está la línea y evito ser un esclavo de la ignorancia jugando a lo seguro?
Mi experiencia es principalmente con servidores HP, por lo que lo anterior puede tener un poco de inclinación de HP, pero supongo que los principios son bastante independientes del proveedor.
Respuestas:
Aquí hay una interesante intersección del diseño del servidor, la tecnología de disco y la economía:
Ver también: ¿Por qué los discos de factor de forma grande (LFF) siguen siendo bastante frecuentes?
Por lo anterior, por lo general, se encuentran fabricantes que se centran en servidores 1U / 2U con compartimientos para unidades de disco de 8-24 2.5 ".
Los discos de 3.5 "son para casos de uso de alta capacidad de bajo IOPs (2TB +). Son los mejores para gabinetes de almacenamiento externo o almacenamiento SAN con alguna forma de almacenamiento en caché. En velocidades empresariales de 15k RPM, solo están disponibles hasta 600GB.
Los discos giratorios de 2.5 "y 10k RPM son para mayores necesidades de IOPS y generalmente están disponibles hasta 1.8TB de capacidad.
Los discos giratorios de 2.5 "7.2k RPM son una mala decisión porque no ofrecen capacidad, rendimiento, longevidad ni ventajas de precio. Por ejemplo, el costo de una unidad SAS 10k de 900GB es muy cercano al de un SAS SAS de 1TB 7.2k RPM. Dado el pequeño precio diferencia, la unidad de 900GB es la mejor compra. En el ejemplo de 1.8TB 10k SAS versus 2.0TB 7.2k SAS , los precios también están muy cerca. Las garantías son de 3 años y 1 año, respectivamente.
Entonces, para servidores y almacenamiento interno de 2.5 ", use SSD o 10k. Si necesita necesidades de capacidad y tiene bahías de unidades de 3.5" disponibles interna o externamente, use 7.2k RPM.
Para los casos de uso que ha descrito, no está configurando en exceso los servidores. Si tienen bahías de unidades de 2.5 ", realmente debería usar solo 10k SAS o SSD. Los discos de la línea media son una pérdida de rendimiento, capacidad, tienen una garantía significativamente más corta y no ahorrarán mucho en costos.
fuente
Hay al menos algunas cosas que podrían causar problemas con ALGUNOS tipos de unidades:
Unidades que no están destinadas a manejar la carga de vibración de un chasis que tiene muchas unidades (problema poco probable con cualquier unidad especificada como compatible con RAID / NAS)
Firmware que no permite TLER, o necesita una reconfiguración manual de la unidad que requiere mucho tiempo para habilitarlo (ídem)
Unidades que nunca se han probado con el controlador RAID utilizado, y que podrían tener errores no reconocidos que aparecen en dicha configuración
Cachés de escritura de unidad interna que se comportan de una manera (la escritura física está fuera de servicio o muy retrasada) que causa mucha confusión en caso de un apagado forzado (el controlador RAID debe configurarse para forzarlos a APAGAR. Problema potencial si el firmware alguna vez debe ignorarse eso. Ver unidades no probadas :)
La unidad puede realizar rutinas de mantenimiento interno ocasionalmente que podrían hacer que la unidad se comporte lentamente o responda con suficiente retraso, para hacer que el controlador RAID piense que falló (relacionado con TLER)
SATA en general, como generalmente se implementa, tiene menos salvaguardas en comparación con SAS contra un disco con dispositivos electrónicos completamente disparados o colgados que cuelgan todo en el controlador (no es un riesgo teórico, ciertas combinaciones de marca de disco + controlador adoran ese modo de falla).
fuente
ENORME problema:
(Puede ser un poco fuera de tema, ¡pero soy importante! )
Cuando se trata de unidades de estado sólido (como suele ser el caso, o puede ser el caso o la tentación), muchas unidades de estado sólido tienen un problema desagradable en el que no siempre pueden recuperarse de cortes de energía espontáneos.
Este es un pequeño problema con los discos duros. Los discos duros generalmente tienen suficiente capacidad para alimentar su lógica y suficiente impulso angular para llevar los platos al terminar de escribir un bloque de 512 bytes, en el caso de que se pierda la potencia a mitad de la escritura. Una vez en una rara tiempo, esto hará que no trabajo, lo que resulta en algo que se llama una "escritura incompleta" - donde un solo bloque puede estar parcialmente escrito. La escritura parcial (albiet raro) causará una falla de suma de verificación en el bloque, es decir, ese bloque individual será malo. Por lo general, esto puede ser detectado como malo por la circuitería del disco y corregido por el controlador RAID ascendente.
Los SSD son un animal diferente. Por lo general, implementan algo llamado "nivelación de desgaste", donde no solo escriben "bloque X" en una ubicación física para "bloque X" como lo hace un HDD. En su lugar, intentan escribir en diferentes lugares en los medios flash, e intentan agregar o combinar escrituras (utilizando un poco de almacenamiento en búfer). Escribir en los diferentes lugares implica mantener un "mapa" de donde se escriben las cosas, que también se guarda y se escribe de una manera destinada a reducir la nivelación del desgaste. Parte de la nivelación del desgaste incluso puede implicar mover datos que ya están en el dispositivo y que ni siquiera se han escrito recientemente.
Este problema es que cuando el SSD pierde energía, tiene muchos datos en la memoria (no vaciados), tiene algunos datos que se han escrito en ubicaciones diferentes / cambiadas, y tiene estos mapas en su propia memoria que deben ser guardados. enjuagado para dar sentido a la estructura de todos los datos en el dispositivo.
MUCHOS SSD no tienen la lógica o los circuitos para poder mantener sus controladores en funcionamiento el tiempo suficiente durante el apagado espontáneo para eliminar todos estos datos de forma segura antes de que mueran. Esto no solo significa que ese bloque que escribió ahora podría estar en peligro, sino otros bloques, incluso todos los bloques en el dispositivo podrían estar en problemas. Muchos dispositivos también tienen problemas en los que no solo pierden todos los datos del dispositivo, sino que el dispositivo en sí mismo se vuelve bloqueado e inutilizable.
Toda esta es una teoría verdadera, pero (trabajando en la industria del almacenamiento), he visto / sucedido esto muchas veces en demasiados dispositivos, ¡incluso en algunas de nuestras propias computadoras portátiles personales!
Muchos proveedores han discutido la creación de "SSD de grado empresarial" donde se agregan específicamente los dispositivos ("super-caps") y otros circuitos para permitir un "vaciado" limpio, pero es muy muy difícil encontrar cualquier dispositivo que indique específicamente como parte de su Hoja de datos de que tiene protección suficiente, explícita y probada contra tales eventos y protegerá contra tales eventos.
Obviamente, si compra una "matriz de almacenamiento de alta gama" de un proveedor de primer nivel que utilizó tecnología flash, ya sea sus unidades, o su sistema en general se han diseñado teniendo en cuenta todo esto. ¡Asegúrate de que lo haya!
El problema con respecto a su pregunta es: si tiene una matriz RAID, y varios de los discos son SSD "defectuosos" sin esta protección, si obtiene un "corte de energía espontáneo", podría perder TODOS los datos en MÚLTIPLES discos haciendo imposible la reconstrucción RAID.
También es generalmente importante tener en cuenta que el "corte de energía espontáneo" puede incluir situaciones como BSOD y bloqueos / bloqueos / pánicos del kernel, en los que no tiene la opción de recuperarse para desconectar el sistema.
fuente