forked from diegoecab/oci-deal-accelerator
Diagram generation: ref-arch-driven procedure + spec validator + KB enrichment
The diagram path now follows a documented standard procedure (lookup the closest Oracle Architecture Center reference → confirm components → author absolute_layout → spec validator → render → visually verify) and ships persistent guardrails so layout regressions can't recur. Persistent procedure changes (apply to all users, all sessions): - tools/diagram_spec_validator.py — geometry checks (CONTAINER_TOO_THIN, CONTAINER_PADDING_VIOLATION, LABEL_OVERFLOW_PARENT) run BEFORE either renderer (drawio + PPTX). Catches the subnet-collapse / label-overflow bugs that the post-render drawio validator missed. - tools/oci_diagram_gen.py + tools/oci_pptx_diagram_gen.py — call the spec validator before emitting any output. Adds mysql / mysql_heatwave type aliases. - tools/archcenter_pattern_lookup.py — scores against cached page descriptions (not just the 1-line summary), supports --queries for multi-fragment composition, and applies synonym expansion via kb/architecture-center/synonyms.yaml so "LB HA cross AD" matches "load balancer high availability availability domain". - kb/architecture-center/synonyms.yaml — canonical synonym table (load balancer, autonomous database, data guard, …) used by the lookup scorer. KB enrichment: - tools/archcenter_description_fetcher.py + 121 cached _description.md under kb/diagram/assets/archcenter-refs/<slug>/. Removes the runtime dependency on docs.oracle.com when authoring specs and feeds the pattern-lookup scorer. - 110+ cached .drawio / .svg / .png references for offline reuse, plus the OCI Toolkit v24.2 import (kb/diagram/assets/oci-toolkit-drawio). Documentation: - docs/skill/output-formats.md — new "Standard diagram-generation procedure (MANDATORY)" + geometry rules + the new validator entry. - SKILL.md option 2 — references the mandatory procedure. - README.md — describes the spec validator, archcenter_pattern_lookup and description fetcher, and updates the KB-health table. Tooling that backs the procedure (cumulative across recent sessions): tools/archcenter_case_runner.py, archcenter_batch_driver.py, archcenter_zip_downloader.py, drawio_visual_validator.py, drawio_fidelity_eval.py, harvest_drawio_icon.py, import_oci_library.py, oci_pptx_diagram_gen.py, oci_pptx_render.py, refresh_pptx_icon_index.py. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
root
@@ -0,0 +1,231 @@
|
||||
# Deploy ORDS with High Availability on OCI
|
||||
|
||||
- Source: https://docs.oracle.com/en/solutions/deploy-ords-ha-oci/index.html
|
||||
- Date: 2025-06
|
||||
- Type: reference-architecture
|
||||
- Services: compute, load-balancer, adb-s, bastion
|
||||
- Tags: database, application, ha-dr
|
||||
|
||||
## Summary (catalog)
|
||||
|
||||
Multi-instance ORDS behind OCI Load Balancer for HA REST access to Oracle DB. Works with ADB-S, DBCS, or ExaCS. Recommends DB in private subnet, ORDS in public with granular NSG rules.
|
||||
|
||||
## Architecture (fetched from source)
|
||||
|
||||
Architecture
|
||||
|
||||
|
||||
|
||||
|
||||
This architecture shows you how to deploy Oracle REST Data Services with high
|
||||
availability on OCI.
|
||||
|
||||
|
||||
The architecture starts with a Virtual Cloud Network (VCN) within a single
|
||||
region. While this VCN can span multiple Availability Domains (AD), for this reference
|
||||
architecture, it uses a single AD. That AD contains multiple fault domains—areas within
|
||||
an AD that have grouped hardware and infrastructure. Compute VMs with ORDS are deployed
|
||||
across multiple fault domains to help in attaining high availability.
|
||||
|
||||
|
||||
In the VCN, multiple subnets contain specific architectural components. It
|
||||
starts with an Internet gateway, which only allows traffic over a specified port to the
|
||||
load balancers on the front end of this VCN in a public subnet. The load balancers also
|
||||
have a public facing IP you can later use to apply custom domain names, if needed. The
|
||||
load balancer will talk to the subnet containing the ORDS compute mid-tiers.
|
||||
Communication is secured by subnet-wide security lists as well as network security
|
||||
groups (NSG). You can apply these NSGs to a set of VNICs on the compute and load
|
||||
balancers to provide granular security rules for communication between these resources.
|
||||
|
||||
|
||||
Finally, again employing security lists and NSGs, the ORDS mid-tiers can
|
||||
access an Oracle database in a private subnet. Resources using private subnets are not
|
||||
given public facing IPs. This way, you can use the NSGs for a secure communication layer
|
||||
between the public and private subnets. The Oracle database instance in this private
|
||||
subnet can be a VM DB instance, an autonomous database, or an Exadata Cloud Service
|
||||
database.
|
||||
|
||||
|
||||
The following diagram illustrates this reference architecture.
|
||||
|
||||
|
||||
|
||||
Description of the illustration ha-ords-oci3.png
|
||||
|
||||
|
||||
|
||||
ha-ords-oci3.zip
|
||||
|
||||
|
||||
|
||||
|
||||
This architecture has the following components:
|
||||
|
||||
|
||||
- Region
|
||||
|
||||
|
||||
An OCI region is a localized geographic area that contains one or
|
||||
more data centers, called availability domains. Regions are independent of
|
||||
other regions, and vast distances can separate them (across countries or
|
||||
even continents).
|
||||
|
||||
|
||||
|
||||
- Availability domains
|
||||
|
||||
|
||||
Availability domains are standalone, independent data centers within a
|
||||
region. The physical resources in each availability domain are isolated from
|
||||
the resources in the other availability domains, which provides fault
|
||||
tolerance. Availability domains don’t share infrastructure such as power or
|
||||
cooling, or the internal availability domain network. So, a failure at one
|
||||
availability domain is unlikely to affect the other availability domains in
|
||||
the region. The resources in this architecture are deployed in a single
|
||||
availability domain.
|
||||
|
||||
|
||||
|
||||
- Fault domains
|
||||
|
||||
|
||||
A fault domain is a grouping of hardware and infrastructure within an
|
||||
availability domain. Each availability domain has three fault domains with
|
||||
independent power and hardware. When you distribute resources across
|
||||
multiple fault domains, your applications can tolerate physical server
|
||||
failure, system maintenance, and power failures inside a fault domain. The
|
||||
resources in this architecture are deployed in multiple fault domains.
|
||||
|
||||
|
||||
|
||||
|
||||
- Virtual cloud network (VCN) and subnets
|
||||
|
||||
|
||||
A VCN is a customizable, software-defined network that you set up
|
||||
in an OCI region. Like traditional data center networks, VCNs give you
|
||||
complete control over your network environment. A VCN can have multiple
|
||||
non-overlapping CIDR blocks that you can change after you create the VCN.
|
||||
You can segment a VCN into subnets, which can be scoped to a region or to an
|
||||
availability domain. Each subnet consists of a contiguous range of addresses
|
||||
that don't overlap with the other subnets in the VCN. You can change the
|
||||
size of a subnet after creation. A subnet can be public or private.
|
||||
|
||||
|
||||
In this reference architecture, the compute instances with ORDS
|
||||
are attached to a public subnet along with the load balancer while the
|
||||
databases can use either a private or public subnet. Database Security best
|
||||
practices put database instances in private subnets whenever
|
||||
possible.
|
||||
|
||||
|
||||
|
||||
- Load Balancer
|
||||
|
||||
|
||||
The Oracle Cloud
|
||||
Infrastructure Load Balancing service provides automated traffic distribution from a single entry point
|
||||
to multiple servers in the back end. This load balancer's public IP will
|
||||
also serve as where we can register custom domain names if needed.
|
||||
|
||||
|
||||
|
||||
|
||||
- API Gateway
|
||||
Oracle Cloud Infrastructure API Gateway enables you to
|
||||
publish APIs with private endpoints that are accessible from within your
|
||||
network, and which you can expose to the public internet, if required. The
|
||||
endpoints support API validation, request and response transformation, CORS,
|
||||
authentication and authorization, and request limiting.
|
||||
|
||||
|
||||
|
||||
- Compute Instances/ORDS Hosts
|
||||
Oracle Cloud Infrastructure
|
||||
Compute lets you provision and manage compute hosts. You can launch compute
|
||||
instances with shapes that meet your resource requirements (CPU, memory,
|
||||
network bandwidth, and storage). After creating a compute instance, you can
|
||||
access it securely, restart it, attach and detach volumes, and terminate it
|
||||
when you don't need it. The web servers in this architecture run on compute
|
||||
virtual machines using either an x86 or ARM CPU architecture
|
||||
|
||||
|
||||
|
||||
|
||||
- Database Instances
|
||||
|
||||
|
||||
The Database service offers autonomous and co-managed Oracle Database cloud solutions. Autonomous databases are preconfigured, fully-managed
|
||||
environments that are suitable for either transaction processing or for data
|
||||
warehouse workloads. Co-managed solutions are bare metal, virtual machine,
|
||||
and Exadata DB systems that you can customize with the resources and
|
||||
settings that meet your needs.
|
||||
|
||||
|
||||
|
||||
This reference
|
||||
architecture can be used for either autonomous databases or co-managed
|
||||
database instances.
|
||||
|
||||
|
||||
|
||||
- Network security groups (NSG)
|
||||
|
||||
|
||||
NSGs act as virtual firewalls for your compute instances. With
|
||||
the zero-trust security model of OCI, all traffic is denied, and you can
|
||||
control the network traffic inside a VCN. An NSG consists of a set of
|
||||
ingress and egress security rules that apply to only a specified set of
|
||||
VNICs in a single VCN. In this architecture, separate NSGs are used for the
|
||||
load balancer, web servers, and the database.
|
||||
|
||||
|
||||
|
||||
- Route Tables
|
||||
|
||||
|
||||
Virtual route tables contain rules to route traffic from subnets to
|
||||
destinations outside a VCN, typically through gateways.
|
||||
|
||||
|
||||
|
||||
- Internet Gateway
|
||||
The internet gateway allows traffic between the
|
||||
public subnets in a VCN and the public internet.
|
||||
|
||||
|
||||
|
||||
- Security Lists
|
||||
Security list are a set of
|
||||
ingress and egress rules that specify the types of traffic allowed in and
|
||||
out for all VNICs/instances in a subnet. Security Lists are applied at
|
||||
subnet level vs NSGs are applied at a VNIC level. Both effectively act as a
|
||||
firewall for a VNIC. With OCI's zero-trust security model, all traffic to a
|
||||
VNIC is denied. Both SL and NSG need to allow the traffic explicitly, for
|
||||
the traffic to be permitted to the VNIC.
|
||||
|
||||
|
||||
|
||||
- Zero-Trust Packet Routing (ZPR)
|
||||
|
||||
|
||||
In addition to SL and NSG, OCI has a network security construct called
|
||||
Zero-Trust Packet Routing. ZPR is intent-based secure networking acting at
|
||||
layer 4 and can be implemented in human readable policy language. By
|
||||
assigning security attributes ("tags" for ZPR) to your resources, you can
|
||||
create granular access controls to ensure that only authorized entities can
|
||||
communicate with sensitive components, such as databases and application
|
||||
servers. This approach not only reduces the risk of unauthorized access but
|
||||
also simplifies policy management as your application evolves. ZPR operates
|
||||
alongside existing NSGs and SLs, providing a more comprehensive security
|
||||
posture that adapts to changes in your network architecture. Here you can
|
||||
assign security attributes (special ZPR tags) to nodes in each subnet, in
|
||||
such a way that only required traffic is permitted (flow direction, protocol
|
||||
and ports), no matter how the network architecture changes/shifts in
|
||||
future.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user