Noyau de nuage privé géré

MPC Core est une option dédiée basée sur VMware Cloud Foundation (VCF) pour les clients qui ont besoin d'un contrôle complet de la pile au sein d'un environnement géré. MPC Core fournit une infrastructure dédiée avec des ressources de calcul, de stockage et de réseau dans un Secure Cabinet Express dédié dans un datacenter Equinix.

Le service MPC Core est basé sur les modèles architecturaux de VMware Cloud Foundation et aligné sur ceux-ci. La connectivité est prise en charge pour les réseaux de couche 2 et 3 via Equinix Fabric ou des connexions directes via Equinix Metro, Campus et/ou Cross Connect. Equinix gère la pile complète, y compris VCF, tandis que les clients configurent leur infrastructure dans les limites d'un déploiement VCF. Les clients peuvent choisir d'inclure la licence VCF dans le service ou d'utiliser l'option BYOL de Broadcom.

MPC Core est disponible dans des centres de données sélectionnés dans le monde entier. En cas d'achat dans différentes régions (AMER, EMEA, APAC), une implémentation indépendante est livrée pour chaque région. Lorsque plusieurs implémentations sont livrées dans la même région, Active Directory et DNS peuvent être partagés entre ces implémentations.

Contenu lié : Cloud privé hébergé

Accès

Pour différents cas d'utilisation, l'accès à MPC Core est requis :

• Premier accès lors de la livraison pour configurer le service MPC Core
• Accès à la plate-forme pour la gestion
• Accès de secours lorsque l'accès utilisateur normal n'est pas disponible

Premier accès

Pour obtenir un accès initial à MPC Core, une solution IPSec VPN est disponible. Grâce à ce VPN, le client peut configurer la connectivité requise pour gérer l'environnement. L'installation, la configuration et les informations d'identification de la solution VPN sont fournies au client lors de l'exécution.

Accès à la plate-forme

Les portails et services suivants sont disponibles pour permettre au client de gérer MPC Core.

Portail	Objectif
Opérations VCF	Gestion et opérations VCF
VCF Identity Broker (courtier en identité)	Authentification centralisée
Opérations VCF pour les journaux	Journalisation de la plate-forme VCF
vCenter	Gestion des machines virtuelles
Gestionnaire NSX	mise en réseau définie par logiciel
HCX Manager	Outils de migration
Hyperviseur ESX	Accès à la console VM

Pendant l'exécution, les adresses IP et les noms de domaine complets des portails MPC Core sont partagés avec le client pour la configuration de l'environnement. Pour accéder aux portails, mettez à jour la configuration du pare-feu afin d'autoriser les éléments suivants :

Rôle	Direction	Objectif	Services autorisés
Système de noms de domaine	Inbound	Résolution de noms DNS du client vers les serveurs DNS MPC	DNS (TCP, UDP/53), PING
Système de noms de domaine	Sortie	Résolution de noms DNS de MPC vers les serveurs DNS du client	DNS (TCP, UDP/53), PING
NTP	Inbound	Synchronisation de l'heure réseau du client vers les serveurs de temps MPC	NTP (TCP, UDP/123), PING
Opérations VCF	Inbound	Accès client au portail des opérations VCF	HTTP (TCP/80), HTTPS (TCP/443), PING
VCF Identity Broker (courtier en identité)	Inbound	Accès client au portail Identity Broker	HTTPS (TCP/443), ping
VCF Identity Broker (courtier en identité)	Sortie	Accès Identity Broker au LDAP du client	TCP/636, TCP/3269, ping
Opérations VCF pour les journaux	Inbound	Accès client au portail VCF Ops for Logs	HTTPS (TCP/443), ping
vCenter	Inbound	Accès client au portail vCenter	HTTP (TCP/80), HTTPS (TCP/443), PING
Gestionnaire NSX	Inbound	Accès client au portail NSX Manager	HTTPS (TCP/443), ping
HCX Manager	Inbound	Accès client au portail HCX Manager	HTTPS (TCP/443), ping
ESX	Inbound	Accès client à l'hyperviseur ESX pour l'accès à la console VM	HTTPS (TCP/443), ping

Configuration de Portal Access

Pour accorder aux utilisateurs de l'entreprise du client l'accès à l'environnement MPC Core, il est important de comprendre les options et les limitations de gestion des identités et des accès (IAM) disponibles. Les utilisateurs sont gérés dans le service d'annuaire du client, qui est connecté à MPC Core Identity Broker via LDAPS. Identity Broker est le composant VCF qui utilise des groupes de clients pour accorder l'accès à l'environnement MPC Core en fonction de rôles prédéfinis. L'authentification des composants VCF tels que vCenter et VCF Operations est gérée par Identity Broker.

Le client doit définir des groupes dans le service d'annuaire. Ces groupes sont importés dans Identity Broker et utilisés pour l'authentification et l'autorisation.

Identity Broker

Identity Broker est le composant VMware VCF qui gère l'authentification unique (SSO) sur l'ensemble de la plate-forme. Identity Broker permet d'accéder aux services suivants :

• Gestionnaire NSX
• Opérations VCF
• vCenter
• Opérations VCF pour les journaux
• HCX Manager

Access Management Protocol

Le protocole pris en charge pour la gestion des identités et des accès est LDAPS. Les clients peuvent connecter leur propre fournisseur d'identité (IdP) à l'aide de LDAPS. Pour utiliser LDAPS, configurez le transfert DNS. Les procédures de déploiement sont fournies lors de l'exécution de la commande.

Configuration des utilisateurs, des groupes, des rôles et des autorisations

Lors de l'exécution, les groupes de clients sont affectés aux rôles principaux MPC. Les clients doivent fournir des groupes à partir de leur propre service d'annuaire. L'équipe d'exécution configure les rôles et les groupes dans l'environnement MPC Core.

Les modifications des autorisations ou des affectations de groupe peuvent être demandées en soumettant une demande de service. Il est conseillé aux clients de :

• Utilisez un nom unique pour chaque groupe affecté à un rôle MPC. Au minimum, fournissez des groupes pour le rôle d'accès le plus élevé pour chaque composant VCF. Sinon, le client ne peut pas gérer ce composant.

  • Par exemple : opérateur VCF, vCenter Admin, NSX Admin

• Pour chaque composant VCF (par exemple, vCenter ou NSX), n'affectez pas un utilisateur à plusieurs groupes pour le même composant.

  • Par exemple : n'affectez pas un seul utilisateur aux groupes « vCenter Admin » et « vCenter ReadOnly ». VCenter utilise un modèle de moindre privilège, de sorte que le niveau d'autorisation le plus bas s'applique.

