RAFAEL RIBEIRO DÉDA REPLICAÇÃO DE BASE DE DADOS: EMPREGABILIDADE E ANÁLISE DE REDUNDÂNCIA

Transcrição

1 RAFAEL RIBEIRO DÉDA REPLICAÇÃO DE BASE DE DADOS: EMPREGABILIDADE E ANÁLISE DE REDUNDÂNCIA Rafael Ribeiro Déda 1 RESUMO Com o aumento da quantidade de dados e, subsequentemente, de sua importância, as empresas precisam se preocupar em manter os mesmos seguros contra situações como desastres naturais entre outros. Para isso, deve-se ter backup das bases de dados e, se possível, num lugar que não esteja no mesmo local do servidor central da empresa, ou seja, que o site backup esteja em outro Estado por exemplo. Para atender essa questão, deve-se ter uma infraestrutura de redes que permita enviá-los de maneira segura, rápida e com um bom custo x benefício para o site backup. Para isso, pode-se usar tecnologias como frame relay, fibra ótica e WiMax. Cada uma possui vantagens e desvantagens e a escolha de usar uma ou outra irá variar de acordo com a situação. Por fim, independente da tecnologia escolhida, há uma necessidade uma atenção especial em relação a sua empregabilidade e importância, bem como, deve-se ter uma rede redundante para, caso a primeira rede falhe, a outra possa entram em funcionamento para permitir que a comunicação entre a matriz e o site backup seja mantida. PALAVRAS-CHAVE Frame Relay; Fibra Ótica; WiMax; Backup; Site Backup; Replicação; Redundância. 1 Bacharel em Sistema de Informação pela Universidade Tiradentes, Pós-graduado em Administração de Banco de Dados pela Faculdade de Negócios de Sergipe - FANESE. rafael.deda@gmail.com

2 2 ABSTRACT With the increasing amount of data and, subsequently, its importance, companies need to worry about keeping them safe from things like natural disasters among others. To do this, you should take backup of databases and, if possible, a place that is not the same place on the company's central server, or the backup site is in another state for example. To answer this question, one must have a network infrastructure that allows sending data securely, quickly and with a good cost / benefit to the backup site. For this, we can use technologies such as frame relay, optical fiber and WiMax. Each has advantages and disadvantages and the choice of using one or the other will vary depending on the situation. Finally, regardless of the technology chosen, one must have a redundant networkin case the primary network fails, the other can come into operation to allowcommunication between hea dquarters and the site is kept up. KEY WORDS Frame Relay, Fiber Optics, WiMax, Backup, Site Backup. 1 INTRODUÇÃO A quantidade de dados armazenados pelas empresas aumentou muito nos últimos anos. Determinados tipos de empresas precisam manter dados por anos, a exemplo de Instituições financeiras que necessitam manter os dados armazenados por 05 (cinco) anos. Assim como aumentou o fluxo de dados, aumentou também a preocupação e a necessidade de manter os mesmos guardados num local separado do servidor central da empresa, um site backup. Isso acontece porque, em caso de catástrofes naturais ou algum outro desastre, os backups estarão salvos e, com isso, a empresa pode voltar a funcionar com o mínimo de perda de dados, afinal, os dados são a alma da empresa. A proposta deste projeto é demonstrar um caso de uso onde será mostrado um cenário que é comum atualmente, expondo o ambiente e as necessidades da empresa para tentar manter os dados seguros em caso de perda do servidor principal. Tendo sido descrito o caso de uso, irá ser demostrado como atender ao cenário da empresa, demostrando as tecnologias de rede que podem ser utilizadas para a transferência de dados, mostrando os prós e contras de cada uma e terminando por selecionar uma e explicando o por que.

