Noyau de cloud 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 certains centres de données à travers le monde. Lorsqu'il est acquis dans différentes régions (Amérique, EMEA, APAC), une implémentation indépendante est fournie pour chaque région. Si plusieurs implémentations sont fournies au sein d'une même région, Active Directory et DNS peuvent être partagés entre elles.

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
Courtier d'identité VCF	Authentification centralisée
Opérations VCF pour les journaux	Journalisation de la plate-forme VCF
vCenter	Gestion des machines virtuelles
Gestionnaire NSX	réseau défini 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	Inbound	Résolution de noms DNS du client vers les serveurs DNS MPC	DNS (TCP, UDP/53), PING
DNS	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
Courtier d'identité VCF	Inbound	Accès client au portail Identity Broker	HTTPS (TCP/443), ping
Courtier d'identité VCF	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	Requis	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	Requis	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	Requis	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ètre	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.

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 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.

Plans directeurs du noyau MPC

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 faciliter la migration vers la plateforme MPC Core. Il est contrôlé par Equinix. Le bassin de ressources contient les ressources du client, et la capacité disponible dépend des composants de gestion installés, du nombre d'hôtes dans la grappe et du type d'hôte.

Le stockage est assuré par vSAN. Pour la connectivité, le client peut utiliser NSX et/ou installer un routeur autogéré. Il peut également recourir au service de pare-feu géré, une offre de pare-feu Equinix à commander 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.

Le logiciel installé inclus dans la flotte MPC Core VCF sur un seul site est:

• Programme d'installation VCF
• Gestion de parc VCF
• Opérations VCF
• Proxy cloud des opérations VCF
• vCenter
• Gestionnaires NSX
• NSX Edges
• Opérations VCF pour les journaux
• Courtier d'identité VCF
• Opérations VCF HCX
• Infrastructure de gestion de base (Services de domaine Active Directory, DNS, Autorité de certification, Surveillance NTP, Serveur de rebond)

Armoire MPC Core

MPC Core est déployé à partir d'un centre de données Equinix dans une armoire Secure Cabinet Express dédiée. Selon sa taille, une grappe peut s'étendre sur plusieurs armoires. L'armoire et l'alimentation électrique sont comprises dans le prix de l'hôte. L'armoire et l'accès sont gérés par Equinix et ne sont pas accessibles à l'équipement du client. Le nombre maximal d'hôtes par armoire dépend de la disponibilité de l'alimentation électrique, ainsi que du nombre et de la consommation électrique des serveurs.

Infrastructure de base MPC

Pour la gestion du cœur MPC, la première baie est équipée de pare-feu de gestion, de capacités de gestion hors bande (OOB) et de commutateurs de gestion. Chaque baie comprend deux commutateurs redondants dotés de 2 ports 48 Gbit/s (2 × 25 Gbit/s) pour la connectivité externe et la connectivité serveur. Chaque serveur utilise deux ports de chaque commutateur pour assurer la redondance. Les commutateurs sont gérés par Equinix. Lorsque deux baies sont déployées, les commutateurs sont interconnectés de manière redondante, offrant une bande passante de 400 Gbit/s.

Cluster central MPC

