Mantenha o Semaphore disponível quando um nó da aplicação parar

A arquitetura ativa-ativa documentada usa múltiplos nós Semaphore, banco PostgreSQL ou MySQL compartilhado, coordenação Redis e balanceador com HTTP e WebSocket. Cada nó precisa das configurações compartilhadas adequadas e identificador HA exclusivo. Planeje a disponibilidade dessas dependências junto aos nós. Só um segundo processo não fornece estado e coordenação exigidos pela topologia completa.

A arquitetura descrita é ativa-ativa, com nós equivalentes participando do serviço. Não depende de nó primário dedicado e standby passivo. Use o guia HA atual para configurar o desenho suportado e não deduza uma arquitetura ativa-passiva separada a partir de linguagem geral sobre disponibilidade. Se precisar de outra topologia, resolva estado e comportamento de failover antes da implantação.

Não. O desenho HA documentado exige banco compartilhado PostgreSQL ou MySQL e Redis. O banco é a fonte comum do estado da aplicação para os nós participantes. Se migrar de um nó com outra opção de armazenamento, planeje migração, backups e validação como trabalhos separados. A adição de nós não deve ser a primeira vez que você testa se o banco compartilhado contém e fornece os dados necessários.

Esses componentes precisam de estratégias próprias de resiliência. O desenho de múltiplos nós Semaphore não cria automaticamente failover de banco, balanceamento redundante ou Redis disponível. Identifique domínio de falha, recuperação e capacidade de cada dependência. Teste todo o caminho entre solicitação do cliente e resultado da tarefa para o plano cobrir o serviço usado, não apenas a quantidade de nós ativos.

Não presuma execução em andamento ininterrupta apenas porque há vários nós da aplicação. O comportamento depende do caminho de execução, componente que falhou e versão em uso. Teste o ciclo de vida da tarefa de que depende, incluindo atualização de status e participação de runners. Planeje também compatibilidade de atualizações e migrações, sem tratar toda mudança de versão como uma operação rolling sem indisponibilidade garantida. Disponibilidade da UI e continuidade das tarefas são requisitos distintos.

Alta disponibilidade é uma capacidade Enterprise. Comece pelos horários de operação exigidos, processo de manutenção, objetivos de recuperação e serviços existentes de banco e balanceamento. Use a topologia documentada para identificar lacunas e teste remoção de nós, recuperação de dependências e backups em ambiente representativo. Uma conversa sobre arquitetura é útil quando esses requisitos são críticos ao negócio, pois o resultado depende da implantação completa, não de uma única opção.

Esse é o objetivo de pôr nós ativos atrás de um endereço de serviço balanceado. O balanceador precisa parar de enviar solicitações ao nó indisponível e suportar HTTP e WebSocket. O nó sobrevivente ainda precisa de banco compartilhado, Redis e configuração alinhada para atender ao projeto.

Não. Múltiplos locais de execução são tratados pelos runners. HA trata da camada da aplicação Semaphore; runners tratam de onde as tarefas executam e quais sistemas alcançam. Produção pode usar ambos: nós HA para UI e API compartilhadas e runners de projeto perto da infraestrutura privada.