sexta-feira, 2 de janeiro de 2015

Tudo (ou quase tudo) que você queria saber sobre licenciamento Oracle e não tinha para quem perguntar

A escolha da melhor tecnologia para atender as suas necessidades em meio a um mercado tão veloz e competitivo é um grande desafio. Se tratando de software então, não basta escolher o melhor produto, mas também escolher a melhor forma de comprá-lo a fim de maximizar o investimento.
No meu dia-a-dia eu vejo muita dificuldade de gestores de TI em entender os conceitos de licenciamento dos mais diversos fornecedores. Como não existe um padrão de mercado é importante estar atento aos nuances de cada fornecedor para não cair em irregularidades.
A fim de facilitar a vida de clientes e parceiros, vou consolidar neste artigo algumas informações bem relevantes na hora de tomar a decisão para o melhor investimento.

O guia prático de licenciamento da Oracle

Sabendo que os clientes têm dificuldades em entender as regras de licenciamento, a Oracle elaborou um manual de licenciamento, chamado Software Investment Guide (SIG), que contém as explanações básicas sobre as métricas de licenciamento para os diferentes tipos de produtos e cenários. Regras bastante polêmicas de licenciamento como failover, stand by, backup, quantidade de usuários e etc. estão explicadas de forma detalhada e com vários exemplos de aplicações destas regras em cenários semelhantes ao mundo real.
No link abaixo, além do SIG você também vai encontrar uma planilha de controle de inventário de licenças que já vem preparada com as métricas e produtos da Oracle. Seu uso não é obrigatório, mas ajuda bastante quando não há nenhum outro tipo de controle.

Principais pontos sobre licenciamento Oracle

A Oracle hoje possui uma gama muito vasta de produtos e serviços, que vai muito além da visão tradicional de que a Oracle é uma empresa de banco de dados. Hoje a Oracle possui em seu portfólio produtos que vão desde a camada de aplicação, passando por middleware, banco de dados, virtualização, sistema operacional, servidores e até storage.
Por isso, quando vamos checar a forma de licenciar um produto, precisamos estar atentos que cada linha de produto possui uma forma específica de licenciamento. Como os pontos mais polêmicos são com relação ao licenciamento de banco de dados, é neste tópico que eu vou focar, mas o SIG está aí para falar também sobre os demais produtos.
O primeiro ponto na escolha do software de banco de dados a ser licenciado é a escolha da funcionalidade desejada. Dependendo das necessidades da empresa em termos de negócio uma ou outra tecnologia pode ser mais adequada. O banco de dados Oracle é comercializado de acordo com a disponibilidade destes recursos para atender necessidades especifícias.
A versão mais básica do banco de dados Oracle é a versão Express (também conhecida como XE). O Oracle XE é gratuíto, porém é o que possui menos recursos e têm maiores limitações em termos de hardware. Independente da máquina onde estiver rodando, ele fica limitado a utilizar apenas um núcleo (core) de processador e 1 GB de memória RAM.
Oracle Standard Edition One (SE1) é a versão comercial entry-level do banco de dados, ele é limitado a rodar num hardware com no máximo 2 (dois) processadores físicos (sockets) e não tem opção de fazer cluster (funcionalidade onde duas ou mais máquinas trabalham em paralelo sobre o mesmo banco de dados).
Oracle Standard Edition (SE), por sua vez, possui o limite de hardware de até 4 processadores físicos (sockets) e tem a possibilidade de fazer cluster através do Oracle RAC (Real Application Clusters). Note que ao optar por utilizar o RAC, continua valendo o limite de 4 processadores para o cluster inteiro (exemplo: duas máquinas com dois processadores).
Finalmente, o banco Oracle Enterprise Edition (EE) é o produto top de linha desta categoria, contendo inúmeras características que o torna ideal para negócios extremamente críticos e dinâmicos. Somente com o Oracle Enterprise Edition você pode garantir alta disponibilidade e continuidade de negócios com zero perda de dados e downtime zero ou próximo de zero. Logo, ele é adequado para empresas que não podem parar (operam 24x7) e também não podem correr risco de perder os seus dados. Isto é, claro, entre outras características como melhor performance, segurança e escalabilidade.
Em termos de licenciamento, o Oracle Enterprise Edition possui uma métrica diferenciada. O processador do EE é calculado de acordo com o número de núcleos (cores) que a máquina possui, aplicado um fator de conversão que é tabelado. Fica mais fácil de entender na prática:
Vamos pegar como exemplo um servidor padrão de mercado hoje, com dois processadores x86 octa-core (8 cores cada, 16 cores no total). O fator de conversão para x86 é 0,5. Logo, o número de processadores a serem licenciados de banco EE é 16 (total de cores) x 0,5 (fator x86) = 8 processadores. (Note que a mesma máquina em SE1 ou SE necessitaria de 2 (duas) licenças de processador)
Para conhecer todos os fatores de conversão, basta consultar a tabela Oracle Processor Core Factor Table. Hoje, os mais relevantes são: 0,5 para x86 e SPARC e 1,0 para processadores RISC não-Oracle.

Licenciamento por Usuários Nomeados (Named User Plus)