3 3 Por fim, será escolhida uma tecnologia e será explicado o porquê da mesma ter sido escolhida em detrimento das outras, mostrando inclusive, em alguns passos como poderá ser feito a replicação de uma base de dados (explicando as possíveis formas) do Sistema Gerenciador de Banco de Dados (SGBD) utilizado no caso de uso. 2 DESENVOLVIMENTO Neste capítulo, serão discutidos um caso de uso e as melhores práticas de rede para atender ao mesmo, sempre tendo em vista o melhor custo benefício para a empresa Caso de Uso O estudo de caso irá analisar opções de estrutura de rede para interligar 02 (duas) unidades de uma empresa para montar uma estrutura de backup da base de dados que contém as informações pertencentes a todos os sistemas que são utilizados na empresa. O SGBD usado é a solução SQL Server 2008 R2 Enterprise e sistema operacional Windows Server A base de dados atualmente possui 100 GB. O servidor usa a estrutura de Cluster, onde um nó é ativo e o outro passivo, ou seja, o segundo nó só será ativado caso o principal falhe. Mas a estrutura em cluster do banco de dados é só o primeiro nível de segurança. Para qualquer empresa, o fundamental é ter todos os dados pertencentes à organização seguros de qualquer sinistro que venha a acontecer no local onde seus sistemas de informações são mantidos. Pensando nisso, o servidor secundário ficará responsável pelo backup dos dados e fazer o controle das gravações em fitas. A política de backup utilizada será a de um backup Full semanal, que ocorre toda sexta às 22h00min. Os backups de log transacional ocorrerão a cada 07 minutos. O backup diferencial ocorrerá de segunda a sexta às 12h00min. Estes backups serão guardados em fita automaticamente pela ferramenta Tivoli Storage Manager da IBM, 03 vezes na semana às 02h00min da madrugada. Com o objetivo de manter guardado com segurança sempre a última posição da semana, ao final do processo de backup, o arquivo gerado será enviado para um site backup que fica a aproximadamente 80 km da matriz. Para isso, o arquivo deverá ser transmitido pela rede. Essa transmissão é para garantir que em caso de catástrofes naturais que possam

4 4 acontecer na matriz, os dados da última semana estarão seguros e prontos para serem utilizados em operações de restore. Para garantir que os backups que estão sendo gravados nas fitas estão funcionando, após a rotina de backup, sempre é executado um comando para verificar a integridade do arquivo de backup. A topologia que será analisada em todas as tecnologias é a do tipo ponto-a-ponto e fará o uso de QoS(Quality of Service) para priorização dos pacotes que serão transmitidos. Além disso, deverá haver uma rede redundante para que, em caso de falha da rede principal, a rede alternativa deverá ser utilizada. Por fim, iremos mostrar os passos de como se fazer uma replicação do tipo Snapshot Replication no SQL Server, mostrando sua funcionalidade como é feita a implementação mediante exemplo com a criação de um database simples, exibindo como realizar configuração no servidor primário e no servidor secundário Opções de Infraestrutura Atualmente, a empresa pode contar com 03 (três) tipos de conexão, as quais seguem listadas abaixo: Frame Relay; Fibra Ótica; WiMax. Cada uma destas tecnologias possuem prós e contras e caraterísticas particulares, as quais serão explicadas a seguir Frame Relay O frame relay é uma tecnologia de comunicação de dados de alta velocidade que é usada em muitas redes ao redor do mundo para interligar aplicações do tipo LAN, SNA, Internet e voz. Basicamente pode-se dizer que esta tecnologia fornece um meio para enviar informações através de uma rede de dados, dividindo essas informações em quadros (frames) ou pacotes (packets). Cada frame carrega um endereço que é usado pelos equipamentos de rede para determinar seu destino.

5 5 A tecnologia Frame Relay utiliza uma forma simplificada de chaveamento de pacotes, que é adequada para computadores, estações de trabalho e servidores de alto desempenho que operam com protocolos inteligentes, tais como SNA e TCP/IP. Isto permite que uma grande variedade de aplicações utilize essa tecnologia, aproveitando-se de sua confiabilidade e eficiência no uso de banda. Figura 1 - Frame Relay Como toda tecnologia, o frame relay possui vantagens e desvantagens. Os principais benefícios são: Altas velocidades de acesso; Baixos retardos; Facilidade de migração e interoperabilidade com protocolos como ATM e TCP/IP; Custo com equipamentos são reduzidos, uma vez que os mesmos são mais simples. As principais desvantagens são: Devido à inexistência de mecanismos de controle de erro, os equipamentos de usuário devem utilizar aplicações com protocolos inteligentes, que controlem o fluxo de dados enviados/recebidos; A rede de transporte deve ser virtualmente a prova de falhas Fibra Ótica

