SlideShare uma empresa Scribd logo
Comparando a arquitetura Classic e Superserver do Firebird
                       Autor: Equipe IBPhoenix Tradução/Adaptação: Paulo Vaz


A arquitetura SuperServer
   Mais recente que a versão Classic, é uma implementação multi-clientes e multi-
tarefas.
   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 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.

   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.

  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.

 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 multi-
 usuá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.



                  Artigo Original:

http://www.ibphoenix.com/main.nfs?a=ibphoenixA
pp&l=;IBPHOENIXAPP.PAGES;NAME='ibp_ss_v
                    s_classic'

              Equipe da IBPhoenix
               www.ibphoenix.com


             Tradução e adaptação:                                    Comunidade Firebird de Língua Portuguesa

                                                                                Visite a Comunidade em:
                Paulo Vaz
        paulo@multi-informatica.com.br                                    http://www.comunidade-firebird.org

       A Comunidade Firebird de Língua Portuguesa foi autorizada pelo Autor do Original para elaborar esta tradução.

Mais conteúdo relacionado

Mais procurados

Virtualização Teste
Virtualização TesteVirtualização Teste
Virtualização Teste
gabrielca200
 
Apostilas modelo cliente servidor
Apostilas   modelo cliente servidorApostilas   modelo cliente servidor
Apostilas modelo cliente servidor
Daniel Silveira
 
Alta Disponibilidade utilizando Pacemaker e DRBD
Alta Disponibilidade utilizando Pacemaker e DRBDAlta Disponibilidade utilizando Pacemaker e DRBD
Alta Disponibilidade utilizando Pacemaker e DRBD
Frederico Madeira
 
Virtualização com Hyper-V
Virtualização com Hyper-VVirtualização com Hyper-V
Virtualização com Hyper-V
CDS
 
Windows Server 2012 - O poder de multiplos servidores, a simplicidade de um
Windows Server 2012 - O poder de multiplos servidores, a simplicidade de umWindows Server 2012 - O poder de multiplos servidores, a simplicidade de um
Windows Server 2012 - O poder de multiplos servidores, a simplicidade de um
Fabio Hara
 
Infnet Infra Day II - Server Core na prática
Infnet Infra Day II - Server Core na práticaInfnet Infra Day II - Server Core na prática
Infnet Infra Day II - Server Core na prática
Invent IT Solutions
 
Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2
Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2
Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2
Invent IT Solutions
 
Sistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na WebSistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na Web
Rafael Chagas
 
Windows server 2012 active directory e server manager fabio hara
Windows server 2012 active directory e server manager fabio haraWindows server 2012 active directory e server manager fabio hara
Windows server 2012 active directory e server manager fabio hara
Fabio Hara
 
Simulado traduzido 70 410
Simulado traduzido 70   410Simulado traduzido 70   410
Simulado traduzido 70 410
dionilson lemos
 
Varnish no clicRBS
Varnish no clicRBSVarnish no clicRBS
Varnish no clicRBS
Lincolm Aguiar
 
planejamento pre-instalacao win server 2012
 planejamento pre-instalacao win server 2012 planejamento pre-instalacao win server 2012
planejamento pre-instalacao win server 2012
Yan Ferrari Ferreira
 
Alta Disponibilidade em Linux com Heartbeat e Drbd
Alta Disponibilidade em Linux com Heartbeat e DrbdAlta Disponibilidade em Linux com Heartbeat e Drbd
Alta Disponibilidade em Linux com Heartbeat e Drbd
Frederico Madeira
 
Como criar infraestrutura de sites para receber milhões de usuários?
Como criar infraestrutura de sites para receber milhões de usuários?Como criar infraestrutura de sites para receber milhões de usuários?
Como criar infraestrutura de sites para receber milhões de usuários?
Marcelo Dieder
 
Apresentação Windows Server 2012 R2
Apresentação Windows Server 2012 R2Apresentação Windows Server 2012 R2
Apresentação Windows Server 2012 R2
Invent IT Solutions
 
Trabalho sobre Proxy
Trabalho sobre ProxyTrabalho sobre Proxy
Trabalho sobre Proxy
Anderson Zardo
 
Windows Server 2012 - estilo de trabalho moderno
Windows Server 2012 - estilo de trabalho modernoWindows Server 2012 - estilo de trabalho moderno
Windows Server 2012 - estilo de trabalho moderno
Fabio Hara
 
Gfs slides
Gfs slidesGfs slides
Nginx, Apache e Varnish
Nginx, Apache e VarnishNginx, Apache e Varnish
Nginx, Apache e Varnish
Ricardo Martins ☁
 
Palestra Hyper-V
Palestra Hyper-VPalestra Hyper-V
Palestra Hyper-V
Impacta Eventos
 

Mais procurados (20)

Virtualização Teste
Virtualização TesteVirtualização Teste
Virtualização Teste
 
