Managed Private Cloud Core

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 certains centres de données du monde entier. Lorsqu'ils sont achetés dans différentes régions (amer, EMEA, APAC), une implémentation indépendante est fournie pour chaque région. Lorsque plusieurs implémentations sont fournies dans la même région, Active Directory et DNS peuvent être partagés entre ces implémentations.

Contenu connexe : 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
DNS	Entrant	Résolution de noms DNS du client vers les serveurs DNS MPC	DNS (TCP, UDP/53), PING
DNS	Sortant	Résolution de noms DNS de MPC vers les serveurs DNS du client	DNS (TCP, UDP/53), PING
NTP	Entrant	Synchronisation de l'heure réseau du client vers les serveurs de temps MPC	NTP (TCP, UDP/123), PING
Opérations VCF	Entrant	Accès client au portail des opérations VCF	HTTP (TCP/80), HTTPS (TCP/443), PING
VCF Identity Broker (courtier en identité)	Entrant	Accès client au portail Identity Broker	HTTPS (TCP/443), ping
VCF Identity Broker (courtier en identité)	Sortant	Accès Identity Broker au LDAP du client	TCP/636, TCP/3269, ping
Opérations VCF pour les journaux	Entrant	Accès client au portail VCF Ops for Logs	HTTPS (TCP/443), ping
vCenter	Entrant	Accès client au portail vCenter	HTTP (TCP/80), HTTPS (TCP/443), PING
Gestionnaire NSX	Entrant	Accès client au portail NSX Manager	HTTPS (TCP/443), ping
HCX Manager	Entrant	Accès client au portail HCX Manager	HTTPS (TCP/443), ping
ESX	Entrant	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=<LDAP Service Account>, OU=<Active Directory OU>, OU=<Active Directory OU>, DC=<Customer AD Name>, DC=<Customer AD TLD> 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 approuvée/intermédiaire ; Linux : magasin de confiance du système selon le cas ; macOS : Trousseau 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ésultat

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.

Gamme 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 d'adresses 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.

Modèles MPC Core

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 également équipé de VCF Operations HCX pour prendre en charge la migration vers la plate-forme 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 fourni par vSAN. Pour la connectivité, un client peut utiliser NSX et/ou installer une appliance de routage auto-gérée. Un client peut également utiliser le service de pare-feu géré, qui est une offre de pare-feu géré par Equinix qui doit être commandée séparément (option pare-feu géré par connectivité).

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
• Proxy VCF Operations Cloud
• 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é à partir d'un datacenter Equinix dans un Secure Cabinet Express dédié. Selon la taille du cluster, un cluster peut couvrir plusieurs armoires. L'armoire et la puissance sont incluses dans le prix de l'hôte. L'armoire et l'accès sont gérés par Equinix et ne sont pas disponibles pour l'équipement du client. Le nombre maximal d'hôtes par armoire dépend de la disponibilité de l'alimentation et du nombre et de la consommation électrique des serveurs.

Infrastructure MPC Core

Pour la gestion de 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 ports Gbps 48 25 pour la connectivité externe et la connectivité serveur. 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, fournissant une bande passante de 400 Gbps.

Cluster MPC Core

• Groupe d'instruments - 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ôte - 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	Ligne de base	16C, 512 GO DE RAM, 4 * 3,84 TO NVME
AHL-16L05V6#4	Hôte générique	Ligne de base	16C, 512 GO DE RAM, 6 * 3,84 TO NVME
AHL-32L05V8#4	Hôte générique	Ligne de base	32C, 512 GO DE RAM, 8 * 3,84 TO NVME
AHL-32L05V6#8	Hôte générique	Ligne de base	32C, 512 GO DE RAM, 6 * 7,68 TO NVME
AHL-32L05V8#8	Hôte générique	Ligne de base	32C, 512 GO DE RAM, 8 * 7,68 TO NVME
AHL-32L05V6#15	Hôte générique	Ligne de base	32C, 512 GO DE RAM, 6 * 3,68 TO NVME
AHL-32L10V8#4	Hôte générique	Ligne de base	32C, 1024 GO DE RAM, 4 * 15.36TO NVME
AHL-32L10V6#8	Hôte générique	Ligne de base	32C, 1024 GO DE RAM, 6 * 7,68 TO NVME
AHL-32L10V8#8	Hôte générique	Ligne de base	32C, 1024 GO DE RAM, 8 * 7,68 TO NVME
AHL-32L10V6#15	Hôte générique	Ligne de base	32C, 1024 GO DE RAM, 6 * 15.36TO NVME
AHL-64L10V8#8	Hôte générique	Ligne de base	64C, 1024 GO DE RAM, 8 * 7,68 TO NVME
AHL-64L10V6#15	Hôte générique	Ligne de base	64C, 1024 GO DE RAM, 6 * 15.36TO NVME
AHL-64L20V8#8	Hôte générique	Ligne de base	64C, 2048 GO DE RAM, 8 * 7,68 TO NVME
AHL-64L20V6#15	Hôte générique	Ligne de base	64C, 2048 GO DE RAM, 6 * 15.36TO NVME

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