Rôle(s) principal(s) MPC	Composant	Exemple de groupe(s) de clients	Statut	Objectif
Customer_VCF_Operator	Opérations VCF	ADM_VCF_Operator	Exigée	Rôle qui permet aux clients de gérer la plate-forme VCF avec les autorisations opérateur
Customer_VCF_ReadOnly	Opérations VCF	N/A	En option	Rôle qui permet aux clients de gérer la plate-forme VCF avec des autorisations ReadOnly
Customer_vCenter_Admin	vCenter	ADM_vCenter_Admin	Exigée	Rôle qui permet aux clients de gérer vCenter avec des autorisations d'administrateur limitées
Customer_vCenter_Operator	vCenter	N/A	En option	Rôle permettant aux clients de gérer vCenter avec les autorisations Operator
Customer_vCenter_User	vCenter	N/A	En option	Rôle permettant aux clients de gérer vCenter avec des autorisations utilisateur
Customer_vCenter_ReadOnly	vCenter	ADM_vCenter_Monitor	En option	Rôle permettant aux clients de gérer vCenter avec des autorisations ReadOnly
Customer_vCenter_Backup-Admin	vCenter	ADM_vCenter_Backup	Requis si l'intégration de la sauvegarde du client est nécessaire	Rôle pour les comptes de service client qui effectuent des sauvegardes pour les charges de travail client exécutées sur la plate-forme VCF
Customer_vCenter_Replication-Admin	vCenter	N/A	Requis si l'intégration de réplication client est nécessaire	Rôle pour les comptes de service client qui exécutent la réplication des charges de travail client exécutées sur la plate-forme VCF
Customer_HCX_tenant	HCX (migration)	ADM_HCX_tenant	Requis si HCX est nécessaire	Rôle qui permet aux clients de gérer HCX, à l'exception de la gestion des profils réseau
Customer_NSX_Admin	NSX	ADM_NSX_Admin	Exigée	Rôle qui permet aux clients de gérer NSX avec des autorisations d'administrateur limitées
Customer_NSX_Operator	NSX	N/A	En option	Rôle qui permet aux clients de gérer NSX avec les autorisations opérateur
Customer_NSX_ReadOnly	NSX	N/A	En option	Rôle qui permet aux clients de gérer NSX avec des autorisations ReadOnly

Configuration de LDAP

Equinix configure LDAPS sur le courtier d'identités dans le cadre du processus de déploiement initial de MPC Core. Pour établir une connexion LDAPS sécurisée, MPC Core doit accéder au fournisseur d'identité client (IdP) en utilisant son nom DNS et en validant les certificats associés. La résolution de noms DNS doit être configurée dans les deux sens entre MPC Core et l'environnement du client.

Les étapes suivantes sont nécessaires pour connecter MPC Core au fournisseur d'identité du client.

Règles de pare-feu et transfert DNS

Le client doit activer les règles de pare-feu requises dans l'environnement client où Equinix fournit les adresses IP source MPC Core.

Serveurs DNS et LDAP du client

Le client doit fournir les adresses IP et les noms de domaine complets des systèmes suivants :

• Serveurs DNS du client
• Serveurs LDAP du client
• Contrôleurs de domaine Active Directory du client, le cas échéant

Certificat CA

Le client doit fournir le certificat CA qui a signé les certificats utilisés par les serveurs LDAP. Ce certificat est généralement un certificat D'AUTORITÉ DE CERTIFICATION racine et n'inclut pas de clé privée . Le certificat doit être fourni au format PEM et inclure les lignes de CERTIFICAT DE DÉBUT et DE FIN.

Paramètres LDAP

Le client doit fournir les paramètres LDAP suivants.

Paramètres	Valeur
Nom de domaine complet	customer.com
DN de base	DC=client, DC=com
Lier le nom d'utilisateur	CN, OU, OU, DC, DC Exemple : CN=ldap-sa, OU=comptes de service, OU=groupes, DC=client, DC=com
Mot de passe de l'utilisateur de liaison	<Password via secure media>

Accès aux portails VCF

MPC Core fournit un accès direct aux portails VCF. Cet accès nécessite un routage entre l'environnement MPC Core et le réseau du client. Une fois la connectivité établie, les clients peuvent accéder aux portails VCF via cette connexion.

Vue d'ensemble de l'accès au service

Le service s'exécute sur une plate-forme VMware dédiée qui inclut des composants tels que vCenter et NSX. Tous les composants de plate-forme et de service résident dans des sous-réseaux de gestion segmentés. Étant donné que la plate-forme utilise des noms d'hôte sur tous les composants, les clients doivent configurer la résolution DNS et établir un certificat de confiance pour accéder aux services et portails de la plate-forme.

Résolution DNS

Les clients doivent configurer le transfert DNS de sorte que les résolveurs DNS internes puissent atteindre les serveurs DNS MPC Core. Pour configurer la résolution DNS :

1. Acceptez les routes annoncées par MPC Core afin que les serveurs DNS des clients puissent atteindre les serveurs DNS MPC Core.
2. Configurez un redirecteur conditionnel sur les serveurs DNS du client pour les zones DNS MPC Core.
3. Créez une zone DNS inverse sur les serveurs DNS du client pour chaque réseau annoncé par MPC Core.

Certificat de confiance

MPC Core utilise une autorité de certification (CA). Cela garantit que tous les composants MPC Core, tels que vCenter et NSX Manager, utilisent des certificats émis et renouvelés par un serveur central. Dans le cadre du service géré, Equinix procède au renouvellement des certificats.

Pour s'assurer que les certificats MPC Core sont approuvés, les clients doivent ajouter le certificat MPC Core CA racine à leurs systèmes internes. Cela empêche les messages d'avertissement de certificat d'apparaître dans les navigateurs des clients. Tous les certificats MPC Core utilisent la norme de dénomination suivante : xxx.mpc-core.com

Ajout du certificat D'AUTORITÉ DE CERTIFICATION racine MPC Core

Les clients peuvent généralement ajouter le certificat D'AUTORITÉ DE CERTIFICATION racine MPC Core à leurs appareils de l'une des manières suivantes :

1. Distribuez le certificat CA racine via Device Management

   • Dans la plupart des environnements, des outils tels que la stratégie de groupe Microsoft Active Directory sont utilisés pour distribuer des certificats racine approuvés. Les solutions de gestion des périphériques d'autres fournisseurs peuvent offrir des fonctionnalités similaires.

