Ederson, boa tarde!! Fico com muito receio de utilizar uma redundância de link e falhar.
Estou no Espirito Santo, Serra, e o meu data center fica em Uberlândia, na Algar. Pelo que sei, meu estado apenas recebe as fibras via BrasilTelecom e isso gera um gargalo até chegar ao Data Center. Tenho receio em implementar um link redundante pelo fato das operadoras de telecomunicação utilizarem de meios "compartilhados", e assim sendo, se alguem rope uma fibra, fico na mão do mesmo jeito, concorda? Hoje trabalho com a Oi em um circuito dedicado de 1MB full interconectando filiais ao Data Center e mesmo assim SEMPRE tenho problemas. O SLA deles não é suficiente para suprir minhas necessidades, uma vez que é impossível prever quando o problema ocorrerá, e neste caso, 2 horas já seria um prejuizo consideravel. Também concordo com você que trazer isso pra dentro da empresa é problema! Neste cenário, quais seriam minhas alternativas? O que você acha? Muito obrigado Rafael --- Em oracle_br@yahoogrupos.com.br, "ederson2001br" <ederson2001br@...> escreveu > > Rafael, > > Já está mudando bastante o cenário. Se o Produção já está em DataCenter, o > problema de desastre começa a ficar secudário, uma vez que no seu contrato > (com certeza?) já contempla um bom SLA. > > O seu problema ou ponto focal, passa a ser o link, como o pessoal já falou. > Eu pensaria primeiro em investir em uma redundância de link, com um bom > circuito IP FIXO para conectar direto com o datacenter. Refazendo as rotas no > seu gateway, quando o circuito principal cair, a conexão da aplicação também > cai e prontamente o usuário conecta novamente, momento este onde o gateway > direcionaria para o novo link, atingindo o mesmo IP e PORTA que está no > TNSNAMES do client. > > Justificativa: se a comunicação cai, por quanto tempo fica fora? um minuto, > dois, cinco?? Até aí, justifica o link secundário. > Uma hora ou mais? justifica cancelar esse MPLS e passar para uma comunicação > mais profissional, ou usar outra operadora e um serviço de comunicação mais > profissional (tipo IP FIXO EMPRESARIAL que tem um SLA que atende mais rápido). > > De toda forma, o circuito de redundância tem mesmo que ser feito com outra > operadora, senão não é redundante pois usaria o mesmo meio físico (se > derrubam um poste, arrebenta todos os fios ...). > > Com DataGuard, para switchover de um tempo pequeno de downtime, não > justificaria uma estrutura redundante e pagar o preco do Active DataGuard, a > não ser que a empresa perca milhões caso haja inatividade do sistema. Isto > justifica o investimento em link, pois vcs já contrataram o DataCenter para > não se preocupar com estrutura de servidor e agora estão puxando novamente > para si, a responsabilidade de manter no ar como se o DC não estivesse mais > atendendo? > > No DC tem gerador, nobreak redundante, link parrudo e redundante, cluster > físico, backup confiável de hardware (storage e servidor), pessoal > monitorando 24h, e todas as cláusulas de SLA vigorando. Se você traz isto de > volta para dentro da empresa, vc consegue garantir tudo isto? qual o custo? > alguém vai fazer a conta que assim não precisa do DC: retrocesso. > > Neste cenário, eu valorizo mais o link redundante com outra operadora e se > for na mesma cidade (empresa e DataCenter), estudaria o custo de implementar > uma fibra ótica exclusiva (para comunicação primária) e usaria o MPLS como > circuito secundário. > > > > Ederson Elias > DBA Oracle > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 > ------------ > Labor improbus omnia vincit > > > --- Em oracle_br@yahoogrupos.com.br, "ciadart" <rafael.henrique@> escreveu > > > > Ederson, bom dia!! > > > > Sou totalmente leigo na administração Oracle. Apenas me arrisco nos PLs da > > vida... rsrsrs.. > > > > Desculpe se minhas perguntas forem óbvias, ok? > > > > Vou tentar detalhar mais o meu ambiente para que assim você possa me > > direcionar melhor. > > > > O "Servidor primário" fica em um data center. Lá temos serviço de backup, > > administração, etc. Já o "Servidor secundário" ficará em uma estrutura > > própria com muito menos recursos. > > > > Como sempre, tenho recursos e orçamento limitados, o que me faz optar pelo > > melhor custo benefício. > > > > Eis as perguntas: > > > > - Acho dificil termos problemas no "Servidor primário" do tipo desastre, > > porque estamos amparados com a infra estrutura do data center. O que pode > > ocorrer, e geralmente ocorre, é perdermos a conexão com o "Servidor > > primário" por problemas de comunicação na MPLS. Neste caso quando a conexão > > é restaurada o sistema volta a operar normalmente sem mais problemas. > > > > É neste ponto que temos que ter a redundância. Pois assim os colaboradores > > seriam redirecionados para o "Servidor secundário" e o sistema fica UP > > novamente. > > > > Porém, após o retorno do link, preciso que estes dados manipulados no > > "Servidor secundário" subam para o "Servidor primário" afim de evitarmos > > retrabalho. > > > > Neste caso, qual solução você me aconselha? Continuariamos com o > > "disaster_recover" + "data guard" ? > > > > Que tipo de licenciamento devo utilizar para o "Servidor secundário"? > > > > Você tem idéia, por alto, da infra estrutura necessária para montagem deste > > cenário? > > > > Muito obrigado pelo apoio! > > > > RAfael > > > > --- Em oracle_br@yahoogrupos.com.br, "ederson2001br" <ederson2001br@> > > escreveu > > > > > > Bom dia Rafael, > > > > > > Muito bom este tópico, com certeza haverá muita participação. > > > > > > Bem, vc passou um cenário como sendo de redundância, mas eu vejo como uma > > > situação de disaster_recover em site remoto, que é uma situação > > > totalmente diferente. > > > > > > Em redundância, vc colocaria um Oracle RAC com vários "nodes" em rede > > > local ou remotamente com enlace por fibra ótica dedicado (neste caso, seu > > > link de 1Mb não seria o indicado). > > > > > > No caso de Disaster_Recover, eu acredito que o RAC não seria o mais > > > indicado, pois o desastre pode ser lógico (remoção/modificação/inserção > > > de dados incorretos) e haverá a necessidade de voltar em uma janela e o > > > backup pode não fornecer a opção para isto (apesar de poder ser > > > configurado e usado para tal). > > > Outra observação é que os diversos "nodes" se conectam a uma storage > > > única (que também pode ser espelhada e outro local), mas aí já estaremos > > > além do escopo. > > > > > > Bem, a ferramenta DataGuard seria uma opção e deverá ser configurada para > > > atualizar de madrugada e também em mão-dupla, isto é, o servidor de > > > disaster também será replicado para o produção. Veja os detalhes aqui: > > > http://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm > > > > > > Tem também opção de ferramentas de terceiros para replicação, que podem > > > te atender. Cada caso é um caso. > > > > > > Considere que qualquer opção envolve licenciamento e não é implantado de > > > bate-pronto, leva um bom tempo de planejamento, adequação de > > > infra-estruturas físicas e configurações se serviços. > > > > > > Minha opinião, prá fechar: sua base é pequena, 100Gb é um volume de dados > > > que pode ser gerenciado com um backup lógico. Vc tendo dois bancos > > > separados geograficamente (veja a SOX para detalhes), vc pode gerar o > > > backup de madrugada e transferir para o outro server. Uma boa rotina para > > > testar o seu backup, é fazer a restauração diária. Desta forma vc terá > > > sempre um banco em produção e outro na janela do dia anterior. Este > > > cenário atende a SOX em Disaster_Recover desde que o SLA assim esteja > > > assinado. > > > > > > Questão colocada em discussão. > > > > > > > > > Ederson Elias > > > DBA Oracle > > > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 > > > ------------ > > > Labor improbus omnia vincit > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, Rafael HM Pereira <rafael.henrique@> > > > escreveu > > > > > > > > Pessoal bom dia!! > > > > > > > > Preciso montar um esquema de redundância / sincronização de dados entre > > > > 2 > > > > servidores oracle distribuidos em sites distintos. A comunicação entre > > > > eles > > > > é feita via MPLS com um link de 1MB Full. > > > > > > > > Estes dois servidores deverão ser sincronizados de madrugada, e o > > > > intuito > > > > da sincronização é criar uma redundância do serviço, tornando possível a > > > > continuidade das atividades em caso de falha do "Servidor principal". > > > > > > > > Hoje temos o "Servidor principal" onde ocorrem todas as transações e > > > > consultas. O "Servidor secundário" será utilizado apenas em caso de > > > > falhas > > > > e não terá um grande hardware, apenas o necessário para rodar o serviço > > > > temporariamente. > > > > > > > > Eu preciso que após a falha, o "Servidor secundário" assuma o controle e > > > > permita a realização das atividades. > > > > > > > > Porém, após o retorno do "Servidor principal", os dados trabalhados no > > > > "Servidor secundário" devem ser sincronizados / replicados para o > > > > "Servidor > > > > principal" e vice-versa, deixando ambos consistentes novamente. > > > > > > > > Hoje trabalhamos com o Oracle 10g no "Servidor principal", e gostaria de > > > > saber qual(is) serviços devem ser configurados para que este ambiente > > > > funcione corretamente. > > > > > > > > O tamanho de minha base de dados esta em torno de 100 GB. O sistema > > > > operacional dos servidores é Linux. > > > > > > > > Desde já agradeço o apoio! > > > > > > > > Muito obrigado > > > > > > > > > > > > -- > > > > Att, > > > > > > > > Rafael HM Pereira > > > > > > > > Linux User Id: 360166 > > > > Skype: rafaelhmpereira > > > > MSN: rafael.henrique@ > > > > Blog: http://rafaelhmpereira.blogspot.com > > > > LinkedIn: http://br.linkedin.com/in/rafaelhmpereira > > > > (27) 9233-0734 / (27) 3328-4320 > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > >
