It is not particularly clear how to remove a vSphere Data Protection (VDP) external proxy in the vSphere Data Protection (VDP) 5.8 Administration Guide. Before I get into that specifically, I should probably start with what a VDP external proxy is and how it is deployed. The external proxy functionality is currently only available with the Advanced edition of VDP. External proxies are virtual appliances that are typically deployed to locations where the VDP appliance does not have direct access to storage, e.g., another cluster or perhaps even another site such as a branch office or remote office. This reduces the amount of network bandwidth required to transmit backup data across the network. An external proxy will utilize SCSI HotAdd to attach the protected VM’s disk(s) to an external proxy during a backup job. The external proxy will first query the VDP appliance to see if the backup data segment already exists in the VDP appliance’s backup data repository – either in the VDP appliance (GSAN) or on the Data Domain appliance, if Data Domain is being used to store VDP backup data. If the segment does exist, the external proxy will not send it again across the network. Without the external proxy, VDP would have to use the Network Block Device (NBD) protocol to back up remote VMs. In this scenario, all changes to the protected VMs would be sent across the network to the VDP appliance and deduplication would happen within the VDP appliance or on the Data Domain appliance.
Category Archives: Uptime
I often get questions regarding backup of a MySQL database server (VM) using vSphere Data Protection (VDP). VDP does not have an agent for MySQL, but you can of course perform an image-level (entire-VM) backup of a VM running MySQL. With VDP and many other backup solutions that use the vSphere APIs for Data Protection (VADP), the backup and recovery of Linux VMs is crash-consistent. In other words, there is no quiescing of the file system and applications running inside the VM when a backup of the VM is performed. When you recover a VM from a crash-consistent backup, it is similar to the state of the server when the power has failed unexpectedly (no graceful shutdown) and then power is restored. MySQL, as with other popular database solutions, has good, built-in protection against data loss and corruption when recovered from a crash-consistent state, but there are no guarantees. The goal is to minimize the chance of corruption and data loss. Here are a few recommendations when using VDP to back up a VM running MySQL:
The latest in our series of reference architectures is now available. This is an update to the previous version which brings in additional products and covers the vCloud Suite 5.8 release.
This reference architecture describes an implementation of a software-defined data center (SDDC) using VMware vCloud® Suite Enterprise 5.8, VMware NSX™ for vSphere® 6.1, VMware IT Business Management Suite™ Standard Edition 1.1, and VMware vCenter™ Log Insight™ 2.0 to create an SDDC. This SDDC implementation is based on real-world scenarios, user workloads, and infrastructure system configurations. The configuration uses industry-standard servers, IP-based storage, and 10-Gigabit Ethernet (10GbE) networking to support a scalable and redundant architecture.
Here’s a visualization we put together to help people understand the various offerings from VMware that can positively affect your levels of availability.
Hope you like it!
vSphere Replication is an excellent host-based, per-VM replication solution that is included with vSphere Essentials Plus Kit and higher editions. That’s right – if you have vSphere Essentials Plus or higher, you have vSphere Replication. There are several use cases for vSphere Replication: Migrating VMs from old hardware to new hardware, migrating VMs between data centers, and disaster recovery – with or without vCenter Site Recovery Manager (SRM) – to name a few. When talking with customers, we tend to cover the features and benefits for starters and move on to how it works – and then what happens when issues such as hardware failure, administrative mistakes, etc. occur.
In this article, we will not discuss all of the details around how it works, but at a high level, changed data for each protected VM is replicated from vSphere hosts at the source location to one or more vSphere Replication virtual appliance(s) at the target location. The vSphere Replication appliance(s) then write this replicated data to vSphere storage at the target location. This often raises questions about what happens if these vSphere Replication appliances go offline or are lost. That is what we will cover in this article.
Hot off of the press: A new white paper that discusses backing up virtual machines running on VMware Virtual SAN (VSAN) using VMware vSphere Data Protection (VDP). These are the main topics that are covered:
- VDP Architectural Overview
- Virtual SAN Backup using VDP
- Factors Affecting Backup Performance
The paper details test scenarios, how backup transport modes affect CPU and memory utilization of the VDP virtual appliance, and how the vSphere hosts management network is impacted when the Network Block Device over Secure Sockets Layer (NBDSSL) transport mode is utilized. The paper concludes with a summary of observations, recommendations when deploying the VDP virtual appliance to a Virtual SAN datastore, and some discussion around transport modes and running concurrent backups. A special thank you goes to Weiguo He for compiling this data and writing this paper!
A question came across my desk a few days ago around being able to automatically back up VMs that have been migrated by vCenter Site Recovery Manager (SRM). After a bit of thought, it seems this is fairly simple to solve. With SRM, I migrate VMs to a resource pool at my recovery site. Why you might ask? This resource pool is configured with shares set to “High”. This has no impact during normal operations, but when I migrate or fail over important workloads, I want to be sure these workloads have priority if there is contention for CPU and memory. However, this also creates a secondary benefit when it comes to backing up migrated VMs…
With the release of VMware vSphere Data Protection (VDP) 5.8, a new type or “identity” of VDP appliance was introduced. It is called VDP Replication Target. When deploying previous versions of VDP, you were presented with the option to deploy VDP, which does not require a license key, or VDP Advanced, which requires a license key. A question commonly asked is “Do I have to deploy and license VDP Advanced at the replication target location even though I do not intend to perform backups there?” With VDP Advanced 5.5, you do have to deploy a VDP Advanced appliance to serve as a replication target, but VMware provides a “zero-CPU” license at no additional charge to enable an appliance to serve as a replication target for VDP Advanced. More details can be found in this blog article. While this was a pretty good workaround, the process for deploying an appliance as a replication target has been improved with the introduction of the VDP Replication Target identity in VDP 5.8. Naturally, you can find more information on the new VDP appliance identity in the VDP Administrator Guide, but Mohan Amarnath and Suraj Vithalkar from EMC have provided an excellent white paper that covers VDP Replication Target in detail including use cases and best practices. Click here to download the VDP Replication Target white paper.
I am sure most of you have heard about the “Shellshock” vulnerability – if not, you can read about it here. Seeing that the vSphere Replication 5.8 virtual appliance is running Linux, a patch is required. This short blog article shows how to fix this issue in vSphere Replication 5.8. To review more details on this security advisory, please see this page.
With the release of vSphere Replication 5.8, it is now possible to replicate virtual machines from a vCenter Server environment to another vCenter Server environment and to vCloud Air Disaster Recovery. Please understand that does not mean you can replicate the same VM to both, but rather you can configure replication for a VM to one destination or the other using the same vSphere Replication 5.8 user interface. Before vSphere Replication 5.8, you could deploy version 5.5 for replication between vCenter Server environments or deploy version 5.6 for replication to vCloud Air Disaster Recovery, but not both.
I have recorded a few short videos – less than two minutes each – to demonstrate using vSphere Replication to replicate virtual machines to both a vCenter Server environment and to vCloud Air Disaster Recovery. These videos do not have audio, but it is easy to understand what is happening in each video thanks to the simple interface vSphere Replication provides us.