Configurando Cluster do Liferay via S3_PING (AWS S3) - Comunidade
Comunidade
- Home
- Infraestrutura
- Configurando Cluster do Liferay via S3_PING (AWS S3)
Configurando Cluster do Liferay via S3_PING (AWS S3)
Configurando Cluster do Liferay via S3_PING (AWS S3)
Guia para clusterizar o Liferay usando o protocolo S3_PING do JGroups para a descoberta de nós — sem depender de IPs fixos como no TCPPING.
Índice
1. Pré-requisitos
2. Configurando o tcp.xml com S3_PING
No cluster do Liferay usamos a tag S3_PING no lugar da tag TCPPING. Edite o arquivo de configuração do JGroups:
Substitua o bloco de descoberta pela tag S3_PING:
3. Configurando o portal-ext.properties
Em cada nó, adicione ao portal-ext.properties:
4. Inicialização e o que o cluster cria no bucket
Após iniciar o Liferay, serão criadas duas pastas dentro do bucket com as informações de comunicação do cluster:
Essas pastas são onde os nós registram sua presença para se descobrirem.
5. Verificação e troubleshooting
No S3_PING os nós do cluster descobrem uns aos outros através de um bucket S3 compartilhado, em vez de uma lista fixa de IPs (TCPPING). Isso facilita a operação em nuvem, onde os IPs podem mudar.
Índice
- Pré-requisitos
- Configurando o tcp.xml com S3_PING
- Configurando o portal-ext.properties
- Inicialização e o que o cluster cria no bucket
- Verificação e troubleshooting
1. Pré-requisitos
- Dois ou mais nós Liferay com a mesma versão e mesmos módulos/temas implantados.
- Document Library compartilhada entre os nós (ex.: S3 Store ou NFS) — todos os nós precisam ver os mesmos arquivos.
- Banco de dados único compartilhado por todos os nós.
- Bucket S3 acessível pelos nós, com uma access key e secret key com permissão de leitura/escrita.
- Elasticsearch remoto (modo REMOTE) compartilhado — sidecar embutido não funciona em cluster.
Credenciais: a access key e a secret key do bucket ficam no Passbolt da SEA (ou no painel da AWS / no servidor onde a Document Library está configurada). Nunca publique essas chaves no fórum nem em arquivos versionados.
2. Configurando o tcp.xml com S3_PING
No cluster do Liferay usamos a tag S3_PING no lugar da tag TCPPING. Edite o arquivo de configuração do JGroups:
| 1 | vim /opt/liferay/tomcat/unicast/tcp.xml |
Substitua o bloco de descoberta pela tag S3_PING:
| 1 | <S3_PING location="NOME_DO_BUCKET" |
| 2 | access_key="SUA_ACCESS_KEY" |
| 3 | secret_access_key="SUA_SECRET_KEY" |
| 4 | /> |
- location: o nome do bucket S3 usado para a descoberta dos nós.
- access_key / secret_access_key: credenciais da AWS, obtidas no painel da Amazon ou no servidor onde a Document Library está configurada.
3. Configurando o portal-ext.properties
Em cada nó, adicione ao portal-ext.properties:
| 1 | #CONFIG CLUSTER# |
| 2 | cluster.link.enabled=true |
| 3 | cluster.link.channel.properties.control=/opt/liferay/unicast/tcp.xml |
| 4 | cluster.link.channel.properties.transport.0=/opt/liferay/unicast/tcp.xml |
Atenção ao caminho: confirme que o caminho do tcp.xml nas propriedades corresponde ao local real do arquivo no servidor. Em caso de bundle padrão da SEA, ajuste para o caminho efetivo (ex.: /opt/liferay/tomcat/unicast/tcp.xml).
4. Inicialização e o que o cluster cria no bucket
Após iniciar o Liferay, serão criadas duas pastas dentro do bucket com as informações de comunicação do cluster:
- liferay-channel-control/
- liferay-channel-transport-0/
Essas pastas são onde os nós registram sua presença para se descobrirem.
5. Verificação e troubleshooting
- Problema na inicialização relacionado ao cluster: exclua as duas pastas (liferay-channel-control/ e liferay-channel-transport-0/) do bucket e reinicie o Liferay. Elas serão recriadas.
- Nós não se enxergam: confirme que todos usam o mesmo bucket (location), as mesmas credenciais e que têm acesso de rede ao S3.
- Conteúdo divergente entre os nós: verifique se a Document Library (S3/NFS) e o banco realmente são compartilhados por todos.
- Busca inconsistente: confirme que todos os nós apontam para o mesmo Elasticsearch remoto.
- Log do cluster: procure no log mensagens do JGroups/Cluster Link indicando o número de membros que entraram no canal (view).
Dica: suba um nó por vez na primeira vez. Confirme no log que o segundo nó "enxergou" o primeiro (view com 2 membros) antes de colocar o load balancer em produção.
5/4/23