¿Está ejecutando un nodo de paridad completo con discos SSD en una configuración RAID 10?

TLDR; probablemente solo quiera ahorrar algo de dinero reemplazando/agregando un solo SSD a su matriz en lugar de ejecutarlo en RAID 10.

Con un nivel de duplicación lo suficientemente alto y una caché de disco lo suficientemente grande, probablemente podría sincronizar la cadena de bloques de Ethereum en un HDD, pero un SSD funcionará debido a la baja latencia de las búsquedas aleatorias; no hay necesidad de poner SSD en RAID.

No ha mencionado si está haciendo RAID por software o hardware, pero en cualquier caso, supongo que su sistema es más que capaz de manejar RAID 10 sin ningún efecto negativo en la sincronización si solo se reduce al uso de RAID. sí mismo.

¿Verá más desgaste? Sí: está escribiendo el doble de datos debido a la parte reflejada de su RAID 10 (la parte de RAID 1). Por lo tanto, es un aumento de al menos (y cerca de) un factor de dos. Pero el desgaste se distribuye en cuatro discos, por lo que creo que vería una expectativa de vida útil por disco de aproximadamente el doble de lo que vería en una configuración RAID 1 o JBOD (es decir, tendrá que cambiar menos de discos por desgaste); OTOH, al ritmo actual, probablemente llevará mucho tiempo desgastar los discos (del orden de años/décadas, si no más, para alcanzar la cantidad de ciclos de escritura para los que están clasificados incluso los SSD más bajos).

Por lo tanto, la respuesta a si su configuración descrita funcionaría es sí. Pero tengo una pregunta diferente: ¿por qué estás pensando en RAID10? (Asumiré una matriz de 2x2) ¿Es porque necesita/quiere RAID 10 para algún otro propósito? La única razón por la que puedo pensar en necesitar RAID 10 es porque tal vez planee volver a instalar un grupo existente para cambiar a SSD sin tiempo de inactividad (si está en ZFS, probablemente haya mejores formas de evitar esto). He aquí por qué creo que RAID 1 es más adecuado que RAID 10 para esta actualización: si tiene una franja RAID (RAID 0), supongo que esto es para aumentar su rendimiento de lectura y/o latencia y/o total direccionable capacidad y ya está satisfaciendo sus necesidades. Pero un SSD no particularmente rápido puede brindarle más del doble de rendimientoque un disco duro y, por lo tanto, proporciona al menos tanto rendimiento como un volumen de disco duro seccionado. También le brinda muchas más IOP que un volumen HDD seccionado de 2 discos (dos o más órdenes de magnitud). Debido a que Ethereum es esencialmente una base de datos gigante en la que hay muchas lecturas/escrituras, la baja latencia de acceso al disco de los SSD brinda una ENORME ventaja en términos de velocidad de sincronización de blockchain. A menos que necesite RAID sus SSD para lograr la capacidad de un solo volumen que necesita, puede ahorrar su dinero y omitir la creación de bandas en sus SSD.

También creo que debería omitir la duplicación de este disco, a menos que planee mantener otras cosas además de la cadena de bloques o desee lograr un mayor tiempo de actividad debido a la redundancia en línea (por ejemplo, en un entorno de servidor de producción). Asumiría que en realidad desearía redundancia a nivel de nodo en una configuración de alta disponibilidad de todos modos, por lo que, de todos modos, la duplicación de disco no abordaría por completo la alta disponibilidad. Siempre puede volver a sincronizar la cadena de bloques si/cuando su disco se estropea, sin pérdida real de datos (supongo que hace una copia de seguridad de sus claves por separado, ¡la redundancia no es una copia de seguridad y las copias no probadas no son copias de seguridad!). Para reducir el tiempo de sincronización, si sus volúmenes/discos admiten la creación de instantáneas, siempre puede realizar una instantánea y volcar sus datos en un medio de menor costo como sus HDD existentes. Luego, una restauración es tan simple como restaurar desde las instantáneas y solo necesita hacer una resincronización parcial. En este caso, la ventaja de los IOP de los SSD es discutible: solo necesita rendimiento para restaurar su copia de seguridad que sus HDD proporcionan más que suficiente. ÉlLa cadena de bloques completa de Ethereum (en lugar de sincronizaciones podadas) tiene aproximadamente 350 GB en este momento. Podría restaurar esa cantidad de datos a un SSD desde un solo disco duro en menos de una hora (suponiendo una velocidad de transferencia de disco duro de 120 MB/s). Así que... ¡tampoco hay necesidad de duplicar!

Dicho esto, uno de mis nodos Ethereum se ejecuta en un volumen ZFS RAID1 de 2x512GiB compuesto por SSD. Esto se debe a que planeo colocar otros datos que necesitan baja latencia en esos discos en algún momento posterior (en este momento, los discos están casi vacíos). En lugar de dedicar un disco no redundante a la tarea, utilicé el volumen duplicado porque me quedé sin bahías de disco intercambiables en caliente y no quería "desperdiciar" una bahía. Por lo tanto, puedo ver varios casos de uso para RAID10 u otros niveles de RAID que se usan para la cadena de bloques; simplemente no creo que haya tantos. Espero haberte ahorrado algo de $$$ :)

Más datos de rendimiento con Parity/v1.7.7-stable-eb7c648-20171015/x86_64-macos/rustc1.20.0: acabo de realizar una nueva sincronización en modo podado (que debería generar al menos tanta E/S como el modo de archivo) en una unidad NVMe; son solo 256 GiB, por lo que no podría hacer una prueba de archivo si quisiera. Mi conexión de red es ~200Mbps arriba y abajo. La paridad parece ser mucho más intensiva en lectura de IOPS que en escritura, pero hace aproximadamente el doble de escritura en términos de volumen de datos, por lo que RAID1 parece proporcionar más beneficios de rendimiento que RAID0. Además, solo veo 5-10k IOPS (<5 % de utilización) y un rendimiento de 200 MB/s. y, por lo tanto, parece estar limitado por la CPU: ~ 2 núcleos al máximo en un i7 6700HQ (2016 15 "MBP). El proceso tomó 2h29m.