Liberação do Dispatcher do Adobe Managed Services

Descrição

Ambiente
Experience Manager

Problema/Sintomas
Este documento dará orientação sobre como a liberação ocorre e explica o mecanismo que executa a liberação e a invalidação do cache.

Como funciona
Ordem de operação

O fluxo de trabalho típico é melhor descrito quando os autores de conteúdo ativam uma página, quando o editor recebe o novo conteúdo, ele aciona uma solicitação de liberação para o dispatcher, conforme mostrado no diagrama a seguir:

Essa cadeia de eventos destaca que apenas liberamos itens novos ou que foram alterados.  Isso garante que o conteúdo tenha sido recebido pelo editor antes de limpar o cache, para evitar condições de corrida, onde a liberação pode ocorrer antes que as alterações possam ser recebidas do editor.

Agentes de replicação

No autor, há um agente de replicação configurado para apontar para o publicador que, quando algo é ativado, ele dispara para enviar o arquivo e todas as suas dependências para o publicador.

Quando o editor recebe o arquivo, ele tem um agente de replicação configurado para apontar para o dispatcher que dispara no evento ao receber.  Em seguida, ele serializará uma solicitação de liberação e a postará no dispatcher.

AGENTE DE REPLICAÇÃO DO AUTOR

Aqui estão algumas capturas de tela de exemplo de um agente de replicação padrão configurado

Normalmente, há 1 ou 2 agentes de replicação configurados no autor para cada editor para o qual eles replicam conteúdo.

O primeiro é o agente de replicação padrão que envia ativações de conteúdo.

O segundo é o agente reverso.  Isso é opcional e está configurado para verificar a caixa de saída de cada editor para ver se há novo conteúdo a ser extraído para o autor como uma atividade de replicação inversa

AGENTE DE REPLICAÇÃO DO EDITOR

Veja um exemplo de capturas de tela de um agente de replicação de liberação padrão configurado

REPLICAÇÃO DE LIBERAÇÃO DO DISPATCHER RECEBENDO HOST VIRTUAL

O módulo Dispatcher procura cabeçalhos específicos para saber quando uma solicitação POST é algo a ser transmitido para renderizações de AEM ou se é serializado como uma solicitação de liberação e precisa ser manipulado pelo próprio manipulador do Dispatcher.  Esta é uma captura de tela da página de configuração que mostra estes valores:

A página de configuração padrão mostra o Tipo de serialização as Liberação do Dispatcher e define o nível de erro

Na guia transporte, você pode ver o URI sendo definido para apontar o endereço IP do dispatcher que receberá as solicitações de liberação.  O caminho /dispatcher/invalidate.cache não é como o módulo determina se é uma liberação, é apenas um endpoint óbvio que você pode ver no log de acesso para saber se foi uma solicitação de liberação.  Na guia Estendido , vamos analisar os itens que estão lá para qualificar que esta é uma solicitação de liberação para o módulo do dispatcher.

O método HTTP para solicitações de liberação é apenas uma solicitação GET com alguns cabeçalhos de solicitação especiais:

• CQ-Action

  • Usa uma variável AEM com base na solicitação e o valor normalmente é ativar ou excluir

• CQ-Handle

  • Usa uma variável de AEM com base na solicitação e o valor normalmente é o caminho completo para o item liberado, por exemplo /content/dam/logo.jpg

• CQ-Path

  • Usa uma variável de AEM com base na solicitação e o valor normalmente é o caminho completo para o item que está sendo liberado, por exemplo /content/dam

• Host

  • É aqui que o Cabeçalho do Host é falsificado para direcionar um VirtualHost específico configurado no servidor Web Apache do dispatcher (/etc/httpd/conf.d/enabled_vhosts/aem_flush.vhost?lang=pt-BR).  É um valor codificado que corresponde a uma entrada no arquivo aem_flush.vhost ServerName ou ServerAlias

Na guia Acionadores, observaremos os acionadores alternados que usamos e quais são

• Ignorar padrão
  • Isso é ativado para que o agente de replicação não seja acionado na ativação de uma página.  Isso é algo que, quando uma instância de autor fizesse uma alteração em uma página, acionaria uma liberação.  Como esse é um editor, não queremos desativar esse tipo de evento.
• Ao receber
  • Quando um novo arquivo for recebido, queremos acionar uma liberação.  Portanto, quando o autor nos enviar um arquivo atualizado, acionaremos e enviaremos uma solicitação de liberação para o dispatcher.
