Comparando A Arquitetura Classic E Super Server Do Firebird

Comparando a arquitetura Classic e SuperServer do Firebird Conheça um pouco mais sobre as arquiteturas Classic e SuperServer do Firebird

Comparando a arquitetura Classic e Superserver do Firebird

A arquitetura SuperServer Mais recente que a versão Classic, é uma implementação multi-clientes e multitarefas. A arquitetura Superserver pode servir muitos clientes ao mesmo tempo usando o recurso de multi-processamento ou "threads", ao invés de processos separados para cada cliente. Threads múltiplas compartilham um único processo de servidor. Os benefícios desta arquitetura incluem: - Havendo um único processo de servidor, elimina-se os gargalos resultantes do gerenciamento ao acesso compartilhado de páginas do banco de dados e reduz a sobrecarga requerida pela inicialização de novos processos e consultas. - Melhora a performance da interação das mensagens porque uma chamada compartilhada à uma biblioteca é sempre mais rápida que os processos de comunicação entre os processos de cliente e do servidor. - Melhora a integridade do banco de dados, porque somente um processo de servidor acessa o banco de dados, muito melhor que um processo para cada cliente. Toda a funcionalidade do motor de banco de dados é encapsulada em um subsistema unificado, protegido e isolado de um erro da aplicação do usuário. - Permite o acesso às estatísticas do banco de dados e informações sobre os usuários que ferramentas podem utilizar para monitorar performance ou executar tarefas administrativas. - Tem uma relação custo-benefício melhor que a arquitetura Classic. Todos os sistemas operacionais possuem um limite no número de processos que podem ser executados concorrentemente. O SuperServer permite que um número fixo de tarefas possam ser multiplexadas através de um número potencialmente grande de conexões concorrentes ao banco de dados. Desde que estas tarefas não sejam muito pesadas ou dedicadas à uma conexão específica, o SuperServer pode suportar um grande número de usuários com um uso mínimo de recursos do sistema.

A arquitetura Classic Desenvolvida desde a versão 4 do Interbase, é baseada em processos. Para cada conexão é iniciado um processo de servidor separado para execução do motor do banco de dados, e cada processo tem um cache de banco de dados dedicado. Os processos disputam entre si o acesso ao banco de dados, portanto um subsistema de gerenciamento de travamentos é requerido para arbitrar e sincronizar o acesso concorrente à páginas do banco de dados pelos processos. Funcionamento da arquitetura Classic O servidor Classic, roda sob demanda das conexões. Quando um cliente tenta conectar-se à um banco de dados Firebird, uma instância do executável gds_inet_server é executada e permanece dedicada à conexão do cliente enquanto esta estiver ativa. O inicializador do gds_inet_server é o inetd, o processo gerenciador de serviços do Unix. Ele possui um arquivo de configuração o /etc/inetd.conf, que associa serviços com os executáveis que irão receber a conexão. Quando o inetd recebe uma requisição de conexão à um serviço disponível, ele busca o programa apropriado no arquivo de configuração, executa-o, e transfere a conexão de rede ao serviço. Quando um cliente solicita a

-2-

Comparando a arquitetura Classic e Superserver do Firebird

