Serviços de rede de aplicativos : Switches de serviços de conteúdo Cisco CSS 11500 Series

Considerações de configuração e compatibilidade do armazenamento em cache do CSS 11000

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento é uma diretriz para de pôr em esconderijo e considerações de compatibilidade da determinação ao executar o Cisco Content Services comuta (CSS) 11000/11500.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes da seguinte informação:

  • O gateway padrão do esconderijo deve ser o CSS.

Componentes Utilizados

Esta informação aplica-se a toda a liberação de software webns running 3.0x de Cisco CSS (11000 & 11500) ou mais altamente.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Configuração de cache

Switch de camada 2 versus Switch de fluxo

O CSS é um interruptor de fluxo, ao contrário de um interruptor da camada 2 (L2). Um interruptor de fluxo traça fluxos às portas baseadas na informação IP, ao contrário da informação da camada de MAC como em um interruptor L2. A funcionalidade de switch de fluxo é o que permite que o CSS tenha conteúdo inteligente e analise o pacote SYN (sincronização/início de TCP) ou o HTTP GET e tome decisões sobre conteúdo, ao contrário de apenas encaminhar os quadros. Em pôr em esconderijo ambientes, o interruptor de fluxo exige que você distribui todos os pacotes que vêm do esconderijo destinado aos clientes.

Roteamento

Como o CSS deve ser o gateway padrão para o cache e rotear todos os pacotes do cache, o CSS deve ter uma tabela de roteamento completa.

Serviços

Ao configurar um serviço como tipo de cache transparente, o CSS regrava o endereço MAC de destino cim o MAC do cache e encaminha os pacotes IP ao cache para preservar o endereço IP de destino. Se o esconderijo não pode escutar promiscuously todo o tráfego da porta 80, a seguir você deve configurar o esconderijo como o tipo cache de proxy; contudo, os serviços proxy-cache não podem usar o método do Failover do desvio. Como você fez o encaminhamento MAC dos pacotes para o cache, ele deve ser conectado diretamente à caixa. Se isso não puder ser realizado, ele deverá ser conectado, por meio de um dispositivo L2 que não pode ser compartilhado, com o cliente ou com uma conexão com a Internet.

Quando um serviço é configurado como proxy-cache ou transparent-cache, é criada uma lista de acesso (ACL) invisível e automática que permite ao IP de origem do cache ignorar todas as regras de conteúdo para poder obter páginas do servidor de origem. Começando na versão webns 4.0, você pode inscrever o comando no cache-bypass para o cache transparente e os serviços proxy-cache a fim desabilitar o desvio automático das regras de conteúdo.

Você não pode ter dois CSS vivo, cada um com o um esconderijo anexado diretamente, equilíbrio da carga os dois esconderijos quando configurado como o tipo cache transparente, a menos que cada esconderijo tiver uma conexão a cada interruptor diretamente. Um interruptor obterá o pedido do cliente e então escolhê-lo-á talvez servir o pedido ao esconderijo conectado ao outro interruptor, que consideraria então o pedido entrar e o combinar contra sua regra e talvez para decidir a servir ao esconderijo conectado ao primeiro interruptor. Como esses pacotes são encaminhados de MAC, não há nenhuma forma para construir uma ACL para fazer isso corretamente.

Camada 4 versus camada 5

Uma regra está considerada ser a camada 5 (L5) quando a informação exigida para combinar a regra ou para fazer a decisão do Balanceamento de carga não está no TCP SYN, mas está no HTTP GET; consequentemente, quando você adiciona uma URL, um método de equilíbrio do domínio, a mistura de domínios, ou a mistura URL, a regra é automaticamente L5 e induz a falsificação. A falsificação é uma vantagem mesmo quando não é um requisito pois protege o cache contra ataques de inundação de SYN. Uma configuração L5 permite o Extension Qualifier List (EQL) e o desvio do Failover, que causa à caixa ao spoof uma conexão com o servidor de origem, ao contrário do esconderijo. Quando uma regra de conteúdo é considerada L5, isso significa que CSS falsifica as conexões com os clientes.

Assimetria

Se há uma rota de volta aos clientes do servidor de origem que não passa com o CSS, a seguir você tem a assimetria, se não conhecido como o triangulação. Se você está usando as regras L5 e há um desvio, as paródias da caixa uma conexão com o servidor de origem, e o caminho de retorno vão diretamente ao cliente, onde é deixado cair então muito rapidamente desde que o cliente não reconhece o número de sequência. É preciso corrigir a assimetria, enviar tudo para o cache e usar failover linear, ou usar o peer NAT para traduzir os endereços IP de clientes em grupos de origem.

Equilíbrio

Recomenda-se que você usa o método de equilíbrio da mistura de domínios e da mistura URL. A mistura de domínios faz uma mistura em todos os caracteres especiais do host e, em seguida, determina qual servidor deve servir aquele domínio, permitindo uma carga com distribuição mais uniforme. O método de equilíbrio de hash de URL funciona similarmente ao método de hash de domínio, mas utiliza a URL como fonte de dados em oposição à etiqueta do host.

Ao usar um cache de proxy de tipo de serviço, balanceamos com base no primeiro GET de uma conexão persistente e, contanto que o segundo GET corresponda à mesma regra, não rebalanceamos, o que poderia fazer com que alguns enlaces fossem duplicados nos entre os caches (consulte a seção pré-produção abaixo). No WebNS 4.0, é possível configurar o CSS para romper a conexão persistente e rebalancear através do comando no persistent command na regra de conteúdo. Sempre que emitir o comando de persistência, talvez seja conveniente usar o comando persistence reset remap do WebNS 4.0. O comando persistence reset é usado para determinar como as conexões persistentes devem ser quebradas. O padrão é a restauração da persistência reorienta, que faz com que o CSS envie um TCP Reset e um HTTP 302 reorienta ao cliente, forçando o cliente a estabelecer uma nova conexão. O Internet Explorer (IE) 5.0 tem problemas conhecidos para receber múltiplos redirecionamentos no mesmo domínio. O remapeamento de redefinição de persistência preserva a conexão do cliente e move a conexão no plano de fundo de um servidor para outro.

