bcache en md o md en bcache

11

bcache permite que una o más unidades de disco rápidas, como las unidades de estado sólido (SSD) basadas en flash, actúen como caché para una o más unidades de disco duro más lentas .

Si entiendo correctamente,

  • un SSD * podría asignarse a la caché de múltiples HDD de respaldo, y luego los dispositivos en caché resultantes podrían RAIDizarse con mdadm
    o
  • múltiples discos duros se podrían RAIDAR en un solo dispositivo de respaldo md y el SSD asignado a la caché que

Me pregunto cuál es el enfoque más sano. Se me ocurre que cultivar un RAID5 / 6 puede ser más simple con una u otra técnica, ¡pero no estoy seguro de cuál!

¿Existen buenas razones (por ejemplo, aumentar el almacenamiento de respaldo o cualquier otra cosa) para elegir un enfoque sobre el otro (para un gran sistema de archivos no root que contiene archivos de respaldo de VM)?

* por "un SSD" me refiero a algún tipo de dispositivo SSD redundante, por ejemplo, un RAID1 de dos SSD físicos

linux ssd block-device bcache
fuente
En cualquier caso, todos los discos con bcachecopias de seguridad tendrán que formatearse bcache, por lo que tendrá que crear una mdmatriz, formatear el único disco resultante completamente como una bcachepartición respaldada, vincularlo a su unidad de caché e ir desde allí, o formatear muchos discos con bcache, vincúlelos a su unidad de caché, luego formatee los muchos discos como una matriz. En cualquier caso, existen múltiples puntos de posible falla, todos los cuales dependen de la interoperabilidad entre dos sistemas de archivos, sin mencionar los fs finales. ver aquí : desplazarse hacia abajo .
mikeserv
Gracias a github.com/g2p/blocks , puede convertirlo en el lugar, aunque existen algunas limitaciones.
Adam Ryczkowski
@mikeserv Entiendo todo eso, esto es para un servidor especialmente diseñado, así que todo está bien. ¿Qué quiere decir "dos sistemas de archivos"? bcache no es un sistema de archivos: el único sistema de archivos que tendré será XFS en el dispositivo bcache o mdadm final (dependiendo de la opción que elija).
Gracias @ Adam, la conversión in situ no es un problema para mí.
@mikeserv no, no lo es. Los sistemas de archivos (por ejemplo, btrfs, xfs, extN, etc.) viven en la parte superior de los dispositivos de bloque. mdadm y bcache funcionan en el nivel del dispositivo de bloque, no en el nivel del sistema de archivos (btrfs confunde el problema con su violación de capas, pero esa es una conversación completamente separada).

Respuestas:

4

Creo que el almacenamiento en caché de todo el dispositivo MD tiene más sentido.

Poner bcache en la memoria caché de todo el dispositivo md sacrifica la idea de tener una incursión, porque introduce otro punto único de falla.

  • Los fallos OTH de los discos SSD son relativamente raros, y bcache se puede poner en el modo writethrough/ writearound(en contraste con el writebackmodo), donde no hay datos almacenados solo en el dispositivo de caché, y el fallo del caché no mata la información en La redada la convierte en una opción relativamente segura.

  • Otro hecho es que hay una sobrecarga computacional significativa de RAID-5 suave; Al almacenar en caché cada miembro de la banda giratoria por separado, la computadora aún tiene que volver a calcular todas las paridades, incluso en los aciertos de caché

  • Obviamente, sacrificaría un espacio ssd costoso, si almacena en caché cada unidad giratoria por separado. - A menos que planee usar caché ssd con incursiones.

  • Ambas opciones relativamente no afectan el tiempo del proceso de crecimiento, aunque la opción con unidades giratorias que se almacenan en caché por separado tiene el potencial de ser más lenta debido al mayor tráfico de autobuses.

Es un proceso rápido y relativamente simple configurar bcache para eliminar el disco ssd, cuando necesita reemplazarlo. Gracias a los bloques , debería ser posible migrar la configuración de incursión en ambos sentidos in situ.

También debe recordar, que por el momento la mayoría (todos?) Distribuciones-CD en vivo no son compatiblesbcache , por lo que no se puede simplemente tener acceso a sus datos con este tipo de herramientas, independientemente de la bcache- mdraidopción de diseño que ha elegido.

Adam Ryczkowski
fuente
1
He actualizado la pregunta para que quede claro que no planeo tener un caché SSD no redundante. Su segundo punto es un punto excelente, gracias por eso. Su tercera viñeta sobre el espacio: ¿quiere decir porque estaría almacenando la paridad en SSD? re su último parámetro, estoy usando F20 pero eventualmente usaré RHEL / CentOS7 o Debian Jessie (si bcache-tools hace el corte).
@JackDouglas Ad 3rd bullet: Sí, exactamente eso. Pero dado que planea usar unidades ssd con incursiones, eso no se aplica a usted.
Adam Ryczkowski
1
Todavía lo hace porque no solo se reflejarán, sino que también deberán almacenar la paridad RAID para las unidades de respaldo. Este no es el caso si el RAID se realiza debajo de bcache, que pensé que era su punto
Creo que quiere decir lo contrario: la matriz ssd no tiene que almacenar la paridad de los discos giratorios, si se alimenta a toda la unidad mdraid.
Adam Ryczkowski
1
sí, eso es exactamente lo que quiero decir!
1

Creo que el enfoque sensato es almacenar en caché el dispositivo MD resultante.

bcache está diseñado para pasar lecturas y escrituras secuenciales.

Si almacena en caché cada dispositivo por separado, lógicamente, varios dispositivos que se insertan en un MD incrustado o despojado, desde la perspectiva de bcache, escribirán constantemente bloques al azar.

Si bien un volumen de MD en caché se verá normal, escribir archivos en el volumen, en lugar de bloques aleatorios en varios dispositivos.

El objetivo principal de la incursión dura y de software es hacer la división de datos en el backend para que el sistema de archivos resultante se vea como un volumen normal.

Es posible que esto no sea correcto (ya que los desarrolladores de bcache pueden ser inteligentes y dar cuenta de ese tipo de situación), pero lo más lógico es hacer caché de volúmenes, en lugar de bloquear dispositivos.

enlightnd
fuente
también es un muy buen punto
Una escritura secuencial grande en un RAID5 / 6 produce escrituras secuenciales en todos los dispositivos componentes. Cada dispositivo componente obtiene cada bloque de datos N-1 (o paridad), pero los datos que obtiene son secuenciales. Pero tienes razón en que distorsionará las cosas. Si hay algunos fragmentos que ven escrituras frecuentes de franjas parciales, lo que resulta en una lectura-modificación-escritura de (parte de) la franja de paridad, eso podría ser almacenado en caché por bcache. Sin embargo, el almacenamiento en caché más arriba, antes de que la escritura de franja parcial llegue al dispositivo MD, sería aún mejor.
Peter Cordes