O Problema
As pessoas estavam pedindo um mecanismo seguro para trocar arquivos. Hoje estamos orgulhosos de anunciar o novo módulo de servidor de arquivos open source. Como o mais novo componente do ecossistema Psono, ele resolve vários problemas:
- Arquivos compartilhados por e-mail se tornam muito grandes. Normalmente, tudo acima de 20mb é rejeitado.
- O upload de arquivos para outras partes por SFTP, e-mails GPG, etc., é muito complexo para usuários comuns.
- O upload de arquivos com a ajuda do Google Drive ou Dropbox pode ser problemático para dados sensíveis.
- Proteção de informações de RH ou gestão de funcionários internos, por exemplo, administradores de servidor de arquivos.
- Hacker ganhando acesso ao seu servidor de arquivos.
- Problemas de largura de banda quando você trabalha em um ambiente de escritório remoto e todos estão baixando do seu pequeno servidor de arquivos do escritório.
É aí que o Psono entra em cena. O Psono foi projetado com todos esses problemas em mente e é extremamente flexível.
A Usabilidade.
Ok, então como isso é para o usuário, você pergunta. Simples.
- Um usuário acessa o cliente web.
- Seleciona o arquivo.
- Clica no botão "upload".
- ... e se ele quiser, compartilha com um clique direito.
Espero que seja simples o suficiente.
Por baixo do capô
Por baixo do capô, o cliente realiza algumas etapas mais complexas, mas todas elas são ocultas do usuário:
- O cliente solicita ao servidor todos os servidores de arquivos disponíveis.
- O servidor avalia a solicitação e decide, de acordo com vários atributos do usuário (permissões, IP, direitos de acesso), quais shards (localizações de arquivos) e servidores de arquivos são adequados.
- O servidor cria um ticket de upload de arquivo.
- O cliente lê o tamanho do arquivo.
- O cliente anuncia o upload do arquivo e do shard para o servidor.
- O cliente divide o arquivo em pedaços de no máximo 128mb se o arquivo for muito grande.
- O cliente criptografa o pedaço.
- O cliente calcula o checksum do pedaço.
- O cliente faz upload do pedaço para o servidor de arquivos junto com o ticket de upload de arquivo.
- O servidor de arquivos envia o ticket de upload para o servidor.
- O servidor valida o ticket.
- O servidor de arquivos aceita o upload do pedaço.
- O cliente continua com o próximo pedaço até que todos os pedaços sejam processados.
- O cliente atualiza seu banco de dados, criptografa-o e envia para o servidor.
Com este mecanismo, podemos resolver qualquer problema de tamanho de arquivo, pois os arquivos são divididos em pedaços. Podemos distribuir uploads por servidores, mesmo para um único arquivo. Todos os arquivos são (como tudo no Psono) criptografados antes de sair do cliente e são enviados para o servidor.
Configuração típica do Psono Fileserver
A parte superior mostra uma configuração típica. Um servidor de relay (um simples proxy reverso) serve alguns arquivos estáticos (o cliente web). O cliente web é servido ao navegador, que então chama endpoints da API REST no servidor. O servidor usa um banco de dados Postgres para armazenar todos os dados persistentes. O Cliente Web Psono e o Servidor Psono podem ser considerados sem estado, todos os dados são armazenados no banco de dados Postgres.
Se você quiser anexar agora um servidor de arquivos, primeiro você deve criar uma configuração de shard e cluster no servidor, que você pode então usar para configurar o servidor de arquivos real. Uma vez que o servidor de arquivos inicia, ele se registrará automaticamente e continuará a anunciar sua disponibilidade em intervalos de 10 segundos. Se um servidor de arquivos morrer, o servidor reconhecerá isso e parará de enviar clientes para o servidor morto. Uma vez que ele voltar, ele se registrará automaticamente novamente e começará a receber solicitações dos clientes. Na imagem acima, estamos armazenando todos os pedaços em armazenamento local e temos um servidor de relay (poderia ser o mesmo para o servidor normal, cliente web em ambientes pequenos) para o descarregamento de SSL.
Além do armazenamento local, você pode usar vários backends de armazenamento e até mesmo misturá-los.
Mistura de vários backends de armazenamento
Atualmente suportados (ao lado do armazenamento local) são Amazon S3, GCP Cloud Storage e Azure Blob Storage.
Você pode usar vários servidores de arquivos para resolver, por exemplo, problemas de desempenho devido a uma limitação de largura de banda. Você poderia ter pessoas trabalhando remotamente, mas apenas uma conexão de internet muito fina no seu escritório. Outro caso de uso poderia ser que você deseja proteger ainda melhor os arquivos locais e
- não permitir que arquivos internos sejam carregados para um armazenamento externo.
- permitir que externos compartilhem arquivos com internos sem uma ferramenta diferente.
Uma configuração que resolve o problema de desempenho e oferece um melhor isolamento pode parecer assim:
Localização remota
Esta configuração compartilha todo o tráfego do shard "externo" entre os sites de forma bidirecional, permitindo que externos carreguem arquivos que, depois, podem ser baixados por funcionários e vice-versa.
Por outro lado, o shard on-premise nunca é sincronizado com a localização remota e permanece melhor protegido. Como os arquivos no shard "externo" são sincronizados apenas uma vez, sempre que mudam, você pode ter 100 funcionários acessando o arquivo deste shard sem a necessidade de baixá-lo 100 vezes da localização remota. Ou se você carregar um arquivo, pode compartilhá-lo com 100 externos, sem a necessidade de fazer o upload 100 vezes.
A vantagem de largura de banda também pode ser usada para conectar locais remotos com uma configuração semelhante a esta:
Com dois escritórios remotos
Nesta configuração, cada local tem seu próprio servidor de arquivos, e todos os arquivos são compartilhados entre os sites. As gravações vão apenas para um shard específico, o que permite uma sincronização unidirecional de cada shard. Esta configuração permitiria que pessoas em Nova York acessassem arquivos sem nenhum atraso.
O próximo grande ponto é o balanceamento de carga. Tudo isso é bom se você tiver apenas alguns funcionários que não saturam sua largura de banda. Se você tiver 1000 funcionários, todos acessando o servidor de arquivos regularmente, isso produzirá limites de largura de banda para um único servidor. Mas, felizmente, o Psono pode lidar com isso. Aqui estão duas opções oferecidas pelo servidor de arquivos do Psono para balanceamento de carga.
Você pode já ter um balanceador de carga que gostaria de usar, então sua configuração pode parecer assim:
Servidor de arquivos balanceado com balanceador de carga
Nesta configuração, um balanceador de carga é usado para o descarregamento de SSL. Dois servidores de arquivos sentados atrás são usados para lidar com as solicitações reais. Ambos anunciam o mesmo shard, então eles precisam sincronizar o shard ou ter algum armazenamento compartilhado. Pode-se usar GlusterFS ou um simples rsync.
A alternativa seria permitir que o cliente balanceasse tudo e economizasse uma configuração e custos. Uma configuração sem um balanceador de carga extra poderia parecer assim:
Servidor de arquivos balanceado sem balanceador de carga
Todas essas configurações podem ser empilhadas, por ex., 3 clusters de 2 servidores cada. Com cada cluster servindo o mesmo shard e tendo um armazenamento sincronizado (ou compartilhado) por baixo,
Espero que eu tenha conseguido dar uma boa impressão sobre as capacidades do novo e poderoso módulo de servidor de arquivos do Psono.
