Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Disaster Recovery Planning using Azure Site Recovery
Ähnlich wie Disaster Recovery Planning using Azure Site Recovery (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Disaster Recovery Planning using Azure Site Recovery
- 1. Disaster Recovery Planning using Azure Site Recovery www.motifworks.com
- 2. Housekeeping 2 No sound? Check your speakers, if you are using headphones … You can also join via phone: +1 (914) 614-3221 Access Code: 846-566-028 Download GoToWebinar You need GoToWebinar client software Ask Question You can ask question anytime using the Question box on your screen Technical problem? Check GoToWebinar Quick Reference Guide Check GoToWebinar Help! http://support.citrixonli ne.com/Webinar/
- 3. 3 MOTIFWORKS AZURE PRACTICES AZURE CONSULTANCY › Azure 101 › Architecture Discussion Sessions (ADS Sessions) › Azure Workshops CLOUD MIGRATION › Lift and Shift › End-of-life Migration › Cloud Burst/Auto-scaling APP MODERNIZATION › Azure PaaS Development › Mobile Backend as a Service › Multi-tenant SaaS apps BI AND AZURE ANALYTICS › Cortana Analytics: Azure HDInsight and Machine Learning › SQL Server BI (SSIS, SSAS, SSRS) DEVOPS AND AUTOMATION › Infrastructure as Code › PowerShell based Automation › ALM / Continuous Integration / Continuous Delivery › Trial as a Service (trial.io) MANAGED SERVICES › 365 * 24 * 7 Infrastructure & Application Support › Backup & Disaster Recovery › Security as a Service ABOUT MOTIFWORKS
- 4. Today’s Presenter 4 Cloud Solutions Architect Motifworks Murad Kayani A seasoned architect strong skills in user training, technical leadership and support for customers in complex environments. Main focus is helping customers understand how Azure can help solve business and technical challenges.
- 5. Today’s Agenda 5 Why you need DR? How to Plan DR? Azure Site Recovery Pricing
- 6. Poll #1 6 What are your thoughts?
- 7. Why you need DR? Human Errors Reduce Cost Cost of downtime Compliance Always On System Failures Brand reputation Natural Disaster Customer Retention “IDC estimates that as many as 50% of organizations have inadequate disaster recovery plans. In fact, IDC warns, such companies might not survive as a going concern after a significant disaster because of their inability to recover IT systems."
- 8. HOW TO PLAN FOR DISASTER RECOVERY 8
- 9. 9 Term Definition Recovery Point Objective The acceptable amount of data loss measured in time. Recovery Time Objective The duration of time within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. Failover Failover is a process to recover the workload on to the protecting site. It can be a planned activity or needed after a disaster to bring back the business. A test failover can also be used to regularly check for DR readiness. Disaster Recovery Plan A plan which captures the various VM which need to be recovered during failover, the data center dependencies that need to be followed and additional tasks that need to be carried out to ensure successful recovery of a workload. Disaster Recovery Terminology
- 10. Business Continuity Running 24/7 Days HIGH AVAILBILITY BACKUP DIASTER RECOVERY Ensuring Data is safe Recovery after a disaster
- 11. Identifying Critical Systems Rebuild when required from off-site backup Hot configuration with Fail-over
- 12. Identifying Critical Systems RPO/RTO Threat Preventation Response Recovery For each critical System • System Failure • Network connectivity down • 15 minutes/2 hours • Backup • Secondary data center • Switch server to backup Server • Resolve Issue and fail back to primary server Example:
- 13. Disaster Recovery in cloud Disks, back-up tapes etc. can be eliminated Mission-critical data can be kept off-site Cost effective Scalable Efficiency Reduce Infrastructure Faster Recovery
- 14. Poll #2 14 What are your thoughts?
- 16. 16 ASR provides single DR solution which works across platforms (Hyper-V, VMWare, Physical) across clouds (public, private and service provider) and across workloads to provide a range of RTO/RPO using multiple channels (Replica, Scout, SAN etc.). Azure Site Recovery
- 17. 17 One solution for multiple infrastructures VMM site to VMM site (on-premises) VMM Site VMM Site Replication VMM to Microsoft Azure Microsoft Azure Replication VMware or physical to VMware (on-premises) VMware VMware Replication VMware or physical to Microsoft Azure VMware or physical Microsoft Azure Replication VMM to VMM (on-premises) Replication SAN SAN VMM Site VMM Site VMM Site Hyper-V to Microsoft Azure Microsoft Azure Replication Hyper-V Site
- 18. Disaster Recovery Process Microsoft Azure Data Channel Microsoft Azure Site Recovery Process Server – Used for Caching, Compression & Encryption Config Server – Used for Centralized Management Master Target – Used as a repository & for retention Source: VMware VMs & Physical Servers Process Server Mobility Service – Captures all data writes from memory Microsoft Azure Target: Microsoft Azure
- 19. 19 1. Sign up 2. Create Recovery Vault
- 20. 3. Configuring Protection Goals
- 21. 21 4. Prepare the source environment Install Azure Site Recovery Provider and the Azure Recovery Services agent on Hyper-V hosts
- 22. 22 5. Installing Provider & Agent
- 23. 23 5. Configure the target environment
- 24. 24 5. Capacity Planning Gather information about your replication environment, including VMs, disks per VMs, and storage per disk. Estimate the daily change (churn) rate you’ll have for replicated data. Microsoft Provides Planning tools for Both Hyper-V and vSphere
- 26. 26 7. Executing Recovery Plan Test Failover Useful to verify that your recovery plan and virtual machine failover strategy are working as expected. Simulates your failover and recovery mechanism into an isolated network(s), that you define, or that can be created automatically. Unplanned Failover Run an unplanned failover when a primary site experiences an unexpected incident, such as a power outage. Planned Failover Perform a complete failover and recovery of virtual machines in your recovery plans in a proactive, planned manner. Non-replicated changes are applied to the replica virtual machine with no data loss before bringing the VM online in the secondary site.
- 27. 27 Price For First 31 days Price After 31 Days Azure Site Recovery to customer owned sites Free $16/month per instance protected Azure Site Recovery to Azure Free $25/month per instance protected Azure Site Recovery is billed based on number of instances protected. Every instance that is protected with Azure Recovery is free for the first 31 days as shown below. Pricing
- 28. 28 Item Cost Total/mo 10 VMs $25 Per instance $250 Storage 300 GB /VM $0.01 Per GB $30 Put (1000000) Operations $0.100 per 1000 Operations $10 Data Retrieval (3000) GB $0.010 per GB $30.00 Data Write (3000) GB $0.003 per GB $7.50 Estimated Cost/ month $327.50 Azure Site Recovery To Azure Cost
- 29. Cloud and Azure Workshops 29 Business Continuity & Disaster Recovery Proof of Concept We review your business objectives, create a business continuity and disaster recovery strategy for the selected workload and implement the DR. • Define Business Objectives • Assess Application • BC/DR Strategy • Implementation • Review Results Cloud Readiness Assessment • Cloud Readiness Assessment presentation along with supporting data, assessment findings and recommendations. • Adoption roadmap, migration options and high-level architecture. • Plan for migration for candidate applications. • High-level cloud consumption plan and costs. Application Modernization • Azure Cloud PaaS Services overview • High-level future architecture • Migration plan, with migration options and high-level plan • Recommendations for improved user experience • High-level cloud consumption plan and costs. You may be qualified to get one of these complimentary workshop
- 30. 31 Thank You! Please do not forget to RATE the webinar Murad Kayani murad@motifworks.com 202.460.5700 www.motifworks.com
Hinweis der Redaktion
- Disks backup - There is no need to maintain daily back-ups using disks, tapes etc. Though this mode can be used, compared to having a DR in the cloud, it is inefficient. The data back-up can be done, even in real-time in the cloud. Mission Critical Data – Cloud is reduntely designed. In case of failure you can recover you data from the cloud. Cost Effective - Since the cloud service provider charges only for the services used, the business can pick and choose what it requires, leading to immense cost reduction. Also, costly hardware need not be duplicated since the cloud is the resource for the DR solution. Scalable - The cloud option can be easily scaled up or down depending on business requirements Efficiency - Since the data is stored in the cloud, large servers and associated hardware is eliminated, leading to lower capital costs. The entire IT infrastructure of the business will be ‘lean and mean’, yet fighting fit, to face a disaster head-on. Reduce Infrastructure – Faster Recovery – With cloud you can expediate the overall recovery, sometimes in minutes. You also have an ability to even recover in the cloud. You can also infact automate the entire recovery plan. Flexible -
- What are the different infrastructures that Azure Site Recovery can provide a solution for? http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-overview/ Well first, for customers who have multiple sites, or work with a service provider as a secondary site, and Hyper-V is running on both sites, they can take advantage of Azure Site Recovery to orchestrate the replication and recovery between those sites. In that example, the engine of replication will be Hyper-V Replica, an inbox VM replication technology that’s built into Windows Server 2012 and 2012 R2. <click> For customers with an investment in SAN technology, that includes replication in the box, through integration with Hyper-V, System Center and Azure Site Recovery, customers can orchestrate the replication and recovery of their key workloads between those sites, this time, harnessing the power of the SAN, through asynchronous or synchronous replication, to transfer data between sites. <click> For customers who don’t have a second site, and are running Hyper-V on their primary site, using Azure Site Recovery, customers can orchestrate the replication and recovery of their on-premises workloads, into the Microsoft Azure datacenters, enabling this as a target for failover in the event of a disaster. The engine of replication in this example is Hyper-V Replica. <click> What about customers who don’t have Hyper-V within their datacenters? Well, as we mentioned at the start of the presentation, with the acquisition of InMage, under the umbrella of Azure Site Recovery, customers can orchestrate the replication and recovery of key workloads from physical, or VMware-based sites, over to a secondary site, running VMware also. This time, InMage Scout is providing the replication engine, and is transferring the data between the two on-premises locations. <click> Finally, just like we saw earlier, where a customers without a secondary location, could use ASR to replicate and recover Hyper-V-based VMs into Azure, with the new InMage technologies, in the future, you will be able to replicate and recover VMware-based VMs into Microsoft Azure. Again, this will be powered by InMage Scout. <click> So let’s dive into each of these in more detail, starting with Hyper-V to Hyper-V replication and recovery with ASR. <next slide>
- on-premises machine that coordinates communication and manages data replication and recovery processes. Acts as a replication gateway. It receives replication data from protected source machines, optimizes it with caching, compression, and encryption, and sends it to Azure storage. It also handles push installation of the Mobility service to protected machines, and performs automatic discovery of VMware VMs. Master Target- Handles replication data during failback from Azure. Mobility - This component is deployed on every machine (VMware VM or physical server) that you want to replicate to Azure. It captures data writes on the machine and forwards them to the process server.
- Firstly, you'll need an Azure account, so you’ll need to register with an appropriate Microsoft Account. Once completed…. <click> You create a Recovery Vault – this is a simple process that involves providing a name, and a location of where you want the vault to reside, choosing the geography which is most relevant to you and your business. From there, to register your on-premises Virtual Machine Manager servers in an Azure Site Recovery vault, you'll need to upload a management certificate (.cer) containing the public key to the vault. This management certificate should reside on each of your VMM servers. The SSL certificate can be self-signed, come from an enterprise CA, or any CA that is trusted by Microsoft. <click> Once the certificate is imported into the Vault, you can deploy the provider, which is downloaded from the Azure portal. This should be installed on each of your VMM servers. The latest version of the Provider installation file is stored in the Azure Download Center. When you run the file on a VMM server the Provider is installed, and the VMM server is registered with the vault. Upon completion of this stage, metadata from the VMM server(s) is pushed to Azure Site Recovery, in order to orchestrate failover and recovery. After a server has been successfully registered its friendly name will be displayed on the **Resources** tab of the Servers page in the vault <next slide>
- <click> You then need to create Clouds on the primary site. In VMM, a cloud is an object that is provisioned and managed on-premises by an organization. The cloud is deployed by using an organization’s own hardware to leverage the advantages of the cloud model. By using VMM, an organization can manage the cloud definition and can manage access to the cloud and the underlying physical resources. Clouds contain the VMs that will be protected by Azure Site Recovery. <click> On the secondary site, you simply create clouds that map to those on primary, so for instance, if you had a cloud on primary called Test, you may create a cloud on secondary called Test_DR. These clouds will be mapped to one another at a later point. <click> The user can then configure the key items within the Azure portal, from replication frequency, to additional recovery points and VSS integration. These settings ultimately determine the settings applied to Hyper-V Replica, which is on each Hyper-V host. <click> From this point forward, Azure Site Recovery will monitor the VMM servers on your on-premises locations, but at this point, we have nothing configured for protection – only our clouds are configured. <click> We then map our networks between the sites, which we can look at in a bit more detail. <next slide>
- When it comes to executing Recovery Plans, there are 3 ways they can be executed. Firstly, the user can run a test failover. <click> Running a test failover executes the recovery plan, brings workloads up on the secondary site, but in an isolated environment, whilst the primary site is still online. The ability to test failover ensures that recovery plans execute as expected, in the event of a disaster. You can have the test failover process automatically create new networks for VMs on the secondary site using Hyper-V Network Virtualization, or use existing ones that you’ve defined in advance. <click> With an unplanned failover, this would be executed when the primary site has had an unexpected outage. When you execute an unplanned failover, you can attempt to shut down the VMs on the primary first, and replicate any final changes, but it’s most likely that in an unplanned scenario, you’ve lost the primary site already, and the main objective is to bring the secondary site online as quickly and efficiently as possible. <click> Finally, we have the planned failover, where you’re executing failover in a proactive, planned manner. In this scenario, the VMs are cleanly shut down, their final delta changes since the last replication are replicated, and the VMs are failed over in a controlled and orchestrated manner. Now that we’ve heard about the process, let’s take a look at it in action with a demo. <next slide>