desconexão, o gds_inet_server fecha a conexão ao banco de dados e outros arquivos, e então sai. Quando não há clientes conectados à um banco de dados, não devem haver instâncias do gds_inet_server rodando. Gerenciamento de Travamentos O gerenciamento de travamentos é cuidado por um outro processo, o gds_lock_mgr. Este programa é iniciado quando um segundo cliente conecta-se ao mesmo banco de dados. O trabalho do gerenciador de travamentos é servir (metaforicamente) como um policial de trânsito. Ele garante o travamento de recursos do banco de dados para os clientes. Isto também requer que os clientes notifiquem os travamentos de um recurso quando este recurso é solicitado por outros clientes. O gds_lock_mgr permanece rodando mesmo depois que o último cliente de desconecta. Na próxima vez que um cliente conectar-se, isto pode evitar a sobrecarga de inicialização do gerenciador de processos. Uso de sinalizadores Posix O processo gds_lock_mgr comunica-se com cada processo cliente utilizando uma área de memória compartilhada, através de um mecanismo de sinalização usando os sinais POSIX SIGUSR1 e SIGUSR2. Os sinais são únicos nas rotinas de manipulação em libgdslib.a, e por esta razão as aplicações dos usuários não devem manipular os sinais ou modificar a máscara dos sinais. Aplicações que necessitem o uso de sinais POSIX devem ser compiladas com uma biblioteca alternativa do Firebird, a libgds.a. Esta bilblioteca tem funcões idênticas à libgdslib.a, mas ela manipula os sinais enviados pelo gerenciador de travamentos em um processo-filho chamado gds_pipe. Todas as aplicações clientes compiladas com a libgds.a rodam automaticamente com este processo-filho. Não são necessárias modificações no código da aplicação, somente uma opção de linkagem diferente. Uso de recursos do sistema Cada instância do gds_inet_server mantém um cache das páginas do banco de dados em seu espaço de memória, o que pode resultar em duplicação dos dados armazenados no sistema. Enquanto o uso de recursos por clientes é maior que na versão Superserver, a versão Classic usa menos recursos de sistema quando o número de conexões concorrentes é baixo. Método de acesso local A arquitetura Classic permite que processos façam acesso de I/O diretamente aos arquivos de bancos de dados, enquanto a arquitetura SuperServer requer que as aplicações solicitem ao servidor operações de I/O por um proxy, usando um método de rede. O método de acesso local é mais rápido que o acesso por rede, mas só é utilizável por aplicações que rodem na mesma máquina do banco de dados. Monitorando conexões ao banco de dados A chamada de informações sobre as conexões ao banco de dados sempre retornam exatamente uma conexão no servidor Classic, não importa quantos clientes estejam conecatados a bancos de dados naquele servidor. A razão disto é que cada conexão de cliente tem seu próprio processo gds_inet_server no servidor, e cada instância deste programa conhece somente a sua própria conexão. Somente o SuperServer faz com que o processo de servidor tenha a capacidade de reconhecer todos os clientes conectados no servidor.

-3-

Comparando a arquitetura Classic e Superserver do Firebird

Segurança Em função da versão Classic poder trabalhar com uma mistura de clientes locais e remotos como usuários diferentes, os executáveis gds_inet_server e gds_lock_mgr devem rodar como o super-usuário root. Os processos devem rodar com uma identidade do root para definir sua efetivas identidades para as identidades de clientes. O gerenciador de travamentos precisa ter privilégios de super-usuário para enviar sinais aos processos. Em alguns ambientes, a presença de executávies com bits setuid ligados podem afetar a segurança. Mesmo assim, não mude a configuração de execução do servidor Firebird. A uso do super-usuário para bits setuid do servidor Classic é importante para o seu funcionamento. Como as aplicações podem rodar com qualquer número de uid, os arquivos de banco de dados devem conceder permissão de escrita para todos os uids que acessam os bancos de dados. Para simplificar a manutenção, os arquivos de bancos de dados são criados com permissão de escrita por todo mundo. Com cuidado, você pode restringir estas permissões, então os arquivos de bancos de dados podem ser protegidos de danos acidentais ou deliberados. Tenha certeza que você conhece e entende de permissões de acesso à arquivos antes de tentar modificar isto, porque todos os clientes locais e remotos precisam de acesso de escrita ao banco de dados, a menos que se deseje apenas que leiam dados.

Comparando Classic e SuperServer Funcionamento do SuperServer Um servidor SuperServer roda como um único processo, uma única carga do executável ibserver. Ele é iniciado uma vez apenas pelo administrador do sistema ou por um script de inicialização. Este processo está sempre rodando, esperando por um pedido de conexão. Quando não há nenhum cliente conectado a um banco de dados no servidor o ibserver continua rodando silenciosamente. O processo do SuperServer não depende do inetd; ele espera por uma requisição de conexão ao serviço gds_db por si mesmo. O processo do SuperServer é uma aplicação multi-thread (multi-processada). Diferentes threads com processos são dedicadas à diferentes processos. Normalmente, uma thread espera por uma requisição de conexão na porta do serviço gds_db. Outras threads são análogas aos processos individuais de gds_inet_server no modelo clássico, servindo consultas de clientes. Outra thread serve ao gerenciador de travamentos, substituindo o processo gds_lock_mgr do modelo Classic. Gerenciamento de Travamentos O gerenciador de travamentos no SuperServer é implementado como uma thread no executável ibserver. Por isto o Firebird não utiliza o processo gds_lock_mgr. Assim sendo, sinalizadores POSIX não são utilizados pela thread do gerenciador de travamentos no SuperServer; e sim mecanismos de comunicação interthread.

-4-

Comparando a arquitetura Classic e Superserver do Firebird

Uso de recursos do sistema O modelo SuperServer tem menos sobrecarga e usa menos recursos por conexão de clientes que o modelo Classic. O Superserver usa um único espaço de cache para todas as ligações de clientes, permitindo um uso mais eficiente da memória cache. Por estas e outras razões, o modelo SuperServer têm demonstrado uma habilidade de servir de forma mais eficiente um grande número de clientes concorrentes. Servidores multi-threads e UDF's As UDF's (User-Defined Functions) são bibliotecas de funções que você pode adicionar para extender o conjunto de funções que o servidor Firebird suporta. As funções em sua bibliteca UDF são executadas no contexto do processo do servidor. Através da implementação de threads do SuperServer, existem questões com UDFs que requerem que você escreva as funções da UDF com mais cuidado do que no modelo Classic. Você precisa projetar UDF's para o SuperServer como funções thread-safe. Você não pode utilizar variáveis globais em sua UDF, porque dois clientes rodando a UDF simultâneamente, vão conflitar no seu uso com variáveis globais. Não utilize variáveis as globais da thread para simular variáveis globais. O modelo SuperServer implementa uma espécie mecanismo de armazenamento de threads, para compartilhar threads através de todas as conexões de clientes. Isto é como se um cliente executar uma UDF duas vezes, que cada execução não seja executada no contexto da mesma thread. Isto significa que você não pode depender de variáveis locais da thread para guardar valores de uma execução da UDF para outra. UDFs que aloquem memória dinâmicamente correm o risco de criar um espaço perdido na memória. Imaginando-se que o SuperServer irá permanecer no ar e rodando indefinidamente, não somente durante o tempo de vida da conexão do cliente, espaços de memória perdidos podem ser mais nocivos ao SuperServer do que o modelo Classic. Se suas UDFs retornam objetos alocados dinamicamente, então você deve utilizar a função malloc() para alocar memória para estes objetos (na plataforma Windows, você deve utilizar ib_util_malloc() ou o malloc() que é parte da biblioteca de runtime do Microsoft Visual C++). Não use new ou globalalloc() ou a função malloc() do compilador da Borland. Finalmente, estas funções devem ser declaradas nos bancos de dados com a opção FREE_IT da instrução DECLARE EXTERNAL FUNCTION. Em contraste, no modelo Clássico, por haver um processo separado para cada conexão de cliente, as UDF's estão garantidas que não conflitarão. Variáveis globais são seguras para utilização. Também espaços perdidos de memória não são perigosos, porque qualquer espaço perdido é liberado quando o cliente se desconecta. Portanto a recomendação é que o uso de UDF's para o SuperServer deve ser mais restrito do que o uso no modelo Classic. Se você utiliza o modelo Classic, certifique-se de que suas UDF's não oferecem risco de uso no modelo SuperServer antes de efetuar o upgrade. Se estas forem construídas dentro dos padrões estabelecidos, não oferecerão riscos, caso contrário deverão ser reescritas. Segurança O modelo SuperServer pode ser configurado para rodar com uma uid não-root, para melhor segurança. Você pode ainda restringir as permissões nos arquivos de banco de dados somente para a uid do servidor Firebird, para acessar o banco de dados.

-5-

Comparando a arquitetura Classic e Superserver do Firebird

Porque dois modelos? O modelo Classic é anterior ao SuperServer, e o SuperServer é o futuro do Firebird. A configuração Classic é utilizada em sistemas operacionais que não dispõe de tecnologia para executar aplicações multi-thread, requerida pelo SuperServer. É possivel utilizar o modelo Classic para plataformas que suportam esta tecnologia, exceto a plataforma Windows, que dispõe apenas do modelo SuperServer. O SuperServer tem a capacidade de atender as demandas de um sistema multiusuário em expansão, mantendo uma boa performance e eficiência. O modelo SuperServer foi implementado em todas as plataformas que suportam sua tecnologia. É a intenção que o SuperServer seja a direção futura do Firebird para todas plataformas.

Fonte.: http://www.ibphoenix.com

-6-