• Sem controle de versão
  • Verificamos isso para evitar que o editor gere novas versões porque um novo arquivo foi recebido.  Vamos substituir o arquivo que temos e confiar no autor para rastrear as versões em vez do editor.

Agora, se olharmos para a aparência típica de uma solicitação de liberação na forma de um comando curl

 

$ curl \ -H "CQ-Action: Activate" \ -H "CQ-Handle: /content/dam/logo.jpg" \ -H "CQ-Path: /content/dam/" \ -H "Content-Length: 0" \ -H "Content-Type: application/octect-stream" \ -H "Host: flush" \ http: //10 .43.0.32:80 /dispatcher/invalidate .cache

Este exemplo de liberação liberaria o caminho /content/dam atualizando o arquivo .stat nesse diretório.

O arquivo .stat

O mecanismo de descarga é de natureza simples e queremos explicar a importância da .stat arquivos gerados na raiz do documento em que os arquivos de cache são criados.

Dentro dos arquivos .vhost e _farm.any, configuramos uma diretiva raiz de documento para especificar onde o cache está localizado e de onde armazenar / veicular arquivos quando uma solicitação de um usuário final chega.

Se você executasse o seguinte comando no servidor do dispatcher, começaria a encontrar arquivos .stat

 

1	$ find /mnt/var/www/html/ - type f -name ".stat"

Este é um diagrama da aparência dessa estrutura de arquivo quando você tem itens no cache e tem uma solicitação de liberação enviada e processada pelo módulo Dispatcher

NÍVEL DE ARQUIVO STAT

Observe que em cada diretório havia um arquivo .stat presente.  Este é um indicador de que ocorreu uma liberação.  No exemplo acima de statfilelevel foi definida como 3 dentro do arquivo de configuração farm correspondente.

A configuração statfilelevel indica quantas pastas o módulo percorrerá e atualizará um arquivo .stat.  O arquivo .stat está vazio, não é nada mais do que um nome de arquivo com um carimbo de data e hora poderia ser criado manualmente, mas executando o comando touch na linha de comando do servidor dispatcher.

Se a configuração de nível de arquivo stat estiver definida como muito alta, cada solicitação de liberação percorrerá a árvore de diretório tocando arquivos stat.  Isso pode se tornar um grande impacto no desempenho em árvores de cache grandes e pode afetar o desempenho geral do seu dispatcher.

Definir esse nível de arquivo como muito baixo pode fazer com que uma solicitação de liberação apague mais do que o esperado.  O que, por sua vez, faria com que o cache fosse retornado com mais frequência, com menos solicitações sendo atendidas do cache, e poderia causar problemas de desempenho.

Observação:

Defina o statfilelevel em um nível razoável.  Examine sua estrutura de pastas e verifique se está configurada para permitir liberações concisas sem ter que percorrer muitos diretórios.   Teste-o e certifique-se de que ele se ajuste às suas necessidades durante um teste de desempenho do sistema.

Um bom exemplo é um site que suporta idiomas.  A árvore de conteúdo típica teria os seguintes diretórios

/content/brand1/en/us/

Neste exemplo, use uma configuração de nível de arquivo stat de 4.  Isso garantirá quando você liberar o conteúdo contido no us que também não fará com que as pastas de idioma sejam liberadas.

 COMPARTILHAMENTO DE CARIMBO DE DATA E HORA DO ARQUIVO STAT

Quando uma solicitação de conteúdo ocorre na mesma rotina

1. O carimbo de data e hora do arquivo .stat é comparado ao carimbo de data e hora do arquivo solicitado
2. Se o arquivo .stat for mais recente que o arquivo solicitado, ele excluirá o conteúdo em cache e obterá um novo AEM e o armazenará em cache.  Em seguida, serve o conteúdo
3. Se o arquivo .stat for mais antigo que o arquivo solicitado, ele saberá que o arquivo é novo e pode servir o conteúdo.

MANIPULAÇÃO DE CACHE - EXEMPLO 1

No exemplo acima, uma solicitação para o conteúdo /content/index.html

A hora do arquivo index.html é 2019-11-01 às 18:21

A hora do arquivo .stat mais próximo é 2019-11-01 às 12:22 PM

Entendendo o que lemos acima, você pode ver que o arquivo de índice é mais recente que o arquivo .stat e o arquivo seria distribuído do cache para o usuário final que o solicitou