Dimensionnement des clusters

Le dimensionnement du cluster doit être basé sur la capacité de traitement et la disponibilité requises. Un cluster se compose de la capacité consommable nette en nombre d'hôtes (N) et inclut la capacité de réserve pour la disponibilité, la restauration et la maintenance. La capacité de réserve requise dépend de la taille du cluster.

• 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 clusters 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 que la capacité qu'ils fournissent n'est pas incluse dans la capacité disponible calculée. La présentation ci-dessous décrit des exemples de tailles de cluster, y compris les tailles minimale et maximale, et la capacité nette utile associée exprimée en cœurs de CPU et en Go de RAM. La surcharge spécifiée par le fournisseur doit être soustraite de la capacité du premier cluster. Le dimensionnement conseillé est basé sur les recommandations du fournisseur :

• Calculer

  • 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 rechange	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 la surcharge VCF (hyperviseur, VSAN, NSX) sont déduites de la capacité disponible. Le dimensionnement doit viser une utilisation maximale de 80 % 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 disponible pour le client. Les règles 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. Le VSAN est configuré avec le chiffrement au repos et le chiffrement en transit. Il incombe aux clients de s'assurer qu'un espace suffisant est disponible 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
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 de Broadcom/VMware ou de licences fournies par Equinix. L'utilisation de BYOL (Bring Your Own License) est soumise aux exigences de conformité de Broadcom. Pour utiliser la licence BYOL pour une instance MPC Core, les licences doivent être partagées avec Equinix et incluses dans les rapports Equinix à Broadcom.

Connectivité MPC Core

Pour intégrer MPC Core dans les architectures cloud (multi) du client, 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. Equinix routé à l'aide de Equinix Fabric™, Equinix Cloud Router™ ou Equinix Network Edge™ b. routage 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, en utilisant des connexions doubles basées sur LACP et non via 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é routée - 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 de périphérie NSX, déployées en grande taille, sont installées par Equinix dans le pool de ressources du client et configurées avec BGP fourni par le client. Toute la connectivité de couche 3 est terminée au niveau du routeur NSX Edge. Le serveur 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. Lorsque la connectivité est routée, les fonctions réseau disponibles sont limitées au 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é acheminée par le client - Dans cette variante, le client fournit un appareil de routage sous licence. Les composants NSX sont toujours installés comme requis par le déploiement VCF. Toutes les connexions externes routées se terminent au niveau de l'appliance de routage fournie par le client. L'appliance se connecte à l'aide de 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 VLAN - Equinix utilise les plages d'adresses IP et les VLAN par défaut pour l'instance principale MPC. Les clients peuvent fournir leurs propres adresses IP et VLAN. En cas de conflit, Equinix attribuera une plage alternative en consultation avec le client.

  Le service est configuré à l'aide d'IPv4. Les clients peuvent utiliser IPv4 et IPv6 pour leurs charges de travail s'ils sont pris en charge par la solution VMware VCF.

Fonctions de mise en réseau NSX

VCF et NSX fournissent un catalogue de fonctions 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
Arête	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 d'arête	Taille	Cas d'utilisation
Arête moyenne	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
Arête 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
Arête 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

Gateway Firewall fournit un pare-feu de couche 2 à 7 défini par logiciel conçu pour sécuriser les charges de travail virtualisées dans un cloud 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 sandbox 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 pare-feu Gateway. Le nombre de licences requises dépend de la taille de l'Edge.

Type	Nombre de licences
Arête moyenne	24
Arête large	48
Arête 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 inclut un courtier d’identités qui doit être connecté à Active Directory du client via LDAP sécurisé. Les utilisateurs et les groupes du client Active Directory sont utilisés pour attribuer des autorisations dans MPC Core. Les groupes définis par le client sont mappés à des rôles prédéfinis dans le cadre du processus d'exécution. Les modifications du modèle d'autorisation peuvent être demandées via 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 requis. Exemples d'utilisation courants :