Além do licenciamento por processador, algumas linhas de produtos podem ser licenciadas por usuários nomeados, os chamados Named User Plus. Para a linha de produtos de banco de dados, isto também é possível, desde que se considere as seguintes regras:
  1. Usuários humanos e não-humanos precisam ser contáveis (ex.: 30 sensores + 400 operadores)
  2. Existem quantidades mínimas de usuários que precisam ser respeitadas, que variam por produto. Para os produtos banco de dados SE1 e SE, o mínimo de usuários nomeados é 5 por processador. Para o banco de dados EE, o mínimo é 25 usuários por processador.
  3. Para calcular os mínimos, primeiro calcula-se o número de licenças de processador necessárias para o hardware específico e depois aplicam-se os multiplicadores de cada produto.
  4. Se o número de usuários contados for maior que o mínimo, licencia-se por usuários contados. Se não, licencia-se pelo mínimo calculado.
Considerando a máquina de referência do exemplo acima, 2 processadores físicos com 8 cores cada um, os mínimos respectivos são:
SE e SE1: 2 processadores x 5 usuários = 10 usuários nomeados
EE: 2 processadores x 8 cores x 0,5 (fator x86) x 25 usuários = 200 usuários nomeados

Tópicos Especiais de Licenciamento

Os cenários de licenciamento descritos acima vão cobrir a maioria dos casos que encontramos no dia-a-dia. No entanto, a medida que precisamos fazer usos mais avançados do software a complexidade da solução aumenta e as regras precisam ser extendidas para contemplar esta nova complexidade. Dois tópicos muito quentes são o licenciamento de disaster recovery e o licenciamento de ambientes virtualizados.
Com relação ao disaster recovery (DR), entendemos por isso um ambiente onde exista o banco de dados Oracle instalado pronto para assumir a carga do ambiente de produção caso ocorra um evento que indisponibilize o mesmo. Ou seja, é um conjunto de hardware e software adicional que através de alguma forma de replicação mantém uma cópia do banco de dados para eventos de desastres ou outros tipos de paradas, sejam estas planejadas ou não planejadas. Todo servidor onde houver o software da Oracle instalado precisa ser licenciado logo, sim, é preciso licenciar o site DR.
Uma pergunta muito comum é: posso licenciar o site de produção por processador e o DR por usuário? A resposta é não. Independente do tipo de replicação utilizado, se a finalidade é DR, os servidores precisam obrigatoriamente seguir a mesma métrica. Agora se estivessemos falando de ambientes distintos, como por exemplo, produção e homologação ou QA, aí sim, neste caso pode ser licenciado produção por processador e homologação por usuários. Para esclarecer de uma vez por todas as regras de licenciamento de sites de disaster recovery, backup, etc, incluindo esta e outras regras, o documento oficial é o Licensing Data Recovery Environments.
Sobre o tema de virtualização, gostaria de destacar que é preciso tomar muito cuidado com este tópico, em especial para não ficar irregular. Todo processador que roda o código Oracle precisa ser licenciado. Isso fica bem fácil de entender vendo um servidor bare metal, onde todo o processamento fica disponível para o banco de dados e com isso toda a máquina precisa ser licenciada. Agora, em ambientes virtualizados, nem sempre temos o controle sobre quais processadores vão executar quais tarefas, podendo elas estar distribuidas em múltiplos servidores em momentos distintos - a exemplo da tecnologia de live migration. Nestes casos, farms de VMs, onde o banco pode estar executando hora em uma máquina, hora em outra, é necessário licenciar TODA a farm de VMs. Sim, toda. Mesmo que você esteja usando só 2 processadores de cada vez.
Existem exceções a esta regra? Sim. Quando a tecnologia de virtualização tem a capacidade de fazer o chamado hard partitioning ou "CPU pin", ou seja, fixar a execução da VM em um determinado core ou grupo de cores, como se efetivamente estivéssemos "fatiando" uma máquina. Note que não são todas as tecnologias de virtualização que suportam isso, e mesmo que as que suportam, precisam ser homologadas pela Oracle para que o licenciamento seja válido. Esta regra pode ser vista na íntegra no documento Partitioning (não confundir com a option de banco Partitioning, este partitioning se refere a divisão de uma máquina física em máquinas virtuais menores).
A documentação completa sobre os tópicos especiais (além dos dois previamente citados) pode ser encontrada no site da Oracle, na seção Specialty Topics.

Palavras Finais

Ok, talvez meu título tenha sido (um pouco) enganatório. Mas o objetivo era chamar a atenção para estes tópicos de licenciamento que são bastante polêmicos e muito comuns de encontrarmos no dia-a-dia. Vale lembrar também que regras de licenciamento são muito dinâmicas e podem variar ao longo dos anos, então por este motivo fiz questão de apontar sempre as referências oficiais, assim mesmo que este texto algum dia fique desatualizado, aí estão os links para a consulta do material direto na fonte.

terça-feira, 30 de dezembro de 2014

Princípios Básicos de Segurança da Informação

Eu lembro que na minha infância costumava se falar muito aquele ditado popular "tempo é dinheiro". Talvez porque naquela época as coisas eram bem mais difíceis... os meios de transportes não eram tão evoluídos (viajar de avião, por exemplo, era uma fortuna), os meios de comunicação idem (telefones fixos custavam o preço de um carro novo e celulares eram aparatos de filmes de ficção científica), então se gastava muito tempo para realizar algumas tarefas que hoje são triviais. A tecnologia encurtou as distâncias e tornou viáveis uma infinidade de novas possibilidades. Hoje mandamos uma mensagem de um lado para o outro do mundo em segundos, quando antes levava meses.
Não obstante, hoje, tempo ainda é dinheiro. Mas talvez mais importante que isso, na era digital, informação é dinheiro. Vivemos num mundo de empresas cada vez mais dependentes de tecnologia, e sobretudo, de seus dados. Devido a toda essa evolução tecnológica encurtando as distâncias, a informação consegue fluir muito rápido e, quando se trata de uma informação crítica para o negócio, é preciso fazer de tudo para que ela não encontre um caminho rápido até as mãos da concorrência.
Na prática, no entanto, vejo muitas empresas não tomarem as devidas precauções com a segurança. O problema, na maioria dos casos, é que uma falha de segurança tem geralmente proporções intangíveis, ou seja, não é possível delimitar um impacto financeiro e nem mesmo dar a certeza de que um dia vai acontecer. Quando se trata de segurança, sempre estamos falando no conceito de risco. Fazer um investimento para mitigar um risco (em contrapartida a uma certeza), não costuma ser muito simples de justificar, exceto quando as companhias já vivenciaram um problema antes.
Outro motivo que tende a minimizar os investimentos em segurança é a própria falta de conhecimento dos profissionais sobre as ferramentas disponíveis no mercado e sobre as regulamentações e normas existentes no setor. O restante deste artigo vou me dedicar a estes dois aspectos.

