Your Browser is Out of Date

ShareDemos uses technology that works best in other browsers.
For a full experience use one of the browsers below

Blogs

Short articles related to PowerProtect Data Manager.

Blogs(4)

Tag :

All Tags

Author :

All Authors

PowerProtect PowerProtect Data Manager AWS

PowerProtect Data Manager – Protecting AWS EKS (Elastic Kubernetes Service)

Eli Persin

Thu, 06 Jan 2022 15:32:25 -0000

|

Read Time: 0 minutes

Recently I had the chance to deploy PowerProtect Data Manager 19.9 on AWS with a PowerProtect DD Virtual Edition and I wanted to test the AWS EKS (Elastic Kubernetes Service) protection feature to see the differences between any other Kubernetes deployments.

The PowerProtect Data Manager deployment itself was super easy. Initiated from the AWS marketplace, it created a CloudFormation stack that deployed all of the needed services after asking for network and other settings. What I especially liked about it was that it deployed the PowerProtect DD as well, so I didn’t have to deploy it separately.

Deploying and configuring the EKS cluster and its Node-Group was easy, but the installation of AWS EBS CSI drivers was a bit challenging, so I decided to share the procedure and my thoughts so others could do it just as easily.

Before you begin, you should make sure that you have kubectl and AWS CLI installed on your computer.

I started by deploying the EKS cluster using the AWS management console and used the 1.21 version (which was also the default one). I then created a Node-Group just as described in the AWS documentation. (This step involved attaching a role, but other than that it’s very intuitive and you could manage on your own without the documentation).

It’s highly recommended to read all of the relevant documentation to understand the following steps. I’ll summarize what I did.

I know it has a lot of steps and it looks scary, but this would probably make your life so much easier and will get you protecting EKS namespaces in no time!

1. Configure kubectl to allow you to connect to the EKS cluster:

aws eks --region <region-code> update-kubeconfig --name <eks-cluster-name

2. Create a secret.yaml file on your computer, which will be used to configure the AWS EBS CSI drivers. 

Add your credentials to the file itself. The required permissions are described here:

https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html).

The yaml structure and more details are available at the AWS EBS CSI driver git page here:

aws-ebs-csi-driver/secret.yaml at master · kubernetes-sigs/aws-ebs-csi-driver · GitHub

 3. Apply the secret:

kubectl apply -f secret.yaml

4. Install the EBS CSI driver:

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.2"  

5. The default storage class on EKS is gp2. Because PowerProtect Data Manager does not support it, it needs to be changed to EBS-SC which works with the EBS CSI driver.

Install the EBS Storage Class.

kubectl apply -f ebs-sc.yaml 

6. Apply all of these: 

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/snapshot/specs/classes/snapshotclass.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

7. Change the default Storage Class to EBS:

kubectl patch storageclass gp2 -p "{\"metadata\": {\"annotations\":{\"storageclass.kubernetes.io/is-default-class\":\"false\"}}}" 

kubectl patch storageclass ebs-sc -p "{\"metadata\": {\"annotations\":{\"storageclass.kubernetes.io/is-default-class\":\"true\"}}}" 

8. Create a service account on the EKS cluster in order to connect to the PowerProtect Data Manager server and allow the EKS cluster discovery:

kubectl apply -f ppdm-discovery.yaml 

9. Create another one for the protection itself:

kubectl apply -f ppdm-rbac.yaml

Both of the previous yaml files can be found on any PowerProtect Data Manager at the following path: /usr/local/brs/lib/cndm/misc/rbac.tar.gz

At this point you should already have, or should create, a new namespace on your EKS cluster and have an application that you want to protect running on it.

10. List the secrets in the powerprotect namespace that was created by running the previous yaml file:

kubectl get secret -n powerprotect  

11. Get the relevant secret from the list that you got from the previous command (the name will change in every deployment, but should be in the following format):

kubectl describe secret ppdm-discovery-serviceaccount-token-45abc -n powerprotect

This will output a string with the secret that you need in order to register the EKS cluster in PowerProtect Data Manager. 

