Resolvendo Todos Os Problemas Do Windows E Outros Programas

Como manter seu site em um desastre com um plano de redirecionamento de DNS

Em um artigo anterior, discuti como usar o Border Gateway Protocol (BGP) para redirecionar rotas pode ser um método eficaz para manter os serviços da Web no caso de o site host ficar inacessível.

Embora complicado, esse método é eficaz se implementado de maneira adequada. No entanto, um método mais simples usando o Domain Name Service (DNS) para redirecionar as consultas do servidor da Web também pode fornecer uma presença básica na Web quando o data center principal está offline. Eu preparei um plano para esse método e logo tive que colocá-lo em prática para ajudar uma empresa parceira em apuros. Veja como eu fiz.



Ajustando DNS



Até agora, concentrei-me em redirecionar o endereço IP do servidor da Web para outra rede. Sempre que você mexe com as tabelas de rota, coisas ruins podem acontecer, e muitas vezes acontecem. Seguindo a rota oposta e mudando o endereço IP para o qual o registro www A (endereço) aponta, você não é prejudicado pela localização do servidor Web temporário. Ele pode ser literalmente colocado em qualquer lugar, sem redirecionar as redes IP.

A solução DNS também requer algum trabalho de preparação e, embora não seja muito difícil, é vital. O DNS depende de servidores primários e secundários para ter autoridade para um domínio específico (neste caso, example.abc). Desde que pelo menos um desses servidores esteja localizado fora da zona de desastre e seja publicado como autoritativo para a zona example.abc, o registro www A pode ser alterado e propagado para outros servidores DNS. Nesse caso, presume-se que todos os servidores DNS autorizados, exceto um (o servidor DNS secundário remoto) para a zona example.abc, estão localizados na rede afetada e, portanto, estão inacessíveis.



Esperançosamente, durante o desastre, o administrador do domínio tem alguma conectividade de rede (seja por modem celular, linha fixa ou em um local físico não afetado pelas interrupções) para acessar o servidor DNS secundário remoto. Se o site remoto estiver executando o Berkeley Internet Name Domain (BIND) no Linux, o Secure Shell (SSH) precisa ser habilitado; O Windows executando o servidor DNS da Microsoft deve ter a Área de Trabalho Remota ativada.

especificação mínima para windows 7

Se o acesso não for possível, um administrador de site remoto deve estar acessível por telefone para transmitir as instruções. Se as comunicações de voz não forem possíveis, o administrador remoto pode ser instruído com antecedência sobre as alterações necessárias para apontar o URL para o novo local. Obviamente, é importante comunicar esses planos (incluindo senhas) antes de um desastre.

Idealmente, o local remoto também deve ser o host do servidor Web de emergência (como Apache no Linux, IIS na Microsoft ou outro pacote de servidor Web) para que o administrador remoto possa postar mensagens de emergência, bem como fazer alterações de DNS, mas isso não é necessário. Em outras palavras, os dois podem ser separados e, na verdade, isso permite que vários sites sejam preparados com antecedência.



Então, quais são as mudanças? Primeiro, se o servidor DNS remoto não for o principal para o domínio (e na maioria dos casos não deveria estar em um ambiente normal), promova-o para ser o principal. Em segundo lugar, altere o registro www A para o novo endereço IP. Na Microsoft, clique com o botão direito do mouse no registro e altere as propriedades. Com BIND, o pacote nsupdate pode ser usado para excluir o registro www e inserir um novo.

Tempo de Viver

netstart a

Independentemente da plataforma DNS, a variável Time To Live (TTL) deve ser definida como 3600. Este é o número de segundos que outros servidores DNS são informados para armazenar em cache o registro wwww. Para entender isso completamente, é necessária uma breve revisão sobre como o DNS funciona.

Se um usuário na Internet deseja acessar www.example.abc, depois que o usuário coloca esse URL no navegador da Web, seu computador faz uma consulta DNS ao (s) servidor (es) DNS configurado (s) na máquina cliente para resolver www.example. abc para um endereço IP. Observe que os clientes geralmente não configuram manualmente seus parâmetros DNS; isso é realizado por meio do protocolo de configuração dinâmica de hosts (DHCP).