• Regrouper - Un environnement MPC Core comprend une configuration de grappe d'au moins sept hôtes, dont six sont disponibles pour l'utilisation et un est réservé à la maintenance et à la haute disponibilité (principe N + 1).
• Hôte - MPC Core offre un catalogue de types d'hôtes basé sur le processeur, le nombre de cœurs, la mémoire vive 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	16 cœurs, 512 Go de RAM, 4 disques NVMe de 3,84 To
AHL-16L05V6#4	Hôte générique	Base de référence	16 cœurs, 512 Go de RAM, 6 disques NVMe de 3,84 To
AHL-32L05V8#4	Hôte générique	Base de référence	32 cœurs, 512 Go de RAM, 8 disques NVMe de 3,84 To
AHL-32L05V6#8	Hôte générique	Base de référence	32 cœurs, 512 Go de RAM, 6 disques NVMe de 7,68 To
AHL-32L05V8#8	Hôte générique	Base de référence	32 cœurs, 512 Go de RAM, 8 disques NVMe de 7,68 To
AHL-32L05V6#15	Hôte générique	Base de référence	32 cœurs, 512 Go de RAM, 6 disques NVMe de 3,68 To
AHL-32L10V8#4	Hôte générique	Base de référence	32 cœurs, 1024 Go de RAM, 4 disques NVMe de 15,36 To
AHL-32L10V6#8	Hôte générique	Base de référence	32 cœurs, 1024 Go de RAM, 6 disques NVMe de 7,68 To
AHL-32L10V8#8	Hôte générique	Base de référence	32 cœurs, 1024 Go de RAM, 8 disques NVMe de 7,68 To
AHL-32L10V6#15	Hôte générique	Base de référence	32 cœurs, 1024 Go de RAM, 6 disques NVMe de 15,36 To
AHL-64L10V8#8	Hôte générique	Base de référence	64 cœurs, 1024 Go de RAM, 8 disques NVMe de 7,68 To
AHL-64L10V6#15	Hôte générique	Base de référence	64 cœurs, 1024 Go de RAM, 6 disques NVMe de 15,36 To
AHL-64L20V8#8	Hôte générique	Base de référence	64 cœurs, 2048 Go de RAM, 8 disques NVMe de 7,68 To
AHL-64L20V6#15	Hôte générique	Base de référence	64 cœurs, 2048 Go de RAM, 6 disques NVMe de 15,36 To

Remarque: Les hôtes du groupe sont réservés pour toute la durée du contrat. Chaque grappe 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 des grappes

Le dimensionnement d'une grappe doit être basé sur la capacité de calcul requise et la disponibilité. Une grappe comprend une capacité nette utilisable, exprimée en nombre d'hôtes (N), et comprend une capacité de réserve pour la disponibilité, la récupération et la maintenance. Cette capacité de réserve dépend de la taille du cluster.

• La taille minimale du groupe est de 7 hôtes (N+1).
• Les grappes de plus de 15 hôtes nécessitent un deuxième hôte de rechange (N+2).

Taille des grappes et capacité nette

Une capacité de serveurs de secours est réservée pour assurer la disponibilité. Les nœuds de secours ne peuvent pas être utilisés tant que tous les nœuds actifs restent opérationnels, et leur capacité n'est pas prise en compte dans le calcul de la capacité disponible. Le tableau ci-dessous présente des exemples de tailles de grappes, incluant les tailles minimales et maximales, ainsi que la capacité nette utilisable associée, exprimée en cœurs de processeur et en Go 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.

• Calculer

  • N = N+1
  • Surcharge pour l'hyperviseur
  • Utilisation moyenne maximale de 80 % du processeur et de la mémoire

• Rangement

  • Frais généraux liés à la reconstruction et aux opérations de vSAN

Taille de la grappe principale MPC	Modèle de serveur hyperviseur	# Serveurs de rechange	Capacité utile	Capacité recommandée
7 (6+1) minimum	16 cœurs, 512 Go de RAM	1	42 cœurs de processeur 1350 GBRAM	39 cœurs de processeur 1220 GBRAM
	32 cœurs, 512 Go de RAM	1	90 cœurs de processeur 1350 GBRAM	77 cœurs de processeur 1220 GBRAM
	32 cœurs, 1024 Go de RAM	1	90 cœurs de processeur 2850 GBRAM	77 cœurs de processeur 2450 GBRAM
	64 °C, 1024 Go de RAM	1	180 cœurs de processeur 2850 GBRAM	154 cœurs de processeur 2450 GBRAM
	64 cœurs, 2048 Go de RAM	1	180 cœurs de processeur 5700 GBRAM	154 cœurs de processeur 4910 GBRAM
14 (13+1)	16 cœurs, 512 Go de RAM	1	182 cœurs de processeur 5850 GBRAM	167 cœurs de processeur 5320 GBRAM
	32 cœurs, 512 Go de RAM	1	390 cœurs de processeur 5850 GBRAM	333 cœurs de processeur 5320 GBRAM
	32 cœurs, 1024 Go de RAM	1	390 cœurs de processeur 12350 GBRAM	333 cœurs de processeur 10640 GBRAM
	64 °C, 1024 Go de RAM	1	780 cœurs de processeur 12350 GBRAM	666 cœurs de processeur 10640 GBRAM
	64 cœurs, 2048 Go de RAM	1	780 cœurs de processeur 24700 GBRAM	666 cœurs de processeur 22930 GBRAM
