Página 1 de 2 12 ÚltimoÚltimo
Resultados 1 a 10 de 16
  1. #1
    Membro
    Data de Ingresso
    Feb 2014
    Posts
    9

    [DÚVIDA] Configuração Cluster cPanel

    Caros colegas,

    Eu fiz uma busca pelo fórum e não encontrei nada a respeito, ficaria feliz caso pudessem me ajudar.

    Atualmente eu tenho quatro servidores em produção, com planos de hospedagem compartilhada.

    Eu nunca configurei o serviço de Cluster do WHM/cPanel e por isso gostaria da ajuda de vocês.

    Além de utilizar únicos servidores de DNS (ns1 e ns2 por exemplo), na configuração de um cliente de e-mail eu poderei utilizar um único endereço por ex.: mail.meudomínioprincipal.com?

    No meu cenário, onde atualmente cada servidor tem seus DNS, enfrentarei algum problema?

    Poderiam me elencar benefícios e malefícios na utilização deste serviço?

    Obrigado.

  2. #2
    Membro
    Data de Ingresso
    Mar 2014
    Posts
    12
    Olá Miguel,

    O Cluster de Dns permite a sincronização das zonas de dns de forma que você utilize o mesmo nameserver (ns1, ns2 [se quiser ns3 também]) para os domínios do Cluster. A sua vantagem é que se um servidor de dns cair, o outro segura as configurações de dns.
    Note, as "CONFIGURAÇÕES"...

    Digamos que Você tenha o servidor A correspondente ao ns1, servidor B ao ns2, servidor C ao ns3 para o domínio exemplo.com
    Digamos também que o Mx deste cliente seja o Google Apps. Se o servidor A, ou até mesmo dois servidores cairem, o servidor que ficar ativo vai manter as configurações de dns mantendo os apontamentos de MX para o Google Apps e os e-mails continuarão funcionando apesar do site fora do ar.

    Porque eu citei o Google Apps? porque é um cenário, o de se manter um MX externo que é útil o Cluster de dns.
    Sem esta necessidade, se o servidor que está o site e e-mail cair, os apontamentos de dns serão mantidos mas não terão nenhuma utilidade para o funcionamento do serviço do cliente.

    Quanto a sua dúvida de usar "mail.meudomínioprincipal.com" não vai funcionar da maneira que você quer.
    mail.meudominioprincipal.com aponta para um servidor, o A por exemplo,
    por isto ele só será válido para quem usar o servidor A.
    Independente de Cluster ou não, o que o serviço de dns faz é dizer para a internet que o mail.meudominioprincipal.com aponta para o ip do servidor A.


    Uma outra vantagem de usar o cluster é que você mantem sempre os mesmos nameservers para todos os clientes, independente de qual servidor o domínio esteja.
    é bem melhor do que usar ns20/ns21 pra um servidor, ns22/n23 para outro e cada vez que mudar um cliente de servidor ter que pedir para o mesmo mudar o dns no Registro.



    , porém, a sua ideia de utilizar o "mail.meudomínioprincipal.com"

  3. #3
    Membro
    Data de Ingresso
    Mar 2014
    Posts
    12
    moderador, exclui a linha
    , porém, a sua ideia de utilizar o "mail.meudomínioprincipal.com"

    eu estava apenas construindo o texto, ainda não me adaptei a este fórum ;-)

  4. #4
    Moderador
    Data de Ingresso
    Oct 2010
    Localização
    Rio de Janeiro
    Posts
    2,679
    O cluster dele é só de DNS, ele não faz clustering de outros serviços...

  5. #5
    Membro
    Data de Ingresso
    Mar 2014
    Posts
    12
    Citação Postado originalmente por cresci Ver Post
    O cluster dele é só de DNS, ele não faz clustering de outros serviços...
    Apenas exemplifiquei para ele compreender onde o uso de cluster de dns terá mais utilidade. E por mais que ele não faça cluster de dns com outros serviços sempre tem clientes que optam por ter um MX externo e informar que sua estrutura mantém um Cluster de dns é uma vantagem.

  6. #6
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,030
    Vou ignorar esse papo de cluster porque cheira e parece BS, e das grandes.

    Vamos ao básico, e sem desenhar.

    Pela sua importância, o sistema (DNS) foi projetado com redundância em mente. Já estou com a lingua sangrando de tanto repetir que não existe essa de master/slave ou primário/secundários do ponto de vista do cliente do serviço. Todos os nameservers devem estar disponiveis para serem consultados e todos são consultados. Qual nameserver é a "bola da vez" para uma determinada query é resultado de circunstâncias que geralmente não estão no controle do provedor do serviço. Não existe esse negócio de "se um servidor de dns cair, o outro segura". Todos estão ativos e todos estão sendo usados. Por sua vez, é erronea a idéia que "se todos os meus serviços estão no mesmo servidor, não tem sentido ter mais de um DNS" ou "só faz sentido se você tiver serviços em outros servidores" porque o servidor intermediário que realiza a consulta ao seu nameserver auth pode não estar na mesma rede que a do computador (usuário) que faz a query. É perfeitamente possivel, normal até, que o intermediário (cache server) temporariamente não tenha acesso a um determinado nameserver mas o cliente (usuário do serviço, pessoa ou programa) tenha acesso normal ao servidor, e vice-versa -- com nameservers adicionais, o cache server poderá resolver a query usando uma outra rota (para outro(s) nameserver).
    Última edição por 5ms; 14-04-2014 às 18:18.

  7. #7
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,030
    Desenhando.

    Você tem um VPS em Cape Town, na Africa do Sul, rodando Web e Bind. O visitante do seu site, que mora em Cape Town, ouviu falar que usando o Google Public DNS (8.8.8.8) faz que o acesso fique mais rápido. Então ele substitui a configuração do computador e deixa de usar o serviço local da "porcaria da operadora". Só que o Google não tem servidores (8.8.8.8) na África. Cada solicitação é processada na Bélgica, por exemplo. Ora, se o computador do visitante em Cape Town não conseguir acessar o serviço do Google na Bélgica, ou se de lá o servidor do Google não conseguir acessar o seu VPS (ou ocorrer timeout), a query não será resolvida embora o seu VPS esteja no ar, e o visitante local, que não teria o mesmo problema de acesso, reclamaria que o seu site está fora do ar.

  8. #8
    Super Moderador
    Data de Ingresso
    Sep 2010
    Localização
    Procurando...
    Posts
    4,106
    Siga-nos em nosso twitter: @wht_brasil

  9. #9
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,030
    Sim, e sempre tem alguém imaginando secundário como failover, standby.

  10. #10
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    15,030
    A DNS server (the computer/software) is not specifically "primary" or "secondary".

    A single DNS server can be configured to host zero, one or multiple zones.

    A DNS server can be primary for one zone ("domain") and secondary for another.

    Each zone is anchored at a specific domain name referred to as the zone’s root domain. A zone contains information about all names that end with the zone’s root domain name. A DNS server is considered authoritative for a name if it loads the zone containing that name.

    Primary is a zone to which all updates for the records that belong to that zone are made. A secondary zone is a read-only copy of the primary zone. A stub zone is a read-only copy of the primary zone that contains only the resource records that identify the DNS servers that are authoritative for a DNS domain name. Any changes made to the primary zone file are replicated to the secondary zone file. DNS servers hosting a primary, secondary or stub zone are said to be authoritative for the DNS names in the zone.

    As mentioned above, a DNS server can host multiple zones. A DNS server can therefore host both a primary zone (which has the writeable copy of a zone file) and a separate secondary zone (which obtains a read-only copy of a zone file).

    A DNS server hosting a primary zone is said to be the primary DNS server for that zone, and a DNS server hosting a secondary zone is said to be the secondary DNS server for that zone.

    The process of replicating a zone file to multiple DNS servers is called zone transfer. Zone transfer is achieved by copying the zone file from one DNS server to a second DNS server. Zone transfers can be made from both primary and secondary DNS servers.

    A master DNS server is the source of the zone information during a transfer. The master DNS server can be a primary or secondary DNS server. If the master DNS server is a primary DNS server, then the zone transfer comes directly from the DNS server hosting the primary zone. If the master server is a secondary DNS server, then the zone file received from the master DNS server by means of a zone transfer is a copy of the read-only secondary zone file.

    The zone transfer is initiated in one of the following ways:

    • The master DNS server sends a notification (RFC 1996) to one or more secondary DNS servers of a change in the zone file.
    • When the DNS Server service on the secondary DNS server starts, or the refresh interval of the zone has expired, the secondary DNS server will query the master DNS server for the changes.



    Types of Zone File Replication

    There are two types of zone file replication. The first, a full zone transfer (AXFR), replicates the entire zone file. The second, an incremental zone transfer (IXFR), replicates only records that have been modified.


    RFCs for the DNS Server Service

    Request for Comments (RFCs) are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. Domain Name System (DNS) specifications are based on approved RFCs published by the Internet Engineering Task Force (IETF) and other working groups.

    The following RFCs can be found in the IETF RFC Database. These documents contain specifications used to design and implement the DNS Server service and DNS Client service.

    RFC 1034 -- Domain Names — Concepts and Facilities

    RFC 1035 -- Domain Names — Implementation and Specification

    RFC 1123 -- Requirements for Internet Hosts — Application and Support

    RFC 1886 -- DNS Extensions to Support IP Version 6

    RFC 1995 -- Incremental Zone Transfer in DNS

    RFC 1996 -- A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

    RFC 2136 -- Dynamic Updates in the Domain Name System (DNS UPDATE)

    RFC 2181 -- Clarifications to the DNS Specification

    RFC 2308 -- Negative Caching of DNS Queries (DNS NCACHE)

    RFC 2535 -- Domain Name System Security Extensions (DNSSEC)

    RFC 2671 -- Extension Mechanisms for DNS (EDNS0)

    RFC 2782 -- A DNS RR for specifying the location of services (DNS SRV)

    Internet Drafts for DNS

    The following Internet drafts contain specifications used to design and implement the DNS Server service and DNS Client service:

    Draft-skwan-utf8-dns-02.txt -- Using the UTF-8 Character Set in the Domain Name System

    Draft-ietf-dhc-dhcp-dns-08.txt -- Interaction between DHCP and DNS

    Draft-ietf-dnsind-tsig-11.txt -- Secret Key Transaction Signatures for DNS (TSIG)

    Draft-ietf-dnsind-tkey-00.txt -- Secret Key Establishment for DNS (TKEY RR)

    Draft-skwan-gss-tsig-04.txt -- GSS Algorithm for TSIG (GSS-TSIG)

    Other Specifications for DNS

    The following additional specification is used to design and implement the DNS Server service and DNS Client service. This specification is published by the ATM Forum. You can obtain this specification by downloading it from the ATM Forum FTP site.

    af-saa-0069.000.doc -- ATM Name System Specification version 1.0
    Última edição por 5ms; 15-04-2014 às 09:31.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •