PostgreSQL: Cluster e Alta Disponibilidade

A seção inicia estabelecendo a relação entre o crescimento de atividades econômicas que utilizam redes eletrônicas (e-business) e o aumento da demanda por recursos computacionais. O e-commerce é citado como a principal atividade dentro desse contexto, ilustrando a crescente necessidade de processamento e armazenamento de informações em larga escala. A dependência das plataformas tecnológicas para transações comerciais, administrativas e contábeis, envolvendo governos, empresas e consumidores, torna evidente a pressão sobre a infraestrutura de TI existente. Esta crescente demanda por processamento de dados e transações online é um dos principais motivadores para a busca por soluções mais eficientes e escaláveis de processamento de dados. A seção, portanto, estabelece o cenário de uma crescente necessidade de capacidade computacional para atender as demandas do mercado digital e das transações online.

O foco principal dessa parte é a identificação e a proposta de soluções para o problema de subutilização de recursos computacionais na administração pública. Estima-se que existam cerca de 300 mil estações de trabalho, com um padrão de uso concentrado nos horários comerciais, resultando em grandes períodos de ociosidade durante o dia e fora do expediente. Este imenso potencial computacional desperdiçado poderia ser explorado através de paradigmas de computação probabilística e Grid Computing. A ineficiência na utilização desses recursos é destacada como um problema de alocação financeira inadequada, pois recursos são investidos em equipamentos subutilizados que poderiam ser direcionados para áreas com demandas mais urgentes. A busca por alternativas como cluster e grid computing surge como uma solução para o problema de computação sob demanda, minimizando a capacidade ociosa e otimizando o uso dos recursos existentes. É mencionado também o potencial de utilização desses recursos ociosos por universidades e centros de pesquisa para projetos científicos. Exemplos de soluções desenvolvidas no Brasil, como o vCluster (PUCRS) e o Ourgrid (UFCG), são citados como evidência de iniciativas para lidar com este problema.

Esta subseção enfatiza a existência de diversas atividades de pesquisa e soluções desenvolvidas em universidades brasileiras para o aproveitamento da capacidade de processamento ociosa. A menção a uma lista de projetos internacionais (disponível em um link para a Wikipédia) contextualiza o esforço brasileiro nessa área. Dois projetos brasileiros são especificamente destacados: o vCluster, desenvolvido pela Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS), e o Ourgrid, desenvolvido pela Universidade Federal de Campina Grande (UFCG). A existência destes projetos demonstra a capacidade de pesquisa e desenvolvimento nacional na área de cluster e grid computing, e a possibilidade de adaptação e implementação de soluções eficazes para a otimização do uso dos recursos computacionais existentes na administração pública, reduzindo custos e melhorando a eficiência dos serviços públicos.

Esta seção descreve a computação de grande porte, tradicionalmente baseada em mainframes. Os mainframes são caracterizados por sua capacidade de processar grandes volumes de informações e transações, servindo milhares de usuários através de redes distribuídas. Sua alta velocidade de operação e grande capacidade de armazenamento de dados são destacadas. A IBM e seu projeto System/360 (1964) são mencionados como marcos históricos. A seção também introduz os supercomputadores, criados na década de 1960 por Seymour Cray e sua empresa Cray Research (dominante no mercado entre 1965 e 1990). A distinção entre mainframes e supercomputadores é abordada, enfatizando que os supercomputadores são otimizados para tarefas com restrições de tempo de cálculo (processamento intensivo), enquanto os mainframes priorizam alta disponibilidade, alta taxa de transferência de dados e acessos simultâneos. A Figura 2.1 ilustra a evolução da carga de processamento e o uso da computação de grande porte, mostrando a aquisição de soluções com capacidade superior à demanda inicial para maximizar o tempo de operação, devido ao alto custo do equipamento. Essa abordagem, no entanto, gera capacidade ociosa significativa, conforme mostrado na figura.

Em contraste com a computação de grande porte, a seção apresenta a computação distribuída como uma alternativa mais eficiente e escalável. O texto destaca a facilidade de dimensionamento de ambientes cluster, que utilizam componentes físicos comuns e permitem a adição de novos recursos conforme a demanda aumenta. Essa característica permite um dimensionamento rápido e com custo reduzido. A arquitetura mais aberta e a disponibilidade de hardwares de mercado contribuem para essa vantagem. A Figura 2.1 é novamente referenciada para comparar o uso de capacidade de processamento entre a computação de grande porte e a distribuída, demonstrando a superior utilização de recursos nos ambientes cluster. A subutilização de recursos na computação de grande porte é associada ao alto custo de hardware e à dificuldade de dimensionamento, enquanto os clusters se apresentam como solução para este problema, maximizando o uso da capacidade de processamento.