2. Installez le certificat manuellement sur chaque appareil

   • Importez la chaîne CA dans les magasins de confiance des clients

     • Importez le certificat CA racine et tous les certificats CA intermédiaires fournis par Equinix au format .CER ou .crt.
     • Importer les certificats dans :
       • Magasin de confiance du système d'exploitation (Windows : ordinateur local → racine sécurisée/intermédiaire ; Linux : magasin de confiance du système selon le cas ; macOS : trousseau du système).
       • Confiance du navigateur (Chrome/Edge/Firefox hérite de la confiance du système d'exploitation sur la plupart des plates-formes ; si votre stratégie isole la confiance du navigateur, importez-la également).
       • Clients non-navigateurs (outils d'automatisation, SDK, modules PowerShell, clients API) s'ils conservent des magasins de confiance séparés.

   • Accessibilité CRL et OCSP

     • Si la vérification de la révocation des certificats est appliquée, assurez-vous que vos systèmes peuvent atteindre les points finaux CRL/OCSP spécifiés dans les certificats. Si ceux-ci ne sont pas accessibles depuis votre réseau, configurez votre stratégie en conséquence ou contactez le support technique Equinix pour demander des fichiers CRL hors ligne.

   • Politique de protocole

     • Assurez-vous que la base de sécurité du client autorise TLS 1,2 ou supérieur et les suites de chiffrement modernes courantes.

RÉSULTATS

Les navigateurs et les clients font confiance aux points de terminaison de la plate-forme (par exemple, vCenter, NSX Manager) sans avertissement, ce qui permet un accès sécurisé.

Accès de contingence

Lorsque l'accès normal à MPC Core n'est pas disponible, les clients peuvent utiliser une solution VPN de secours pour accéder à l'environnement. Les clients doivent télécharger et installer le logiciel VPN et le configurer pour l'accès MPC Core. Pour utiliser ce service, les clients doivent fournir une plage IP sur liste blanche.

Connectivité externe

MPC Core peut se connecter à l'environnement du client via Cross Connect, Metro Connect ou Fiber Connect en utilisant la fibre monomode à 1 Gbps, 10 Gbps ou 25 Gbps. Ces connexions peuvent être configurées comme une connexion unique non redondante. Pour une configuration redondante, LACP est requis.

La connectivité Equinix Fabric est disponible sur fibre monomode à 1 Gbps ou 10 Gbps. La structure peut être configurée dans une configuration unique ou redondante en utilisant un seul circuit virtuel (VC) ou deux circuits virtuels sur différents ports.

Le tableau suivant indique les options de connectivité disponibles et le nombre de ports disponibles.

Produit	Bande passante prise en charge	Type	Ports disponibles
Cross Connect, Metro Connect, Fiber Connect	1 Gbps	Fibre monomode	4
Cross Connect, Metro Connect, Fiber Connect	10/25 Gbps	Fibre monomode	2
Fabric	10 Gbit/s	Fibre monomode	4

Les connexions externes (VLAN) sont terminées par défaut sur le serveur Edge NSX fourni par Equinix. Les clients peuvent également utiliser leur propre appliance virtuelle pour mettre fin aux connexions externes. Cette configuration peut être appliquée après la prestation du service. Si les arêtes ne sont pas nécessaires, les clients peuvent les supprimer via le libre-service du portail VCF.

Plage VLAN

Pour la connectivité de service de couche 2, 64 VLAN consécutifs dans la plage 2000-4000 sont réservés aux connexions externes. Ces VLAN prennent en charge les services de connectivité de couche 2 tels que Metro Connect et Cross Connect et permettent une extension future. Si le client ne spécifie pas de plage VLAN de départ, Equinix attribue les VLAN 2000 à 2063. Ce choix est définitif et ne peut pas être modifié ultérieurement. Un VLAN est configuré sur une seule connexion externe pour éviter les boucles de couche 2.

Plage IP

Pour les outils de gestion Equinix, les clients doivent fournir une plage IP /18 afin que les services puissent être acheminés correctement. Cette allocation standard :

• Empêche le chevauchement entre le déploiement du service et le plan d'adresses IP du client.
• Permet un accès direct aux services sans NAT, y compris vCenter, NSX Manager, les téléchargements de modèles, les intégrations IdP, et d'autres intégrations.
• Permet à l'environnement de service de se développer sans contraintes d'adresse IP.

Si le client ne spécifie pas de plage IP, Equinix sélectionne une plage IP dans RFC1918 172.16. Ce choix est définitif et ne peut pas être modifié ultérieurement.

Intégration d'applications

MPC Core prend en charge l'intégration avec les applications client, telles que les outils de sauvegarde et de reprise après sinistre. Pour maintenir la disponibilité du service, les méthodes d'intégration suivantes ne sont pas prises en charge :

• Accès root à l'hyperviseur
• Applications nécessitant l'installation d'un logiciel fourni par le client sur l'hyperviseur. Les exemples incluent Veeam CDP, Rubrik CDP et Zerto.

MPC Core Blueprints

La conception de MPC Core est basée sur le modèle VMware VCF Fleet in a Single site with minimal Footprint , avec HA activé au niveau du composant de gestion (implémentations en cluster). Les composants de gestion VCF et les ressources client s'exécutent dans un cluster unique. Ce modèle fournit un domaine de gestion contenant un cluster avec un pool de ressources pour les composants de gestion et un pool de ressources pour les ressources client.

Le domaine de gestion est en outre équipé de VCF Operations HCX pour soutenir la migration vers la plateforme MPC Core. Le domaine de gestion est contrôlé par Equinix. Le pool de ressources contient des ressources client et la capacité disponible dépend des composants de gestion installés, du nombre d'hôtes dans le cluster et du type d'hôte.

Le stockage est assuré par vSAN. Pour la connectivité, un client peut utiliser NSX et/ou installer une appliance de routage autogérée. Un client peut également utiliser le service Managed Firewall, qui est une offre de pare-feu gérée par Equinix et qui doit être commandée séparément (Option Connectivity Managed Firewall).

Flotte

Un parc est une construction architecturale qui regroupe plusieurs instances VCF pour prendre en charge la gestion centralisée et les opérations en libre-service. La première instance MPC Core d'un datacenter est un parc VCF contenant une seule instance VCF. Cette conception prend en charge jusqu'à 5 clusters, 100 hôtes ou 1000 machines virtuelles par défaut. Lorsqu'une mise à l'échelle supplémentaire est nécessaire, la taille de certains composants de gestion doit être augmentée et cette capacité est déduite du pool de ressources client.

Les logiciels installés inclus dans le MPC Core VCF Fleet in a Single Site sont :

• Installateur VCF
• Gestion de flotte VCF
• Opérations VCF
• VCF Operations Cloud Proxy
• vCenter
• Responsables NSX
• NSX Edge
• Opérations VCF pour les journaux
• VCF Identity Broker (courtier en identité)
• Opérations VCF HCX
• Infrastructure de gestion de base (Active Directory Domain Services, DNS, Autorité de certification, surveillance NTP, Jump Host)

Armoire centrale MPC

MPC Core est livré depuis un centre de données Equinix dans une Secure Cabinet Express dédiée. En fonction de sa taille, un cluster peut s'étendre sur plusieurs armoires. L'armoire et l'alimentation électrique sont incluses dans le prix de l'hébergement. L'armoire et l'accès sont gérés par Equinix et ne sont pas disponibles pour l'équipement du client. Le nombre maximum d'hôtes par armoire dépend de la disponibilité de l'énergie ainsi que du nombre et de la consommation d'énergie des serveurs.

MPC Core infrastructure

Pour la gestion du MPC Core, la première armoire est équipée de pare-feu de gestion, de capacités de gestion hors bande (OOB) et de commutateurs de gestion. Chaque armoire comprend deux commutateurs redondants avec 2×48 ports 25 Gbps pour la connectivité externe et la connectivité des serveurs. Chaque serveur utilise deux ports de chaque commutateur pour la redondance. Les commutateurs sont gérés par Equinix. Lorsque deux armoires sont déployées, les commutateurs sont interconnectés de manière redondante entre les armoires, ce qui fournit une bande passante de 400 Gbps.

MPC Core Cluster

• Cluster - Un environnement MPC Core comprend une configuration de cluster d'au moins sept hôtes, dans laquelle six hôtes sont disponibles et un hôte est réservé à la maintenance et à la haute disponibilité (principe N + 1).
• Hébergez - MPC Core fournit un catalogue de types d'hôtes basés sur le CPU, les cœurs, la RAM et le stockage.

Hôte	Type d'hôte	Type de facturation	Description
AHL-16L05V4#4	Hôte générique	Base de référence	16C, 512GB RAM, 4*3.84TB NVME
AHL-16L05V6#4	Hôte générique	Base de référence	16C, 512GB RAM, 6*3.84TB NVME
AHL-32L05V8#4	Hôte générique	Base de référence	32C, 512GB RAM, 8*3.84TB NVME
AHL-32L05V6#8	Hôte générique	Base de référence	32C, 512GB RAM, 6*7.68TB NVME
AHL-32L05V8#8	Hôte générique	Base de référence	32C, 512GB RAM, 8*7.68TB NVME
AHL-32L05V6#15	Hôte générique	Base de référence	32C, 512GB RAM, 6*3.68TB NVME
AHL-32L10V8#4	Hôte générique	Base de référence	32C, 1024GB RAM, 4*15.36TB NVME
AHL-32L10V6#8	Hôte générique	Base de référence	32C, 1024GB RAM, 6*7.68TB NVME
AHL-32L10V8#8	Hôte générique	Base de référence	32C, 1024GB RAM, 8*7.68TB NVME
AHL-32L10V6#15	Hôte générique	Base de référence	32C, 1024GB RAM, 6*15.36TB NVME
AHL-64L10V8#8	Hôte générique	Base de référence	64C, 1024GB RAM, 8*7.68TB NVME
AHL-64L10V6#15	Hôte générique	Base de référence	64C, 1024GB RAM, 6*15.36TB NVME
AHL-64L20V8#8	Hôte générique	Base de référence	64C, 2048GB RAM, 8*7.68TB NVME
AHL-64L20V6#15	Hôte générique	Base de référence	64C, 2048GB RAM, 6*15.36TB NVME

Remarque : Les hôtes du cluster sont engagés pour toute la durée du contrat. Chaque cluster MPC Core doit utiliser des hôtes du même type. Les limites de la plateforme MPC Core sont définies au niveau de la solution VCF.

Dimensionnement de la grappe

Le dimensionnement d'une grappe doit être basé sur la capacité de calcul et la disponibilité requises. Une grappe se compose d'une capacité consommable nette en nombre d'hôtes (N) et comprend une capacité de réserve pour la disponibilité, la récupération et la maintenance. La capacité de réserve requise dépend de la taille de la grappe.

• La taille minimale d'un cluster est de 7 hôtes (N+1).
• Les clusters de plus de 15 hôtes nécessitent un deuxième hôte de secours (N+2).

Taille des grappes et capacité nette

La capacité des serveurs de réserve est réservée pour garantir la disponibilité. Les nœuds de réserve ne peuvent pas être utilisés tant que tous les nœuds actifs restent opérationnels, et la capacité qu'ils fournissent n'est pas incluse dans la capacité disponible calculée. L'aperçu ci-dessous décrit des exemples de tailles de clusters, y compris les tailles minimales et maximales, et la capacité nette utilisable associée, exprimée en cœurs de CPU et en gigaoctets de RAM. Les frais généraux spécifiés par le fournisseur doivent être soustraits de la capacité du premier cluster. Le dimensionnement conseillé est basé sur les recommandations du fournisseur :

• Calcul

  • N = N+1
  • Frais généraux pour l'hyperviseur
  • Utilisation maximale de 80 % de l'unité centrale et de la mémoire

• Stockage

  • Frais généraux pour la reconstruction de vSAN et la réserve d'exploitation

Taille du cluster MPC Core	Modèle de serveur d'hyperviseur	# Serveurs de réserve	Capacité utilisable	Capacité conseillée
7 (6+1) minimum	16C, 512 GBRAM	1	42 cœurs de processeur 1350 GBRAM	39 cœurs de processeur 1220 GBRAM
	32C, 512 GBRAM	1	90 cœurs de processeur 1350 GBRAM	77 cœurs de processeur 1220 GBRAM
	32C, 1024 GBRAM	1	90 cœurs de processeur 2850 GBRAM	77 cœurs de processeur 2450 GBRAM
	64C, 1024 GBRAM	1	180 cœurs de processeur 2850 GBRAM	154 cœurs de processeur 2450 GBRAM
	64C, 2048 GBRAM	1	180 cœurs de processeur 5700 GBRAM	154 cœurs de processeur 4910 GBRAM
14 (13+1)	16C, 512 GBRAM	1	182 cœurs de processeur 5850 GBRAM	167 cœurs de processeur 5320 GBRAM
	32C, 512 GBRAM	1	390 cœurs de processeur 5850 GBRAM	333 cœurs de processeur 5320 GBRAM
	32C, 1024 GBRAM	1	390 cœurs de processeur 12350 GBRAM	333 cœurs de processeur 10640 GBRAM
	64C, 1024 GBRAM	1	780 cœurs de processeur 12350 GBRAM	666 cœurs de processeur 10640 GBRAM
	64C, 2048 GBRAM	1	780 cœurs de processeur 24700 GBRAM	666 cœurs de processeur 22930 GBRAM
16 (14+2)	16C, 512 GBRAM	2	196 cœurs de processeur 6300 GBRAM	180 cœurs de processeur 5730 GBRAM
	32C, 512 GBRAM	2	420 cœurs de processeur 6300 GBRAM	359 cœurs de processeur 5730 GBRAM
	32C, 1024 GBRAM	2	420 cœurs de processeur 13300 GBRAM	359 cœurs de processeur 11460 GBRAM
	64C, 1024 GBRAM	2	840 cœurs de processeur 13300 GBRAM	717 cœurs de processeur 11460 GBRAM
	64C, 2048 GBRAM	2	840 cœurs de processeur 26600 GBRAM	717 cœurs de processeur 22930 GBRAM

Remarque : La pile de gestion MPC Core et les frais généraux VCF (hyperviseur, vSAN, NSX) sont déduits de la capacité disponible. Le dimensionnement doit viser un maximum de 80 % d'utilisation pour éviter les limitations de croissance futures.

MPC Core Storage

Dans MPC Core, le stockage est inclus dans l'hôte et basé sur la technologie vSAN. La capacité brute du cluster est à la disposition du client. Les politiques de redondance des données dépendent du nombre d'hôtes dans le cluster. Les frais généraux spécifiés par le fournisseur doivent être déduits de la capacité du cluster. Les clients peuvent sélectionner leur configuration RAID préférée. vSAN est configuré avec le chiffrement au repos et le chiffrement en transit. Les clients doivent s'assurer que l'espace disponible est suffisant pour les opérations de maintenance.

Le tableau suivant répertorie la capacité garantie basée sur six disques dans chaque serveur. La capacité attendue peut être jusqu'à un facteur 1,2 plus élevée, selon les caractéristiques génériques des données de VM, la compressibilité et les données qui ne sont pas chiffrées par le client, selon les moyennes de la plate-forme et les politiques recommandées par le fournisseur.

Serveurs en grappe	Capacité avec taille de disque en TB (3.84)	Capacité avec taille de disque en TB (7.68)	Protection de l'environnement
4	24.6	53.43	RAID-5 (Simple parité / schéma 2+1 / 50% de surcharge RAID)
5	34.09	73.47	RAID-5 (Simple parité / schéma 2+1 / 50% de surcharge RAID)
6	52.29	112.19	RAID-5 (Simple parité / schéma 4+1 / 25% de surcharge RAID)
7	53.06	113.53	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
8	62.55	133.56	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
9	72.03	153.59	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
10	81.51	173.62	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
11	90.99	193.65	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
12	100.47	213.68	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
13	109.95	233.71	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
14	119.43	253.74	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)
15	128.91	273.77	RAID-6 (Double parité / schéma 4+2 / 50% de surcharge RAID)

Licences VMware

MPC Core prend en charge l'utilisation de licences VCF appartenant au client et provenant de Broadcom/VMware ou de licences fournies par Equinix. L'utilisation de licences BYOL (Bring-Your-Own-License) est soumise aux exigences de conformité de Broadcom. Pour utiliser des licences BYOL pour une instance MPC Core, les licences doivent être partagées avec Equinix et incluses dans le rapport d'Equinix à Broadcom.

MPC Core Connectivity

Pour intégrer MPC Core dans les architectures (multi) cloud des clients, il peut être connecté à différentes options de connectivité. Deux aspects doivent être pris en compte pour déterminer comment MPC Core se connecte aux ressources externes :

• Le type de connectivité (couche 2 ou couche 3)
• Le routage (fourni par Equinix ou par le client)

La connectivité externe du MPC Core prend en charge les éléments suivants :

1. Couche 3 basée sur BGP a. Acheminement Equinix à l'aide d'Equinix Fabric™, d'Equinix Cloud Router™ ou d'Equinix Network Edge™ b. Acheminement fourni par le client à l'aide de Cross Connect™, Metro Connect™ ou Infrastructure Port™.

2. Couche 2 via Infrastructure Port™, Cross-Connect™, ou Metro-Connect™ a. Non redondant, utilisant une seule connexion b. Redondant, utilisant des connexions doubles basées sur LACP et ne passant pas par la Fabric

Les connexions de couche 2 et de couche 3 sont toutes deux prises en charge au sein d'une même implémentation MPC Core.

Produit	Couche 3	Couche 2	Redondance de couche 2 avec LACP
Fabric	X	X	-
Network Edge	X	X	-
Routeur en nuage	X	X	-
Cross Connect	X	X	X
Metro Connect	X	X	X

• Connectivité Routed - Dans cette variante, la solution réseau NSX incluse dans la suite VCF est utilisée comme fonction de routage et de réseau virtuel. Deux appliances NSX Edge, déployées dans la taille Large, sont installées par Equinix dans le pool de ressources du client et configurées avec le BGP fourni par le client. Toute la connectivité de couche 3 se termine au niveau du routeur NSX Edge. L'Edge est connecté à l'aide de deux VLAN pour la connectivité externe. Les connexions de couche 2 sont terminées dans un groupe de ports dans vCenter. La connectivité étant acheminée, les fonctions réseau disponibles sont limitées à un pare-feu sans état.

  Lorsqu'un pare-feu dynamique ou un pare-feu distribué est nécessaire, des options de service supplémentaires peuvent être commandées, notamment Gateway Firewall et Distributed Firewall.

• Connectivité Client Routed - Dans cette variante, le client fournit une appliance de routage sous licence. Les composants NSX sont toujours installés selon les besoins du déploiement VCF. Toutes les connexions externes acheminées sont terminées par l'appliance de routage fournie par le client. L'appliance se connecte en utilisant deux VLAN pour la connectivité externe. Les connexions de couche 2 sont terminées dans un groupe de ports dans vCenter.

  Avec le routage fourni par le client, le pare-feu distribué peut être utilisé en tant que fonction optionnelle, sous licence par le biais de l'option de service.

• Adressage IP et VLANs - Equinix utilise des plages d'adresses IP et des VLAN par défaut pour l'instance MPC Core. Les clients peuvent fournir leurs propres adresses IP et VLAN. En cas de conflit, Equinix attribuera une autre plage en concertation avec le client.

  Le service est configuré en utilisant IPv4. Les clients peuvent utiliser IPv4 et IPv6 pour leurs charges de travail si elles sont prises en charge par la solution VMware VCF.

Fonctions de mise en réseau NSX

VCF et NSX fournissent un catalogue de fonctions de mise en réseau. Certaines fonctions sont incluses dans la licence VCF, tandis que d'autres nécessitent une licence supplémentaire par cœur.

Type	Description	Cluster Edge requis	Licence supplémentaire
Bord	Fonctions de base du réseau	Oui	Non
Passerelle pare-feu	Pare-feu dynamique	Oui	Oui
Pare-feu distribué	Protection est-ouest	Non	Oui

Pour utiliser les fonctions de mise en réseau NSX, l'option connectivité routée doit être sélectionnée. Avec cette configuration, les fonctions NSX deviennent disponibles pour le client. Les arêtes sont déployées dans le cluster client et consomment des ressources à partir de ce cluster. Le type Edge détermine les fonctionnalités et les performances disponibles.

Type de Edge	Taille	Cas d'utilisation
Edge Medium	Deux Edge en HA avec 4 vCPU, 16 GB RAM, 300 GB de stockage chacun	- Caractéristiques L2–L4 - Bande passante attendue jusqu'à 2 Gbps - Pare-feu L3–L4 - NAT Routage
Edge Large	Deux Edge en HA avec 8 vCPU, 16 GB RAM, 300 GB de stockage chacun	- Caractéristiques L2–L4 - Bande passante prévue jusqu'à 10 Gbps - Pare-feu L3–L4 - NAT Routage - Bridging VPN - Inspection TLS
Edge X-Large	Deux Edge en HA avec 16 vCPU, 32 GB RAM, 300 GB de stockage chacun	- Caractéristiques L2–L7 - Pare-feu L3–L4 - NAT Routage - Bridging VPN - Inspection TLS - Profil d'accès L7 (filtrage d'URL) - IDS / IPS - Prévention des logiciels malveillants