Regulamentação

As normas que regem o domínio da segurança da informação estão consolidadas na série ISO 27000. Em linhas gerais, a série 27000 especifica a uma estrutura para gerenciamento de segurança da informação para qualquer organização, seja esta pública ou privada, de pequeno ou grande porte.
A ISO/IEC 27000 propriamente dita constitui uma visão geral da família 27000, além de definir um glossário dentro do escopo da Tecnologia da Informação e da gestão da segurança da informação, para melhor entendimento das demais normas que constituem o conjunto.
ISO/IEC 27002:2007 é a norma de Segurança da Informação, que por motivos históricos muitas vezes é referenciada por ISO/IEC 17799:2005, a sua numeração anterior. Ela foi publicada originalmente em 2000, sendo então uma cópia fiel do padrão britânico (BS 7799-1:1999), e passou por uma revisão em 2005 para se adaptar ao mercado internacional.

Objetivos de Segurança

A segurança da informação estabelece alguns princípios básicos que precisam ser “forçados” para garantir a proteção dos dados. Estes princípios, também conhecidos como atributos, objetivos ou propriedades (entre outros), regem o foco das políticas de segurança e as funcionalidades que as ferramentas de tecnologia dispõe para controla-los.
O coração da segurança da informação costuma ser definido pela tríade clássica: confidencialidade, integridade e disponibilidade. A medida que o estudo desta área foi evoluindo, diversos autores e comitês propuseram princípios adicionais. A ISO/IEC 27002:2007 define, além da tríade clássica, os princípios da autenticidade e da irretratabilidade (ou não repúdio). Resumidamente, os 5 princípios regem sobre os seguintes aspectos:
  • Confidencialidade: o acesso a informação deve ser permitido apenas as entidades autorizadas.
  • Integridade: a informação deve ser preservada da forma como o seu proprietário a definiu e/ou modificou, durante todo o seu ciclo de vida, sendo protegida contra modificações não autorizadas ou não detectadas.
  • Disponibilidade: a informação deve estar acessível aos usuários autorizados ao seu acesso sempre que necessário.
  • Autenticidade: garantia de que a informação é genuína e que os sujeitos autorizados que a modificaram, ao longo do seu ciclo de vida, são realmente quem dizem ser (e não um terceiro impersonando um sujeito autorizado).
  • Irretratabilidade (não-repúdio): é a impossibilidade de negar a autoria de uma transação realizada anteriormente sobre um determinado conjunto de dados

Políticas de Segurança

Para cumprir com os objetivos de segurança é necessário ter uma política de segurança bem definida. Conforme a RFC 2196 – Site Security Handbook – uma política de segurança é uma declaração formal das regras as quais as pessoas que possuem acesso a informações e tecnologia de uma organização devem respeitar. O principal propósito de uma política de segurança é informar aos usuários, equipe e gerentes de suas obrigações para proteger os bens da companhia, sejam estes bens informações ou tecnologia.
A política deve especificar os mecanismos pelos quais estes requisitos são cumpridos. Para que a política seja eficiente, todos os procedimentos precisam ser documentados e estarem prontamente disponíveis a todos os atores, cada qual com o seu papel muito bem definido. Além disso, ferramentas precisam ser implementadas para garantir as regras e sansões precisam ser definidas onde as ferramentas não conseguem proteger o bem automaticamente.
Note que, neste processo, grande ênfase é dada ao papel das pessoas. Em contrapartida, as ferramentas têm um papel importante, porém não tem valor se não forem operadas e implementadas corretamente. Nada vale um sistema de segurança em uma empresa onde, por exemplo, para não esquecer a senha o funcionário deixa um post-it com suas senhas coladas no monitor. Sim, isso acontece.
Mas de qualquer forma, as ferramentas de tecnologia desempenham um papel fundamental no controle da informação e na garantia de que as propriedades básicas sejam asseguradas. Sem a tecnologia apropriada, hoje, é impossível manter o controle do volume de informações que transitam entre os mais diversos sistemas que compõem a infraestrutura das empresas.

Tipos de Controles na Tecnologia de Informação

Nos voltando agora para a tecnologia da informação, podemos classificar os mecanismos que temos para atuar sobre a segurança da informação em dois níveis básicos de controle: o controle preventivo, ou seja, os mecanismos que temos para prevenir que uma ação mal intencionada seja efetuada e, o controle reativo, aquele que nos permite agir mediante uma falha de segurança.
Quando entramos a fundo nas regulamentações de mercado no que tange a tecnologia, é comum encontrarmos a divisão do controle da TI em dois domínios: o domínio das aplicações e o domínio geral, que seria correspondente ao domínio da infraestrutura.
O domínio das aplicações é regido pelo acesso dos usuários aos aplicativos corporativos. Geralmente as próprias aplicações possuem algum tipo de controle para que apenas usuários autorizados tenham acesso às informações, porém algumas ferramentas específicas de TI tendem a melhorar este controle fornecendo algumas facilidades, como por exemplo, o Single Sign-On (SSO) ou outras modalidades de gerenciamento de acesso e controle de chaves.
Logo, no domínio das aplicações consideramos um risco o acesso de pessoas não autorizadas pela própria camada de aplicação, seja pela incorporação de uma identidade (ex.: roubo de senha, personificação ou fraude) ou por uma falha no controle de acesso (ex.: um funcionário demitido com credenciais ainda válidas).
No domínio geral, ou infraestrutura, os pontos de risco são mais amplos. Pensando em segurança da informação, o objeto mais crítico é o banco de dados, onde todas as informações das aplicações estão armazenadas. Como pontos chave para falhas de segurança temos desde a comunicação entre os servidores de banco de dados e de aplicação (camada de rede), o acesso direto aos dados (via sistema operacional), o acesso irrestrito de usuários privilegiados e, finalmente, a exposição indevida de dados críticos a desenvolvedores de sistema.
Permitam-me elaborar um pouco sobre cada um deles, e as maneiras de proteger-se contra cada um destes riscos:
1) Comunicação entre aplicação e banco de dados: toda e qualquer comunicação entre computadores está sujeita ao que chamamos de “sniffing” ou “packet capture”, entre outros termos, que nada mais é a interceptação das informações transmitidas de ponto a ponto por um software terceiro. Uma forma de se proteger deste tipo de ataque é através da criptografia, pois assim mascaramos os dados transmitidos de uma ponta a outra e sem a chave o terceiro não consegue decodificar a mensagem.
2) Acesso direto aos dados: semelhante ao item anterior, se os dados são armazenados “planos” (sem criptografia), não importa quantas camadas de segurança e autenticação você coloque, uma pessoa com acesso a uma cópia do banco de dados pode acessar todas as informações contidas nele com um grau moderado a leve de dificuldade. Imagine o cenário onde, por exemplo, que o “motoboy” que vai levar as fitas de backup para o cofre perde uma destas fitas ou é roubado. Ou um sysadmin mal-intencionado faz uma cópia dos datafiles do banco. A criptografia também é a solução para estes problemas.
3) Acesso irrestrito de usuários privilegiados: administradores de banco de dados (DBAs) geralmente são profissionais com o mais alto nível de acesso em uma infraestrutura de banco de dados. Isto se deve a própria característica do trabalho, pois, eles devem ter o poder tanto de criar como, literalmente, destruir o banco. Mas deveriam eles ter acesso às informações contidas no banco? Não necessariamente. Por exemplo, um DBA não deveria ter acesso a uma tabela de salários em um sistema de RH. Na prática, muitos têm. A forma de controlar isso depende muito de banco para banco.
4) Exposição de dados críticos a desenvolvedores de sistemas: também de nada adianta tomar todas as precauções com a segurança - criptografia, controle de acesso e limitação de usuários privilegiados - se deixamos os dados de produção completamente expostos no ambiente de desenvolvimento. É muito comum criarmos massas de dado para desenvolvimento e testes a partir dos dados de produção, mas nestes ambientes secundários os mecanismos de segurança são mais relaxados ou inexistentes. Em decorrência disso, qualquer desenvolvedor com acesso direto ao banco pode ter acesso a dados que jamais deveria ter conhecimento. Aí mais uma vez para ilustrar uso o exemplo do sistema de RH, onde o salário de todos os funcionários está exposto. Mas não só isso, poderiam ser informações estratégicas de negócio da própria empresa ou de uma empresa cliente. Um risco este que pode ser mitigado através da estratégia de mascaramento de dados, descaracterizando os dados sensíveis de maneira irreversível, mas mantendo suas características relacionais para que testes permaneçam válidos.

A tecnologia Oracle voltada para a segurança

Como especialista em Oracle eu não poderia deixar de indicar as tecnologias que a Oracle tem para endereçar cada uma destas necessidades.
Para trabalhar com controle no domínio das aplicações, a Oracle dispõe da suíte deIdentity Management (IDM). Esta é uma suíte completa que inclui produtos para controle de acesso, gestão de identidade, single sign-on, governança, serviços de diretório, mobile e etc.
Já para trabalhar no domínio geral, a Oracle conta com algumas opções de banco para atuar tanto no controle preventivo como reativo. De modo geral estes produtos são comercializados como options do banco Oracle Database Enterprise Edition (DBEE) ou como packs para o Enterprise Manager. Alguns destes produtos, no entanto, podem ser utilizados em conjunto com outros bancos de dados que não são Oracle.
Para trabalhar com criptografia de banco de dados (data files e backup), a ferramenta é chamada de Transparent Data Encryption (TDE), sendo comercializada como option do Oracle Database Enterprise Edition com o nome de Advanced Security. Para criptografia de rede, entre banco de dados e aplicação, até junho de 2013 este recurso também fazia parte da option Advanced Security, porém desde então agora ela faz parte da funcionalidade padrão do banco de dados Oracle Database Enterprise Edition.
O controle de usuários privilegiados, considerando o banco de dados Oracle Enterprise Edition, pode ser feito através da option Database Vault. O objetivo desta option é assegurar que os usuários privilegiados (DBAs e SYSDBAs) continuem com os seus “super poderes” administrativos, porém não tenham acesso a dados sensíveis.
Finalmente, para trabalhar com o mascaramento dos dados de produção na hora de replicar o ambiente para desenvolvimento, a ferramenta da Oracle é um pack do Enterprise Manager 12c chamado de Data Masking and Subsetting. Este pack é capaz não só de descaracterizar os dados como também exportar apenas um subconjunto dos dados de produção mantendo sua integridade referencial, mas reduzindo os requisitos de espaço na base de dados de desenvolvimento. Um fato interessante é que esta ferramenta é multi-banco, ou seja, não funciona apenas em bancos de dados Oracle.
Todas as ferramentas acima trabalham no conceito de controle preventivo. Para fechar o raciocínio dos tipos de controle e suas soluções faltou comentar sobre o controle reativo. A ferramenta que dispomos para tratar este tipo de controle é chamada de Audit Vault, um repositório de informações de auditoria isolado dos ambientes que monitora e totalmente desenvolvido com as melhores práticas de segurança para que não haja alteração dos dados auditados. O princípio é que, no advento de uma falha de segurança, hajam informações disponíveis para rastrear a origem da falha e punir com as devidas sanções os responsáveis. O Audit Vault, assim como o Data Masking, é uma ferramenta que pode ser usada também em bancos não-Oracle, incluindo SQL Server, DB2 e outros.

Palavras Finais

Espero com este artigo ter conseguido mostrar um pouco do mundo da segurança da informação e as possíveis vulnerabilidades as quais as empresas estão sujeitas no dia a dia. Como minha especialidade é Oracle, tomei a liberdade também de mostrar algumas das ferramentas dentro do nosso portfólio podem ser utilizadas para atacar os pontos de risco citados no artigo. De maneira alguma o meu objetivo foi ser exaustivo na descrição destas ferramentas, mas sim dar uma visão geral do que está disponível no mercado.
Caso haja mais interesse em conhecer o portfólio de segurança da Oracle, fiquem a vontade para entrar em contato. Estarei a disposição para esclarecer quaisquer dúvidas que por ventura possam aparecer.
E para finalizar, vale lembrar aquilo que eu comentei anteriormente sobre política de segurança e ferramentas. De nada adianta investir em ferramentas top de linha se não houver uma mudança de cultura corporativa, afinal segurança é um conceito extremamente dependente das pessoas. Para que uma política de segurança funcione corretamente, não basta ter as ferramentas corretas, mas também é preciso treinar as pessoas e deixar muito claro através de políticas, papéis e sanções o que cabe a cada um fazer.

quinta-feira, 27 de novembro de 2014

Tutorial: Como criar um ambiente de testes do Enterprise Manager 12c Cloud Control com o Oracle VM VirtualBox

O objetivo deste tutorial é criar um ambiente de demo ou testes do Enterprise Manager 12c Cloud Control. Ele surgiu como uma necessidade direta do meu trabalho como pré-vendas em demonstrar soluções para os clientes, porém este mesmo material pode ser muito útil para o público geral, em especial aquelas pessoas que gostariam de ter um ambiente sandbox para aprender mais sobre a ferramenta Enterprise Manager 12c e não têm uma máquina física disponível. 

Além disso, é sabido que a instalação manual do EM12c é um pouco trabalhosa, e muitas vezes o que queremos é apenas usar o ambiente, e não aprender a instalá-lo. Logo, para conseguir um ambiente funcional o mais rápido possível, optei por utilizar extensivamente os templates de VMs disponíveis no site da Oracle.

Pré-Requisitos


Antes de começar, é importante se assegurar que as seguintes condições sejam cumpridas:
  • O suporte a virtualização está habilitado no BIOS. (Extensões VT-x ou similar)
  • A última versão do Oracle VM VirtualBox está instalada. Se vocês caírem no erro abaixo, atualizar a versão do VirtualBox:
 

Baixar em https://www.virtualbox.org/wiki/Downloads. É importante também baixar o Extension Pack compatível.

Para atualizar o Extension Pack do VirtualBox, vá em Arquivo -> Preferências -> Extensões e clique em Acrescentar pacote:

 Selecione o arquivo baixado da home do VirtualBox e atualize o pacote:

  • Baixar os templates das VMs no site da Oracle / e-delivery.
a. Oracle Linux: baixar a Oracle Linux 6 Admin VM. No www.oracle.com, ir em Downloads -> Prebuilt developer VMs
   

 Na lista de VMs, localizar a Oracle Linux 6 Admin VM:



b. Oracle Enterprise Manager 12c Cloud Control: 

Baixar pelo e-delivery (https://edelivery.oracle.com/linux). No Media Pack Search escolher Oracle VM Templates e x86 64 bit:

Baixar o template abaixo:


Cuidado para não baixar o o Oracle VM Template, e sim o Oracle VM VirtualBox. O arquivo correto tem 4 partes e 15 GB no total. A versão mais atual é a 12.1.0.4.0.

Antes de importar o appliance é necessário descompactar os arquivos e recombiná-los em um só *.OVA. Para fazer isso basta seguir as instruções do readme:

a) Extract all of the zip files using unzip. This will create files with the .ova extension. 

b) Run the following command to combine the .ova files into one .ova file: 

On Linux: cat VBox*.ova > EM12cR4.ova

On Windows: type VBox*.ova > EM12cR4.ova
Sugestão: como é um processo intensivo de I/O, recomendo fazer esta movimentação entre HDs diferentes.

Descritivo do Ambiente