HANDSHAKE DE CACHE - EXEMPLO 2

No exemplo acima, uma solicitação para o conteúdo /content/dam/logo.jpg

A hora do arquivo logo.jpg é 31/10/2019 às 13:13

A hora do arquivo .stat mais próximo é 2019-11-01 às 12:22 PM

Como você pode ver neste exemplo, o arquivo é mais antigo que o arquivo .stat e será removido, e um novo é extraído do AEM para substituí-lo no cache antes de ser enviado ao usuário final que o solicitou.

Configurações do arquivo farm

A documentação está aqui para o conjunto completo de opções de configuração: https://docs.adobe.com/content/help/pt-BR/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#configuring-dispatcher_configuring-the-dispatcher-cache-cache

Destacaremos alguns deles relacionados à liberação de cache

Raiz do documento

Essa entrada de configuração está na seguinte seção do arquivo farm:

 

/myfarm {      /cache {          /docroot

Você especifica o diretório no qual deseja que o dispatcher preencha e gerencie como um diretório de cache.

Observação:

Esse diretório deve corresponder à configuração da raiz do documento apache do domínio que seu servidor da Web está configurado para usar.

Ter pastas docroot aninhadas por cada farm que vivem subpastas da raiz do documento apache é uma péssima ideia por vários motivos.

Nível dos arquivos stat

Essa entrada de configuração está na seguinte seção do arquivo farm:

 

/myfarm {      /cache {          /statfileslevel

Essa configuração mede o quão profundo os arquivos .stat precisarão ser gerados quando uma solicitação de liberação entrar.

/statfileslevel definido no seguinte número com a raiz do documento de /var/www/html/ teria os seguintes resultados ao liberar /content/dam/brand1/en/us/logo.jpg

• 0 - os arquivos stat a seguir seriam criados

  • /var/www/html/.stat

• 1 - os arquivos stat a seguir seriam criados

  • /var/www/html/.stat
  • /var/www/html/content/.stat

• 2 - os arquivos stat a seguir seriam criados

  • /var/www/html/.stat
  • /var/www/html/content/.stat
  • /var/www/html/content/dam/.stat

• 3 - os arquivos stat a seguir seriam criados

  • /var/www/html/.stat
  • /var/www/html/content/.stat
  • /var/www/html/content/dam/.stat
  • /var/www/html/content/dam/brand1/.stat

• 4 - os arquivos stat a seguir seriam criados

  • /var/www/html/.stat
  • /var/www/html/content/.stat
  • /var/www/html/content/dam/.stat
  • /var/www/html/content/dam/brand1/.stat
  • /var/www/html/content/dam/brand1/en/.stat

• 5 - os arquivos stat a seguir seriam criados

  • /var/www/html/.stat
  • /var/www/html/content/.stat
  • /var/www/html/content/dam/.stat
  • /var/www/html/content/dam/brand1/.stat
  • /var/www/html/content/mala/brand1/en/.stat
  • /var/www/html/content/mala/brand1/en/us/.stat

Observação:

Lembre-se de que, quando ocorre o handshake do carimbo de data e hora, ele procura o arquivo .stat mais próximo.

ter um nível de arquivo .stat 0 e um arquivo stat somente em /var/www/html/.stat significa que o conteúdo contido em /var/www/html/content/dam/brand1/en/us/ procuraria o arquivo .stat mais próximo e percorreria 5 pastas para encontrar o único arquivo .stat existente no nível 0 e comparar datas com esse arquivo.  Isso significa que uma liberação no nível mais alto invalidaria todos os itens em cache.

Invalidação permitida

Essa entrada de configuração está na seguinte seção do arquivo farm:

 

/myfarm {      /cache {          /allowedClients {

Dentro dessa configuração, você coloca uma lista de endereços IP que podem enviar solicitações de liberação.  Se uma solicitação de liberação entrar no dispatcher, ela deverá vir de um IP confiável.  Caso tenha configurado incorretamente ou enviado uma solicitação de liberação de um endereço IP não confiável, você verá o seguinte erro no arquivo de log:

 

Mon Nov 11 22:43:05 2019 W pid 3079 (tid 139859875088128) Flushing rejected from 10.43.0.57

Regras de invalidação

Essa entrada de configuração está na seguinte seção do arquivo farm:

 

/myfarm {      /cache {          /invalidate {

Normalmente, essas regras indicam quais arquivos podem ser invalidados com uma solicitação de liberação.

Para evitar que arquivos importantes sejam invalidados com uma ativação de página, você pode colocar regras que especificam quais arquivos são ok para invalidar e quais arquivos devem ser invalidados manualmente.  Este é um conjunto de amostras de configuração que permite que somente arquivos html sejam invalidados:

 

/invalidate {     /0000 { /glob "*" /type "deny" }     /0001 { /glob "*.html" /type "allow" } }

Resolução

Teste/solução de problemas

Ao ativar uma página e obter a luz verde informando que a ativação da página foi bem-sucedida, você deve esperar que o conteúdo ativado também seja liberado do cache.

Atualize sua página e veja os itens antigos e há luz verde.

Vamos seguir alguns passos manualmente no processo de liberação para nos trazer uma ideia do que poderia estar errado.  No shell do editor, execute a seguinte solicitação de liberação usando curl:

 

$ curl -H "CQ-Action: Activate" \ -H "CQ-Handle: /content/PATH TO ITEM TO FLUSH" \ -H "CQ-Path: /content/PATH TO ITEM TO FLUSH" \ -H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ -H "Host: flush" \ http: // DISPATCHER IP ADDRESS /dispatcher/invalidate .cache

Exemplo de solicitação de liberação de teste

 

$ curl -H "CQ-Action: Activate" \ -H "CQ-Handle: /content/customer/en-us" \ -H "CQ-Path: /content/customer/en-us" \ -H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ -H "Host: flush" \ http: //169 .254.196.222 /dispatcher/invalidate .cache

Depois de disparar o comando de solicitação para o dispatcher, você desejará ver o que é feito nos logs e o que é feito com os arquivos .stat.  Siga o arquivo de log e você deve ver as seguintes entradas para confirmar a ocorrência da solicitação de liberação do módulo do dispatcher

 

Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Activation detected: action=Activate /content/dam/logo.jpg Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Touched /mnt/var/www/html/.stat Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Touched /mnt/var/www/html/content/.stat Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 Touched /mnt/var/www/html/content/dam/.stat Wed Nov 13 16:54:12 2019 I pid 19173:tid 140542721578752 "GET /dispatcher/invalidate.cache" 200 purge publishfarm/- 0ms

Agora que vemos o módulo selecionado e reconhecemos a solicitação de liberação, precisamos ver como ele afetou os arquivos .stat.  Execute o seguinte comando e observe a atualização dos carimbos de data e hora à medida que emite outra liberação:

 

| $ watch -n 3 "find /mnt/var/www/html/ -type f -name " .stat " | xargs ls -la $1" |
| — |

Como você pode ver na saída do comando, os carimbos de data e hora dos arquivos .stat atuais

 

-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/dam/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/ .stat

Agora, se executarmos a liberação novamente, você verá os carimbos de data e hora serem atualizados

 

-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/dam/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/ .stat -rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/ .stat

Vamos comparar nossos carimbos de data e hora de conteúdo com nossos carimbos de data e hora de arquivos .stat

 

$ stat /mnt/var/www/html/content/customer/en-us/ .stat    File: .stat’  Tamanho: 0 Blocos: 0 Bloco de E/S: 4096 normal vaziofileDispositivo: ca90h/51856d`    `Inode: 17154125    Links: 1Acesso: (0644)/-rw-r--r--) Uid: (48/apache) Gid: (48/apache)Access: 2019-11-13 16:22:31.000000000 -0400Modificar: 2019-11-13 16:22:31.00000000 -0400Change: 2019-11-13 16:22:31.000000000 -0400`<br> <br>`$ stat/mnt/var/www/html/content/customer/en-us/logo.jpgArquivo: logo.jpg'    Size: 15856           Blocks: 32          IO Block: 4096   regular file Device: ca90h /51856d    Inode: 9175290    Links: 1 Access: (0644 /-rw-r--r-- )  Uid: (   48/  apache)   Gid: (   48/  apache) Access: 2019-11-11 22:41:59.642450601 +0000 Modify: 2019-11-11 22:41:59.642450601 +0000 Change: 2019-11-11 22:41:59.642450601 +0000

Se você observar qualquer um dos carimbos de data e hora, observará que o conteúdo tem um horário mais recente que o arquivo .stat, o que instrui o módulo a veicular o arquivo do cache, pois ele é mais recente que o arquivo .stat.

Em resumo, algo atualizou os carimbos de data e hora desse arquivo, o que não o qualifica como "liberado" ou substituído.