Failover

Quando uma regra de conteúdo é formada de serviços que são do tipo cache transparente e usam um dos métodos de balanço de cache, o método de desvio de failover pode ser usado para permitir que as requisições destinadas para um cache específico sejam encaminhadas ao servidor de origem se o cache for desativado. Refira a edição da assimetria acima.

Desvio de EQL

O CSS pode ser configurado com uma lista de extensões de arquivo a serem enviadas para o cache. Essa lista é chamada de EQL. Se você anexar um EQL à linha de URL em uma regra de conteúdo, a regra combinará somente as requisições com extensões de arquivo presentes na lista. O CSS pode igualmente ser configurado para contornear um EQL mudando o aplicativo na regra de conteúdo contornear. No WebNS 4.0, caso deseje que o CSS encaminhe cada solicitação em uma conexão persistente ao destino apropriado, com base em um EQL, é necessário emitir o comando no persistent na regra de conteúdo. Uma vez que a regra de conteúdo esteve contorneada, se você quer o seguinte consiga na conexão persistente ser enviado ao esconderijo se é em cache, a seguir você precisa de emitir o comando webns 4 0 bypass persistence disable global. Sempre que desabilita a persistência, você deseja emitir o comando global persistence reset remap 4.0 para evitar problemas com IE 5.0.

Desvio de cache

Alguns esconderijos têm a capacidade para configurar uma lista de locais que devem ser contorneados pelo esconderijo. O CSS é incompatível com a funcionalidade de desvio da maioria dos caches. O CSS permite a configuração de NQLs (Listas qualificadoras de rede), o que permite a configuração de uma lista de endereços IP ou redes que podem ser incluídos em uma cláusula única em um ACL.

Recurso de desvio de parâmetros de URL

O CSS pode ser configurado para contornear automaticamente todas as URL que tiverem parâmetros. Essas são requisições que um cache nunca pode atender (por exemplo, cotações de ações).

Recurso de busca prévia

Ao proporcionar um serviço de cache aos clientes, a variável que cria o grande atraso no tempo de resposta é quando o esconderijo não contém a página que está sendo pedida, porque então tem que ir a recuperar. O objetivo de esconderijos do Balanceamento de carga é aumentar a probabilidade de um hit de cache. Alguns caches possuem um recurso chamado busca prévia, que permite que o cache analise os dados retornados da solicitação de aquisição inicial e obtenha de forma proativa objetos naquela página antes que o cliente as solicite explicitamente. Às vezes, isto pode levar a uma utilização extra do backbone da Internet caso o cliente tivesse que interromper o carregamento da página, mas isto, provavelmente, significa uma quantidade de tráfego desprezível.

Se você está usando o cache transparente, a seguir a característica do desvio EQL no CSS quebra o algoritmo dos recursos de pré-fetch porque, à revelia, o EQL não inclui o Home Page, que é simplesmente um GET para “/.” Sem a home page principal de um site, o cache não tem uma página principal da qual trabalhar para a pré-busca. Em segundo lugar, se não enviarmos solicitações dinâmicas para o cache, haverá solicitações em duplicata indo para o servidor de origem, uma do CSS e outra do cache. O cliente deve decidir quais são as metas e, em seguida, determinar qual funcionalidade de cada produto deseja combinar.

Em locais onde múltiplos caches são distribuídos, o balanceador de carga deve tentar ao máximo garantir um hit de cache. O CSS tem vários algoritmos de balanceamento de carga que foram projetados para otimizar o número de acertos de cache. Desde que o interruptor é um interruptor L5, pode olhar a informação no HTTP GET que outros equilibradores da carga não podem. Por exemplo, podemos determinar para qual cache enviar uma solicitação, com base no nome de domínio ou no URL que está sendo solicitado. Se você fosse usar o algoritmo de hash de domínio, todas as solicitações de conteúdo que tivessem rótulos de host idênticos seriam enviadas para o mesmo cache, aumentando, portanto, a possibilidade de que o conteúdo residisse naquele cache. Ao usar recursos de pré-fetch com caches transparente, o esconderijo está indo ir obtém o pedido antes do interruptor que envia o pedido a ele, que pode causar para que o esconderijo errado vá obtém a página. Nesse exemplo, é possível que você queira desabilitar o exame prévio.

Ao discutir proxy cache, o cabeçalho IP não fornece verdadeiramente a informação válida para o Balanceamento de carga de um modo para prever aperfeiçoar o número de hit de cache; o endereço IP de destino não muda. A única informação válida seria o endereço IP de origem, que não significa nada realmente quando se trata de surfar na Internet. O interruptor pode ainda ver a etiqueta e a informação de URL do host para fazer estas decisões. Desde que os proxy cache mantêm tipicamente uma conexão persistente com o cliente, o interruptor faz somente a decisão do Balanceamento de carga baseada no primeiro HTTP GET, e todos os GET subsequentes vão ao mesmo esconderijo. Como não interrompemos a conexão persistente, isso funciona bem com o recurso de busca prévia para todos os GETS subseqüentes na mesma conexão. Começando na liberação 4.0 de WebNS, você pode configurar o CSS para quebrar estas conexões se você deseja assim emitindo o comando no persistent.


Informações Relacionadas


Document ID: 12574