6 6 A fibra ótica é um pedaço de vidro ou de materiais poliméricos com capacidade de transmitir luz. Possui diâmetros variáveis, dependendo da aplicação, indo desde diâmetros ínfimos, da ordem de micrômetros até vários milímetros. Cabos de fibra ótica atravessam oceanos e são muito usados pelas telecomunicações. Para transmitir dados pela fibra ótica são necessários equipamentos especiais, que contém um componente foto emissor, que pode ser um diodo emissor de luz (LED) ou um diodo laser. Figura 2 - Cabos submarinos de fibra ótica Esta tecnologia possui as seguintes vantagens e desvantagens. As vantagens do uso da fibra ótica são: Dimensões reduzidas; Capacidade para transportar grandes quantidades de informação (Dezenas de milhares de conversações num par de fibras); Atenuação muito baixa, que permite grandes equipamentos entre repetidores, com distância entre repetidores superiores a algumas centenas de quilômetros; Imunidade às interferências eletromagnéticas; Matéria-prima muito abundante. Contudo, essa tecnologia possui as seguintes desvantagens: Custo ainda elevado de compra e manutenção; Fragilidade das fibras óticas sem encapsulamento;

7 7 Dificuldade de conexões das fibras óticas; Acopladores tipo T com perdas muito grandes; Impossibilidade de alimentação remota de repetidores; Falta de padronização dos componentes óticos. Figura 3 - Mapa dos Cabos Submarinos pelo Mundo 2.5. WiMax O WiMax é uma rede sem fio para redes metropolitanas (WMAN). É muito similar ao padrão Wi-Fi, porém agrega conhecimentos e recursos mais recentes, visando a um melhor desempenho de comunicação. Possui uma cobertura na ordem de quilômetros e taxas de transmissão de até 74 Mbps, além de qualidade de serviço (QoS) e interfaces para redes IP, ATM, E1/T1 e Ethernet. As redes WiMax funcionam ponto-multiponto, semelhante à tecnologia Wi-Fi do ponto de vista de transmissão e recepção de dados via rádio, as transmissões de dados podem chegar a 1 Gbps a uma distância de até 50 Km, a uma faixa de frequência centrada de Ghz.

8 8 O padrão WiMax tem como objetivo estabelecer a parte da infraestrutura de conexão de banda larga (last smile) oferecendo conectividade para uso doméstico, empresarial e em hotspots. Figura 4 - Wimax Essa tecnologia possui as seguintes vantagens: Baixos custos na implementação; Redução de custos de acesso à internet com banda larga; Alta flexibilidade; Altas taxas de transferência; Qualidade de serviço. As desvantagens do WiMax são: Tecnologia nova, não se sabe se irá possuir uma boa aceitação; Incompatibilidade do WiMax móvel com o fixo; Nas frequências mais altas, sofre com interferências pela chuva, causando diminuição de taxas de transferências e dos raios de cobertura.

9 9 Figura 5 Funcionamento da Rede WiMax em relação ao Wi-Fi 2.6. Fazendo a Replicação das Bases para outro Servidor Nos tópicos anteriores, mostramos soluções de como faríamos as transferências dos backups dos dados levando em conta os meios físicos de rede existentes. Já neste, iremos supor que nessa empresa que possui 2 (dois) servidores, quiséssemos utilizar um desse para receber a replicação dos dados do primeiro para que caso haja uma parada abrupta do servidor principal, o secundário possa assumir o controle. Existem vários cenários de replicação existentes, dentre eles temos processamento offline e a redundância. No caso de uso em questão iremos usar a 2ª forma, a redundância. Na replicação, a ferramenta de replicação permite que você construa uma base "espelhada" da base de sua aplicação, o que permite que em algum momento de indisponibilidade ela tome o lugar da base de "produção" sem maiores dificuldades. Em qualquer cenário de replicação existem dois principais componentes, os Editores ( Publishers) e ao Assinantes (Subscribers).

