Re: [firebase-br] Servidor Espelho - Sugestões...

[Eduardo Jedliczka]

Bom, não entendi que a troca devesse ser transpartente, pois é completamente
adimissível que ocorra um período de "recomposição" do sistema em caso de
pane no servidor.

Levantei várias sugestões, mas apenas uma é 100% eficaz para a troca
transparente (utilizando Linux com servidor mestre e escravo), e outra
parcialmente eficaz (cluster beowulf) as outras nem chegam perto de serem
transparentes.

[s]

====================
Eduardo Jedliczka
Apucarana - Paraná
====================
----- Original Message -----
From: "Jean Mikellides" <suporte em eltronsolutions.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Thursday, July 14, 2005 10:46 AM
Subject: Re: [firebase-br] Servidor Espelho - Sugestões...


Eduardo as exigências do Felipe ... não permitam dependências do servidor A´
para o Servidor B´

Pois ao ter um pane no servidor A´ automaticamente o servidor B´deveria
assumir tendo o mesmo todos os dados... (tendo 02 HD´s no mesmo servidor não
dara ok), Para tal o servidor B´ deverá estar na rede totalmente
independente  acho eu ....  a novell tem um sistema destes ...  também temos
o problema de IP´s usando o mesmo terminais Windows ...  e o NET TERM  usara
IP de Chamada ..  tendo o Servidor B´ um Ip diferente não sei si estou sendo
claro .. devera ter algo do tipo FULL DUPLEX ...  estarei vendo o que posso
achar em termos de LINUX ...

[]

Jean




----- Original Message -----
From: "Eduardo Jedliczka (TeamFB)" <jedyfb em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Wednesday, July 13, 2005 8:07 PM
Subject: Re: [firebase-br] Servidor Espelho - Sugestões...


> Felipe,
>
> Li cuidadosamente todas as mensagens desta threat. Então deixe-me comentar
> meu ponto de vista sobre as principais sugestões....
>
> a) Replicação - É uma alternativa extremamente interessante, e esbarra
> apenas no tempo de sincronização. Há ferramentas (gratuitas e pagas) que
> funcionam muito bem. Como tudo é feito com triggers, há uma perca razoável
> de processamento em rotinas de inclusão/alteração (mas não nas consultas)
> o
> que não compromete sua utilização.
>
> b) Servidor Escravo - É uma técnica muito antiga e utilizada no mundo Unix
> (e linux), porém é ligeiramente complexo para configurar, as formas mais
> seguras, envolvem um cabo (geralmente serial Db9 ) interligando
> fisicamente
> os equipamentos, e é testado continuamente (em alguns milissegundos) se há
> resposta, quando não houver, o escravo assume o IP do servidor principal e
> todas as suas funções, a instalação, programas e arquivos (leitura e
> gravação) são sempre idênticos em ambos os servidores, pois tudo que é
> recebido no IP principal é alocado para o IP secundário, a troca de
> servidores é automática e transparente, e sem derrubar as conexões
> atualmente existentes (ainda é muito comum em servidores web de alta
> disponibilidade)
>
> c) Shadows - acho o valor 20% extremamente exagerado - um valor entre 2% e
> 5% mais realista, se tiver 2 HDs e o shadow ficar no segundo disco, eu
> ousaria dizer que o prejuízo é perto de Zero. Nunca utilizei shadows em
> linux ou outros unices, e duvido que seja possível criar shadows em outras
> máquinas (ou volumes de rede), pois se o FireBird suportasse isto, seria
> muito fácil permitir acessar uma base em outra máquina. Isto sem contar a
> necessidade de um Gbak para "recompor" a base...
>
> d) Backup / Restore programado (a cada XX minutos) - Uma solução
> interessante para você é utilizar um script no computador secundário para
> realizar um Backup da base principal e restore local, continuamente (com
> alguns nomes diferentes para não sobregravar e você ficar sem base). No
> caso
> de pane do servidor principal, o prejuízo será apenas de alguns minutos
> (dependendo do tempo de backup / restore da base). Esta opção pode
> degradar
> a performance sériamente (ousaria dizer entre 20 e 50% - em alguns testes
> que realizei em horário de pico, um backup consumiu uma média de 35% de
> CPU
> além do consumo esperado sem o backup).
>
> e) Cluster (beowulf) - são várias máquinas compartilhando CPU e memória (o
> conceito de GridComputing do Oracle), trabalhando como se fossem uma
> única.
> Se você colocar 3 máquinas e formar um cluster, todas as requisições
> recebidas por aquele IP serão divididos entre as várias máquinas,
> permitindo
> assim um ganho excepcional de desepenho. Nesta situação pode-se replicar
> (por software) o disco entre todas as máquinas, e se uma delas cair, as
> outras mantém o sistema em pé, porém mais lento. Pode acontecer, durante a
> queda de uma máquina, que alguns terminais tenham suas conexões
> finalizadas
> (pois aquela máquina estava respondendo por algumas requisições). O
> problema
> é que o FB não funciona em Cluster. O Nicolay Samofatov desenvoloveu a
> pedido de uma empresa, uma versão personalizada uma versão anterior ao FB
> 1.5 final que funcionava em Beowulf, mas não está disponível para
> utilização. Segundo alguns comentários, o Vulcan (que funciona muito bem
> em
> máquinas multiprocessadas) pode ser utilizado em cluster, mas ainda não
> tem
> uma versão Oficial.
>
> Resumindo, acho que a opção D muito viável e "barata" (no sentido de
> percas
> e tempo de recuperação), se puder perder tempo, pesquise e experimente a
> opção B... Em último caso fique com a opção A e torça para não ter
> problemas. E, quem sabe até o natal a opção E não estará disponível ????
>
>
> Sucesso,
>
> Eduardo Jedliczka
> Membro do TeamFB (FireBase)
> Apucarana - Paraná
>
> ----- Original Message -----
> From: "Felipe Giotto" <felipe em metasoftware.com.br>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Wednesday, July 13, 2005 5:17 PM
> Subject: Re: [firebase-br] Servidor Espelho
>
>
> Nós utilizamos shadow em alguns clientes, e realmente funciona... Existe
> uma
> perda de desempenho de cerca de 20% quando da utilização de shadows, mas
> em
> alguns casos vale a pena... Outra coisa é que a shadow não é ativada
> automaticamente.. Para se ativer uma shadow, deve-se usar o arquivo
> "GBAK.EXE" e depois substituir a base de dados original (claro que essa
> tarefa pode ser realizada por um aplicativo)....
>
> Espero ter ajudado,
>
> Felipe ;-)
>
> ----- Original Message -----
> From: "Giovani Benedetti Penha" <giovani em cooperval.com>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Wednesday, July 13, 2005 4:57 PM
> Subject: Re: [firebase-br] Servidor Espelho
>
>
>> Bom, se eu fosse você seguiria a dica do Felipe, pesquise sobre esse
>> shadow. Acho que seria a solução mais simples e funcional para o seu
>> caso,
>> além de não precisar de configurar um servidor Linux para trabalhar
>> espelhado (essa tarefa não é das mais simples de serem feitas).
>> Alguém aqui na lista já usou esse shadow? Funciona mesmo? :)
>>
>> []´s
>> Giovani Benedetti Penha
>>
>> Marciano Bandeira escreveu:
>>
>>> Perder o que não foi comitado não tem problema, o que quero evitar é por
>>> exemplo...
>>> ... a industria de confeções tem que entregar um lote de mercadorias
>>> hoje, mais com o sistema fora do ar não tem como eles saber o que tem
>>> que
>>> produzir,  ou chega um cliente de uma loja que usa o sistema, e não pode
>>> pagar sua conta porque o sistema está fora do ar...
>>> ... ou o gerente quer saber o que tem que comprar pra suprir o estoque
>>> da
>>> loja e tem que contar o estoque no dedo pois o sistema ta fora do ar...
>>>
>>> isso que quero evitar
>>> desde ja agradeço
>>> Marciano Bandeira
>>>
>>> ----- Original Message ----- From: "Giovani Benedetti Penha"
>>> <giovani em cooperval.com>
>>> To: "FireBase" <lista em firebase.com.br>
>>> Sent: Wednesday, July 13, 2005 4:38 PM
>>> Subject: Re: [firebase-br] Servidor Espelho
>>>
>>>
>>> Olha cara, não sou perito em DRDB, mas pelo que li, o que ele faz é, de
>>> x em x minutos (segundos, milésimos :)), verificar quais blocos do HD do
>>> servidor foram mudados e copiar esses blocos de forma idêntica para o
>>> servidor escravo.
>>> Ou seja, teoricamente você teria exatamente o mesmo banco de dados nas
>>> duas máquinas. Só tem que verificar como fica a questão dos dados que
>>> estão na memória, porque esses não são copiados para o escravo. Talvez
>>> fosse o caso de usar o forced write (me corrijam se eu estiver errado)
>>> ou algum mecanismo que garanta que todos os dados do banco sejam
>>> gravados em disco de X em X tempos. Diminuiria um pouco a performance do
>>> servidor, mas ganharia confiabilidade e alta disponibilidade.
>>> A transação com certeza não seria a mesma. O serviço na máquina escravo
>>> inclusive deveria ficar parado, apenas sendo iniciado quando a máquina
>>> mestre parasse. Ou seja, as transações no mestre que não foram comitadas
>>> seriam perdidas (em tese).
>>>
>>> []´s
>>> Giovani Benedetti Penha
>>>
>>>
>>> Marciano Bandeira escreveu:
>>>
>>>> Obrigado pela resposta imediata!
>>>>
>>>> Achei legal o esque de servidor e escravo, mais não manjo nada de
>>>> Linux...
>>>> ... podem me dar mais detalhes de como funciona o esquema de
>>>> replicação,
>>>> tem como fazer sem alterar meu sistema? tipow fazer um serviço??
>>>>
>>>> Nesse esquema eu teria dois bancos (iguaizinhos) nos servidores?
>>>> A gravação nos dois ficaria na mesma transação?
>>>>
>>>> Desde ja agradeço
>>>> Marciano Bandeira
>>>>
>>>> ----- Original Message ----- From: "Giovani Benedetti Penha"
>>>> <giovani em cooperval.com>
>>>> To: "FireBase" <lista em firebase.com.br>
>>>> Sent: Wednesday, July 13, 2005 3:45 PM
>>>> Subject: Re: [firebase-br] Servidor Espelho
>>>>
>>>>
>>>> Mas o duro é que, nesse caso, se queimar o processador, por exemplo, o
>>>> servidor pára de qquer jeito.. Resolve só pra problema no HD mesmo.
>>>> Eu sugeriria um servidor com outro espelhado. O problema é que fica uma
>>>> máquina inutilizada na empresa (ou seja, a que vai ficar de "estepe"
>>>> para o servidor principal). Existe uma maneira em Linux de você
>>>> utilizar
>>>> alta disponibilidade, ou seja, um servidor mestre e um escravo
>>>> monitorando. Se aquele pára, este toma seu lugar. Existe uma forma
>>>> inclusive de "espelhar" o HD do mestre no escravo, utilizando um
>>>> aplicativo chamado DRBD (Distributed Replicated Block Device). Mais
>>>> informações (muito boas, por sinal) em:
>>>> http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=52&pagina=7
>>>> http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=2135
>>>> http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=2477
>>>>
>>>> []´s
>>>> Giovani Benedetti Penha
>>>>
>>>> Oliveira escreveu:
>>>>
>>>>> Utilize o sistema de RAID, com um servirdor Linux, se eu não estou
>>>>> enganado e assim mesmo que se escreve, com isso, vc pode fazer de tal
>>>>> forma que tudo que for gravado em um HD, tb seja gravado em outro como
>>>>> um espelho..... Tem uns servidores HP, que tem esse recurso
>>>>> nativo.....
>>>>> Se quiser investir !!!!
>>>>> Atenciosamente,
>>>>>
>>>>> Oliveira, José Augusto
>>>>> JASO Tecnologia & Desenvolvimento.
>>>>>
>>>>>
>>>>>     _______________________________________________________ Yahoo!
>>>>> Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
>>>>> http://br.acesso.yahoo.com/
>>>>>
>>>>>
>>>>> ______________________________________________
>>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>>>> Para editar sua configuração na lista, use o endereço
>>>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>>>
>>>>>
>>>>
>>>>
>>>> ______________________________________________
>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>>> Para editar sua configuração na lista, use o endereço
>>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>>
>>>> ______________________________________________
>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>>> Para editar sua configuração na lista, use o endereço
>>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>>
>>>>
>>>
>>>
>>> ______________________________________________
>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>> Para editar sua configuração na lista, use o endereço
>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>
>>> ______________________________________________
>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>> Para editar sua configuração na lista, use o endereço
>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>
>>>
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>> Para editar sua configuração na lista, use o endereço
>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa