Meta tags:
description= This document describes how to plan and implement active-passive and active-inactive disaster recovery for OpenShift deployments on Google Cloud.;
Headings (most frequently used words):
active, and, passive, inactive, dr, use, cases, design, considerations, application, scenario, in, an, openshift, on, disaster, recovery, for, with, products, deployments, configuration, management, traffic, cluster, gitops, operator, description, of, components, database, backups, google, cloud, strategies, setups, stay, organized, collections, save, categorize, content, based, your, preferences, architectures, deployment, what, next, used, safeguarding, state, failover, process, secure, secret, networking, vpcs, subnets, ip, addresses, cross, red, hat, service, mesh, as, code, the, execution, firewall, rules, pricing, support, resources, engage, block, storage, persistent, volumes, persistentvolumes, objects, level, replication, self, hosted, using, managed, services,
Text of the page (most frequently used words):
and (195), the (192), for (142), create (121), vms (103), with (88), cloud (67), cluster (63), about (62), troubleshoot (62), use (57), that (54), #google (51), instance (50), manage (48), disk (48), openshift (47), using (43), active (41), configure (39), server (39), view (38), disks (37), set (36), this (35), data (35), compute (35), you (34), from (34), network (33), windows (33), mig (33), application (32), performance (32), replication (31), primary (31), overview (31), region (30), load (30), configuration (29), recovery (29), disaster (28), sql (27), storage (27), reservation (27), clusters (26), your (26), engine (25), secondary (24), can (22), backups (21), regional (21), management (21), applications (21), monitor (21), hyperdisk (21), machine (21), resources (20), backup (20), passive (20), images (20), policies (19), failover (19), groups (19), persistent (19), traffic (18), access (18), instances (18), gpu (18), availability (17), image (17), linux (17), are (16), based (16), apply (16), snapshots (16), inactive (16), regions (16), connect (16), custom (16), global (16), database (16), best (16), recommendations (16), reservations (16), between (15), balancer (15), virtual (15), practices (15), workload (15), ssh (15), infrastructure (14), workloads (14), service (14), creation (14), host (14), across (13), example (13), type (13), secrets (13), time (13), bulk (13), microsoft (13), health (12), following (12), state (12), design (12), multiple (12), external (12), restore (12), managed (12), sole (12), see (11), all (11), learn (11), during (11), operator (11), new (11), vpc (11), oadp (11), dns (11), postgresql (11), metadata (11), machines (11), zones (11), delete (11), stateful (11), code (10), more (10), install (10), monitoring (10), services (10), event (10), internal (10), start (10), migs (10), attached (10), migrate (10), add (10), logs (10), how (9), resource (9), gitops (9), process (9), approach (9), addresses (9), networking (9), enable (9), keys (9), tools (9), systems (9), high (9), licenses (9), tenant (9), shutdown (9), hpc (9), license (8), red (8), hat (8), both (8), deploy (8), necessary (8), security (8), repository (8), recommend (8), ensure (8), where (8), mode (8), rpo (8), databases (8), available (8), snapshot (8), back (8), standby (8), scale (8), import (8), cpu (8), login (8), optimize (8), choose (8), agent (8), existing (8), update (8), guest (8), boot (8), h4d (8), flexibility (8), optimized (8), tpu (8), events (7), thumb (7), documentation (7), deployment (7), types (7), help (7), deployments (7), scenario (7), running (7), considerations (7), run (7), like (7), different (7), point (7), manager (7), asynchronous (7), production (7), demand (7), highly (7), commitments (7), startup (7), balancing (7), benchmark (7), manually (7), idle (7), request (7), mysql (7), zonal (7), remove (7), maintenance (7), templates (7), send (6), control (6), configurations (6), has (6), git (6), strategies (6), issues (6), ensures (6), automatically (6), provides (6), section (6), cross (6), non (6), routing (6), each (6), specific (6), setups (6), node (6), these (6), secret (6), loss (6), over (6), uses (6), container (6), operations (6), cases (6), scripts (6), perform (6), provisioned (6), operating (6), usage (6), migration (6), updates (6), instant (6), files (6), nested (6), gpus (6), group (6), pools (6), extension (6), change (6), transfer (6), customized (6), spot (6), site (5), architecture (5), samples (5), support (5), understand (5), details (5), which (5), manual (5), components (5), continuously (5), within (5), environment (5), store (5), describes (5), deployed (5), method (5), but (5), requests (5), authentication (5), testing (5), api (5), schedule (5), minimal (5), downtime (5), objects (5), volumes (5), cost (5), single (5), locations (5), live (5), series (5), default (5), accounts (5), errors (5), future (5), drivers (5), virtualization (5), nvidia (5), placement (5), build (5), multi (5), modify (5), capacity (5), schedules (5), audit (5), symphony (5), options (5), email (5), enhanced (5), capabilities (5), stop (5), tenancy (5), workstation (5), faq (5), flex (5), português (4), español (4), system (4), products (4), other (4), down (4), need (4), under (4), its (4), topology (4), reference (4), connectivity (4), routes (4), another (4), patterns (4), stores (4), have (4), also (4), scenarios (4), prevent (4), subnets (4), separate (4), vpcs (4), ensuring (4), consistent (4), shared (4), ingress (4), negs (4), target (4), balancers (4), https (4), user (4), certificates (4), important (4), must (4), when (4), failure (4), checks (4), automatic (4), name (4), document (4), used (4), take (4), rto (4), protection (4), kubernetes (4), not (4), longer (4), warm (4), restored (4), velero (4), diagram (4), project (4), costs (4), higher (4), failures (4), ready (4), plan (4), distributed (4), ubuntu (4), console (4), bandwidth (4), tcp (4), pmu (4), number (4), local (4), ssd (4), get (4), share (4), projects (4), upgrade (4), autoscaling (4), calendar (4), metrics (4), containers (4), extensions (4), work (4), zone (4), suspend (4), location (4), resize (4), graceful (4), plans (4), review (4), bound (4), terms (3), information (3), updated (3), content (3), apache (3), solutions (3), implement (3), only (3), them (3), avoid (3), check (3), maintain (3), any (3), quickly (3), controller (3), enables (3), mesh (3), methods (3), engine_vm_ip_port (3), dynamic (3), approaches (3), allow (3), distribution (3), backend (3), endpoint (3), additional (3), typically (3), results (3), latency (3), involves (3), credentials (3), strategy (3), common (3), follows (3), tolerate (3), most (3), recent (3), writes (3), consider (3), replica (3), automated (3), built (3), case (3), scheduled (3), cloudnative (3), streaming (3), such (3), level (3), copy (3), block (3), consistency (3), processes (3), file (3), platform (3), full (3), critical (3), development (3), minutes (3), maintaining (3), provisioning (3), configured (3), periodic (3), serving (3), through (3), actively (3), replicated (3), minimizes (3), objectives (3), acts (3), one (3), fails (3), architectures (3), guides (3), observability (3), analytics (3), troubleshooting (3), encryption (3), pro (3), serial (3), discounts (3), cuds (3), scalable (3), resilient (3), autoscale (3), policy (3), list (3), ibm (3), spectrum (3), deploying (3), prepare (3), rhel (3), protect (3), query (3), disable (3), properties (3), account (3), increase (3), lifecycle (3), size (3), pool (3), move (3), creating (3), workstations (3), tpus (3), product (3), 한국어 (2), 日本語 (2), עברית (2), brasil (2), italiano (2), indonesia (2), français (2), américa (2), latina (2), deutsch (2), english (2), sign (2), action (2), youtube (2), center (2), started (2), status (2), pricing (2), missing (2), last (2), 2026 (2), utc (2), page (2), licensed (2), developers (2), feedback (2), environments (2), what (2), next (2), follow (2), restrict (2), functionality (2), define (2), firewall (2), appropriate (2), permissions (2), strict (2), suitable (2), operators (2), defined (2), same (2), way (2), directly (2), quick (2), restoration (2), enabling (2), reliably (2), however (2), reliable (2), manifests (2), definitions (2), after (2), federation (2), supports (2), communication (2), useful (2), there (2), address (2), networks (2), peering (2), pod (2), hop (2), lower (2), direct (2), internet (2), ocp (2), then (2), distribute (2), iam (2), roles (2), validation (2), test (2), regularly (2), regular (2), able (2), securely (2), secure (2), steps (2), zero (2), alternatively (2), read (2), serves (2), features (2), connection (2), self (2), outage (2), synchronous (2), facilitate (2), make (2), pvcs (2), persistentvolumes (2), reduce (2), backing (2), object (2), potentially (2), needed (2), requirements (2), less (2), ongoing (2), than (2), hours (2), recommended (2), limits (2), business (2), continuous (2), require (2), examples (2), terraform (2), buckets (2), versioning (2), bucket (2), contains (2), fully (2), description (2), shown (2), preceding (2), record (2), triggered (2), shows (2), part (2), source (2), enabled (2), setup (2), making (2), predefined (2), detection (2), mechanism (2), responsible (2), normal (2), conditions (2), doesn (2), affect (2), located (2), until (2), handles (2), kept (2), recover (2), sdk (2), languages (2), frameworks (2), industry (2), hybrid (2), multicloud (2), pipelines (2), hosting (2), quota (2), commitment (2), consumption (2), standard (2), registration (2), sles (2), export (2), port (2), collecting (2), nodes (2), report (2), arm (2), core (2), rdp (2), general (2), app (2), analyze (2), visible (2), cores (2), committed (2), generation (2), underutilized (2), insights (2), utilization (2), globally (2), web (2), autohealing (2), iis (2), reserve (2), autoscaler (2), autoscalers (2), activity (2), provider (2), place (2), directory (2), setting (2), redis (2), cloning (2), writer (2), always (2), alwayson (2), authenticate (2), synchronization (2), switch (2), byol (2), payg (2), byos (2), changes (2), families (2), guide (2), securing (2), simulate (2), together (2), repairs (2), repair (2), template (2), suspended (2), stopped (2), physical (2), cancel (2), once (2), limit (2), interfaces (2), ipv6 (2), static (2), decrease (2), basic (2), scoped (2), appliances (2), throughput (2), encrypt (2), names (2), format (2), mount (2), memory (2), extreme (2), balanced (2), organization (2), advanced (2), rdma (2), created (2), preemptible (2), models (2), rtx (2), vws (2), constraints (2), accelerator (2), apis (2), technology (2), areas (2), close (2), subscribe, newsletter, our, third, decade, climate, join, cookies, privacy, tech, twitter, blog, engage, training, certification, getting, github, release, notes, community, forums, contact, sales, marketplace, easy, easytounderstand, solved, problem, solvedmyproblem, otherup, hard, hardtounderstand, incorrect, sample, incorrectinformationorsamplecode, missingtheinformationsamplesineed, otherdown, tell, except, otherwise, noted, java, registered, trademark, oracle, affiliates, creative, commons, attribution, success, alerting, least, privilege, principle, means, inbound, outbound, consistently, flow, enhance, unified, rules, include, intervention, branching, tagging, identify, stable, synchronizes, match, redeploying, manifest, referencing, execution, matches, drift, reconciles, argo, supported, automates, reconciling, chosen, adopt, syncing, known, runtime, redeploy, logic, rapidly, solution, function, particularly, might, communicate, overlapping, ranges, segmentation, conflicts, often, native, required, propagate, seamless, centralize, simplifies, administration, effectively, integration, allows, router, pods, their, podip, targetport, bypasses, extra, proxying, checking, exposing, routers, ips, abstraction, layer, either, directs, proximity, validate, retrieve, staged, confirm, provided, rotate, accommodates, rotation, don, included, tool, pull, passwords, tls, aspects, described, causes, promoted, takes, promotion, accept, redirects, because, potential, mitigate, against, config, maps, correct, strings, apiversion, cnpg, kind, scheduledbackup, spec, backupownerreference, snippet, even, asynchronously, detailed, cloudnativepg, natively, integrates, durability, pg_basebackup, hosted, depend, kinds, outline, some, message, queues, pub, sub, link, sure, volume, claims, contain, seamlessly, outlined, implementation, depends, further, restoring, namespaces, complementing, rely, nfs, restic, kopia, performing, offers, comprehensive, containerized, configmaps, crds, does, safeguarding, factors, should, develop, meets, reliability, archival, batch, processing, optimization, expense, prohibitive, rather, rtos, several, regulated, industries, justified, impact, feasible, minimized, seconds, would, achievable, cold, restores, immediately, accessible, automation, trigger, orchestration, tooling, iac, well, pvs, initially, operational, two, redundancy, europe, west1, central1, latest, pipeline, provisions, monitored, becomes, unavailable, backed, open, contents, compared, activated, disasters, unlike, relies, stored, integrated, ideal, times, organizations, align, extended, underlying, creates, semi, redirect, upon, unrecoverable, updating, assess, copying, essential, helping, meet, entry, route, geographically, isolated, provide, foundation, large, impacting, fault, isolation, partially, serve, runs, delay, having, pre, meaning, minimize, aligning, passthrough, focuses, remain, recoverable, face, assumes, documents, intended, administrators, architects, who, resilience, achieve, rapid, managing, handling, save, categorize, preferences, stay, organized, collections, home, concurrent, operation, renewal, nvme, resizing, pay, viewing, output, diagnostic, sudoers, screenshots, generate, bug, blackwell, soft, lockups, bus, locks, rescue, inaccessible, dumps, kernel, panic, fstab, unresponsive, suspension, reboots, shutdowns, tips, nics, dpdk, improve, resiliency, compact, idpf, interface, irdma, driver, nic, customize, threads, per, sustained, merge, split, extend, renew, without, purchase, savings, overcommit, cpus, floating, udp, backends, scaling, consuming, consume, combine, cud, sharing, decisions, signals, predictions, organize, labels, states, observe, reports, tensorflow, inference, tensorrt5, learning, monte, carlo, spark, forwarding, others, integrate, clustering, exchange, 2016, sharepoint, integrations, were, transition, hammerdb, aws, ec2, pacemaker, s2d, netapp, hot, drbd, client, private, mailjet, mailgun, sendgrid, sending, blue, green, lamp, joomla, asp, net, interactive, mongodb, flask, servers, mtls, random, generator, virtio, rng, accurate, protocol, ntp, append, els, restrictions, packages, deprecate, versions, family, trusted, knowledgebase, risks, command, controls, confidential, kek, expiration, shielded, attributes, handle, notices, faulty, unmanaged, preserved, turn, off, alternate, repairing, click, upgrades, override, selectively, applying, accelerate, out, rebalance, reenable, proactive, redistribution, shape, info, accidental, deletion, spread, edit, rename, reset, resume, restart, referrers, uuid, corrupted, duplicate, clones, alerts, vss, regionally, failback, replicate, iops, evaluate, settings, kms, customer, supplied, symbolic, links, practice, device, ram, attach, exapools, verify, identity, ptr, rates, tags, automate, password, powershell, sac, apps, root, vpn, bastion, iap, browser, connections, iso, imported, prerequisites, importing, exporting, bring, own, path, detach, reattach, constraint, accounting, provision, slurm, reserved, team, slice, slices, adds, deterministic, base, aci, preempted, historical, alternative, similar, displays, ops, logging, subnet, public, gpudirect, ultra, specify, minimum, hostname, quickstarts, office, licensing, premium, gemini, bare, metal, accelerators, platforms, scores, purpose, discover, free, skip, main,
Text of the page (random words):
agram two separate openshift regional clusters are deployed each in a different google cloud region such as us central1 and europe west1 each cluster must be highly available within its region and use multiple zones to allow for redundancy description of components in an active inactive dr scenario the architecture has the following configuration primary region region a contains the fully operational openshift cluster serving production traffic secondary region region b initially contains minimal resources vpc and subnets infrastructure compute engine instances and ocp is provisioned during failover backup storage google cloud storage buckets store periodic backups oadp or velero for application objects as well as pvs and database backups we recommend that you use versioning and cross region replication for the bucket configuration management git repository stores infrastructure as code iac for example terraform and kubernetes or openshift manifests for gitops backup tooling oadp velero configured in the primary cluster to perform scheduled backups to cloud storage orchestration scripts or automation tools trigger infrastructure provisioning and restore processes during failover use cases this section provides examples of the different use cases for active passive and active inactive deployments active passive dr use cases active passive dr is recommended for the following use cases applications that require a lower rto for example minutes to hours than would be achievable with cold restores where data is restored from a backup that is not immediately accessible systems where continuous data replication is feasible and the rpo must be minimized for example minutes to seconds regulated industries with strict downtime limits and critical business applications where the cost of maintaining a warm standby cluster is justified by the business impact of downtime active inactive dr use cases active inactive dr is recommended for the following use cases applications that can tolerate longer rtos for example several minutes to hours environments where cost optimization is important and the expense of a continuously running standby cluster is prohibitive the primary ongoing cost is for object storage rather than for running compute instances development testing or less critical production workloads archival or batch processing systems where recovery time is less critical design considerations this section describes design factors best practices and design recommendations that you should consider when you use this reference architecture to develop a topology that meets your specific requirements for security reliability cost and performance active passive design considerations this section describes the design considerations for an active passive dr scenario safeguarding application state and configuration openshift container platform provides oadp and offers comprehensive disaster recovery protection for applications running in clusters you can use it to back up the kubernetes and openshift objects that are used by both containerized applications and virtual machines for example deployments services routes pvcs configmaps secrets and crds however oadp does not support full cluster backup and restore to learn how to configure and schedule backups and how to restore operations see the red hat documentation oadp provides backup and restore processes for persistent volumes that rely on the block storage and nfs stores that are used by the applications you can action these processes by using tools restic or kopia to snapshot or performing file level backup oadp is useful for backing up object definitions ensuring configuration consistency and potentially restoring specific applications or namespaces if needed complementing data replication to further reduce rpo and rto in an active passive configuration we recommend that you configure data replication between primary and secondary regions data replication is important for ensuring the secondary cluster can take over seamlessly as outlined in the following section implementation of data replication from the primary to the secondary clusters depends on the storage type that the application uses block storage persistent volumes use google persistent disk asynchronous replication to copy data from the primary to the secondary region in this approach you create a primary disk in the primary region a secondary disk in the secondary region and set up replication between them the use of consistent groups ensures that both disks contain replication data from a common point in time which is then used for dr to learn more see configure persistent disk asynchronous replication persistentvolumes objects in openshift create persistentvolumes objects in both clusters that link to these disks and make sure that applications use the same persistent volume claims pvcs in both clusters application level replication some applications for example databases and message queues have built in replication features that you can configure across clusters you can also use a managed service like pub sub to facilitate replication for specific types of application data or events database backups applications can depend on different kinds of database products to help outline design considerations for database backups this document uses postgresql as an example database self hosted backups using an in cluster database operator database operators like the cloudnative postgresql operator can facilitate scheduled backups and disaster recovery for postgresql clusters cloudnative postgresql operator natively integrates with tools like pg_basebackup and supports streaming replication backups you can store backups in cloud storage services such as google cloud storage cloud storage for durability and recovery you can set up streaming replication between primary and secondary regional clusters to ensure that even in the case of outage in the primary region data is available this streaming replication is typically synchronous within a region and asynchronously across regions for detailed configuration steps see the cloudnativepg documentation in the case of a disaster you can restore backups to a new postgresql cluster ensuring minimal downtime and data loss the following is an example configuration snippet for enabling scheduled backups using the cloudnative postgresql operator apiversion postgresql cnpg io v1 kind scheduledbackup metadata name backup example spec schedule 0 0 0 backupownerreference self cluster name pg backup managed services managed databases like cloud sql have built in backup and replication features we recommend that you set up asynchronous replication from the primary database instance to a replica in the secondary region to learn more see about replication in cloud sql in openshift configure secrets or config maps to point to the correct database connection strings for each cluster because asynchronous replication results in a non zero rpo there s a potential for loss of the most recent data writes you must design your application to mitigate against data loss alternatively consider using another replication method we also recommend that you enable cloud sql automated backups to learn more see create and manage on demand and automatic backups failover process in the event of primary cluster failure cloud dns automatically redirects traffic to the secondary regional cluster based on health checks and failover policies when the secondary cluster is promoted from a read replica to a primary it takes over as an active site and serves production traffic this promotion is necessary to be able to accept database writes to set up dr for cloud sql follow the steps described in the google cloud sql disaster recovery documentation using asynchronous database or storage replication causes a non zero rpo to help to ensure that your application can tolerate loss of most recent writes alternatively consider using another replication method secure secret management secrets like database passwords api keys and tls certificates are important aspects of dr you must be able to restore these secrets securely and reliably in a new cluster common approaches to secret management are as follows use external secrets use a tool like the external secrets operator to pull secrets from google secret manager backup secrets with oadp operator if you don t use an external store ensure that secrets are included in your backups regular rotation rotate secrets regularly and ensure your secret management strategy accommodates dr scenarios testing test secret restoration in a staged environment to confirm that all services can start with the provided credentials validation validate that your dr cluster has the necessary iam roles or authentication methods to retrieve secrets from external stores networking and traffic management use google cloud s global external https load balancer as the primary ingress point to distribute traffic between multiple openshift clusters for example primary and secondary clusters this global service directs user requests to the appropriate backend cluster based on proximity health and availability to connect the global load balancer to your openshift clusters you can use either of the following approaches use regional load balancers internet negs configure google cloud internet network endpoint groups negs to point to the external ip addresses of the regional load balancers exposing each of your openshift clusters ingress services ocp routers the global load balancer then routes traffic to these regional load balancer ips this approach provides an abstraction layer but involves a hop to an additional network direct pod routing compute engine_vm_ip_port negs configure the openshift ingress controller integration to use google cloud network endpoint groups negs of type compute engine_vm_ip_port this approach allows the global load balancer to target the openshift ingress controller router pods directly using their internal podip targetport this method bypasses the extra hop and additional node proxying it typically results in lower latency and enables more direct health checking from the global load balancer both setups allow the global load balancer to manage traffic distribution effectively across clusters in different regions to learn more see set up a global external application load balancer with an external backend vpcs we recommend the following approaches for vpc management shared vpc use a shared vpc to centralize network management for both primary and secondary clusters this approach simplifies administration and ensures consistent network policies across regions global dynamic routing enable global dynamic routing within your vpcs to automatically propagate routes between regions ensuring seamless connectivity between clusters custom mode vpcs use custom mode vpcs and create specific subnets in the regions where your clusters run this is often necessary for vpc native pod networking required by methods like compute engine_vm_ip_port routing vpc network peering if it s necessary for you to use separate vpc networks for each region and cluster use vpc network peering to connect the regions and clusters subnets and ip addresses create regional subnets in each region to maintain network segmentation and avoid ip address conflicts ensure that there are non overlapping ip ranges between regions to prevent routing issues cross cluster traffic with red hat service mesh openshift supports service mesh federation which enables communication between services deployed across multiple openshift clusters this function is particularly useful for dr scenarios where services might need to communicate across clusters during failover or data replication to learn how to set up service mesh federation between primary and secondary clusters see the red hat documentation active inactive design considerations this section describes the design considerations for an active inactive dr solution application configuration as code gitops we recommend that you adopt a gitops approach to store all cluster and application configurations in a git repository this approach enables quick restoration in a dr scenario by enabling syncing to a state that is known to be running reliably in another cluster backups ensure you have snapshots of your runtime state however you also need a reliable way to redeploy application logic manifests and infrastructure definitions rapidly after a disaster use the openshift gitops operator the openshift gitops operator based on argo cd provides a red hat supported way to implement gitops patterns directly within an openshift environment it automates the process of continuously reconciling your cluster state with your chosen configuration and stores it in a git repository the openshift gitops operator s controller continuously ensures that the cluster s state matches the configuration defined in this repository if resources drift or are missing it automatically reconciles them to learn more see about red hat openshift gitops dr scenario execution in the event of a disaster do the following set up a new openshift cluster in another region install the openshift gitops operator apply the same application manifest referencing your git repository the operator synchronizes the cluster state to match your repository quickly redeploying deployments services routes operators and any other resources that are defined in your code to help avoid any issues during dr we recommend that you do the following maintain strict branching and tagging strategies in your git repository so you can identify stable configurations suitable for dr check that your dr cluster has network connectivity and appropriate permissions to access the git repository include all resource types as code to avoid manual intervention during failover for example infrastructure components application workloads and configurations firewall rules define unified firewall policies and apply them consistently across both clusters to control traffic flow and enhance security follow the least privilege principle which means that you restrict the inbound and outbound traffic to only what s necessary for application functionality deployment to learn how to deploy a topology based on this reference architecture see the red hat documentation what s next learn how to implement monitoring and alerting for cluster health replication status backup success and application performance in both primary and secondary environments learn how to install openshift on google cloud learn more about red hat solutions on google cloud send feedback except as otherwise noted the content of this page is licensed under the creative commons attribution 4 0 license and code samples are licensed under the apache 2 0 license for details see the google developers site policies java is a registered trademark of oracle and or its affiliates last updated 2026 07 14 utc need to tell us...
|