Le pare-feu Gateway Firewall est un pare-feu de couche 2-7 défini par logiciel, conçu pour sécuriser les charges de travail virtualisées dans un nuage privé. Il prend en charge le pare-feu dynamique avec des capacités de prévention des menaces. La protection avancée contre les menaces (ATP) combine plusieurs technologies de détection, notamment la détection et la prévention des intrusions (IDS/IPS), le sandboxing réseau et l'analyse du trafic réseau (NTA), ainsi que des moteurs d'agrégation, de corrélation et de contexte issus de la détection et de la réponse réseau (NDR). Cette fonction nécessite des licences supplémentaires qui peuvent être commandées via l'option de service Gateway Firewall. Le nombre de licences nécessaires dépend de la taille de l'Edge.

Type	Nombre de licences
Edge Medium	24
Edge Large	48
Edge X-Large	96

Le pare-feu distribué fournit un pare-feu de couche 2 à 7 défini par logiciel conçu pour sécuriser les charges de travail virtualisées, les conteneurs et les serveurs sans système d’exploitation dans un cloud privé. Il peut être appliqué à chaque charge de travail pour segmenter le trafic est‑ouest et empêcher le mouvement latéral des menaces. Pour utiliser le pare-feu distribué, l'option de service pare-feu distribué (DFW) doit être sélectionnée. Le nombre de licences requises dépend de la taille du cluster en cœurs, et chaque cœur doit être sous licence.

Accès à MPC Core

MPC Core fournit plusieurs interfaces utilisateur pour les opérations :

• Opérations VCF
• Opérations VCF pour les journaux
• NSX
• vCenter
• VCF Operations HCX (disponible uniquement pendant la migration)

Pour la gestion des identités et des accès, MPC Core comprend un courtier en identité qui doit être connecté à l'Active Directory du client via un protocole LDAP sécurisé. Les utilisateurs et les groupes de l'Active Directory du client sont utilisés pour attribuer des autorisations au sein de MPC Core. Les groupes définis par le client sont associés à des rôles prédéfinis dans le cadre du processus d'exécution. Les modifications du modèle de permission peuvent être demandées par le biais d'une demande de service.

Permissions

MPC Core distingue trois types de permission :

Nom	Description
Restreint	Seul Equinix a accès et détermine la configuration requise pour la disponibilité du service.
Limité	Seul Equinix y a accès, mais le client peut demander des modifications de paramètres par le biais d'une demande de service.
Gratuit	Les fonctions sont accessibles au client via les consoles.

Intégration d'applications

Pour certaines applications ou intégrations, l'accès à l'environnement de gestion est nécessaire. Les cas d'utilisation les plus courants sont les suivants

• Intégration pour la sauvegarde (Veeam, CommVault, Rubrik)
• Intégration pour les outils DR (Zerto, Veeam Replication)
• Intégration de solutions VDI (Omnissa, Citrix)
• Intégration pour l'automatisation CI/CD et Infrastructure as Code (Terraform, Ansible)

