Experiência com o CVS em um sistema de arquivos em cluster

Question

Eu estaria interessado em qualquer experiência usando o CVS em um sistema de arquivos em cluster com vários servidores acessando-o. Eu acho que isso é semelhante ao que provedores como o SourceForge fazem.

Atualmente, usamos um servidor CVS baseado em RHEL com um sistema de arquivos do repositório ext3 em uma SAN.

A idéia é usar várias máquinas para lidar com conexões CVS de clientes, todos trabalhando no mesmo sistema de arquivos em uma SAN rápida. Essa redundância poderia servir tanto para fins de balanceamento de carga quanto de failover (usando, por exemplo, um DNS round-robin que poderia ser reconfigurado se um dos servidores falhasse).

O SVN não é uma alternativa por várias razões, por favor, não inicie uma discussão CVS / SVN.

    

Answer 1

A melhor resposta para os problemas de dimensionamento do VCS é a que você deu na sua pergunta. Não use o CVS. Eu concordo com você, porém, o SVN é a solução para os problemas de ninguém. Há muitos sistemas de controle de versão altamente escaláveis por aí (Perforce, Rational são exemplos).

Eu acho que, em geral, você vai descobrir que os sistemas de arquivos em cluster não irão fornecer o desempenho que você está procurando, seus principais objetivos são a disponibilidade. Se você precisa escolher qualquer FS em cluster, então eu acho que você precisa olhar para algo como link que é construído para alta performance agrupamento de banco de dados. Os bancos de dados de alta performance, no entanto, não dependem de mecanismos de bloqueio de arquivos semelhantes ou flock, como o CVS faz, simplesmente não é dimensionável. Você precisaria adicionar algum tipo de gerenciador de bloqueio distribuído transacional. O CVS e o alto desempenho simplesmente não cabem no mesmo cenário.

Eu tenho a sensação de que você não está tentando escalar seu sistema de controle de origem e está tentando usar o CVS para algo específico de aplicativo. Nesse caso, sugiro codificar diretamente para o RCS e rolar seu próprio gerenciador de bloqueio. Evitaria a complicação e os custos dos sistemas de arquivos distribuídos ou em cluster e se concentraria em criar um aplicativo mais inteligente usando algum tipo de abordagem de bucket de hash distribuído.

    

Answer 2

Entre o seu san e as máquinas que executam o CVS você vai precisar de algum tipo de sistema de arquivos em rede (pelo menos, não consigo pensar em nenhum sistema de arquivos que lida com acesso simultâneo ao mesmo dispositivo, e estou assumindo que por SAN você quer dizer armazenamento apresentado ao servidor / SO como um dispositivo de armazenamento). Há alguns anos houve uma discussão sobre o CVS sobre o NFS , e você provavelmente encontrará os mesmos tipos / semelhantes de problemas com qualquer sistema de arquivos de rede.

• Você quer um sistema de arquivos em rede que lide bem com os bloqueios
• O ideal é que você também queira um sistema de arquivos em rede que lide com a coerência do cache do sistema de arquivos entre seus front ends do CVS

Agora, eu não sei exatamente como o sourceforge está estruturado para o CVS, no entanto, meu palpite seria algo como:

• Um pequeno número de caixas que permitem commits de CVS, isto é possivelmente particionado de tal forma que um projeto é associado a uma caixa / sistema de arquivos onde eles fazem seus commits.
• O estado das caixas de confirmação do CVS é então replicado para um grande número de caixas / sistemas de arquivos que balancam a carga e lidam com failovers para leituras anônimas de CVS, navegação CVS- > html, etc.

(O raciocínio por trás dos meus palpites é que o CVS anônimo serviu ocasionalmente um CVS com várias horas de vida, e eu tenho uma vaga lembrança de falar com as caixas de commit do sf CVS ocasionalmente rastreando muito lentamente).

    

Answer 3

Eu realmente não tenho uma resposta, mas para aprofundar a discussão ...

Eu assumo que o CVS usa algum tipo de banco de dados transacional como um armazenamento de apoio (eu sei que é assim que o SVN faz isso). Se for esse o caso, parece-me que vários escritores nessas estruturas de arquivos não seriam realmente seguros. A melhor abordagem não seria criar a camada de abstração na interface do banco de dados? Por exemplo, use um serviço SQL em vez do BDB / LDBM local ou qualquer que seja (supondo que o CVS suporte tal coisa).