Beruflich Dokumente
Kultur Dokumente
RELATÓRIO DE PROJECTO
sobre
realizado na
por
Agraı̈ments
Durant aquests mesos que he estat a l’empresa Trety he tingut el suport d’un equip.
Voldria expressar el meu agraı̈ment a tot el Departament d’Informàtica, especialment al
meu tutor Santi Solà que m’ha recolzat en tot moment i a l’Alberto Cárceles per haver-me
acollit i donat l’oportunitat de dur a terme aquest projecte.
Agradecimentos
Ao Professor João Cunha, a quem eu devo a sua orientação neste trabalho, o seu
cuidado apoio, disponibilidade e sobretudo pela sua paciência.
Ao Professor João Balsa, a quem eu agradeço toda a atenção e simpatia que sempre
encontrei na sua pessoa, assim como pela prontidão a que sempre acedeu, estivesse em
causa uma burocracia ou uma simples dúvida.
Quero agradecer ao Paulo Carvalho pelo seu tempo, ajuda, e principalmente pela
confiança que encontrei na sua amizade.
Ao Nuno Castro, por apesar de ser grande a distância, estar sempre tão perto.
À Cèlia e ao Josep por me fazerem sentir parte da famı́lia.
À minha famı́lia, eu devo o seu amor e suporte emocional, mas tenho a certeza que
encontrarei melhores formas para agradecer-lhes por isso. Uma palavra muito especial a
ti, Anna, a quem eu devo mais do que tempo.
vii
Resumo
Acrónimos
BD Base de dados
CD Compact Disc
OCFS Oracle Cluster File System (OCFS2 refere-se à segunda versão deste sistema de
ficheiros)
ODF Open Document Standard, forma reduzida para OASIS Open Document Format
for Office Applications
SO Sistema Operativo
SP Service Pack
1 Introdução 1
1.1 Integração na empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Estrutura do relatório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Virtualização 4
2.1 Componentes do VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 VMwareTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Criação de Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Resolução de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Sistemas Operativos 9
3.1 Selecção de candidatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Análise de algumas opções . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Sistema de Ficheiros . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Optimizações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Hugepages - Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Desactivar registos de acesso a leitura . . . . . . . . . . . . . . . . . 12
3.3.3 Recompilação do kernel . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Comparação de desempenhos 14
4.1 Sistema de Gestão de Base de Dados (SGBD) . . . . . . . . . . . . . . . . . 14
4.2 Aplicação Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Principais classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Testes de desempenho complementares . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 TPC-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Hammerora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.3 Automatic Workload Repository . . . . . . . . . . . . . . . . . . . . 18
xii CONTEÚDO
6.4.7 Orarun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.5 Scripts Desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6.1 Cluster Verification Utility (CVU) . . . . . . . . . . . . . . . . . . . 51
6.6.2 Verificações de pós-instalação . . . . . . . . . . . . . . . . . . . . . . 52
6.6.3 Adição de um nó numa fase posterior . . . . . . . . . . . . . . . . . 54
6.7 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7 Protótipo 56
7.1 Infra-estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.1.1 Criação da máquina virtual . . . . . . . . . . . . . . . . . . . . . . . 57
7.2 Multiplos Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Instalação SUSE Linux Enterprise Server 9 . . . . . . . . . . . . . . . . . . 59
7.4 Actualizar kernel e OCFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.5 Instalação das VMwareTools . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.6 Configuração de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.7 Acerto dos Relógios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.8 Criar directorias para software Oracle . . . . . . . . . . . . . . . . . . . . . 64
7.9 Instalação do CVU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.10 Configuração do Hangcheck-Timer . . . . . . . . . . . . . . . . . . . . . . . 65
7.11 Disponibilizar Memória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.12 Resolução de nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.13 Orarun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.14 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.15 Máquinas seguintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.16 Equivalência de utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.17 Preparação das partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.18 OCFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.19 Clusterware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.19.1 Verificar a instalação do Clusterware . . . . . . . . . . . . . . . . . . 74
7.20 Automatic Storage Management . . . . . . . . . . . . . . . . . . . . . . . . 75
7.20.1 Instalar o software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.20.2 Configurar o driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.20.3 Criar discos ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.21 Instalação do software Oracle Database 10g . . . . . . . . . . . . . . . . . . 76
7.22 Configuração do Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.23 Criação da base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
xiv CONTEÚDO
8 Outras Tarefas 82
8.1 Servidores Blade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2 Citrix Metaframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.3 Clonagem de servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.4 Open Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.4.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.4.2 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9 Conclusões finais 89
Índice 97
Bibliografia 98
Lista de Figuras
Introdução
A nı́vel de Departamento de Informática, a minha recepção foi levada a cabo por Santi
Solà, Tutor e responsável pela supervisão deste projecto. Foi-me apresentada a equipa
do departamento, disponibilizado um posto de trabalho e dadas as primeiras linhas de
orientação incidentes no projecto a desenvolver.
Foi extremamente útil a interacção existente com a maioria dos colegas, pois daı́ pude
aprender com as suas sugestões e experiência, em diversas áreas. Áreas técnicas, pelo
conhecimento de úteis e poderosas aplicações, no aprofundamento de matérias ao nı́vel
de sistemas, das bases de dados, em Linux e tanto mais; mas também, e não menos
importantes, Humanas. Este ponto teve uma elevada importância para mim, dadas as
caracterı́sticas deste projecto, em que existia um alto grau de autonomia que lhe estava
associado.
1.2 Objectivos
Este trabalho tem como finalidade implementar um sistema de base de dados (SGBD)
Oracle Database 10 g utilizando a solução Real Application Clusters (RAC), que permite
a disposição de uma base de dados em múltiplas máquinas, funcionando em cluster , de
modo a promover as propriedades de disponibilidade e escalabilidade sobre as bases de
dados nele contidas.
Numa primeira fase, pretende-se definir que sistema operativo (SO) utilizar para su-
portar tal implementação. Para isso será feito um estudo de benchmarking que opõe
uma selecção de distribuições Linux ao Windows, com o Windows 2003 Server , o sistema
operativo maioritariamente utilizado nos servidores desta empresa.
Após a escolha do sistema operativo a adoptar, serão descartadas as outras alternati-
vas. Serão analisados os requisitos para o RAC e deverão ser feitas as opções necessárias
ao seu cumprimento, para traçar o conjunto de passos necessários à implementação do
cluster no sistema operativo seleccionado. Isto deverá ser feito em concordância com as
recomendações existentes, adequados à realidade da empresa e aos recursos de que seja
possı́vel dispôr.
Pretende-se que a plataforma criada com este trabalho crie uma base de conhecimento
a partir da qual se possam adoptar as orientações aqui tomadas e considerar esta hipótese
num potencial cenário de migração de um sistema existente, ou como possı́vel solução para
albergar um sistema a adoptar futuramente, que requeira garantias de alta disponibilidade
ou boas condições para uma fácil escalabilidade.
Este relatório regista ao longo dos seus capı́tulos os principais aspectos estudados
no desenvolvimento do Projecto em Engenharia Informática. Neste primeiro capı́tulo de
introdução é feita a apresentação da instituição de acolhimento – Trety, SA (Grupo Trèves)
– e é feita uma abordagem de como se deu, em moldes gerais, a integração na empresa.
São também apresentados os objectivos do projecto, na secção 1.2, e na presente secção é
explicada a organização do relatório.
No capı́tulo 2 explicam-se as caracterı́sticas da solução de virtualização de hardware
da VMware. A plataforma de VMware foi utilizada numa primeira fase para fazer o
estudo de benchmarking sobre o comportamento do SGBD Oracle Database 10 g sobre
1.3 Estrutura do relatório 3
Virtualização
o hardware e contém já a componente de sistema operativo integrada, que tem uma fisio-
nomia Linux, porém com algumas caracterı́sticas distintas.
Com esta arquitectura tenta aligeirar a camada de virtualização, encurtando a distância
entre as necessidades dos guests e os recursos facilitados pelo host.
2.2 VMwareTools
Este é um pactote de aplicações que deverá ser instalado após o processo de instalação
do sistema operativo guest numa máquina virtual, qualquer que seja a versão utilizada.
Quando uma máquina virtual é criada é requerida a indicação do sistema operativo que irá
ser instalado. Mediante o caso, é disponibilizado o pacote VMwareTools adequado ao tipo
de sistema operativo utilizado. No caso particular do Linux, poderá ser necessária a com-
pilação deste pacote, dependendo da compatibilidade do pacote VMwareTools facultado
na versão do VMware presente com a versão especı́fica do kernel instalado.
Entre as funções deste pacote pode destacar-se a utilização de drivers apropriados para
uma melhor performance (driver SVGA, drivers de rede – vmxnet), suporte para partilha
de directorias ou facilidades de copiar/colar entre host e guest, etc.
Para efectuar a sua instalação, deve seleccionar-se a opção “Install VMwareTools” na
consola remota de acesso à máquina virtual em questão. É então montada na drive de
CD-ROM uma imagem com o pacote de instalação, e a partir daı́ efectuar o procedimento
de instalação recomendado (pode verificar-se um exemplo de instalação na secção 7.5,
presente na página 62).
Tabela 2.1: Mostra comparativa das caracterı́sticas básicas das máquinas “guest” e “host”
• Interferência mútua
O VMware faculta a possibilidade de definir um processador especı́fico para cada
máquina virtual. Porém, apesar desta escolha ser configurável, mostrou ter com-
portamentos pouco estanques durante da realização de execuções concorrentes. Isto
devido à partilha dos recursos existentes e consequente concorrência no seu acesso,
com processos de escalonamento que dificilmente facultam uma parcialidade total
perante as diferentes máquinas.
Outras máquinas, alheias ao contexto do teste de desempenho, impõem também
factores externos que tornam difı́cil limitar o subconjunto de factores que influenciam
os resultados obtidos.
2.5 Limitações
Sistemas Operativos
Inicialmente houve uma fase de angariação de opções para sistemas operativos que
fossem considerados válidos para participar no estudo de benchmarking a ser realizado em
oposição ao Windows 2003 Server .
Entre os candidatos podem destacar-se: Centos, Ubuntu, Red Hat Enterprise Linux ,
Suse Linux Enterprise Server e WhiteBox.
A selecção recaı́u sobre o Red Hat Enterprise Linux 4 e o SUSE Linux Enterprise
Server 9 , essencialmente por serem as soluções certificadas pela Oracle e por isso possuı́rem
melhores condições em termos de documentação e de “massa crı́tica”, assim como a sua
adopção fornece melhores garantias de suporte e segurança na continuidade das futuras
actualizações do produto.
3.2.1 Partições
Espaço Swap
Para cada processo que corre num computador é alocado um conjunto de blocos de
memória ou páginas. Se possı́vel, o sistema operativo tenta manter na RAM o conjunto
de páginas que são utilizadas, ou que se prevê que venham a sê-lo. Quando a utilização
de páginas excede a capacidade disponı́vel na memória RAM, o kernel tenta libertar a
memória esgotada, escrevendo páginas no disco. O espaço Swap é utilizado para este fim.
Efectivamente, ele aumenta a quantidade de memória disponı́vel pelo sistema. Porém,
se considerarmos que as operações de acesso a disco são cerca de cem vezes mais lentas
que as de leitura e escrita para RAM, este recurso deve ser considerado como memória de
emergência e não memória extra [46].
Em sistemas Linux é obrigatório definir espaço a ser utilizado para Swap. É um dos
passos a percorrer na instalação do sistema. Geralmente o espaço mı́nimo recomendado
para este efeito depende do tamanho da RAM utilizada, porém os valores apropriados
dependem também da utilização especı́fica que se pretenda dar ao sistema em mente.
Pode também ser definido espaço adicional numa fase posterior. Para isso podem ser
utilizados comandos para efectuar este acréscimo ou reconfiguração. Para definir uma
partição Swap, há que preparar o espaço onde ela será aplicada. Se pretendermos dedicar-
-lhe a partição referida por /dev/sda5 devemos primeiro preparar esta partição e depois
activá-la.
O espaço máximo utilizado por uma partição Swap depende da arquitectura. Para
uma arquitectura Intel i386, este limite é de 2GB. Existe, ainda assim, a possibilidade de
definir múltiplas partições para este efeito. A partir do kernel Linux 2.4, é permitido a
utilização de 32 áreas Swap, o que dá alguma margem de manobra. . .
Para uma utilização com bases de dados Oracle, os valores apontados como ideais
respeitam a tabela 6.1 constante na página 39. Dado que foram utilizados 2GB de memória
RAM em cada máquina virtual, como o valor recomedado para Swap pela Oracle para esta
quantidade de memória RAM é de 3GB, tiveram de ser criadas duas partições dedicadas
à utilização Swap em cada uma das máquinas, de modo a que o tamanho máximo para a
partição Swap não fosse excedido.
De um modo geral um sistema de ficheiros está presente e faz parte como subsistema de
qualquer sistema operativo. Funciona como interface entre os recursos de armazenamento
a que tem acesso e as camadas de nı́veis superiores. Trata de guardar os dados e organizá-
-los de maneira a que seja fácil a sua localização e acesso.
Pode lidar com diferentes tipos de recursos de armazenamento, sejam eles fı́sicos, como
um disco duro ou um CD, o que envolve conhecer a localização fı́sica dos ficheiros, ou
virtuais, e existir apenas como método de acesso em rede (por exemplo NFS), que faculta
um acesso em rede a conteúdos remotos.
Geralmente é através deste sistema que as operações de escrita ou leitura são efectua-
das. Em complemento a estas operações básicas, acumula um conjunto de outras operações
cujas caracterı́sticas e extensão depende de cada solução em particular. Algumas das fun-
cionalidades mais comuns são gerir o espaço livre, optimizar o manuseamento dos dados,
gerir as permissões de acesso aos ficheiros, registar meta-dados sobre a sua utlilização, etc.
3.3 Optimizações 11
O conjunto de serviços que cada sistema de ficheiros disponibiliza, assim como o tipo
de abstração que ele promove, depende de qual o seu propósito. Uma das “mais-valias”
que alguns dos sistemas de ficheiros oferecem é a capacidade de “journaling”.
Journaling é uma funcionalidade exercida através de um sistema de logs, em que du-
rante a execução regular do sistema é guardado um registo das operações efectuadas, e
que permite uma fácil recuperação (através da consulta aos registos efectuados), caso haja
uma interrupção abrupta do sistema, sem que tenha de ser feito um diagnóstico exaustivo
ao sistema de ficheiros.
Tabela 3.1: Análise comparativa de alguns dos principais sistemas de ficheiros dedicados
a discos locais para Linux publicada em [47].
3.3 Optimizações
Foi explorada mais a vertente das optimizações no sistema operativo Linux por ser este
que apresentava inicialmente piores prestações nos testes de desempenho efectuados. No
entanto foram também exploradas algumas opções de modo encontrar uma configuração
optimizada para o sistema operativo Windows, com alguns efeitos práticos evidenciados.
Hugetlbpages é uma facilidade introduzida com o kernel Linux 2.6 que, em vez de usar
páginas de memória de 4kB, valor standard para arquitecturas x86 de 32-bit, faz com que
sejam utilizadas páginas até 4MB. Isto permite poupar um considerável “overhead” quer
em termos de processador, quer de memória, que de outra forma teria de ser empregue
gerindo uma quantidade significativamente maior de páginas de menor tamanho.
Pode ser especificado o tamanho de página a utilizar e por outro lado o número de
páginas que devem ser utilizadas (e reservadas para tal efeito).
Para configurar as Hugepages efectuar o seguinte procedimento:
2. Definir o tamanho de página a ser usado (em kB), introduzindo na linha de comandos:
# echo 4096 > /proc/sys/vm/nr_hugepages
4. Editar (ou criar caso não exista) o ficheiro /etc/sysctl.conf e colocar-lhe a seguinte
linha:
vm.disable_cap_mlock = 1
5. Para fazer com que o ficheiro editado seja levado em conta de cada vez que o sistema
reinicie, executar na linha de comandos: chkconfig boot.sysctl on
Após reiniciar o sistema pode verificar-se a utilização das Hugepages, com o comando
indicado anteriormente. É mostrada a informação do sistema respectiva à sua utilização.
HugePages_Total: 1024
HugePages_Free 940
Hugepagesize: 2048kB
# mount -o noatime,nodiratime
Comparação de desempenhos
Para fazer este estudo foi desenvolvida e utilizada uma aplicação em Java – Bench.
Foram também analisados alguns produtos especializados em testes de benchmarking a
bases de dados, como o Benchmark Factory 1 (um produto da Quest Software), e as soluções
de utilização livre SwingBench 2 e Hammerora 3 . Este último foi adoptado para dar suporte
ao estudo a ser realizado.
Numa primeira fase foi instalada a versão 10.1.0.2 e posteriormente foi utilizada a
versão mais actualizada, a 10.2.0.1. Esta versão foi utilizada para executar os testes
de desempenho e posteriormente também para criar o ambiente em cluster com os Real
Application Clusters.
Nas várias instalações foi utilizada uma configuração semelhante e tentou-se manter o
mesmo conjunto de serviços activos. Por exemplo o Enterprise Manager, uma plataforma
de gestão da Oracle, que nos sistemas operativos Linux não é colocada em actividade
após a instalação, foi lançada e através dela comparadas algumas parametrizações entre
os ambientes (utilização de memória, áreas System Global Area (SGA) e Process Global
Area (PGA), reservadas para utilização das instâncias Oracle, etc.).
1
http://www.quest.com/benchmark_factory
2
http://www.dominicgiles.com/swingbench.php
3
http://hammerora.sourceforge.net
4.2 Aplicação Bench 15
Esta é uma aplicação em Java, criada para gerar um conjunto de pedidos a submeter
à base de dados, efectuando-lhe um teste de carga transaccional. Foi criada de forma
modular, de forma a permitir a escalabilidade da aplicação, e foram sendo acrescentadas
funcionalidades no sentido de colmatar as necessidades de cada ambiente especı́fico.
Inicialmente o desenvolvimento desta aplicação não estava planeado. A decisão da
sua utilização surgiu ao identificar o comportamento anormal dos relógios nas máquinas
virtuais (ver secção 2.4).
Foi então produzida esta aplicação de modo a tornear esse problema e dar resposta a
uma primeira necessidade - o registo credı́vel dos resultados. Através da inserção de um
coordenador externo, poder-se-ia isolar a execução do teste pretendido, que compreende
as operações de carga transaccional sobre a base de dados, realizadas localmente onde se
encontra alojada a BD, do controlo de desempenho, realizado numa máquina externa que
de um modo centralizado, a par de gerir quando deverá ser feito o arranque do teste em
cada servidor, trata também de efectuar a medição das durações de cada teste submetido,
eliminando os problemas relativos à sincronização de relógios. Assim, este coordenador
será responsável pelo controlo de execução e registo de desempenho.
Segue um modelo mestre-escravo, ou cap-i-cua4 para utilizar a designação em catalão,
com a classe Cap responsável pelo controlo do fio de execução dos testes e a classe Cua,
alojada em cada uma das máquinas virtuais, que recebe os pedidos para executar o teste
local.
Localmente cada instância Cua é responsável por atender aos pedidos que lhe chegam,
de acordo com um protocolo de comunicação. Prepara a base de dados e despoleta uma
nova ocorrência do teste preparado. Este teste por sua vez compreende um conjunto de
4
capicua, é uma aglutinação de palavras catalãs que significam cabeça(cap) e(i) cauda(cua).
16 Comparação de desempenhos
A aplicação Bench, está distribuı́da por duas componentes, o cliente (Cap) e o servidor
(Cua). O cliente, organizado num pacote de classes que corre numa máquina externa (que
funciona como coordenador), apresenta a interface de controlo com o utilizador, gere a
informação acumulada e estabelece as ligações com as múltiplas componentes servidor e
gere a informação adquirida. Cada componente servidor agrupa num ficheiro jar as classes
necessárias para preparar o teste de desempenho, executá-lo e notificar a sua conclusão ao
módulo cliente através da ligação TCP estabelecida.
Cap Classe que contém o método main do programa cliente da aplicação de desempenho.
Concorrente Classe que contém o método main do programa que é lançado no servidor
onde está alojada a base de dados.
Control Esta classe é responsável pela sincronização dos processos de inı́cio e fim dos
testes nos distintos servidores no funcionamento sı́ncrono ou assı́ncrono. Faz o con-
trolo das operações de teste, com a sinalização para arranque da fase de preparação
do teste e seu consequente lançamento.
Desempenho Tem funções que fazem a chamada a procedimentos pl/sql remotos utili-
zados para carregar a base de dados.
Ligacao Estabelece as ligações entre o cliente e servidor e gere a sua manutenção, assim
como lida com o protocolo de comunicação a usar com a parte servidor.
Periodo Guarda informação sobre os perı́odos de tempo que se referem à duração dos
testes de desempenho.
4.3 Testes de desempenho complementares 17
Sessão Gere a informação respeitante a uma sessão, como o nome, a descrição os seus
conteúdos, a data da sua criação, as contagens, etc.
4.3.1 TPC-C
4.3.2 Hammerora
5
acrónimo para as propriedades Atomicidade, Consistência, Isolamento e Durabilidade
18 Comparação de desempenhos
4.3.5 Orion
O Orion é uma ferramenta que tenta prever a performance de uma base de dados
Oracle sem ter de instalar o software em questão ou criar uma base de dados. Foi criado
expressamente para simular cargas de E/S da BD usando nas operações realizadas uma
abordagem semelhante à efectuada pelas bases de dados Oracle.
Permite efectuar diferentes tipos de cargas de operações sobre os discos, podendo
inclusivamente efectuar simulações do efeito de striping produzido pelo Automatic Storage
Management (ASM), que será visto com algum detalhe na secção 5.2.4 (página 33).
Esta ferramenta foi utilizada para verificar o rendimento das operações de disco nos
sistemas operativos Windows e Linux perante uma instalação na mesma máquina, em
partições distintas.
4.4 Cenários Testados 19
O objectivo deste estudo não se baseou em descobrir qual o melhor sistema operativo,
pois esse tema apesar de muito debatido, dificilmente nos deixa com uma resposta objec-
tiva. Isto porque são muitos os factores de que depende este tipo de conclusões que uns e
outros sempre poderão alegar em defesa da sua escolha de preferência.
O seu foco incide sim em comparar os desempenhos que o sistema de gestão de bases
de dados, o Oracle Database 10 g revela sobre as diferentes soluções de sistema operativo
avaliadas.
Neste ambiente os servidores são máquinas virtuais. As máquinas foram criadas de-
finindo os seus recursos com caracterı́sticas semelhantes (quantidade de memória, disco,
velocidade de processamento) e o factor que as distingue, para além do nome que apresen-
tam perante a interface de gestão do VMware, é o sistema operativo que têm instalado.
Cenário A
Cenário B
Cenário C
Cenário D
Os testes de desempenho foram realizados não só pela aplicação Bench como também
pela aplicação Hammerora.
4.5 Resultados
Cenário A
Cenário B
SLES9
RHEL4
W2003
140
120
100
80
0 5 10 15 20
Figura 4.2: Bench - ambiente virtual - cenário B. Resultados registados pela aplicação
Bench. Os gráficos são respeitantes aos diferentes servidores, cujos sistemas operativos de
cada um são o Red Hat Enterprise Linux 4 (RHEL4), SUSE Linux Enterprise Server 9
(SLES9) e Windows 2003 Server (W2003).
de optimização utilizados é imposta pela camada de virtualização que separa estes sistemas
operativos da camada fı́sica de hardware.
Cenário C
SLES9
160
W2003
150
140
130
0 5 10 15 20
Figura 4.3: Bench - ambiente nativo - cenário C - Resultados relativos aos testes realizados
sobre sistema operativo SUSE Linux Enterprise Server 9 (SLES9) e Windows 2003 Server
(W2003).
Este cenário apresentava um ponto bastante importante por atingir no que toca à
equivalência de recursos entre os dois ambientes avaliados, sobretudo no tipo de teste que
estava a ser submetido às bases de dados, em que o acesso a disco representa um aspecto
extremamente importante, perante o tipo de operações submetidas. Com a utilização
de diferentes segmentos do disco por parte de cada um dos ambientes, era provável a
existência de diferenças na velocidade das operações de disco, o que tem um importante
impacto no desempenho, conforme sugeriram os resultados.
Estas expectativas foram confirmadas com a ajuda do Orion (ver secção 4.3.5, na
página 18). Confirmou-se o melhor rendimento das operações de disco no ambiente Linux,
cujas partiçoes, definidas posteriormente às do Windows, estavam localizadas em sectores
onde se atingem maiores velocidades que em sectores iniciais do disco.
Cenário D
Foram também aplicadas algumas optimizações sobre cada um dos ambientes analisa-
dos. No ambiente Windows as diferentes configurações avaliadas testaram a utilização da
opção PAE, 3GB e foi criada ainda outra configuração que conjugava estas duas opções.
No Linux, as configurações testadas adicionalmente compreenderam a utilização de um
kernel actualizado, a recompilação do kernel e a utilização das Hugepages.
Estas configurações foram testadas tanto pela aplicação Bench como pela Hammerora.
Resultados Bench
120
tempo (s)
115
110
0 5 10 15 20
Figura 4.4: Visão comparativa dos resultados da execução da aplicação Bench sobre os
sistemas operativos Windows 2003 Server (W2003) e SUSE Linux Enterprise Server 9
(SLES9), na sua configuração inicial.
Resultados Hammerora
Ao realizar o benchmark Hammerora sobre os vários cenários testados, dado que esta
ferramenta se encarrega de realizar o teste mas não de avaliar os desempenhos, foi ne-
cessário procurar um meio de realizar essa medição, através de um mecanismo externo à
aplicação. Para esse efeito, foi utilizada a funcionalidade disponibilizada pela Oracle, o
AWR (ver secção 4.3.3, na página 18).
Os dados recolhidos estão resumidos na tabela 4.2
Os dados observados mostram prestações significativamente melhores sobre a base de
dados alojada em sistema operativo Linux.
24 Comparação de desempenhos
130
config.inicial
pae
125 3gb
pae+3gb
120
110
105
100
0 5 10 15 20
130
config. inicial
k. actualizado
125 k. monolitico
hugepages
120
115
tempo (s)
110
105
100
95
0 5 10 15 20
Figura 4.5: Resultados da execução da aplicação Bench sobre os sistemas operativos Win-
dows 2003 Server (W2003), em cima, e SUSE Linux Enterprise Server 9 (SLES9), em
baixo, com as diferentes configurações avaliadas.
Configuração t̄ (s)
Windows
Inicial 115,85
PAE 115,75
3GB 110,85
PAE + 3GB 100,85
Linux
Inicial 120,05
kernel actualizado 118,6
kernel Monolı́tico 103,7
Hugepages utilizadas 100,45
Tabela 4.2: Resultados da execução do benchmark TPC-C sobre Windows e Linux através
do Hammerora. Os valores apresentados referem-se a transacções por segundo. São apre-
sentados os resultados das várias configurações avaliadas.
4.6 Conclusões
Como a aplicação Bench apresenta uma carga mais pesada a nı́vel de acesso a disco,
pode considerar-se que o subsistema de sistema de ficheiros no Linux seja menos eficiente
perante o tipo de operações predominante nesta aplicação. No entanto, com vista à ins-
talação do Oracle Database 10 g Real Application Clusters, e ao funcionamento de bases
de dados, esse facto teria pouca importância. As operações E/S nesse tipo de plataforma
são essencialmente realizadas sobre os ficheiros de dados e estes ficheiros encontram-se fora
do âmbito do sistema de ficheiros locais. Encontram-se num espaço de armazenamento
partilhado, mantido geralmente em equipamentos dedicados.
Com o estudo realizado, e analisados os resultados obtidos, decidiu-se adoptar o Linux,
nomeadamente a distribuição SUSE Linux Enterprise Server 9 , como sistema operativo
a instalar nos nós necessários à implementação da plataforma que sustentará o Oracle
Database 10 g, com a extensão Real Application Clusters. Sobre esta plataforma será
criada uma base de dados a funcionar em cluster . Neste ponto descartam-se os restantes
sistemas operativos avaliados.
Capı́tulo 5
cumprir este requisito podem ser tomadas diferentes opções, perante as diferentes soluções
tecnológicas disponı́veis. As principais são apresentadas mais adiante neste capı́tulo, na
secção 5.2.
Podemos considerar que estamos perante um “cluster ” quando temos múltiplos compu-
tadores ou servidores que aparentam ser apenas um servidor, perante os utilizadores finais
ou aplicações [48]. Vamos ainda considerar que falamos de duas ou mais máquinas com
partilha de disco rı́gido, que correm sobre o mesmo sistema operativo e estão interligados
através de uma rede comum.
O Oracle Clusterware, formalmente designado por Cluster Ready Services (CRS), é
uma solução integrada de gestão a nı́vel de cluster que permite ligar diversos servidores,
de modo que funcionam como um único sistema. Ajuda a agrupar um conjunto de trabalho
aplicacional que está sobre seu controlo [49].
É facultado por esta solução um conjunto de serviços de gestão do sistema e tem a
capacidade de exercer uma interacção com outros produtos de clusterware especializados,
caso sejam utilizados, de modo a coordenar informação a respeito dos membros do cluster.
O Oracle Cluster Registry (OCR) contém informação sobre a base de dados e sobre o
cluster , para os Cluster Ready Services a operar com Real Application Clusters (RAC).
Este ficheiro guarda a lista de nós na base de dados “clusterizada”, a aplicação CRS, perfis
de recursos utilizados e as autorizações para o Event Manager.
O OCR tem de ser alojado num espaço de armazenamento partilhado. Pode residir
num ficheiro contido num Cluster File System (sistema de ficheiros com funcionalidades
dedicadas ao ambiente em cluster ) ou num dispositivo Raw . A localização a utilizar para
o ficheiro OCR é especificada durante o processo de instalação do Oracle Clusterware.
Outro ficheiro do Oracle Clusterware a guardar no espaço partilhado é o Voting Disk,
que contém informação durante a operação, relativa aos membros activos no cluster a cada
momento.
5.1.1 Instalação
Esta secção trata de um dos pontos chave dos quais depende a arquitectura dos Real
Application Clusters da Oracle, o acesso ao armazenamento partilhado em disco.
A arquitectura RAC é baseada no armazenamento partilhado. Os ficheiros da base
de dados, redo logs e ficheiros de controlo são mantidos num espaço a que todos os nós
pertencentes ao cluster acedem. Não só estes ficheiros são aqui mantidos, também alguns
componentes necessários ao Clusterware, o Oracle Cluster Registry (OCR) e o Voting
Disk, têm necessidade de estar alojados em ambiente partilhado, para que o sistema possa
funcionar.
Para além disso, com a nova versão Oracle Cluster File System 2 (OCFS2), é possı́vel
alojar também o software da base de dados. Esta é uma visão atı́pica do que costuma
acontecer num ambiente em cluster , onde não costuma haver partilha a este nı́vel.
A infraestrurura onde é feito o armazenamento pode ser de diferentes tipos. Pode
ser uma Storage Area Network (SAN), tı́pica em ambientes empresariais de larga escala,
Network Attached Storage (NAS), tipicamente disponibilizada através de servidores NFS,
ou dispositivos ligados directamente, que facultam a facilidade de partilha, normalmente
acedidos através de SCSI sobre cobre ou fibra óptica.
ASM
OCFS
BD
Oracle
Raw RAC
Clusterware
NFS
SCSI, discos c/
NAS SAN
partilha de bus
Figura 5.2: Relação das opções de armazenamento partilhado disponı́veis (em baixo), com
os métodos de acesso que se lhes podem aplicar (representados pelas caixas a picotado)
para possibilitar o alojamento da base de dados RAC e do Clusterware. As zonas fronteira
(tracejado forte) são as zonas de decisão que representam pontos onde deve ser escolhida
uma das opções. Existem casos de dependência estrita que estão representados pelas setas
a azul, em que para a adopção de uma opção há uma obrigatoriedade de satistfazer essa
dependência.
30 Requisitos tecnológicos para Real Application Clusters
A par da infra-estrutura propriamente dita, há que definir os métodos de acesso aos
dispositivos de armazenamento partilhado. Na figura 5.2, podemos ver um esquema que
tenta resumir a relação entre as opções de infraestrutura a adoptar e os métodos de acesso
que podem ser utilizados. Ao criar uma plataforma RAC, tanto o Oracle Clusterware como
a base de dados necessitam dispôr do armazenamento partilhado para o seu funcionamento.
A base de dados pode utilizar qualquer uma das opções, devendo a sua escolha recair na
solução que lhe dê maiores vantagens de acordo com os recursos que existem à disposição.
Já o Clusterware não pode utilizar o ASM para colocar os seus ficheiros, pois sem existir
já activa uma camada de clusterware o ASM não pode operar. Isto sucede porque a
sua execução depende dos serviços prestados pelo Clusterware, da coordenação por ele
prestada às diferentes instâncias Oracle que no incumprimento deste requisito se vêm
incapazes de funcionar. Quanto ao NFS, necessita obrigatoriamente que a infraestrutura
utilizada seja o NAS, dado que se baseia num método de acesso a armazenamento remoto
por rede, necessita que a infra-estrutura utilizada faculte um acesso baseada numa ligação
IP, como é o caso NAS.
ter de configurar os dispositivos Raw. Essa versão foi desenhada para armazenar ficheiros
relacionados com a base de dados e não era permitido guardar ficheiros regulares. Esta
limitação foi levantada na versão seguinte.
A nova geração, o OCFS2, foi introduzida em Agosto de 2005 para as plataformas
Red Hat Enterprise Linux 4 e Suse Linux Enterprise Server 9. Com capacidades para
armazenar ficheiros regulares, é uma alternativa não só para guardar os ficheiros criados
pela base de dados como também os ficheiros binários e de configuração dos produtos
Oracle. Isto possibilita que tenhamos uma Home partilhada pelos diversos nós do cluster,
permitindo um ponto de gestão centralizado, que poderá facilitar algumas tarefas.
Os volumes utilizados com este tipo de partição com o objectivo de alojar especifica-
mente os componentes partilhados do cluster RAC como Voting Disk, Cluster Registry do
Oracle Clusterware, ou os ficheiros da base de dados como Data files, Redo logs, Archive
logs e Control logs devem ser montados com três opções fundamentais para o seu correcto
funcionamento:
datavolume Certifica que os processos Oracle abrem estes ficheiros com a flag o direct
nointr Comprova que as operações de escrita/leitura não são interrompidas por sinais
netdev Indica que este volume é dependente da ligação à rede, garantindo que a rede
seja ligada antes que entre em funcionamento e que, ao desligar, os serviços de
rede sejam desactivados apenas depois deste volume ser posto em inoperatividade
• DLM: Gestor de trincos distribuı́do, que mantém o controlo dos trincos existentes,
seus donos e seu estado actual
Heartbeat
Opções
Com a possibilidade de usar ficheiros regulares, pode ser alojado na partição partilhada
em OCFS2 o software necessário à instalação dos produtos Oracle. Essa opção não foi
escolhida dado que como não está presente um mecanismo de mirroring/striping externo,
seria estabelecer um potencial ponto de estrangulamento, com os nós a concorrerem no
acesso, o que não é apropriado na utilização de um recurso de performance limitada como
o que foi utilizado.
Neste sistema de ficheiros foram apenas mantidos os ficheiros a ser partilhados para o
Clusterware. Também os ficheiros da base de dados poderiam ser aqui colocados, porém
para este fim foi usada a opção Automatic Storage Management (ASM) (apresentada na
secção 5.2.4), que permite algumas facilidades suplementares na gestão do armazenamento.
Esta é também uma solução possı́vel para funcionar com os Oracle Real Application
Clusters, porém a Oracle apenas recomenda a sua utilização sob um conjunto limitado de
5.2 Armazenamento partilhado 33
soluções fornecidos por parceiros certificados com polı́ticas de licenças de acesso restrito.
Para sua utilização é necessário que seja utilizado o protocolo TCP, que os blocos de
escrita/leitura usados sejam de 32kB e com servidores que permitam um acesso directo de
E/S.
Segundo a Oracle, é preferı́vel a utilização de outras alternativas, como OCFS ou
ASM, para disponibilizar o armazenamento partilhado para RAC. Por outro lado, a
indisponibilidade do software necessário devidamente licenciado traduzia o incumprimento
dos seus requisitos. Por estas razões este método não foi utilizado.
Instância ASM
Configuração do ASM
Opções de armazenamento
Disk Group (DG) - Indentifica o conjunto de discos a ser gerido como uma única uni-
dade lógica. Através deste conceito, o ASM elimina a complexidade associada à
gestão de uma enorme quantidade de dados e discos. Também simplifica os proces-
sos de aplicação de mirroring, adição de discos e sua remoção. O administrador da
base de dados fica com as suas tarefas significativamente simplificadas.
Dados com diferentes caracterı́sticas deverão ser guardados em grupos de discos
distintos. Para cada um desses grupos poderá ser definido um nı́vel particular de
redundância, definindo subgrupos de falha que estabeleçam uma configuração parti-
cular.
Exemplos de Disk Groups diferentes:
– DG para uso geral de uma base de dados.
– DG para recuperação, albergando a Flash Recovery Area.
– DG para histórico de dados.
5.2 Armazenamento partilhado 35
Failure Group (FG) define um grupo de discos ou partições que partilham componen-
tes, de modo a que se um desses componentes falhar, os outros discos que dele
dependem também falham. Um exemplo de um grupo de falha pode ser um con-
junto de discos SCSI que partilham a mesma controladora SCSI. Num cenário de
falha dessa controladora, todo esse grupo de discos se torna indisponı́vel. Neste
exemplo, o conjunto de discos fazem parte do mesmo grupo de falha, devendo por
isso ser declarado como Failure Group. Como resultado desta declaração, a instância
ASM não irá utilizar discos dentro do mesmo grupo de falha para efectuar processos
de mirroring entre si. Pelo contrário, efectuará tal procedimento entre grupos de
falha distintos, para assim aumentar o nı́vel de protecção dos dados guardados.
Isto permite a perda ou falha de componentes sem que daı́ resulte uma perda dos dados
nele contidos.
Nı́veis de redundância:
• Elevada - Definir 3 FG
Com este nı́vel de redundância os dados são guardados em triplicado. Toda a in-
formação manuseada tem duas cópias redundantes e são utilizados três grupos de
falha. Com esta opção, é possı́vel a falha em dois dos grupos de falha que ainda
assim o terceiro é capaz de conter uma cópia completa dos dados contidos no Disk
Group.
A Flash Recovery Area é utilizada para recuperar dados que de outra maneira se
perderiam durante uma falha de sistema. É também utilizada pelo Enterprise Manager
caso esteja habilitada a opção de gestão local e cópias de segurança diárias, opções definidas
na página de “Opções de Configuração”, no processo de configuração da base de dados a
partir do Database Configuration Assistant.
Esta área é um espaço que pode ser localizado num sistema de ficheiros, numa directoria
gerida pelo software Oracle ou um Disk Group do ASM, que disponibiliza uma localização
centralizada em disco para guardar cópias de segurança e ficheiros de recuperação.
O Enterprise Manager pode usar este espaço para armazenar as suas cópias de segu-
rança e usa-o para proceder à recuperação de ficheiros. Os componentes de recuperação
da Oracle interagem com a Flash Recovery Area assegurando-se que a base de dados é
36 Requisitos tecnológicos para Real Application Clusters
É apresentada, na tabela 5.1, uma sı́ntese dos principais pontos a favor e contra de
cada um dos métodos de acesso ao armazenamento partilhado, analisados anteriormente.
Ideal para quem tenha de tomar uma decisão em 5 minutos.
+/- Justificação
RAW
+ Não é necessário instalar clusterware da Oracle ou de outro
fornecedor, nem drivers adicionais
− Gestão penosa das partições necessárias
− Escalabilidade - complicadas operações de reparticiona-
mento ou adição de novas partições
NFS
+ Solução de baixo custo
+ Facilidade de utilização
− Apenas disponı́vel para SO’s de famı́lia Unix
− Não recomendado para grandes cargas transaccionais
OCFS2
+ Permite ficheiros regulares (pode alojar o software da BD
Oracle)
+ Aceita operações tı́picas fornecidas por um sistema de fichei-
ros regular
+ Fornece uma solução tanto para Linux como para Windows
− Não tão fácil de gerir como o ASM
ASM
+ Disponibiliza mecanismos de striping e mirroring
+ Grande facilidade de gestão, quer através de sintaxe Oracle,
quer através do Enterprise Manager
+ Óptima escalabilidade
− Difı́cil o manuseamento directo dos ficheiros contidos
− Não é possı́vel guardar os ficheiros do Oracle Clusterware
6.1 Arquitectura
Uma base de dados Real Application Clusters é uma base de dados que funciona em
cluster , ou seja, é formada por um grupo de servidores independentes que cooperam
entre si, funcionando como um único sistema. Esta solução favorece o crescimento do
sistema através de um incremento modular, ao invés de promover pesados sistemas de
multiprocessadores simétricos (SMP). Ao haver uma falha do sistema, o funcionamento
em cluster assegura uma alta disponibilidade do serviço aos utilizadores, de modo a que
não se perca o acesso a dados crı́ticos.
Uma arquitectura RAC utiliza hardware redundante de modo a evitar os “pontos
únicos de falha”. Deste modo, quando sucede uma quebra imprevista no funcionamento
de um dos seus componentes, o que geralmente significaria uma quebra temporária do
serviço prestado, poderá ser suportado pelos componentes restantes que se mantenham
operacionais. O facto de haver uma multiplicidade de nós, interligações e discos no sistema
de armazenamento partilhado, permitem ao cluster garantir uma maior resistência aos
perı́odos de indisponibilidade.
Com a opção RAC, desacoplamos a instância Oracle (as estruturas e processos a correr
num servidor que permitem o acesso aos dados) da base de dados Oracle (as estructuras
fı́sicas residentes no espaço de armazenamento, referidas de uma maneira geral como fi-
cheiros de dados). Para isto contribui o facto destes ficheiros de dados serem alojados num
espaço comum de armazenamento, onde cada um dos nós tem o mesmo nı́vel de acesso.
1
ou grid (em inglês) - de onde vem o g de 10g.
38 Real Application Clusters (RAC)
Uma base de dados a funcionar em cluster , apesar de ser uma única BD, pode ser
acedida através de diversas instâncias. Cada instância corre num nó distinto do cluster .
Quando são requeridos recursos adicionais (como um novo servidor de base de dados ou
um par de discos), podem ser facilmente adicionados ao cluster , sem que seja necessário
suspender o serviço prestado pelos nós activos. A partir do momento em que uma nova
instância é iniciada, as aplicações que usam os serviços da base de dados podem imedia-
tamente dispôr do novo recurso, sem que para isso seja necessário introduzir alterações à
aplicação ou ao servidor de aplicações.
De acordo com o que se pode ver na figura 6.1, nesta arquitectura existe um elevado
grau de partilha em cada camada. Ao nı́vel do armazenamento partilhado, onde são
guardados os ficheiros de dados da BD, é mantido um acesso equidistante desde os vários
membros do cluster aos discos, que são alojados numa localização independente e cujos
métodos de acesso configurados permitem que os seus conteúdos sejam compartidos, de
modo concorrente, pelos vários nós. Ao nı́vel dos membros do cluster , onde são mantidas
as diferentes instâncias da BD, são partilhadas estruturas de memória, que através de
uma eficaz troca de mensagens de baixa latência, mantêm uma vista comum sobre o
estado actual da base de dados (através do mecanismo de Cache Fusion, apresentado na
secção 6.1.1). Ao nı́vel de rede, cada membro partilha duas sub-redes. Uma privada, onde
se estabelecem as interligações de alta velocidade que garantem a troca de mensagens
reservada ao funcionamento do cluster e outra pública, onde são estabelecidas as ligações
com as aplicações cliente ou por onde se estabelece a ligação com a consola de gestão
centralizada, capaz de administrar as inúmeras opções configuráveis deste software.
6.2 Requisitos 39
6.2 Requisitos
6.2.1 Hardware
Segundo é documentado pela Oracle [48], cada um dos elementos do cluster deve ter
disponı́vel:
• Espaço Swap
O espaço Swap é necessário para a utilização da memória virtual. Para isso deve
ser criada uma partição Swap dedicada (ou mais), processo configurável durante o
processo de instalação do sistema operativo, porém, caso seja necessário, pode ser
alocado mais espaço numa fase posterior. A quantidade de espaço em disco ocupada
para este efeito deve ser no mı́nimo igual à quantidade de memória RAM presente.
Consultar a tabela 6.1 para aplicar o tamanho apropriado.
Tabela 6.1: Esta tabela mostra a recomendação para o espaço Swap a utilizar.
2
A seguinte instrução deve ser executado na linha de comandos
40 Real Application Clusters (RAC)
• Deve haver em disco espaço suficiente para o software Oracle, que pode alcançar os
4GB, dependendo do tipo de instalação e plataforma.
– Para verificar a quantidade de espaço existente nas diferentes partições disponı́veis,
introduzir:
# df -h
6.2.2 Software
Para verificar que versão do kernel está instalada com a presente distribuição Linux,
executar na linha de comandos:
# uname -r
No que diz respeito aos pacotes de software instalados, na comprovação que os requi-
sitos são cumpridos, pode ser executado um comando semelhante ao seguinte:
# rpm -q NOME_DO_PACOTE
ou
# rpm -qa | grep NOME_DO_PACOTE
Quanto ao Oracle Cluster File System 2 , a versão disponibilizada com o SUSE Linux
Enterprise Server 9 não tem, de uma maneira geral, um paralelismo no que respeita
ao seu número de versão com o OCFS2 presente no site oficial (http://oss.oracle.com/
projects/ocfs2/). Isto acontece devido à polı́tica de gestão de versões ser gerida por
3
...de Redhat Package Manager
6.2 Requisitos 41
Item Requisito
Sistema operativo x86 SUSE Linux Enterprise Server 9 (SP2 ou posterior)
Red Hat Enterprise Linux AS/ES 3 (Update 3 ou posterior)
Red Hat Enterprise Linux AS/ES 4 (Update 1 ou posterior)
Versão do Kernel O sistema deve correr no seguinte kernel (ou versão posterior)
SUSE Linux Enterprise Server 9 :
2.6.5-7.97
Red Hat Enterprise Linux 3 (Update 4):
2.4.21-27.EL
Red Hat Enterprise Linux 4 (Update 1):
2.6.9-11.EL
Tabela 6.2: Requisitos para sistemas Linux x86 (32-bit). Versão do kernel e pacotes a
instalar para a opção SUSE Linux Enterprise Server 9
42 Real Application Clusters (RAC)
6.2.3 Rede
• Os nomes das interfaces associadas quer à rede privada, quer à rede pública, deverão
ser idênticos em todos os nós que façam parte do cluster. Se considerarmos que
estamos a produzir um cluster de dois nós, e associamos eth0 à interface de rede
pública e eth1 à interface de rede privada num dos nós, temos de manter essa mesma
atribuição no outro membro do cluster.
• Para uma maior confiabilidade, podem ser configurados adaptadores de rede redun-
dantes em cada nó do cluster quer para a rede pública, quer para a rede privada.
Para isto deve ser configurado um mecanismo de bonding (secção 6.4.6)
• Para a rede rede privada, a interligação deve suportar UDP, e usar adaptadores de
rede e comutadores de rede4 que suportem TCP/IP (Gigabit Ethernet ou superior
é recomendável)
UDP é o protocolo utilizado por omissão pelo Oracle Real Application Clusters e
TCP é o protocolo de interligação usado pelo Oracle Clusterware.
• Através da rede privada, os nós devem estar acessı́veis entre si. Não deve haver
qualquer nó que não tenha ligação com todos os outros. Para isto, a interface de
rede deve estar devidamente configurada, com os parâmetros apropriados (endereço
IP e máscara de rede válidos, ligações fı́sicas devidamente estabelecidas. . . ). Para
verificar o alcance a uma das interfaces presentes no cluster, pode ser utilizado o
comando ping . Utilizando a ferramenta Cluster Verification Utility (CVU), cujas
caracterı́sticas são apresentadas na secção 6.6.1, existe também uma funcionalidade
que permite aferir sobre a boa conectividade entre os nós, confirmando assim uma
correcta configuração ao nı́vel das interligações.
6.2.4 Endereços IP
nome_de_rede endereço_ip
por cada um dos nós que compõem o cluster, incluindo o próprio onde está a ser
editado o ficheiro.
O endereço IP utilizado para a rede pública e o VIP devem fazer parte da mesma
subrede.
Nem os endreços IP especificados nem os nomes de rede a eles associados devem estar
sob utilização, de modo a não causar conflitos na rede e consequentemente um funciona-
mento defeituoso da plataforma criada.
Um exemplo de configuração da estrutura de rede pode ser visto na página 44, con-
sultando a tabela 6.6 que apresenta a configuração adoptada na criação do protótipo
desenvolvido no âmbito deste projecto.
Em conformidade com as considerações tecidas na secção 6.2.4, que estabelece a atri-
buição de endereços IP, foi requisitado um endereço de rede Classe C para albergar as
máquinas que farão parte do cluster. assim como as subredes necessárias à construção
uma plataforma de rede
Rede de Classe C que foi atribuı́da: 172.16.9.0
Com a necessidade de ter duas redes distintas, a pública (para as interfaces públicas e
virtuais) e a privada (para as interfaces privadas), torna-se imprescindı́vel segmentar esta
rede em subredes.
Do leque de endereços IP cedidos com a rede que foi atribuı́da, podemos dispôr dos
8 bits menos significativos, dos 32 que compõem um endereço IP, para gerir a necessária
segmentação. De modo a cumprir com os requisitos e guardar alguma margem de manobra,
para a possibilidade de ser necessária uma reserva extraordinária de endereços ou redes IP
numa fase posterior, foi analisado o espaço de endereços de modo a definir que segmentação
de rede efectuar. Foi criada uma tabela auxiliar para análise e decisão da configuração
da rede disponı́vel, com vista à sua segmentação. São mostradas as diferentes hipóteses
consideradas na tabela 6.3.
44 Real Application Clusters (RAC)
Tabela 6.4: Endereços de subredes, com a indicação dos valores válidos como máximos e
mı́nimos para os endereços IP.
Subrede
Interface Rede
# Endereço
eth0 1 172.16.9.0 Pública (e Virtual)
eth1 2 172.16.9.16 Privada
Tabela 6.5: Relação entre cada interface, subrede definida e tipo de rede que a utiliza.
Antes de efectuar a instalação, foi também verificado o acerto entre os relógios das
diferentes máquinas pois deste sincronismo depende o bom funcionamento do Oracle Real
Application Clusters. Nesse sentido, foi configurado o Network Time Protocol (NTP) nos
vários elementos do cluster. É importante verificar que todos os nós do cluster tenham
acesso a um mesmo servidor de tempo como referência.
É uma rede privada de alta velocidade, que permite a inter-comunicação entre todos
os elementos do cluster. Também conhecida como HSI (High-speed interconnect), é o
principal veı́culo para o eficaz funcionamento da tecnologia Oracle’s Cache Fusion que
combina a memória fı́sica (RAM), individual de cada máquina, numa cache única e global.
Cada nó do cluster tem configurado um endereço IP com a interface de rede de acesso
público, contido numa rede comum, partilhada pelo conjunto de nós. Este endereço é
utilizado para a configuração da interface de rede utilizada pela base de dados para aceitar
as ligações com os clientes. Para além deste endereço deve estar atribuı́do um endereço IP
virtual (VIP) que lhe é associado automaticamente no processo de instalação dos Oracle
Real Application Clusters pelo OUI.
Para utilização dos Oracle Real Application Clusters é necessário haver um endereço
IP virtual (Virtual IP, ou VIP) atribuı́do a cada servidor que faça parte do cluster. Este
endereço deve estar disponı́vel e fazer parte da mesma subrede da interface de rede pública.
É o endereço que as aplicações ou utilizadores externos utilizam para se ligar à base
de dados RAC. Se um dos nós falhar, esse facto é identificado pelo cluster, que procede
a uma reatribuição desse endereço a um dos nós que tenham “sobrevivido”, dando assim
uma resposta imediata aos pedidos de ligação apesar da quebra existente.
Isto aumenta a disponibilidade para as aplicações, pois não têm de esperar as no-
tificações de rede sobre a quebra da ligação e buscar uma alternativa. Antes que isso
aconteça, o cluster trata de fazer o reencaminhamento do serviço indisponı́vel para outro
servidor enquanto o que registou a quebra não recuperar o seu estado operativo e voltar
a estar disponı́vel [53].
O VIP tem de ser definido mas inicialmente não tem qualquer adaptador de rede
atribuı́do. Somente numa fase posterior esta configuração é feita pelo OUI (Oracle Uni-
versal Installer ).
46 Real Application Clusters (RAC)
6.4 Opções
Foi configurada a utilização deste módulo nos servidores do cluster da base de dados.
É um módulo do sistema operativo Linux que deve ser incorporado no kernel .
Monitoriza a disponibilidade e confiabilidade do servidor. Se por algum motivo uma
destas propriedades não é cumprida, como quando existe um bloqueio na resposta do
servidor este módulo trata de reiniciar a máquina automáticamente.
Utiliza dois parâmetros chave, um para o intervalo entre verificações do estado de saúde
do sistema – hangcheck-tick – e outro para a margem de espera – hangcheck-margin – que
define o perı́odo de tempo que deve ser tolerado a servidor até obter uma resposta activa.
6.4.3 Listener
Cada vez um cliente solicita uma sessão de rede com um servidor, um Listener recebe
o actual pedido. Caso a informação prestada pelo cliente coincida com a informação do
Listener, é concedida a ligação ao servidor.
6.4.4 Serviços
• Disponı́vel – O serviço é arrancado nesta instância caso não seja possı́vel fazê-lo
numa preferida. O serviço pode correr na instância caso uma das preferidas falhe.
Esta é uma tecnologia que permite restituir um serviço em caso de falha, dando suporte
aos Real Application Clusters para manter os serviços disponı́veis, ainda que ocorra uma
quebra num dos servidores. Quando isso acontece, o TAF tenta restabelecer a ligação
entre a aplicação e o serviço, mesmo que tenha de reencaminhar a aplicação para outra
instância. Este processo é feito sem que o utilizador final se aperceba.
Na configuração desta aplicação existem parâmetros que devem ser definidos. São
apresentados os dois principais.
Tipo:
• Select - os cursores abertos na aplicação podem continuar a ser usados após a falha
desde a nova instância.
48 Real Application Clusters (RAC)
Método:
Configuração
BOOTPROTO=static
BROADCAST=172.16.9.15
IPADDR=172.16.9.1
NETMASK=255.255.255.240
NETWORK=172.16.9.0
STARTMODE=onboot
BONDING_MASTER=’yes’
INTERFACE=’bond0’
BONDING_MODULE_OPTS=’miimon=100 mode=active-backup primary=eth0’
BONDING_SLAVE0=eth0
BONDING_SLAVE1=eth2
Deverá ser reiniciado o sistema para confirmar que a interface é iniciada no processo
de arranque. Para verificar o seu funcionamento efectuar a instrução indicada na linha de
comandos (como root) e confirmar a existencia da interface bond0 na lista de interfaces
apresentada.
# ifconfig
6.4.7 Orarun
Foi utilizado o pacote Orarun, que faz parte da distribuição da Novell. Este pacote
realiza um conjunto de tarefas que agilizam o processo de instalação de productos Oracle,
através da incorporação de um conjunto de scripts ao ser utilizados tornam
Altera os parâmetros do kernel e adaptá-los com valores indicados para uma instalação
Oracle.
Cria automaticamente os grupos necessários à instalação de produtos Oracle e o utili-
zador oracle do sistema operativo como membro destes grupos.
Estabelece para este utilizador as variáveis de ambiente necessárias para a instalação
dos diversos produtos.
Permite a disponibilização automática de alguns serviços comuns, como da base de
dados, ou o listener que fica à escuta de ligações por parte dos clientes.
• VARIAMB.sh
– Define as variáveis de ambiente utilizadas pelas diversas scripts desenvolvidas.
Neste ficheiro podem ser alterados os parâmetros a utilizar, como a directoria reflec-
tida na variável DESTI SEGURETAT, que deve ser usada para guardar os ficheiros
de sistema originais , a directoria onde se encontra o software a ser utilizado (FONT ),
a Home para o CVU (CV HOME ), a directoria onde devem ser colocados os ficheiros
de script a que serão executadas pelo utilizador oracle, etc.
• 001 directoris.sh
– Cria as directorias necessárias ao software Oracle.
• 002 cvuhome.sh
–Instala o software CVU referente ao utilizador root. –
• 003 cvuoracle.sh
–Deve ser executado pelo utilizador oracle quando solicitado pelo script anterior.
• 004.sh
–Realiza a actualização do kernel e Oracle Cluster File System
• 005 hangcheck.sh
–Instala o módulo ao kernel com os parâmetros adequados.
• 006 hosts.sh
–Trata da resolução de nomes.
• 007 mem.sh
– Retira as limitações ao uso de memória por parte do utilizador oracle, conforme
visto na secção 7.11.
• 008 orarun.sh
–Modifica os ficheiros do pacote Orarun, de modo a adequar o ambiente criado
com as particularidades definidas, a nı́vel dos parâmetros ORACLE HOME, ORA-
CLE BASE e SID da instância de acordo com o servidor onde é executado. Executa
o script rcoracle que activa a utilização do Orarun.
• 009.sh
–Manipula os limites da shell para o utilizador oracle.
• 010.sh
–Cria as chaves SSH.
• 011
–Transfere as diversas chaves públicas para o ficheiro local de autorizações.
• 012 ocfs.sh
–Prepara a instalação do Oracle Cluster File System 2 .
5
em catalão. . .
6.6 Testes 51
• 015 asminstall.sh
–Instala o driver ASM.
• 016 asmconfigure.sh
–Configura o driver ASM.
• 018 preparaCRS.sh
–Prepara a instalação do Clusterware.
6.6 Testes
Esta é uma nova ferramenta disponibilizada a partir da última versão Oracle Data-
base 10 g Release 2 (10.2) desenvolvida para assistir na configuração e instalação quer
do Clusterware, quer do próprio RAC. Verifica as componentes essenciais, ao longo das
consecutivas etapas de instalação de todo o ambiente. A sua acção de diagnóstico sobre
o processo é extensa, abrangendo da configuração inicial do hardware, até à implantação
final do sistema no seu estado operacional.
Tem uma grande abrangência no diagnóstico de diferentes pontos do processo de ins-
talação do ambiente RAC. Através da linha de comandos, a instrução cluvfy pode funci-
onar através de dois modos de funcionamento essenciais:
• por fase: para os pontos crı́ticos da instalação são estabelecidos marcos, que identi-
ficam as suas fases fundamentais (como a instalação do Clusterware, por exemplo).
Esta ferramenta tem estabelecido um conjunto de critérios de entrada e de saı́da
para cada uma destas fases.
Quando a instalação atinge um dos marcos crı́ticos estipulados, pode ser executado o
teste respectivo. Então, com base nos critérios estabelecidos para a tarefa concreta a
executar, é avaliado o cumprimento dos seus requisitos (necessários para cumprir-la
com sucesso). Deste modo, em caso de esquecimento ou incorrecção no cumprimento
de algum dos passos necessários, pode evitar-se a sua propagação para etapas pos-
teriores, o que possivelmente teria consequências, quer na sua localização posterior,
quer nos impactos negativos que daı́ poderiam provir.
Comandos relacionados
Para diagnóstico dos vários items esta ferramenta pode ser usada com os seguintes
parâmetros:
LISTA DE NÓS: é uma lista separada por vı́rgulas com os nós sobre os quais incide o
teste. Por exemplo: rac1,rac2
Algumas das verificações executadas são aqui enunciadas:
• Para verificar a ligação entre todos os nós através de uma interface em especı́fico,
usar a opção -i INTERFACE.
# cluvfy comp nodecon -n LISTA_DE_NÓS -i eth0 [-verbose]
• Verificar se o sistema está preparado para instalar a Oracle Database 10 g com RAC
# cluvfy stage -pre dbinst -n LISTA_DE_NÓS
sobre este tema é apresentado no apêndice). Através do Sqlplus pode também ser avaliado
um vasto conjunto de parâmetros.
SELECT instance_name,
host_name,
NULL AS failover_type,
NULL AS failover_method,
NULL AS failed_over
FROM v$instance
UNION
SELECT
NULL,
NULL,
failover_type,
failover_method,
failed_over
FROM v$session
WHERE username = ’SYSTEM’;
4. Num dos nós do cluster (podia ser qualquer deles) foi forçado o desligamento
da instância referida anteriormente (rac1) pelo utilizador oracle:
54 Real Application Clusters (RAC)
# su - oracle
#srvctl status database -d orcl
Instance orcl1 is running on node rac1
Instance orcl2 is running on node rac2
# srvctl stop instance -d orcl -i orcl1 -o abort
#srvctl status database -d orcl
Instance orcl1 is not running on node rac1
Instance orcl2 is running on node rac2
5. Nesta altura, a partir da consola que permaneceu aberta no cliente Oracle foi
executada de novo a sentença SQL, e o resultado foi então o seguinte:
INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- --------- ------------- --------------- -----------
orcl2 rac2
SELECT BASIC YES
Após o processo de instalação inicial, em que é criado o cluster e posta a base de dados
num estado operacional, é possı́vel proceder à adição de nós adicionais, sem que para isto
seja necessário que os membros já existentes deixem de prestar o serviço sobre a base de
dados. Para isso é necessário criar no novo nó um sistema que seja compatı́vel com o
ambiente RAC, respeitando as suas limitações, sobre as quais são referidos alguns pontos
na secção seguinte (6.7).
É necessário que o novo membro tenha uma arquitectura semelhante aos já existentes,
assim como o mesmo sistema operativo. Após ter sido instalado o sistema operativo, é
necessário colocar a camada de rede num modo funcional, mantendo a estrutura de interfa-
ces utilizadas, e respectivos endereços, concordantes com o tipo de rede a que pertencem.
6.7 Limitações 55
Como exemplo, se nos outros nós a interface eth0 está atribuı́da à rede pública, esta
relação deve conservar-se na configuração do novo nó.
Deve ser configurada a equivalência de utilizador ao nı́vel do protocolo SSH, de modo
a permitir o estabelecimento de ligações seguras entre os nós, sem depender da entrada
em modo interactivo (para pedir a password ou confirmar o estabelecimento da ligação),
efectuando a troca de chaves públicas com os outros nós, tal como terá sido feito pelos
membros existentes anteriormente.
Deve ser seguido o processo de configuração do sistema para o ambiente RAC, ade-
quado aos novos nós, garantindo o acesso aos dispositivos que garantem o armazenamento
partilhado, conforme feito numa instalação de raı́z, até ao momento de instalação do
software Oracle.
Existem vários procedimentos para estender o ambiente RAC a novos nós e instâncias
e proceder à instalação do software Oracle, no qual se inserem o Oracle Clusterware e o
Oracle Database 10 g. Dos existentes, o método de clonagem Oracle é o preferı́vel. Este
método permite criar uma nova instalação, com todas as actualizações que já tiverem sido
aplicadas, através de um “único passo”, evitando ter de passar por todos os passos isolados
de instalação, configuração e aplicação de actualizações. Possibilita uma maior rapidez
neste processo e permite que um nó de origem, que faça já parte do cluster , com uma
instalação bem sucedida, funcione como fonte na disseminação da instalação por diversos
nós.
6.7 Limitações
Com o Oracle Database 10 g Release 2 (10.2), Oracle Clusterware e Oracle Real Appli-
cation Clusters são suportados até um máximo de 100 nós num cluster [53]. Apesar desta
imposição sobre o tamanho que pode atingir um cluster deste tipo ser bastante razoável,
um cenário de grandes dimensões não implica necessariamente uma melhor solução.
Segundo a opinião de alguns especialistas, o número “ideal” para popular um RAC
ronda os quatro nós.
Não tem de haver homogeneidade respeitante aos servidores que compõem o cluster
RAC, porém estes devem correr sobre o mesmo sistema operativo.
Tem de ser idêntica a versão Oracle que utilizam. Inclusivamente, quando co-existem
duas versões diferentes da base de dados no mesmo sistema, estas apenas podem funcionar
de modo independente e não poderão partilhar a mesma Home 6 .
A maior parte das actualizações, quer da base de dados, quer do sistema operativo,
representarão uma quebra no serviço disponibilizado pelo nó onde se procede a manu-
tenção. Dado que esta prática provavelmente terá de ser repetida pelos outros nós, poderá
representar uma morosidade considerável, sobretudo caso seja um cluster numeroso.
Todos os servidores devem suportar a mesma arquitectura, por exemplo serem todos
sistemas de 32-bit ou todos 64-bit.
6
variável que especifica a directoria onde é realizada a instalação do software dos produtos Oracle.
Capı́tulo 7
Protótipo
Com base no estudo efectuado sobre o produto Oracle Database 10 g Release 2 (10.2),
com a sua extensão Real Application Clusters, foi realizado um protótipo que pretendeu
criar na prática uma plataforma em cluster deste género. No decorrer deste capı́tulo são
apresentadas as principais opções tomadas na sua concretização, assim como os passos que
compuseram o seu desenvolvimento. Muitos dos termos, opções ou tarefas aqui tratados
são apresentados e justificados nos capı́tulos anteriores, cuja consulta se considera, deste
modo, bastante útil para melhor compreender este processo de implementação.
7.1 Infra-estrutura
1. Escolheu-se a opção “Add Virtual Machine” para criar uma nova máquina virtual.
O painel onde são definidas as opções standard para a máquina em questão foi então
apresentado.
Localização Definiu-se onde deveria ser guardado o ficheiro que contém a parame-
trização da máquina virtual a ser criada.
/home/rnogueira/vmware/linux/rac1 maq.vmx
2. Processador e memória
3. Opções de Disco
Para cada máquina foi criado um disco para conter os ficheiros locais necessários
(como o sistema operativo, software da base de dados e do Clusterware, etc.). So-
bre cada um destes discos foram criadas as partições necessárias à sua estrutura
básica local. Além destes, foram ainda criados discos responsáveis por garantir o
armazenamento partilhado, do qual depende a arquitectura RAC. Para este efeito
foi criado um disco para ser utilizado com sistema de ficheiros OCFS2 e outros três
para serem utilizados pelo ASM. Este espaço a ser compartido foi configurado para
ser “partilhado” através da controladora SCSI que lhes foi atribuı́da (que deverá ser
diferente da que controla o disco local).
Tabela 7.1: Criação de discos. O âmbito de utilização para o disco respectivo, se Local ou
Partilhado, e o tamanho de cada um (em GigaBytes).
58 Protótipo
espaco /dev/sda
partilhado
/dev/sde
Local
/dev/sdd
/dev/sdc ASM
OCFS2
/dev/sda /dev/sdb
EXT3
Local
Para a instalação nos múltiplos nós do cluster pode ser usado um processo de clonagem.
Na figura 7.2 podem ver-se os passos que esta operação poderá englobar, facilitando o
processo global de instalação.
Existem alguns métodos para realizar este processo de clonagem. Podem ser utilizados
programas especı́ficos para este fim ou pode ser criado um ficheiro, compactando nele os
conteúdos do sistema de origem e utilizá-lo para transportá-los para o sistema de destino.
Neste caso foi utilizada uma terceira opção. O VMware fornece no seu componente Gestor
de Ficheiros a possibilidade de efectuar operações sobre os ficheiros contidos na máquina
host. No ambiente VMware, os discos das máquinas virtuais são alojados em ficheiros, cujo
nome é especificado na sua criação. Para clonar um destes discos basta apenas efectuar
uma cópia do ficheiro que lhe corresponde.
No entanto é necessário evitar possı́veis inconsistências que poderão resultar das clo-
nagens realizadas. Como precaução tomada nesse sentido, as interfaces de rede foram
7.3 Instalação SUSE Linux Enterprise Server 9 59
Criar
nova maquina
Figura 7.2: Encadeamento das várias tarefas numa primeira fase da instalação RAC.
Estas tarefas são feitas isoladamente em cada servidor, livres ainda das dependências de
grupo. Como este é um processo repetitivo entre os diferentes servidores, poderá ser usado
um processo de clonagem para aplicar a mesma configuração em múltiplos nós.
desabilitadas no momento prévio à criação dos clones. No seu restauro, antes de proce-
der à sua activação, as interfaces de rede foram devidamente configuradas, ajustando os
endereços de rede em conformidade com os valores definidos anteriormente (segundo a
tabela 6.6, presente na página 44).
Para a instalação do sistema operativo foi utilizada a distribuição SUSE Linux Enter-
prise Server 9 (6 CDs) com o Service Pack 3 (3CDs).
12. Gráficos e som. Estes serviços não foram configurados. Caso se pretenda, estes
serviços podem ser configurados, porém isso deve ser feito depois da instalação das
VMwareTools.
O sistema foi actualizado com o novo kernel Linux (2.6.5-7.257) e a utilização de uma
versão mais recente do OCFS2 (1.2.1-4.2), o que resolveu alguns problemas observados
com as versões anteriores. Uma das dificuldades com as versões anteriormente instaladas
era devida ao sistema de escalonamento E/S e, para circundá-la, podia ser definida uma
opção de boot elevator=deadline. Com estas actualizações esse procedimento já não é
necessário1 .
1. Deverá ser utilizado preferencialmente o modo de texto. Para isso poderá ser usada
a combinação de teclas <Ctl> + <Alt> + <F1> para mudar para modo de texto
(ou introduzir o comando #telinit 3 num terminal virtual).
# /etc/init.d/network stop
# rmmod pcnet32
# rmmod vmxnet
# depmod -a
# modprobe vmxnet
# /etc/init.d/network start
Este processo deverá ser reproduzido em todas as máquinas que fazem parte do cluster ,
caso a opção de clonagem não seja adoptada.
Para resolver o problema da velocidade excessiva do relógio no sistema (ver secção 2.4
na página 7), foi editado o ficheiro \etc\lilo.conf e junto com as opções do kernel,
introduziram-se as seguintes opções adicionais: acpi=off e clock=pmtmr
Exemplo:
image = /boot/vmlinuz
label = Linux
initrd = /boot/initrd
optional
root = /dev/sda4
append = "selinux=0 splash=silent acpi=off clock=pmtmr hugepages=146"
1. Foi criada uma directoria “Home” para alojar o software CVU onde o utilizador
oracle, responsável pela instalação Oracle Database 10 g, tivesse plenas permissões
de leitura e escrita. Nesta instalação foi definida a directoria cvu dentro da sua
directoria Home (\home\oracle\cvu).
# mkdir ∼oracle/cvu
# chown -R oracle:oinstall
# chmod -R 755 ∼oracle/cvu
4. Criou-se uma directoria (∼oracle/cvu/tmp) onde seria colocado o output dos testes
executados por esta aplicação.
# mkdir ∼oracle/cvu/tmp
De modo a que estas variáveis fiquem disponı́veis para futuras sessões pode editar-se
o ficheiro ∼oracle/.bashrc. Como este ficheiro não existia, foi necessário criá-lo, e
adicionaram-se as seguintes linhas:
CV_HOME=∼oracle/cvu
CV_JDKHOME=/usr/lib/java/jre
CV_DESTLOC=∼oracle/cvu/tmp
export CV_HOME CV_JDKHOME CV_DESTLOC
6. Para a utlização do CVU no SUSE Linux Enterprise Server 9 foi também necessário
fazer uma pequena alteração no ficheiro de configuração do CVU, localizado em
∼oracle/cvu/cv/admin/cvu_config, alterando o parâmetro ASSUME_DISTID do
valor Taroon para Pensacola de modo a permitir a adaptação da ferramenta ao
contexto desta distribuição. Desenvolveu-se um script (003_cvuoracle.sh) que faz
esta correcção automaticamente.
Este módulo, visto com melhor pormenor na secção 6.4.2, na página 46, deve ser
carregado no kernel com os parâmetros devidos. Para isso foram efectuados os seguintes
passos como root.
Introduziu-se dinamicamente o módulo no kernel Linux:
# modprobe hangcheck-timer hangcheck_tick=30 hangcheck_margin=180
Automatizou-se o seu carregamento para cada vez que o sistema fosse reiniciado:
# echo ’modprobe hangcheck-timer hangcheck_tick=30 hangcheck_margin=180’
>> /etc/init.d/boot.local
Confirmou-se que havia sido devidamente adicionado e que estava a funcionar com os
parâmetros correctos:
# grep Hangcheck /var/log/messages | tail -2
5
Java Runtime Environment, v1.4
66 Protótipo
Para tornar esta alteração permanente e não apenas válida na presente sessão, executou-
se na linha de comandos:
# echo "vm.disable_cap_mlock = 1" >> /etc/sysctl
# chkconfig boot.sysctl on
7.13 Orarun
Foi necessário alterar os parâmetros em alguns dos scripts que fazem parte deste pacote
para adequar o ambiente criado com o cenário que se pretendia implementar.
Nó SID
rac1 orcl1
rac2 orcl2
Este pacote cria o utilizador oracle como membro dos grupos necessários para a
instalação dos productos Oracle, criando também os respectivos grupos. Inicialmente
esta conta tinha algumas capacidades desactivadas, como a de fazer login ou aceder à
linha de comandos. Foi necessário activá-las. Uma das formas utilizadas para fazê-lo foi
editando o ficheiro /etc/passwd atribuindo-lhe uma shell, alterando o valor /bin/false
para /bin/bash .
Feito isto, foi definida uma password para este utilizador através do comando:
# passwd oracle
7.14 Limites
Foram ainda alteradas algumas variáveis de ambiente (script 009) para permitir alargar
os limites ao utilizador oracle quanto ao número de descritores, assim como o número de
processos que se lhe permite ter abertos.
Caso este procedimento seja utilizado, deverá ser reposta a funcionalidade de rede em
cada uma das máquinas.
68 Protótipo
É requisito para a instalação do RAC que haja uma equivalência do utilizador oracle,
assim como dos grupos a que pertence (em particular dba e oinstall), entre os vários nós
do cluster. Isto porque existem comandos, programas e ficheiros que são trocados entre
os vários servidores e esta prática facilita a gestão destas operações.
Nesse sentido foi configurada também uma equivalência a nı́vel de protocolo SSH, para
que as operações remotas fossem efectuadas de um modo seguro, por um lado, e autónomo,
por outro, já que através da equivalência que é estabelecida se evita a necessidade de
interacção com o utilizador para inserir a password quando se estabelece a ligação segura.
Em cada nó, na directoria Home da conta do utilizador oracle, foi criada a directoria
onde seriam guardados os ficheiros necessários à troca de mensagens SSH entre os membros
do cluster . Nesta localização criou-se um par de chaves (pública e privada) de cada tipo
(RSA e DSA). Isto porque a versão 1 do SSH utiliza chaves RSA e a versão 2 utiliza
chaves DSA. Cobrindo os dois tipos permite-se que o SSH possa utilizar qualquer uma das
versões.
# mkdir ∼/.ssh
# chmod 755 ∼/.ssh
# /usr/bin/ssh-keygen -t rsa
# /usr/bin/ssh-keygen -t dsa
Na criação das chaves pode ser opcionalmente definida uma frase de passe para garantir
uma protecção adicional. Nesta configuração foi deixada em branco. Porém, caso seja
preenchida, deverá ser definida com o mesmo valor em ambos os nós e lançado o programa
ssh-agent em todas as máquinas do cluster .
O conteúdo dos ficheiros relativos às chaves públicas de cada nó, id_rsa.pub e também
id_dsa.pub, deve ser copiado para o ficheiro ∼oracle/.ssh/authorized_keys, quer da
própria máquina, quer de todas as outras que fazem parte do cluster . Neste caso, entre
máquinas distintas, o comando ssh especificado faz a cópia dos conteúdos da máquina
remota para a máquina local. Estes comandos devem ser repetidos nos vários membros
do cluster .
Foi então testada a conectividade entre todos os nós, estabelecendo a partir de cada um
ligações SSH tanto para o próprio, como para os restantes nós. Quando se estabelecia a
primeira ligação entre cada par, era apresentado um pedido de confirmação sobre a ligação
em causa, que não se voltava a repetir em posteriores ligações. Como este pedido deve ser
evitado durante o funcionamento do RAC, devem ser testadas e estabelecidas, nesta fase,
todas as ligações possı́veis entre os nós.
7.17 Preparação das partições 69
Foi criada uma única partição em cada disco. Ao correr o fsdisk, utilizou-se a opção
n para criar uma nova partição. Indicou-se que seria primária (p) e que seria a primeira
partição primária de quatro possı́veis (1). Escolhendo a opção p era mostrada a tabela de
partições, pronta a ser criada. Quando se confirmou a validação, por parte do utilizador,
da configuração preparada, através da opção w foi feita a escrita da nova tabela de partições
no disco apontado. Ao ser finalizada a escrita, o programa saiu automaticamente para a
linha de comandos.
Para que nos outros elementos do cluster as alterações realizadas fossem reconhecidas
pelo kernel, foi executado como root, em cada um deles, o comando:
# partprobe
7.18 OCFS2
Seguidamente são enunciados os passos que foram percorridos para configurar o sistema
de ficheiros Oracle Cluster File System 2 .
1. Para criar o ficheiro de configuração do Oracle Cluster File System 2 , que é alojado
em /etc/ocfs2/cluster.conf, foi executado como root:
# ocfs2console
2. O ficheiro criado deverá constar em todos os servidores. Para isso poderá ser feita
uma cópia fiel do ficheiro criado no ponto anterior, colocando-a na localização res-
pectiva nos diferentes nós ou pode ser usada a consola utilizada no ponto anterior.
Foi utilizado este último método, que é provavelmente o mais ágil. Para isso fechou-
se a janela em que é feita a configuração dos nós. Seleccionou-se então, na janela
inicial da consola, [Cluster]⇒[Propagate Configuration]. O ficheiro de configuração
criado foi disseminado pelos restantes servidores.
70 Protótipo
Como esta propagação utiliza SSH, teve de ser introduzida a password de root,
quando requerido, para permitir que a operação fosse efectuada nos diversos servi-
dores.
4. Para que a pilha fosse carregada a cada reinı́cio, inseriu-se o seguinte comando em
todos os nós, como root:
# /etc/init.d/o2cb enable
Espera-se que o serviço se encontre com o estado “on” para os nı́veis 3 e 5, que
representam o respectivo runlevel 6 .
5. Criou-se o ponto de montagem para este sistema de ficheiros nos vários nós:
# mkdir /u02
6. Apenas a partir de um nó, foi criado o sistema de ficheiros, introduzindo como root:
# mkfs.ocfs2 -b 4K -C 32K -N 4 -L /u02 /dev/sdb1
Pode ver-se que foi utilizada a etiqueta que associámos ao sistema de ficheiros quando
o criámos, para facilitar a sua identificação.
Utilizou-se também a opção de montagem datavolume. É uma opção essencial para
os volumes que contenham os ficheiros Voting Disk, Cluster Registry, os ficheiros de
dados da BD, Redo logs, logs de arquivo e ficheiros de controlo, de modo a assegurar
que os processos Oracle abram estes ficheiros com a flag o_direct [60]. Esta flag
tenta minimizar os efeitos da cache de E/S nos ficheiros acedidos. Geralmente este
procedimento traduz-se num decréscimo da performance mas é útil em situações em
que as aplicações têm os seus próprios mecanismos de cache ou necessitam ter um
acesso directo aos dados contidos nos dispositivos, como é o caso.
Para verificar se a montagem foi feita devidamente:
# mount
6
runlevel é uma configuração do software do sistema que apenas permite existir um grupo pré-
seleccionado de processos em execução
7.19 Clusterware 71
9. Criou-se uma directoria no sistema de ficheiros OCFS2, usada para guardar os fi-
cheiros partilhados do Clusterware. Como root executou-se na linha de comandos:
# mkdir -p /u02/oracrs
# chown oracle:oinstall /u02/oracrs
# chmod 775 /u02/oracrs
Criou-se outra directoria para conter os ficheiros da base de dados (onde seria mon-
tado posteriormente o ASM).
# mkdir -p /u02/oradata
# chown oracle:oinstall /u02/oradata
# chmod 775 /u02/oradata
7.19 Clusterware
Caso sejam utilizadas aplicações que utilizem o acesso remoto para executar aplicações
gráficas, de maneira a permitir esse tipo de acesso, deve ser desactivado o controlo de
acesso ao servidor X pelo root (executando xhost +) ou especificando o endereço IP da
máquina de onde provém o pedido (executando xhost + IPMÁQUINA).
# su a
# DISPLAY=:0.0; export DISPLAY; xhost +
a
introduzir a password de root e após realizar os comandos preten-
didos como super-utilizador, introduzir exit na respectiva consola para
voltar ao modo normal.
Foi assegurado que algumas variáveis de ambiente não estivessem definidas (ver secção 5.1.1
na página 28).
# unset ORACLE_HOME
# unset TNS_ADMIN
72 Protótipo
Criou-se uma directoria para o software necessário e colocou-se aı́ o ficheiro zip de
instalação do Clusterware. Descomprimiu-se o ficheiro zip.
# unzip 10201_clusterware_linux32.zip
7. Actuar de igual modo como no ponto anterior, agora relativamente ao Voting Disk.
Localização para o Voting Disk: /u02/oracrs/vot.crs
rac1
Nome do nó rac1
Nome da interface VIP rac1-vip
Endereço VIP: 172.16.9.8
Máscara de rede 255.255.255.240
rac2
Nome do nó rac2
Nome da interface VIP rac2-vip
Endereço VIP: 172.16.9.9
Máscara de rede 255.255.255.240
(d) Foi então apresentado o sumário da configuração a realizar, que deveria ser
confirmada. Finalizou-se, de modo a que fosse aplicada.
(e) Quando o processo terminou, foram mostrados os resultados na janela do as-
sistente de configuração. Poude então ser terminada a aplicação escolhendo
“Exit”.
11. Finalizou-se então a aplicação OUI, confirmando a completa execução dos scripts
solicitados por parte do utilizador root.
# $CRS_HOME/bin/crs_start -all
Deve instalar-se o software, o que foi feito através da conta do utilizador root, na
directoria onde se encontravam os pacotes rpm, através do comando:
# rpm -Uvh oracleasm-2.6.5-7.257-default-2.0.2-1.i586.rpm \
oracleasmlib-2.0.2-1.i386.rpm oracleasm-support-2.0.2-1.i386.rpm
Antes de a utilizar, esta ferramenta teve de ser configurada em todos os nós (pelo
root).
# /etc/init.d/oracleasm configure
Para utilizar os discos dedicados à utilização ASM foi necessário prepará-los como tal,
usando as partições criadas na secção 7.17 (página 69).
Esta operação foi realizada apenas num dos membros do cluster através da conta de
super-utilizador. No comando a empregado é especificado o nome a atribuir ao novo disco
(NOMEDISCO), onde devem ser usadas apenas letras maiúsculas, números e undersco-
res( ), tendo necessariamente de começar por uma letra. A PARTIÇÃO que deverá ser
utilizada é especificada pela identificação que tem perante o sistema operativo. O comando
tem o formato ‘oracleasm createdisk NOMEDISCO PARTIÇ~ AO’.
# /etc/init.d/oracleasm createdisk VOL1 /dev/sdc1
# /etc/init.d/oracleasm createdisk VOL2 /dev/sdd1
# /etc/init.d/oracleasm createdisk VOL3 /dev/sde1
76 Protótipo
Nos outros pontos do cluster , foi validada a configuração efectuada através do co-
mando:
# /etc/init.d/oracleasm scandisks
Pode também ser questionado se uma determinada partição está a ser utilizada pelo
ASM através do comando:
# /etc/init.d/oracleasm querydisk /dev/sda3
Este processo efectuou-se a partir de um único servidor do cluster . Neste caso fez-se
desde o rac1.
Desactivou-se o controlo de acesso sobre o modo gráfico, pelo método já referido em
pontos anteriores (secção 7.19), de modo a que a aplicação pudesse ser executada.
Confirmou-se que em cada nó o SID definido era distinto e que o Clusterware nos
vários nós se encontrava activo. Usando a conta de utilizador oracle, desactivaram-se
as variáveis de ambiente ORACLE HOME e TNS ADMIN. Lançou-se o OUI em modo
gráfico para realizar a instalação do software.
# /u01/app/oracle/orainstall/database/runInstaller
8. Após ter sido efectuado em todos os nós do cluster , a sua execução teve de ser
indicada no assistente de instalação e então finalizou-se.
Para proceder a esta configuração é necessário ter acesso ao modo gráfico. Fez-se o
login como oracle. Através do modo gráfico, arrancou-se num dos nós o assistente de
configuração Oracle Net:
# netca &
5. Escolher um nome para o listener. Pode ser utilizado o valor LISTENER, que é
apresentado por omissão.
8. Indicou-se que não deve ser criado um Listener adicional e no final da configuração
clicou-se em “Next”.
Um erro reportado ao colocar o Listener em estado online num dos nós, representa
muito provavelmente um problema na configuração, possivelmente relacionado com
o VIP. Certificar que as interfaces de rede têm a configuração adequada. Caso seja
utilizado uma gateway, verificar que está acessı́vel (através do comando ping), pois
tal inacessibilidade pode traduzir-se num funcionamento irregular da rede virtual,
fundamental para o sucesso desta fase.
78 Protótipo
11. Depois de esperar pelo final do processo de configuração pôde-se sair da aplicação.
Pode-se verificar o sucesso desta configuração através de uma das seguintes instruções:
# ps -ef | grep -v grep | grep lsnr
# $CRS_HOME/bin/crs_stat -t
# netstat -anp | grep 1521
Pelo primeiro comando vemos se o processo está a correr, pelo segundo o estado do
serviço no registo, segundo os registos do Clusterware, e pelo terceiro vemos que o porto
especificado se encontra a ser utilizado pelo Listener.
Este processo foi efectuado apenas num dos nós, utilizando a conta de utilizador oracle
e através do modo gráfico, de acordo com o procedimento efectuado em pontos anteriores.
# dbca &
3. Selecção dos nós. Foram seleccionados todos os nós disponı́veis (rac1 e rac2).
6. Opções de gestão.
Foram utilizados os valores apresentados por omissão. A base de dados é configurada
com o Enterprise Manager. Poderá opcionalmente ser definido um endereço de email
para onde deverão ser enviadas as notificações respeitantes à gestão da base de dados
assim como poderá ser activado o serviço de cópias de segurança diárias, porém estas
facilidades não foram activadas.
Pode ser definida apenas uma para todas as contas de administração (opção utilizada,
adequada num âmbito de provas porém veemente desaconselhada para um ambiente
de produção).
Caso seja escolhida a opção que permite a distinção de passwords, deverão ser espe-
cificados os pares – password e confirmação – para os utilizadores SYS, SYSTEM ,
DBSNMP e SYSMAN.
8. Opções de Armazenamento.
A opção utilizada foi Automatic Storage Management (ASM).
10. Foi apresentado um ecrão onde seria feita a gestão dos grupos de discos (Disk Group).
Procedeu-se à criação de um novo Disk Group (secção 5.2.4, página 34), clicando em
“Create New”.
grupos, o que permite que perante uma incidência sobre um dos grupos possa
ser mantida uma resposta activa do serviço por parte do outro.
Foram apresentados como candidatos ao Disk Group presente os discos ASM
anteriormente criados na secção 7.20.3 (página 75).
Seleccionaram-se os discos membros: ORCL:VOL1 e ORCL:VOL2 (Deixou-
se o volume ORCL:VOL3 por seleccionar)
Tabela 7.5: Disk Group para armazenamento da BD: Escolha de discos membros.
Tabela 7.6: Disk Group para Flash Recovery Area: Escolha de discos membros.
Na janela de gestão dos grupos de discos, escolheu-se apenas o grupo para utilização
geral da BD (ORCL GRUP1) e clicou-se em “Next” para adoptá-lo como grupo
que contém a base de dados.
18. Antes de criar a instância da base de dados, foi apresentado o respectivo sumário.
Após a sua verificação, foi confirmada a criação.
No final, foi apresentada uma janela reportando a conclusão da criação, a partir da
qual poderia ser completado o processo de gestão das contas de utilizador de maneira
a desbloquear algumas delas e, se pretendido, alterar as respectivas passwords.
Ao sair da aplicação a instância foi iniciada juntamente com os respectivos serviços.
Capı́tulo 8
Outras Tarefas
Durante o perı́odo em que o projecto ia sendo desenvolvido, houve também uma co-
laboração activa com a secção de Infra-estruturas do departamento de informática em
algumas tarefas. Apesar de não estarem relacionadas com o projecto de um modo di-
recto, pela sua natureza, permitiram o contacto fı́sico com as plataformas sobre as quais
se debruçava o estudo levado a cabo.
Por outro lado, com a formação apreendida neste âmbito, caso se tivessem concretizado
as expectativas de se ter seguido com a implementação Oracle Real Application Clusters em
ambiente nativo, pela aprendizagem e familiarização em termos de conceitos, componentes
e equipamentos que daı́ resultou, alguns dos passos já estariam dados, pois segundo a
previsão inicial seria utilizado equipamento semelhante.
Houve um contacto com servidores Blade da Dell (PowerEdge 1855), executando a sua
instalação desde uma fase “bare-metal” com a montagem fı́sica no rack de servidores, até
ao estado de produção.
Figura 8.1: Rack de servidores Blade. Em destaque pode ver-se um dos servidores Blade
(limitado a laranja)
8.2 Citrix Metaframe 83
Nas máquinas onde foi aplicada esta prática o processo era composto por três fases:
• Clonagem
Tabela 8.1: Programas utilizados em cada uma das soluções Office, segundo o seu tipo. É
também referida a extensão dos ficheiros no formato tı́pico utilizado por cada um.
3
formato standard com especificação pública e aberta, desenvolvido pela OASIS (um consórcio de orga-
nizações internacional com fins não lucrativos), que pretende ser uma alternativa aos formatos proprietários
para documentos “Office”.
8.4 Open Office 85
8.4.1 Resultados
Write
Calc
Figura 8.2: OpenOffice – Calc – Acesso à base de dados DB2 de produção no AS/400. Na
parte superior é mostrado o conteúdo da base de dados, através das tabelas disponı́veis (no
lado esquerdo) e o conteúdo da tabela seleccionada (à direita). Em baixo está a folha de
cálculo, onde podem ser estabelecidas ligações com a base de dados.
Impress
A importação deste tipo de ficheiros foi geralmente feita de modo simples porém, de
igual modo, algumas alterações no formato exibido ou a exclusão de algum tipo de objectos
sucede nalgumas ocasiões.
De salientar a enorme quantidade de formatos para que podem ser exportados os
documentos utilizados por esta aplicação, que para além de PDF, permite a exportação
para o formato Flash, além de muitos outros.
A gravação em formato ppt desde esta aplicação, apesar de possı́vel, geralmente não
é feita correctamente já que nos testes feitos guardando o documento com este tipo, a
abertura do documento pelo PowerPoint não era bem sucedida, sendo o erro justificado
pelo não reconhecimento do formato.
Base
Nos casos testados ao efectuar esta ligação, a importação no seu essencial resultou no que
se refere às tabelas e dados nelas contidos, assim como a maioria de consultas criadas, por
vezes de modo incompleto, exigindo ao utilizador um esforço complementar e um nı́vel de
experiência avançado com a ferramenta para estabelecer manualmente algumas ligações
quebradas do esquema inicial.
Quanto aos formulários, os que provêm do Access não são suportados pelo Base.
Também em formato nativo se apresentaram menos completos já que, por exemplo, apenas
podem organizar-se num único nı́vel, não podendo criar-se sub-formulários de uma forma
hierarquizada.
Pela visita que foi feita à versão beta do MicrosoftOffice 2007 (figura 8.3), também
a sua adopção exigirá uma forte adaptação por parte do utilizador de versões anteriores,
dadas as sua diferenças com a actual versão, quer pela localização espacial das ferramentas
quer pela adopção de um novo modelo de funcionamento, muito mais gráfico.
8.4.2 Conclusões
A solução livre avaliada demostrou poder ser uma alternativa viável ao MicrosoftOffice
pela boa resposta nas funcionalidades que disponibiliza a um nı́vel de utilização simples
ou médio. Os principais pontos negativos encontrados concentram-se a um nı́vel de uti-
lização avançada e sobretudo com a frequente incapacidade na importação amena dos
88 Outras Tarefas
documentos das aplicações Microsoft, sobretudo quando são utilizados estruturas (como
tabelas, macros ou gráficos) mais complexas, reflexo de uma dificuldade em lidar com a
impermeabilidade do formato fechado que estas utilizam.
Sem dúvida que o preço é uma importante motivação para considerar a adopção de
uma solução open-source. Se reflectirmos sobre os principais entraves para uma migração
destre género, seguramente que um excessivo esforço a nı́vel da familiarização com uma
nova interface, causando uma quebra nos hábitos de funcionamento do “utilizador tipo”
ao efectuar as operações quotidianas e, por outro lado, uma resposta ineficaz ao nı́vel da
funcionalidade por parte do novo produto, se traduzirá num custo demasiado elevado nessa
adopção que não justificará a mudança. Neste caso não parecem ser estes os factores que
bloqueiam a transição, pois o frontend das aplicações no OpenOffice e nas aplicações Mi-
crosoftOffice é muito semelhante. No seu essencial, também as funcionalidades fornecidas
apresentam uma grande proximidade, apesar de uma maior consistência demonstrada na
solução da Microsoft, em que foram testemunhados menos bloqueios súbitos nas aplicações.
Considerando o cenário de uma implantação OpenOffice, um dos critérios essenciais
reside na boa capacidade de intercâmbio de documentos com o exterior, com parceiros
que potencialmente utilizam de forma massificada os formatos fechados MicrosoftOffice.
Até agora este critério não se encontra satisfeito dado ter sido precisamente no ponto da
importação e exportação destes formatos onde foram identificadas maiores dificuldades.
No entanto a Microsoft, que se encontrava até há pouco tempo estanque a qualquer
iniciativa no sentido de uma abertura ao formato standard, alterou de alguma maneira a
sua posição perante os pedidos de interoperabilidade por parte de algumas organizações
governamentais. Algumas delas com medidas efectivamente tomadas na transição para o
OpenOffice como software de produtividade adoptado (em França, Dinamarca, Espanha
ou ultimamente pelo governo do estado de Massachusetts). Em resposta a estes factos, a
Microsoft anunciou recentemente estar a colaborar num novo projecto de open source, alo-
jado na SourceForge (http://sourceforge.net/projects/odf-converter), que se encontra
a trabalhar no desenvolvimento de um tradutor que visa possibilitar a leitura e escrita
em formato ODF dos documentos editados no MicrosoftOffice 2007, através de um add-in
instalável gratuitamente.
Talvez esta medida proporcione a ponte entre as duas plataformas de modo a que a
escolha de uma solução de produtividade deste tipo por parte dos utilizadores se possa
basear em factores de qualidade e não num jogo de dependências.
Capı́tulo 9
Conclusões finais
Ajuda
# man Comando
Mostra a página de manual sobre um determinado Comando
# whatis Comando
Mostra quais as várias páginas de manual disponı́veis para Comando
# whereis Comando
Especifica qual a localização de um determinado Comando
# apropos Palavra
Indica que páginas do manual (man) fazem referência a uma dada Palavra
Informação de sistema
# uname -r
Diz qual é a versão do kernel usada
# cat /proc/version
Mostra versão do kernel presente
# cat /etc/issue
Mostra qual a distribuição Linux instalada
# lsmod
# cat /proc/modules
Informa sobre os módulos carregados no kernel
#modprobe -l
Lista os módulos presentes
Pesquisas
Permissões
# umask 022
Estabelece 755 como nı́vel de permissões por omissão.
Definido realizando operação Xor entre o valor que é inserido, ’022’, e a máscara ’777’
# passwd Utilizador
Procede à alteração da password do Utilizador referido
A.1 Comandos úteis 93
Rede
# ping Endereço_Destino
Verifica a ligação com o destinatário através do envio de pacotes ICMP
# ifconfig
Mostra informação acerca das interfaces de rede, assim como permite configurá-las
# netstat
Dá a lista de ligações estabelecidas
# route
Informação diversa sobre encaminhamento
# cat /proc/net/dev
# mii-tool
Dão informação relativa aos dispositivos de rede no sistema
Recursos
# cat /proc/cpuinfo
Apresenta informação sobre o processador
# top
Mostra um quadro com informação sobre o processamento actual
# free
Informa sobre a utilização de memória actual
# cat /proc/meminfo
Apresenta informação relacionada com memória
# iostat
Ferramenta de monitorização sobre dispositivos de armazenamento
# df -h
Indica qual a utilização feita das partições de disco
# lspci -vv
Lista as placas PCI presentes na máquina
94 Linux: “caderno de notas”
# export ORACLE_SID=orcl1
# srvctl start nodeapps -n rac1
# srvctl start asm -n rac1
# srvctl start instance -d orcl -i orcl1
# emctl start dbconsole
Iniciar ambiente RAC
# export ORACLE_SID=orcl1
# emctl stop dbconsole
# srvctl stop instance -d orcl -i orcl1
# srvctl stop asm -n rac1
# srvctl stop nodeapps -n rac1
Encerrar ambiente RAC
# lsnctl start|stop|status
Inicia, termina ou verifica o estado do Listener
Vários
# file *
Informa de que tipo são os ficheiros
# crontab -e (editar)
# crontab -r (retirar)
Permite calendarizar o lançamento de programas com uma frequência configurável.
Configuração guardada em /var/spool/cron/tabs/Utilizador
# shutdown -h now
Ordena o encerramento imediato do sistema
# pwd
Indica qual a directoria actual
# vi /etc/sysctl.conf
# vi /etc/rc.local
Definir serviços lançados no arranque do sistema
# cat /var/log/messages
# cat /var/log/dmesg
Mostra mensagens lançadas pelo kernel
# strace -p Pid
Monitoriza as chamadas de sistema feitas por um determinado processo
# cat /proc/interrupts
Contador de interrupções do sistema operativo (entrada 0 refere-se ao relógio)
# ulimit -a
Limites de ambiente impostos ao utilizador actual
# telinit 3
Provoca a mudança para o runlevel 3
# ssh -X user@hostname
Cria um túnel seguro com possibilidade de forwarding para aplicações gráficas
# ln -s Fitxer.txt Ligacao.lnk
96 Linux: “caderno de notas”
# xhost +[<Endereço_Remoto>]
# xhost -[<Endereço_Remoto>]
Habilita/desabilita o controlo de acesso para servidor X.
Pode-se habilitar/desabilitar apenas um endereço especı́fico
# Comando --display=122.133.132.123:0.0
# export DISPLAY=123.123.123.123:0.0; Comando;
Executa um dado Comando e apresenta-o remotamente (no servidor X indicado)
# ps -ef
Mostra todos os processos que se encontram a correr na máquina
# w
# who
Apresenta os utilizadores que têm sessões abertas e que programas estão a correr
# chkconfig ntpd on
Verifica para que runlevels o serviço ”ntpd”está activo
# pgrep ntpd
Indica os identificadores dos processos que correm o ntpd
# chkconfig -l
Lista que scripts estão activados para iniciar nos diferentes runlevels
# mkswap -f /dev/hda5
Prepara a partição para ser usada como Swap
# swapon /dev/hda5
Activa a partição referida como espaço Swap
# sysctl -p
Define todas as variáveis de sysctl.conf em proc/
# mount -a
Monta todos os dispositivos constantes no ficheiro /etc/fstab
# chroot Directoria
Altera a directoria tida como raı́z. Útil no restauro do Lilo
Índice
[3] A. Singh, Oracle 10g R2 (10.2.0.1) on Suse Linux Enterprise Server 9 (How to
Install). Novell, Julho, 2005.
http://ftp.novell.com/partners/oracle/docs/10gR2_sles9_install.pdf.
[4] S. Daniel, NAS vs. SAN for Database Applications Using NAS Protocols with
Databases. Network Appliance, Fevereiro, 2003.
http://www.netapp.com/library/tr/3227.pdf.
[5] A. Firebaugh, A. Robinson and T. Patel, Oracle10g real application clusters release
1: Installation with a filer in a suse linux enterprise server 8/9 (sles 8, sles 9)
environment, tech. rep., Network Appliance, Julho, 2005.
http://www.netapp.com/library/tr/3413.pdf.
[6] K. McGowan and R. Knapp, Oracle Real Application Clusters Best Practices On
Linux. Oracle Corporation.
http://web51-01.oracle.com/owparis_2003/50136_McGowan.doc.
[8] VMware, Systems Compatibility Guide for ESX Server 2.x, Maio, 2006.
http://www.vmware.com/pdf/esx_system_guide.pdf.
[9] VMware, Using ESX Server and VirtualCenter to Reduce Oracle Real Application
Clusters Deployment Costs And Cycle Times, 2004.
http://www.vmware.com/pdf/esx_vc_oracle.pdf.
[11] B. Martelli and G. Peco, LCG 3D and Oracle Cluster, Março, 2006.
http://agenda.pi.infn.it/askArchive.php?base=agenda&categ=a06133&id=
a06133s4t26/transparencies.
[12] R. Kulkarni and P. Schay, Linux Filesystem Performance Comparison for OLTP
with Ext2, Ext3, Raw, and OCFS on Direct-Attached Disks using Oracle 9i Release
BIBLIOGRAFIA 99
[14] Oracle Corporation, Oracle Cluster File System (OCFS2) Users Guide. http:
//oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_users_guide.pdf.
[17] M. E. Matsunaga, Oracle Cluster FileSystem for Linux (Users Guide). Oracle
Corporation, Agosto, 2003.
http://oss.oracle.com/projects/ocfs/dist/documentation/OCFS_Users_Guide.doc.
[18] S. Poon and G. Verstraeten, Oracle 10g R2 RAC Implementation on xSeries. IBM
Corporation, Janeiro, 2006. http://www-03.ibm.com/solutions/businesssolutions/
oracle/doc/content/bin/Oracle_10g_R2_RAC_xSeries-Jan2006.pdf.
[19] V. Ravipati and A. Zavery, Oracle Application Server 10g : The Best Application
Server for the Oracle Database. Oracle Corporation, Dezembro, 2004.
http://www.oracle.com/technology/products/ias/pdf/oracleas10g_best_appserver_
for_oracledatabase_wp.pdf.
[20] R. Rossebo, Best Practices for 10g RAC. Oracle Corporation, Dezembro, 2005.
http://www.oracleracsig.org/pls/htmldb/Z?p_url=RAC_SIG.download_my_file?p_
file=1000480&p_cat=1000480&p_company=550311706566234.
[21] Z. Afrookhteh, Technical Comparison of Oracle Real Application Clusters 10g vs.
IBM DB2 UDB v8.2. Oracle Corporation, Agosto, 2005.
http://www.oracle.com/technology/products/database/clustering/pdf/twp_rac_
10g_vs_db2_v8.2%5B1%5D.pdf.
[22] Oracle Corporation, Your Desktop Data Center: Oracle Database 10g on SuSE
Linux on VMware Evaluation, Fevereiro, 2005. http:
//www.oracle.com/technology/tech/linux/vmware/readme_desktop_suse_v14.pdf.
[23] M. Newman, C.-M. Wiberg and B. Braswell, Server Consolidation with VMware
ESX Server. IBM Corporation, Janeiro, 2005.
http://www.redbooks.ibm.com/redpapers/pdfs/redp3939.pdf.
[27] J. Tate, R. Kanth and A. Telles, Introduction to Storage Area Networks. IBM
Corporation, Abril, 2005.
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245470.pdf.
[32] D. Patel, Storage File Mapping in Databases. Veritas Architect Network, Abril,
2003. http://sysdoc.doors.ch/VERITAS/2867.pdf.
[33] Hewlett-Packard Company, Using ServiceGuard Extension for Real Application
Cluster (RAC), Junho, 2003. http://docs.hp.com/en/T1859-90006/T1859-90006.pdf.
[34] S. Behlert, F. Bodammer, S. Dirsch, O. Donjak, R. Drahtmüller, T. Duwe,
T. Dubiel, T. Fehr, S. Fent, W. Fink, K. Garloff, C. Groß, J. Gleißner,
A. Grünbacher, F. Hassels, A. Jaeger, K. Kämpf, H. Mantel, L. Marowsky-Bree,
J. Meixner, L. Müller, M. Nagorni, A. Nashif, S. Olschner, P. Pöml, T. Renninger,
H. Rommel, M. Schäfer, N. Schüler, K. Singvogel, H. Vogelsang, K. G.Wagner,
R. Walter and C. Zoz, Suse Linux Enterprise Server - Installation And
Administration. Suse Linux Ag., 9 ed., 2004. http://www-uxsup.csx.cam.ac.uk/pub/
doc/suse/sles9/SUSE-LINUX-Enterprise-Server-9-Adminguide.pdf.
[35] D. G. Pfeifer, Optimizing Kernel 2.6 and SLES9 for the best possible performance.
Novell. http://www.novell.com/brainshare/europe/05_presentations/tut303.pdf.
[36] G. Smith, Oracle RAC 10g Overview - An Oracle White Paper. Oracle Corporation,
Novembro, 2003.
http://www.oracle.com/technology/tech/windows/wp/Oracle_DB_10g_RAC_WP.pdf.
[38] Red Hat, Inc., Red Hat Enterprise Linux 4: Introduction to System Administration,
2005. http:
//www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-isa-en.pdf.
[40] VMware, Inc., Accelerate Software Development Testing and Deployment with the
VMware Virtualization Platform, 2005. http://www.vmware.com/pdf/dev_test.pdf.
[41] VMware, ESX Server 2 - Best Practices, 2003.
http://www.vmware.com/pdf/esx2_best_practices.pdf.
[42] VMware, Inc., VMware ESX Server 2 - ESX Server Performance and Resource
Management for CPU-Intensive Workloads, 2005.
http://www.vmware.com/pdf/ESX2_CPU_Performance.pdf.
[43] VMware, Inc., ESX Server 2 - NIC TEAMING IEEE 802.3ad, 2003.
http://www.vmware.com/pdf/esx2_NIC_Teaming.pdf.
[47] S. Calish, Guide to linux filesystem mastery, tech. rep., Oracle, Novembro, 2004.
http://www.oracle.com/technology/pub/articles/calish_filesys.html.
[49] M. Ault, D. Liu and M. Tumma, Oracle Database 10g New Features. Novembro,
2003. http://www.remote.dba.cc/10g_409.html.
[50] L. Morris-Murphy, Storage on Automatic. http://www.oracle.com/technology/
oramag/webcolumns/2003/techarticles/murphy_asm.html.
[52] M. Ault and M. Tumma, Oracle 10g Grid & Real Application Clusters. Rampant
Techpress, Maio, 2004.
[53] B. Lundhild, Oracle Real Application Clusters 10g – An Oracle White Paper. Oracle
Corporation, Maio, 2005. http://www.oracle.com/technology/products/database/
clustering/pdf/twp_rac10gr2.pdf.
[54] A. Das, S. Sharma and L. Vadassery, Oracle Database Installation Guide 10g
Release 2 (10.2) for Linux x86. Oracle, 2005.
http://download-east.oracle.com/docs/cd/B19306_01/install.102/b15660.pdf.
[55] C. McGregor, Oracle Database 2 Day DBA 10g Release 2 (10.2). Oracle, Dezembro,
2005.
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14196.pdf.
[56] VMware, Inc, ESX Server 2.5 Administration Guide, Março, 2005.
http://www.vmware.com/pdf/esx25_admin.pdf.
102 BIBLIOGRAFIA
[57] VMware, Inc, ESX Server 2.5 Installation Guide, Março, 2005.
http://www.vmware.com/pdf/esx25_install.pdf.
[58] VMware, Inc, ESX Server 2.5 Release Notes, Abril, 2006.
http://www.vmware.com/support/esx25/doc/releasenotes_esx253.html.
[59] VMware, Inc, Storage Subsystem Performance in VMware ESX Server: BusLogic
Versus LSI Logic, Abril, 2006.
http://www.vmware.com/pdf/ESX2_Storage_Performance.pdf.
[60] J. Hunter, Build your own oracle rac 10g cluster on linux and firewire, tech. rep.,
Oracle, Março, 2005.
http://www.oracle.com/technology/pub/articles/hunter_rac.html.
[61] D. Austin, M. Bauer and D. Williams, Oracle Clusterware and Oracle Real
Application Clusters Administration and Deployment Guide. Oracle, Janeiro, 2006.
http://download-east.oracle.com/docs/cd/B19306_01/rac.102/b14197.pdf.
[64] Blade Infrastructure Solution Center, VMware ESX 2.1 NIC Bonding and VLANs
On BladeCenter HS20, Março, 2004.
http://www.vmware.com/pdf/esx21_IBM_NIC_VLAN.pdf.
[65] VMware, Inc., VMware ESX Server Using Raw Device Mapping, 2005.
http://www.vmware.com/pdf/esx/esx25_rawdevicemapping.pdf.
[66] VMware, Inc., Systems Compatibility Guide for ESX Server 2.x, Mayo, 2006.
http://www.repton.co.uk/library/Storage/esx_systems_guide.pdf.
[70] Red Hat, Inc., Red Hat Enterprise Linux Performance Tuning Guide, 2004.
http://people.redhat.com/mbehm/RHEL_Tuning_Guide.pdf.
[72] VMware, Inc., VMware ESX Server 2 - Architecture and Performance Implications,
2005. http://www.vmware.com/pdf/esx2_performance_implications.pdf.
BIBLIOGRAFIA 103
[73] Oracle Corporation, Quick Installation Guide - 10g Release 1 (10.1.0.3) for Linux
x86, Outubro, 2004.
http://ftp.portera.com/Linux/SLES9-x64-ORA10/10gR1_sles9_install.pdf.
[74] K. Mensah, Whats New for Java DB, JDBC, and Database Web Services in Oracle
Database 10g. Oracle Corporation, Maio, 2005.
http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/twp_appdev_jav%a_
whats_new_4_java_jdbc_web_services.pdf.
[75] J. E. Koerv, Deploying Oracle 10g on Red Hat Enterprise Linux v.3. Red Hat, Inc.,
Abril, 2004. http://www.redhat.com/f/pdf/rhel/WHP0007USOracle10g.pdf.
[78] K. Weidner, Common Criteria EAL4+ Evaluated Configuration Guide for SUSE
LINUX Enterprise Server on IBM Hardware. Atsec, Janeiro, 2005.
http://www.uniforum.chi.il.us/slides/HardeningLinux/
IBM-SLES-EAL4-Configuration-Guide.pdf.
[79] Novell, What’s New in Suse Linux Enterprise Server 9, Julho, 2004.
http://www.novell.com/products/linuxenterpriseserver/sles9_whatsnew.pdf.
[81] P. Huey, Oracle Database Installation Guide 10g Release 1 (10.1.0.2.0) for
Windows. Oracle Corporation, Setembro, 2004.
http://download-uk.oracle.com/docs/pdf/B10130_02.pdf.
[82] Oracle Corporation, Oracle Database Quick Installation Guide 10g Release 1
(10.1.0.2.0)) for Windows, Março, 2004.
http://download-uk.oracle.com/docs/pdf/B13669_01.pdf.
[83] Red Hat, Inc., Red Hat Enterprise Linux 4 Introduction to System Administration,
2005. http:
//www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-isa-en.pdf.
[84] P. Rad, R. Rajagopalan, T. Michael and J. Kozak, Best Practices for Oracle
Database 10g - Automatic Storage Management on Dell/EMC Storage. Dell, Inc.,
Outubro, 2004.
http://www.dell.com/downloads/global/power/ps4q04-20040150-Rad.pdf.
[85] Z. Mahmood, A. Fernandez, B. Scalzo and M. Vallath, Testing Oracle 10g RAC
Scalability on Dell PowerEdge Servers and Dell/EMC Storage. Dell, Inc., Fevereiro,
2006. http://www.dell.com/downloads/global/power/ps1q06-20050300-Quest.pdf.
[87] P. Newlan, Using Oracle Clusterware to Protect 3rd Party Applications. Oracle
Corporation, Maio, 2005. http://www.oracle.com/technology/products/database/
clustering/pdf/twp_oracleclusterware3rdparty%5B1%5D.pdf.
[88] Oracle Corporation, Oracle Cluster File System (OCFS2) User’s Guide. http:
//oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_users_guide.pdf.
[89] Red Hat, Inc., Red Hat Enterprise Linux - Performance Tuning Guide, 2004.
http://people.redhat.com/mbehm/RHEL_Tuning_Guide.pdf.
[90] Oracle Corporation, Orion: Oracle I/O Numbers Calibration Tool. http:
//oraclelon1.oracle.com/otn/utilities_drivers/orion/Orion_Users_Guide.pdf.