Pooling de servidor confiável

O Reliable Server Pooling (RSerPool) é uma estrutura de protocolo para a administração de pools de servidores e para a implementação de sessões lógicas de clientes com esses pools. Como parte do gerenciamento de sessão, RSerPool assume em particular a seleção de um servidor do pool (distribuição de carga, balanceamento de carga) e, se o servidor falhar, a transição (failover) para um servidor substituto no pool. RSerPool foi desenvolvido pelo grupo de trabalho IETF RSerPool e estabelecido em RFC 5351 a RFC 5356 como um padrão da Internet em setembro de 2008 .

Ideia básica de RSerPool

Com certos aplicativos cliente / servidor, danos muito elevados podem resultar de falha do servidor. No caso de e-commerce, z. B. os clientes potenciais simplesmente outro provedor. Para poder continuar fornecendo o serviço crítico mesmo em caso de falha do servidor, a redundância do servidor é necessária. Ou seja, existem pelo menos dois servidores; se um deles falha, outro simplesmente assume suas funções.

O objetivo do Reliable Server Pooling, que está sendo padronizado pelo grupo de trabalho IETF RSerPool, é um procedimento unificado para gerenciar pools de servidores (servidores podem, por exemplo, ser adicionados ou removidos dinamicamente do pool) e para acesso de clientes a as piscinas. Da perspectiva do aplicativo cliente, um pool de servidores é um servidor lógico para o qual uma sessão é estabelecida. RSerPool cuida da seleção do servidor (especialmente da distribuição da carga), estabelecimento da conexão, monitoramento da conexão e nova seleção de um servidor em caso de erro.

Descrição mais detalhada do RSerPool

Reliable Server Pooling ( RSerPool ) é uma estrutura de protocolo para a administração e acesso a pools de servidores . Atualmente, está sendo padronizado pelo grupo de trabalho IETF RSerPool.

Na terminologia do RSerPool, os servidores são referidos como elementos do pool (PE). O conjunto de todos os PEs que oferecem o mesmo serviço formam um pool. Um PE é identificado dentro de um pool por um identificador de elemento de pool de 32 bits (PE ID). O PE ID é determinado aleatoriamente quando um PE se registra em um pool. A totalidade de todos os pools é chamada de espaço de manuseio . Em publicações anteriores, o termo também pode ser namespace. A renomeação foi feita para evitar confusão com o Sistema de Nomes de Domínio . Cada conjunto em um espaço de manuseio é identificado por um identificador de conjunto exclusivo (PH), que é um vetor de bytes selecionado aleatoriamente. Normalmente, é um nome em codificação ASCII ou Unicode, como "DownloadPool" ou "WebServerPool".

Cada espaço de manuseio tem uma área limitada de aplicação (escopo de operação, por exemplo, uma organização ou empresa). Não é explicitamente um objetivo desejável do RSerPool gerenciar todos os pools globais em um único espaço de manuseio. Devido à importância local da área de aplicação, é possível manter o espaço da alça "plano". Isso significa que não há hierarquia para PHs - em contraste com o Sistema de Nomes de Domínio com seu nível superior - e subdomínios. Esse contraste leva a uma simplificação significativa do gerenciamento do espaço da alça.

Um espaço de manipulação é gerenciado por registradores de pool redundantes (PR) em uma área de aplicativo . Os PRs também são conhecidos como servidores ENRP ou servidores de nomes (NS). Sua redundância é necessária para que um único PR não se torne um ponto único de falha (SPoF). Cada PR de uma área de aplicação é identificado com seu ID de Registrador (PR ID), um número aleatório de 32 bits. Não é necessário garantir a exclusividade dos IDs de PR. Um PR contém uma cópia completa do espaço de manuseio de uma área de aplicação. Os PRs de uma área de aplicação comparam sua visão do espaço de manuseio usando o Endpoint Handlespace Redundancy Protocol (ENRP). Versões mais antigas desse protocolo são chamadas de Protocolo de Redundância de Espaço de Nomes de Endpoint; esta designação foi substituída para evitar confusão com DNS. Como o espaço de manuseio é sincronizado pelo ENRP, a funcionalidade dos PRs é idêntica dentro de uma área de aplicação. Isso significa que as tarefas de um PR que já não pode ser alcançado podem ser assumidas por qualquer outro PR na área de atividade.