10 10 Os Editores disponibilizam seus dados para outros servidores através de Artigos (Articles), um artigo é um objeto em uma base de dados, como por exemplo, views, tabelas, entre outros. Os Assinantes consomem os dados dos editores, eles que recebem as atualizações quando há alguma modificação na base Editora. Lembrando que nada impede que uma base de dados seja Assinante e Editora ao mesmo tempo, onde isso é frequentemente utilizado. O processo de "meio de campo" entre Editores e Assinantes é feito pelos Agentes (Agents). O SQL Server suporta três diferentes tipos de replicação, Snapshot, Transactional e Merge Replication. Para facilitar o nosso estudo, iremos apresentar a replicação Snapshot, por ser mais simples e didático. No Snaphot Replication, esse é o modelo inicial de replicação, pois, ele simplesmente tira uma "foto" da base de dados replicada e compartilha essa "foto" com os seus Assinantes, em um processo longo e que consome muitos recursos do servidor, afinal é uma cópia completa de todos os artigos da Publicação, lembrando que esse tipo de replicação não é utilizado em uma base de dados que sofre frequentes alterações. Primeiramente, devemos habilitar a replicação no servidor de banco de dados que será replicado. Na instalação, selecione a opção SQL Server Replication, conforme exibido abaixo. Figura 6 - Habilitar SQL Server Replication Depois de instalada a feature de replicação no servidor de banco de dados, devemos configurar o Distributor. No cenário ideal, devemos separar o distributor em um servidor dedicado (que no nosso caso teremos dois servidores), porém também podemos configurá-lo no servidor que será replicado, lembrando que essa decisão deve ser estudada, levando em

11 11 consideração os databases existentes no servidor e o tamanho da replicação que estará sendo implementada. Para configurar o distributor, clique com o botão direito em Replication e em seguida Configure Distribution, conforme Figura 7. Figura 7 - Configurando o Distributor Em Configure Distribution Wizard Distributor (logo abaixo), você irá configurar o servidor atual como Distributor ou poderá indicar um outro servidor para ser o Distributor. No nosso exemplo, o próprio servidor será o Distributor. Figura 8 - Selecionando o servidor para Distributor Na Figura 9, caso o seu servidor não esteja com o SQL Server Agent configurado para iniciar automaticamente, o wizard da replicação irá questionar se você não quer mudar a

12 12 inicialização para automática. É altamente recomendável que o SQL Server Agent seja configurado para iniciar automaticamente, pois ele tem papel fundamental no funcionamento da replicação. Figura 9 - Alterar inicialização do SQL Server Agent para iniciar automaticamente Como dito anteriormente, para todo tipo de replicação, será necessário criar um pacote Snapshot, com a estrutura e dados para carga inicial. Para que todos os assinantes consigam acessar esse pacote, criaremos um compartilhamento com acesso somente aos usuários que iniciam o SQL Server Agent dos servidores replicados (Figura 10). Figura 10 - Configurando a Snapshot Folder

13 13 Apenas um detalhe, para um bom funcionamento de toda a estrutura de replicação, sugere que utilize sempre um mesmo usuário e senha locais, criados em todos os servidores que fazem parte da replicação, e que esse usuário seja configurado para iniciar o SQL Server e o SQL Server Agent. Mas fica a critério, lembrando que se forem usuários diferentes em cada servidor replicado, você precisará configurar o acesso desses usuários no compartilhamento do snapshot. O passo seguinte, conforme Figura 11, é configurar o nome do database e o local onde ficarão fisicamente os arquivos de dados e log. Nesse exemplo, iremos seguir o sugerido, mas lembre-se, é sempre recomendável separar os arquivos de dados e log em discos físicos diferentes. Figura 11 - Nome e local do database distributor A próxima tela do wizard será para habilitar os servidores e databases publicadores (Publishers). Conforme Figura 12, nesse exemplo somente teremos o servidor local.

