← TODOS OS CASES ← ALL CASES
Cliente Oracle (sob NDA) · Indústria · enterprise

Automação de Oracle Enterprise Manager em HA

Migração de Oracle Enterprise Manager para modelo resiliente em AWS, com deployment automatizado via Ansible e Python.

2024·119· ·2 MESES
OEM 13c
Plataforma
Em AWS com HA
Automatizado
Deployment
Ansible + Python, repetível
Multi-AZ
HA
Resiliente a falha de zona
Reduzida
Manutenção
Upgrade + reconfig via código
Oracle customer (under NDA) · Industry · enterprise

Oracle Enterprise Manager HA automation

Migration of Oracle Enterprise Manager to a resilient AWS deployment model, with automated provisioning via Ansible and Python.

2024·119· ·2 MONTHS
OEM 13c
Platform
On AWS with HA
Automated
Deployment
Ansible + Python, repeatable
Multi-AZ
HA
Resilient to zone failure
Reduced
Maintenance
Upgrade + reconfig as code

O problema

Oracle Enterprise Manager 13c rodando em deployment manual, single-AZ, com upgrade e reconfiguração feitos por scripts ad-hoc. Cliente queria evoluir para arquitetura resiliente em AWS, com deployment repetível, sem dependência de conhecimento operacional específico.

Risco da configuração atual: incidente de zona = downtime de monitoração. Sem monitoração = cego para incidentes em produção. Cascade risk.

Como abordamos

Redesign do deployment OEM como infraestrutura como código.

  • Arquitetura HA: multi-AZ em AWS, com OMS (Oracle Management Server) replicado, repository database em RDS com Multi-AZ habilitado
  • Automação Ansible: playbooks para instalação OEM, configuração inicial, agente de target deployment
  • Python tooling: scripts para tarefas operacionais recorrentes (cleanup, archive, métrica custom)
  • Infrastructure-as-code: Terraform para componentes AWS, Ansible para configuração OEM em cima

Tudo testado em ambiente espelho antes de aplicar em produção. Upgrade futuro vira mudança de versão no playbook, não trabalho manual.

Handover

Cliente recebeu playbooks, scripts Python, e documentação operacional. Time interno consegue replicar deployment ou reaplicar em novo ambiente sem dependência de Redgator. Modelo de tunig de Ansible/Python documentado para evolução futura.

The problem

Oracle Enterprise Manager 13c running in a manual deployment, single-AZ, with upgrades and reconfigurations done via ad-hoc scripts. The client wanted to evolve toward a resilient architecture on AWS, with repeatable deployment, no dependency on specific operational knowledge.

Risk of the current setup: a zone incident = monitoring downtime. No monitoring = blind to production incidents. Cascade risk.

How we approached it

OEM deployment redesigned as infrastructure as code.

  • HA architecture: multi-AZ on AWS, with replicated OMS (Oracle Management Server), repository database on RDS with Multi-AZ enabled
  • Ansible automation: playbooks for OEM install, initial configuration, target agent deployment
  • Python tooling: scripts for recurring operational tasks (cleanup, archive, custom metrics)
  • Infrastructure-as-code: Terraform for AWS components, Ansible for OEM config on top

Everything tested in mirror environment before applying to production. Future upgrade becomes a version change in the playbook, not manual work.

Handover

Client received playbooks, Python scripts, and operational documentation. Internal team can replicate the deployment or reapply in a new environment without Redgator dependency. Ansible/Python tuning model documented for future evolution.

Conversar

Tem um problema parecido?

45 min com o TL que executou este case. Sem deck.

Talk to us

Got a similar problem?

45 min with the TL who ran this case. No deck.