• Intégration pour la sauvegarde
• Intégration de l'outillage DR
• Intégration pour les solutions VDI
• Intégration pour l'automatisation ci/CD et infrastructure en tant que code

Pour les intégrations d'applications, les comptes de service Active Directory des clients se voient attribuer des rôles prédéfinis dans MPC Core. Ces rôles ne doivent pas accorder des privilèges administratifs complets ou de niveau racine au sein du système de gestion.

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 du même parc. L'instance VCF supplémentaire inclut 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 fournies par le biais du service Managed Private Backup Service (commandé séparément). Le service inclut la sauvegarde des données de VM ou des données d'application à l'aide d'une plate-forme de sauvegarde partagée.

Licences logicielles

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 d'assistance

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 de frais	UNITÉ DE MESURE	Commande et facturation
Plan de support technique	Mensuel	Ligne de base	heure	Réservation mensuelle d'heures pour le support technique
Plan de support technique	Annuel	Ligne de base	heure	Réservation annuelle d'heures de support 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 des charges de travail vers MPC Core à partir d’environnements sur site, d’autres installations Colocation ou de plates-formes VMware basées sur le cloud public (telles que AWS ou OCVS), Equinix fournit un outil de migration qui permet la migration des charges de travail en libre-service sans refactoriser les applications. L'outil prend en charge les charges de travail exécutées sur vSphere, Hyper‑V et d'autres plates-formes de virtualisation en utilisant plusieurs méthodes de migration, y compris la migration au niveau de l'hyperviseur et du système d'exploitation invité.

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

• Migration vMotion : 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
  • Nombre maximal de machines virtuelles par opération : 1

• Migration à froid : 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
  • Nombre maximal de machines virtuelles par opération : 1

• Migration groupée : cette méthode utilise VMware vSphere Replication 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 la migration en masse (opérations parallèles, résilience, planification) avec vMotion (migration 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 supprimé.

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
Bases 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 du réseau	Equinix Managed Solutions	Plateforme VMware NSX, configuration NSX (firewall, edges), connectivité.
Calculer	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.

• Ligne de base - volume spécifique de l'unité de mesure de service telle que définie dans la commande.
• Excédent - quantité de service consommée qui dépasse le volume de référence 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	Excédent
Service MPC	Connectivité	Chacun	Non	Ligne de base	Non
Calcul MPC	<Host Type>	Hôte	Oui	Ligne de base	Non
Option de service MPC	Pare-feu de passerelle <n> Taille de l'arête	Arête	Non	Ligne de base	Non
	Pare-feu distribué <n> Cœurs	Hôte	Non	Ligne de base	Non

Rôles et responsabilités

Lors de l'exécution et de la livraison du service, 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
Planifiez / exécutez la réunion de lancement du projet	RA	CI
Planifier / exécuter l'accueil 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 de mise 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 du logiciel : Opérations VCF, 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 (global).	I¹	CAR
Gérer la capacité de calcul et de stockage dans le cluster	I¹	CAR
Créez, importez et gérez des VM 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 (OSPF / BGP dynamique)	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

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

I¹ informer n'est obligatoire que pour les tâches qui ont un impact sur le fonctionnement de l'environnement utilisateur.
I² L'information n'est requise 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 est incluse dans le support technique. Tous les incidents sont traités en fonction de la 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 interruption. Le client ne peut remplir ses obligations envers ses propres utilisateurs. Le client subit un impact direct 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 Medium	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 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.

Remarque : Cette classification ne s'applique pas aux interruptions 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 clients 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 modifications de configuration. Les modifications de configuration standard peuvent être demandées via le portail libre-service MPC en tant que demande de service. L'assistance 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 qui n'entraînent pas de frais supplémentaires.
• Supplémentaire - 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

Le contrat de niveau de service (SLA) définit les niveaux de performance mesurables applicables au service MPC et spécifie les solutions disponibles pour le client si Equinix ne parvient pas à atteindre ces niveaux. Les pénalités de service énumérées ci-dessous constituent le seul et unique recours en cas de non-respect des seuils de niveau de service définis dans cette 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é du 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 passer le cluster de charges de travail dans un état d'erreur qui interrompt les services client.

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 au SLA de disponibilité tel que défini dans la politique de 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 via le libre-service à l'aide de la console opérationnelle Managed Private Backup. Si Managed Private Backup n'est pas sous contrat, la restauration des données relève de la responsabilité du client.