Dual-Site

Preview

Datacenters

Presentation

Cloud Avenue (NGP) is deployed in 2 datacenters located in France. These data centers are made by "Orange design" and integrate natural cooling technology (“free cooling”) allowing them to achieve a PUE of less than 1.3. A data center includes several buildings, each made up of 4 rooms that are completely independent in terms of energy, network and cooling. The very design of the buildings guarantees non-propagation of fire between rooms for 4 hours.

Datacenter	Code	Number of rooms hosting customer workloads
Val de Reuil - Normandy 1	VDR	2
Chartres	CHA	1

The backup solution used on the platform is hosted in a different room and independent from the rest of the platform, regardless of the site.

The management infrastructure of the VDR site is spread over 3 rooms for maximum resilience with .

Certifications

Our data centers are certified :

• ISO 14 001 for environmental management
• ISO 50 001 for energy management
• ISAE 3402/ SOC2  American standard resulting from SOX and which certifies compliance with physical access and operational security requirements

They also have Mastercard and PCI DSS approvals for banking data security.

Interconnection

The two sites are connected by a physical 2x100Gbps dark fiber link with a latency of less than 5ms.

Principle and functionalities

Each site is independent and autonomous. However, it is possible to use the resources of each site simultaneously in order to construct business recovery or business continuity scenarios.

Several configurations are possible, each allowing different use cases, detailed below.

Dual site active/passive

This topology allows the implementation of a disaster recovery plan (PRA), quite simply, with the tool integrated into the VCD portal, VCDA (vCloud Director Availability). The VM Replication page provides all the information you need to know about how VCDA works.

Dual site active/active

This topology provides several redundancy mechanisms, and in particular allows the implementation of a business continuity plan (BCP), by installing the same application on the 2 sites.

Use cases

Several use cases are supported in a two-site configuration.

Use case 1 - PRA

An application is deployed on a nominal site, here VDR. The application is protected by VCDA and ready to restart on the backup site, here CHA. The application is exposed on the internet and uses a public IP address, referenced in a public DNS.

In the event of a breakdown of one or more components of the platform rendering the exposed service inoperable, the customer can trigger its PRA (configured with VCDA) and thus restore the service in a very short time, with minimal data loss. Here, the public IP will migrate to the backup site and allow the service to be fully available, once BGP sync is complete. The rollback is done quite naturally with VCDA, without loss of data, once the service on VDR is reestablished. The public IP will then migrate to the nominal site. Important: choose vDCs in PAYG mode on the recovery site, in order to minimize billing on the backup site.

Use case 2 - Redundancy of internet access

The 2 organizations on VDR and CHA are initially independent. Needs : make the VMs of the 2 sites communicate protect yourself from a failure of internet access to the nominal site (here VDR) = have redundancy of internet access have an automatic switch of the public IP. The first step is to configure multi-site in VCD (the 2 organizations will be paired). This operation is detailed on this page.
Multisite has been configured and provides: the possibility of configuring an L2VPN between the 2 local networks of each site, in order to allow communication between the VMs. a logical link between the T0 VRFs, which will make it possible to manage the automatic switchover of traffic in the event of loss of primary internet access; Each T0 VRF will define the default exit route to the internet for each site. It is important to properly configure the network addressing of each site so that it is compatible and complementary. Here, an application works on the 2 sites in active/active mode. Internet access to the VDR site is used to expose the service. The public IP is NATed on the VIP of the Load Balancer, hosted on a VM (the Load Balancer of the T1 cannot be used in this case, because a T1 does not "see" the remote local network). Each VM uses its local access to go out to the internet. The local networks of each site are configured to be compatible with each other (same subnet, division of the addressing plan per site). The VMs are able to communicate with each other between the two sites, and the synchronization of transactions is carried out via application mechanisms.
Incident majeur sur le site de VDR : l'accès internet du site de VDR est indisponible (incident backbone). Que se passe-t-il côté NSX ? La T0 VRF de VDR ne communique plus avec internet, et n'est plus capable de router le traffic internet directement via son interface principale. La T0 VRF de VDR "décide" que la passerelle par défaut est maintenant côté CHA, et va router tout le trafic internet vers la T0 VRF de CHA (bascule BGP) L'IP publique exposée sur la T0 VRF de VDR est aussi basculée sur la T0 VRF de CHA, et la bascule BGP la rend accessible à partir de CHA. L'application continue à fonctionner normalement. Le trafic internet est entièrement assuré par le site de CHA, y compris pour les VM de VDR. Criitical issue on the VDR site: internet access to the VDR site is unavailable (backbone incident). What's happening on the NSX side? VDR's T0 VRF no longer communicates with the internet, and is no longer capable of routing internet traffic directly via its main interface. The VDR T0 VRF "decides" that the default gateway is now on the CHA side, and will route all internet traffic to the CHA T0 VRF (BGP switchover) The public IP exposed on VDR's T0 VRF is also switched to CHA's T0 VRF, and the BGP switch makes it accessible from CHA. The application continues to function normally. Internet traffic is entirely provided by the CHA site, including for VDR VMs.