Eu estou usando como máquina de teste o notebook Dell Latitude E7240. É um modelo com disco interno SSD e 8 GB de RAM. Eu já fiz um ambiente similar utilizando um note mais antigo, Lenovo Thinkpad T420, também com 8 GB, porém com disco normal. O meu note está com Windows 8, mas no setup anterior fiz com o Windows 7.

Em termos de periféricos, como eu já montei algumas demos bem grandes (exemplo: EBS Vision Single Node, requisitos de 300 GB de disco!), eu comprei dois HDs externos – um HD SSD de 240 GB e outro normal de 1 TB que eu uso como “storage”, ambos em USB 3.0.

A idéia é rodar as VMs a partir do SSD, seja interno ou externo (vou montar no externo neste setup), e manter uma biblioteca de templates no disco normal. Em casos extremos como o do EBS Vision não tem outra escolha senão rodar a VM a partir do disco externo.

Observação: se vocês forem utilizar o recurso de snapshots extensivamente, sugiro deixar num disco externo bem grande, pois vocês vão ver o disco sumir rapidinho. Também dá para bolar uma estratégia mista, mantendo a imagem original no disco lento e as imagens diferenciais no disco rápido. Depois vou elaborar melhor este ponto, primeiro vamos cuidar dos setups básicos, ok?

Basicamente, para ter menos concorrência em disco, uma alternativa é alternar sempre o drive de destino. Ex.: baixar os arquivos do template na unidade externa ‘A’, descompactar no disco interno ‘B’ (ou outra unidade externa ‘C’) e recombinar os arquivos para a unidade externa ‘A’ de novo. Eu mantenho um diretório com todos os templates de VM prontos para importar no disco de 1 TB.

A VM do EM12c depois de importada tem em torno de 40 GB. A VM do Oracle Linux tem 5,5 GB. Após o fim de todos os setups é esperado que elas ocupem bem mais espaço, então recomendo reservar cerca de 60 GB para todo o ambiente.

Passo 1: Import dos Templates


Antes de importar qualquer template é importante indicar para o VirtualBox qual é o diretório de destino das máquinas virtuais. Na tela principal, clicar em Arquivo -> Preferências -> Geral e modificar a pasta padrão das máquinas para o diretório desejado (ficar atento para exigências de espaço livre em disco):


Na tela principal do VirtualBox, clicar em Arquivo -> Importar Appliance:


Selecionar o arquivo EM12cR4.ova e apertar Próximo:
  

Na tela seguinte, eu recomendo renomear a máquina virtual para emcc.example.com, reduzir o número de CPUs para 1 e desativar o áudio, para economizar um pouco de recursos. Feito isto basta disparar o import:


Este processo, considerando o setup que eu comentei, leva em torno de 10 minutos. Se vocês forem importar no mesmo disco, esperem que vai demorar... :)

Na sequência, fazer o mesmo para o Oracle Linux, renomeando a máquina para oel.example.com e desativando o áudio. O import desta máquina leva em torno de 3 minutos. No final vocês devem ter as duas máquinas na página principal do VirtualBox.

Agora, para eu me organizar melhor, eu costumo fazer duas práticas que vocês podem adotar também ou não. A primeira, é organizar as VMs em grupo, assim eu sei que elas fazem parte do mesmo ambiente. Clique com o botão direito do mouse em uma das VMs e escolha Grupo:


Em seguida, arraste a segunda VM para dentro do grupo. Eu vou chamar este grupo de EM12c 12.1.0.4:


A segunda prática é criar um snapshot a cada passo significativo do setup do ambiente. Como acabamos de importar os templates e esse é um processo que pode ser demorado (importar o EM12cR4.ova na minha máquina antiga levava quase uma hora). 

Manter snapshots é uma forma de garantir “restore points” caso vocês precisem voltar o ambiente para o estado anterior, seja para desfazer um erro de configuração ou ainda como um passo natural para ambientes de demo. 

Vou criar um para cada VM a fim de guardar este estado inicial. Primeiro clique em Snapshots, e depois em Criar Snapshot:


Passo 2: Configuração do EM12c


Estamos prontos para inciar a VM pela primeira vez. Inicie a VM emcc.example.com. O usuário e senha é oracle/welcome1. Como primeira tarefa, vamos atualizar os Adicionais para Convidado. No menu do VirtualBox, clicar em Dispositivos -> Inserir imagem de CD dos Adicionais para Convidados...

Na caixa de mensagem que abrir na tela, dar um duplo clique no autorun.sh e escolher Run in Terminal. Ele vai pedir o password do root que também é welcome1. Espere concluir o processo e você pode “ejetar” o CD.

Vamos dar um shutdown na VM e preparar o ambiente de rede. O primeiro passo é configurar a rede de hospedeiro. No menu do VirtualBox, clique em Arquivo -> Preferências -> Rede -> Redes Exclusivas de Hospedeiro. Deve haver pelo menos um adaptador criado:

 

Se não houver, criar um com o ícone + no canto direito da tela. Clique na chave de fenda e depois em Servidor DHCP para ver as configurações da rede:


Por padrão o VirtualBox utiliza a faixa de IPs de 192.168.56.x. IPs iguais ou maiores que 101 estão reservados para o servidor DHCP interno. Como nós vamos utilizar este ambiente para testes de data guard, RAC, etc, recomendo utilizar IPs fixos na faixa de 10 a 100.

Para meu setup inicial, vou considerar as seguintes máquinas:

192.168.56.10 emcc.example.com emcc
192.168.56.20 oel.example.com  oel

