In storage and availability we’ll have a lot to talk about across the board: Some sessions will offer deeper examinations of our current products, others will give you a great exploration of some of the newer things VMware has to showcase.
I’ve made a list of some of the sessions put on by those of us in the storage and availability product team; it’s a good cross section from product marketing, product managers, and technical marketing people such as myself. Outside of the engineers who actually write the code, these are the people closest to the products you use, so sign up and hear something new. There are also sessions from our highly experienced field sales and technical teams — the experts at understanding how these products address customer requirements and explaining their value to our customers.
I’m personally doing a technical session with my colleague Rawlinson on Virtual SAN (STO4275) and looking forward to it quite a bit.
Lastly, don’t be shy to come say hello after the sessions. We love to hear your thoughts, if we’ve got time between activities…
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.
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.
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.
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.