Search the Community

Today, AWS Elastic Disaster Recovery (AWS DRS) announces support of AWS Outposts racks. With this launch, you can now set your data replication and recovery destinations to AWS Outposts racks, in addition to using AWS Regions and Availability Zones where AWS DRS is available. View the full article

We're excited to announce a major enhancement to Google Cloud Backup and DR, making it simpler than ever to safeguard your critical Google Compute Engine virtual machines (VMs). You can now leverage the power of Google Cloud tags, including inheritance, to easily configure backup policies for Compute Engine VMs, ensuring consistent protection of your dynamic cloud environments. The challenge of managing VM backups Managing backups for a large number of Compute Engine VMs can be complex, especially when VMs are frequently added, removed, or modified. Manually assigning backup policies to individual VMs is time-consuming and can be error-prone, potentially leaving vital resources unprotected. The power of tag-based backups With our new tag-based backup approach, you can leverage the organizational power of tags to automate the protection of your Compute Engine VMs. Here's how it works: Assign your tags: Apply meaningful tags to your organization, folders, projects, or directly to your VMs. These tags might reflect application names, environments (production, development, testing), or criticality levels. Create tag-based policies: Within Google Backup and DR, you can create backup policies with your desired backup schedules, retention periods, and recovery regions. After policy creation, you can assign them to specific tags. Automate protection: Any VM with a matching tag is automatically assigned the backup policy. New VMs inheriting those tags immediately gain protection. Benefits of tag-based backups Simplified management: Drastically reduce the administrative overhead of configuring VM backups at scale by updating the policy attached to the tag rather than at an individual VM backup level. Consistent protection: Ensure new VMs with inherited tags from the project, folder, or organization are automatically protected without manual intervention. Flexibility: Adjust your backup strategies easily by modifying tags or creating new tag-based policies, including support for tags assigned using Terraform For example, you can easily tag all production projects with the tag backupdr-dynamicprotect:production. You could then create a backup policy that does the following: Takes daily snapshots of VMs in those projects that inherit the backupdr-dynamicprotect:production tag Retains backups for 30 days Updates your Terraform script to include your new protection tag to ensure protection of every new Compute Engine instance that’s created Getting started Review the Google Backup and DR documentation on tag-based backups. Develop a tagging strategy for your Compute Engine VMs. Create backup policies that target your chosen tags. Attend ARC205, Protect your critical workloads and recover your most critical asset - your data at Google Cloud Next. View the full article

Starting today, AWS Elastic Disaster Recovery (DRS) is available in 12 additional Regions: US West (N. California), Africa (Cape Town), Asia Pacific (Hong Kong), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Canada (Central), Europe (Milan), Europe (Paris), Europe (Stockholm), Middle East (Bahrain), South America (São Paulo). View the full article

We are excited to announce that AWS Elastic Disaster Recovery (DRS) has added support for multiple staging and target accounts. Today you can replicate and protect up to 300 source servers per AWS account. By using multiple staging and target accounts, you can now also recover up to 3,000 replicating source servers into any target AWS account. This feature makes disaster recovery setup, implementation, and monitoring easier and more efficient, especially for large-scale projects. View the full article

A brief look at what DR is & a closer look at the different types of DR patterns available; https://faun.pub/google-cloud-disaster-recovery-2022-choosing-the-right-dr-pattern-ef463c78c7a0

AWS Resilience Hub now supports Amazon Elastic Container Service (Amazon ECS), Amazon Route 53, AWS Elastic Disaster Recovery, AWS Backup, and the ability to use Terraform as a source to upload applications. With this expansion of supported resources, you can use Resilience Hub to prepare and protect even more of your applications from disruptions. View the full article

The massive shift to remote work necessitated by the COVID-19 pandemic kickstarted many companies’ digital transformation. While this transition had already begun for most organizations, the pandemic sped up the timeline. These events also had an impact on how storage and backup is done. Let’s look at why the right storage solution is key to […] The post Fast Object Storage Key to Backup and DR Strategy appeared first on DevOps.com. View the full article

Starting today Amazon Relational Database Service (RDS) for Oracle supports Amazon RDS Cross-Region Automated Backups. This feature extends the existing RDS backup functionality, giving you the ability to setup automatic replication of system snapshots and transaction logs from a primary AWS Region to a secondary AWS Region. View the full article

A core capability of any distributed system, whether it is distributed for capacity or recovery reasons, is that the initial system can be reproduced. More often than not, large organizations document changes in a Word document that get manually applied to each and every environment. While this has served as a way to propagate changes to core systems essentially for decades, it is not a reliable way to reproduce a system in today’s distributed world... View the full article

Starting today Amazon Relational Database Service (RDS) for Oracle supports the creation of Oracle Data Guard physical standby DB instances which run in mount mode, which fully manage the configuration of Oracle Data Guard, and asynchronously replicates data over secured network connections between a primary DB instance and its physical standby mounted DB replicas. Amazon RDS for Oracle Data Guard mounted DB replicas require Oracle Enterprise Edition (EE) but not Oracle Active Data Guard. View the full article

Disaster Recovery is not a new concept, in fact it is a requirement for critical business systems for almost as long as those critical business systems have existed. For modern distributed systems, teams can encounter two types of potential failures - unintentional errors and deliberate malicious attacks. Both require human intervention, especially if the distributed system is exposed to multiple errors simultaneously. This article discusses how teams can take advantage of GitOps principles in order to design with recovery in mind and strengthen existing systems... View the full article

In the first blog posts of this series, we introduced the basic concepts for Application Lifecycle on Advanced Cluster Management and deployed an application to multiple clusters. In the second blog post, we showed how a Blue/Green deployment can be made by using Advanced Cluster Management. In the third blog post, we migrated our application across different regions by using Advanced Cluster Management. If you haven't read the previous blog posts yet, go ahead and read them. This post is a continuation and you will need the context from the previous ones. We are using the same infrastructure we used in the previous posts. See the following diagram: NOTE: Pay special attention to the different labels, as they will be used during the blog posts examples. Component Version Red Hat OpenShift Container Platform 4.5.7 Red Hat Advanced Cluster Management 2.0 Fix Pack 2.0.2 Disaster Recovery on Red Hat Advanced Cluster Management In the previous post we migrated our application across different regions using PlacementRules. In this blog post we are going to see how PlacementRules can help us with a basic Disaster Recovery scenario. Configuring required Advanced Cluster Managemen manifests We will re-use the Red Hat Advanced Cluster Management manifests used in the previous blog post, which means that we will be using the Namespace reverse-words-region and the Subscription reversewords-region-app-subscription. We will need to create a new PlacementRule. This time we will include new properties to our PlacementRule; let's review them: apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: us-eu-region-clusters namespace: reverse-words-region spec: clusterConditions: - type: "ManagedClusterConditionAvailable" status: "True" clusterSelector: matchExpressions: - key: region operator: In values: - EU - US matchLabels: {} clusterReplicas: 1 We are using the matchExpressions property in order to match any cluster that has a label region with a value of either EU or US. We are using the clusterReplicas property in order to get only one of the clusters that match the previous expression. Additionally, we are matching only healthy clusters. This new PlacementRule will make sure that in case one of the clusters moves to a non-healthy state, the cluster returned by the PlacementRule changes to one on the list that has a healthy state. Configuring Subscription to use the new PlacementRule Let's create the PlacementRule discussed in the previous section. oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/05_placement_rule_DR.yaml If we look at the clusters reported by the PlacementRule, we will only see one cluster (Production in this case). oc --context hub -n reverse-words-region get placementrule us-eu-region-clusters -o yaml <OMITTED_OUTPUT> status: decisions: - clusterName: managed-cluster1-dev clusterNamespace: managed-cluster1-dev Now we can go ahead and update the Subscription we used in the previous blog post. We are going to patch it to use the new PlacementRule we just created. oc --context hub -n reverse-words-region patch subscription.apps.open-cluster-management.io/reversewords-region-app-subscription -p '{"spec":{"placement":{"placementRef":{"name":"us-eu-region-clusters"}}}}' --type=merge The application will run in EU cluster (Development). See the following commands and output: oc --context dev -n reverse-words-region get deployments,services,pods NAME READY UP-TO-DATE AVAILABLE AGE deployment.extensions/reverse-words 1/1 1 1 42s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/reverse-words LoadBalancer 172.30.185.94 a520ed21ff982452abeacf63b0b58cc5-31012041.eu-central-1.elb.amazonaws.com 8080:32283/TCP 42s NAME READY STATUS RESTARTS AGE pod/reverse-words-68795d69ff-crzqp 1/1 Running 0 42s Now, I'm going to destroy my EU cluster in order to simulate a disaster; let's see what happens. NOTE: We actually destroyed the cluster, if you want to try this without destroying your cluster, you can remove the region: EU label from the cluster As soon as Red Hat Advanced Cluster Management detects my EU cluster is gone, the PlacementRule gets updated and now it points to the US cluster. oc --context hub -n reverse-words-region get placementrule us-eu-region-clusters -o yaml The PlacementRule now points to US cluster. <OMITTED_OUTPUT> status: decisions: - clusterName: managed-cluster2-prod clusterNamespace: managed-cluster2-prod The application has been moved automatically to the US cluster. oc --context pro -n reverse-words-region get deployments,services,pods NAME READY UP-TO-DATE AVAILABLE AGE deployment.extensions/reverse-words 1/1 1 1 76s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/reverse-words LoadBalancer 172.30.187.142 a1c7d218d901c40ac98375f4a9474084-1310645059.us-west-2.elb.amazonaws.com 8080:31095/TCP 78s NAME READY STATUS RESTARTS AGE pod/reverse-words-68795d69ff-ttzz5 1/1 Running 0 77s The EU cluster is gone. When the EU cluster is online again, it will get added to the PlacementRule again automatically Closing Thoughts During this blog posts series we have discovered the basics around Application Lifecycle management using Red Hat Advanced Cluster Management. Feel free to share your comments and keep exploring other Red Hat Advanced Cluster Management related blog posts. View the full article