Tag: prosody

  • Alta disponibilidade acessível

    Venho há algumas semanas organizando uma forma de ter alta disponibilidade para o serviço isaCloud. É claro que o conceito de alta disponibilidade precisa ser de acordo com as demandas do “negócio” (entre aspas porque isaCloud é um serviço sem fins comerciais).

    O que eu tenho pensado:

    • Ter um cold site, isto é, um segundo datacenter (ou site secundário) com dados replicados que possa assumir o serviço
    • Não preciso ter failover automático
    • O chaveamento dos sites pode tolerar uma mudança e propagação de DNS (até 1h, digamos)

    Comecei configurando um simples lsync entre o datacenter A e o datacenter B. Estou há duas semanas mantendo essa replicação ativa de dados e configurações entre um servidor no Brasil e um na Holanda.

    Eu testei a virada de DNS de um dos domínios que tenho no isaCloud e a seguir compartilho o que funcionou e o que não funcionou:

    ✅ Consistência do histórico de mensagens
    ✅ Baixa latência para replicação
    ✅ Configurações do servidor e certificados
    ✅ Boot do serviço
    ✅ Reconexão de conversas com usuários de servidores externos
    🔴 Reconexão de conversas com usuários de outros domínios também do isaCloud

    Como mencionei ali em cima, eu virei apenas 1 domínio dos 5 que tenho no isaCloud e, nesse caso, a comunicação entre o domínio “migrado” pro site secundário e os demais que ficaram no site primário não funcionou bem porque os domínios que ficaram achavam ainda que o domínio em questão ainda era servido pelo site primário.

    Outra questão que não ficou clara para mim é sobre deixar previamente configuradas entradas de DNS SRV com menor prioridade para que a escolha pelo site secundário fosse automática. Mas isso tem uns poréns:

    • Pro meu teste não funcionou porque o site primário continuava acessível no target da entrada SRV já que os demais domínios seguiam funcionando lá
    • No caso de um failover automático pro site secundário através dessa entrada SRV com prioridade menor, o failback acabaria acontecendo automaticamente se o site primário voltasse a responder sozinho – porém os dados no site primário estariam desatualizados.

    Bem, ainda tô desenhando a melhor forma de fazer isso tudo:

    • Failover automático com faiback manual
    • Failover manual alterando o hostname pra onde os SRV apontam

    Num próximo post eu compartilho o que ficou decidido e como ficou implementado.

    Com carinho,
    Isadora.

  • Como eu cheguei no Lua

    Foi sorte… de verdade.

    Quando comecei a pesquisar sobre XMPP depois de ANOS afastada desse protocolo tão legal, me deparei com uma lista de servidores XMPP no site da XSF (https://xmpp.org).

    Eu tinha a lembrança nítida do Openfire, um dos servidores mais clássicos e padrões desde 2003 pelo menos.

    Mas eu queria recomeçar meu contato com o ecossistema. Olhei vários nomes de servidores na lista até que um deles me chamou atenção: Prosody. Ali indicava ser feito em Lua e eu pensei: “deve ser leve, acho que merece ser estudado”.

    Entrei na documentação, no repositório, olhei, olhei… parecia simples de implementar. E assim foi.

    Comecei a me debruçar sobre o Prosody, preparar container para implantação, comecei a conhecer o código fonte, a modularização, a lista enorme de módulos de comunidade e fiquei apaixonada: é isso!

    Cheguei num ponto em que já escrevi alguns pequenos módulos e modifiquei o comportamento de alguns componentes core para que a jornada de novos usuaŕios no isaCloud fosse mais amigável.

    Não me arrependo! Estou super satisfeita depois de quase 8 meses de uso, sem reclamações.

    Ter contato com os desenvolvedores diretamente por um canal XMPP também dá muita confiança de que resolver problemas não é um caminho tão árduo.

    Fico feliz de hoje estar tão confortável a ponto de poder ajudar mais pessoas que estão na jornada do Prosody.