Estoy considerando un almacenamiento para correo electrónico. Este sistema de almacenamiento se ejecuta en mi propia nube privada (ya replicada), entonces no me importa la replicación.
Estoy pensando en 2 opciones:
1- Crearé algunos "discos" (volumen en la nube) y crearé un sistema de archivos Btrfs en discos múltiples; y cuando el sistema de archivos esté lleno, crearé más "disco" y lo agregaré al sistema de archivos btrfs de la siguiente manera:
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
Este punto de montaje (/mnt) se expondrá a través de NFS y mi servidor Dovecot montará esta exportación y almacenará los correos electrónicos en él.
2- Crearé algunos "discos" (volumen en la nube) y crearé un volumen distribuido GlusterFS entre estos discos; y cuando el sistema de archivos esté lleno, crearé más "discos" y agregaré nuevos "discos" al volumen distribuido de GlusterFS y lo reequilibraré. My Dovecote montará este volumen usando glusterfs-client y almacenará correos electrónicos en él.
(Repetir: no necesito replicar, porque mi "disco", volumen en la nube privada, se replica bajo el capó)
¿Crees que opción tiene mejor?
- ¿actuación? (muchas E/S pequeñas de lectura/escritura)
- ¿estable?
- ¿flexible?
Respuesta1
Debe considerar el patrón de E/S de un servidor de correo: lectura/escritura.muchosarchivos pequeños lo más rápido posible. Ambas variantes son realmente inadecuadas para esto cuando se trata de una gran cantidad de clientes, en mi humilde opinión.
Ninguno de los FS es lo suficientemente rápido y supongo que, especialmente, la sobrecarga de bloqueo de GlusterFS será significativa. Luego agregas otra capa con NFS, que tiene su propia sobrecarga. En lugar de esto, intentaría conectar el almacén de correo con la menor sobrecarga posible y con un sistema de archivos rápido. Por lo general, esto significa conectarse lo más directamente posible al almacenamiento físico, pero dado que oculta su arquitectura detrás de términos de bingo como "nube privada", no sabemos qué sería posible.
Un enfoque que podría probar sería exportar el almacenamiento a través de iSCSI al servidor de correo y luego usar un FS que sea rápido con muchos archivos pequeños y tal vez, si es realmente importante, usar LVM para poder agregar fácilmente espacio a ese FS en el forma de volúmenes iSCSI adicionales (lo que añade algo de sobrecarga).
Independientemente de lo que intentes, debes comparar las diferentes variantes y ver si obtienes el rendimiento requerido.
Respuesta2
Si necesita elegir uno de los dos anteriores, creo que es preferible NFS.
GlusterFS pierde todos sus beneficios como sistema de archivos distribuido en su configuración, ya que los volúmenes de OpenStack todavía se montan desde un almacenamiento central. No es ni más estable ni más inteligente, ya que debería preocuparse por el bloqueo de archivos distribuidos, mientras que el bloqueo NFS se realiza en un solo servidor.
No estoy seguro de que combinar el almacenamiento de varios dispositivos sea una buena idea. Alternativamente, puede considerar omitir la funcionalidad del servicio de volumen OpenStack de alto nivel y exponer su almacenamiento directamente: volumen LVM(/ZFS/SAN) formateado exportado por NFS. De esta manera eliminará el nivel iSCSI innecesario y podrá aumentar el espacio de almacenamiento de correo según demanda siempre que el almacenamiento principal tenga suficiente espacio libre.