Adicione estes endereços nos arquivos hosts de todos os servidores, incluindo o computador host do VirtualBox e as VMs. No Windows 8, o arquivo hosts está no caminho X:\Windows\System32\drivers\etc\hosts, onde X é a unidade de instalação do SO. No Linux, o arquivo hosts está no caminho /etc/hosts. (Um atalho rápido para linha de comando no Windows 8 é pressionar a tecla Windows+x e depois pressionar ‘a’. É preciso ter acesso de administrador para editar o arquivo hosts)
  



Feito isso vamos mudar as configurações das placas de rede dos dois servidores para fixar estes IPs. No VirtualBox, clicar com o botão direito no nome da máquina (emcc.example.com) e depois em Configurações -> Rede e trocar o adaptador para Placa de Rede Exclusiva de Hospedeiro (host-only).


Fazer o mesmo para a máquina oel.example.com.

Um último passo de setup que pode economizar bastante tempo no futuro é definir uma pasta compartilhada para as VMs e o host. Ainda na tela de Configurações, escolher o último item, Pastas Compartilhadas. Eu costumo acrescentar uma pasta shared no meu disco “Storage”.
  

A pasta compartilhada vai estar disponível no diretório /media/sf_nome. Como a minha pasta se chama shared, ela aparece como /media/sf_shared. Note que para o usuário oracle poder ler e gravar nesta pasta ele precisa das permissões corretas. Para fazer isso é necessário acessar o terminal da VM e adicionar o usuário oracle ao grupo vboxsf:


Depois dessa mudança é necessário fazer Log Out / Log On para que o X Windows reconheça as novas permissões.

(Observação: outra coisa que pode ajudar bastante neste momento é habilitar o clipboard bi-direcional no VirtualBox. Isso pode ser feito no menu Dispositivos -> Área de Transferência Compartilhada -> Bi-direcional)

Agora vamos subir a máquina emcc.example.com. Inicie a VM e entre com o usuário oracle/welcome1. Precisamos mudar o IP do adaptador de rede e configurar o arquivo hosts assim como fizemos no Windows. Vá em System -> Administration -> Network, entre com a senha de root - welcome1.

É possível configurar tudo a partir desta única tela, basta seguir os modelos abaixo. Selecionar eth0 e clicar em edit:


Configurar o IP estático:


Na aba hosts, adicionar os endereços do emcc.example.com e oel.example.com:


 


Está na hora de iniciar o EM12c, finalmente, mas os scripts estão bugados... Então antes de subir o EM precisamos corrigi-los no terminal. Abra uma janela do terminal pelo menu Applications -> Accessories -> Terminal.

Então renomeamos os scripts antigos e criamos dois scripts novos para start/stop do oms:

$ mv start_oms.sh start_oms.sh.old
$ mv stop_oms.sh stop_oms.sh.old
$ echo /u01/OracleHomes/Middleware/oms/bin/emctl start oms > start_oms.sh
$ echo /u01/OracleHomes/Middleware/oms/bin/emctl stop oms > stop_oms.sh
$ chmod +x start_oms.sh
$ chmod +x stop_oms.sh

Agora é um bom momento para criar um snapshot da VM. Utilizando a tecla host (Ctrl Direito) + T você pode chamar a tela de criação de snapshots diretamente da VM.


Feito isso basta rodar o script start_all.sh para iniciar o ambiente. O startup pode levar alguns minutos dependendo da máquina, sendo o mais demorado o OMS. Para checar que os detalhes da configuração do OMS, após a inicialização, basta rodar o seguinte comando:

$ /u01/OracleHomes/Middleware/oms/bin/emctl status oms –details
Oracle Enterprise Manager Cloud Control 12c Release 4 
Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved.
Enter Enterprise Manager Root (SYSMAN) Password : 
Console Server Host : emcc.example.com
HTTP Console Port : 7788
HTTPS Console Port : 7799
HTTP Upload Port : 4889
HTTPS Upload Port : 4900
EM Instance Home : /u01/OracleHomes/gc_inst/em/EMGC_OMS1
OMS Log Directory Location : /u01/OracleHomes/gc_inst/em/EMGC_OMS1/sysman/log
OMS is not configured with SLB or virtual hostname
Agent Upload is locked.
OMS Console is locked.
Active CA ID: 1
Console URL: https://emcc.example.com:7799/em
Upload URL: https://emcc.example.com:4900/empbs/upload

WLS Domain Information
Domain Name : GCDomain
Admin Server Host : emcc.example.com
Admin Server HTTPS Port: 7101
Admin Server is RUNNING

Oracle Management Server Information
Managed Server Instance Name: EMGC_OMS1
Oracle Management Server Instance Host: emcc.example.com
WebTier is Up
Oracle Management Server is Up

BI Publisher is not configured to run on this host.

O EM12c já está no ar, porém está acessível apenas a partir da VM. O último passo para liberar o acesso do EM12c no host do VirtualBox é mudar a configuração do Firewall. Existem duas opções: desabilitar o firewall completamente ou adicionar as portas do EM12c como exceção. Ambas as configurações podem ser feitas no menu System -> Administration -> Security Level and Firewall. Para manter a simplicidade do demo, vou simplesmente desabilitar o Firewall como um todo.


Com tudo no ar, basta abrir uma janela do browser no host Windows e digitar o endereço https://emcc.example.com:7799/em.

Se a página não abrir, existe um passo adicional de configuração na rede do host. Numa linha de comando, verifique que a rede VirtualBox Host-Only Network está na mesma faixa de endereços que a VM utilizando o comando ipconfig:

Ethernet adapter VirtualBox Host-Only Network:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::494f:65d3:7114:caef%13
Autoconfiguration IPv4 Address. . : 169.254.202.239
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