Pour les intégrations d'applications, les comptes de service de l'Active Directory du client sont affectés à des rôles prédéfinis dans MPC Core.

Extension du service

L'extension du service MPC Core peut se faire de plusieurs manières :

• Ajout de serveurs identiques aux clusters existants
• Extension du nombre de clusters dans l'instance, jusqu'à un maximum de 5 clusters par installation
• Démarrage d'une nouvelle instance VCF

Lorsqu'un cluster de calcul nécessite une forte séparation des ressources, une deuxième instance peut être créée au sein de la même flotte. L'instance VCF supplémentaire comprend sa propre pile de gestion.

Options de service

MPC Core comprend plusieurs options de service qui sont commandées séparément.

Sauvegarde et restauration

La sauvegarde et la restauration des ressources MPC sont assurées par le service Managed Solutions (commandé séparément). Ce service comprend la sauvegarde des données des machines virtuelles ou des données d'application à l'aide d'une plateforme de sauvegarde partagée.

Licences de logiciels

Un catalogue des ISO de logiciels sans licence pour MPC est disponible. Ce catalogue répertorie les logiciels qui peuvent être utilisés dans les machines virtuelles exécutées dans un déploiement MPC Core. Les logiciels sous licence peuvent être achetés via le produit licence logicielle. Après approvisionnement, les ISO sont disponibles dans le catalogue.

Les clients peuvent également apporter leurs propres licences logicielles. Lorsque vous utilisez Bring Your Own License (BYOL), la conformité avec les termes de la licence du fournisseur du logiciel doit être validée.

Pour toutes les licences, le client est responsable du respect des exigences de conformité du fournisseur du logiciel.

Plan de soutien

Le plan d'assistance fournit des services supplémentaires, notamment des demandes de service, une assistance améliorée, des rapports et une assistance à la conception.

• Le plan d'assistance Managed Solutions premier est un programme prépayé offrant des blocs d'heures d'assistance mensuels ou annuels (paiement unique) à un tarif réduit.
• Le temps de support est calculé par incréments de 15 minutes.
• Sans plan prépayé, le support est facturé à l'heure au tarif standard du service premier support, calculé par tranches de 15 minutes.

Unité d'achat	Type	Type d'accusation	unité de mesure	Commande et facturation
Plan d'assistance technique	Mensuel	Base de référence	heure	Réservation mensuelle d'heures pour l'assistance technique
Plan d'assistance technique	Annuel	Base de référence	heure	Réservation annuelle d'heures pour l'assistance technique

Le plan d'assistance s'applique à tous les produits Managed Solutions, et non à un produit spécifique.

Si toutes les heures du plan sont consommées, les heures supplémentaires sont facturées au tarif horaire du premier support Service (tarif horaire standard).

Les heures mensuelles ou prépayées du plan d'assistance Managed Solutions premier ne sont pas transférées et sont perdues si elles ne sont pas utilisées. L’utilisation du plan de support premier Managed Solutions prépayé au-delà du montant alloué préacheté est facturée aux tarifs réguliers du « service de support premier », sauf si une mise à niveau est demandée.

Le plan est spécifique au pays et ne peut pas être lié à un centre de données IBX spécifique.

Aide à la migration

Pour migrer les charges de travail vers MPC Core à partir d'environnements sur site, d'autres installations de colocation ou de plates-formes VMware basées sur le cloud public (comme AWS ou OCVS), Equinix fournit un outil de migration qui permet de migrer les charges de travail en libre-service sans avoir à remanier les applications. Cet outil prend en charge les charges de travail exécutées sur vSphere, Hyper-V et d'autres plateformes de virtualisation en utilisant plusieurs méthodes de migration, y compris la migration du système d'exploitation au niveau de l'hyperviseur et à l'intérieur de l'hôte.

Pour permettre la migration des charges de travail vSphere, le client reçoit une appliance VCF Operations HCX qui est installée dans l'environnement du client et associée à l'environnement MPC Core lors de la configuration. L'outil prend en charge la réplication asynchrone.

• vMotion Migration - Cette méthode utilise le protocole VMware vMotion pour déplacer une machine virtuelle vers un site distant.

  • Conçu pour déplacer une seule machine virtuelle à la fois
  • Migration de l'état de la machine virtuelle sans interruption de service
  • Nécessite une capacité de débit de 250 Mbps ou plus
  • Latence < 150 ms
  • MTU minimum : 1150
  • Maximum de VM par opération : 1

• Cold Migration - Cette méthode utilise le protocole VMware NFC et est automatiquement utilisée lorsque la machine virtuelle source est mise hors tension.

  • Nécessite une capacité de débit de 250 Mbps ou plus
  • Latence < 150 ms
  • MTU minimum : 1150
  • Maximum de VM par opération : 1

• Migration en bloc - Cette méthode utilise la réplication VMware vSphere pour déplacer les machines virtuelles vers le site de destination.

  • Conçu pour déplacer plusieurs machines virtuelles en parallèle
  • Peut être programmé pour se terminer à une heure prédéfinie
  • La machine virtuelle fonctionne à la source jusqu'à ce que le basculement commence (interruption de service similaire à un redémarrage).
  • Nécessite une capacité de débit de 50 Mbps ou plus
  • Latence < 150 ms
  • MTU minimum : 1150
  • Prend en charge jusqu'à 1 000 migrations simultanées (en fonction de la taille de l'appliance HCX Manager).

• Replication Assisted vMotion (RAV) - Replication Assisted vMotion combine les avantages de Bulk Migration (opérations parallèles, résilience, planification) avec vMotion (migration d'état sans temps d'arrêt).

  • Nécessite une capacité de débit de 250 Mbps ou plus
  • Latence < 150 ms
  • MTU minimum : 1150
  • Prend en charge jusqu'à 1 000 migrations simultanées (en fonction de la taille de l'appliance HCX Manager).

La migration facile nécessite des circuits Fabric dédiés ou des VLAN dans un Cross-Connect. Une fois la migration terminée, l'outil de migration est retiré.

Démarcation des services

Le tableau suivant montre la délimitation des responsabilités entre le client et Equinix.

Zone	Responsabilité	Détails
Données-Client :	Client	Gouvernance des données et gestion des droits d'accès aux données
Gestion des comptes et des accès	Client	Gestion des comptes utilisateurs, identité MFA/ID, authentification multifactorielle
Protection des données	Client	Antivirus, cryptage des données des clients et des serveurs, cryptage du trafic réseau
Applications	Client	Gestion des applications fonctionnelles et techniques
Base de données	Client	MySQL, Microsoft SQL, Oracle, PostgreSQL
Middleware	Client	Enterprise Service Bus, Tomcat, .NET Framework
Système d’exploitation	Client	Gestion des systèmes d'exploitation Windows et Linux
Virtualisation du calcul	Equinix Managed Solutions	Hyperviseur VMware ESXi, configuration vCenter
Virtualisation réseau	Equinix Managed Solutions	Plateforme VMware NSX, configuration NSX (firewall, edges), connectivité.
Calcul	Equinix Managed Solutions	Ressources informatiques dédiées
Stockage	Equinix Managed Solutions	stockage vSAN, configuration vSAN
Datacenter Connect	Equinix Managed Solutions	Commutateurs redondants
Installations de datacenter	Equinix Managed Solutions	Armoire sécurisée express, alimentation, refroidissement, contrôle d'accès, sécurité physique

Unités d'achat

Le service MPC est facturé mensuellement sur la base des valeurs de référence ou des types de frais de référence avec dépassement.

• Baseline - Le volume spécifique de l'unité de mesure du service tel que défini dans la commande.
• Overage - La quantité de service consommée qui dépasse le volume de base contractuel.

Catalogue des unités d'achat

Le tableau énumère les unités d'achat pour Managed Private Cloud, y compris l'unité de mesure et la méthode de facturation :

Catégorie	Unité d'achat	unité de mesure	Frais d'installation	Méthode de facturation	Dépassement
Service MPC	Connectivité	Chaque	Non	Base de référence	Non
MPC Compute	<Host Type>	Hôte	Oui	Base de référence	Non
Option de service MPC	Pare-feu de passerelle <n> Taille de l'arête	Bord	Non	Base de référence	Non
	Pare-feu distribué <n> Cœurs	Hôte	Non	Base de référence	Non

Rôles et responsabilités

Lors de l'exécution et de la livraison des services, les responsabilités sont partagées entre Equinix et le client. La section suivante donne un aperçu de ces responsabilités.

Provisionnement des locataires

Activités	Equinix	Client
Planifier / exécuter la réunion de lancement du projet	RA	CI
Planifier / exécuter l'intégration des clients	RA	CI
Livraison des hôtes d'un cluster conformément au plan et à l'ordre de conception	CAR	I¹
Livraison de la capacité de stockage conformément à la conception	CAR	I¹
Livraison de la connectivité conformément à la commande	CAR	I¹
Fournir les fonctionnalités réseau convenues conformément à la conception (optionnel)	CAR	C
Configurez des comptes de service pour les applications sélectionnées	CAR	C
Livraison de la console opérationnelle MPC	CAR	I¹
Fourniture de groupes d'utilisateurs en fonction du client	CAR	I¹

Acceptation en service

Une fois les activités d'intégration terminées, des tests confirmeront que le produit a été livré avec succès et qu'il est prêt à être facturé.

Activités	Equinix	Client
Testez l'accès à la documentation MPC sur docs.equinix.com	CI	RA
Testez l'accès aux différentes consoles pour les différents groupes	CI	RA
Confirmez l'accomplissement du PPM sur la base des preuves fournies	CI	RA
Vérifiez la documentation de transfert	CI	RA
Définir le produit comme activé pour les systèmes internes du client	RA	I

Opérationnel

Une fois le service Managed Private Cloud activé, les éléments opérationnels suivants sont traités :

