El Problema
Las personas estaban pidiendo un mecanismo seguro para intercambiar archivos. Hoy estamos orgullosos de anunciar el nuevo módulo de servidor de archivos de código abierto. Como el componente más nuevo en el ecosistema de Psono, resuelve múltiples problemas:
- Los archivos compartidos por correo se vuelven demasiado grandes. Normalmente, todo lo que supera los 20 MB es rechazado.
- Cargar archivos a otras partes por SFTP, correos GPG, etc. es demasiado complejo para los usuarios normales.
- Cargar archivos con la ayuda de Google Drive o Dropbox puede ser problemático para datos sensibles.
- Protección de información de RRHH o de administración de empleados internos, por ejemplo, administradores del servidor de archivos.
- Hacker que obtiene acceso a tu servidor de archivos.
- Problemas de ancho de banda cuando trabajas en un entorno de oficina remota y todos están descargando desde tu pequeño servidor de archivos de oficina.
Y ahí es donde entra Psono. Psono fue diseñado teniendo en cuenta todos esos problemas y es extremadamente flexible.
La Usabilidad
Ok, entonces, ¿cómo se ve para el usuario preguntarás? Sencillo.
- Un usuario accede al cliente web.
- selecciona el archivo.
- hace clic en el botón "cargar".
- ... y si quiere lo comparte con un clic derecho.
Eso es lo suficientemente simple, espero.
Bajo el capó
Bajo el capó, el cliente realiza algunos pasos más complejos, pero todos están ocultos para el usuario:
- El cliente le pide al servidor todos los servidores de archivos disponibles.
- El servidor evalúa la solicitud y decide, según varios atributos del usuario (permisos, IP, derechos de acceso), qué fragmentos (ubicaciones de archivos) y servidores de archivos son adecuados.
- El servidor crea un ticket de carga de archivo.
- El cliente lee el tamaño del archivo.
- El cliente anuncia la carga del archivo y el fragmento al servidor.
- El cliente divide el archivo en fragmentos de un máximo de 128 MB si el archivo es demasiado grande.
- El cliente cifra el fragmento.
- El cliente calcula la suma de verificación del fragmento.
- El cliente carga el fragmento al servidor de archivos junto con el ticket de carga de archivo.
- El servidor de archivos envía el ticket de carga al servidor.
- El servidor valida el ticket.
- El servidor de archivos acepta la carga del fragmento.
- El cliente continúa con el siguiente fragmento hasta que todos los fragmentos estén procesados.
- El cliente actualiza su almacén de datos, lo cifra y lo envía al servidor.
Con este mecanismo podemos solucionar cualquier problema de tamaño de archivo, ya que los archivos se dividen en fragmentos. Podemos distribuir las cargas a través de servidores incluso para un solo archivo. Todos los archivos están (como todo lo demás en Psono) cifrados antes de salir del cliente y llegar al servidor.
Configuración típica del servidor de archivos Psono
La parte superior muestra una configuración típica. Un servidor de retransmisión (un proxy inverso simple) sirve algunos archivos estáticos (el cliente web). El cliente web se sirve al navegador, que luego llama a puntos finales de la API REST en el servidor. El servidor utiliza una base de datos Postgres para almacenar todos los datos persistentes. El cliente web Psono y el servidor Psono se pueden considerar sin estado, todos los datos se almacenan en la base de datos Postgres.
Si quieres adjuntar ahora un servidor de archivos, primero tienes que crear una configuración de fragmento y clúster en el servidor, que luego puedes tomar para configurar el servidor de archivos real. Una vez que el servidor de archivos arranca, se registrará automáticamente y continuará anunciando su disponibilidad en intervalos de 10 segundos. Si un servidor de archivos muere, el servidor reconocerá esto y dejará de enviar clientes al servidor muerto. Una vez que vuelva, se registrará automáticamente y comenzará a recibir solicitudes de clientes. En la imagen de arriba, estamos almacenando todos los fragmentos en almacenamiento local y tenemos un servidor de retransmisión (podría ser el mismo que para el servidor normal, cliente web en entornos pequeños) para la descarga de SSL.
Además del almacenamiento local, puedes usar varios backend de almacenamiento e incluso mezclarlos.
Mezcla de varios backend de almacenamiento
Actualmente se admiten (además del almacenamiento local) Amazon S3, GCP Cloud Storage y Azure Blob Storage.
Puedes usar varios servidores de archivos para resolver, por ejemplo, problemas de rendimiento debido a una limitación de ancho de banda. Podrías tener personas trabajando de forma remota pero solo con una conexión a Internet muy delgada en tu oficina. Otro caso de uso podría ser que quieras proteger aún mejor los archivos locales y
- no permitir que los archivos internos se carguen en un almacenamiento externo.
- permitir que los externos compartan archivos con los internos sin una herramienta diferente.
Una configuración que resuelve el problema de rendimiento y te brinda un mejor aislamiento podría verse así:
Ubicación remota
Esta configuración comparte todo el tráfico del fragmento "externo" entre sitios de manera bidireccional, permitiendo que los externos carguen archivos que luego pueden ser descargados por los empleados y viceversa.
El fragmento en las instalaciones, por otro lado, nunca se sincroniza con la ubicación remota y se mantiene mejor protegido. Como los archivos en el fragmento "externo" solo se sincronizan una vez, cada vez que cambian podrías tener 100 empleados accediendo al archivo desde este fragmento sin la necesidad de descargarlo 100 veces desde la ubicación remota. O si subes un archivo, puedes compartirlo con 100 externos, sin la necesidad de subirlo 100 veces.
La ventaja de ancho de banda también se puede utilizar para conectar ubicaciones remotas con una configuración similar a esta:
Con dos oficinas remotas
En esta configuración, cada sitio tiene su propio servidor de archivos, y todos los archivos se comparten entre los sitios. Las escrituras solo van a un fragmento específico, lo que permite una sincronización unidireccional de cada fragmento. Esta configuración permitiría a las personas en Nueva York acceder a archivos sin demora.
El siguiente punto importante es el equilibrio de carga. Todo esto es agradable si solo tienes unos pocos empleados que no saturan tu ancho de banda. Si tienes 1000 empleados, todos accediendo regularmente al servidor de archivos, esto producirá limitaciones de ancho de banda para un solo servidor. Afortunadamente, Psono puede manejar esto. Aquí hay dos opciones que ofrece el servidor de archivos de Psono para el equilibrio de carga.
Es posible que ya tengas un balanceador de carga que te gustaría usar, entonces tu configuración podría verse así:
Servidor de archivos con balanceo de carga y balanceador
En esta configuración se utiliza un balanceador de carga para descargar SSL. Dos servidores de archivos detrás son utilizados para manejar las solicitudes reales. Ambos anuncian el mismo fragmento, por lo que deben sincronizar el fragmento o tener algún almacenamiento compartido. Se podría usar GlusterFS o un simple rsync.
La alternativa sería permitir que el cliente equilibre todo y ahorrar algo de configuración y costos. Una configuración sin un balanceador de carga adicional podría verse así:
Servidor de archivos con balanceo de carga sin balanceador
Todas estas configuraciones pueden apilarse, p. ej., 3 clústeres de 2 servidores cada uno. Con cada clúster sirviendo el mismo fragmento y con un almacenamiento sincronizado (o compartido) debajo.
Espero haber podido darte una buena impresión sobre las capacidades del nuevo y poderoso módulo de servidor de archivos de Psono.