Se o ISP do cliente não contiver o registro em seu cache, ele consultará um dos servidores DNS publicados para o domínio example.abc. A quantidade de tempo que um registro é armazenado em cache é determinada pelo TTL. Por padrão, a maioria dos servidores DNS atribuem um TTL de 86400 a todos os registros; este é o número de segundos antes que a entrada em cache expire. Esse padrão é encontrado no registro Start of Authority (SOA).

A importância do TTL deve ser óbvia, pois determina a rapidez com que uma alteração de DNS se propaga pela Internet. Como 86.400 segundos denota um dia, pode ser preferível configurar o registro www A normal com um TTL de 3.600 segundos. Dessa forma, pode-se ter certeza de que o novo registro www A se propagará por toda a Internet em uma hora. Isso é obrigatório quando o objetivo é estabelecer uma presença de emergência na Web o mais rápido possível.

Outras configurações de TTL de DNS para cache de resposta positiva e negativa de zona também podem ser ajustadas. Eles estarão contidos no registro SOA. No entanto, como a habilitação de um servidor Web temporário requer a alteração de apenas um registro, geralmente é melhor deixar os padrões da zona inteira como estão.

Você deve garantir, entretanto, que o número de série no SOA para a zona na qual o registro www reside seja incrementado. Normalmente, isso ocorre automaticamente ao usar a ferramenta adequada para fazer alterações de registro (por exemplo, nsupdate no Linux). No entanto, se editar manualmente o arquivo de zona, o número de série deve ser incrementado e o processo do servidor DNS reiniciado.

remover ícones da barra de tarefas do mac

A partir deste ponto, obter as informações necessárias é tão simples quanto editar um arquivo HTML no novo servidor web. Este não é um momento para gráficos ou bancos de dados chamativos. A comunicação simples de status, planos e números de telefone de contato de emergência pode ajudar muito na recuperação.

O teste

Pouco depois de criar e implementar este plano, surgiu uma situação em que uma empresa parceira foi tirada do ar por causa de uma grande interrupção de energia e instalações. Essa empresa hospedava seu servidor DNS primário no local e seu ISP gerenciava o servidor DNS secundário da empresa. A empresa parceira, tendo ouvido falar de meu plano, perguntou-me se havia um método para redirecionar rapidamente seu site para fornecer informações de emergência em tempo hábil.

Entrei em contato com o ISP e expliquei ao administrador de DNS o conceito de redirecionamento de DNS. Embora o TTL do registro www A da empresa tenha sido definido para o padrão de um dia, estava claro que a hospedagem na Web não seria possível no site danificado por possivelmente uma semana. Portanto, até mesmo um atraso de até um dia no redirecionamento era preferível a ficar off-line por uma semana.

O ISP se recusou a hospedar um site temporário. Portanto, sugeri criar um servidor temporário no site corporativo principal e redirecionar o registro www para o IP desse servidor. Novamente, neste caso, um servidor Web robusto não era necessário, pois uma simples página explicando a situação era tudo o que era necessário.

Um servidor Microsoft Windows 2003 executando o IIS como um servidor Web de teste foi recomissionado como o servidor Web de emergência. O acesso remoto para o administrador da Web da empresa parceira foi concedido por meio da Área de Trabalho Remota. As alterações de DNS foram feitas e, em poucas horas, o site estava no ar. Concedido, por causa do problema de TTL, alguns usuários não conseguiam acessar o site da empresa parceira a princípio. Mas, à medida que as mudanças de DNS se propagavam, mais clientes podiam acessar a página, até que o acesso completo fosse obtido em um dia.

Depois que a emergência passou, pedi ao ISP para alterar o registro www A para o endereço IP original e, como o TTL do registro de emergência era 3600, as novas informações se propagaram em uma hora. A crise acabou, as operações normais foram retomadas e alguma continuidade de negócios foi mantida durante a crise porque informações críticas estavam disponíveis durante a paralisação.

Resumo

do que são feitos os microchips

Embora eu tenha certeza de que existem vários métodos para fornecer serviços básicos da Web de emergência, para mim o método de redirecionamento de DNS provou ser o mais econômico e fácil de implementar. Como afirmei no início do artigo anterior, gostaria que houvesse um plano a ser seguido quando fui incumbido de me preparar para tal situação. Ao relacionar essas experiências, meu objetivo é preencher esse vazio, fornecendo dois roteiros possíveis para alcançar uma solução aceitável.