Esta seção faz uma comparação entre as arquiteturas de computação de grande porte e distribuída, ressaltando similaridades em termos de complexidade da infraestrutura física: segurança, controle de acesso, refrigeração, e organização do espaço. A adoção de tecnologias cluster e grid, assim como outras inovações tecnológicas, impacta nas relações entre usuários e sistemas computacionais, e nos processos de desenvolvimento e aplicação de sistemas informatizados. O texto enfatiza que não existe uma tecnologia superior de forma global, cada uma tendo seu nicho de aplicação. A quinta geração da computação distribuída, também conhecida como grid computing, é descrita como a utilização de um pool virtual de recursos computacionais, permitindo que o cliente acesse a capacidade computacional necessária sem precisar controlar a localização dos recursos. A importância da análise prévia dos benefícios, riscos e impactos da adoção de tecnologias cluster e grid pelos gestores e técnicos é ressaltada. A decisão sobre qual tecnologia, o momento da adoção e a metodologia a serem empregadas devem ser criteriosas.

A seção discute a crescente necessidade de mecanismos de replicação para o PostgreSQL em sistemas de grande porte, impulsionada pelo seu crescimento no mercado corporativo. Soluções de replicação pré-existentes, como o Slony-I 4.1.1, permitiam escalabilidade para milhares de consultas simultâneas, mas apresentavam problemas de performance e dificuldade de manutenção, limitando sua adoção em larga escala. A busca por uma solução mais eficiente e fácil de implementar é o contexto principal desta seção. Antes do lançamento do PostgreSQL 9.0, as ferramentas existentes apresentavam limitações significativas em termos de desempenho e facilidade de administração, tornando a implantação de sistemas de replicação complexa e custosa, dificultando sua adoção por empresas que necessitavam de soluções de alta disponibilidade e escalabilidade para seus bancos de dados.

O lançamento do PostgreSQL 9.0 trouxe a solução para o problema anterior: o mecanismo de Hot Standby. Essa inovação possibilita a configuração de um cluster Master-Slave em poucos minutos, de forma relativamente segura e confiável, utilizando apenas a configuração do banco de dados. O Hot Standby é descrito como um recurso que permite conectar ao banco de dados para executar operações de leitura enquanto o servidor está em modo archive recovery ou standby. Ele simplifica tanto a replicação de dados quanto a restauração de backups. A possibilidade do servidor mudar de um estado de recuperação para operação normal, enquanto os usuários mantêm suas conexões abertas, é outra vantagem mencionada. Apesar das vantagens, os dados em standby possuem um atraso mensurável em relação ao servidor primário, resultando em consistência eventual. Somente após o registro do commit da transação no servidor standby as mudanças são visíveis. Restrições quanto ao uso de Data Manipulation Language (DML) em modo de recuperação são mencionadas, assim como a ausência de suporte a triggers nesse contexto.

A seção compara o Hot Standby com outros modelos de replicação de bancos de dados. É enfatizado que diferentes modelos atendem a diferentes necessidades e que um único modelo dificilmente se adapta a todas elas. A replicação assíncrona do Slony-I, que utiliza triggers para coletar as atualizações, é mencionada como um exemplo de um modelo distinto. A replicação multi-master é apresentada como uma alternativa, onde as transações são enviadas a todos os servidores do cluster, mantendo a informação sempre atualizada. No entanto, esse método apresenta perda de performance na inserção de dados, uma vez que é necessário aguardar a propagação dos dados antes de torná-los disponíveis para consulta. A complexidade de gerenciar um sistema de replicação multi-master é implícita na comparação com a simplicidade do Hot Standby. Apesar de não ser um sistema multi-master, o Hot Standby do PostgreSQL tem planos para se tornar multi-master em uma versão futura, o que demonstra a evolução e adaptação da tecnologia às demandas do mercado.