Usando o Aggregate Server Access Protocol (ASAP), um PE pode se adicionar a um pool ou fazer logoff de seu pool novamente. Qualquer RP da área de aplicação pode ser usado para isso. Em caso de sucesso no cadastramento, o PR selecionado pelo PE passa a ser o PR domiciliar do PE (PR-H). O PR-H não apenas informa aos outros PRs que seus PEs foram registrados ou cancelados, mas também monitora a disponibilidade de seus PEs por meio de mensagens keep-alive . Uma mensagem keep-alive de seu PR-H deve ser confirmada por um PE dentro de um determinado período de tempo. Se o PE não responder dentro de um período de tempo especificado, ele será considerado não mais acessível e será imediatamente removido do espaço de manuseio. Além disso, espera-se que um PE se registre regularmente novamente. Com esse novo registro, também é possível para um PE atualizar a lista de seus endereços de transporte e outras informações.

Um cliente de um pool é referido como um usuário de pool (PU) na terminologia RSerPool . Para usar o serviço de pool, ele pede a qualquer PR na área de aplicação que resolva o PH do pool em uma lista de identidades PE. Este processo é conhecido como resolução de identificador. Se o pool existir, o PR seleciona a lista desejada de identidades PE com base na regra de seleção especificada para o pool ( política de seleção de membros do pool, abreviadamente conhecida como política de pool ).

As políticas de pool possíveis são, por exemplo, random (random), round robin ou PEs com a utilização mais baixa (menos usada). Embora nenhuma informação adicional sobre os PEs seja necessária nos primeiros dois casos (políticas não adaptativas), as informações de carga atuais nos PEs são necessárias para a seleção menos usada (política adaptativa). Embora isso exija atualizações regulares dos dados de status (por meio de novo registro), também pode obter uma distribuição de carga significativamente melhor no pool.

Depois de receber uma lista de identidades PE do PR, um PU pode gravar essas identidades PE em seu cache local. Essa memória também é conhecida como cache do lado da PU. A partir desse cache, o PU agora, por sua vez, seleciona exatamente um PE com base na política de pool. Em seguida, ele estabelece uma conexão com este PE selecionado usando o protocolo do aplicativo - por exemplo, B. HTTP sobre SCTP ou TCP no caso de um servidor web - e então usa a aplicação real do servidor. Se a configuração da conexão falhar ou se a conexão for interrompida enquanto o serviço está sendo usado, um novo PE é discado. Se as informações no cache não estiverem desatualizadas, o cache pode ser usado diretamente para seleção. Caso contrário, uma nova solicitação de resolução de identificador com um PR é necessária e todo o processo é repetido. Se uma conexão a um novo PE for finalmente estabelecida, o status da sessão interrompida deve ser restaurado no novo PE. O procedimento a ser executado para isso é conhecido como procedimento de failover e é específico do aplicativo. No caso de um download de FTP , por exemplo B. o nome do arquivo e a última posição do arquivo recebido podem ser comunicados ao novo PE. O novo PE é então capaz de continuar o download no ponto de interrupção.

Para permitir que PEs e PUs encontrem PRs automaticamente, os PRs podem enviar anúncios por UDP via multicast IP . Ao ouvir as mensagens de anúncio em um grupo multicast definido, os PEs e PUs são então capazes de aprender uma lista dos PRs atualmente disponíveis em seu domínio multicast. Ao usar multicast em vez de broadcast, o mecanismo também funciona além dos limites do roteador. No caso de uma Ethernet comutada, também se consegue que as mensagens multicast sejam encaminhadas apenas para as portas através das quais estão ligados os dispositivos que realmente têm interesse nelas. Se multicast não estiver disponível, os endereços PR devem ser configurados estaticamente.

Implementações

As seguintes implementações de RSerPool são conhecidas atualmente:

Documentos de padronização

RFCs

  • RFC 3237 - Requisitos para pool de servidores confiáveis
  • RFC 5351 - Uma visão geral dos protocolos de pooling de servidores confiáveis
  • RFC 5352 - Aggregate Server Access Protocol (ASAP)
  • RFC 5353 - Endpoint Handlespace Redundancy Protocol (ENRP)
  • RFC 5354 - Parâmetros do protocolo Aggregate Server Access (ASAP) e Endpoint Handlespace Redundancy Protocol (ENRP)
  • RFC 5355 - Ameaças introduzidas por Reliable Server Pooling (RSerPool) e requisitos de segurança em resposta a ameaças
  • RFC 5356 - Políticas de pool de servidores confiáveis
  • RFC 5525 - Definição de Módulo MIB de Pooling de Servidor Confiável

Rascunhos do Grupo de Trabalho

Mais rascunhos

Links da web

Evidência individual

  1. ↑ a b Regulamento do pool de servidores confiáveis ​​(rserpool). 19 de fevereiro de 2006, acessado em 3 de outubro de 2019 .