16 (14+2)	16 cœurs, 512 Go de RAM	2	196 cœurs de processeur 6300 GBRAM	180 cœurs de processeur 5730 GBRAM
	32 cœurs, 512 Go de RAM	2	420 cœurs de processeur 6300 GBRAM	359 cœurs de processeur 5730 GBRAM
	32 cœurs, 1024 Go de RAM	2	420 cœurs de processeur 13300 GBRAM	359 cœurs de processeur 11460 GBRAM
	64 °C, 1024 Go de RAM	2	840 cœurs de processeur 13300 GBRAM	717 cœurs de processeur 11460 GBRAM
	64 cœurs, 2048 Go de RAM	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 devrait viser un taux d'utilisation maximal de 80 % afin d'éviter les limites de croissance futures.

Stockage du noyau MPC

Dans MPC Core, le stockage est intégré à l'hôte et repose sur la technologie vSAN. La capacité brute de la grappe est mise à 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 choisir la configuration RAID qui leur convient. vSAN est configuré avec le chiffrement des données au repos et en transit. Il incombe aux clients de s'assurer qu'ils ont suffisamment d'espace 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 du groupe	Capacité avec la taille du disque en To (3,84)	Capacité avec la taille du disque en To (7,68)	Protection de l'environnement
4	24.6	53.43	RAID-5 (Parité simple / Schéma 2+1 / Surcharge RAID de 50 %)
5	34.09	73.47	RAID-5 (Parité simple / Schéma 2+1 / Surcharge RAID de 50 %)
6	52.29	112.19	RAID-5 (Parité simple / Schéma 4+1 / Surcharge RAID de 25 %)
7	53.06	113.53	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
8	62.55	133.56	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
9	72.03	153.59	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
10	81.51	173.62	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
11	90.99	193.65	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
12	100.47	213.68	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
13	109.95	233.71	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
14	119.43	253.74	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)
15	128.91	273.77	RAID-6 (parité double / Schéma 4+2 / Surcharge RAID de 50 %)

Licences VMware

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

Connectivité du noyau MPC

Pour intégrer MPC Core aux architectures infonuagiques (multi) des clients, différentes options de connectivité sont possibles. 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 de MPC Core prend en charge ce qui suit:

1. Couche 3 basée sur BGP a. Equinix routé à l'aide d'Equinix Fabric™, d'Equinix Cloud Router™ ou d'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, 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 seule 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é routinière - Dans cette configuration, la solution réseau NSX incluse dans la suite VCF assure le routage et la virtualisation du réseau. Deux appareils NSX Edge, déployés en configuration Large, sont installés par Equinix dans le pool de ressources du client et configurées avec le protocole BGP fourni par ce dernier. Toute la connectivité de couche 3 est terminée au niveau du routeur NSX Edge. Ce dernier est connecté par deux VLAN pour la connectivité externe. Les connexions de la couche 2 sont terminées dans un groupe de ports de vCenter. Une fois la connectivité acheminée, les fonctions réseau disponibles se limitent au pare-feu sans état.

  Lorsque le pare-feu dynamique ou le pare-feu distribué est requis, des options de service supplémentaires peuvent être commandées, notamment le pare-feu de passerelle et le pare-feu distribué.

• Connectivité client acheminée - Dans cette configuration, le client fournit un routeur sous licence. Les composants NSX sont installés conformément aux exigences du déploiement VCF. Toutes les connexions externes acheminées sont terminées au niveau du routeur fourni par le client. Ce dernier se connecte par deux VLAN pour la connectivité externe. Les connexions de la couche 2 sont terminées dans un groupe de ports de vCenter.

  Avec le routage fourni par le client, le pare-feu distribué peut être utilisé comme une fonctionnalité optionnelle, sous licence via l'option de service.

• Adressage IP et VLAN - 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 plage alternative en consultation avec le client.

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

Fonctions réseau NSX

