Upstream#
Fornece contexto para descrever grupos de servidores que podem ser usados na diretiva proxy_pass. Descreve um grupo de servidores. Os servidores podem escutar em portas diferentes. Além disso, servidores escutando em TCP e sockets de domínio UNIX podem ser misturados. Exemplo: Por padrão, as conexões são distribuídas entre os servidores usando um método de balanceamento round-robin ponderado. No exemplo acima, cada 7 conexões serão distribuídas da seguinte forma: 5 conexões vão para backend1.example.com:1935 e uma conexão para cada um dos segundo e terceiro servidores. Se ocorrer um erro durante a comunicação com um servidor, a conexão será passada para o próximo servidor, e assim por diante até que todos os servidores funcionais sejam tentados. Se a comunicação com todos os servidores falhar, a conexão será fechada. Define o endereço e outros parâmetros de um servidor. O endereço pode ser especificado como um nome de domínio ou endereço IP com uma porta obrigatória, ou como um caminho de socket de domínio UNIX especificado após o prefixo Os seguintes parâmetros podem ser definidos: Define o peso do servidor; por padrão, 1. Limita o número máximo de conexões ativas simultâneas para o servidor com proxy. O valor padrão é Aqui, uma tentativa malsucedida é um erro ou timeout ao estabelecer uma
conexão com o servidor. Nota Se uma diretiva Se um upstream contém apenas um servidor
após todas as suas diretivas O número padrão de tentativas. Desabilita a contabilização de tentativas. Por padrão, isso é definido como 10 segundos. Nota Se uma diretiva Se um upstream contém apenas um servidor
após todas as suas diretivas Marca o servidor como um servidor de backup. Ele receberá requisições quando os servidores primários estiverem indisponíveis. Marca o servidor como permanentemente indisponível. Marca o servidor como drenando; isso significa
que ele recebe apenas requisições das sessões
que foram vinculadas anteriormente com sticky.
Caso contrário, ele se comporta de forma similar a Aviso O parâmetro Os parâmetros Habilita o monitoramento de mudanças na lista de endereços IP que
corresponde a um nome de domínio, atualizando-a sem recarregar a configuração.
O grupo deve residir em uma
zona de memória compartilhada;
além disso, um resolver deve ser definido. Habilita a resolução de registros DNS SRV e define o nome do serviço.
Para que este parâmetro funcione, o parâmetro resolve também deve ser especificado,
sem especificar a porta do servidor no nome do host. Se não houver pontos no nome do serviço,
o nome é formado de acordo com o padrão RFC:
o nome do serviço é prefixado com O Angie resolve os registros SRV
combinando o nome do serviço normalizado e o nome do host
e obtendo a lista de servidores para a combinação via DNS,
junto com suas prioridades e pesos. Registros SRV de prioridade máxima
(aqueles que compartilham o valor mínimo de prioridade)
resolvem para servidores primários,
e outros registros tornam-se servidores de backup.
Se O peso é similar ao parâmetro Este exemplo irá procurar o registro Define o ID do servidor no grupo. Se o parâmetro não for especificado,
o ID é definido como um hash MD5 hexadecimal
do endereço IP e porta ou caminho do socket de domínio UNIX. Define o tempo para um servidor recuperar seu peso
ao retornar ao serviço
com os métodos de balanceamento de carga round-robin ou least_conn. Se o parâmetro estiver definido
e um servidor for novamente considerado saudável
após uma falha de acordo com max_fails e upstream_probe (PRO),
o servidor gradualmente recupera seu peso designado
durante o período de tempo especificado. Se o parâmetro não estiver definido,
em uma situação similar
o servidor imediatamente começa a trabalhar com seu peso designado. Nota Se apenas um Especifica o file onde a lista de servidores upstream é armazenada persistentemente.
Ao instalar a partir dos
nossos pacotes,
um diretório dedicado
O formato da lista de servidores aqui é similar ao Aviso Para usar a diretiva Define o nome e tamanho da zona de memória compartilhada que armazena a configuração e estado de execução do grupo, compartilhada entre processos worker. Múltiplos grupos podem usar a mesma zona. Neste caso, é suficiente especificar o tamanho apenas uma vez. A diretiva habilita a capacidade de iniciar a seleção de servidor não do grupo primário,
mas do grupo ativo, ou seja, aquele onde um servidor foi encontrado com sucesso anteriormente.
Se um servidor não puder ser encontrado no grupo ativo para a próxima requisição,
e a busca se mover para o grupo de backup,
este grupo de backup se torna ativo,
e requisições subsequentes são primeiro direcionadas para servidores neste grupo. Se o parâmetro Exemplo: Se o balanceador de carga alternar dos servidores primários para o grupo de backup,
todas as requisições subsequentes são tratadas por este grupo de backup por 2 minutos.
Após 2 minutos expirarem, o balanceador de carga re-verifica os servidores primários
e os torna ativos novamente se estiverem funcionando normalmente. Padrão — upstream Habilita um mecanismo de balanceamento de carga baseado em feedback para o Os seguintes parâmetros podem ser especificados: A variável da qual o valor de feedback é obtido.
Ela deve representar uma métrica de desempenho ou saúde;
assume-se que seja fornecida pelo servidor. O valor é avaliado com cada resposta do servidor
e considerado na média móvel
de acordo com as configurações Se o parâmetro estiver definido, o valor de feedback é interpretado inversamente:
valores menores indicam melhor desempenho. O fator pelo qual o valor de feedback é ponderado
ao calcular a média.
Valores válidos são inteiros de 0 a 99.
O padrão é A média é calculada usando a fórmula de suavização exponencial. Quanto maior o fator, menos os novos valores afetam a média;
se Especifica uma variável de condição
que controla como as conexões são contabilizadas no cálculo.
O valor médio é atualizado com o valor de feedback
apenas se a variável de condição
não for igual a Nota Por padrão, o tráfego de sondas
não é incluído no cálculo;
combinar a variável $upstream_probe
com Exemplo: Esta configuração categoriza servidores por níveis de feedback
baseados nos protocolos usados em sessões individuais,
e também adiciona uma condição em $upstream_probe
para contabilizar apenas sondas Especifica um método de balanceamento de carga para o grupo onde o mapeamento cliente-servidor é determinado usando um valor de chave hash. A chave pode conter texto, variáveis e suas combinações. Note que qualquer adição ou remoção de servidores do grupo pode resultar no remapeamento da maioria das chaves para servidores diferentes. O método é compatível com a biblioteca Perl Cache::Memcached. Exemplo de uso: Ao usar nomes de domínio que resolvem para múltiplos endereços IP
(por exemplo, com o parâmetro Se o parâmetro Especifica um método de balanceamento de carga para o grupo onde uma conexão é passada para o servidor com o menor número de conexões ativas, levando em conta os pesos dos servidores. Se vários servidores forem adequados, eles são selecionados ciclicamente (round-robin) com seus pesos levados em conta. Padrão — upstream Especifica um método de balanceamento de carga para o grupo onde a probabilidade de passar
uma conexão para um servidor ativo é inversamente proporcional ao seu tempo médio
de resposta; quanto menor ele for, mais conexões o servidor receberá. A diretiva leva em conta o tempo médio para estabelecer uma conexão. A diretiva usa o tempo médio para receber o primeiro byte da resposta. A diretiva usa o tempo médio para receber a resposta completa. Executa a mesma função que response_time_factor (PRO),
e o sobrescreve se o parâmetro for especificado. Especifica uma variável de condição
que controla quais conexões são contabilizadas no cálculo.
O valor médio é atualizado
apenas se a variável de condição da conexão
não for igual a Nota Por padrão, sondas
não são incluídas no cálculo;
combinar a variável $upstream_probe
com Os valores atuais são apresentados como Especifica um método de balanceamento de carga para o grupo onde uma conexão é passada para um servidor selecionado aleatoriamente, levando em conta os pesos dos servidores. Se o parâmetro opcional Especifica para o método de balanceamento de carga least_time (PRO) o fator
de suavização para o valor anterior ao calcular o tempo médio de resposta usando a
fórmula de média móvel exponencialmente ponderada. Quanto maior o number especificado, menos os novos valores afetam a média; se
Os resultados atuais do cálculo são apresentados como Nota Apenas respostas bem-sucedidas são consideradas no cálculo;
o que constitui uma resposta mal-sucedida
é determinado pelas diretivas proxy_next_upstream. Padrão — upstream Configura sessões persistentes entre clientes e servidores upstream,
dependendo do modo especificado no primeiro parâmetro.
Para gradualmente tirar servidores com Aviso A diretiva Este modo usa identificadores de rota predefinidos
que podem ser incorporados em propriedades de conexão acessíveis ao Angie.
É menos flexível, pois depende de valores predefinidos,
mas é mais adequado se tais identificadores já estiverem em uso. Aqui, ao estabelecer uma conexão, o servidor upstream
pode atribuir uma rota ao cliente e retornar seu identificador de uma forma
conhecida por ambas as partes.
O identificador de rota
deve usar o valor do parâmetro sid
da diretiva server.
Note que o parâmetro é adicionalmente hasheado
se a diretiva sticky_secret for especificada. Conexões subsequentes de clientes que desejam usar esta rota
devem conter o identificador emitido pelo servidor, de tal forma
que ele termine em variáveis do Angie. Os parâmetros da diretiva especificam variáveis para roteamento.
Para selecionar o servidor para onde a conexão de entrada é direcionada,
a primeira variável não vazia é usada;
ela é então comparada com o parâmetro sid
da diretiva server.
Se a seleção do servidor falhar
ou o servidor selecionado não puder aceitar a conexão,
outro servidor será selecionado
de acordo com o método de balanceamento de carga configurado. Aqui o Angie procura o identificador de rota na variável Neste modo, uma chave gerada dinamicamente é usada
para vincular um cliente a um servidor upstream específico;
este modo é mais flexível
pois atribui servidores dinamicamente,
armazena sessões em uma zona de memória compartilhada,
e suporta várias formas de passar identificadores de sessão. Aqui, uma sessão é criada
com base em propriedades de conexão vindas do servidor upstream.
Os parâmetros O identificador de sessão é o valor da primeira variável não vazia
especificada com Sessões são armazenadas em uma zona de memória compartilhada;
seu nome e tamanho são especificados pelo parâmetro Por padrão, o Angie estende o tempo de vida da sessão
atualizando o timestamp do último acesso cada vez que ela é usada.
O parâmetro Conexões subsequentes de clientes que desejam usar uma sessão
devem conter seu identificador.
O parâmetro O parâmetro No exemplo, o Angie cria e procura sessões
usando a variável $rdp_cookie: Os parâmetros Diferentemente do modo O parâmetro O princípio geral de operação deste modo é o seguinte:
se um identificador de sessão não for encontrado localmente,
o Angie envia uma subrequisição síncrona para um armazenamento remoto
especificado pelo parâmetro Quando uma nova conexão chega, o Angie executa as seguintes ações: Primeiro, o identificador de sessão é extraído da primeira variável não vazia
na lista Então o Angie envia uma subrequisição HTTP síncrona para o armazenamento remoto
especificado pelo parâmetro o identificador de sessão do parâmetro o identificador do servidor pré-selecionado:
o valor do parâmetro As variáveis O armazenamento remoto processa a requisição e retorna uma resposta HTTP: Uma resposta com código 200, 201 ou 204 confirma o servidor selecionado.
O armazenamento remoto pode simultaneamente
retornar um identificador de servidor alternativo em um cabeçalho HTTP;
ele pode ser extraído via Ao receber qualquer outro código HTTP do armazenamento
(incluindo erros de rede e timeouts)
ou um identificador de servidor inexistente,
o Angie usa o servidor originalmente selecionado. O identificador do servidor é extraído da resposta do armazenamento remoto
via o parâmetro Abaixo está um exemplo de configuração simplificado.
O armazenamento remoto retorna o identificador do servidor no cabeçalho Aqui, com a seguinte resposta do armazenamento remoto: Duas variáveis ficam disponíveis: Como a variável A diretiva Servidores marcados como Servidores que atingiram o número máximo de conexões
(ao usar Servidores com a opção Se um servidor anteriormente indisponível se recuperar,
O comportamento de Zonas de memória compartilhada
especificadas no parâmetro Adiciona string como salt à função hash MD5
para a diretiva sticky no modo O salt é adicionado após o valor hasheado;
para verificar independentemente o mecanismo de hashing: Quando habilitado, o Angie retornará um erro de conexão para o cliente
se o servidor desejado estiver indisponível,
em vez de fazer fallback para outro servidor disponível,
que é o comportamento padrão quando nenhum servidor correspondente é encontrado. O módulo Usado com Usado com armazena o endereço IP e porta, ou o caminho para o socket de domínio UNIX do servidor upstream. Se vários servidores foram contatados durante o proxy, seus endereços são separados por vírgulas, por exemplo: 192.168.1.1:1935, 192.168.1.2:1935, unix:/tmp/sock Se um servidor não puder ser selecionado, a variável mantém o nome do grupo de servidores. número de bytes recebidos de um servidor upstream. Valores de várias conexões são separados por vírgulas e dois pontos como endereços na variável $upstream_addr. número de bytes enviados para um servidor upstream. Valores de várias conexões são separados por vírgulas e dois pontos como endereços na variável $upstream_addr. tempo para conectar ao servidor upstream; o tempo é mantido em segundos com resolução de milissegundos. Tempos de várias conexões são separados por vírgulas e dois pontos como endereços na variável $upstream_addr. tempo para receber o primeiro byte de dados; o tempo é mantido em segundos com resolução de milissegundos. Tempos de várias conexões são separados por vírgulas como endereços na variável $upstream_addr. duração da sessão em segundos com resolução de milissegundos. Tempos de várias conexões são separados por vírgulas como endereços na variável $upstream_addr. Status das conexões sticky. Conexão roteada para um grupo de servidores onde sticky não está habilitado. Conexão não contém informações sticky. Conexão com informações sticky roteada para o servidor desejado. Conexão com informações sticky roteada para um servidor
selecionado pelo algoritmo de balanceamento de carga. Valores de múltiplas conexões são separados por vírgulas e dois pontos,
similar aos endereços na variável $upstream_addr.Exemplo de Configuração#
upstream backend {
hash $remote_addr consistent;
zone backend 1m;
server backend1.example.com:1935 weight=5;
server unix:/tmp/backend3;
server backend3.example.com service=_example._tcp resolve;
server backup1.example.com:1935 backup;
server backup2.example.com:1935 backup;
}
resolver 127.0.0.53 status_zone=resolver;
server {
listen 1936;
proxy_pass backend;
}
Diretivas#
upstream#
upstream backend {
server backend1.example.com:1935 weight=5;
server 127.0.0.1:1935 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend2;
server backend3.example.com:1935 resolve;
server backup1.example.com:1935 backup;
}
server#
unix:. Um nome de domínio que resolve para vários endereços IP define múltiplos servidores de uma vez.weight=númeromax_conns=número0, significando que não há limite. Se o grupo de servidores não residir na memória compartilhada, a limitação funciona por cada processo worker.max_fails=número — define o número de tentativas malsucedidas
de comunicação com o servidor
que devem acontecer na duração definida por fail_timeout
para considerar o servidor indisponível;
ele é então tentado novamente após a mesma duração.server em um grupo resolve para múltiplos servidores,
sua configuração max_fails se aplica a cada servidor individualmente.server serem resolvidas,
a configuração max_fails não tem efeito e será ignorada.max_fails=1max_fails=0fail_timeout=tempo — define o período de tempo durante o qual um número especificado de
tentativas malsucedidas de comunicação com o servidor (max_fails) deve acontecer para considerar o servidor indisponível.
O servidor então permanece indisponível pela mesma quantidade de tempo
antes de ser tentado novamente.server em um grupo resolve para múltiplos servidores,
sua configuração fail_timeout se aplica a cada servidor individualmente.server serem resolvidas,
a configuração fail_timeout não tem efeito e será ignorada.backupdowndrain (PRO)down.backup não pode ser usado junto com os métodos de balanceamento de carga hash e random.down e drain são mutuamente exclusivos.resolveservice=nome_,
então _tcp é adicionado após um ponto.
Assim, o nome do serviço http resultará em _http._tcp.backup for definido com server,
registros SRV de prioridade máxima resolvem para servidores de backup,
e outros registros são ignorados.weight da diretiva server.
Se o peso for definido tanto pela diretiva quanto pelo registro SRV,
o peso definido pela diretiva é usado._http._tcp.backend.example.com:server backend.example.com service=http resolve;
sid=idslow_start=timeserver for especificado no upstream,
slow_start não tem efeito e será ignorado.state (PRO)#
/var/lib/angie/state/ (/var/db/angie/state/ no FreeBSD)
é criado com as permissões apropriadas para armazenar tais arquivos,
então você só precisa adicionar o nome do arquivo na configuração:upstream backend {
zone backend 1m;
state /var/lib/angie/state/<NOME DO ARQUIVO>;
}
s_server.
O conteúdo do arquivo muda sempre que servidores são modificados na
seção /config/stream/upstreams/
via API de configuração.
O arquivo é lido na inicialização do Angie ou no recarregamento da configuração.state em um bloco upstream,
não deve haver diretivas server nele,
mas uma zona de memória compartilhada (zone) é necessária.zone#
backup_switch (PRO)#
permanent for definido sem um valor de tempo,
o grupo permanece ativo após a seleção,
e a re-verificação automática de grupos com níveis de prioridade mais baixos não ocorre.
Se time for especificado,
o status ativo do grupo expira após o intervalo especificado,
e o balanceador de carga novamente verifica grupos com níveis de prioridade mais baixos,
retornando a eles se os servidores estiverem funcionando normalmente.upstream media_backend {
server primary1.example.com:1935;
server primary2.example.com:1935;
server reserve1.example.com:1935 backup;
server reserve2.example.com:1935 backup;
backup_switch permanent=2m;
}
feedback (PRO)#
feedback variable [inverse] [factor=number] [account=condition_variable];upstream.
Ele ajusta dinamicamente as decisões de balanceamento de carga
multiplicando o peso de cada servidor proxy pela média do valor de feedback,
que muda ao longo do tempo baseado no valor da variable
e está sujeito a uma condição opcional.variableinverse e factor.inversefactor90.90 for especificado, 90% do valor anterior será considerado
e apenas 10% do novo valor.account"" ou "0".account permite incluí-las
ou até mesmo excluir todo o resto.upstream backend {
zone backend 1m;
feedback $feedback_value factor=80 account=$condition_value;
server backend1.example.com:1935 weight=1;
server backend2.example.com:1935 weight=2;
}
map $protocol $feedback_value {
"TCP" 100;
"UDP" 75;
default 10;
}
map $upstream_probe $condition_value {
"high_priority" "1";
"low_priority" "0";
default "1";
}
high_priority
ou sessões regulares de cliente.hash#
hash $remote_addr;
resolve),
o servidor não ordena os endereços recebidos, então sua ordem pode diferir
entre diferentes servidores, o que afeta a distribuição de clientes.
Para garantir distribuição consistente,
use o parâmetro consistent.consistent for especificado, o método de hash consistente ketama será usado em vez do método acima. O método garante que quando um servidor é adicionado ou removido do grupo, apenas um número mínimo de chaves será remapeado para outros servidores. Usar o método para servidores de cache fornece uma taxa de acerto de cache mais alta. O método é compatível com a biblioteca Perl Cache::Memcached::Fast com o parâmetro ketama_points definido como 160.least_conn#
least_time (PRO)#
least_time connect | first_byte | last_byte [factor=number] [account=condition_variable];connectfirst_bytelast_bytefactoraccount"" ou "0".account permite incluí-las
ou até mesmo excluir todo o resto.connect_time, first_byte_time,
e last_byte_time no objeto health do servidor
entre as métricas de upstream na API.random#
two for especificado, o Angie seleciona aleatoriamente dois servidores e então escolhe um servidor usando o método especificado. O método padrão é least_conn, que passa a conexão para o servidor com o menor número de conexões ativas.response_time_factor (PRO)#
90 for especificado, 90% do valor anterior será considerado e apenas 10% do
novo valor. Valores válidos são de 0 a 99 inclusive.connect_time (tempo
para estabelecer uma conexão), first_byte_time (tempo para receber o primeiro
byte da resposta), e last_byte_time (tempo para receber a resposta completa) no
objeto health do servidor entre as métricas de upstream na API.sticky#
sticky route $variable...;sticky learn zone=zone create=$create_var1... lookup=$lookup_var1... [connect] [norefresh] [timeout=time];sticky learn lookup=$lookup_var1... remote_action=uri remote_result=$remote_var [remote_uri=uri];sticky de rotação,
você pode usar a opção drain (PRO) no bloco server.sticky deve aparecer após todas as diretivas de método de balanceamento de carga,
caso contrário não funcionará.$route,
que recebe seu valor baseado em $ssl_preread_server_name
(note que ssl_preread deve estar habilitado):stream {
map $ssl_preread_server_name $route {
a.example.com a;
b.example.com b;
default "";
}
upstream backend {
server 127.0.0.1:8081 sid=a;
server 127.0.0.1:8082 sid=b;
sticky route $route;
}
server {
listen 127.0.0.1:8080;
ssl_preread on;
proxy_pass backend;
}
}
create e lookup listam variáveis
que especificam como novas sessões são criadas e as existentes são encontradas.
Ambos os parâmetros podem ser usados múltiplas vezes.create;
por exemplo, isso poderia ser
o nome do servidor upstream.zone.
Se uma sessão não foi acessada dentro do tempo
especificado por timeout, ela é excluída.
O valor padrão é 1 hora.norefresh altera este comportamento:
a sessão expira estritamente pelo timeout, mesmo se estiver sendo usada.lookup procura o identificador de sessão na conexão
usando a lista especificada de variáveis,
parando na primeira não vazia.
Se nada for encontrado, a requisição é considerada nova.
O valor do identificador encontrado
é comparado com sessões na memória compartilhada.
Se a seleção do servidor falhar
ou o servidor selecionado não puder lidar com a conexão,
outro servidor será selecionado
de acordo com o método de balanceamento de carga configurado.connect permite criar uma sessão
imediatamente após estabelecer uma conexão com o servidor upstream.
Sem ele, a sessão é criada apenas após o processamento da conexão estar completo.
(No caso de conexões UDP, sessões são criadas imediatamente após a seleção do servidor.)stream {
upstream backend {
server 127.0.0.1:3390;
server 127.0.0.1:3391;
sticky learn lookup=$rdp_cookie create=$rdp_cookie zone=sessions:1m;
}
server {
listen 127.0.0.1:3389;
rdp_preread on;
proxy_pass backend;
}
}
remote_action e remote_result
permitem atribuir e gerenciar identificadores de sessão dinamicamente
usando um armazenamento de sessão remoto.learn com zone,
este modo não armazena sessões localmente em cache
e consulta o armazenamento remoto para cada conexão.remote_action deve apontar para um location
no contexto client.
O parâmetro remote_uri especifica o URI da requisição HTTP do cliente
para o location especificado.
Por padrão, é /.
O valor de remote_uri pode conter variáveis.remote_action.lookup.
Se todas as variáveis estiverem vazias,
o algoritmo normal de balanceamento de carga é usado sem sessões persistentes.remote_action, que deve conter
em um formato compreendido pelo armazenamento:lookup
(na configuração, esta é a
variável $sticky_sessid);sid= da diretiva server,
se especificado,
ou o hash MD5 do nome do servidor
(na configuração, esta é a
variável $sticky_sid).$sticky_sessid e $sticky_sid são automaticamente
exportadas para o contexto HTTP com o prefixo stream_:
$stream_sticky_sessid, $stream_sticky_sid.
Isso permite usá-las diretamente em diretivas HTTP,
por exemplo via cabeçalhos HTTP usando proxy_set_header.remote_result.remote_result:
ele pode especificar variáveis
com o prefixo upstream_http_,
que são criadas automaticamente pelo Angie para acessar
cabeçalhos de resposta HTTP do armazenamento remoto.
Por exemplo, o cabeçalho X-Sid: server1 em tal resposta
torna-se acessível na variável $upstream_http_x_sid
com o valor server1.X-Sticky-Sid
e assim confirma ou substitui a seleção do Angie:http {
client {
location @sticky_client1 {
# usa variáveis do stream upstream;
# ele adiciona essas variáveis ao contexto HTTP com o prefixo stream_*
proxy_set_header X-Sticky-Sessid $stream_sticky_sessid;
proxy_set_header X-Sticky-Sid $stream_sticky_sid;
proxy_set_header X-Sticky-Last $msec;
proxy_pass http://127.0.0.1:8080;
proxy_cache remote;
proxy_cache_valid 200 1d;
proxy_cache_key $scheme$proxy_host$request_uri$stream_sticky_sessid;
}
}
}
stream {
upstream u {
server 127.0.0.1:8081 sid=backend-01;
server 127.0.0.1:8082 sid=backend-02;
sticky learn lookup=$remote_addr # variável stream
remote_action=@sticky_client1 # location do bloco client
remote_result=$upstream_http_x_sticky_sid # variável HTTP
remote_uri=/foo; # padrão é /
}
server {
listen 127.0.0.1:8080;
proxy_pass u;
}
}
HTTP/1.1 200 OK
...
X-Sticky-Sid: backend-01
X-Session-Info: active
$upstream_http_x_sticky_sid,
com o valor backend-01;$upstream_http_x_session_info,
com o valor active.$upstream_http_x_sticky_sid
é especificada no parâmetro remote_result,
seu valor será usado
para selecionar o servidor com sid=backend-01.sticky leva em conta o estado dos servidores em upstream:down ou temporariamente indisponíveis devido a falhas
são excluídos da seleção.max_conns) são temporariamente ignorados.drain (PRO)
podem ser selecionados para criar novas sessões no modo sticky
quando os identificadores correspondem.sticky automaticamente retoma seu uso.sticky pode ser configurado adicionalmente
com as diretivas sticky_secret e sticky_strict.
Se sticky falhar ao selecionar um servidor ou ele estiver indisponível,
a requisição será tratada de acordo com o método de balanceamento de carga selecionado,
a menos que a diretiva sticky_strict esteja habilitada.
No modo sticky_strict on;, a requisição é rejeitada com um erro.zone da diretiva sticky
não podem ser compartilhadas entre diferentes grupos upstream;
cada grupo deve usar sua própria zona.sticky_secret#
route.
String pode conter variáveis, por exemplo $remote_addr:upstream backend {
server 127.0.0.1:8081 sid=a;
server 127.0.0.1:8082 sid=b;
sticky route $route;
sticky_secret my_secret.$remote_addr;
}
$ echo -n "<VALUE><SALT>" | md5sum
sticky_strict#
Variáveis Integradas#
stream_upstream suporta as seguintes variáveis integradas:$sticky_sessid#remote_action em sticky;
armazena o identificador de sessão inicial obtido de lookup.$sticky_sid#remote_action em sticky;
armazena o identificador do servidor previamente associado com a sessão.sticky_sid contém o valor do parâmetro sid=
da diretiva server no bloco upstream, se especificado,
ou o hash MD5 do nome do servidor.$upstream_addr#$upstream_bytes_received#$upstream_bytes_sent#$upstream_connect_time#$upstream_first_byte_time#$upstream_session_time#$upstream_sticky_status#""NEWHITMISS
Conteúdo