14 14 Figura 12 - Habilitando os publicadores Em seguida, será perguntada qual a ação que você quer tomar para finalizar o wizard. Temos 2 opções, configurar o Distributor nesse momento ou gerar um script para configurálo depois. Nesse exemplo, já iremos configurá-lo. Adiante, será mostrado um resumo de todas as opções selecionadas durante esse wizard, na Figura 13 abaixo. Figura 13 - Ação para finalização e resumo das opções selecionadas Agora já podemos criar nossos pacotes de replicação, chamados de Publications. Iremos criar uma publicação, utilizando a Transaction Replication, para ilustrar o que podemos fazer com a replicação do SQL Server. Para criar uma publicação, clique com o botão direito em Local Publication e depois em New Publication, conforme Figura 14 abaixo.

15 15 Figura 14 - Criando nova publicação Na tela seguinte, clique me Next. Como mostrado na Figura 15, em Publication Database, vamos selecionar o database que iremos replicar as informações, no nosso exemplo DBMatriz. Em seguida, na tela Publication Type, iremos selecionar a opção Transactional Replication. Nessa replicação, como dito anteriormente, os dados somente são enviados aos assinantes, não haverá retorno de nenhuma alteração ou novos dados. Clique em Next. Figura 15 - Selecionando o database e o tipo de replicação Serão exibidos todos os objetos do dabatase escolhido. Agora iremos selecionar as tabelas que desejamos replicar. Note na Figura 11, onde estão listadas as tabelas de nosso exemplo, que há uma tabela com um símbolo indicando que ela não pode ser

16 16 selecionada/replicada. A tabela tbamb2 não tem primary key definida, por esse motivo não pode ser replicada. Um requisito básico para replicar tabelas, é que elas precisam ter a chave primária criada. Figura 16 - Selecionando as tabelas a serem replicadas Após selecionar todas as tabelas, iremos verificar as propriedades dos objetos selecionados, clicando em Article Properties e depois em Set Properties of All Table Articles, conforme indica a Figura 17. Figura 17 - Verificando as propriedades das tabelas selecionadas A Figura 18 mostra a tela de propriedades que podemos alterar para replicar, tanto a estrutura da tabela, quando seus dados. Obviamente para cada tipo de necessidade, temos que alterar propriedades diferentes, porém sugiro uma atenção para as seguintes

17 17 propriedades: Copy foreign keys constraints, Copy check constraints, Copy Clustered index, Copy nonclustered indexes, Copy collation, Copy permissions. Uma atenção especial em Action if name is in use, pois é nesse item que definiremos qual o comportamento da replicação, caso a tabela já exista no destino. Normalmente utilizo a opção, Truncate all data in the existing object. Essa opção irá realizar um truncate na tabela antes de enviar os dados a serem replicados. Figura 18 - Propriedades das tabelas selecionadas Depois de configuradas as propriedades, clique em OK e depois em Next. Então, chegamos aos filtros que podemos criar para as tabelas que serão replicadas na Figura 19. Para cada tabela que selecionamos anteriormente, podemos criar filtros para os dados que serão replicados. Não criem filtros complexos ou selects muito extensos, pois isso pode impactar drasticamente na performance da replicação, e consequentemente no seu database principal. Justamente por esse motivo, você poderá notar que JOINs não são permitidos no select principal desses filtros. Outro fator importante ao criar um filtro, tenha em mente que se nas propriedades das tabelas, você habilitou enviar para os assinantes todas as regras de constraints, certifique-se que não haverá violação dos dados nesses filtros.

