Quanta sobrecarga de rede (e problemas de bloqueio de arquivo) posso esperar de 25 a 50 usuários em um DB do Visual FoxPro 9 via SMB / CIFS?

Question

Título alternativo da pergunta: Como posso traduzir "Esse software me dá arrepio" para um caso de negócio para a alta gerência por não comprá-lo?

Sou o departamento de TI de uma pequena empresa que passou por vários anos de crescimento sustentado. Começamos no QuickBooks, mudamos para um sistema contábil diferente e agora estamos no mercado para sistemas ERP de médio porte que são um pouco mais abrangentes e personalizáveis. No momento, estamos avaliando um sistema ERP que está escrito no Visual FoxPro 9 e tenho um mau pressentimento sobre isso, mas não consigo enumerar exatamente por que isso acontece.

É composto por vários módulos, o módulo de back office e um módulo web são os dois que nos interessam. O módulo de backoffice contém as funções habituais de pedido / atendimento / envio / contabilização de ERP. O módulo da Web é conduzido pelo mesmo banco de dados do FoxPro por meio do IIS em um componente .NET que abre o banco de dados de outra máquina usando um caminho UNC. Eu também não sei sobre isso, mas isso é um assunto separado, por enquanto.

Minha preocupação é que o sistema seja "instalado" fazendo o seguinte:

1.  Create a top-level folder on a server.  
2.  share that folder with appropriate users and groups as \server\erp
3.  unzip the .exe and dlls and \data folder in the shared folder
4.  map \server\erp to a drive on client computers
5.  create a shortcut to the \server\data\erp.exe on client desktops.
6.  double click on shortcut!  You’re ERPing! (after some other minimal setup)

O .exe usa o acesso a arquivos no subdiretório \\ server \ data para preencher formulários e etc, como de costume.

Estou preocupado com o fato de que usuários simultâneos (25 ou mais) acessando um .exe que está acessando arquivos através do sistema de arquivos de rede (cifs) para executar funções de banco de dados parece ... suspeito. Todos os outros sistemas que eu vi usam um mecanismo de banco de dados separado, ou um caseiro (o que é ruim o suficiente) ou algo parecido com o SQL Server, Oracle, mesmo PostGreSQL ou até mesmo MySQL para lidar com acesso a dados, mas este é apenas um arquivo .exe em uma pasta compartilhada, executado diretamente a partir dessa pasta compartilhada na área de trabalho de cada cliente. Parece que isso é ineficiente, ou pelo menos deselegante, e que causaria muito tráfego excessivo na rede. O arquivo .exe tem cerca de 10 MB e reside no servidor, abrindo arquivos .dbf que residem em um diretório \ data adjacente. O vendedor estava perguntando se nós tínhamos uma rede de gigabit (nós fazemos) e parecia muito importante para ele ... agora eu posso ver porque ele estava perguntando.

Eu não tenho um profundo histórico de desenvolvimento, mas parece-me que você deve ter um mecanismo de banco de dados separado que se comunica com clientes via pipe nomeado ou soquete TCP / IP ou, pelo menos, algum tipo de protocolo de rede binária. nada mais. Usar o compartilhamento de netBIOS (você insere caminhos UNC no banco de dados como propriedades) parece estar errado, porque você não teria problemas de bloqueio de arquivos se, e. dois usuários querem abrir o mesmo cliente em A / R? Estou apenas sendo excessivamente cauteloso? Isso é realmente uma prática padrão, como o vendedor diz? Eu não tenho muita experiência nos sistemas contábeis maiores como este. Nosso pacote atual usa um modelo cliente-servidor com arquivos de manipulação do mecanismo de banco de dados e, em seguida, os usuários que executam o software em suas máquinas conversam com ele por meio da rede. Estou errado em pensar que algo supostamente mais avançado terá uma interface semelhante?

    

Answer 1

O que você descreveu certamente me causaria preocupação por alguns motivos:

• O fato de o representante insistir na rede Gigabit para um aplicativo tão pequeno. Pode não ter impacto prático em sua rede, mas me deixaria seriamente preocupado com o design do aplicativo. Um sistema ERP de 50 usuários não deve incomodar uma linha de 10Mbit, quanto mais uma gigabit.