VCF et NSX offrent 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	Baccalauréat supplémentaire
Bordure	fonctions de base du réseau	Oui	Non
Pare-feu Gateway	Pare-feu avec état	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 bord	Taille	Cas d'utilisation
Moyenne	Deux périphériques en haute disponibilité avec 4 vCPU, 16 Go de RAM et 300 Go de stockage chacun.	- Caractéristiques L2–L4 - Bande passante attendue jusqu'à 2 Gbps - Pare-feu L3–L4 - NAT  routes
Bordure Large	Deux serveurs Edge en haute disponibilité, chacun doté de 8 vCPU, 16 Go de RAM et 300 Go de stockage.	- Caractéristiques L2–L4 - Bande passante prévue jusqu'à 10 Gbps - Pare-feu L3–L4 - NAT  routes - Bridging RPV - Inspection TLS
Edge XL	Deux serveurs Edge en haute disponibilité, chacun doté de 16 vCPU, 32 Go de RAM et 300 Go de stockage.	- Caractéristiques L2–L7 - Pare-feu L3–L4 - NAT  routes - Bridging RPV - Inspection TLS - Profil d'accès L7 (filtrage d'URL) - IDS / IPS - Prévention des logiciels malveillants

Le pare-feu passerelle est un pare-feu logiciel de couche 2 à 7 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 fonctionnalité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 requiert des licences supplémentaires, disponibles via l'option de service Pare-feu de passerelle. Le nombre de licences nécessaires dépend de la taille du réseau Edge.

Type	Nombre de permis
Moyenne	24
Bordure Large	48
Edge XL	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 au noyau MPC

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

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

Pour la gestion des identités et des accès, MPC Core intègre un courtier d'identité qui doit être connecté à l'Active Directory du client via LDAP sécurisé. Les utilisateurs et les groupes de l'Active Directory du client servent à attribuer les autorisations au sein de MPC Core. Les groupes définis par le client sont associés à des rôles prédéfinis durant le processus de déploiement. Tout changement au modèle d'autorisations peut faire l'objet d'une demande de service.

Permissions

MPC Core distingue trois types d'autorisation:

Nom	Description
Limité	Seul Equinix y 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 via 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. Voici quelques cas d'utilisation courants:

• Intégration pour la sauvegarde (Veeam, CommVault, Rubrik)
• Intégration des outils de reprise après sinistre (Zerto, Veeam Replication)
• Intégration pour les solutions VDI (Omnissa, Citrix)
• Intégration pour l'automatisation CI/CD et l'infrastructure en tant que 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 être réalisée de plusieurs façons:

• Ajouter plus de serveurs identiques aux grappes existantes
• Extension du nombre de grappes dans l'instance, jusqu'à un maximum de 5 grappes par installation
• Démarrage d'une nouvelle instance VCF

Lorsqu'une grappe de calcul nécessite une séparation importante des ressources, une deuxième instance peut être créée au sein du même parc. Cette instance VCF supplémentaire a sa propre infrastructure 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 de sauvegarde privée gérée (à commander séparément). Ce service inclut la sauvegarde des données des machines virtuelles ou des applications sur 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, il incombe au client de se conformer aux exigences de conformité du fournisseur de logiciels.

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 de soutien technique	Mensuellement	Base de référence	heure	Réservation mensuelle d'heures pour l'assistance technique
Plan de soutien 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 depuis des environnements sur place, d'autres centres de colocation ou des plateformes VMware basées sur le cloud public (telles qu'AWS ou OCVS), Equinix fournit des outils de migration permettant une migration en libre-service sans refactorisation des applications. Ces outils prennent en charge les charges de travail exécutées sur vSphere, Hyper-V et d'autres plateformes de virtualisation grâce à plusieurs méthodes de migration, notamment la migration au niveau de l'hyperviseur et au sein du système d'exploitation invité.

Pour permettre la migration des charges de travail vSphere, le client reçoit un dispositif VCF Operations HCX installé dans son environnement et associé à l'environnement MPC Core lors de la configuration. Cet outil 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
  • Migre l'état de la machine virtuelle sans interruption de service.
  • Nécessite une capacité de débit de 250 Mbit/s 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 NFC de VMware et est automatiquement activée lorsque la machine virtuelle source est mise hors tension.

  • Nécessite une capacité de débit de 250 Mbit/s ou plus.
  • Latence < 150 ms
  • MTU minimum: 1150
  • Nombre maximal de machines virtuelles par opération: 1

• Migration en masse - 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éétablie
  • La machine virtuelle continue de fonctionner à la source jusqu'au basculement (interruption de service semblable à un redémarrage).
  • Nécessite une capacité de débit de 50 Mbit/s ou plus.
  • Latence < 150 ms
  • MTU minimum: 1150
  • Prend en charge jusqu'à 1000 migrations simultanées (selon la taille de l'appareil HCX Manager)