18 18 Figura 19 - Adicionando filtros as tabelas de sua replicação Seguindo adiante, iremos configurar o Snapshot Agent. Como mencionado no início, toda replicação é sempre iniciada através de um snapshot do database. Nesse momento, iremos indicar se queremos criar o snapshot imediatamente ao término do wizard, e deixá-lo disponível para os novos assinantes, e as opções de agendamento da execução do agente que controla o snapshot. Conforme mostrado na Figura 20, recomendo deixar marcada a opção Create snapshot immediately and keep ths snapshot available to initialize subscriptions e deixar desmarcada a opção que configura o agente do snapshot. O Snapshot Agent somente deve ser executado na criação de um novo assinante, ou na necessidade de reinicializar algum assinante, portando sua execução poderá ser manual, somente quando necessária.

19 19 Figura 20 - Configuração do Snapshopt Agent Na Figura 21, vamos configurar as contas de usuários que irão executar o Snapshot Agent e Log Reader Agent. O ideal, é que você tenha em todos os servidores que fazem parte da replicação, uma mesma conta local, com usuários e senhas iguais, para evitarmos problemas de acessos e permissões pelos agentes. Figura 21 - Configurando a segurança dos agentes do snapshot e log reader Por fim, será questionado se queremos criar a publicação nesse momento ou gerar um script que fará todo esse trabalho. No nosso caso, só iremos deixar marcada a opção Create the publication. Após será solicitado um nome para nossa publicação.

20 20 Figura 22 - Finalizando o processo de criação de uma publicação e nomeando o publication Finalizamos o primeiro passo. Agora iremos criar os assinantes que receberão os dados da publicação que acabamos de criar. No Microsoft SQL Server Management, em Replication e depois em Local Publications, note que apareceu um item com o nome do database replicado, mais o nome que você preencheu ao criar a publicação. Clique com o botão direito em cima desse novo item, e depois em New Subscriptions, conforme indica a Figura 23. Figura 23 - Criando um novo Subscription (assinante) Conforme ilustrado na Figura 24, devemos selecionar um Publisher e depois qual será a ação do Distributor. Temos duas opções, a Push subscriptions e Pull subscriptions. Na Push o distributor irá enviar as informações ao subscriber (assinante), já na Pull, o assinante é

21 21 responsável por ir até o distributor e pegar as informações. No nosso exemplo, iremos utilizar a push subscription. Figura 24 - Selecionando o publisher e a opção do distributor Na próxima tela, iremos selecionar os subscribers que receberão a replicação. Note que aparecerão os servidores que você tem registrado no seu Management Studio. Caso queira incluir mais servidores, basta clicar no botão Add Subscriber e cadastrá-los. Após selecionar cada servidor subscriber, será necessário escolher o database no servidor assinante que receberá os dados ou até poderá criar novos databases nos mesmos. Figura 25 - Selecionando os assinantes e os respectivos databases Após, iremos configurar as contas que serão utilizadas pelos agentes do subscriber. Clicando em ( ), irá abrir uma tela para configurar as contas que serão utilizadas pelos

22 22 agentes. Recomendo que utilize a mesma conta local criada anteriormente, lembrando novamente que a utilização de uma mesma conta, irá reduzir a possibilidade de problemas referentes a permissões entre os servidores. Figura 26 - Configurando as contas utilizadas pelos agentes no subscriber Em seguida iremos definir como o agente do distributor irá enviar as informações ao assinante. Essa é uma informação que você deverá ter definido no projeto de sua replicação. A pergunta que se aplica a isso é: Por quanto tempo posso manter as informações das tabelas sem atualizar?. Respondida essa pergunta, poderemos configurar a latência dessa replicação. Mas não podemos deixar a replicação por um longo período de tempo sem replicar os dados, pois isso pode expirar os dados, e se isso acontecer, será necessário reiniciar o assinante e novamente gerar um snapshot do database principal. A tela seguinte, conforme Figura 27, nos dá a opção de inicializar imediatamente a Subscription no término do wizard.

