Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Azure Disaster Recovery - Guillermo Zepeda
Semelhante a Azure Disaster Recovery - Guillermo Zepeda (20)
Último
Último (15)
Azure Disaster Recovery - Guillermo Zepeda
- 1. DISASTER RECOVERY EN AZURE Guillermo Zepeda Microsoft MVP Visual Studio and Development Technologies
- 2. ¿Qué es Disaster Recovery? Políticas, herramientas y procedimientos
- 3. ¿Qué es Disaster Recovery? Enfocada en infraestructura tecnológica y sistemas de información
- 4. ¿Qué es Disaster Recovery? Business continuity > Disaster recovery
- 5. ¿Qué es Disaster Recovery? Desde los mainframes hasta la nube…
- 7. Tipos de desastres Inducidos por humanos
- 8. ¿Cómo puedo hacer Disaster Recovery? Prevenir Detectar Corregir
- 9. ¿Cómo puedo hacer Disaster Recovery?
- 10. ¿Cómo puedo hacer Disaster Recovery? ¡Tener un DRP es obligatorio!
- 11. Estrategias para hacer DR Backup en cinta Backup en Disco Replicación de datos Nube privada Nube híbrida Alta disponibilidad
- 12. Disaster Recovery en Azure • Proteja sus sistemas sin incurrir en altos costos • Unificar administración de datos, seguridad y protección • Asegurar que las aplicaciones funcionen cuando se les necesita • Realizar pruebas en cualquier momento para tener confianza que la solución funciona • Se pueden utilizar distintos partners para el almacenamiento de datos
- 13. Disaster Recovery en Azure – PYMES
- 14. Disaster Recovery en Azure – Enterprise
- 15. Demo
- 16. Ejemplo – ASR
- 17. Ejemplo – ASR
- 18. Ejemplo – ASR
- 20. El futuro (o presente): Azure Stack La “nube híbrida”
- 21. El futuro (o presente): Azure Stack • Ofrecida en asociación con fabricantes de Hardware • Casos de uso: • Escalabilidad transparente • Requisitos legales de no tener archivos fuera de oficina.
- 22. Consideraciones finales • No DRP… No party • Hay que hacer la tarea: RPO y RTO • BCP como complemento del DRP
- 23. ¿Preguntas?
Notas do Editor
- involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. Disaster recovery focuses on the IT or technology systems supporting critical business functions,[1] as opposed to business continuity, which involves keeping all essential aspects of a business functioning despite significant disruptive events. Disaster recovery is therefore a subset of business continuity.[2]
- involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. Disaster recovery focuses on the IT or technology systems supporting critical business functions,[1] as opposed to business continuity, which involves keeping all essential aspects of a business functioning despite significant disruptive events. Disaster recovery is therefore a subset of business continuity.[2]
- involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. Disaster recovery focuses on the IT or technology systems supporting critical business functions,[1] as opposed to business continuity, which involves keeping all essential aspects of a business functioning despite significant disruptive events. Disaster recovery is therefore a subset of business continuity.[2]
- Disaster recovery developed in the mid- to late 1970s as computer center managers began to recognize the dependence of their organizations on their computer systems. At that time, most systems were batch-oriented mainframes which in many cases could be down for a number of days before significant damage would be done to the organization. As awareness of the potential business disruption that would follow an IT-related disaster, the disaster recovery industry developed to provide backup computer centers, with Sun Information Systems (which later became Sungard Availability Services) becoming the first major US commercial hot site vendor, established in 1978 in Sri Lanka. During the 1980s and 90s, customer awareness and industry both grew rapidly, driven by the advent of open systems and real-time processing which increased the dependence of organizations on their IT systems. Regulations mandating business continuity and disaster recovery plans for organizations in various sectors of the economy, imposed by the authorities and by business partners, increased the demand and led to the availability of commercial disaster recovery services, including mobile data centers delivered to a suitable recovery location by truck. With the rapid growth of the Internet through the late 1990s and into the 2000s, organizations of all sizes became further dependent on the continuous availability of their IT systems, with some organizations setting objectives of 2, 3, 4 or 5 nines (99.999%) availability of critical systems. This increasing dependence on IT systems, as well as increased awareness from large-scale disasters such as tsunami, earthquake, flood, and volcanic eruption, spawned disaster recovery-related products and services, ranging from high-availability solutions to hot-site facilities. Improved networking meant critical IT services could be served remotely, hence on-site recovery became less important. The rise of cloud computing since 2010 continues that trend: nowadays, it matters even less where computing services are physically served, just so long as the network itself is sufficiently reliable (a separate issue, and less of a concern since modern networks are highly resilient by design). 'Recovery as a Service' (RaaS) is one of the security features or benefits of cloud computing being promoted by the Cloud Security Alliance.[3]
- Disasters can be classified into two broad categories. The first is natural disasters such as floods, hurricanes, tornadoes or earthquakes. While preventing a natural disaster is impossible, risk management measures such as avoiding disaster prone situations and good planning can help. The second category is man-made disasters, such as hazardous material spills, infrastructure failure, bio-terrorism, and disastrous IT bugs or failed change implementations. In these instances, surveillance, testing and mitigation planning are invaluable.
- Disasters can be classified into two broad categories. The first is natural disasters such as floods, hurricanes, tornadoes or earthquakes. While preventing a natural disaster is impossible, risk management measures such as avoiding disaster prone situations and good planning can help. The second category is man-made disasters, such as hazardous material spills, infrastructure failure, bio-terrorism, and disastrous IT bugs or failed change implementations. In these instances, surveillance, testing and mitigation planning are invaluable.
- Control measures are steps or mechanisms that can reduce or eliminate various threats for organizations. Different types of measures can be included in disaster recovery plan (DRP). Disaster recovery planning is a subset of a larger process known as business continuity planning and includes planning for resumption of applications, data, hardware, electronic communications (such as networking) and other IT infrastructure. A business continuity plan (BCP) includes planning for non-IT related aspects such as key personnel, facilities, crisis communication and reputation protection, and should refer to the disaster recovery plan (DRP) for IT related infrastructure recovery / continuity. IT disaster recovery control measures can be classified into the following three types: 1. Preventive measures – Controls aimed at preventing an event from occurring. 2. Detective measures – Controls aimed at detecting or discovering unwanted events. 3. Corrective measures – Controls aimed at correcting or restoring the system after a disaster or an event. Good disaster recovery plan measures dictate that these three types of controls be documented and exercised regularly using so-called "DR tests".
- Prior to selecting a disaster recovery strategy, a disaster recovery planner first refers to their organization's business continuity plan which should indicate the key metrics of recovery point objective (RPO) and recovery time objective (RTO) for various business processes (such as the process to run payroll, generate an order, etc.). The metrics specified for the business processes are then mapped to the underlying IT systems and infrastructure that support those processes.[7] Incomplete RTOs and RPOs can quickly derail a disaster recovery plan. Every item in the DR plan requires a defined recovery point and time objective, as failure to create them may lead to significant problems that can extend the disaster’s impact.[8] Once the RTO and RPO metrics have been mapped to IT infrastructure, the DR planner can determine the most suitable recovery strategy for each system. The organization ultimately sets the IT budget and therefore the RTO and RPO metrics need to fit with the available budget. While most business unit heads would like zero data loss and zero time loss, the cost associated with that level of protection may make the desired high availability solutions impractical. A cost-benefit analysis often dictates which disaster recovery measures are implemented.
- Traditionally, a disaster recovery system involved cutover or switch-over recovery systems. Such measures would allow an organization to preserve its technology and information, by having a remote disaster recovery location that produced backups on a regular basis. However, this strategy proved to be expensive and time-consuming. Therefore, more affordable and effective cloud-based systems were introduced.
- Some of the most common strategies for data protection include: backups made to tape and sent off-site at regular intervals backups made to disk on-site and automatically copied to off-site disk, or made directly to off-site disk replication of data to an off-site location, which overcomes the need to restore the data (only the systems then need to be restored or synchronized), often making use of storage area network (SAN) technology Private Cloud solutions which replicate the management data (VMs, Templates and disks) into the storage domains which are part of the private cloud setup. These management data are configured as an xml representation called OVF (Open Virtualization Format), and can be restored once a disaster occurs. Hybrid Cloud solutions that replicate both on-site and to off-site data centers. These solutions provide the ability to instantly fail-over to local on-site hardware, but in the event of a physical disaster, servers can be brought up in the cloud data centers as well. the use of high availability systems which keep both the data and system replicated off-site, enabling continuous access to systems and data, even after a disaster (often associated with cloud storage)[9] In many cases, an organization may elect to use an outsourced disaster recovery provider to provide a stand-by site and systems rather than using their own remote facilities, increasingly via cloud computing. In addition to preparing for the need to recover systems, organizations also implement precautionary measures with the objective of preventing a disaster in the first place. These may include: local mirrors of systems and/or data and use of disk protection technology such as RAID surge protectors — to minimize the effect of power surges on delicate electronic equipment use of an uninterruptible power supply (UPS) and/or backup generator to keep systems going in the event of a power failure fire prevention/mitigation systems such as alarms and fire extinguishers anti-virus software and other security measures
- Implementation guidance PRODUCTS/DESCRIPTIONDOCUMENTATION Traffic Manager DNS traffic is routed via Traffic Manager which can easily move traffic from one site to another based on policies defined by your organization. Configure Failover routing method Site Recovery Azure Site Recovery orchestrates the replication of machines and manages the configuration of the failback procedures. How does Azure Site Recovery work? Replicate Hyper-V virtual machines (without VMM) to Azure using Azure Site Recovery with the Azure portal Virtual Network The virtual network is where the failover site will be created when a disaster occurs. Designing your network infrastructure for disaster recovery Blob storage Blob storage stores the replica images of all machines that are protected by Site Recovery.Introduction to Microsoft Azure Storage
- PRODUCTS/DESCRIPTIONDOCUMENTATIONTraffic Manager DNS traffic is routed via Traffic Manager which can easily move traffic from one site to another based on policies defined by your organization.Configure Failover routing method Site Recovery Azure Site Recovery orchestrates the replication of machines and manages the configuration of the failback procedures.How does Azure Site Recovery work? Replicate VMware virtual machines and physical machines to Azure with Azure Site Recovery using the Azure portal Blob storage Blob storage stores the replica images of all machines that are protected by Site Recovery.Introduction to Microsoft Azure Storage Azure Active Directory Azure Active Directory is the replica of the on-premises Azure Active Directory services allowing cloud applications to be authenticated and authorized by your company.Integrating your on-premises identities with Azure Active Directory VPN Gateway The VPN gateway maintains the communication between the on-premises network and the cloud network securely and privately.Create a VNet with a Site-to-Site connection using the Azure portal Virtual Network The virtual network is where the failover site will be created when a disaster occurs.Designing your network infrastructure for disaster recovery
- The following graphic provides a high-level view of an Azure VM environment in a specific region (in this example, the East US location). In an Azure VM environment: Apps can be running on VMs with disks spread across storage accounts. The VMs can be included in one or more subnets within a virtual network.
- Step 1 When you enable Azure VM replication, the following resources are automatically created in the target region, based on the source region settings. You can customize target resources settings as required. ResourceDetails Target resource group The resource group to which replicated VMs belong after failover. Target virtual network The virtual network in which replicated VMs are located after failover. A network mapping is created between source and target virtual networks, and vice versa. Cache storage accounts Before source VM changes are replicated to a target storage account, they are tracked and sent to the cache storage account in source location. This step ensures minimal impact on production applications running on the VM. Target storage accounts Storage accounts in the target location to which the data is replicated. Target availability sets Availability sets in which the replicated VMs are located after failover.
- Step 2 As replication is enabled, the Site Recovery extension Mobility service is automatically installed on the VM: The VM is registered with Site Recovery. Continuous replication is configured for the VM. Data writes on the VM disks are continuously transferred to the cache storage account, in the source location. Site Recovery never needs inbound connectivity to the VM. Only outbound connectivity is needed for the following. Site Recovery service URLs/IP addresses Office 365 authentication URLs/IP addresses Cache storage account IP addresses If you enable multi-VM consistency, machines in the replication group communicate with each other over port 20004. Ensure that there is no firewall appliance blocking the internal communication between the VMs over port 20004. Important If you want Linux VMs to be part of a replication group, ensure the outbound traffic on port 20004 is manually opened as per the guidance of the specific Linux version. Step 3 After continuous replication is in progress, disk writes are immediately transferred to the cache storage account. Site Recovery processes the data, and sends it to the target storage account. After the data is processed, recovery points are generated in the target storage account every few minutes.
- Failover process When you initiate a failover, the VMs are created in the target resource group, target virtual network, target subnet, and in the target availability set. During a failover, you can use any recovery point.
- Azure Stack is a hybrid cloud platform that lets you use Azure services from your company's or service provider's datacenter. As a developer, you can build apps that run on Azure Stack. You can then deploy these apps to Azure Stack, to Azure, or you can build truly hybrid apps that leverage the connectivity between an Azure Stack cloud and Azure. Your Azure Stack operator will let you know which services are available for you to use, and how to get support. They offer these services through their customized plans and offers. The Azure technical content assumes that apps are being developed for an Azure service instead of Azure Stack. When you build and deploy apps to Azure Stack, you must understand some key differences, such as: Azure Stack delivers a subset of the services and features that are available in Azure. Your company or service provider can choose which services they want to offer. This includes customized services or applications. They may offer their own customized documentation. You must use the correct Azure Stack-specific endpoints (for example, the URLs for the portal address and the Azure Resource Manager endpoint). You must use PowerShell and API versions that are supported by Azure Stack. Doing this ensures that your apps will work in both Azure Stack and Azure.
- Azure Stack is a hybrid cloud platform that lets you use Azure services from your company's or service provider's datacenter. As a developer, you can build apps that run on Azure Stack. You can then deploy these apps to Azure Stack, to Azure, or you can build truly hybrid apps that leverage the connectivity between an Azure Stack cloud and Azure. Your Azure Stack operator will let you know which services are available for you to use, and how to get support. They offer these services through their customized plans and offers. The Azure technical content assumes that apps are being developed for an Azure service instead of Azure Stack. When you build and deploy apps to Azure Stack, you must understand some key differences, such as: Azure Stack delivers a subset of the services and features that are available in Azure. Your company or service provider can choose which services they want to offer. This includes customized services or applications. They may offer their own customized documentation. You must use the correct Azure Stack-specific endpoints (for example, the URLs for the portal address and the Azure Resource Manager endpoint). You must use PowerShell and API versions that are supported by Azure Stack. Doing this ensures that your apps will work in both Azure Stack and Azure.