|
Campo
|
Descrição
|
|
Endereço IP
|
Digite um novo endereço IP Virtual para ser o ponto de entrada alvo para acessar o Servidor Real. Esse IP é onde os usuários ou aplicações vão apontar para acessar a aplicação balanceada de carga.
|
|
Subrede Máscara/Prefixo
|
Este campo é para a máscara de sub-rede relevante para a rede na qual o ADC está localizado.
|
|
Porto
|
O porto de entrada utilizado para o acesso ao VIP. Esse valor não precisa necessariamente ser o mesmo que o Real Server se o senhor usar o Reverse Proxy.
|
|
Nome do serviço
|
O nome do serviço é uma representação textual do propósito do VIP. É opcional, mas recomendamos que o senhor o esclareça.
|
|
Tipo de serviço
|
Há muitos tipos diferentes de serviços disponíveis para que o senhor possa selecionar. Os tipos de serviço de camada 4 não podem usar a tecnologia flightPATH.
|
|
Campo
|
Descrição
|
|
Atividade
|
O campo de atividade pode ser usado para mostrar e mudar o status do servidor real balanceado de carga.
Online - Denota que o servidor está ativo e recebendo pedidos de balanceamento de carga
Offline - O servidor está offline e não está recebendo pedidos
Drenagem - O servidor foi colocado em modo de drenagem, de modo que a persistência pode ser nivelada e o servidor passou para um estado off-line sem afetar os usuários.
Standby - O servidor foi colocado em estado de espera
|
|
Endereço IP
|
Esse valor é o endereço IP do Real Server. Ele deve ser preciso e não deve ser um endereço DHCP.
|
|
Porto
|
O porto alvo de acesso no Real Server. Quando se usa um proxy reverso, isso pode ser diferente do porto de entrada especificado no VIP.
|
|
Ponderação
|
Essa configuração geralmente é configurada automaticamente pela ADC. O senhor pode mudar isso se desejar alterar a ponderação de prioridade.
|
|
Opção
|
Descrição
|
|
Cluster
|
Cluster é o papel padrão do ADC na instalação, e a coluna Principal/Modo indicará o modo em que ele está funcionando atualmente. Quando o senhor tiver um par de aparelhos do ADC em seu centro de dados, um deles mostrará Ativo e o outro Passivo.
|
|
Manual
|
O papel do Manual permite que o par ADC funcione em modo Ativo-Ativo para diferentes endereços IP virtuais. Nesses casos, a coluna primária conterá uma caixa ao lado de cada IP Virtual único que pode ser marcado para Ativo ou deixado sem marcar para Passivo.
|
|
Stand-Alone
|
O ADC está agindo como um dispositivo autônomo e não está no modo de Alta Disponibilidade. Como tal, a coluna Primária indicará autônoma.
|
|
LED
|
Significado
|
|
l
|
Online
|
|
l
|
Failover-Standby. Este serviço virtual é hot-standby
|
|
l
|
Indica que um "secundário" está se atrasando para um "primário".
|
|
l
|
O serviço precisa de atenção. Essa indicação pode resultar de um servidor real falhar em um exame de monitoramento de saúde ou ter sido mudado manualmente para Offline. O tráfego continuará a fluir, mas com capacidade reduzida do Real Server
|
|
l
|
Fora de linha. Os servidores de conteúdo são inacessíveis, ou não há servidores de conteúdo habilitados.
|
|
l
|
Situação de busca
|
|
l
|
Não licenciados ou licenciados IPs Virtuais excedidos
|
|
Tipo de serviço
|
Porto/Protocolo
|
Camada de serviço
|
Comentário
|
|
Camada 4 TCP
|
Qualquer porto TCP
|
Camada 4
|
O ADC não alterará nenhuma informação no fluxo de dados e realizará o balanceamento de carga padrão do tráfego de acordo com a política de balanceamento de carga
|
|
Camada 4 UDP
|
Qualquer porto UDP
|
Camada 4
|
Assim como no Layer 4 TCP, o ADC não alterará nenhuma informação no fluxo de dados e realizará o balanceamento de carga padrão do tráfego de acordo com a política de balanceamento de carga
|
|
Camada 4 TCP/UDP
|
Qualquer porto TCP ou UDP
|
Camada 4
|
É ideal que seu serviço tenha um protocolo primário como o UDP, mas que volte ao TCP. O ADC não alterará nenhuma informação no fluxo de dados e realizará o balanceamento de carga padrão do tráfego de acordo com a política de balanceamento de carga.
|
|
DNS
|
!!!
|
|
|
|
HTTP
|
Protocolo HTTP ou HTTPS
|
Camada 7
|
O ADC pode interagir, manipular e modificar o fluxo de dados usando o flightPATH.
|
|
FTP
|
Protocolo de transferência de arquivos
|
Camada 7
|
Usando controle separado e conexões de dados entre cliente e servidor
|
|
SMTP
|
Protocolo de transferência de correio simples
|
Camada 4
|
Uso ao equilibrar a carga dos servidores de correio
|
|
POP3
|
Protocolo dos Correios
|
Camada 4
|
Uso ao equilibrar a carga dos servidores de correio
|
|
IMAP
|
Protocolo de acesso a mensagens na Internet
|
Camada 4
|
Uso ao equilibrar a carga dos servidores de correio
|
|
RDP
|
Protocolo de Desktop Remoto
|
Camada 4
|
Uso no balanceamento de carga de servidores de Serviços Terminais
|
|
RPC
|
Chamada de procedimento remoto
|
Camada 4
|
Uso quando sistemas de balanceamento de carga usando chamadas RPC
|
|
RPC/ADS
|
Troca 2010 Static RPC para serviço de catálogo de endereços
|
Camada 4
|
Uso no balanceamento de carga Servidores de câmbio
|
|
RPC/CA/PF
|
Troca 2010 Static RPC para Acesso do Cliente e Pastas Públicas
|
Camada 4
|
Uso no balanceamento de carga Servidores de câmbio
|
|
DICOM
|
Imagens e Comunicações Digitais em Medicina
|
Camada 4
|
Uso quando servidores de balanceamento de carga usando protocolos DICOM
|
|
LED
|
Significado
|
|
l
|
Conectado
|
|
£
|
Não monitorado
|
|
l
|
Drenagem
|
|
l
|
Offline
|
|
l
|
Espera
|
|
l
|
Não Ligado
|
|
l
|
Situação de busca
|
|
l
|
Não licenciados ou licenciados Servidores Reais excederam
|
|
Opção
|
Descrição
|
|
Online
|
Todos os Servidores Reais designados on-line receberão tráfego de acordo com a política de balanceamento de carga estabelecida dentro da guia Básica.
|
|
Dreno
|
Todos os Servidores Reais designados como Drain continuarão a servir as conexões existentes, mas não aceitarão nenhuma nova conexão. A luz de status piscará verde/azul enquanto o dreno estiver em andamento. Uma vez que as conexões existentes tenham sido fechadas naturalmente, os Verdadeiros Servidores ficarão offline, e a luz de Status será azul sólido. O senhor também pode ver essas conexões navegando até a seção Navegação > Monitor > Status.
|
|
Offline
|
Todos os Servidores Reais definidos como Offline serão imediatamente desligados e não receberão nenhum tráfego.
|
|
Espera
|
Todos os Servidores Reais definidos como Standby permanecerão off-line até que TODOS os servidores do grupo Online falhem em suas verificações do Monitor de Saúde do Servidor. O tráfego é recebido pelo grupo "Standby" de acordo com a política de equilíbrio de carga quando isso acontece. Se um servidor do grupo Online passar na verificação do Monitor de Saúde do Servidor, esse servidor Online receberá todo o tráfego, e o grupo Standby deixará de receber tráfego.
|
|
Opção
|
Descrição
|
|
O mais rápido
|
A política de equilíbrio de carga mais rápida calcula automaticamente o tempo de resposta para todos os pedidos por servidor suavizados ao longo do tempo. A coluna Peso Calculado contém o valor calculado automaticamente. A entrada manual só é possível quando se usa essa política de balanceamento de carga.
|
|
Round Robin
|
Round Robin é comumente usado em firewalls e equilibradores de carga básica e é o método mais simples. Cada Real Server recebe um novo pedido em seqüência. Esse método só é apropriado quando o senhor precisa carregar os pedidos de equilíbrio de carga para os servidores de maneira uniforme; um exemplo seria os servidores web look-up. No entanto, quando o senhor precisa carregar o saldo com base na carga de pedidos ou na carga do servidor, ou mesmo garantir que o senhor use o mesmo servidor para a sessão, o método Round Robin é inadequado.
|
|
Ligações Mínimas
|
O equilibrador de carga manterá um registro do número de conexões atuais com cada servidor real. O Servidor Real com o menor número de conexões recebe o novo pedido subseqüente.
|
|
Camada 3 Sessão Afinidade/Persistência - IP Limitada
|
Nesse modo, o endereço IP do cliente forma a base para selecionar qual Servidor Real receberá o pedido. Essa ação proporciona persistência. Os protocolos HTTP e Layer 4 podem usar esse modo. Esse método é útil para redes internas onde a topologia da rede é conhecida, e o senhor pode estar confiante de que não há "super proxies" a montante. Com o Layer 4 e os proxies, todos os pedidos podem parecer que vêm de um cliente, e como tal, a carga não seria uniforme. Com HTTP, a informação do cabeçalho (X-Forwarder-For) é usada quando presente para lidar com os procuradores.
|
|
Afinidade/Persistência de Camada 3 Sessões - Lista de PI
|
A conexão com o Real Server inicia-se então usando "Menos conexões", a afinidade da sessão é alcançada com base no endereço IP do cliente. Uma lista é mantida por 2 horas por padrão, mas isso pode ser mudado usando um jetPACK.
|
|
Camada 7 Afinidade/Persistência da Sessão - Cookie da Sessão
|
Esse modo é o método de persistência mais popular para o balanceamento de carga HTTP. Nesse modo, o ADC usa o balanceamento de carga baseado em lista de IP para cada primeira solicitação. Ele insere um cookie nos cabeçalhos da primeira resposta HTTP. Depois disso, o ADC usa o cookie do cliente para encaminhar o tráfego para o mesmo servidor back-end. Esse cookie é usado para persistência quando o cliente precisa ir ao mesmo servidor de back-end cada vez. O cookie expira uma vez que a sessão é encerrada.
|
|
Afinidade/Persistência de Camada 7 Sessão - Cookie Persistente
|
O modo de equilíbrio de carga baseado na lista de PI é usado para cada primeiro pedido. O ADC insere um cookie nos cabeçalhos da primeira resposta HTTP. Depois disso, o ADC usa o cookie do cliente para encaminhar o tráfego para o mesmo servidor back-end. Esse cookie é usado para persistência quando o cliente deve ir ao mesmo servidor de back-end cada vez. O cookie expirará após 2 horas, e a conexão será balanceada de acordo com um algoritmo baseado em uma lista de IP. Esse tempo de expiração é configurável usando um jetPACK.
|
|
Cookie de Sessão - Cookie de Sessão Clássico ASP
|
O Active Server Pages (ASP) é uma tecnologia do lado do servidor da Microsoft. Com essa opção selecionada, o ADC manterá a persistência da sessão no mesmo servidor se um cookie ASP for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie ASP, a carga será balanceada usando o algoritmo de Conexões Mínimas.
|
|
Cookie de Sessão - ASP.NET Cookie de Sessão
|
Esta modalidade se aplica ao ASP.net. Com essa modalidade selecionada, o ADC manterá a persistência da sessão no mesmo servidor se um cookie ASP.NET for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie ASP, a carga será balanceada usando o algoritmo de Ligações Mínimas.
|
|
Cookie de Sessão - Cookie de Sessão JSP
|
Java Server Pages (JSP) é uma tecnologia do lado do servidor Oracle. Com esse modo selecionado, o ADC manterá a persistência da sessão no mesmo servidor se um cookie JSP for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie JSP, a carga será balanceada usando o algoritmo de Ligações Mínimas.
|
|
Cookie de Sessão - JAX-WS Cookie de Sessão
|
Java web services (JAX-WS) é uma tecnologia do lado do servidor Oracle. Com esse modo selecionado, o ADC manterá a persistência da sessão no mesmo servidor se um cookie JAX-WS for detectado e encontrado em sua lista de cookies conhecidos. Na detecção de um novo cookie JAX-WS, ele será carregado em equilíbrio usando o algoritmo de Conexões Mínimas.
|
|
Cookie de Sessão - Cookie de Sessão PHP
|
A Personal Home Page (PHP) é uma tecnologia de código aberto do lado do servidor. Com esse modo selecionado, o ADC manterá a persistência da sessão para o mesmo servidor quando um cookie PHP for detectado.
|
|
Sessão Cookie - RDP Cookie Persistência
|
Esse método de equilíbrio de carga usa o Cookie RDP, criado pela Microsoft com base no nome de usuário/domínio, para dar persistência a um servidor. A vantagem desse método significa que é possível manter uma conexão com um servidor, mesmo que o endereço IP do cliente mude.
|
|
Baseado em Cookie-ID
|
Um novo método muito semelhante ao "PhpCookieBased" e outros métodos de balanceamento de carga, mas usando CookieIDBased e cookie RegEx h=[^;]+
Esse método usará o valor definido no campo de notas do Real Server "ID=X;" como o valor do cookie para identificar o servidor. Isso, portanto, significa que é uma metodologia semelhante à CookieListBased, mas usa um nome de cookie diferente e armazena um valor de cookie único, não o IP codificado, mas o ID do Real Server (lido no tempo de carga).
O valor padrão é CookieIDName="h"; entretanto, se houver um valor de substituição na configuração avançada do servidor virtual, use esse valor em seu lugar. NOTA: Se esse valor for definido, nós substituímos a expressão "cookie" acima para substituir h= pelo novo valor.
A última parte é que se um valor desconhecido de cookie chegar e corresponder a uma das IDs do servidor real, ele deve selecionar esse servidor; caso contrário, use o próximo método (delegado).
|
|
Opção
|
Descrição
|
|
Nenhum
|
Nesse modo, o Real Server não é monitorado e está sempre funcionando corretamente. O ajuste Nenhum é útil para situações em que o monitoramento perturba um servidor e para serviços que não deveriam participar da ação de fail-over da ADC. É um caminho para hospedar sistemas não confiáveis ou legados que não são primários para as operações do H/A. Use esse método de monitoramento com qualquer tipo de serviço.
|
|
Ping/ICMP Echo
|
Nesse modo, o ADC envia um pedido de eco ICMP para o IP do servidor de conteúdo. Se uma resposta de eco válida for recebida, a ADC considera que o Real Server está em funcionamento, e o tráfego de passagem para o servidor continua. Ele também manterá o serviço disponível em um par H/A. Esse método de monitoramento é utilizável com qualquer tipo de serviço.
|
|
Conexão TCP
|
Nesse modo, uma conexão TCP é feita ao Real Server e imediatamente quebrada sem o envio de quaisquer dados. Se a conexão tiver êxito, o ADC considera que o Servidor Real está em funcionamento. Esse método de monitoramento é utilizável com qualquer tipo de serviço. Os serviços UDP são os únicos atualmente não apropriados para o monitoramento da conexão TCP.
|
|
ICMP Inacessível
|
O ADC enviará um exame de saúde da UDP ao servidor e marcará o Real Server como indisponível se ele receber uma mensagem não alcançável na porta do ICMP. Esse método pode ser útil quando o senhor precisar verificar se uma porta de serviço UDP está disponível em um servidor, tal como a porta 53 do DNS.
|
|
RDP
|
Nesse modo, uma conexão TCP se inicia, como explicado no ICMP, método inalcançável. Após a inicialização da conexão, é solicitada uma conexão RDP de Camada 7. Se a conexão for confirmada, o ADC considera que o Real Server está instalado e funcionando. Esse método de monitoramento é utilizável com qualquer servidor terminal da Microsoft.
|
|
200 OK
|
Nesse método, uma conexão TCP inicializa-se no Real Server. Após o sucesso da conexão, o ADC envia ao Servidor Real um pedido HTTP. Uma resposta HTTP é aguardada e verificada para o código de resposta "200 OK". Se o código de resposta "200 OK" for recebido, o ADC considera que o Real Server está em funcionamento. Se o ADC não receber um código de resposta "200 OK" por qualquer razão, incluindo timeouts, falha na conexão, e outras razões, o ADC marca o Servidor Real indisponível. Esse método de monitoramento só é válido para uso com tipos de serviço HTTP e HTTP acelerado. Se um tipo de serviço de Camada 4 estiver em uso para um servidor HTTP, ele é utilizável se o SSL não estiver em uso no Servidor Real ou se for tratado apropriadamente pela instalação "Conteúdo SSL".
|
|
DICOM
|
Uma conexão TCP inicializa-se ao Real Server no modo DICOM, e um "Pedido de Associado" Echoscu é feito ao Real Server na conexão. Uma conversa que inclui um "Associate Accept" do servidor de conteúdo, uma transferência de uma pequena quantidade de dados seguida por um "Release Request", e depois um "Release Response" conclui com sucesso o monitor. Se, por qualquer razão, o monitor não concluir com sucesso, então o Servidor Real é considerado como desligado.
|
|
Usuário Definido
|
Qualquer monitor configurado na seção de Monitoramento do Servidor Real aparecerá na lista.
|
|
Opção
|
Descrição
|
|
Por anfitrião
|
O cache por anfitrião é baseado na aplicação por nome de anfitrião. Haverá um Cache separado para cada domínio/nome de anfitrião. Esse modo é ideal para servidores web que podem servir múltiplos websites, dependendo do domínio.
|
|
Por Serviço Virtual
|
O senhor está disponível quando escolhe essa opção. Apenas um Cache existirá para todos os domínios/nomes de domínios que passarem pelo serviço virtual. Essa opção é um ambiente especializado para uso com vários clones de um único site.
|
|
Opção
|
Descrição
|
|
Off
|
Desligar a compressão para o Serviço Virtual
|
|
Compressão
|
Quando selecionada, essa opção ativa a compressão para o Serviço Virtual selecionado. O ADC comprime dinamicamente o fluxo de dados para o cliente, mediante solicitação. Esse processo só se aplica a objetos que contenham a codificação de conteúdo: cabeçalho gzip. O conteúdo de exemplo inclui HTML, CSS, ou Javascript. O cliente também pode excluir certos tipos de conteúdo usando a seção Exclusões Globais.
|
|
Opção
|
Descrição
|
|
Sem SSL
|
O tráfego da fonte para o ADC não é criptografado.
|
|
Todos
|
Carrega todos os certificados disponíveis para uso
|
|
Inadimplência
|
Essa opção resulta na aplicação de um certificado criado localmente, chamado "Default", ao lado do navegador do canal. Use essa opção para testar o SSL quando um não tiver sido criado ou importado.
|
|
AnyUseCert
|
Usar qualquer certificado presente no ADC que o usuário tenha carregado ou gerado
|
|
Opção
|
Descrição
|
|
Sem SSL
|
O tráfego do ADC para o Real Server não é criptografado. A seleção de um certificado no lado do navegador significa que "No SSL" pode ser escolhido no lado do cliente para fornecer o que é conhecido como "SSL Offload".
|
|
Qualquer
|
O ADC atua como cliente e aceitará qualquer certificado que o Real Server apresentar. O tráfego do ADC para o Real Server é criptografado quando essa opção é selecionada. Use a opção "Qualquer" quando um certificado é especificado no lado do Serviço Virtual, fornecendo o que é conhecido como "SSL Bridging" ou "SSL Re-Encryption".
|
|
SNI
|
O ADC atua como cliente e aceitará qualquer certificado que o Real Server apresentar. O tráfego do ADC para o Servidor Real é criptografado se este for selecionado. Use a opção "Qualquer" quando um certificado for especificado no lado do Serviço Virtual, fornecendo o que é conhecido como "SSL Bridging" ou "SSL Re-Encryption". Escolha essa opção para habilitar o SNI no lado do servidor.
|
|
AnyUseCert
|
Quaisquer certificados que o senhor tenha gerado ou importado para o ADC aparecem aqui.
|
|
Opção
|
Descrição
|
|
Procuração reversa
|
A Reverse Proxy é o valor padrão e trabalha em Layer7 com compressão e caching. E na Camada4 sem caching ou compressão. Nesse modo, seu ADC age como um proxy reverso e se torna o endereço de origem visto pelos Servidores Reais.
|
|
Retorno direto do servidor
|
Direct Server Return ou DSR como é amplamente conhecido (DR - Direct Routing em alguns círculos) permite ao servidor por trás do equilibrador de carga responder diretamente ao cliente contornando o ADC na resposta. O DSR só é adequado para uso com o balanceamento de carga de Camada 4. Portanto, Caching e Compressão não estão disponíveis com essa opção escolhida.
O balanceamento de carga da camada 7 não funciona com esse DSR. Além disso, não há nenhum apoio persistente além do baseado na Lista de PI. O balanceamento de carga SSL/TLS com esse método não é o ideal, já que o suporte de persistência de IP de origem é o único tipo disponível. O DSR também requer mudanças no Real Server para ser feito. Consulte a seção Mudanças no Servidor Real.
|
|
Porta de entrada
|
O modo Gateway permite que o senhor encaminhe todo o tráfego através do ADC, permitindo que o tráfego dos Servidores Reais seja encaminhado através do ADC para outras redes através das máquinas virtuais ou interfaces de hardware do ADC. Usar o dispositivo como um dispositivo de gateway para Servidores Reais é ideal quando estiver rodando em modo multi-interface.
O equilíbrio de carga da camada 7 com esse método não funciona, pois não há nenhum outro apoio de persistência além do baseado na lista de IP. Esse método exige que o Real Server defina seu gateway padrão para o endereço de interface local (eth0, eth1, etc.) do ADC. Por favor, consulte a seção Mudanças no Servidor Real.
Queira observar que o modo Gateway não suporta falhas em um ambiente de cluster.
|