• As implicações de segurança do processo de instalação seriam um problema para mim. Esse é um sistema que contém informações sobre clientes (e provavelmente pagamento de clientes). Os usuários iniciarão um atalho exe, o que significa que haverá 25 a 50 instâncias desse exe sendo executado sob as credenciais do usuário em suas estações de trabalho. Esses processos estão acessando e gravando diretamente nos arquivos de banco de dados compartilhados no mesmo compartilhamento . Isso significa que todo usuário, por design, deve ter acesso direto de leitura / gravação a todo o seu banco de dados. Isso é horrível de um ponto de vista técnico e de conformidade de segurança.

Pessoalmente, eu corri uma milha a partir deste aplicativo no último ponto sozinho. Tenho certeza de que as pessoas com mais familiaridade nas áreas de conformidade (ou com o FoxPro) podem comentar mais.

    

Answer 2

Estive lá, fiz isso.

Eu admito que o VFP9 parece um pouco antiquado, mas é uma tecnologia comprovada.

Acredite ou não: o VFP9 é muito robusto em uma configuração como essa. Não é como msaccess em tudo. Eu também tive minhas dúvidas a princípio, mas na prática não há problema algum.

Bônus adicionado: Você pode até fazer backups simples baseados em arquivos dos DBs, desde que nenhum usuário tenha o aplicativo aberto, o que é bom se você não estiver executando uma loja 24 horas por dia, 7 dias por semana.

Mas você precisa de uma LAN rápida (pelo menos 100 Mb) entre clientes e servidores. (E pelo amor de Deus, coloque um NIC 1G no servidor.) O EXE local ou no servidor não importa realmente, ou vai funcionar muito bem.

Como outros afirmaram: Para usuários não locais, você precisa de uma configuração do WTS. A recomendação é fazer isso em uma máquina separada e não no próprio servidor VFP9. (Claro que com o Hyper-V ou o VMWare, ambas as máquinas podem ser VMs na mesma caixa física.)

Por favor, note que os usuários do WTS podem precisar de uma boa quantidade de RAM por usuário. Depende um pouco da eficiência das consultas do banco de dados e das necessidades do aplicativo.

Pelo que vi, conjuntos de trabalho de 100 a 200 MB são bastante normais para aplicativos vfp9, dos quais cerca de metade seria fixada na RAM física. Na minha experiência, 20 a 30 usuários em um servidor WTS de 4 GB de RAM são factíveis se não precisarem executar muito mais na sessão do WTS. Dependendo das necessidades da sua aplicação, a sua milhagem pode variar.

    

Answer 3

Eu tenho muita experiência com um pacote Visual FoxPro 9 ERP que funciona mais ou menos da mesma maneira - compartilhamento de arquivos em um servidor, vários clientes com local EXEs e arquivos de suporte acessando o compartilhamento SMB . O conjunto de dados para cada empresa no ERP é de centenas de arquivos DBF.

Em termos de desempenho, não vemos problemas. Temos muitos clientes executando 30 ou mais clientes em um servidor Windows padrão, acessando arquivos DBF que podem ter milhões de linhas e mais de 1 GB. Se a indexação e o bloqueio forem implementados corretamente pelo ERP, esses números estarão todos bem.

Sim, existem implicações de segurança com um compartilhamento de arquivos cheio de arquivos DBF. Suponho que isso depende do tipo de cliente para o qual o ERP vende, mas em mais de 15 anos e com milhares de sites, o número que eu pessoalmente conheço que perdemos por causa dessa configuração pode totalizar 20 ou mais. Também é possível contornar esse problema usando os Serviços de Terminal.

Você está absolutamente correto também em ter que empregar os Serviços de Terminal, possivelmente por meio de uma VPN, para executá-lo remotamente.

Além disso, se você acabar usando o ERP em questão e tiver máquinas Windows 7 e Server 2008, verifique se eles estão no SP1, pois houve um bug no SMB que causou a corrupção dos arquivos de índice.