Technical track 2: arcserve UDP for virtualization & cloud
•Als PPTX, PDF herunterladen•
2 gefällt mir•3,508 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie Technical track 2: arcserve UDP for virtualization & cloud
Ähnlich wie Technical track 2: arcserve UDP for virtualization & cloud (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Technical track 2: arcserve UDP for virtualization & cloud
- 1. Solutions for Virtualization & Cloud Christopher Evans – Principal Consultant, Technical Sales Americas Miami May 12th – 14th
- 2. Agenda & live demo focus areas 2 Virtualization Virtual Standby Cloud Copyright © 2014 CA. All rights reserved.
- 3. Virtualization Copyright © 2014 CA. All rights reserved.
- 4. Virtual environments expectations Reduced operating expenses Reduced administration effort Increased reliability/availability Rapid application deployment Streamlined disaster recovery 4 ? Copyright © 2014 CA. All rights reserved.
- 5. Virtualization best practices Test that the physical system works, before virtualizing it Document your IT environment and create a diagram Only create new virtual servers, when you really need them Make sure you backup your virtual servers! – Agentless vs. Agent Based – Transport modes – One solution for VMs and a different solution for physical servers? – Backup: 2D, 2T or D2D2T, and restore from tapes 5Copyright © 2014 CA. All rights reserved.
- 6. Solution Overview Agentless backup for VMware & Hyper-V host environments Enables single-pass backup of all VMs without the need to install software agents on each VM Integrates with VMware vStorage API’s Only backs up changed blocks Application consistent (Exchange, SQL etc.) & transaction-log purge Easily recover individual files & folders from within each VM Centralized node, group & plan management from UDP Console arcserve® agentless host-based backup 6 PRIMARY SITE PROTECTS VMs, VOLUMES, FILES, DATABASES, APPLICATIONS & RAW DEVICE MAPPINGS (vRDM & pRDM) vSPHERE FARM OR HYPER-V FULL VM RESTORE & GRANULAR RESTORE GRANULAR RESTORE DIRECTLY FROM TAPE PRIMARY SITE RECOVERY POINT SERVER TAPE BACKUP DISK, TAPE OR CLOUD GLOBAL DEDUPE CENTRALIZED MANAGEMENT Copyright © 2014 CA. All rights reserved.
- 7. Demo environment “MANAGER” “Hyper-V” UDP CONSOLE / UDP Agent (Proxy) / RPS Server (Destination) “vSphere” 7Copyright © 2014 CA. All rights reserved.
- 8. Demo Copyright © 2014 CA. All rights reserved.
- 9. arcserve® for Citrix XenServer environments Copyright © 2014 CA. All rights reserved. 9 Solution Overview Protection for Citrix XenServer host environments Single-pass volume backup within each guest VM Infinite Incremental (I2 Technology)TM backups Application consistent backups (Exchange, SQL etc.) Easily recover individual files & folders from within each VM, or whole VMs via BMR Cross-hypervisor restore and Virtual Standby to Hyper-V & VMware vSphere Centralized node, group & policy management PROTECTS VOLUMES, FILES, DATABASES & APPLICATIONS XENSERVER FARM STANDALONE XENSERVER PRIMARY SITE GLOBAL DEDUPE FULL VM RESTORE & GRANULAR RESTORE GRANULAR RESTORE DIRECTLY FROM TAPE TAPE BACKUP DISK, TAPE OR CLOUD RECOVERY POINT SERVER CENTRALIZED MANAGEMENT
- 10. Virtual standby Copyright © 2014 CA. All rights reserved.
- 11. Solution Overview Local & remote virtual standby Periodic, image-based system, application & data protection for physical servers & VMs Replicate to remote location (remote office, DR site, MSP & Cloud) Run recovery point conversion into VHD or VMDK formats at the remote site to a virtual server Register with Hypervisor Server heartbeat monitoring Automated or manual failover to remote resources arcserve® Unified Data Protection 11 PHYSICAL OR VIRTUAL REPLICA SERVERS PHYSICAL OR VIRTUAL SERVERS RECOVERY POINT SERVER VIRTUAL STANDBY PROXY BMR RECOVERY POINT SERVER LOCAL & REMOTE USERS PRIMARY SITE WAN OPTIMIZED REPLICATION GLOBAL DEDUPE REMOTE SITE CENTRALIZED MANAGEMENT Copyright © 2014 CA. All rights reserved.
- 12. Demo environment “MANAGER”“Hyper-V” “vSphere” “RPS-R” (no console) “RPS-MSP” “vSphere” “vSphere” REMOTE SITEPRIMARY SITE UNIFIED MANAGEMENT 12Copyright © 2014 CA. All rights reserved.
- 13. Demo Copyright © 2014 CA. All rights reserved.
- 14. 3 types of Virtual Standby Local VSB Remote VSB Customer side: MSP side: (Local) Virtual Standby: 2 tasks Remote Virtual Standby: 3+ tasks Remotely-managed Virtual Standby: 2 plans, 4+ tasks (across 2 UDP Consoles) Copyright © 2014 CA. All rights reserved. 14
- 15. Cloud
- 16. Cloud expectations Copy/move source files to cloud − Improve efficiency − Regulatory compliance − Reduce local/on-premise storage costs − Multiple file versions Supported Cloud Vendors: − Amazon S3 − Windows Azure − Eucalyptus-Walrus − Fujitsu Cloud (Windows Azure) 16Copyright © 2014 CA. All rights reserved.
- 17. arcserve® UDP & Cloud Copyright © 2014 CA. All rights reserved. 17 Solution Overview Fast, simple, efficient image- based backup to cloud for Windows & Linux applications Perform local backup to disk Schedule offsite copy/archive to cloud Supports Amazon, Windows Azure, Fujitsu Cloud & Eucalyptus-Walrus Cloud platforms Recover from local resources if available Recover files from cloud, for disaster recovery PUBLIC & PRIVATE CLOUD GRANULAR RESTORE FILE COPY / ARCHIVE RESTORE LOCAL & REMOTE USERS PRIMARY SITE FILES DATABASES APPLICATIONS WINDOWS OR LINUX PHYSICAL OR VIRTUAL RECOVERY POINT SERVER CLOUD GLOBAL DEDUPE UNIFIED MANAGEMENT
- 18. arcserve® UDP & Cloud 18Copyright © 2014 CA. All rights reserved.
- 19. arcserve® UDP & Cloud PRIMARY SITE FILES DATABASES APPLICATIONS WINDOWS OR LINUX PHYSICAL OR VIRTUAL RECOVERY POINT SERVER AMAZON EC2 CLOUD GLOBAL DEDUPE UNIFIED MANAGEMENT RECOVERY POINT SERVER 19Copyright © 2014 CA. All rights reserved.
- 20. Cloud best practices Must have a Cloud account Amazon − configure a VPC (Amazon Virtual Private Cloud) connection − Register the AWS account and credentials − retrieve the VPC ID associated to the account − Decide the EC2 instance and launch it − remotely deploy the arcserve UDP/RPS 20Copyright © 2014 CA. All rights reserved.
- 21. Summary
- 22. Summary “MANAGER” “Hyper-v” “vSphere” Replica RPS Remote RPS (MSP) Virtual standby Virtual standby Virtual standby PRIMARY SITE REMOTE SITE / CLOUD 22Copyright © 2014 CA. All rights reserved.
- 23. Questions Copyright © 2014 CA. All rights reserved.
- 24. Licensing & pricing options Chris Evans Principal Consultant 13th -14th May 2014 Copyright © 2014 CA. All rights reserved.
- 25. Copyright © 2014 CA. All rights reserved. 25 Before Thousands of SKUs Dozens of options Legacy pricing Complex choices After 5 primary SKUs Simplified options Competitive Channel-friendly Versions Includes Licensing Options Per TB Per Socket Per Workstation Standard UDP File Server Protection Basic Tape N/A Advanced All UDP Components Basic Tape N/A Premium All UDP Components Premium Tape (ASBU) File-level Replication N/A Premium Plus All UDP Components Premium Tape (ASBU) Premium HA (RHA) N/A Workstation UDP Windows Workstation Protection Basic Tape N/A N/A Per-socket prices offered for both virtual & physical servers. arcserve® UDP: Simple & flexible licensing
- 26. Customer service & support Chris Evans Principal Consultant 13th -14th May 2014 Copyright © 2014 CA. All rights reserved.
- 27. Customer Success Delivering world-class customer service & support, with 24x7 global access Online knowledge base Ask CA Support live chat Self-service support tickets Product documentation Certified device lists Software compatibility Online training Global user community & forums Downloads, beta’s, patches CA arcserve Tech Insider support newsletter Direct access to the UDP Knowledge Centre from within the UDP product Customer success Copyright © 2014 CA. All rights reserved. 30
- 28. THANK YOU Copyright © 2014 CA. All rights reserved.
- 29. Legal Copyright © 2014 CA. All rights reserved. Microsoft, Windows, Windows Azure, Windows Server, Hyper-V, Active Directory, SQL Server, and SharePoint are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark of the open Group in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. All other trademarks, trade names, service marks and logos referenced herein belong to their respective companies. THIS PRESENTATION IS FOR YOUR INFORMATIONAL PURPOSES ONLY. CA Technologies assumes no responsibility for the accuracy or completeness of the information. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA TECHNOLOGIES PROVIDES THIS DOCUMENT “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. In no event will CA Technologies be liable for any loss or damage, direct or indirect, in connection with this presentation, including, without limitation, lost profits, lost investment, business interruption, goodwill, or lost data, even if CA Technologies is expressly advised of the possibility of such damages. Copyright © 2014 CA. All rights reserved.
Hinweis der Redaktion
- I like to talk a little about expectations because everyone does something for a reason and they expect certain business benefits to come out of their actions. You may have had to provide your management with a cost / benefit analysis to approve you spending your time and purchasing the Hypervisor software licenses to use in production. The first thing people look for is often reductions in operating expenses. Less money spent on physical hardware acquisition and maintenance because you consolidated several physical servers onto one physical server running several virtual servers. This also saves on your monthly electric bill in two ways – First there is a server power usage savings having unplugged several physical servers. Second there is a power savings in your air conditioning costs since you now have less servers generating heat in your computer room. You may also see a reduction in your data center costs if you have to pay for rack space as you will need less of that moving forward. Some people may look for savings in Administration effort saying virtual servers are easier to manage than physical servers. This is not necessarily always the case as virtual servers require new ways of managing and protecting. Your administrators will all have to be trained how to handle issues with virtual servers now. Training is very important as you can’t always be available to handle all the issues that could arise and are unique to virtual servers. You will also need the right tools in place to better track and manage your virtual and physical servers to help you more efficiently manage them. We will talk more about this later on.
- Now lets look at a few industry best practices to keep your newly virtualized environment running smoothly. The first and foremost best practice is to make sure that your virtual servers are backed up and that your data is protected and recoverable. Although this may sound basic, some people think that since Hypervisors provide high availability for their virtual servers, they don’t need to perform backups. Most backup systems will allow you to put a backup client or agent on the virtual server and back it up as if it were any other physical server. The negative to this approach is that you could have several virtual server backups running at the same time and that would put an excessive load on the physical server hosting those virtual servers. A much more elegant, and Hypervisor vendor recommended approach, is to use a backup system that uses the backup API provided by the Hypervisor vendor. These APIs manage the backup process and make sure that the supporting hardware resources are not being over taxed during a backup process. They also provide additional functionality that enables backup vendors to rapidly move data for backup and restore and eliminate the need to use temporary storage for backup data. There are products on the market that are specifically focused on backing up only virtualized servers. Although these products may sound like the best backup solution for virtual servers, the fact that they are a point solution causes you to have multiple backup applications, one for physical and one for virtual servers and this just increases the complexity of your environment while also adding cost through additional software acquisition and maintenance and additional training costs. A far better solution is to look for a backup application that provides solid reliable backup across your entire environment for all your servers, physical and virtual. This helps to simplify your environment, reduce your management tasks and help keep costs down so you can reap the savings associated with virtualizing your servers. Most long-standing backup application vendors have integrated support for hypervisor APIs to provide the recommended backup and restore methodologies for virtual servers so there is no reason not to use a single backup system across your environment. When you decide to migrate an application to a virtual server or decide to setup a virtual server as a Disaster Recovery server, you should test your application in advance to make sure there are no hidden issues. Testing can be easily performed by using the backup and recovery capability found in your backup system. Simply backup the production server, application and data and perform a bare-metal recovery to the virtual server. This will copy the complete server image over and allow you to run the application against a copy of the production data. Do be careful as this is a real copy of your production server and it will perform automated functions that may be programmed into it. Alternatively, there are high availability applications that will let you start up the application on a virtual replica server and run the application with a copy of the production data. This also gives you the ability to test and make sure everything is in place for a successful migration from physical to virtual servers. However you setup your test environment, you should be sure to check the new virtual server for any license issues as well as understand what demands the application will put on the system resources. This also gives you an opportunity to check for application performance capabilities on the virtualized server so you will know what to expect when you migrate over for production. Also, as a Disaster Recovery alternative, you may be willing to accept reduced performance on a remote virtual server until you are able to recover your primary production server. The important thing is to know what to expect before you actually make a switchover. We talked earlier about the need to document and diagram your new environment so you can quickly understand which servers are physical and which are virtual and what applications they are running. This will greatly help you in the event of an unplanned outage to recover quickly. Now, I know this can be a tedious task that requires you to continually remember to update your documents and diagrams as changes occur in your environment – and something we all like to procrastinate with. However, the real solution here is not to do this manually but rather use a set of management tools to do this automatically for you. Tools are available from the Hypervisor vendors but they are limited in scope and only cover their own virtual servers. If you are like most and are trying several hypervisors out, you will not be able to have a single report across all your servers. You would be better off with a product that provides information across all the servers in your environment, physical and virtual and whether it is a Microsoft Hyper-v, VMware, or another virtual server. Best practices are to look for a comprehensive product that covers not only the servers but also the storage, network and components on the servers such as memory, CPU and OS levels and patches. This may sound like an expensive proposition but look for backup vendors who provide this as part of their backup application so you don’t need to buy anything else. The fourth best practice is to be careful when cloning or provisioning new virtual servers. This sounds simple but, because virtual servers are so easy to create that, often times, people end up with many more than they really need. It is easy to say, “well, I just want to test this one thing out so I will create a quick clone to use to test.” Before you know it, you have an awful lot of “clones” out there and they are all active. The issue is that each VM takes up hardware resources and software licenses that could be used by production systems. You then have to go thru each server understand what it is being used for and if you can de-provision it. Some might think this is only a problem for larger environments however smaller environments will actually “feel the pinch” sooner as they have fewer physical resources available and less time to spend managing their virtual server environments.
- Remark that now we do support Hyper-v Same Simple solution for both hypervisors hyper-v and VMware Same console for virtual and physical server If someone ask about: cluster support for Hyper-v : answer: YES, with the UDP premium edition you will able to protect Hyper-v cluster’s VIX : Our strategy is aligned with vmware…”
- How host-Based Backup works? For Host-Based Agentless backup, a “proxy” is required The proxy will run the actual backup process Act as the agent for the backup The “agent” deduplicates data while sending to the RPS The proxy can be: Running on the RPS server Completely separate from the hypervisor A virtual guest Running on the Hyper-V “parent partition” (physical)
- Demos Steps: Review the Environment New Plan Create a host based backup Task Add VMs from Hyper-v Add VMs From vSphere Comment that it’s the same procedure than for Physiscal Machines Enter Manager as Proxy and explain about it Select destination UDP RPS Manager Select DS1 Enter Pass: 1234 Go to schedule show the advanced options (keep default) Talk about the Recovery points…. As we are ussing deduplication, we may keep more Recovery points than before. Go to Advanced and select “generate file system catalog…” Save the plan and Run a BKP Show the new groups created on the Resources -> Nodes Restore Option….. Restore from Windows explorer SAME as UDP for physiscal servers From the GUI (right clik on the VM from “resources”: “browse files and folders” “Recover VM” show that we can restore to a Different location, but SAME hypervisor type…. BUT:::: We can use for example BMR or Virtual Standby in order to convert recovery point to MS Hyper-v
- Also I’ll menthion that we can protect also ESXi FREE editions intalling UDP Agent within each guest VM
- Same for Virtual and physical servers Cross hypervisor conversion
- Demo Create a new Plan Task 1 Agent less for one VM from Hyper-v Then add new Task for Virtual Stanby on the vsphere (I should have an already prepared and working plan doing: Agent lees Backup –> Replicated to RPS-R -> Virtual Stand by -> replicate to Remote RPS:: :: on the Remote RPS -> also have a Virtual Standby task after the “Replicate From task” During Virtual Stand by Demo, at the end, show super quickly Full System HA integration (for those that will not attend the session 3) Show RPS Jumpstart as a nice utility for UDP running on the cloud.-
- Tentative, just in case someone ask for more details
- Now lets look at a few industry best practices to keep your newly virtualized environment running smoothly. The first and foremost best practice is to make sure that your virtual servers are backed up and that your data is protected and recoverable. Although this may sound basic, some people think that since Hypervisors provide high availability for their virtual servers, they don’t need to perform backups. Most backup systems will allow you to put a backup client or agent on the virtual server and back it up as if it were any other physical server. The negative to this approach is that you could have several virtual server backups running at the same time and that would put an excessive load on the physical server hosting those virtual servers. A much more elegant, and Hypervisor vendor recommended approach, is to use a backup system that uses the backup API provided by the Hypervisor vendor. These APIs manage the backup process and make sure that the supporting hardware resources are not being over taxed during a backup process. They also provide additional functionality that enables backup vendors to rapidly move data for backup and restore and eliminate the need to use temporary storage for backup data. There are products on the market that are specifically focused on backing up only virtualized servers. Although these products may sound like the best backup solution for virtual servers, the fact that they are a point solution causes you to have multiple backup applications, one for physical and one for virtual servers and this just increases the complexity of your environment while also adding cost through additional software acquisition and maintenance and additional training costs. A far better solution is to look for a backup application that provides solid reliable backup across your entire environment for all your servers, physical and virtual. This helps to simplify your environment, reduce your management tasks and help keep costs down so you can reap the savings associated with virtualizing your servers. Most long-standing backup application vendors have integrated support for hypervisor APIs to provide the recommended backup and restore methodologies for virtual servers so there is no reason not to use a single backup system across your environment. When you decide to migrate an application to a virtual server or decide to setup a virtual server as a Disaster Recovery server, you should test your application in advance to make sure there are no hidden issues. Testing can be easily performed by using the backup and recovery capability found in your backup system. Simply backup the production server, application and data and perform a bare-metal recovery to the virtual server. This will copy the complete server image over and allow you to run the application against a copy of the production data. Do be careful as this is a real copy of your production server and it will perform automated functions that may be programmed into it. Alternatively, there are high availability applications that will let you start up the application on a virtual replica server and run the application with a copy of the production data. This also gives you the ability to test and make sure everything is in place for a successful migration from physical to virtual servers. However you setup your test environment, you should be sure to check the new virtual server for any license issues as well as understand what demands the application will put on the system resources. This also gives you an opportunity to check for application performance capabilities on the virtualized server so you will know what to expect when you migrate over for production. Also, as a Disaster Recovery alternative, you may be willing to accept reduced performance on a remote virtual server until you are able to recover your primary production server. The important thing is to know what to expect before you actually make a switchover. We talked earlier about the need to document and diagram your new environment so you can quickly understand which servers are physical and which are virtual and what applications they are running. This will greatly help you in the event of an unplanned outage to recover quickly. Now, I know this can be a tedious task that requires you to continually remember to update your documents and diagrams as changes occur in your environment – and something we all like to procrastinate with. However, the real solution here is not to do this manually but rather use a set of management tools to do this automatically for you. Tools are available from the Hypervisor vendors but they are limited in scope and only cover their own virtual servers. If you are like most and are trying several hypervisors out, you will not be able to have a single report across all your servers. You would be better off with a product that provides information across all the servers in your environment, physical and virtual and whether it is a Microsoft Hyper-v, VMware, or another virtual server. Best practices are to look for a comprehensive product that covers not only the servers but also the storage, network and components on the servers such as memory, CPU and OS levels and patches. This may sound like an expensive proposition but look for backup vendors who provide this as part of their backup application so you don’t need to buy anything else. The fourth best practice is to be careful when cloning or provisioning new virtual servers. This sounds simple but, because virtual servers are so easy to create that, often times, people end up with many more than they really need. It is easy to say, “well, I just want to test this one thing out so I will create a quick clone to use to test.” Before you know it, you have an awful lot of “clones” out there and they are all active. The issue is that each VM takes up hardware resources and software licenses that could be used by production systems. You then have to go thru each server understand what it is being used for and if you can de-provision it. Some might think this is only a problem for larger environments however smaller environments will actually “feel the pinch” sooner as they have fewer physical resources available and less time to spend managing their virtual server environments.
- Now lets look at a few industry best practices to keep your newly virtualized environment running smoothly. The first and foremost best practice is to make sure that your virtual servers are backed up and that your data is protected and recoverable. Although this may sound basic, some people think that since Hypervisors provide high availability for their virtual servers, they don’t need to perform backups. Most backup systems will allow you to put a backup client or agent on the virtual server and back it up as if it were any other physical server. The negative to this approach is that you could have several virtual server backups running at the same time and that would put an excessive load on the physical server hosting those virtual servers. A much more elegant, and Hypervisor vendor recommended approach, is to use a backup system that uses the backup API provided by the Hypervisor vendor. These APIs manage the backup process and make sure that the supporting hardware resources are not being over taxed during a backup process. They also provide additional functionality that enables backup vendors to rapidly move data for backup and restore and eliminate the need to use temporary storage for backup data. There are products on the market that are specifically focused on backing up only virtualized servers. Although these products may sound like the best backup solution for virtual servers, the fact that they are a point solution causes you to have multiple backup applications, one for physical and one for virtual servers and this just increases the complexity of your environment while also adding cost through additional software acquisition and maintenance and additional training costs. A far better solution is to look for a backup application that provides solid reliable backup across your entire environment for all your servers, physical and virtual. This helps to simplify your environment, reduce your management tasks and help keep costs down so you can reap the savings associated with virtualizing your servers. Most long-standing backup application vendors have integrated support for hypervisor APIs to provide the recommended backup and restore methodologies for virtual servers so there is no reason not to use a single backup system across your environment. When you decide to migrate an application to a virtual server or decide to setup a virtual server as a Disaster Recovery server, you should test your application in advance to make sure there are no hidden issues. Testing can be easily performed by using the backup and recovery capability found in your backup system. Simply backup the production server, application and data and perform a bare-metal recovery to the virtual server. This will copy the complete server image over and allow you to run the application against a copy of the production data. Do be careful as this is a real copy of your production server and it will perform automated functions that may be programmed into it. Alternatively, there are high availability applications that will let you start up the application on a virtual replica server and run the application with a copy of the production data. This also gives you the ability to test and make sure everything is in place for a successful migration from physical to virtual servers. However you setup your test environment, you should be sure to check the new virtual server for any license issues as well as understand what demands the application will put on the system resources. This also gives you an opportunity to check for application performance capabilities on the virtualized server so you will know what to expect when you migrate over for production. Also, as a Disaster Recovery alternative, you may be willing to accept reduced performance on a remote virtual server until you are able to recover your primary production server. The important thing is to know what to expect before you actually make a switchover. We talked earlier about the need to document and diagram your new environment so you can quickly understand which servers are physical and which are virtual and what applications they are running. This will greatly help you in the event of an unplanned outage to recover quickly. Now, I know this can be a tedious task that requires you to continually remember to update your documents and diagrams as changes occur in your environment – and something we all like to procrastinate with. However, the real solution here is not to do this manually but rather use a set of management tools to do this automatically for you. Tools are available from the Hypervisor vendors but they are limited in scope and only cover their own virtual servers. If you are like most and are trying several hypervisors out, you will not be able to have a single report across all your servers. You would be better off with a product that provides information across all the servers in your environment, physical and virtual and whether it is a Microsoft Hyper-v, VMware, or another virtual server. Best practices are to look for a comprehensive product that covers not only the servers but also the storage, network and components on the servers such as memory, CPU and OS levels and patches. This may sound like an expensive proposition but look for backup vendors who provide this as part of their backup application so you don’t need to buy anything else. The fourth best practice is to be careful when cloning or provisioning new virtual servers. This sounds simple but, because virtual servers are so easy to create that, often times, people end up with many more than they really need. It is easy to say, “well, I just want to test this one thing out so I will create a quick clone to use to test.” Before you know it, you have an awful lot of “clones” out there and they are all active. The issue is that each VM takes up hardware resources and software licenses that could be used by production systems. You then have to go thru each server understand what it is being used for and if you can de-provision it. Some might think this is only a problem for larger environments however smaller environments will actually “feel the pinch” sooner as they have fewer physical resources available and less time to spend managing their virtual server environments.
- .
- If someone ask about: Cluster support for Hyper-v : answer: YES, with the UDP premium edition you will able to protect Hyper-v cluster’s VIX : Our strategy is aligned with vmware…”