Apostilas modelo cliente servidor
Apostilas   modelo cliente servidorApostilas   modelo cliente servidor
Apostilas modelo cliente servidor
 
Alta Disponibilidade utilizando Pacemaker e DRBD
Alta Disponibilidade utilizando Pacemaker e DRBDAlta Disponibilidade utilizando Pacemaker e DRBD
Alta Disponibilidade utilizando Pacemaker e DRBD
 
Virtualização com Hyper-V
Virtualização com Hyper-VVirtualização com Hyper-V
Virtualização com Hyper-V
 
Windows Server 2012 - O poder de multiplos servidores, a simplicidade de um
Windows Server 2012 - O poder de multiplos servidores, a simplicidade de umWindows Server 2012 - O poder de multiplos servidores, a simplicidade de um
Windows Server 2012 - O poder de multiplos servidores, a simplicidade de um
 
Infnet Infra Day II - Server Core na prática
Infnet Infra Day II - Server Core na práticaInfnet Infra Day II - Server Core na prática
Infnet Infra Day II - Server Core na prática
 
Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2
Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2
Ciclo de Palestras Infnet 2014 - Migrando o dc para Windows Server 2012 R2
 
Sistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na WebSistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na Web
 
Windows server 2012 active directory e server manager fabio hara
Windows server 2012 active directory e server manager fabio haraWindows server 2012 active directory e server manager fabio hara
Windows server 2012 active directory e server manager fabio hara
 
Simulado traduzido 70 410
Simulado traduzido 70   410Simulado traduzido 70   410
Simulado traduzido 70 410
 
Varnish no clicRBS
Varnish no clicRBSVarnish no clicRBS
Varnish no clicRBS
 
planejamento pre-instalacao win server 2012
 planejamento pre-instalacao win server 2012 planejamento pre-instalacao win server 2012
planejamento pre-instalacao win server 2012
 
Alta Disponibilidade em Linux com Heartbeat e Drbd
Alta Disponibilidade em Linux com Heartbeat e DrbdAlta Disponibilidade em Linux com Heartbeat e Drbd
Alta Disponibilidade em Linux com Heartbeat e Drbd
 
Como criar infraestrutura de sites para receber milhões de usuários?
Como criar infraestrutura de sites para receber milhões de usuários?Como criar infraestrutura de sites para receber milhões de usuários?
Como criar infraestrutura de sites para receber milhões de usuários?
 
Apresentação Windows Server 2012 R2
Apresentação Windows Server 2012 R2Apresentação Windows Server 2012 R2
Apresentação Windows Server 2012 R2
 
Trabalho sobre Proxy
Trabalho sobre ProxyTrabalho sobre Proxy
Trabalho sobre Proxy
 
Windows Server 2012 - estilo de trabalho moderno
Windows Server 2012 - estilo de trabalho modernoWindows Server 2012 - estilo de trabalho moderno
Windows Server 2012 - estilo de trabalho moderno
 
Gfs slides
Gfs slidesGfs slides
Gfs slides
 
Nginx, Apache e Varnish
Nginx, Apache e VarnishNginx, Apache e Varnish
Nginx, Apache e Varnish
 
Palestra Hyper-V
Palestra Hyper-VPalestra Hyper-V
Palestra Hyper-V
 

Semelhante a Cflp t017

Cliente e servidor
Cliente e servidorCliente e servidor
Cliente e servidor
Davi Silva
 
Aula04 Sistemas Distribuídos - Processos
Aula04 Sistemas Distribuídos - ProcessosAula04 Sistemas Distribuídos - Processos
Aula04 Sistemas Distribuídos - Processos
Messias Batista
 
Aula 2 arquitecturas de sgbd, utilizadores, perfis
Aula 2   arquitecturas de sgbd, utilizadores, perfisAula 2   arquitecturas de sgbd, utilizadores, perfis
Aula 2 arquitecturas de sgbd, utilizadores, perfis
Hélio Martins
 
Redes de computador
Redes de computadorRedes de computador
Redes de computador
tecnicacomputador
 
Sistemas operacionais de redes II
Sistemas operacionais de redes IISistemas operacionais de redes II
Sistemas operacionais de redes II
Daniel Brandão
 
Aula 3 banco de dados
Aula 3   banco de dadosAula 3   banco de dados
Aula 3 banco de dados
Jorge Ávila Miranda
 
World Wide Web
World Wide WebWorld Wide Web
World Wide Web
Sérgio Rocha
 
Arquitetura Cliente-Servidor
Arquitetura Cliente-ServidorArquitetura Cliente-Servidor
Arquitetura Cliente-Servidor
Israel Messias
 
Poster08
Poster08Poster08
Poster08
Simba Samuel
 
Comparação entre p2 p e cs
Comparação entre p2 p e csComparação entre p2 p e cs
Comparação entre p2 p e cs
Ana Paula Gama
 