No meu caso ela não está, então para corrigir vamos alterar as configurações da rede no Painel de Controle:


As configurações do IPV4 estavam erradas. É só colocar tudo em automático e voltar ao teste. Para confirmar que o problema está resolvido, basta rodar um ping na linha de comando:

C:\Windows\system32>ping emcc

Pinging emcc.example.com [192.168.56.10] with 32 bytes of data:
Reply from 192.168.56.10: bytes=32 time<1ms TTL=64
Reply from 192.168.56.10: bytes=32 time<1ms TTL=64
Reply from 192.168.56.10: bytes=32 time<1ms TTL=64
Reply from 192.168.56.10: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.56.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms


C:\Windows\system32>

De volta ao browser:


Voilá! Sucesso! :)

Lembrando que a senha do sysman é welcome1.


Opcional: Executar a VM sem interface gráfica.


Para economizar um pouco de recursos, eu gosto de desabilitar a interface gráfica das VMs e consolidar todo o gerenciamento via browser no host do VirtualBox. Para fazer isso, primeiro é necessário baixar os serviços do EM12c. No terminal, execute o script stop_all.sh.

Em seguida, como root edite o arquivo /etc/inittab e troque o default runlevel de 5 para 3:

# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

Reinicie a máquina, entre com o usuário oracle/welcome1 e execute o script start_all.sh novamente. Estamos prontos!

Passo 3: Configuração da máquina Linux


O objetivo do tutorial era criar um ambiente EM12c para demos. Uma das primeiras coisas que os clientes gostam de ver é como se faz uma instalação de agentes remotamente. É para isso que eu vou utilizar esta máquina com o Oracle Linux.

Primeiro, vamos configurar a conectividade. Inicie a VM oel.example.com. O usuário e senha é oracle/oracle.

Como é uma versão diferente do Linux, os menus estão em lugares diferentes, mas os objetivos são os mesmos:

1. Instalar Adicionais para Convidados

2. Desabilitar (ou configurar) o Firewall: em System -> Administration -> Firewall

3. Configurar o IP estático: System -> Preferences -> Network Connections. Em eth0 -> Edit.

4. Adicionar entradas de endereço no arquivo /etc/hosts.

5. Configurar Pastas Compartilhadas, incluindo permissões do usuário oracle e owner da pasta.

Um passo adicional que não foi necessário fazer na VM anterior é mudar o nome da máquina. É preciso editar o arquivo /etc/sysconfig/network e mudar a linha HOSTNAME para HOSTNAME=oel.example.com.

Além disso, precisamos adicionar o usuário oracle na lista de sudoers. Como root, utilize o comando visudo e adicione a seguinte linha no final do arquivo:

oracle ALL=(ALL) ALL

Ainda no visudo, vamos aproveitar para mudar as propriedades requiretty para !requiretty e !visiblepw para visiblepw:


Também vamos criar a hierarquia de diretórios para acomodar a instalação do agente. Como root digite:

mkdir /u01

chown oracle:oracle /u01

Passo 4: Instalar o agente do EM12c no host oel.example.com


Agora que temos todo o ambiente preparado, vamos adicionar a VM oel.example.com como um alvo gerenciado no EM12c.

No menu Setup -> Add Target -> Configure Auto Discovery vamos criar uma nova pesquisa para encontrar o host oel.example.com.

Clique em Create para adicionar uma nova regra de descoberta:


Na tela seguinte, clique em Add. Neste passo estamos escolhendo o agente do EM12c que vai ficar responsável por fazer esta varredura. No caso, só temos um agente disponível, o do próprio EM12c:

  

Selecione o agente emcc.example.com:3872 para prosseguir para a próxima tela. Agora temos que preencher o formato de busca do host. Você pode preencher vários valores separados por espaços e utilizar faixas de endereço ou nomes de hosts. Eu optei por fazer a busca diretamente pelo nome do host para economizar tempo.


É necessário definir também as credenciais de root (ou poweruser) do host onde está o agente que vai fazer a varredura. Lembrando, a senha do root é welcome1. Vou salvar esta credencial como credencial nomeada para uso futuro:


Ao clicar em Save and Submit Scan você vai voltar para a tela anterior:


Depois de poucos segundos o resultado já deve estar completo:


Você pode ver o resultado da pesquisa clicando no número “1” na coluna Discovered Targets, ou pelo menu Setup -> Add Target -> Auto Discovery Results. Na primeira aba da tela, Host and Oracle VM Manager, é possível promover o host para gerenciado pelo botão Promote


O Promote vai abrir um wizard para guiar a instalação do agente do EM12c no host:



Na primeira tela não tem muito segredo, é só certificar que o SO foi descoberto corretamente. Na segunda tela especificamos o caminho da instalação do agente. Pode ser qualquer caminho que faça sentido. Vou colocar /u01/agentHome:


Também vou criar uma credencial nomeada para o usuário oracle:



A última tela é apenas um review. Clique em Deploy Agent.


O EM12c vai executar os passos de verificação e instalar o agente:


Pronto, o oel.example.com está gerenciado!

Conclusões


O objetivo deste roteiro era criar uma infra estrutura básica para poder rodar demos do Enterprise Manager 12c Cloud Control. Não se trata de um ambiente production ready em função de algumas simplificações que fizemos na configuração, em especial em termos de segurança, mas é perfeitamente funcional para realizar demos, testes e apresentações.

Espero que tenham gostado do passo a passo e quaisquer dúvidas fiquem a vontade para postar nos comentários.