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):
serves all user traffic under normal operating conditions secondary openshift cluster passive located in a separate google cloud region for fault isolation this cluster acts as the warm standby cluster it s partially set up and running and is ready to take over if the primary system fails it has the necessary infrastructure openshift configuration and application components deployed on it but it doesn t serve live production traffic until a failover event is triggered google cloud regions geographically isolated locations that provide the foundation for disaster recovery using separate regions ensures that a large scale event impacting one region doesn t affect the standby cluster global external https load balancer acts as the single global entry point for application traffic under normal conditions it s configured to route all traffic to the primary active cluster its health checks monitor the primary cluster s availability data replication mechanism continuous process or tools that are responsible for copying essential application data from the primary cluster to the secondary cluster for example databases or persistent volumes state this approach ensures data consistency and minimizes data loss during a failover helping you to meet your rpo monitoring and health checks systems that continuously assess the health and availability of the primary cluster and its applications for example cloud monitoring load balancer health checks internal cluster monitoring these systems are important for the quick detection of any failures failover mechanism a predefined process manual semi automated or fully automated to redirect traffic from the primary to the secondary cluster upon detection of an unrecoverable failure in the primary this process typically involves updating the global load balancer s backend configuration to target the secondary cluster making it the new active site vpc network the underlying google cloud network infrastructure that creates the necessary connectivity between regions for data replication and management active inactive deployments active inactive dr involves maintaining a secondary region as a standby which is activated only during disasters unlike active passive setups where data is continuously replicated this strategy relies on periodic backups that are stored in cloud storage with infrastructure provisioned and data restored during failover you can use tools such as velero integrated with openshift api for data protection oadp to perform periodic backups this approach minimizes costs making it ideal for applications that can tolerate longer recovery times it can also help organizations to align with extended recovery time objectives rto and recovery point objectives rpo in an active inactive dr scenario data is regularly backed up to the standby region but not actively replicated the infrastructure is provisioned as part of the failover process and data is restored from the most recent backup you can use the openshift api for data protection oadp which is based on the velero open source project to perform regular backups we recommend that you store these backups in cloud storage buckets with versioning enabled in the event of a disaster you can use oadp to restore the contents of the cluster this approach minimizes ongoing costs but results in longer rto and potentially higher rpo compared to active passive this setup is suitable for applications with longer recovery time objectives the following diagram shows an active inactive deployment and the failover process the failover process is as follows a dr event is triggered when a monitored service becomes unavailable a pipeline automatically provisions infrastructure in the dr region a new openshift cluster is provisioned application data secrets and objects are restored from the latest backup through oadp cloud dns record is updated to point to the regional load balancers in the dr region as shown in the preceding diagram 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 l...
|