• Replication assistée par vMotion (RAV) - Replication assistée par vMotion combine les avantages de la migration massive (opérations parallèles, résilience, planification) avec vMotion (migration d'état sans interruption de service).

  • Nécessite une capacité de débit de 250 Mbit/s ou plus.
  • Latence < 150 ms
  • MTU minimum: 1150
  • Prend en charge jusqu'à 1000 migrations simultanées (selon la taille de l'appareil HCX Manager)

Une migration simplifiée nécessite des circuits Fabric dédiés ou des VLAN dans un Cross Connect. Une fois la migration terminée, les outils de migration sont supprimés.

Délimitation des services

Le tableau ci-dessous illustre la répartition des responsabilités entre le client et Equinix.

Zone	Responsabilité	Détails
Données du 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, authentification multifactorielle (MFA/ID), authentification multifacteurs
Protection des données	Client	Antivirus, chiffrement des données client et serveur, chiffrement du trafic réseau
Application	Client	Gestion fonctionnelle et technique des applications
Base de données	Client	MySQL, Microsoft SQL, Oracle, PostgreSQL
Middleware	Client	Autobus de services aux entreprises, 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 (pare-feu, périphériques périphériques), connectivité
Calculer	Equinix Managed Solutions	Ressources informatiques dédiées
Rangement	Equinix Managed Solutions	stockage vSAN, configuration vSAN
Datacenter Connect	Equinix Managed Solutions	Interrupteurs redondants
Installations de datacenter	Equinix Managed Solutions	Armoire express sécurisée, alimentation électrique, refroidissement, contrôle d'accès, sécurité physique

Unités d'achat

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

• Référence - Le volume spécifique de l'unité de mesure de service tel que défini dans la commande.
• Dépassement - La quantité de service consommée qui excède le volume de base contractuel.

Catalogue des unités d'achat

Le tableau énumère les unités d'achat pour le nuage privé géré, y compris l'unité de mesure et le mode 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
Calcul MPC	<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	Bordure	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 la mise en œuvre et de la prestation de services, les responsabilités sont partagées entre Equinix et le client. La section suivante présente un aperçu de ces responsabilités.

Provisionnement des locataires

Activités	Equinix	Client
Planifier ou exécuter la réunion de lancement du projet	RA	CI
Planifier et exécuter l'intégration des clients	RA	CI
Livraison des hôtes d'une grappe conformément au plan de conception et à l'ordre de livraison	CAR	Moi
Livraison de la capacité d'entreposage conformément aux spécifications	CAR	Moi
Fourniture de la connectivité conformément à la commande	CAR	Moi
Fournir les fonctionnalités réseau convenues conformément à la conception (optionnel)	CAR	C
Configurer les comptes de service pour les applications sélectionnées	CAR	C
Livraison de la console opérationnelle du MPC	CAR	Moi
Livraison des groupes d'utilisateurs selon le client	CAR	Moi

Entrée en service

Une fois les activités d'intégration terminées, les tests confirmeront que le produit a été livré avec succès et est prêt pour la facturation.

Activités	Equinix	Client
Accédez à la documentation MPC sur docs.equinix.com pour tester l'accès.	CI	RA
Tester l'accès aux différentes consoles pour les différents groupes	CI	RA
Confirmer la conformité aux exigences du MPC sur la base des preuves fournies	CI	RA
Vérifier la documentation de passation des pouvoirs	CI	RA
Configurer le produit pour les systèmes internes du client	RA	I

Opérationnel

Une fois le service de nuage privé géré activé, les points opérationnels suivants sont abordés:

