IV Congresso Brasileiro de Computação CBComp 2004 Brasil
Tecnologia de Grid Computing utilizando Banco de Dados Oracle
C. H. P. de Oliveira
FIAP - Faculdade de Informática e Administração Paulista, Brasil,
cpoderoso@fiap.com.br
RESUMO
C. H. P. de Oliveira. 2004. Tecnologia de Grid Computing utilizando Banco de Dados Oracle. Congresso Brasileiro de Ciência da Computação, Itajaí, 2004, 903 – 912. Itajaí, SC – Brasil, ISSN 1677-2822
A velocidade com que a tecnologia avança muitas vezes assusta mesmo os mais entusiastas profissionais de informática. Mesmo com equipamentos cada vez mais potentes, sempre estamos precisando de mais velocidade e agilidade para nossas aplicações. Compra-se cada vez mais equipamentos e cada vez mais rápido eles deixam de atender nossas necessidades. Os negócios (e naturalmente a necessidade de informações) adquirem uma dinâmica jamais imaginada e nós, profissionais de TI, temos que responder a estas requisições. Por outro lado, as empresas adotaram modelos compartilhados, fugindo do padrão centralizado exatamente para melhorar e dinamizar o fluxo da informação na empresa. Porém, como melhorar a qualidade da informação disponibilizada em um ambiente tão heterogênio e complexo? Como garantir o controle das operações se os recursos estão esparsos pela empresa? A estas questões a tecnologia de Grid procura achar respostas.
A Oracle, líder mundial em vendas de bancos de dados relacionais e uma das maiores empresas de informática do mundo, procura com a versão Oracle Database 10g busca prover recursos para que empresas de qualquer porte possam ter acesso a esta tecnologia. Neste caso, a grande questão é saber se o produto está maduro e em condições de atender este objetivo.
PALAVRAS DE INDEXAÇÃO ADITIONAIS: centralização, descentralização, compartilhamento, Oracle Database 10g,cliente-servidor, internet, colaboração, infraestrutura, enterprise grids, service grids, autocorreção, autodiagnóstico
GRID COMPUTING
A evolução dos equipamentos de informática tem sido fantástica nos últimos tempos. Passamos de grandes para pequenos computadores sem perder a qualidade e velocidade de processamento. As empresas descentralizaram seus departamentos de informática, fazendo com que o usuário seja o responsável pela sua própria informação.
Com isso a tecnologia deixou de ser uma "ilha" para fazer parte do dia-a-dia das pessoas. As pessoas passaram a exigir mais dos sistemas. O usuário comum passou a conhecer ferramentas e técnicas que antes apenas profissionais conheciam.
Esta mudança no perfil do usuário o deixou muito mais exigente do que antes. Informações importantes começaram a transitar pelos departamentos das empresas com mais rapidez, porém com menos segurança. Os sistemas cliente-servidor mostraram-se eficazes, porém com alto custo de manutenção devido a configuração de equipamentos, atualização de sistemas operacionais, treinamento de usuários, entre outros.
Com o surgimento da internet, os sistemas começaram a retornar aos grandes servidores e estão disponibilizados mundialmente com uma velocidade aceitável. A visão de um sistema em três ou mais camadas parecia atender plenamente todos os requisitos da informação nas empresas, em especial as de grande porte.
Hoje em dia, diversos computadores, muitos com alta capacidade de armazenamento e processamento, são mal utilizados. Em boa parte do tempo eles permanecem ociosos. Seria possível extrair destes equipamentos o máximo de desempenho sem prejudicar suas atividades normais? Fazendo isso, seria
possível atender melhor as necessidades de informação dos usuários?
Estas questões podem parecer muito recentes e para muitos bem pouco importantes, mas o conceito de grid computing, que pode ser entendido como uma computação por demanda, é relativamente antigo. Consta que em 1965, no MIT, foi idealizada uma infraestrutura computacional que seria como uma companhia elétrica, telefônica ou de abastecimento. É exatamente esta a forma que se espera que seja a informática daqui a algum tempo:
os altos investimentos em infra-estrutura e servidores ficariam por conta de algumas empresas que forneceriam e cobrariam pelo serviço prestado. O usuário simplesmente requisita o serviço quando necessita dele. Claro que isso será uma evolução e não uma revolução. Ninguém em sã consciência seria capaz de permitir compartilhar seus recursos ou utilizar recursos alheios sem ter a certeza de que a informação será preservada e mantida em completo sigilo.
Diariamente nas empresas nos deparamos com situações em que estamos utilizando pouco ou muito de um determinado equipamento, seja ele o computador local de um usuário ou o servidor da empresa. O grande problema é que hoje em dia o parque de servidores (e computadores de um modo geral) nas empresas são dimensionados para o pico de utilização. Desta forma, ainda que precisemos de um servidor trabalhando a plena capacidade apenas algumas horas ou dias por mês, temos que tê-lo durante todo o mês sendo subutilizado na maior parte do tempo.
Isso faz com que a subutilização seja um fato aceito na maior parte das empresas.
Imagine aqueles períodos do mês em que há maior necessidade de informação e processamento na sua empresa. Seja pelo
Tecnologia de Grid Computing utilizando Banco de Dados Oracle
fechamento contábil, folha de pagamento ou programação de produção, sempre há um momento na organização em que é necessário utilizar e priorizar os recursos para determinada tarefa.
Agora imagine que, neste exato momento, seu servidor está ocupado com as rotinas usuais da empresa. Você tem que compartilhar a sua necessidade extrema com procedimentos que poderiam ser adiados, sem prejuízo para companhia. Pior que isso:
sua empresa possui diversos computadores espalhados em rede e a maior parte deles sequer percebe que você está precisando urgentemente daquela informação que é extremamente importante naquele momento. Você tem recursos, só que eles não podem ser utilizados de maneira inteligente quando uma situação especial está acontecendo.
Conforme cresce a necessidade de informação e processamento da empresa, o custo de aumentar a capacidade de processamento e armazenamento torna-se muito grande. Mesmo tomando cuidado para não aumentar desnecessariamente o parque operacional da empresa, é natural que em determinados momentos haja falta de recursos e isso acabe por gerar atrasos na entrega da informação necessária. Mais cedo ou mais tarde as empresas acabam por render-se à necessidade de atualização dos servidores, aumentando ainda mais os recursos ociosos da organização.
No conceito de computação por demanda, ou grid computing, a idéia é que os recursos sejam dinamicamente realocados para atender as necessidades do sistema na hora em que eles realmente precisam. Em outras palavras, seria possível compartilhar seus recursos e necessidades através dos diversos equipamentos da empresa. Parece um mundo perfeito para informática, mas não é nenhuma novidade para outras áreas do conhecimento. Afinal, quando precisamos utilizar a energia elétrica não nos importamos como nem quem está nos fornecendo. Apenas acionamos o interruptor e a luz estará disponível. O mesmo se dá com água, telefone, etc.
Mais do que isso, estendendo este conceito para diversas empresas ou mesmo empresas globais, podemos utilizar recursos ociosos em diferentes países em horários de pouca ou nenhuma utilização. É o caso de uma empresa que tenha escritórios em diferentes países, Brasil e China, por exemplo. Os computadores brasileiros poderão ser utilizados para processamento durante a noite, exatamente quando na China é dia. Resultado: menos necessidade de investimento em hardware e melhor utilização dos recursos. Imaginando grandes fornecedores de infraestrutura de hardware e software, pode-se concluir que os investimentos nestas grandes ilhas de processamento poderiam ser melhores aproveitadas.
O que é Grid Computing?
Inicialmente foi um termo utilizado para indicar uma infraestrutura de computação distribuída visando auxiliar cientistas e engenheiros na solução de problemas mais complexos.
Ampliando este conceito, podemos entender grid computing como sendo um grupo de usuários compartilhando diversos recursos utilizando redes de altíssima velocidade. Esta rede seria capaz de atender a demanda pelas requisições e os recursos deveriam estar sob o controle de algo que pudesse, dinamicamente, distribuir o serviço de maneira a equilibrar esta equação. Contudo este centralizador de operações não poderia ser um controlador central único. Conceitualmente deve haver diversos centralizadores de operações no grid para que todo o grid não venha a falhar quando um centralizador de operações falhar.
Esta malha que se forma é que garante a segurança de todo sistema. Seria como se uma distribuidora de energia elétrica
pudesse confiar em uma única usina para fornecer energia. Caso aquela usina falhasse, todo o sistema estaria comprometido.
Ao criar diversas fontes de processamento com um gerenciamento adequado de replicação e tolerância a falhas, caso uma das fontes tenha qualquer problema, outra automaticamente assume a posição e o processamento continua com pouquíssima repercussão na rede.
Do ponto de vista dos usuários, o acesso aos dados e aos recursos em geral deve ser realizado sem que alguém seja notificado e nem mesmo o usuário que requisitou deve saber (ou se preocupar) onde está ou quem processa a informação. Na realidade, o usuário apenas solicita um processamento. Quem, onde, quando são respostas que o grid resolve sozinho, sem interferência e mesmo sem prestar contas ao usuário final. Mais uma vez comparando com a distribuidora de energia elétrica, não nos importa de qual usina veio a eletricidade que estamos utilizando. Importa-nos utilizar a energia e que ela esteja disponível quando precisamos dela.
Do ponto de vista da informática, para atingirmos este patamar é necessário a utilização de padrões abertos para implantação de grids. Como imaginar um grupo de usuários tendo que utilizar sistemas específicos para se beneficiar do grid? Claro que para tirarmos vantagens de algumas tecnologias podemos ter algumas diretrizes que são melhores aproveitadas em determinado sistema operacional, por exemplo. Determinados tipos de redes podem atender melhor algumas solicitações. Porém, a maior vantagem é exatamente poder utilizar qualquer recurso em qualquer tempo e através de qualquer meio. Isso só é possível quando pensamos em uma indústria que seja capaz de adotar e seguir padrões, pois muitos servidores do meu grid podem não utilizar meu sistema operacional, banco de dados ou mecanismo de storage.
A forma de unir coisas tão heterogêneas é exatamente o padrão que a indústria venha a seguir. A não adoção de padrões, no mínimo para determinados segmentos, seria o mesmo que permitir às pessoas que utilizam os serviços de telefonia a utilização de apenas um tipo de telefone. Algo que além de representar o perigo de um oligopólio, poderia inviabilizar determinados recursos.
Um grid deve ser capaz de gerir diferentes tipos de requisições e direcionar a solução para a melhor alternativa de recursos disponível.
Vantagens do Grid
Montar uma rede com porte para atender a estas diversas demandas só foi possível no final da década de 90. Projetos de comunidades científicas e voltadas à engenharia têm sido desenvolvidos desde então.
Comunidades específicas, como universidades e laboratórios de pesquisa têm maior chance de notarem, em um primeiro momento, as vantagens de um grid. As bases de dados dessas comunidades acabam por serem utilizadas em conjunto, gerando e recebendo informações com maior agilidade.
As empresas podem reduzir custos de TI, pois manterão a mesma infraestrutura de hardware com a máxima utilização. Com isso a qualidade e velocidade da informação disponibilizada são muito maiores.
A utilização de equipamentos desktop para realizar operações em conjunto com os servidores, dividindo o processamento centralizado, fará com que os recursos da empresa sejam racionalizados.
Uma outra grande vantagem é a possibilidade de prevenir-se de desastres, uma vez que o grid deve manter mais de um centro de processamento e armazenamento.
Oliveira
Naturalmente nem todas as aplicações podem se beneficiar desta tecnologia. As que tiram maior proveito são aquelas em que o processamento pode ser realizado em paralelo. Queries de banco de dados são exemplos típicos deste tipo de operação. Os bancos de dados comerciais já prevêm a possibilidade de paralelizar as consultas. Em um grid, isso seria feito em diversos servidores simultaneamente.
Com o avanço da internet e as novas tecnologias de telecomunicação isto está se tornando cada vez mais próximo de ser utilizado em larga escala. Desta forma, pouco importa qual equipamento resolveu sua requisição. O que realmente importa é que a sua requisição foi atendida no menor prazo possível e utilizando todos os recursos do grid.
Este conceito é exatamente o mesmo que utilizamos com a telefonia, por exemplo. Sempre que precisamos utilizar o telefone basta que o utilizemos. Assim também deverá ser, um dia, com as nossas informações e procedimentos. Do ponto de vista do usuário, tudo seria realizado desta forma: simples, pois elimina a complexidade de se ter que administrar pesados recursos de informática e rápido, pois sua requisição será processada em diversos equipamentos dentro do grid.
Fases de Implantação
Conforme descrito anteriormente, a implantação de grids se dará em fases distintas, não necessariamente seguindo uma ordem determinada. Podemos classificá-las em três:
a.) Implantação local: grids locais podem atingir empresas de qualquer porte e otimizar a utilização de recursos ociosos. Distribuir o processamento entre os computadores da empresa, armazenar informações e banco de dados serão os primeiros passos. As redes locais são suficientemente rápidas para se conseguir as vantagens do grid. Nesta fase podemos imaginar empresas com sedes em diferentes países utilizando recursos espalhados pelo mundo. Naturalmente os investimentos em infraestrutura de rede serão necessários para garantir a agilidade do processamento e distribuição. Neste grid não temos necessariamente problemas de padronização de sistemas operacionais, bancos de dados ou storage. O controle aqui pode ser centralizado. Em termos de segurança, as informações devem estar protegidas por mecanismos adequados de rede (como firewalls). Este tipo de grid é conhecido como Enterprise Grid.
b.) Implantação regional: grids regionais serão aqueles onde será possível compartilhar informação de interesse de um grupo de pessoas, empresas, universidades. Pessoas com interesses comuns poderão se beneficiar da troca de experiências e compartilhamento de recursos de computação. Aqui os padrões farão a diferença. Não se pode limitar uma comunidade a utilização de determinados sistemas. Aqui será necessário que as entidades possam utilizar diferentes sistemas operacionais, controle de rede, banco de dados e armazenamento. O controle não pode ser centralizado. Em termos de segurança, será necessário manter mecanismos de acesso restrito entre os membros da rede. Devido a complexidade e importância das informações, este é um capítulo a ser tratado com muito cuidado. Por definição os dados estarão disponíveis remotamente e o acesso deve ser controlado para evitar ataques externos.
c.) Implantação global: este é o objetivo final, onde o grid será visto como um serviço disponibilizado por empresas especializadas. Mais uma vez, o padrão aberto e o controle descentralizado das operações serão fundamentais. O mecanismo de proteção deve atender aos requisitos mínimos de segurança e acesso às informações. Os grids devem ser interligados e serão geridos por grandes empresas de informática. Esta fase é conhecida como Service Grid.
Cluster x Grid
Os sistemas baseados em cluster atendem, em parte, a este conceito. Devido à semelhança de um de outro, é necessário diferenciar um cluster de um grid.
Quando existe um compartilhamento de recursos gerenciado por um único sistema, temos um cluster. O grid, por definição, não deve ter um controle único centralizado.
Como é possível notar, na fase de implantação local, um grid poderá ser confundido com um cluster. Mas nas fases seguintes, isso não haverá margens às dúvidas.
Equipamentos, sistemas operacionais e bancos de dados já utilizam clusters para agilizar o desempenho das aplicações, tolerância às falhas e armazenamento de dados.
Recentemente a IBM anunciou esforços para realizar em setores específicos (petróleo, indústria química e educação entre outros) uma super rede de computadores visando diminuir a necessidade de novas aquisições de equipamentos. Utilizando PCs e sistemas em clusters aliados a aplicativos específicos será possível compartilhar estes recursos. Naturalmente nada seria realizado sem o auxílio de outros fornecedores, como os de rede, por exemplo. Atualmente, toda linha de produtos da IBM tem funcionalidades para implementação de grid, com especial atenção para banco de dados DB2 e o sistema operacional Linux.
A Sun coloca em seu Sistema Operacional diversos mecanismos para utilização de grids. O Linux também possui recursos semelhantes. Diversos fornecedores de storage estão implementando soluções baseadas no conceito de grid, mas elas estão restritas aos meios de armazenamento.
A Oracle está lançando o Oracle Database 10g como uma solução para montar um grid envolvendo meios de armazenamento, bancos de dados, servidores de aplicação e aplicações.
O marketing do grid é muito mais interessante hoje em dia do que o cluster. Por este motivo diferenciar neste momento o que é grid do que ainda é cluster não é trabalho fácil. Ainda temos que nos manter no nível conceitual para diferenciá-los.
Para facilitar a análise, é possível citar alguns termos que permite diferenciar grid de cluster. Um grid pressupõe:
a.) Heterogeneidade: o ambiente em que está o grid deve ser o mais amplo e heterogêneo possível.
b.) Colaboração: todos os agentes de um grid devem permitir a colaboração entre seus recursos.
c.) Coordenação: cada recurso deve manter uma estrutura independente de coordenação, mas integrados aos demais membros do grid e coodenados por um centralizador de operações. O ideal é que haja um pequeno número de grandes servidores. Desta forma, realocar os recursos dinamicamente é um trabalho mais fácil de se realizar do que manter diversos e pequenos servidores dispersos pela rede.
d.) Compartilhamento de Recursos: os recursos do grid devem ser conhecidos e compartilhados na rede.
Este compartilhamento deve seguir regras e padrões
Tecnologia de Grid Computing utilizando Banco de Dados Oracle
adotados no grid. Os recursos devem ser dinamicamente realocados atendendo às solicitações das aplicações. Isso quer dizer que, em caso de pico de utilização, os recursos devem ser dirigidos para atender as solicitações e, assim que esta necessidade for atendida e o processamento for concluído, estes mesmos recursos devem estar disponíveis para outras requisições.
e.) Organizações Virtuais: são grupos de recursos e/ou pessoas que possuem um objetivo comum e podem se reunir em torno do grid para troca e complemento de informações. Isso faz com que haja uma quebra entre os recursos e suas aplicações.
Ainda que um cluster possa possuir algumas dessas características, somente um grid possuirá todas.
O que é necessário para um Grid?
Está claro que um grid é uma infraestrutura de sistemas que visa garantir melhor uso dos recursos de informática. Com este conceito, as regras que antes mantinham conexões físicas entre os clientes e os diversos servidores, seja de arquivos, banco de dados ou armazenamento, podem ser gerenciadas pelo grid. Com isso é natural que um melhor uso dos recursos seja alcançado.
No entanto, a implementação deste modelo é extremamente complexa para os gestores desta tecnologia. Os principais desafios são:
a.) Desenvolver sistemas que permitam alocação dinâmica de recursos: deve-se garantir que não haverá recursos ociosos caso alguma tarefa esteja aguardando para ser executada.
b.) Provisionamento flexível das informações: é garantir que usuários e aplicações saibam onde e quando podem utilizar determinado recurso.
c.) Alta disponibilidade: significa que a informação e os processos estarão disponíveis sempre que necessário.
d.) Alta confiabilidade: restrições de acesso, segurança na disponibilização dos dados e política para compartilhamento dos recursos.
e.) Capacidade de autocorreção: em função das requisições e dos recursos disponíveis.
f.) Gerenciamento centralizado: deve ser realizado em um único local. Note que o gerenciamento é centralizado, não o grid.
g.) Utilização de padrões abertos: um grid pressupõe a utilização de protocolos de interface de propósito geral, com mecanismos de autenticação, autorização e identificação de recursos.
h.) Qualidade dos serviços: o recurso utilizado pelo grid deve indicar a qualidade do serviço prestado em termos de tempo de resposta, disponibilidade, segurança e troca de informações.
Talvez o maior desafio nesta fase inicial seja a confiabilidade, pois o mundo está invadido pelos hackers e mesmo as empresas fornecedoras de software tendo investido milhares de dólares, sempre há novas invasões e vulnerabilidades são descobertas nos sistemas.
Se analisarmos a implantação comercial de um grid entre empresas de um mesmo segmento ou não, veremos que é natural a desconfiança por parte dos empresários em disponibilizar seu maior partrimônio, a informação, para que terceiros controlem e garantam o processamento. Este processo de terceirizar o processamento e armazenamento de informações em data centers,
contudo, é uma realidade nos dias atuais. Para isso diversas normas são garantidas pelos fornecedores.
Ao ampliar isso para locais que sequer é possível saber onde está o processamento e a informação é natural que o compromisso entre as partes seja muito maior.
Note que, na implantação global, empresas concorrentes poderão compartilhar o mesmo pool na demanda de informática.
Muitos analistas consideram que isso não é problema já que existe uma tendência para que a concorrência não se dê individualmente entre as empresas, mas sim entre cadeias e redes de valor integradas. Aqui se pode notar que a implantação deste modelo não se trata apenas de uma questão tecnológica, mas sim de mercado.
É possível implantar já um Grid?
Neste momento fica claro que um grid será utilizado em um conjunto de computadores, discos e redes e que tudo isso será gerenciado por algum software. Se pensarmos apenas em uma empresa, vamos concluir que podemos, desde que tenhamos o software adequado, obter ganhos ao compartilhar os recursos que já estão disponíveis - computadores, discos rígidos, etc.
Uma boa infraestrutura para um grid, atualmente, poderia ser imaginado em um grupo de servidores clusterizados, cada um com até 4 processadores, com mecanismo de armazenamento compartilhado (storage). Conexões de rede de alta velocidade (gigabit ethernet ou InfiniBand) entre os nós e a mesma tecnologia ou fibra ótica entre os meios de armazenamento.
Esta configuração está disponível em boa parte das médias e grandes empresas. Logo, a implementação dessa tecnologia pode se tornar uma realidade muito próxima. Com o barateamento dos equipamentos e o amadurecimento da tecnologia, inclusive com a entrada de outros fornecedores de software, em breve será possível aumentar o leque de empresas beneficiadas.
A infraestrutura necessária para instalar um grid não representa impedimento para o seu uso. Mesmo em empresas que não possuam redes de altíssima velocidade ou modernos mecanismos de storage é possível obter ganhos simplesmente clusterizando o banco de dados para distribuir o processamento entre os computadores da empresa. Isso pode se dar em empresas de pequeno porte, que tenham alguns poucos computadores em rede local.
A tendência de preço desses produtos deve contemplar a utilização por pequenas empresas. Para atingir este mercado, contudo, é necessário que o grid seja facilmente gerenciável. Do contrário, pequenas empresas não terão como agregar recursos humanos compatíveis com a tecnologia.
Tendências do Grid Computing
As empresas necessitam estar mais ágeis para responder às constantes mudanças no mercado. Não há como ser competitivo sem possuir uma rede de informações segura dentro da empresa.
Desta forma, sistemas ERP foram implantados e sistemas de business intelligence estão sendo desenvolvidos. Porém isso tem feito com que o investimento no parque de computadores da empresa tenha sido aumentado consideravelmente. Por outro lado, cada vez mais computadores são subutilizados na empresa.
Juntemos um grupo de empresas e veremos que há recursos que estão sendo muito mal utilizados.
Alie-se a isso a necessidade de haver na empresa profissionais dedicados à segurança e integridade das informações.
Profissionais que vão desde DBAs até especialistas em rede e
Oliveira
segurança. Conforme cresce a complexidade do ambiente, maior é a responsabilidade que a empresa tem que administrar e maiores os riscos a que está sujeita.
Portanto, se não houver meios de permitir ao grid um autogerenciamento e autocorreção a falhas, não há como imaginar a implantação maciça desta tecnologia.
Inicialmente os primeiros clusters tinham recursos compartilhados na rede e eram disponibilizados através de plataformas heterogêneas. A tendência, contudo, é que haja um padrão da indústria, como há para banco de dados, telecomunicações, etc., onde os recursos estejam compartilhados em "servidores clusterizados", responsáveis pela operação de todos. A questão é saber se este padrão será um padrão de fato ou o padrão de cada fornecedor, como temos visto nos bancos de dados. Exemplo: a Oracle 9i utiliza o LDAP como padrão, mas os usuários de banco de dados não podem se autenticar utilizando outros servidores LDAP. Só podem fazê-lo com o servidor LDAP da Oracle.
BANCO DE DADOS ORACLE DATABASE 10G
A idéia da Oracle ao criar uma infraestrutura de grid está baseada em quatro pilares:
a.) Aplicações
b.) Servidores de Aplicações c.) Servidores de Banco de Dados d.) Armazenamento
Esta arquitetura baseia-se em servidores de custo relativamente baixo, mas constantemente atualizados. Os servidores devem estar interconectados em uma estrutura de cluster. O Oracle Application Server 10g e o Oracle Database 10g foram concebidos para serem executados em clusters e poderem alocar dinamicamente os recursos de acordo com a necessidade do grid.
É possível, dentro desta estrutura, acrescentar novos recursos ao grid sem que seja necessário parar e reiniciar os aplicativos.
Assim, acrescentar novos discos no grid ou novos processadores é um trabalho a ser realizado independente da utilização dos demais recursos de rede. Isso pode ser feito ao contrário. Retirar estes mesmos recursos é um trabalho que não envolve interromper os serviços atuais do grid.
A grande vantagem deste mecanismo é a possibilidade de acrescentar os recursos apenas quando estes forem necessários, ou seja, no pico de utilização. O balanceamento dos recursos é aumentado ou diminuído com base na necessidade de processamento e armazenamento do grid.
A seguir vamos verificar o resumo da tecnologia utilizada pela Oracle para computação baseada em grid.
Banco de Dados
Real Application Cluster: é a base do grid. É um banco de dados clusterizado que é executado em vários computadores e com diversos meios de armazenamento. As ferramentas de manutenção do banco de dados são válidas para todo o grid. Desta forma, rotinas de backup e recovery e monitoramento de desempenho podem ser realizadas em um único local. Novos nós podem ser acrescentados ao grid baseados na carga de trabalho.
Gerenciamento Automático de Armazenamento (ASM): aqui a administração dos meios de armazenamento são realizadas em grupos de discos (unidade lógica) e não mais em arquivos do banco de dados. Para o DBA isso significa que deverá ser administrado apenas um pequeno grupo de discos. Isso faz com que haja benefícios semelhantes ao uso de RAID. A diferença é que no ASM é possível implementar segurança ao nível dos
arquivos e não apenas dos dispositivos de disco além de permitir um melhor balanceamento do I/O entre os dispositivos.
Provisionamento de Informação: dependendo do volume da informação e do nível de requisição dela, o Oracle é capaz de realocá-la em qualquer ponto do grid para agilizar o acesso aos dados. Este recurso permite migrar dados de um banco de dados para outro de maneira transparente, mesmo que os bancos de dados estejam em diferentes sistemas operacionais.
Banco de dados autogerenciável: as estatísticas do banco de dados são extraídas automaticamente e são dinamicamente alteradas, fazendo com que o banco de dados possa ter seu desempenho ajustado sem necessidade de interferência humana.
Quando necessário, o próprio banco de dados informa ao DBA onde foi detectado um problema para que ele possa realizar análises e propor modificações no banco. O objetivo da Oracle não é eliminar o DBA, mas sim otimizar sua tarefa e reduzir o custo de administração do banco de dados. Instâncias isoladas ou com pequeno volume de transações poderão ser gerenciadas sem a presença de um DBA, mas grandes instalações continuarão a ter esta necessidade.
Application Server
Cluster do Servidor de Aplicação: os serviços do servidor de aplicação (HTTP, Web Services, J2EE, etc.) podem ser alocados em diferentes computadores no grid. Diversos mecanismos de gerenciamento dos recursos, políticas de acesso e conexões estão disponíveis no Oracle Application Server 10g. Como a aplicação está em um grid, a disponbilidade é muito maior, visto que eventuais quedas de um computador são automaticamente compensadas em outro.
Gerenciamento de Identidade: administração dos usuários se dá em um único local. Isso é particularmente importante em um ambiente onde há diversos computadores compartilhando recursos e distribuindo informação. Ao criar, excluir e atribuir direitos aos usuários em um único local, vulnerabilidades no sistema ficam reduzidas e o gerenciamento facilitado, pois não será necessário criar um usuário em cada banco de dados e servidor de aplicação.
A Oracle utiliza o Lightweight Directory Access Protocol (LDAP) em conjunto com o Oracle Internet Directory (OID) para criar e gerenciar os privilégios dos usuários.
Enterprise Manager Control
É um ambiente centralizado para realizar as tarefas de gerenciamento administrativo do grid. Este é o ambiente integrador da tecnologia. Não depende de instalação separada e está totalmente disponível para administração e acompanhamento logo após a criação do banco de dados.
As tarefas de gerenciamento são:
a.) Oracle Collaboration Suite 10g b.) Oracle eBusiness Suite 11i c.) Oracle Application Server 10g d.) Oracle Database 10g
e.) Aplicações legadas ou de terceiros
Ao gerenciar toda a estrutura que faz parte do grid, é possível dimensionar e realocar os recursos disponíveis. Completamente baseado em ambiente web, fornece informações de todos os serviços que estão sendo executados e permite modificar dinamicamente os recursos visando a melhoria do desempenho das aplicações.
Tecnologia de Grid Computing utilizando Banco de Dados Oracle
A TECNOLOGIA EMBUTIDA NO ORACLE DATABASE
10G
O Banco de Dados Oracle 10g, componente da solução de infraestrutura de grid da Oracle, colocou o foco de ação nos seguintes itens:
a.) Gerenciamento b.) Disponibilidade c.) Desempenho
d.) Business Intelligence e Data Warehousing e.) Plataforma de Desenvolvimento
Muitas destas funções já existiam nas versões anteriores do banco de dados e agora foram melhoradas para atender as necessidades da computação baseada em grid.
O que será visto daqui para frente, mostra exatamente com o Banco de Dados Oracle utiliza estes recursos para atingir este objetivo.
No Oracle Database 10g, foi criada uma nova tablespace chamda SYSAUX. Esta tablespace é utilizada para armazenar uma série de informações relevantes para o funcionamento do banco de dados. Como o próprio nome sugere, ela é um auxiliar para a tablespace SYS e manterá uma série de informações de schemas específicos para o banco de dados.
Naturalmente o objetivo deste artigo não é explorar todas as novas funcionalidades do Oracle Database 10g e sim as modificações importantes para que ele possa ser utilizado em um grid. Também não será demonstrado como as demais ferramentas da Oracle (Oracle Application Server e Oracle Entreprise Manager) se integram ao Banco de Dados.
Arquitetura de Gerenciamento
Está baseada nos seguintes componentes:
a.) Automatic Workload Repository (AWR):
principal elemento da nova infraestrutura. Permite ao banco de dados realizar a coleta, processamento, manutenção e acesso às estatísticas internas visando resolver problemas de desempenho.
b.) Aconselhamento: utiliza uma infraestrutura específica para identificar gargalos no banco de dados e propor soluções para resolver os problemas. Está baseada no Automatic Database Diganostic Monitor (ADDM).
c.) Administração automática: as tarefas repetitivas que eram realizadas pelo DBA agora podem ser direcionadas para que o próprio banco de dados realize. Desta forma, as estatísticas que antes eram extraídas pelo DBA poderão ser realizadas automaticamente pelo banco de dados. Isso pode parecer igual ao que se fazia em versões anteriores, mas com esta nova versão é possível manter uma estrutura histórica de valores estatísticos dentro do banco de dados e não dependente de outras ferramentas.
d.) Alertas do Servidor: pode-se determinar o nível de situações onde o servidor envie mensagens de alerta ao DBA. Desta forma, dependendo da situação encontrada no servidor, ele mesmo será capaz, de acordo com métricas estabelecidas pelo DBA, de enviar mensagens solicitando uma ação para corrigir o problema.
Esta estrutura se interrelaciona fornecendo e requisitando informações entre elas para que o gerenciamento do banco de dados se dê mais facilmente.
Isso ocorre porque em versões anteriores do banco de dados era necessário utilizar uma boa parcela do tempo do administrador com rotinas repetitivas. Estas rotinas visavam verificar índices de desempenho e estatísticas de acesso ao banco de dados. Como boa parte dos parâmetros do banco de dados agora são dinâmicos, uma tendência que a Oracle já demonstrava na versão 9i, a solução de boa parte desses problemas pode ser realizada automaticamente pelo próprio banco de dados.
Claro que em instalações com mais de uma instância, vários servidores e alta complexidade de transações, a figura do DBA continuará existindo. Apenas as rotinas repetitivas foram automatizadas pelo banco de dados.
Automatic Workload Repository (AWR)
Esta infraestrutura consiste em duas partes principais:
a.) Coleta de estatíticas mantidas em memória que continuam sendo acessadas através das visões de desempenho (V$).
b.) Manutenção destas mesmas estatísticas em snapshots que são periodicamente alimentados pelo banco de dados. Estes dados podem ser acessados através de visões do dicionário de dados.
A grande mudança ocorrida diz respeito a manutenção dos dados históricos para consulta, mesmo em caso de queda/reinicilização do banco de dados. Isso permite que, em determinadas situações, dados históricos possam ser requisitados para efeito de comparação. Note que isso é particularmente útil para determinar o uso histórico do grid.
Sem isso não há como medir o quanto deve ser alocado para determinado recurso (armazenamento ou processador, por exemplo) quando uma determinada aplicação for requisitada.
Com dados históricos armazenados isso se torna possível.
A principal função do AWR é permitir ao Oracle manter o histórico de utilização para que ele mesmo consiga realizar o autoajuste de seus parâmetros. Desta forma, problemas de desempenho podem ser resolvidos com base no que aconteceu (e está armazenado) no servidor. Nem sempre quando analisamos o servidor, o problema está acontecendo e, por isso, nem sempre tomamos a melhor decisão. Ao manter o dado histórico, o próprio servidor realizará o ajuste necessário.
Estas estatísticas são coletadas a cada 30 minutos, padrão que pode ser modificado pelo DBA através do parâmetro INTERVAL, e são muito semelhantes ao nível 5 do STATSPACK.
As principais estatísticas coletadas pelo AWR são:
a.) Time-model (V$SYS_TIME_MODEL): indica quanto tempo as atividades demoraram. Avalia: conexão, parse, execução de comandos SQL, execução de PL/SQL e compilação de PL/SQL.
b.) Sistema Operacional (V$OSSTAT): consumo de CPU e memória.
c.) Wait Classes (V$EVENT_NAME): aplicação, concorrência, gravação, I/O, administração, confuguração, rede, cluster, jobs, etc.
d.) SQL: comandos e variáveis bind baseados no consumo de CPU, tempo e parse.
O schema WR armazena as informações estatísticas de desempenho do banco de dados. Este usuário utiliza a tablespace SYSAUX para armazenar os dados.
Há três níveis de estatísticas que podem ser ajustadas ao banco de dados: BASIC (onde o AWR estará desligado), TYPICAL (AWR ligado e as estatísticas fundamentais serão coletadas - padrão) e ALL (AWR ligado com todas as
Oliveira
estatísticas habilitadas). O parâmetro que modifica a forma de coleta de estatística é STATISTICS_LEVEL.
O processo do servidor que controla o AWR é o MMON e as métricas relacionadas às estatísticas são mantidas em memória por uma hora aproximadamente.
Como as estatísticas da sessão são gravadas a cada 30 minutos, existe um mecanismo chamado Active Session History (ASH) que mantém as atividades mais recentes da sessão. A cada segundo o ASH verifica a V$SESSION e grava os eventos que estão sendo aguardados. As informações mais antigas serão sobrepostas pelas mais novas, quando não forem gravadas. Este processo se dá em memória, o que permite ser realizado com relativa rapidez. A visão V$ACTIVE_SESSION_HISTORY mantém as informações históricas da sessão.
As visões que permitem identificar estas métricas são:
V$SYSMETRIC e V$SYSMETRIC_HISTORY.
AWR Snapshots Baselines
Entende-se por baseline o mecanismo que extrai dados relevantes periodicamente. Um baseline é composto por um par de snapshots. Para criar um baseline executa-se o procedimento
CREATE_BASELINE do pacote DBMS_WORKLOAD_REPOSITORY, especificando os dois
snapshots que fazem parte dele. Entende-se que devemos criar os baselines sempre que precisarmos medir o desempenho do banco de dados em dois momentos distintos, um no passado e outro mais atual.
Freqüentemente os snapshots antigos precisam ser apagados para ceder lugar a outras estatísticas. Isso se deve ao motivo dos dados serem armazenados na tablespace SYSAUX. É possível modificar o padrão através do MODIFY_SNAPSHOT_SETTINGS do mesmo pacote citado anteriormente. Snapshots que façam parte de baselines não serão apagados até que o baseline seja removido.
Alertas do Servidor
Vimos que o banco de dados gera dois tipos de alertas do servidor. O processo que controla estes alertas é o MMON.
Baseado em métricas do desempenho do banco de dados, o MMON consultará o dicionário de dados para verificar se alguma solução pode ser dada diretamente por ele. Em qualquer situação, alertas serão enviados ao DBA, mesmo que ele possa resolver a questão. Os alertas sempre são enviados com sugestão para solução do problema.
Há dois tipos de alertas básicos do banco de dados: atenção e crítico. Eles são baseados em 161 métricas do tipo: leituras físicas por segundo, gravações por segundo, tempo de resposta de comandos SQL por segundo e assim sucessivamente. Ao atingir limites de 85% são enviados alertas de atenção. Se este limite atingir 97% será enviado um alerta crítico.
A seqüência para utilização desse tipo de alerta é:
a.) Habilitar alertas
b.) Configurar regras de notificação c.) Receber a notificação
d.) Rever detalhes de alertas e indicações para solução e.) Corrigir o problema
f.) Verificar se o problema foi resolvido
Dois procedimentos PL/SQL permitem controlar os alertas do servidor: SET_THRESHOLD e GET_THRESHOLD. Ambos estão no pacote DBMS_SERVER_ALERT.
Tarefas
Através do Scheduler é possível delegar ao Oracle Database 10g que algumas tarefas repetitivas sejam realizadas diretamente pelo servidor, como manutenções baseadas em procedimentos e coleta de estatísticas.
O pacote DBMS_SCHEDULER veio acrescentar algumas funções ao DBMS_JOB. Como ele é possível controlar onde, quando e qual tarefa deve ser realizada.
Quando o banco de dados é criado, o GATHER_STATS_JOB também será criado. Ele executa o DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC
que utiliza o scheduler para realizar a coleta de dados estatísticos do banco de dados. Através da união destes dois mecanismos é possível definir dois padrões de coleta, um para o período do dia e outro da noite, por exemplo.
Através do DBMS_SCHEDULER, é possível utilizar um plano de utilização de recursos diferenciado para esta atividade, não comprometendo a utilização do banco de dados durante o período de coleta.
Aconselhamento
São componentes que fornecem informações a respeito da utilização de recursos e desempenho do banco de dados.
A base deste recurso é o Automatic Database Diagnostic Monitor (ADDM). Com ele é possível identificar problemas e deterctar as possíveis causas, recebendo recomendações de como solucionar o problema. Baseado nas estatísticas coletadas e nos alertas enviados pelo servidor, é possível estabelecer um mecanismo automatizado de controle do desempenho do banco de dados (autoajuste).
Há diversos mecanismos de controle para esta função:
a.) SQL Tuning: indicações de desempenho baseado no histórico de comandos SQL. Gera recomendações de novos índices e visões materializadas visando reduzir o I/O do sistema.
b.) SQL Access: baseado em informações do schema determina a melhor forma de acesso aos dados.
c.) PGA: fornece estatísticas da área de trabalho e fornece recomendações sobre a utilização da memória da PGA.
Recurso existente na versão 9i.
d.) SGA: fornece recomendações com base na utilização e distribuição da memória do sistema. Pode realizar a alteração automaticamente dependendo da configuração do sistema.
e.) Buffer cache: automaticamente verifica como está o desempenho do buffer do sistema.
f.) Library cache: gerencia o cache para as bibliotecas do sistema.
g.) Segment: verifica questões de espaço e crescimento dos objetos.
h.) Undo: sugere mudança de parâmetro para otimizar a utilização dos recursos de flashback (será visto posteriormente).
Para se criar uma sessão de ajuste que invoca o ADDM através do PL/SQL, deve-se (todos baseados no pacote DBMS_ADVISOR):
a.) Criar uma tarefa de aconselhamento (CREATE_TASK) b.) Ajustar os parâmetros (SET_TASK_PARAMETER) c.) Realizar a análise (EXECUTE_TASK)
d.) Verificar o resultado (CREATE_TASK_REPORT)
Tecnologia de Grid Computing utilizando Banco de Dados Oracle
Ao utilizar o ADDM em conjunto com o Oracle Enterprise Manager, pode-se gerenciar o desempenho de diversas fontes de dados e verificar ou propor soluções para diversos servidores.
Sempre que uma instância apresentar problemas de desempenho o ADDM será executado e o DBA terá condições de verificar o que estava acontecendo no momento em que surgiu o problema.
O ADDM fará uma verificação entre os dois últimos snapshots disponíveis, possibilitando detectar o que causou o problema. A estrutura do ADDM permite concentrar-se apenas nos principais problemas, aqueles que efetivamente causaram algum impacto no banco de dados.
Internamente o ADDM trabalha com uma estrutura de árvore de problema, onde cada ramo (problema) leva a um galho (causa) e este ao tronco e à raiz, se for o caso.
Para reconfigurar automaticamente o sistema, o ADDM solicita o Automatic Storage Management (ASM) e o Automatic Memory Management (AMM).
Gerenciamento de Armazenamento
Para compor o grid é necessário que haja mecanismos adequados de armazenamento das informações. Para este fim, o Oracle Database 10g implementou uma série de recursos:
a.) Automatic Storage Management (ASM)
b.) Melhor gerenciamento de tablespaces (temporárias, permanentes, específicas para arquivos grandes, facilidade para transportar entre diferentes plataformas).
Automatic Storage Management (ASM)
É um serviço que permite balancear o trabalho entre discos, previnir a fragmentação dos dados, reorganizar automaticamente o espaço disponível e prover tolerância a falhas (via redundância da informação).
O principal objetivo é manter o banco de dados permanentemente disponível (24 x 7).
A gestão dos dados se dá pelas características de desempenho necessárias por classes de dados e não mais por tipo de arquivo.
Esta estrutura pode conviver com a forma atual de gerenciar arquivos, sem causar problemas na administração. As vantagens, contudo, estão exatamente na retirada da complexidade do operador (DBA) que não precisa mais preocupar-se com extensões, fragmentação e localização física dos arquivos de dados. Esta preocupação ficará a cargo do próprio banco de dados.
Isso inclui o controle de redundância, em especial mecanismos de réplica dos dados, como no RAID.
Ao criar um ASM, o DBA deixa de preocupar-se com o ajuste de I/O e terá simplificada sua tarefa de modificação ou inclusão de novos discos para o banco de dados. Isso leva a uma redução no tempo de indisponibilidade do banco de dados e reduz o custo de manutenção dos mecanismos de armazenamento. Haverá menos objetos para gerenciar, pois o gerenciamento se dá via grupo de discos e não mais arquivos de dados.
O ASM é uma instância do banco de dados responsável pelo gerenciamento dos recursos de armazenamento. O banco de dados acessa o conteúdo dos arquivos do ASM diretamente através do layout desses arquivos. O ASM é uma extensão lógica do Oracle Managed Files (OMF)
Na instância ASM há dois processos do servidor responsáveis pelo balanceamento das atividades entre os dispositivos disponíveis (RBAL) e outro para extensões de dados (ORB0, ORB1, etc.). Na instância que utiliza o ASM há, também, dois novos processos do servidor: RBAL para realizar as chamadas para abrir os discos no ASM e OSMB que realiza a comunicação
com os processos de retaguarda da instância ASM. Sempre que for necessária a execução de uma operação no ASM, os processos de retaguarda do banco de dados conectam-se com a instância ASM para realizar a operação.
Quando se cria um ASM, criam-se grupos de discos. Este grupo é formado por um ou mais discos que são gerenciados como uma unidade lógica de armazenamento. Um banco de dados utilizando ASM não precisa ser reinicializado para que um novo disco seja reconhecido por ele. O trabalho do ASM é exatamente permitir o rebalanceamento das informações através dos recursos disponíveis.
Estes grupos podem ser separados com base em critérios de segurança e redundância de dados. Os arquivos do ASM são criados no grupo de discos do ASM. Eles não são visíveis ao sistema operacional, mas são visíveis para o RMAN e outras ferramentas Oracle. Sempre que for necessário criar um novo arquivo, como tablespaces, log files, redo logs, deve-se especificar apenas o grupo e o ASM se responsabilizará pelo nome e localização do mesmo. Lembre-se que em um grid não importa onde, fisicamente, o arquivo de dados estará e sim que ele esteja disponível assim que solicitado.
Um grupo de discos pode conter mais de uma instância de banco de dados e uma instância pode conter arquivos de dados em diferentes instâncias ASM.
Os grupos de discos podem ser criados para atender algumas características específicas, como:
a.) Diferentes fabricantes, tamanhos e velocidade.
b.) Redundância.
c.) Área de trabalho e/ou recuperação de dados.
Gerenciamento da Instância ASM
Será iniciado exatamente como uma instância de banco de dados a não ser pelo parâmetro INSTANCE_TYPE que terá seu valor como OSM. Naturalmente o que será montado são os grupos de discos e não um banco de dados propriamente dito. O parâmetro que identifica os grupos de discos é OSM_DISKGROUPS.
A conexão ao ASM se dá apenas como SYSDBA e SYSOPER.
Normalmente esta instância necessita apenas de 64Mb de SGA para funcionar.
Há novas visões que permitem gerenciar o ASM. São elas:
a.) v$osm_diskgroup (contém informações do grupo de discos)
b.) v$osm_client (identifica o banco de dados que utiliza o grupo de discos)
c.) v$osm_disk (contém uma linha para cada disco pertencente a instância ASM, mesmo aqueles que não fazem parte de qualquer grupo)
d.) v$osm_file (contém uma linha para cada arquivo em cada grupo de disco)
e.) v$osm_template (contém uma linha para cada template do grupo de disco)
f.) v$osm_alias (contém uma linha para cada apelido em cada grupo de disco)
g.) v$osm_operation (contém uma linha para cada operação longa executada no ASM)
Gerenciamento de Memória
O gerenciamento adequado da memória do servidor permite liberar o DBA de tarefas repetitivas relacionadas ao desempenho do banco de dados. Com isso, em caso de maior necessidade de utilização por força de maior utilização de recursos no grid, não
Oliveira
será necessário aguardar para que o DBA venha modificar a configuração do servidor. O Oracle Database 10g é capaz de realizar este trabalho automaticamente através do Automatic Memory Management (AMM).
Automatic Memory Management (AMM)
Um único parâmetro é responsável pelo gerenciamento automático de memória por parte do banco de dados Oracle. Caso seja informado conteúdo para o parâmetro SGA_TARGET outros parâmetros serão substituídos e a alocação de memória RAM será realizada automaticamente pelo Oracle.
Normalmente um DBA faz alocação de memória para Data Buffers, Shared Pool e Log Buffers. Ao ativar o parâmetro SGA_TARGET, toda divisão de memória ficará a cargo do próprio banco de dados.
Duas visões fornecem as informações necessárias ao banco de dados para realizar modificações que garantam o máximo de desempenho: v$db_cache_advice e v$shared_pool_advice.
Quando se utiliza o AMM, apenas três parâmetros tornam-se responsáveis pelo gerenciamento de memória do banco de dados:
a.) SGA_MAX_SIZE: indica o limite máximo que o SGA_TARGET pode assumir. Normalmente ambos terão o mesmo valor, mas, se de antemão o DBA souber que pode haver picos de utilização, deve-se atribuir um valor superior a este parâmetro. Assim o SGA_TARGET será dinamicamente alterado para atender a demanda.
b.) SGA_TARGET: indica o total de memória que a SGA pode consumir. Inclui outras alocações, como SHARED POOL, JAVA POOL e LARGE POOL.
c.) PGA_AGGREGATE_TARGET: define o total de RAM utilizado para indexações do sistema.
Os demais parâmetros não são mais necessários (mas continuam existindo), a partir da utilização do SGA_TARGET. Caso eles sejam definidos, devem possuir valores muito baixos, permitindo ao AMM modificá-los livremente.
Funcionamento do AMM
Ao utilizar o AMM, o banco de dados terá a possibilidade de aumentar ou diminuir áreas de RAM do Oracle. Esta decisão se dará com base nas estatísticas de demanda de processamento.
Mesmo que a instância seja reiniciada, as informações relativas ao AMM estarão disponíveis quando o banco de dados retornar.
Sempre que houver ganho significativo (ganho marginal) no aumento da memória disponível em relação às leituras e gravações (I/O) de disco, o AMM aumenta o Data Buffer Block. O AMM decidirá quando isso vale a pena, visto que nem sempre há um ganho significativo quando se aumenta a memória RAM disponível para este processo.
Um novo processo do servidor chamado MMAN (memory manager) é responsável por coletar as informações e realizar as alterações necessárias.
Para utilizar o AMM é necessário que o parâmetro STATISTICS_LEVEL esteja em TYPICAL ou ALL, além de estar especificado um valor diferente de zero para SGA_TARGET.
Visões relacionadas ao AMM
As visões a seguir fornecem informações importantes a respeito da SGA e do seu redimensionamento dinâmico.
a.) v$sga: indica os totais de utilização da SGA
b.) v$sgainfo: indica o tamanho da SGA, incluindo seus componentes e memória livre
c.) v$sgastat: informações detalhadas da SGA
d.) v$sga_dynamic_components: totaliza as informações baseadas no redimensionamento desde a última reinicialização
e.) v$sga_dynamic_free_memory: indica a memória disponível para a próxima operação de redimensionamento
f.) v$sga_resize_ops: mostra as informações relacionadas às últimas 100 operações de redimensionamento
g.) v$sga_current_resize_ops: mostra as informações relacionadas a atual operação de redimensionamento.
CONCLUSÃO
Os benefícios do grid computing são reais: sistemas mais flexíveis que podem ser compartilhados em diversos servidores, servidores que podem se autoajustar em função da demanda de processamento, maior disponibilidade para aplicações e uso mais racional dos recursos. Com grids podemos obter melhor desempenho das aplicações, maior escalabilidade e nem por isso teremos custos maiores. Nós, profissionais de TI, poderemos utilizar serviços e equipamentos que, de outra forma, não teríamos acesso devido, principalmente, aos custos envolvidos. As aplicações serão executadas muito mais rapidamente e a um custo sensivelmente menor. Melhor: poderemos contar com os recursos de informática apenas no momento em que dele necessitarmos.
Para as empresas haverá o ganho de utilizar efetivamente todo seu parque de computadores. Isso fará com que os investimentos em TI possam ser melhor aproveitados.
Algumas questões, porém, ainda precisam ser mais bem analisadas: segurança é a principal delas. Velocidade é outra. Há poucos sistemas que realizam o gerenciamento completo do grid.
Isso faz com que tenhamos pouco espaço para comparações. A tecnologia está sendo aplicada há pouco tempo o que fará com que, em futuro próximo, novos padrões possam surgir e efetivamente integrar todos os equipamentos necessários para viabilizar sua aplicação.
Do ponto de vista do banco de dados Oracle, este dá um passo importante para fornecer subsídios para um grid. Permite um autogerenciamento de sua base de dados, possibilita o aumento e diminuição dinâmica de diversos recursos, como processadores e meios de armazenamento. Tudo isso sem aumentar significativamente a complexidade na manutenção da estrutura.
A integração do banco de dados ao Servidor de Aplicação e deste com o gerenciamento único e centralizado completa uma alternativa tecnológica que viabiliza a implantação do grid. Existe a facilidade no gerenciamento no banco de dados o que possibilitará empresas de diversos portes participarem desta nova tecnologia.
REFERÊNCIAS
AULT, M.; LIU, D.; TUMMA, M. Oracle Database New Features. 1ª ed. USA: Rampant, 2003.
ORACLE. Oracle Database 10g New Manageability Features.
1ª ed. USA: Oracle, 2003.
BOMBONATO, F Computação em Grid Uma Introdução.
Disponível em
Tecnologia de Grid Computing utilizando Banco de Dados Oracle
http://www.geleira.org/artigos/?redes+grid_computing. Acessado em fevereiro de 2004.
BAIRD, I Understanding Grid Computing. Dispónível em:
http://www.platform.com/pdfs/whitepapers/understanding_grid.pd f
FOSTER, I What is the Grid? A Three Point Checklist.
Disponível em: http://www- fp.mcs.anl.gov/~foster/Articles/WhatIsTheGrid.pdf
GRIDCOMP Grid Computing Info Centre (GRID Infoware).
Disponível em: http://www.gridcomputing.com/
GRIPHYN Education & Outreach Center. Disponível em:
http://www.phys.utb.edu/griphyn/
LASZEWSKI, G. V. Gregor von Laszewski – Grid Course.
Disponível em: http://www-fp.mcs.anl.gov/~gregor/grid- iit/talks/Introduction%20to%20Grid%20Computing.htm
