EBC Availability
EBC Availability is a part of the Equinix Business Cloud (EBC) portfolio of platform services. It is a cloud-based Disaster Recovery solution designed specifically for your EBC environment. This provides fast, efficient, and secure Disaster Recovery in a self-service or managed way, depending on the purchased EBC platform variant (Flex, Single Tenant, or Core).
Disaster Recovery as a Service (DRaaS) is provided for all types of VMs (up-to mission critical) as part of your Business Continuity plan. For EBC Flex and Single Tenant (ST) the service is available in a self-service way, and for EBC Core in a managed way. To fit the importance of the data, the service is offered in several RPO variants.
The main use-cases of both variants are:
-
EBC Flex / Single Tenant replication –
-
Replication of VMs between EBC Flex / ST variants, locations and tiers with RPO values up to 1 hour.
-
Replication of On-premises vSphere to EBC Flex / ST variants, locations and tiers with RPO values up to 1 hour.
-
-
EBC Core –
Replication of VM’s between locations and tiers with intervals up to 4 hours.
EBC Availability is designed to extend the EBC platform with DRaaS functionalities. This way VM’s are replicated between EBC locations of choice in The Netherlands with RPO values up to 1 hour.
Availability for EBC Flex and ST (Self-Service)
EBC Availability for EBC Flex / ST is the self-service DRaaS offering from Equinix, targeted for EBC Flex and ST Virtual Datacenters (VDCs).
EBC Availability offers crash consistent VM replication in three customer selectable SLA Profiles across three data-centers in Netherlands.
Besides replicating to and from Flex/ST, a mix of both is also supported.
The VDC in the secondary data-center could consist of lower cost (in terms of capacity and performance) compute or storage, but must be enough for the intended workload.
To be able to successfully failover VM’s to the secondary data-center, a VDC and suitable network topology must be available. Equinix can help design a suitable network design supporting the DR goal. Especially in a DR situation it is paramount that connectivity to the internet, on-premises locations and/or cabinet is working as intended within the secondary data-center.
To make sure failovers work as intended, EBC Availability supports the testing of VM failovers in self-service.
SLA Overview
Parameter | Value | Description |
---|---|---|
RPO |
Gold = 1 hour Silver = 4 hours Bronze = 12 hours |
Timeframe in which the replication is finished. |
RTO | 30 min | Timeframe within the VM must be started in the secondary data-center, upon customer-initiated failover.1 |
# Retention points |
Gold = latest + 8 points Silver = latest + 6 points Bronze = latest + 2 points |
All profiles consist of latest restore point + amount of automatically stored restore points. Max. restore point age is 2 days |
Note:
1. RTO starts after failover is initiated by users.
If at any moment a failover should be necessary, the user is able to failover the workload to the secondary data-center in a self-service way. This way the user is in control of the failover, which results in faster (application) recovery. To make failover possible, VM’s are replicated according to the selected SLA Profile. Network links and bandwidths are operated and monitored by Equinix as part of the service.
After the primary data-center has returned to normal operation, the replication direction is reversed by the user in the EBC portal. When completed, the VM’s and applications return to the primary data-center at a suitable time chosen by the user.
Note: User related connectivity (which VM’s and applications attach to), are setup and purchased outside of the EBC Availability service, and need to be setup in advance to make connectivity between data-centers, internet, cabinets and on-premises networks possible.
Performance and Capacity
For a self-service DRaaS service it is critical to know which activities have an impact on the performance, capacity, and responsibility of the environment as a whole. These responsibilities include the following.
-
The technology underneath the EBC Availability service is I/O filter (capture) based instead of snapshot based. By using the filter approach, the performance impact for VM’s by using snapshots is prevented.
-
The user is responsible for selecting the suitable EBC compute and storage performance level in the secondary data-center. The selected performance level should meet the user SLA and expected performance in case a failover needs to be performed.
-
The user needs to make sure the amount of EBC compute and storage capacity in the second data-center is sufficient to perform a full failover. When resources like test & dev are running in the secondary locations, these could need to be shutdown by the user before failover can occur.
-
The availability and capacity of the replication link in cloud-to-cloud scenarios is part of the service. Equinix makes sure it is available and has sufficient capacity to meet the SLA.
-
The availability and capacity for user related networking needs to be in place before successful failover can occur. The user is responsible to make sure it is available, and has sufficient capacity to meet the needs.
Billing Options
EBC Availability for EBC Flex / ST is billed on a VM per month depending on the chosen SLA Profile.
Pricing includes replication connectivity and bandwidth, and is offered in 3 SLA Profiles:
-
EBC Availability RPO = 1
-
EBC Availability RPO = 4
-
EBC Availability RPO = 12
Costs for compute and storage capacity in the secondary data-center is part of the EBC Service.
Multi-site networking connectivity for VMs is additionally required.
Metering
To determine the amount of replicated VMs for billing, all VMs that were part of a certain SLA Profile on a daily basis, are counted.
If a VM is changed between different SLA Profiles within a month, it will be billed accordingly.
Relations and Dependencies
EBC Availability can only be consumed as part of the EBC Flex / ST services.
-
During failover, no replication takes place, and therefore does not adhere to the SLA.
-
During the failback configuration phase (re-protect), no replication takes place, and therefore does not adhere to the SLA.
-
Returning to the situation before the disaster, is required. Failback should be performed within 1 month after the disaster.
-
Back-ups during failover are only in place when the user has requested for a backup plan for the secondary data-center.
Availability for EBC Core (Managed)
EBC Availability for EBC Core is the managed DRaaS offering from Equinix, and can be added to EBC Core clusters residing in separate EBC data-centers. The service offers crash consistent replication in four selectable RPO options.
Based on user requirements (such as RPO, RTO and network), a design is made. Based on this design, Equinix implements the managed DRaaS environment from the agreed parameters on top of EBC Core. When configured for replication, the EBC Core platform is required in primary and secondary locations.
In the deployment phase, Equinix configures the replicated VMs according to the agreed design.
SLA Overview
Parameter | Value | Description |
---|---|---|
RPO |
4 hours 8 hours 12 hours 24 hours |
Selectable RPO in 4 options. |
RTO | 4 hours | Timeframe within the VM must be started in the secondary data-center in case of a successful registration of a P1 incident. |
# Retention points |
2 (latest + 1) |
Amount of retention point available in secondary data-center. |
In case of disaster, Equinix will failover the VMs to the secondary data-center on explicit user approval as part of the priority 1 (P1) incident. Equinix begins the failover procedure by starting the replicated VMs in the secondary data-center. The network configuration in the secondary data-center must be pre-configured properly for a successful failover. The user is responsible for functional network testing.
If the situation in the primary data-center returns to normal again, Equinix can move the user's VMs back to the original location. An annual failover test can be requested by the user as a Service Request.
Performance and Capacity
For a DRaaS service, it is critical to know which activities impact the performance, capacity, and responsibility of the environment. These responsibilities include:
-
The technology underneath the EBC Availability service for EBC Core is snapshot based. Performing snapshot-based replications can impact the VM performance.
-
The user is responsible for selecting the suitable EBC compute and storage performance level in the secondary data-center. The selected performance level should meet the user SLA and expected performance in case a failover needs to be performed. This is required for Equinix to guarantee the storage tier in the secondary data-center.
-
The user needs to make sure the amount of EBC compute and storage capacity in the second data-center is sufficient to perform a full failover. When resources like test & dev are running in the secondary locations, these could need to be shutdown by the user before production workloads can be failed over.
-
The availability and capacity of the replication link in cloud-to-cloud scenarios is part of the service. Equinix makes sure it is available and has sufficient capacity to meet the SLA.
Billing Options
EBC Core Availability Standard is billed on a VM per month. Pricing includes replication connectivity and bandwidth, and is offered in 4 SLA groups:
-
EBC Core Availability RPO = 4
-
EBC Core Availability RPO = 8
-
EBC Core Availability RPO = 12
-
EBC Core Availability RPO = 24
Costs for compute and storage capacity in the secondary data-center is part of the EBC Core service. Multi-site networking connectivity for VMs is additionally required.
Metering
To determine the amount of replicated VMs for billing, all VMs that were part of a certain SLA Profile on a daily basis, are counted.
-
If a VM is removed from the SLA group before the end of the month, it will not be billed the next month.
-
If a VM is changed between different SLA Profiles within a month, it will be billed accordingly.
Relations and Dependencies
EBC Core Availability can only be consumed as part of the EBC Core platform services.
-
During failover, no replication takes place, and therefore does not adhere to the SLA.
-
During the failback configuration phase (re-protect), no replication takes place, and therefore does not adhere to the SLA.
-
Returning to the situation before the disaster, is required. Failback should be performed within 1 month after the disaster.
-
Back-ups during failover are only in place when the user has requested for a backup plan for the secondary data-center.