Activités	Equinix	Client
Gestion technique du service (dans son ensemble)	CAR	JE*
Mise à jour et gestion du cycle de vie des logiciels: VCF Operations, vSphere, NSX, vSAN, HCX	CAR	JE*
surveillance et entretien de l'infrastructure MPC	RA	I
Assurez-vous que les applications intégrées à MPC sont compatibles avec les versions de MPC Core.	JE*	CAR
Gestion fonctionnelle de l'environnement du client au sein du service (dans son ensemble)	Moi	CAR
Gérer la capacité de calcul et de stockage de la grappe	Moi	CAR
Créer, importer et gérer des machines virtuelles et des vApps	Moi	CAR
Gardez vos outils VM à jour.	Moi	CAR
Faire évoluer les VM à la hausse et à la baisse	Moi	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	Moi	CAR
NFV : réseaux L2 virtuels	Moi	CAR
NFV : pare-feu standard	Moi	CAR
NFV : Routage (statique)	Moi	CAR
NFV : Routage (dynamique OSPF / BGP)	Moi	CAR
NFV : NAT	Moi	CAR
NFV : DHCP	Moi	CAR
NFV : équilibrage de la charge	Moi	CAR
NFV: VPN (IPsec, Client)	Moi	CAR
Configurer et gérer les fonctionnalités de script et d'automatisation		RACI

Remarque: RACI signifie Responsable, Comptable, Consulté et Informé.

I¹ L’information 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 ayant un impact sur le fonctionnement et/ou la gestion du service.

Gestion des incidents

La gestion des incidents fait partie intégrante du soutien technique. Tous les incidents sont traités par ordre de priorité. Cette priorité est déterminée après le signalement de l'incident et son évaluation par Equinix, en fonction des informations fournies.

Priorité	Impact / Urgence	Description
P1 Haut	L'indisponibilité imprévue d'un service ou d'un environnement fourni et géré par Equinix, conformément à la description du service, suite à une interruption de service, empêche le client de remplir ses obligations envers ses propres utilisateurs. Le client subit un impact direct et tangible de cette indisponibilité.	Le service doit être rétabli immédiatement ; les environnements de production sont indisponibles en raison de perturbations affectant l'ensemble de la plateforme.
P2 Moyen	Le service n'offre pas toutes ses fonctionnalités, ou fonctionne partiellement ou avec des performances réduites, ce qui a un impact sur l'utilisateur. Le client subit un impact direct et tangible en raison de la disponibilité limitée des fonctionnalités.	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é de concert avec la personne qui a fait le signalement.

Remarque: Cette classification ne s’applique pas aux interruptions causées, par exemple, par des applications spécifiques à l’utilisateur, par des actions de l’utilisateur ou par des tiers. Les incidents peuvent être signalés par le portail client, dans la section « Solutions gérées ». Les incidents de niveau 1 doivent être signalés par téléphone.

Demandes de service

Les demandes de service servent à signaler les problèmes de service ou à 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 sous forme de demande de service. L'assistance est disponible 24 heures sur 24, 7 jours sur 7. Deux types de demandes de service sont disponibles:

• Incluse - Les demandes de service qui relèvent de la portée du service et n'entraînent pas de frais supplémentaires.
• Supplémentaire - Demandes de service qui ne relèvent pas de la portée du service et qui entraînent des frais supplémentaires.

Nom de la demande	Inclus / Supplémentaire
Créer un nouveau groupe d'autorisation	Inclus
Supprimer un groupe d'autorisations	Inclus
Ajouter un VLAN à l'instance MPC Core	Inclus
Supprimer un VLAN du noyau MPC	Inclus
Créer une grappe Edge	Supplémentaire
Supprimer la grappe Edge	Supplémentaire
Redimensionner la grappe 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 de ce service, le client recevra un rapport mensuel couvrant les sujets suivants:

• Billets ouverts mesurés par rapport aux paramètres SLA
• Capacité par OVDC

Niveaux de service

L'Accord sur le 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 cette section.

Priorité	Temps de réponse¹	Temps de résolution²	Exécution des travaux	SLA³
P1	< 30 min	< 4 heures	24h/24 et 7j/7	95%
P2	< 60 min	< 24 heures	24h/24 et 7j/7	95%
P3	< 120 min	< 5 jours	24h/24 et 7j/7	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 provoque une erreur au niveau du groupe de charge de travail, interrompant ainsi les services clients.

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

Un régime de crédits de service s'applique au SLA de disponibilité tel que défini dans la Politique Produit. La disponibilité du service MPC n'inclut pas la restauration des données. Il incombe aux clients de restaurer leurs données. Avec un contrat de sauvegarde privée gérée, les données peuvent être restaurées en libre-service via la console opérationnelle de sauvegarde privée gérée. Sans contrat de sauvegarde privée gérée, la restauration des données est à la charge du client.