Activités	Equinix	Client
Gestion technique du service (dans son ensemble)	CAR	I*
Patching et LCM des logiciels : VCF Operations, vSphere, NSX, vSAN, HCX	CAR	I*
Surveillance et maintenance de l'infrastructure MPC	RA	I
Maintenez la conformité des applications intégrées dans MPC avec les versions de MPC Core	I*	CAR
Gestion fonctionnelle de l'environnement du client au sein du service (dans son ensemble)	I¹	CAR
Gérer la capacité de calcul et de stockage dans le cluster	I¹	CAR
Créer, importer et gérer des machines virtuelles et des vApps	I¹	CAR
Maintenez l'outillage VM à jour	I¹	CAR
Faire évoluer les VM à la hausse et à la baisse	I¹	RACI
Gérer les instantanés de VM		RACI
Gérer l'accès aux machines virtuelles à l'aide d'une console		RACI
Demander des statistiques de performance		RACI
Créez et remplissez la "bibliothèque" avec les fichiers ISO/OVA du client.		RACI
Séparer ou regrouper des machines virtuelles pour des raisons de disponibilité ou de performance	I¹	CAR
NFV : réseaux L2 virtuels	I¹	CAR
NFV : pare-feu standard	I¹	CAR
NFV : Routage (statique)	I¹	CAR
NFV : Routage (dynamique OSPF / BGP)	I¹	CAR
NFV : NAT	I¹	CAR
NFV : DHCP	I¹	CAR
NFV : équilibrage de la charge	I¹	CAR
NFV : VPN (IPsec, Client)	I¹	CAR
Configurez et gérez les capacités de script et d'automatisation		RACI

Note : RACI est l'abréviation de Responsible, Accountable, Consulted and Informed (responsable, responsable, consulté et informé).

I¹ L'information n'est obligatoire que pour les tâches qui ont un impact sur le fonctionnement de l'environnement de l'utilisateur.
I² L'information n'est obligatoire que pour les tâches qui ont un impact sur le fonctionnement et/ou la gestion du service.

Gestion des incidents

La gestion des incidents fait partie de l'assistance aux services. Tous les incidents sont traités en fonction de leur priorité. La priorité est déterminée après qu'un incident a été signalé et évalué par Equinix en fonction des informations fournies.

Priorité	Impact / Urgence	Description
P1 Haut	Indisponibilité imprévue d'un service ou d'un environnement fourni et géré par Equinix, conformément à la description du service, en raison d'une perturbation. Le client ne peut pas remplir ses obligations envers ses propres utilisateurs. Le client subit un impact direct et démontrable en raison de l'indisponibilité de cette fonctionnalité.	Le service doit être rétabli immédiatement ; les environnements de production sont indisponibles en cas de perturbations à l'échelle de la plateforme.
P2 Moyen	Le service n'offre pas toutes les fonctionnalités, ou fonctionne avec des fonctionnalités partielles ou des performances réduites, ce qui a un impact sur l'utilisateur. Le client subit un impact direct et démontrable en raison de la disponibilité limitée de la fonctionnalité.	Le service doit être réparé le même jour ouvrable ; l'environnement de gestion n'est pas disponible.
P3 Faible	Le service fonctionne avec une disponibilité limitée pour un ou plusieurs utilisateurs, et une solution de contournement est en place.	Le délai de réparation est déterminé en concertation avec le déclarant.

Note: Cette classification ne s'applique pas aux perturbations qui sont, par exemple, causées par des applications spécifiques à l'utilisateur, des actions de l'utilisateur, ou qui dépendent de tiers. Les incidents peuvent être soumis via le portail client sous Managed Solutions. Les incidents P1 doivent être soumis par téléphone.

Demandes de service

Les demandes de service sont utilisées pour signaler des problèmes de service ou pour demander de l'aide pour la mise en œuvre ou les changements de configuration. Les changements de configuration standard peuvent être demandés via le portail libre-service MPC en tant que demande de service. Le support est disponible 24×7×365. Deux types de demandes de service sont disponibles :

• Inclus - Demandes de service qui entrent dans le cadre du service et n'entraînent pas de frais supplémentaires.
• Additional - Demandes de service qui sortent du cadre du service et entraînent des frais supplémentaires.

Nom de la demande	Inclus / Supplémentaire
Créez un nouveau groupe d'autorisations	Inclus
Supprimer un groupe de permissions	Inclus
Ajouter un VLAN à l'instance MPC Core	Inclus
Supprimer un VLAN de MPC Core	Inclus
Créer un cluster Edge	Supplémentaire
Supprimer le cluster Edge	Supplémentaire
Redimensionner le cluster Edge	Supplémentaire

Les modifications non répertoriées ci-dessus peuvent être demandées en sélectionnant modifier dans le module de demande de service. Equinix effectuera une analyse d'impact pour déterminer la faisabilité, le coût et le délai d'exécution. Les frais liés aux demandes de service sont déduits du solde du plan de support premier. Si le solde est insuffisant, les frais sont facturés au taux en vigueur. Les demandes ayant une incidence sur la capacité de base, les quantités commandées ou toute modification ayant une incidence sur les frais de service mensuels doivent être adressées à l'équipe commerciale de Equinix.

Rapports

Dans le cadre du service, le client recevra un rapport mensuel sur les services couvrant les sujets suivants :

• Tickets soulevés mesurés par rapport aux paramètres SLA
• Capacité par OVDC

Niveaux de service

L'accord de niveau de service (SLA) définit les niveaux de performance mesurables applicables au service MPC et précise les recours dont dispose le client si Equinix ne respecte pas ces niveaux. Les crédits de service énumérés ci-dessous constituent le seul et unique recours en cas de non-respect des seuils de niveau de service définis dans la présente section.

Priorité	Temps de réponse¹	Résolution Temps²	Exécution des travaux	SLA³
P1	< 30 min	< 4 heures	24x7	95%
P2	< 60 min	< 24 heures	24x7	95%
P3	< 120 min	< 5 jours	24x7	95%

¹ le temps de réponse est mesuré à partir du moment où un ticket d'incident est soumis jusqu'à ce qu'un spécialiste Equinix Managed Solutions fournisse une réponse formelle. ² le temps de résolution est mesuré de la création du ticket à la fermeture, l'annulation ou le transfert au support IBX. ³ le SLA s'applique au temps de réponse, des détails sur le SLA sont disponibles dans la politique produit .

Le niveau de disponibilité **** pour le service MPC reflète la disponibilité d'un cluster. Le service est considéré comme indisponible lorsque l'infrastructure gérée par Equinix fait entrer le cluster de charge de travail dans un état d'erreur qui perturbe les services aux clients.

DISPONIBILITÉ NIVEAU DE SERVICE	DESCRIPTION
99.95%+	Moins de 22 minutes d'indisponibilité par mois civil

Un régime de crédit de service s'applique à l'ANS de disponibilité tel que défini dans la politique produit. La disponibilité du service MPC n'inclut pas la restauration des données. Les clients sont responsables de la restauration de leurs données. Lorsque Managed Private Backup est sous contrat, les données peuvent être restaurées en libre-service à l'aide de la console opérationnelle de Managed Private Backup. Si Managed Private Backup n'est pas sous contrat, la restauration des données est de la responsabilité du client.