23 23 Figura 27 - Agendamento e inicialização do assinante Finalizando, a Figura 23 mostra as duas últimas telas no processo de criação do subscriber. A primeira mostra as opções de criação do subscriber. Deixaremos marcada a primeira opção, que irá criar o subscriber imediatamente e a segunda é para gerar o script desse wizard. Após será exibido um resumo do wizard. Figura 28 - Finalizando a criação do subscriber Agora iremos abrir o Replication Monitor e verificar se todas as ações de inicialização, criação do snapshot e envio das informações ao subscriber foram realizadas com sucesso. No Management Studio do servidor matriz, vá em Replication e clique com o botão direito. Após selecione a opção Launch Replication Monitor. Será apresentada uma tela como a Figura 29.

24 24 Figura 29 - Replication Monitor Essa é a tela que utilizamos para administrar a replicação no SQL Server. Nela podemos definir as propriedades de tempo de sincronização, iniciar e parar replicações para um ou todos os assinantes, ver detalhes da replicação, entre outras coisas. Como podemos visualizar na Figura 29, na guia All Subscriptions, estão listados todos os assinantes da publicação selecionada. Como a latência está em 00:00:00, podemos perceber que os dados foram enviados e o pelo tempo da latência, essa indica que o dados está praticamente on-line. Outra guia importante e que temos que monitorar constantemente, é a guia Agents (Figura 30). Nela podemos verificar os status dos agentes de Snapshot e Log Reader. Figura 30 - Guia Agents do Replication Monitor Para testar na prática, crie uma nova Database Engine Query no seu Management Studio, e no database DBMatriz, execute os inserts abaixo:

25 Inserindo dados na tabela da matriz: INSERT INTO tbacaotipo (nmacaotipo, idusuariogrupo) VALUES ('Preparando', 1) INSERT INTO tbacaotipo (nmacaotipo, idusuariogrupo) VALUES ('Replicando', 1) Após, execute um select na tabela tbacaotipo no database DBFilial (nosso exemplo), e veja que os dados encontram-se lá. Dessa maneira concluímos o estudo de caso exibindo os passos de replicação utilizando o SQL Server 2008.

26 26 CONSIDERAÇÕES FINAIS Analisando as tecnologias expostas, vemos que algumas são muito boas e possuem uma boa taxa de transferência, contudo pode ter um custo muito grande de manutenção, ou então pode sofrer de interferências externas que podem inviabilizar a transmissão de arquivos. Como a empresa em questão está querendo ter um baixo custo de implementação, mas também quer possuir uma boa confiabilidade da rede para que o processo de transferência do arquivo de backup possa ser transferido sem interferências externas, a tecnologia a ser escolhida será a de frame relay, uma vez que ela já é muito difundida pelo mundo e já muito consolidada. Além disso, o frame relay possui a vantagem de ter a manutenção sob responsabilidade das empresas que fornecem este tipo de serviço, devendo garantir a operação contínua, tanto na rede interna (dentro da empresa com a configuração de DTU s e roteadores) como na rede externa (nos postos e centrais de comunicação), fazendo-as responsáveis por todo esse serviço. Com o frame relay, pode-se optar por dois links de 45 Mbps, onde com isso pode-se tentar transferir os dados para o servidor do site backup em até 07 (sete) horas. E como será utilizado um segundo link, caso o primeiro falhe pode-se usar o segundo link para o envio do arquivo de backup de sexta.

27 27 REFERÊNCIAS BIBLIOGRÁFICAS DUPONT, Marco Antônio. Redes Frame Relay Como funcionam. Disponível em: < Acesso em: 26/03/2011. FIGUEIREDO, José Eduardo N. REDES WIMAX. Disponível em: < Acesso em: 26/03/2011. TELECO Inteligência em Telecomunicações. Frame Relay: O que é. Disponível em: < Acesso em: 26/03/2011. UNIVERSIDADE FEDERAL DO RIO DE JANEIRO. Fibras ópticas Conceitos e ConceitoseComposio.html>. Acesso em: 26/03/2011. WIKIPÉDIA A enciclopédia livre. Fibra óptica. Disponível em: < Acesso em: 26/03/2011. Composição. Disponível em: < /