Comparação entre p2 p e cs
Comparação entre p2 p e csComparação entre p2 p e cs
Comparação entre p2 p e cs
Ana Paula Gama
 
Comparação entre p2 p e cs
Comparação entre p2 p e csComparação entre p2 p e cs
Comparação entre p2 p e cs
Ana Paula Gama
 
222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores
Marco Guimarães
 
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptxAula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
ChadidoDiogo1
 
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
Deep Tech Brasil
 
Apostila Oracle 10g
Apostila Oracle 10gApostila Oracle 10g
Apostila Oracle 10g
Andre Nascimento
 
Arquitetura cliente servidor
Arquitetura cliente servidorArquitetura cliente servidor
Arquitetura cliente servidor
Marcia Abrahim
 
Aula2 caracteristicas da_tecnologia_de_banco_de_dados
Aula2 caracteristicas da_tecnologia_de_banco_de_dadosAula2 caracteristicas da_tecnologia_de_banco_de_dados
Aula2 caracteristicas da_tecnologia_de_banco_de_dados
Antony Barbosa
 
Programação Concorrente - Objetos e Concorrência
Programação Concorrente - Objetos e ConcorrênciaProgramação Concorrente - Objetos e Concorrência
Programação Concorrente - Objetos e Concorrência
Fabio Moura Pereira
 
SI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoSI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de Código
Frederico Madeira
 

Semelhante a Cflp t017 (20)

Cliente e servidor
Cliente e servidorCliente e servidor
Cliente e servidor
 
Aula04 Sistemas Distribuídos - Processos
Aula04 Sistemas Distribuídos - ProcessosAula04 Sistemas Distribuídos - Processos
Aula04 Sistemas Distribuídos - Processos
 
Aula 2 arquitecturas de sgbd, utilizadores, perfis
Aula 2   arquitecturas de sgbd, utilizadores, perfisAula 2   arquitecturas de sgbd, utilizadores, perfis
Aula 2 arquitecturas de sgbd, utilizadores, perfis
 
Redes de computador
Redes de computadorRedes de computador
Redes de computador
 
Sistemas operacionais de redes II
Sistemas operacionais de redes IISistemas operacionais de redes II
Sistemas operacionais de redes II
 
Aula 3 banco de dados
Aula 3   banco de dadosAula 3   banco de dados
Aula 3 banco de dados
 
World Wide Web
World Wide WebWorld Wide Web
World Wide Web
 
Arquitetura Cliente-Servidor
Arquitetura Cliente-ServidorArquitetura Cliente-Servidor
Arquitetura Cliente-Servidor
 
Poster08
Poster08Poster08
Poster08
 
Comparação entre p2 p e cs
Comparação entre p2 p e csComparação entre p2 p e cs
Comparação entre p2 p e cs
 
Comparação entre p2 p e cs
Comparação entre p2 p e csComparação entre p2 p e cs
Comparação entre p2 p e cs
 
Comparação entre p2 p e cs
Comparação entre p2 p e csComparação entre p2 p e cs
Comparação entre p2 p e cs
 
222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores
 
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptxAula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
 
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
 
Apostila Oracle 10g
Apostila Oracle 10gApostila Oracle 10g
Apostila Oracle 10g
 
Arquitetura cliente servidor
Arquitetura cliente servidorArquitetura cliente servidor
Arquitetura cliente servidor
 
Aula2 caracteristicas da_tecnologia_de_banco_de_dados
Aula2 caracteristicas da_tecnologia_de_banco_de_dadosAula2 caracteristicas da_tecnologia_de_banco_de_dados
Aula2 caracteristicas da_tecnologia_de_banco_de_dados
 
Programação Concorrente - Objetos e Concorrência
Programação Concorrente - Objetos e ConcorrênciaProgramação Concorrente - Objetos e Concorrência
Programação Concorrente - Objetos e Concorrência
 
SI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoSI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de Código
 

Cflp t017

  • 1. Comparando a arquitetura Classic e Superserver do Firebird Autor: Equipe IBPhoenix Tradução/Adaptação: Paulo Vaz A arquitetura SuperServer Mais recente que a versão Classic, é uma implementação multi-clientes e multi- tarefas. 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
  • 2. 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 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.
  • 3. 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. 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.
  • 4. 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. 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
  • 5. 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. 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 multi- usuá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. Artigo Original: http://www.ibphoenix.com/main.nfs?a=ibphoenixA pp&l=;IBPHOENIXAPP.PAGES;NAME='ibp_ss_v s_classic' Equipe da IBPhoenix www.ibphoenix.com Tradução e adaptação: Comunidade Firebird de Língua Portuguesa Visite a Comunidade em: Paulo Vaz paulo@multi-informatica.com.br http://www.comunidade-firebird.org A Comunidade Firebird de Língua Portuguesa foi autorizada pelo Autor do Original para elaborar esta tradução.