A seção introduz o PGpool, um middleware para PostgreSQL distribuído sob licença BSD. Sua principal função é atuar como intermediário entre os clientes e os servidores de banco de dados, fornecendo alta disponibilidade, replicação e balanceamento de carga. Além dessas funcionalidades, o PGpool otimiza a gestão de conexões, salvando as conexões com os servidores PostgreSQL e reutilizando-as quando novas conexões com as mesmas propriedades (usuário, banco de dados, protocolo) chegam. Esse recurso reduz a sobrecarga de conexão e aumenta a taxa de transferência de todo o sistema. O PGpool, no entanto, trabalha atualmente apenas com dois servidores PostgreSQL. Em caso de indisponibilidade de um servidor, o PGpool tenta continuar o serviço com o servidor ativo em um modo chamado de "modo degenerado". A recuperação de um servidor com problemas requer sincronização manual dos bancos de dados, geralmente através de ferramentas como o rsync, seguido de reinicialização dos bancos e do PGpool. Dois modos de operação são descritos: o modo "restrict", padrão e mais seguro, e a utilização da palavra-chave /STRICT/ para melhorar o desempenho, mas com o risco de deadlocks.

A seção apresenta o PGpool-II, uma versão avançada do PGpool, que melhora significativamente o desempenho através da utilização de código-fonte otimizado e processamento paralelo em múltiplos nós. Sua arquitetura é baseada em um "System DB", que processa as informações administrativas e operações agregadas, e múltiplos nós onde os dados são armazenados. A inclusão e alteração de novos dados se baseiam em regras de particionamento predefinidas, definidas por funções SQL e armazenadas no System DB. Esta arquitetura permite um melhor balanceamento de carga e maior escalabilidade em comparação com o PGpool original. A diferença fundamental em relação ao PGpool está na arquitetura distribuída e no uso de processamento paralelo, permitindo maior eficiência e escalabilidade para lidar com grandes volumes de dados e transações. A arquitetura do PGpool-II, ilustrada em uma figura (não apresentada aqui), demonstra a sua complexidade e capacidade de processamento distribuído.

A seção detalha a Licença Pública Geral GNU (GPL), que visa garantir a liberdade de compartilhar e modificar softwares livres, assegurando que o software permaneça livre para todos os usuários. A GPL é aplicável à maioria dos softwares da Free Software Foundation e a outros programas cujos autores optam por utilizá-la. A licença abrange a cópia, distribuição e modificação do software, mas exclui outras atividades. A execução do programa em si não tem restrições, porém o resultado gerado só é coberto pela licença se constituir uma obra derivada. A licença busca garantir a liberdade do usuário, permitindo a cópia, a distribuição e a modificação do software, desde que as condições da licença sejam cumpridas. A licença abrange uma ampla gama de direitos e obrigações, incluindo a preservação da condição livre de todos os derivados do software, promovendo o compartilhamento e a reutilização de software. O texto detalha que outras atividades além da cópia, distribuição e modificação não estão cobertas pela licença, estando fora de seu escopo.

Esta seção detalha os termos e condições específicos para copiar, distribuir e modificar o software sob a licença GPL. A licença se aplica a qualquer programa contendo um aviso de que pode ser distribuído sob seus termos. É descrito como o programa modificado deve incluir um aviso de direitos autorais, uma notificação sobre a ausência de garantia e instruções para os usuários sobre como visualizar uma cópia da licença. A licença também define as condições para modificações, incluindo a obrigatoriedade de fornecer o código-fonte correspondente a qualquer terceiro por um custo razoável. A licença especifica que, ao modificar ou distribuir o programa, o usuário está aceitando os termos da licença. É enfatizada a invalidade de qualquer tentativa de copiar, modificar, sublicenciar ou distribuir o programa de forma contrária aos termos da licença. A seção esclarece que terceiros que receberam cópias ou direitos sob a licença não têm suas licenças rescindidas, desde que cumpram os termos da mesma.

A seção aborda as restrições geográficas que podem ser aplicadas caso a distribuição e/ou uso do programa seja restrito em certos países devido a patentes ou interfaces protegidas por direitos autorais. Nesse caso, o titular original dos direitos autorais pode adicionar uma limitação geográfica explícita à licença. A seção enfatiza que a licença não tem o objetivo de induzir à violação de patentes ou direitos de propriedade. A exclusão de garantia é claramente estabelecida: como o programa é licenciado sem custo, não há garantia, no limite permitido pela lei aplicável. O programa é fornecido "no estado em que se encontra", sem garantias explícitas ou implícitas, incluindo garantias de comerciabilidade e adequação a uma finalidade específica. O risco total quanto à qualidade e desempenho do programa é assumido pelo usuário. O texto destaca que se o programa contiver defeitos, o usuário arcará com os custos de serviços, reparos ou correções necessárias. A possibilidade de incorporar partes do programa em outros programas livres, com condições de distribuição diferentes, é abordada, sujeita à aprovação do autor original.