12. Get the FQDN to register the EKS cluster (You’re looking for the Kubernetes control plane, and must remove the “https://”):

kubectl cluster-info 

13. Get the EKS Cluster Certificate authority from the AWS EKS cluster UI, and convert it from BASE64. Use this website for example: https://www.base64decode.org/.

14. SSH to the PowerProtect Data Manager server, then create a new eks-root.pem file with the decoded BASE64 result (including the BEGIN and END CERTIFICATE lines).

15. Run the following command:

keytool -importcert -alias <your-eks-cluster-name> -keystore /etc/ssl/certificates/extserver/extserver.truststore -storepass extserver -file eks-root.pem

16. Connect to the PowerProtect Data Manager UI, and add a new Kubernetes Asset Source.

Use the FQDN from Step 12 (again, without the https://) and create new credentials with the Service Account Token that you got in Step 11. 

After the EKS cluster is added as an Asset Source, you can protect the namespaces in your EKS cluster by creating a new Protection Policy. For more info, check out the interactive demos at the Dell Technologies Demo Center.

Author: Eli Persin   

LinkedIn

Read Full Blog
data protection Kubernetes disaster recovery PowerProtect Data Manager

Protect your SUSE Rancher managed RKE downstream Kubernetes workloads with Dell EMC PowerProtect Data Manager

Vinod Kumaresan

Thu, 09 Dec 2021 15:43:41 -0000

|

Read Time: 0 minutes

Together, We Stop at Nothing!

We have been continuously working to extend the level of support for Kubernetes with Dell EMC PowerProtect Data Manager, to protect Kubernetes workloads on different platforms.

With this continued services path, we now protect SUSE Rancher managed Kubernetes workloads with PowerProtect Data Manager by taking advantage of a partnership with SUSE Rancher.

Kubernetes cluster and containers have become a popular option for deploying enterprise applications in the cloud and in on-premise environments. SUSE Rancher is a Kubernetes management platform that simplifies cluster installation and operations, whether they are on-premises, in the cloud, or at the edge, giving the freedom to build and run containerized applications. PowerProtect Data Manager protects SUSE Rancher managed Kubernetes workloads and ensures high availability and consistent, reliable backup and restore for Kubernetes workloads during normal operations or during a disaster recovery situation.

Protect SUSE Rancher managed Rancher Kubernetes Engine (RKE) downstream workloads with PowerProtect Data Manager

PowerProtect Data Manager enables customers to protect, manage, and recover data for on-premises, virtualized, or cloud deployments. Using PowerProtect Data Manager, customers can discover, protect, and restore workloads in a SUSE Rancher managed Kubernetes environment to ensure that the data is easy to backup and restore.

PowerProtect Data Manager enhances the protection by sending the data directly to the Dell EMC PowerProtect DD series appliance to gain benefits from unmatched efficiency, deduplication, performance, and scalability. See the solution brief and this technical white paper for more details.

About SUSE Rancher and RKE

SUSE Rancher is an enterprise computing platform for running Kubernetes for on-premises, cloud, and edge environments. With Rancher, you can form your own Kubernetes-as-a-Service by creating, upgrading, and managing Kubernetes clusters. Rancher can set up clusters by itself or work with a hosted Kubernetes provider. It addresses the operational and security challenges of managing multiple Kubernetes clusters anywhere. SUSE Rancher also provides IT operators and development teams with integrated tools for building, deploying, and running cloud-native workloads.

SUSE Rancher supports the management of CNCF-Certified Kubernetes distributions, such as Rancher Kubernetes Engine (RKE). RKE is a certified Kubernetes distribution for both bare-metal and virtualized servers.

Protecting data by integrating SUSE Rancher managed RKE downstream Kubernetes clusters with PowerProtect Data Manager

You can integrate PowerProtect Data Manager with SUSE Rancher managed Kubernetes clusters through Kubernetes APIs to discover namespaces and associated persistent resources PersistentVolumeClaims (PVCs). PowerProtect Data Manager discovers the Kubernetes clusters using the IP address or fully qualified domain name (FQDN). PowerProtect Data Manager uses the discovery service account and the token kubeconfig file to integrate with kube-apiserver.

PowerProtect Data Manager integrates with SUSE Rancher managed Kubernetes clusters for data protection in the following ways:

  • Directly connecting to the RKE downstream single node with controlplane and etcd roles.
  • Through an external load balancer, when there are multiple RKE nodes for high availability with controlplane and etcd roles in an RKE downstream cluster.

SUSE Rancher managed RKE downstream Kubernetes clusters integration with PowerProtect Data Manager

Adding the RKE downstream Kubernetes cluster with PowerProtect Data Manager as an asset source

Once the Kubernetes cluster is added as an asset source in PowerProtect Data Manager and the discovery is complete, the associated namespaces are available as assets for protection. PowerProtect Data Manager protects two types of Kubernetes cluster assets: Namespaces and PVCs. Note that PPDM also protects the associated metadata for namespaces and cluster resources that include secrets, ConfigMaps, custom resources, RoleBindings, and so on. 

During the discovery process, PowerProtect Data Manager creates the following namespaces in the cluster:

  • Velero-ppdm: This namespace contains a Velero pod to back up metadata and stage to target storage in bare-metal environments. It performs PVC snapshot and metadata backup for VMware cloud native storage.
  • PowerProtect: This namespace contains a PowerProtect controller pod to drive persistent volume claim snapshot and backup, and to send the backups to the target storage using dynamically deployed cProxy pods.

Kubernetes uses persistent volumes to store persisted application data. Persistent volumes are created on external storage and then attached to a particular pod using PVCs. PVCs are included along with other namespaces in PowerProtect Data Manager backup and recovery operations. Dell EMC PowerStore, PowerMax, XtremIO, and PowerFlex storage platforms all come with CSI plugins to support containerized workloads running on Kubernetes. 

With this easy integration for data protection with PowerProtect Data Manager, Dell Technologies empowers Kubernetes admins to perform backup/recovery operations and ensure that SUSE Rancher managed Kubernetes cluster workloads are available, consistent, durable, and recoverable.

For more details, see the white paper SUSE Rancher and RKE Kubernetes cluster using CSI Driver on DELL EMC PowerFlex about how to protect SUSE Rancher managed Kubernetes workloads with PowerProtect Data Manager.

Author: Vinod Kumaresan


Read Full Blog
disaster recovery Azure PowerProtect Data Manager AWS Cloud DR

Cloud DR - Deployments over a Private Network

Eli Persin

Thu, 14 Oct 2021 12:15:16 -0000

|

Read Time: 0 minutes

Dell EMC launched Cloud Disaster Recovery (Cloud DR) in 2017, to help customers expand their DR to the cloud and meet their compliance demands, and to give them peace of mind about running their workloads in the cloud in case of a disaster scenario. 

The initial phase was to support the most used cloud platforms back then, AWS and Azure, and focus on simplicity and automation, all while leveraging existing data protection technologies that customers already have, such as Avamar and Data Domain. 

From its first release, Cloud DR supported automated deployment. This process created everything the solution needed on the customer’s cloud account, and was initiated from the on-prem component (the Cloud DR Add-on (CDRA))  over the internet -- the most common way to connect small or medium size organizations to the cloud.

Over time, more and more organizations reached a level of maturity of cloud usage: in the way they worked with it, protected their resources running on the cloud, and in how they planned to combine that with their on-prem resources. All of this resulted in larger organizations requiring more advanced and up-to-date features that Cloud DR already offered.

To support those new and larger organizations, Cloud DR’s core functionality was integrated into additional data protection technologies, such as RecoverPoint for VMs, PowerProtect Data Manager, and PowerProtect DP (what used to be called IDPA), so organizations who were already working and using these solutions would also be able to benefit from Cloud DR features and to protect and recover their VMs to, and on, the cloud.

 

Naturally, larger organizations are more complex. They usually combine their cloud and on-prem resources, connecting the environments with VPN. Some also use a dedicated network (such as Direct Connect in AWS or ExpressRoute in Azure).

These customers wanted to leverage their private connections for the deployment and usage, but since Cloud DR's core ability was to deploy over the public internet and create its AWS or Azure resources with an auto generated public IP (because it was the original design that fit almost all of the customers, and because some customers had strict security rules preventing any public IP creation), there was naturally a rising demand to add support for VPN connections, without creating or using any public IP. 

To address that concern, a solution was introduced for CDRA users to switch the way the CDRA communicates with the Cloud DR Server (CDRS), changing its default deployment from using a public IP to using its private IP, but this was relevant only for CDRA and only for specific Cloud DR releases (19.5 - 19.8).

In Cloud DR 19.9 (which is also included in PowerProtect Data Manager 19.9), released in September 2021, this requirement is further simplified. Cloud DR allows you to deploy over your existing private connection. In the web UI, you can also easily select whether you want to deploy through the internet and create a public IP, or deploy through your private network. 

While the Cloud DR interface makes it easy and intuitive to select the connection mode, it’s important that you configure the networks properly to support private connectivity. (The most common cause for failed deployments is related to misconfigured networks, routing, and firewalls.) 

This new feature should work as-is for well configured environments. You need to make sure your on-prem CDRA or PowerProtect Data Manager can reach and send its protected data to the cloud object storage (AWS S3 bucket / Azure Storage Account) over VPN. That’s because by default the object storage is reachable through the internet. Of course, you can also keep and use that default behavior and make sure that the CDRA or PowerProtect Data Manager can also send files through the internet, and connect to the CDRS through your VPN connection.

With Cloud DR and PowerProtect Data Manager you can protect your workloads with an easy deployment to your cloud account, and now also with a simplified deployment over your VPN.

Be sure to check out our Cloud DR best practices white paper, demos, and interactive demos:

Cloud DR Best practices whitepaper

Demos:

Interactive Demos:

Author: Eli Persin

 

Read Full Blog
VMware Oracle data protection PowerProtect PowerProtect Data Manager

A Quick Update on how PowerProtect Data Manager Discovers Oracle Databases

Frank Gagnon

Wed, 29 Sep 2021 13:47:43 -0000

|

Read Time: 0 minutes

There’s a new Oracle database discovery method introduced in PowerProtect Data Manager version 19.9!

Dell EMC PowerProtect Data Manager provides software defined data protection, automated discovery, deduplication, operational agility, self-service, and IT governance for physical, virtual, and cloud environments. PowerProtect Data Manager helps you to:

  • Orchestrate protection directly through an intuitive interface or empower data owners to perform self-service backup and restore operations from their native applications
  • Enjoy unique VMware protection: Protect VMware VMs without business disruption
  • Ensure compliance and meet even the strictest service level objectives
  • Leverage your existing Dell EMC PowerProtect appliances

PowerProtect Data Manager gives you valuable insight into protected on-premises and in-cloud workloads, applications, file systems, and virtual machines. Designed with operational simplicity and agility in mind, PowerProtect Data Manager enables protecting traditional workloads, such as Oracle, Exchange, SQL, SAP HANA, and file systems, as well as Kubernetes containers and virtual environments.

PowerProtect Data Manager supports discovering Oracle databases through either the traditional /etc/oratab file located on the Oracle server or starting in PPDM 19.9, by using Oracle PMON (Process MONitor) processes. Let’s review these two methods.

Method 1:

PowerProtect Data Manager uses the /etc/oratab file to discover Oracle databases. Note that since the appearance of Oracle release 12.2, Oracle no longer updates the /etc/oratab file with information such as ORACLE_HOME and ORACLE_SID automatically. Administrators can still update the /etc/oratab file manually to continue using this discovery method.

Here’s an example of an /etc/oratab file with entries for a database called “oradb105”.

Method 2:

PowerProtect Data Manager 19.9 introduces a new mechanism for discovering Oracle databases. This method uses information contained in the Oracle PMON processes and doesn’t have dependencies on /etc/oratab entries.  PMON is an Oracle background process created when a database instance is started.

Here’s an example of a PMON process for the same database mentioned earlier:  

The PMON process contains the name of the database. The PowerProtect Data Manager discovery job will look for those PMON processes and add the database to the asset list (as in the following figure).

In conclusion, PowerProtect Data Manager no longer requires entries in the /etc/oratab to discover Oracle databases. Those entries will continue to have the highest precedence, but it will also look for Oracle PMON processes to gather the full list of assets.

I urge you to check out this interactive demo of PowerProtect Data Manager 19.9.

For more information, see the whitepaper PowerProtect Data Manager: Oracle® RMAN Agent Backup and Recovery that provides details about the Oracle RMAN agent architecture and the backup and restore workflow. 

Author: Frank Gagnon


Read Full Blog