Inspiring the next generation of global problem solvers, how Cisco is partnering with Global Citizen to recognize young leaders.
Shining a Spotlight on Young Leaders Who are Solving Global Problems
Together, Cisco and Duo are designing infrastructure for the extended enterprise where users, devices and applications are the center of the modern security architecture.
Securing Access for the New Perimeter with Duo Security
Veeam Backup & Replication is known for ease of installation and a moderate learning curve. It is something that we take as a great achievement, but as we see in our support practice, it can sometimes lead to a “deploy and forget” approach, without fine-tuning the software or learning the nuances of its work. In our previous blog posts, we examined tape configuration considerations and some common misconfigurations. This time, the blog post is aimed at giving the reader some insight on a Veeam Backup & Replication infrastructure, how data flows between the components, and most importantly, how to properly load-balance backup components so that the system can work stably and efficiently.
Overview of a Veeam Backup & Replication infrastructure
Veeam Backup & Replication is a modular system. This means that Veeam as a backup solution consists of a number of components, each with a specific function. Examples of such components are the Veeam server itself (as the management component), proxy, repository, WAN accelerator and others. Of course, several components can be installed on a single server (provided that it has sufficient resources) and many customers opt for all-in-one installations. However, distributing components can give several benefits:
- For customers with branch offices, it is possible to localize the majority of backup traffic by deploying components locally.
- It allows to scale out easily. If your backup window increases, you can deploy an additional proxy. If you need to expand your backup repository, you can switch to scale-out backup repository and add new extents as needed.
- You can achieve a High Availability for some of the components. For example, if you have multiple proxies and one goes offline, the backups will still be created.
Such system can only work efficiently if everything is balanced. An unbalanced backup infrastructure can slow down due to unexpected bottlenecks or even cause backup failures because of overloaded components.
Let’s review how data flows in a Veeam infrastructure during a backup (we’re using a vSphere environment in this example):
All data in Veeam Backup & Replication flows between source and target transport agents. Let’s take a backup job as an example: a source agent is running on a backup proxy and its job is to read the data from a datastore, apply compression and source-side deduplication and send it over to a target agent. The target agent is running directly on a Windows/Linux repository or a gateway if a CIFS share is used. Its job is to apply a target-side deduplication and save the data in a backup file (.VKB, .VIB etc).
That means there are always two components involved, even if they are essentially on the same server and both must be taken into account when planning the resources.
Tasks balancing between proxy and repository
To start, we must examine the notion of a “task.” In Veeam Backup & Replication, a task is equal to a VM disk transfer. So, if you have a job with 5 VMs and each has 2 virtual disks, there is a total of 10 tasks to process. Veeam Backup & Replication is able to process multiple tasks in parallel, but the number is still limited.
If you go to the proxy properties, on the first step you can configure the maximum concurrent tasks this proxy can process in parallel:
For normal backup operations, a task on the repository side also means one virtual disk transfer.
On the repository side, you can find a very similar setting:
For normal backup operations, a task on the repository side also means one virtual disk transfer.
This brings us to our first important point: it is crucial to keep the resources and number of tasks in balance between proxy and repository. Suppose you have 3 proxies set to 4 tasks each (that means that on the source side, 12 virtual disks can be processed in parallel), but the repository is set to 4 tasks only (that is the default setting). That means that only 4 tasks will be processed, leaving idle resources.
The meaning of a task on a repository is different when it comes to synthetic operations (like creating synthetic full). Recall that synthetic operations do not use proxies and happen locally on a Windows/Linux repository or between a gateway and a CIFS share. In this case for normal backup chains, a task is a backup job (so 4 tasks mean that 4 jobs will be able to generate synthetic full in parallel), while for per-VM backup chains, a task is still a VM (so 4 tasks mean that repo can generate 4 separate VBKs for 4 VMs in parallel). Depending on the setup, the same number of tasks can create a very different load on a repository! Be sure to analyze your setup (the backup job mode, the job scheduling, the per-VM option) and plan resources accordingly.
Note that, unlike for a proxy, you can disable the limit for number of parallel tasks for a repository. In this case, the repository will accept all incoming data flows from proxies. This might seem convenient at first, but we highly discourage from disabling this limitation, as it may lead to overload and even job failures. Consider this scenario: a job has many VMs with a total of 100 virtual disks to process and the repository uses the per-VM option. The proxies can process 10 disks in parallel and the repository is set to the unlimited number of tasks. During an incremental backup, the load on the repository will be naturally limited by proxies, so the system will be in balance. However, then a synthetic full starts. Synthetic full does not use proxies and all operations happen solely on the repository. Since the number of tasks is not limited, the repository will try to process all 100 tasks in parallel! This will require immense resources from the repository hardware and will likely cause an overload.
Considerations when using CIFS share
If you are using a Windows or Linux repository, the target agent will start directly on the server. When using a CIFS share as a repository, the target agent starts on a special component called a “gateway,” that will receive the incoming traffic from the source agent and send the data blocks to the CIFS share. The gateway must be placed as close to the system sharing the folder over SMB as possible, especially in scenarios with a WAN connection. You should not create topologies with a proxy/gateway on one site and CIFS share on another site “in the cloud” — you will likely encounter periodic network failures.
The same load balancing considerations described previously apply to gateways as well. However, the gateway setup requires an additional attention because there are 2 options available — set the gateway explicitly or use an automatic selection mechanism:
Any Windows “managed server” can become a gateway for a CIFS share. Depending on the situation, both options can come handy. Let’s review them.
You can set the gateway explicitly. This option can simplify the resource management — there can be no surprises as to where the target agent will start. It is recommended to use this option if an access to the share is restricted to specific servers or in case of distributed environments — you don’t want your target agent to start far away from the server hosting the share!
Things become more interesting if you choose Automatic selection. If you are using several proxies, automatic selection gives ability to use more than one gateway and distribute the load. Automatic does not mean random though and there are indeed strict rules involved.
The target agent starts on the proxy that is doing the backup. In case of normal backup chains, if there are several jobs running in parallel and each is processed by its own proxy, then multiple target agents can start as well. However, within a single job, even if the VMs in the job are processed by several proxies, the target agent will start only on one proxy, the first to start processing. For per-VM backup chains, a separate target agent starts for each VM, so you can get the load distribution even within a single job.
Synthetic operations do not use proxies, so the selection mechanism is different: the target agent starts on the mount server associated with the repository (with an ability to fail over to Veeam server if the mount server in unavailable). This means that the load of synthetic operations will not be distributed across multiple servers. As mentioned above, we discourage from setting the number of tasks to unlimited — that can cause a huge load spike on the mount/Veeam server during synthetic operations.
Scale-out backup repository. SOBR is essentially a collection of usual repositories (called extents). You cannot point a backup job to a specific extent, only to SOBR, however extents retain some of settings, including the load control. So what was discussed about standalone repositories, pertains to SOBR extents as well. SOBR with per-VM option (enabled by default), the “Performance” placement policy and backup chains spread out across extents will be able to optimize the resource usage.
Backup copy. Instead of a proxy, source agents will start on the source repository. All considerations described above apply to source repositories as well (although in case of Backup Copy Job, synthetic operations on a source repository are logically not possible). Note that if the source repository is a CIFS share, the source agents will start on the mount server (with a failover to Veeam server).
Deduplication appliances. For DataDomain, StoreOnce (and possibly other appliances in the future) with Veeam integration enabled, the same considerations apply as for CIFS share repositories. For a StoreOnce repository with source-side deduplication (Low Bandwidth mode) the requirement to place gateway as close to the repository as possible does not apply — for example, a gateway on one site can be configured to send data to a StoreOnce appliance on another site over WAN.
Proxy affinity. A feature added in 9.5, proxy affinity creates a “priority list” of proxies that should be preferred when a certain repository is used.
If a proxy from the list is not available, a job will use any other available proxy. However, if the proxy is available, but does not have free task slots, the job will be paused waiting for free slots. Even though the proxy affinity is a very useful feature for distributed environments, it should be used with care, especially because it is very easy to set and forget about this option. Veeam Support encountered cases about “hanging” jobs which came down to the affinity setting that was enabled and forgotten about. More details on proxy affinity.
Whether you are setting up your backup infrastructure from scratch or have been using Veeam Backup & Replication for a long time, we encourage you to review your setup with the information from this blog post in mind. You might be able to optimize the use of resources or mitigate some pending risks!
The end of general support for vSphere 5.5 was on September 19, 2018. There may be a number of questions for those customers that are still sitting on vSphere 5.5, like what version do I upgrade to? And what considerations do I need to make as part of the support upgrade path?
You have four options you first need to consider:
The first option is to stay on vSphere 5.5 in an unsupported fashion. This wouldn’t be the greatest of decisions, but I do understand that if this is the first time you are hearing of the end of general support, then you may not have the time and resources to make the change and upgrade. Another option may be to explore extended support options with VMware.
The third option could be getting everything to vSphere 6.0, which will be supported until March 12, 2020, so it will give you a few more years before this comes around again. This is the easiest step in terms of time and resources. For more information about this path read this VMware KB article. Don’t miss this important information before upgrading to vSphere 6.0 Update 1.
Now we get to the more interesting, and final, option because of the features and functionality that will become available with these next two releases.
vSphere 6.5 and vSphere 6.7 will see you in general support until Nov. 15, 2021. I will touch on some of the functionality you will gain by moving to this platform over the others later on.
- vCenter Server Appliance — If you are running a Windows-based VMware Virtual Center today, it might be time to consider this upgrade path since in 6.5, we saw a fully-featured version of the vCenter appliance. The appliance, as you will read later, is the future. It brings concise management, but also scale, ease of migration and the infamous Update Manager that is also embedded into the appliance.
- VM encryption — Always a bone of contention because with encryption of any data you lose out on something. In vSphere 6.5, you have the ability to encrypt virtual machines at rest, within the hypervisor and at the point the IO comes out of the virtual disk controller. This adds its own benefits alone, but there are more details here.
- vSAN — This won’t be applicable to all, especially if you are running your shared storage system to provide your VMware datastores where your virtual machines are stored, but a consideration to be made is to look at the capabilities that come with vSAN in the 6.5 release: erasure coding, stretch clustering, QoS, encryption and the list keeps on going.
- vCenter Management — Introducing the HTML5-based vSphere client. Now this should in no way be the deciding factor on jumping to this version as the HTML5 interface is not complete, and you will find yourself jumping between the interfaces to get things done, but it’s a good step. And as we get to vSphere 6.7, this is the only way to manage your vSphere environment.
The upgrade to 6.7 will depend on many things, including is your hardware compatible with the latest GA version from VMware? A lot has changed on that front, so be sure to check that. vSphere 6.7 was released last year at VMworld 2017 and it had a ton of new and exciting features and functionality that came with it. Amongst the wider offering from VMware, it wasn’t just vSphere; it was the surrounding products also.
I mentioned the HTML5 client. Well, in this release, we see things take a much broader step to be the management interface, including not having to jump between multiple windows to perform certain tasks. Another thing to add here is that vSphere 6.7 will be the last version that will support the vCenter Server being on Windows — VCSA all the way.
A couple of things to note for vSphere 6.7 and the storage scene: When it comes to deciding, the ability to use PMEM (Persistent Memory), which has similar characteristics of memory but retains the data during power cycles, really assists in some of those enterprise applications that just require everything to be faster. There is a whole white paper on this.
The most notable and significant vSAN release came with vSAN 6.7. Firstly, management can be done through the HTML5 interface rather than having to go through CLI and APIs. The vSAN iSCSI supports Windows Server Failover Clusters (WSFC). In 6.5, vSAN already supported modern Windows application layer clustering technologies, such as Microsoft SQL Always-on Availability Groups (AAG), Microsoft Exchange Database Availability Groups (DAG) and Oracle Real Application Clusters (RAC).
There is also the Adaptive Resync feature to ensure a fair share of resources is available for VM I/Os and Resync I/Os during dynamic changes in load on the system.
“vSAN continues to see rapid adoption with more than 10,000 customers and growing. A 600 million dollar run rate was announced for Q4FY2018, and IDC named it the #1 and fastest growing HCI Software Solution.”
Loads more on this can be found here in the What’s New with VMware vSAN 6.7.
There are heaps of other things to consider, but these are just a few things. Also, take a look at the security enhancements and TPM that also landed in vSphere 6.7.
More details on some useful smaller enhancements that could help a decision tree can be found in this VMware article.
How can Veeam help?
Veeam takes vSphere platform support very seriously and has done so since our company’s beginnings. One of the most effective ways that organizations can migrate to a newer vSphere platform is from Veeam replication.
This is a very powerful technique as organizations can migrate workloads to a new cluster with very little downtime and have the ability to fail back if needed. Additionally, this introduces the option of a new cluster. How many times are there things about the old cluster that you would like to change and not move forward to be stuck with forever? Migrating to a new cluster via Veeam replication can allow you to put in new design elements that can be the right choice today. You can find more about Veeam replication in the Veeam Help Center.
There have been lots of articles and walkthroughs on how to make that upgrade work for you, and how to get to a supported level of vSphere. This VMware article is very thorough walking through each step of the process.
But we wanted to touch on making sure your data is protected prior, during and after the upgrade events.
If we look at the best practice upgrade path for vSphere, we’ll see how we make sure we’re protected at each step along the way:
The first thing that needs to be considered is what path you’ll be taking to get away from the end of general support of vSphere 5.5. You have two options:
- vSphere 6.5 which is now going to be supported till November 2021 (so another 5 years’ time)
- vSphere 6.7 which is the latest released version from VMware.
Another consideration to make here is support for surrounding and ecosystem partners, including Veeam. Today, Veeam fully supports vSphere 6.5 and 6.7, however, vSphere 6.5 U2 is NOT officially supported with Veeam Backup & Replication Update 3a due to the vSphere API regression.
The issue is isolated to over-provisioned environments with heavily loaded hosts (so more or less individual cases).
It’s also worth noting that there is no direct upgrade path from 5.5 to 6.7. If you’re currently running vSphere 5.5, you must first upgrade to either vSphere 6.0 or vSphere 6.5 before upgrading to vSphere 6.7.
Management – VMware Virtual Center
The first step of the vSphere upgrade path after you’ve decided and found the appropriate version, is to make sure you have a backup of your vCenter server. The vSphere 5.5 virtual center could be a Windows machine or it could be using the VCSA.
Both variants can be protected with Veeam, however, the VCSA runs on a Postgres-embedded database. Be sure to take an image-level backup with Veeam and then there is a database backup option within the appliance. Details of the second step can be found in this knowledge base article.
If you’re an existing Veeam customer, you’ll already be protecting the virtual center as part of one of your existing backup jobs.
You must also enable VMware tools quiescence to create transactionally-consistent backups and replicas for VMs that do not support Microsoft VSS (for example, Linux VMs). In this case, Veeam Backup & Replication will use the VMware Tools to freeze the file system and application data on the VM before backup or replication. VMware Tools quiescence is enabled at the job level for all VMs added to the job. By default, this option is disabled.
You must also ensure Application-Aware Image Processing (AAIP) is either disabled or excluded for the VCSA VM.
Virtual Machine Workloads
If you are already a Veeam customer, then you’ll already have your backup jobs created and working with success before the upgrade process begins. However, as part of the upgrade process, you’ll want to make sure that all backup job processes that initiate through the virtual center are paused during the upgrade process.
If the upgrade path consists of new hardware but with no vMotion licensing, then the following section will help.
More information on Quick Migration can be found in our user guide.
During the upgrade process
As already mentioned in the virtual machine workloads section, it is recommended to stop all vCenter-based actions prior to update. This includes Veeam, but also any other application or service that communicates with your vCenter environment. It is also worth noting that whilst the vCenter is unavailable, vSphere Distributed Resource Scheduler (DRS) and vSphere HA will not work.
Veeam vSphere Web Client
If you’re moving to vSphere 6.7 and you have the Veeam vSphere Web Client installed as a vSphere plug-in, you’ll need to install the new vSphere Veeam web client plug-in from a post-upgraded Veeam Enterprise Manager.
More detail can be found in Anthony Spiteri’s blog post on new HTML5 plug-in functionality.
You’ll also need to ensure that any VMware-based products or other integrated products vCenter supports are the latest versions as you upgrade to a newer version of vSphere.
From a Veeam Availability perspective, the above steps are the areas that we can help and make sure that you are constantly protected against failure during the process. Each environment is going to be different and other considerations will need to be made.
Another useful link that should be used as part of your planning: Update sequence for vSphere 5.5 and its compatible VMware products (2057795)
One last thing is a shout out to one of my colleagues who has done an in-depth look at the vSphere upgrade process.
The post Get your data ready for vSphere 5.5 End of Support appeared first on Veeam Software Official Blog.
The No. 1 question we get all the time: “Why do I need to back up my Office 365 Exchange Online, SharePoint Online and OneDrive for Business data?”
And it’s normally instantaneously followed up with a statement similar to this: “Microsoft takes care of it.”
Do they? Are you sure?
To add some clarity to this discussion, we’ve created an Office 365 Shared Responsibility Model. It’s designed to help you — and anyone close to this technology — understand exactly what Microsoft is responsible for and what responsibility falls on the business itself. After all — it is YOUR data!
Over the course of this post, you’ll see we’re going to populate out this Shared Responsibility Model. On the top half of the model, you will see Microsoft’s responsibility. This information was compiled based on information from the Microsoft Office 365 Trust Center, in case you would like to look for yourself.
On the bottom half, we will populate out the responsibility that falls on the business, or more specifically, the IT organization.
Now, let’s kick this off by talking specifically about each group’s primary responsibility. Microsoft’s primary responsibility is focused on THEIR global infrastructure and their commitment to millions of customers to keep this infrastructure up and running, consistently delivering uptime reliability of their cloud service and enabling the productivity of users across the globe.
An IT organization’s responsibility is to have complete access and control of their data — regardless of where it resides. This responsibility doesn’t magically disappear simply because the organization made a business decision to utilize a SaaS application.
Here you can see the supporting technology designed to help each group meet that primary responsibility. Office 365 includes built-in data replication, which provides data center to data center georedundancy. This functionality is a necessity. If something goes wrong at one of Microsoft’s global data centers, they can failover to their replication target, and, in most cases, the users are completely oblivious to any change.
But replication isn’t a backup. And furthermore, this replica isn’t even YOUR replica; it’s Microsoft’s. To further explain this point, take a minute and think about this hypothetical question:
What has you fully protected, a backup or a replica?
Some of you might be thinking a replica — because data that is continuously or near-continuously replicated to a second site can eliminate application downtime. But some of you also know there are issues with a replication-only data protection strategy. For example, deleted data or corrupt data is also replicated along with good data, which means your replicated data is now also deleted or corrupt.
To be fully protected, you need both a backup and a replica! This fundamental principle has been the bedrock of Veeam’s data protection strategy for over 10 years. Look no further than our flagship product, aptly named Veeam Backup & Replication.
Some of you are probably already thinking: “But what about the Office 365 recycle bin?” Yes, Microsoft has a few different recycle bin options, and they can help you with limited, short-term data loss recovery. But if you are truly in complete control of your data, then “limited” can’t check the box. To truly have complete access and control of your business-critical data, you need full data retention. This is short-term retention, long-term retention and the ability to fill any / all retention policy gaps. In addition, you need both granular recovery, bulk restore and point-in-time recovery options at your fingertips.
The next part of the Office 365 Shared Responsibility Model is security. You’ll see that this is strategically designed as a blended box, not separate boxes — because both Microsoft AND the IT organization are each responsible for security.
Microsoft protects Office 365 at the infrastructure level. This includes the physical security of their data centers and the authentication and identification within their cloud services, as well as the user and admin controls built into the Office 365 UI.
The IT organization is responsible for security at a data-level. There’s a long list of internal and external data security risks, including accidental deletion, rogue admins abusing access and ransomware to name a few. Watch this five-minute video on how ransomware can take over Office 365. This alone will give you nightmares.
The final components are legal and compliance requirements. Microsoft makes it very clear in the Office 365 Trust Center that their role is of the data processor. This drives their focus on data privacy, and you can see on their site that they have a great list of industry certifications. Even though your data resides within Office 365, an IT organization’s role is still that of the data owner. And this responsibility comes with all types of external pressures from your industry, as well as compliance demands from your legal, compliance or HR peers.
In summary, now you should have a better understanding of exactly what Microsoft protects within Office 365 and WHY they protect what they do. Without a backup of Office 365, you have limited access and control of your own data. You can fall victim to retention policy gaps and data loss dangers. You also open yourself up to some serious internal and external security risks, as well as regulatory exposure.
All of this can be easily solved with a backup of your own data, stored in a place of your choosing, so that you can easily access and recover exactly what you want, when you want.
Looking to find a simple, easy-to-use Office 365 backup solution?
Look no further than Veeam Backup for Microsoft Office 365. This solution has already been downloaded by over 35,000 organizations worldwide, representing 4.1 million Office 365 users across the globe. Veeam was also named to Forbes World’s Best 100 Cloud Companies and is a Gold Microsoft Partner. Give Veeam a try and see for yourself.
- Gartner report: Adopt Microsoft Office 365 Backup for Damage Control and Fast Recovery After Malicious Attacks
- Veeam special report: 6 Critical Reasons for Office 365 Backup
- Three months FREE: Veeam Backup for Microsoft Office 365
As I meet more and more with our customers and partners, it’s clear that regardless of what industry you are in (retail, medical, agriculture, etc…) every company is becoming a…
The Cisco Blueprint Studio: Sharing the Cisco on Cisco Story with Our Customers
Many environments have the requirement to be flexible to what platform they are running. Flexibility allows for the ability to move, migrate and leverage data between each of their virtual environment assets. This also applies to extending into other cloud environments, whether that be for backup retention purposes, using a Veeam Cloud & Service Provider partner for managed service providers or expanding the production environment into the public cloud to offer further flexibility to the on-premises infrastructure.
Brief architecture overview
The agentless architecture for Veeam Availability for Nutanix AHV consists of a Veeam Backup Proxy Appliance that will reside within the AHV cluster. The requirement here is one proxy per cluster, and as a v1 product with extensive beta testing, we have not seen a requirement to scale this function out. The Veeam Backup Proxy Appliance is a lightweight installation, offering an intuitive Prism-like web UI that is used to manage the appliance itself, configure, schedule and run backups, and perform both full-VM recoveries and disk-based recoveries.
The Veeam Backup Proxy Appliance is required to have communication with a Veeam Backup & Replication server for authentication purposes, but this also extends recovery capabilities with the ability to perform file-level recoveries and application item-level recoveries using the established Veeam Explorers. Also, as an extension to the backup policy, you can leverage backup copy jobs or send AHV backups to tape. Finally, there’s the ability to do more with AHV data, like converting those backup files into VMDK, VHD and VHDX for use in different virtual environments, as well as sending and converting them to machines in Microsoft Azure, which is ideal for a testing environment with infinite and scalable resources.
The final thing to mention on the architecture is where the backup files are stored — a Veeam Backup & Replication repository, the primary reason for the communication and authentication from Veeam Backup Proxy Appliance to the Veeam Backup & Replication server.
Zero socket license
Because of the requirement for a Veeam Backup & Replication server and repository, a common question is “if we are moving completely to Nutanix AHV as our only hypervisor in the environment, how do we gain access to the required Veeam Backup & Replication components if we do not have a license for it?” This is essentially the same question in Veeam Agent-only customer environments with no virtualization in place, so the same answer applies.
All Veeam Availability for Nutanix AHV licenses (and Veeam Agent licenses) are delivered with a zero-socket license for Veeam Backup & Replication at no additional cost. The zero-socket license unlocks Veeam Backup & Replication functionality for AHV backups in environments where an existing Veeam Backup & Replication for VMware vSphere of Microsoft Hyper-V instance does not exist.
As mentioned above, many environments will have the requirement to run a multi-hypervisor infrastructure for numerous reasons. The possibilities from a management, backup and recovery perspective for AHV environments that have been brought with the release of Veeam Availability for Nutanix AHV have already been discussed, but if we were to also have a VMware vSphere or a Microsoft Hyper-V footprint alongside AHV, does this mean I have to have additional Veeam management components?
No, that same Veeam Backup & Replication management server and repository can be used for Nutanix AHV, VMware and Microsoft Hyper-V backups, as well as Veeam Agent backups. However, in some circumstances, there may be a requirement to have separate management for these environments, and that can be achievable using the zero socket license applicable in both AHV- or Veeam Agent-only environments. Remember, Veeam does not license the components that are licensed on the production workload, meaning you are able to have as many Veeam components as you see fit.
The post Veeam and Nutanix AHV in a multi-hypervisor environment appeared first on Veeam Software Official Blog.