Use case 3 - Redundancy of BVPN access

The 2 organizations on VDR and CHA are initially independent. The need : protect yourself from a failure of BVPN access to one of the 2 sites = have redundancy of BVPN access for the site impacted by the failure. The first step is to configure multi-site in VCD (the 2 organizations will be paired). This operation is detailed on this page. Here we will also configure an L2VPN, which allows for “extended LAN” and allows communication between the VMs of each site. This functionality requires an adjusted configuration of the pools of each local network, in order to avoid IP address overlap.

Major incident on the VDR site: BVPN access to the VDR site is unavailable (backbone incident). What's happening on the NSX side? VDR's T0 VRF no longer communicates with the BVPN router, and is no longer capable of routing intranet traffic directly via its main interface. The VDR T0 VRF "decides" that the default gateway is now on the CHA side, and will route all intranet traffic to the CHA T0 VRF (BGP switchover) The applications hosted on each site are accessible from the intranet.

Use case 4 - Redundancy of BVPN access

The 2 organizations on VDR and CHA are initially independent. The need : protect yourself from a failure of BVPN access to one of the 2 sites = have redundancy of BVPN access for the site impacted by the failure. The first step is to configure multi-site in VCD (the 2 organizations will be paired). This operation is detailed on this page. Here we have not created an L2VPN. In this case, the network configurations could be completely identical, or on the contrary completely different.

Major incident on the VDR site: BVPN access to the VDR site is unavailable (backbone incident). What's happening on the NSX side? VDR's T0 VRF no longer communicates with the BVPN router, and is no longer capable of routing intranet traffic directly via its main interface. The VDR T0 VRF "decides" that the default gateway is now on the CHA side, and will route all intranet traffic to the CHA T0 VRF (BGP switchover) The applications hosted on each site are accessible from the intranet.

Use case 5 - Stretched Cluster vCoD (Cloud Avenue Private Service)

The extended cluster presents the highest level of availability and makes it possible to compensate for the loss of a site.

The service uses extended VM profiles, which means that each VM has its data on each site.

Thus, the VM is updated and permanently available on each site.

At the infrastructure level, the service relies on an extensive cluster deployed in the two Orange data centers in Val-de-Reuil and Chartres.

A minimum of 4 servers is required on each site (4+4) with a symmetrical configuration.

PCA = Service continuity => In a nominal situation, the workloads are distributed between the 2 sites in a balanced manner (50/50) but each site is able to support the entire load. Thus, in the event of the loss of a site, the second site will be able to redeploy all the workloads.

The storage security profile is granularly applicable to the VM (the Customer can select which of the deployed VMs will automatically restart on the second datacenter).

The sizing and capacity planning must be established to respect the principle of continuity of service and allow this switchover (100% of the protected VMs must be able to operate on a single site).

Please note!
The control plane is deployed in active/passive mode: a single instance is started on the primary site. If the primary site is lost, the instance is restarted on the secondary site.

Billing

Each site being independent, it is billed independently. Usage is normally reported by site and billed, like any Cloud Avenue organization.

Additional invoicing will occur based on the traffic exchanged between the 2 organizations. See price sheet for details.

Order

Each organization orders through the normal organization ordering process. Each site corresponds to an organization, and therefore a contract.

Short Links :