Dual Site
Aperçu
Les datacenters
Présentation
Cloud Avenue (NGP) est déployé sur 2 datacenters situés en France. Ces datacenters sont de conception Orange et intègrent une technologie de refroidissement naturel (« free cooling ») leur permettant d’atteindre un PUE inférieur à 1.3. Un datacenter comporte plusieurs bâtiments, chacun composé de 4 salles totalement indépendantes en énergie, réseau et refroidissement. La conception même des bâtiments garantie une non-propagation d’incendie entre les salles de 4h.
| Datacenter | Code | Nombre de salles hébergeant les charges de travail des clients |
|
Val de Reuil – Normandy 1 |
VDR | 2 |
| Chartres | CHA | 1 |
La solution de sauvegarde utilisée sur la plateforme est hébergée dans une salle différente et indépendante du reste de la plateforme, quel que soit le site.
L’infrastructure de management du site de VDR est repartie sur 3 salles pour un maximum de résilience avec .
Certifications
Nos datacenters sont certifiés :
- ISO 14 001 sur le management environnemental
- ISO 50 001 sur le management de l’énergie
- ISAE 3402/ SOC2 Standard Américain issu de SOX et qui certifie le respect des exigences de sécurité d’accès physique et de fonctionnement
Ils ont également les agréments Mastercard et PCI DSS sur la sécurisation des données bancaires
Interconnexion
Les deux sites sont reliés par un lien physique en fibre noire de 2x100Gbps avec une latence inférieure à 5ms.
Principe et fonctionnalités
Chaque site est indépendant et autonome. Cependant, il est possible d’utiliser simultanément les ressources de chaque site afin de construire des scénarios de reprise d’activité ou de continuité d’activité.
Plusieurs configurations sont possibles, chacune permettant différents cas d’usage, détaillés ci-après.
Bi-site actif/passif
Cette topologie permet la mise en place d’un plan de reprise d’activité (PRA), assez simplement, avec l’outil intégré au portail VCD, VCDA (vCloud Director Availability). La page Réplication de VM fournie toutes les informations à savoir sur le fonctionnement de VCDA.
Bi-site actif/actif
Cette topologie fournit plusieurs mécanismes de redondance, et permet notamment la mise en place d’un plan de continuité d’activité (PCA), en installant une même application sur les 2 sites.
Cas d’usage
Plusieurs cas d’usages sont supportés dans une configuration bi-site.
Cas d’usage 1 – PRA
|
Une application est déployée sur un site nominal, ici VDR. L’application est protégée par VCDA et prête à redémarrer sur le site de secours, ici CHA.
|
 |
|
En cas de panne d’un ou plusieurs composants de la plateforme rendant inopérant le service exposé, le client peut déclencher son PRA (configuré avec VCDA) et ainsi rétablir le service dans un délai très court, avec un minimum de perte de données.
Le retour arrière se fait tout naturellement avec VCDA, sans perte de données, une fois le service sur VDR rétabli. L’IP publique migrera alors vers le site nominal.
|
 |
Cas d’usage 2 – Redondance de l’accès internet
|
Les 2 organisations sur VDR et CHA sont initialement indépendantes.
|
 |
|
Le multisites a été configuré et fournit :
Il est important de bien configurer l’adressage réseau de chaque site afin qu’il soit compatible et complémentaire. Ici, une application fonctionne sur les 2 sites en actif/actif. L’accès internet du site de VDR est utilisé pour exposer le service.
|
 |
|
Incident majeur sur le site de VDR : l’accès internet du site de VDR est indisponible (incident backbone).
Le trafic internet est entièrement assuré par le site de CHA, y compris pour les VM de VDR. |
 |
Cas d’usage 3 – Redondance de l’accès BVPN
|
Les 2 organisations sur VDR et CHA sont initialement indépendantes.
se protéger d’une défaillance de l’accès BVPN d’un des 2 sites = avoir une redondance de l’accès BVPN pour le site impacté par la panne.
Ici on va aussi configurer un L2VPN, ce qui permet d’avoir du « LAN étendu » et de permettre la communication entre les VM de chaque site. Cette fonctionnalité nécessite une configuration ajustée des pools de chaque réseau local, afin d’éviter le recouvrement d’adresse IP. |
 |
|
Incident majeur sur le site de VDR : l’accès BVPN du site de VDR est indisponible (incident backbone).
Les applications hébergées sur chaque site sont accessibles de l’intranet. |
 |
Cas d’usage 4 – Redondance de l’accès BVPN
|
Les 2 organisations sur VDR et CHA sont initialement indépendantes.
se protéger d’une défaillance de l’accès BVPN d’un des 2 sites = avoir une redondance de l’accès BVPN pour le site impacté par la panne.
Ici, nous n’avons pas créé de L2VPN. Dans ce cas, les configurations réseau pourraient être totalement identiques, ou au contraire totalement différentes. |
 |
|
Incident majeur sur le site de VDR : l’accès BVPN du site de VDR est indisponible (incident backbone).
Les applications hébergées sur chaque site sont accessibles de l’intranet. |
 |
Cas d’usage 5 – Stretched Cluster vCoD (Service Cloud Avenue Private)
Le cluster étendu présente le plus haut niveau de disponibilité et permet de palier la perte d’un site.
Le service utilise des profils de VM étendus, ce qui signifie que chaque VM dispose de ses données sur chaque site.
Ainsi, la VM est actualisée et disponible en permanence sur chaque site.
Au niveau infrastructure, le service s’appuie sur un cluster étendu déployé sur les deux datacenters Orange de Val-de-Reuil et Chartres.
Un minimum de 4 serveurs est requis sur chaque site (4+4) avec une configuration symétrique.
PCA = Continuité de service => En situation nominale, les workloads sont répartis entre les 2 sites de manière équilibrée (50/50) mais chaque site est en mesure de supporter l’ensemble de la charge. Ainsi, en cas de perte d’un site, le second site pourra redéployer l’ensemble des workloads.
Le profil de sécurisation de stockage est applicable granulairement à la VM (le Client peut sélectionner laquelle des VM déployées redémarrera automatiquement sur le second datacenter).
Le dimensionnement et le capacity planning devront être établis pour respecter le principe de continuité de service et permettre ce basculement (100% des VMs protégées doivent pouvoir fonctionner sur un seul site).
La facturation est standard et s’appuie sur les UO de la fiche tarifaire identifiées HADR.
À noter
Le plan de contrôle est déployé en mode actif/passif : une seule instance est démarrée sur le site primaire. En cas de perte du site primaire, l’instance est redémarrée sur le site secondaire.
Facturation
Chaque site étant indépendant, il est facturé de manière indépendante. Les usages sont normalement remontés par site et facturés, comme n’importe quelle organisation Cloud Avenue.
Une facturation supplémentaire interviendra sur la base du traffic échangé entre les 2 organisations. Voir la fiche tarifaire pour les détails.
Commande
Chaque organisation se commande via le processus de commande normal d’une organisation. A chaque site correspond une organisation, et donc un contrat.