Estamos a punto de implementar el almacenamiento compartido en busca de almacenamiento ultrarrápido para implementar Microsoft SQL Server Failover Cluster (FCI). Hasta ahora, el proyecto continúa, comenzaríamos con 500K IOPS para bloques de 8k con un patrón de 70r / 30w. También nos gustaría tener la capacidad de aumentar el rendimiento de hasta 2 millones de IOPS (para el mismo patrón) en un año más o menos, debido a las crecientes expectativas del servidor SQL.
Para el propósito del proyecto, vamos a implementar un clúster de 4 nodos de Microsoft Storage Spaces Direct (S2D). En cuanto al hardware, ya tenemos 2x servidores en rack Dell R730xd con 2x E5-2697 y 512GB de RAM y estamos listos para obtener 2 más.
En cuanto al almacenamiento, Microsoft recomienda usar NVMe o NVMe + SSD para obtener el máximo rendimiento ( fuente ). Por lo tanto, después de algunas investigaciones, los SSD de Samsung son buenos. https://www.starwindsoftware.com/blog/benchmarking-samsung-nvme-ssd-960-evo-m-2 http://www.storagereview.com/samsung_960_pro_m2_nvme_ssd_review
La configuración que consideramos es la siguiente: 1x Samsung 960 EVO NVMe + 4x SSD Samsung PM863 por host S2D.
¿Puede la implementación de S2D usando Samsung 960 EVO NVMe y Samsung PM863 entregar 500k a SQL FCI?
EDITAR:
a) ¿no preguntaste algo similar el otro día? - Yo hice. Se publicó una nueva pregunta ya que el primer disparo estaba fuera de tema. El sujeto y el cuerpo cambian. La pregunta anterior será eliminada.
b) son unidades de consumo. La cuestión es encontrar la configuración de S2D que podría albergar 500k IOPS requeridas al inicio. ¿Qué configuración recomendarías?
c) ¿cómo planea conectarlos? No conozco un servidor con 5 ranuras M.2. Necesitamos saber esto. Solo se utilizará una unidad 1x M.2 por cada nodo. He corregido la configuración del almacenamiento compartido: 1x Samsung 960 EVO NVMe + 4x Samsung PM863 SATA SSD por host S2D.
d) ¿qué tipo de IOPS (tamaño y tipo)? - SQL FCI lee una carga de trabajo intensiva de 4k, 8k, 64k bloques. El rango de lecturas es 70-90% y escribe uno - 30-10%.
e) 500k a 2M es un rango muy amplio de variación de requisitos, ¿por qué un rango tan amplio? - Se espera que el rendimiento del proyecto crezca significativamente en el período de clasificación, por lo que debemos tener la capacidad de ejecutar 4 veces la carga de trabajo en el mismo hardware hasta el primer año. Un año después, agregaremos 4 veces más hosts al clúster.
Somos Microsoft Shop, por lo que no hay otra opción para ir a otra parte que Microsoft SQL Server 2016. Además, como puede consumir el proyecto, se requiere redundancia y disponibilidad adicional, por lo tanto, la instancia de clúster de conmutación por error SQL se implementará a un lado de S2D.
fuente
Respuestas:
Es una mala idea usar SSD de consumidor en sus implementaciones de SDS. VMware VSAN y Microsoft S2D asumen que las escrituras serán "atómicas", por lo que un ACK-ed por host está en la memoria persistente; Los SSD de los consumidores no tienen ninguna protección contra cortes de energía, por lo que PODRÍAN perder sus datos. Escribir resistencia también es muy diferente.
https://blogs.technet.microsoft.com/filecab/2016/11/18/dont-do-it-consumer-ssd/
https://blogs.vmware.com/vsphere/2013/12/virtual-san-hardware-guidance-part-1-solid-state-drives.html
http://www.yellow-bricks.com/2013/09/16/frequently-asked-questions-virtual-san-vsan/
Sugeriría seguir con algunas tarjetas NVMe de grado empresarial.
fuente