EBC Core

Un environnement EBC Core est configuré pour un matériel onvDedicated client unique (locataire unique). L'infrastructure se compose de ressources de calcul, de stockage et de réseau qui peuvent être configurées et gérées via un portail.

EBC Core Compute

EBC Core offre un environnement informatique dans lequel les ressources sont utilisées efficacement. La plate-forme EBC Core d'un utilisateur peut inclure divers clusters de calcul. Différents clusters de calcul peuvent être requis pour la virtualisation des postes de travail, les environnements de production séparés et OTA, les restrictions de licence ou les garanties de CPU. EBC Core est fourni dans un cluster composé d'un certain nombre d'hôtes.

EBC Core Host

Dans un environnement EBC Core, l'hôte est basé sur une configuration de serveur standard. Le type de serveur « EBC HV GC » est le serveur standard fourni et il est fourni dans la dernière version disponible. Pour les environnements EBC avec des exigences de mémoire plus élevées, il existe un type de serveur hyperviseur à mémoire élevée. Ceci peut être utilisé sur demande. Le tableau ci-dessous répertorie les types de serveurs hyperviseurs actuellement disponibles et la capacité utilisable qu'un seul serveur hyperviseur ajoute à un cluster.

Type de serveur hyperviseur	Déploiement	Cas d'utilisation	# Go de mémoire vive disponibles1	# Go de mémoire vive disponibles1	Vitesse du cœur de l'unité centrale
EBC HV GC v2	Standard	Calcul générique	450	28	≥ 2.4GHz
EBC HV HM v2	En option	Mémoire élevée	900	28	≥ 2.4GHz

Remarque : Capacité nette du cluster

Un environnement EBC Core a une configuration de cluster d'au moins trois hôtes où deux hôtes sont utilisés et un hôte de secours (principe N+1). Le cluster (N+1) dispose d'un maximum de 15 hôtes (14 + 1) ; un serveur de secours supplémentaire est requis au-delà de ce nombre. La taille maximale du cluster est de 30 serveurs hyperviseurs (28 + 2). La capacité du ou des serveurs de réserve n'est pas disponible pour une utilisation régulière et ne fait donc pas partie de la capacité nette. La présentation ci-dessous montre quelques exemples de tailles de cluster, y compris les tailles minimale et maximale, et la capacité nette utilisable associée dans le nombre de cœurs de CPU utilisables et de Go de RAM.

Taille du cluster central EBC	Modèle de serveur d'hyperviseur	# Serveurs de réserve	# Cœurs de processeur disponibles1	# Go de mémoire vive disponibles1
3 (2+1) minimum	EBC HV GC v2	1	56	900
15 (14+1)	EBC HV GC v2	1	392	6.300
17 (15+2)	EBC HV GC v2	2	420	6.750
30 (28+2) maximum	EBC HV GC v2	2	784	12.600

Remarque : Capacité nette du cluster

Types d'unités d'achat EBC Core

1. Le nombre d'hôtes (hyperviseurs-serveurs) dans le cluster
2. L'engagement de 50% sur la capacité nette en GB RAM
3. Le nombre de Go de RAM utilisés

Dans EBC Core, les cœurs CPU font partie intégrante de l'unité d'achat hôte. La validation de 50 % est un achat minimum dans la capacité nette de RAM en Go du cluster. La capacité totale de RAM nette du cluster est disponible à l'achat et l'utilisation d'une capacité de Go de RAM supérieure à 50 % est facturée pour 1 Go d'utilisation. Les ressources CPU nettes disponibles peuvent être utilisées à votre discrétion.

Les unités d'achat sont décrites dans le tableau ci-dessous.

Unité d'achat	Type d'hôte	Type de facturation	Description
EBC Core - Hôte	• Générique • Mémoire élevée	Ligne de base	Nombre convenu d'hôtes dans la grappe
EBC Core - 50 % d'engagement		Ligne de base	50% des Go de RAM associés à l'hôte
EBC Core - 1GB RAM supplémentaire		Excédent	Consommation de Go de RAM supérieure à la valeur de référence

Vous pouvez également étendre votre environnement EBC Core. L'extension se fait sous la forme d'un hôte plus 50 % de la capacité nette de VRAM Go.

EBC vCPU

Dans le produit EBC Core, 1 processeur est égal à au moins 2,4 GHz. Vous déterminez comment utiliser la capacité des cœurs de CPU physiques nets disponibles. Il existe des directives relatives à l'utilisation du CPU virtuel pour des performances applicatives prévisibles. Valeurs de garantie de CPU virtuels de sursouscription, la valeur de garantie indique le nombre de CPU virtuels pouvant être déployés pour chaque cœur de CPU physique présent. EBC Core vous donne la liberté de déterminer dans quelle mesure le surabonnement est appliqué par cluster de calcul.

Les niveaux de sursouscription les plus couramment utilisés sont les suivants (à titre indicatif) :

Variante vCPU	Valeur de garantie vCPU	Cas d'utilisation
Garantie standard vCPU EBC (par défaut)	1:4 (25%)	• Serveurs de production génériques • Serveurs OTA
Garantie élevée EBC vCPU	1:2 (50%)	- Serveurs d'application à charge moyenne
Garantie totale EBC vCPU	1:1 (100%)	• Serveurs terminaux • Serveurs d'applications à forte charge • Serveurs d'applications sensibles à la latence

Exemple de calcul EBC Core

Vous disposez d'un environnement pour les applications avec une charge supérieure à la moyenne et utilisez donc le vCPU EBC avec garantie élevée. Les ressources demandées sont les suivantes :

1. 500 vCPUs (garantie élevée 1:2)
2. 4000 GB vRAM.
3. 20% d'espace libre pour la croissance

CPU virtuel

En raison de la valeur de garantie 1:2, la moitié des vCPU demandées doivent être présentes en tant que cœurs de CPU physiques pour répondre aux exigences de performance.

500 CPU virtuels : 2 = 250 processeurs.

20% de 500 vCPUs = 100 vCPUs requis comme espace libre pour la croissance.

100 CPU virtuels : 2 = 50 processeurs.

Au total, vous avez besoin de 250 + 50 = 300 CPU.

Mémoire

4000 Go de vRAM et une marge de croissance de 20% sont nécessaires.

4000 GB vRAM + 20% = 4400 GB vRAM.

Hôtes

L'hôte hyperviseur standard ajoute un total net de 28 unités centrales et 450 Go à un CDV.

300 CPU : 28 = 10,7 — en termes de CPU, vous avez besoin d'une capacité de 11 hôtes.

4400 Go de VRAM : 450 = 9,8 — en termes de mémoire, vous avez besoin d'une capacité de 10 hôtes.

La valeur la plus élevée des deux ci-dessus est utilisée, dans ce cas, 11 hôtes.

Pour chaque tranche de 15 hôtes (jusqu'à un maximum de 30) dans un cluster, 1 hôte de secours sera déployé. Dans cet exemple, 1 hôte de secours est ajouté à la configuration.

Le nombre total d'hôtes dans la grappe est donc de 11 + 1 = 12 hôtes.

Un cluster EBC Core avec 12 hôtes est donc déployé avec la capacité nette indiquée dans le tableau ci-dessous.

Taille du cluster EBC Core en nombre d'hôtes	Type de serveur hyperviseur	# Serveurs de réserve	# Cœurs de processeur disponibles1	# Go de mémoire vive disponibles1
(11 + 1) 12	EBC HV GC v2	1	308	4950

Remarque : Capacité nette du cluster

Au sein de ce cluster, vous disposez d'une capacité nette de 308 processeurs et de 4950 Go de RAM disponible. La capacité requise et immédiatement requise est de 500 CPU virtuels (1 :2) et 4000 Go de RAM.

• Ce cluster contient 308 processeurs. Les 500 CPU virtuels haute garantie (1 :2) utilisent 250 CPU. Il y en a Encore 308 - 250 = 58 CPU de capacité nette disponible. Les processeurs sont inclus dans l'unité hôte (ligne de base). L'utilisation de CPU n'a pas de composante de coût (propre).
• Ce cluster contient 4950 Go de RAM. Cette capacité nette se compose de 2 unités d'achat est la suivante :

  • EBC Core - 50 % d'engagement

    L'engagement de 50 % correspond à la moitié de la capacité nette, soit, dans cet exemple, 0,5 * (11 * 450) = 2475 Go de RAM.

  • EBC Core - 1 GB vRAM supplémentaire

    Dans ce cluster, les 50 % restants (2475 Go de RAM) par unité d'achat de 1 Go de RAM sont disponibles en tant qu'excédent. Pour les 4000 Go de RAM directement nécessaires, 4000 - 2475 = 1525 de cette unité d'achat est nécessaire.

La capacité supplémentaire disponible dans cet exemple de cluster est de 4950 - 4000 = 950 Go de RAM.

Le calcul des unités d'achat dans cet exemple est illustré dans le tableau ci-dessous.

Unité d'achat	Type de calcul	Quantité	Description
EBC Core - Hôte générique 450 GB RAM	Ligne de base	12	La taille du cluster est de 12 hôtes (11+1)
EBC Core - 50 % d'engagement	Ligne de base	11	50% d'engagement sur 11 hôtes nets (225 GB RAM/hôte)
EBC Core - 1 GB vRAM supplémentaire	Excédent	1525	La différence entre 4000 Go - 11 * 225 Go de RAM

Noyau EBC en usage

Vous choisissez le nombre d'hôtes et de clusters qui correspondent à la demande de ressources qui inclut les directives ci-dessous -

• La commande minimale est de 50 % de la capacité utilisable d'une grappe.
• Avez-vous besoin de plus de ressources pendant le travail ou la croissance régulière ? Si tel est le cas, vous pouvez accéder à des ressources supplémentaires. La consommation supplémentaire est automatiquement facturée mensuellement. Le gestionnaire de compte Equinix peut vous conseiller sur l'achat qui convient le mieux à votre situation.
  • Pour EBC Core, la consommation supplémentaire est limitée à la capacité maximale disponible. (100 %) d'un cluster utilisé pour votre environnement.
• Dans les limites de l'hôte, EBC Core n'a pas de taille maximale de VM pour l'utilisation de ressources de calcul. Il existe des recommandations pour les meilleures performances d'une machine virtuelle. L'ajout de ressources de traitement supplémentaires à une machine virtuelle au-delà de la taille recommandée ne conduit pas toujours à une amélioration des performances.
  • Pour EBC Core, la taille maximale recommandée de la VM est de 8 vCPU et 64 Go de vRAM.

Option EBC Core 3.0 Sans licence VMware (NVL)

Avec EBC Core 3,0, les hôtes sont configurés dans un cluster VMware. Le prix de l'hôte inclut les licences VMware. EBC Core 3,0 NVL offre une option pour régler les licences VMware séparément en tant que points de licence VMware. Dans ce cas, vous payez un prix inférieur pour la validation de 50 % de la VRAM Go et pour la VRAM Go supplémentaire. L'avantage de cette option est que les licences ne sont réglées que pour la durée pendant laquelle une machine virtuelle de la plate-forme utilise réellement VMware conformément à la définition de VMware.

Stockage de base EBC

Le stockage EBC est une partie fixe de la plate-forme EBC. Le stockage peut être acheté à quatre niveaux de performances (niveaux), sous la forme de magasins de données sur lesquels les machines virtuelles peuvent être placées. Les performances du magasin de données dépendent de sa taille et sont exprimées en opérations d'E/S par seconde (IOPS). Les performances de chacun des magasins de données sont partagées entre les machines virtuelles qu'il contient.

En termes de performance, chaque niveau a une garantie et une valeur limite. La garantie est la valeur que Equinix est tenu de livrer. Vous pouvez utiliser plus que la valeur de garantie pour de courtes périodes, jusqu'à la valeur limite, selon le principe de l'utilisation équitable. Un responsable de compte Equinix peut vous conseiller sur les niveaux de performance les mieux adaptés à votre situation. Les spécifications de performances de stockage des niveaux livrables sont indiquées ci-dessous.

Niveau	Nom	Utilisation	Impact
1	Haute performance	DB (Logs), RDS/ SBC, VDI Charges de travail bénéfiques à faible latence	• Garantie IOPS : 1,000 IOPS par To ; max. • 30,000 par datastore1 • limite IOPS : 1,500 IOPS par To ; max. • 45,000 par magasin de données2 • latence : 5 ms3 • taille : Min 250 Go, max. 30 To par volume4, 5, 6
2	Performance (par défaut)	VM génériques, services applicatifs / Web, services de fichiers à haute performance / stockage d'objets	• Garantie IOPS : 250 IOPS par To. Max. 7,500 par datastore1 • limite IOPS : 500 IOPS par To. max. 15,000 par magasin de données2 • latence : 10 ms3 • taille : Min 250 Go, max. 30 To par volume4, 5, 6
3	Standard	Sauvegarde, générique Services de fichiers / stockage d'objets	• Garantie IOPS : 100 IOPS par To. max. 3,000 par datastore1 • limite d'IOPS : 250 IOPS par To. max. 7,500 par magasin de données2 • latence : 15 ms3 • taille : Min 250 Go, max. 30 To par volume4, 5, 6
4	Archiver	Archives, Stockage à froid	• Garantie IOPS : 50 IOPS par To. max. 1,500 par datastore1 • limite d'IOPS : 75 IOPS par To. max. 2,250 par magasin de données2 • latence : 20 ms3 • taille : Min 250 Go, max. 30 To par volume4, 5, 6

Remarque :

1. IOPS - Valeur maximale de 65 % en lecture / 35 % en écriture avec une taille de bloc de 8 Ko.

2. Limite – basée sur une utilisation équitable. En cas de dépassement à long terme de la garantie (utilisation équitable), Equinix se réserve le droit de fixer la garantie comme limite.

3. Latence – Moyenne par 5 minutes dans le cadre de la garantie IOPS.

4. Taille – Extension par tranche de 250 Go.

5. Arrondi – GB est mis en œuvre sur la base de multiples de 1024.

6. Arrondi – 1 To équivaut à 1 000 Go.

Caractéristiques du stockage de base EBC

• La taille minimale recommandée pour un disque virtuel est de 40 Go.
• La taille maximale d'un disque virtuel est de 8 To.
• Les performances de chaque magasin de données sont partagées entre les machines virtuelles qui l'utilisent.
• La performance IOPS disponible est partagée avec la solution de sauvegarde EBC.
• La capacité de stockage est attribuée par multiples de 250 Go.
• La capacité de stockage est allouée par grappe de calcul.
• La gestion de la capacité de stockage est assurée par le client.
• Les magasins de données sont répertoriés par niveau dans leur propre cluster de magasins de données.

Unités d'achat de stockage de base EBC

Le stockage EBC Core est acheté dans des magasins de données conformément à la politique de stockage, avec des unités d'achat de 1 Go. Une validation ou une ligne de base minimale de 250 Go par cluster de magasins de données s'applique à chaque règle.

Exemples de calcul pour le stockage de base EBC

Exemple de calcul 1 vous achetez un cluster EBC avec 5 To de stockage de niveau 2. Vous avez alors accès à 1 magasin de données de niveau 2 puisque la capacité demandée est inférieure à 30 To, avec les éléments suivants :

• Garantie - 1250 IOPS

  • Par magasin de données : Max. 2500 IOPS
  • Par To : 5 TO X 250 IOPS = 1250 IOPS

  La valeur la plus basse des deux ci-dessus est utilisée, dans ce cas, 1250 IOPS.

• Limite - 2500 IOPS

  • Par magasin de données : Max. 15000 IOPS
  • Par To : 5 TO X 500 IOPS = 2500 IOPS

  La valeur la plus basse des deux ci-dessus est utilisée, dans ce cas, 2500 IOPS.

Exemple de calcul 2 vous commandez un cluster EBC avec 20 To de stockage de niveau 1 et 50 To de stockage de niveau 2. Vous avez alors accès à :

Niveau 1 – un magasin de données puisque la capacité demandée est inférieure ou égale à 30 To, avec les éléments suivants :

• Garantie - 20 000 IOPS

  • Par magasin de données : Max. 30,000 IOPS
  • Par To : 20 TO X 1000 IOPS = 20,000 IOPS

  La valeur la plus basse des deux ci-dessus est utilisée, dans ce cas, 20 000 IOPS.

• Limite - 30 000 IOPS

  • Par magasin de données : Max. 45,000 IOPS
  • Par To : 20 TO X 1500 IOPS = 30,000 IOPS

  La valeur la plus basse des deux ci-dessus est utilisée, dans ce cas, 30 000 IOPS.

Niveau 2 : deux magasins de données de 25 To, la capacité requise étant supérieure à 30 To, avec les éléments suivants :

• Garantie - 2500 IOPS

  • Par magasin de données : Max. 7500 IOPS
  • Par To : 25 TO X 250 IOPS = 6250 IOPS

  La valeur la plus basse des deux ci-dessus est utilisée, dans ce cas, 6 250 IOPS par magasin de données.

• Limite - 5000 IOPS

  • Par magasin de données : Max. 15000 IOPS
  • Par To : 25 TO X 500 IOPS = 12 500 IOPS.

  La valeur la plus basse des deux ci-dessus est utilisée, dans ce cas, 12 500 IOPS par magasin de données.

Utilisation du stockage central EBC

Les frais de stockage partagé sont basés sur la consommation de la capacité allouée de tous les disques virtuels liés et sur la capacité utilisée. Ceci est mesuré à partir de ce qui suit, par règle :

• Fichiers d'échange de VM
• Instantanés
• Fichiers dans une bibliothèque (modèles de vApp et ISO)

Lorsque vous souhaitez lier plus de 4 To à une ou plusieurs machines virtuelles, dans certains cas, il peut être conseillé d'utiliser le service de stockage géré Equinix (EMSS). Lors de l’utilisation de l’EMSS, le stockage peut être lié au sein des machines virtuelles du client sans l’intervention de la plateforme EBC. Les cas d'utilisation sont l'utilisation d'un fichier virtuel ou d'un serveur de sauvegarde. Des instantanés facultatifs ou des copies supplémentaires des données stockées dans le service EMS peuvent être créés dans un deuxième centre de données IBX.

Réseau central EBC

La plate-forme EBC offre diverses fonctionnalités de réseau virtuel que vous pouvez configurer via le portail en libre-service. Equinix offre cette fonctionnalité sur cinq niveaux de fonctionnalités de virtualisation des fonctions réseau (NFV) :

1. Basique
2. Standard
3. Avancé
4. Entreprise
5. Enterprise plus

NFV – libre-service

La plupart des fonctions NFV sont disponibles via le portail Web en libre-service, les outils d'automatisation et API. Cela donne à l'organisation la possibilité de mettre en œuvre la configuration réseau souhaitée sans avoir à investir dans l'équipement à l'avance. Les architectes Equinix peuvent vous conseiller à ce sujet si nécessaire. Voici quelques exemples de fonctions NFV :

• Pare-feu jusqu'à la couche 4 (L4).
• NAT
• Routage
• Équilibrage de charge
• VPN

Routeurs virtuels

Les caractéristiques et fonctionnalités offertes par les routeurs virtuels sont similaires à celles de Shared Network, sauf que leurs plages de déploiement couvrent uniquement large, Extra large et Quad large.

Micro-segmentation

La micro-segmentation, également connue pour les pare-feu distribués (DFW), est une fonctionnalité importante de la plate-forme EBC ST et est disponible à partir du niveau de fonctionnalité Advanced NFV. La fonction DFW permet aux utilisateurs d'appliquer dynamiquement des règles de pare-feu basées sur les machines virtuelles, les balises, les groupes de ports, le type de système d'exploitation, etc. Cela contraste avec les situations traditionnelles où il est seulement possible de pare-feu sur une interface d'un routeur basée sur l'adresse IP ou le segment IP. L'application de règles DFW rend possible le principe de mise en réseau zéro confiance lorsqu'il n'est plus nécessaire de configurer un segment IP, un routeur et un pare-feu pour chaque application ou collection de machines virtuelles qui protègent l'utilisateur.

Unités d'achat du réseau central EBC

Veuillez consulter les unités d'achat du réseau EBC Flex proposées par EBC Core Network.

Réseaux internes

Les réseaux internes sont des réseaux de couche 2 (L2) auxquels des machines virtuelles peuvent être connectées et qui ne peuvent exister qu'au sein d'un environnement EBC Core dans un seul centre de données. Ces réseaux sont basés sur la technologie de superposition et sont disponibles en groupes de ports. Ils transcendent les clusters de calcul et ne sont accessibles que via des routeurs virtuels (L3) en dehors du datacenter. Les cas d'utilisation incluent le zonage et la segmentation du réseau EBC. Des réseaux internes supplémentaires peuvent être demandés via une demande de service adressée au centre d'assistance Equinix. Si vous avez besoin de réseaux L2 et/ou L3 disponibles en dehors de votre environnement EBC Core, reportez-vous à la section réseaux externes . Cinq réseaux internes sont inclus dans le cadre du service EBC Core. Si plus de cinq réseaux internes sont utilisés par centre de données, ceux-ci sont facturés automatiquement tous les mois.

Réseaux externes

Les réseaux externes sont des réseaux de couche 2 (L2) auxquels des machines virtuelles ou des routeurs peuvent être connectés. Pour activer la connectivité externe, vous devez acheter les services EBC Connect en combinaison avec d'autres services Equinix, tels que Metro Connect ou ECX Fabric. Les réseaux externes sont basés sur des VLAN et sont mis à disposition sous forme de groupes de ports. Ils transcendent les clusters de calcul et sont accessibles en dehors du centre de données sans l'intervention de routeurs. Les exemples d'utilisation incluent la connectivité à un deuxième centre de données, un environnement sur site ou des fournisseurs de cloud public. Des réseaux externes supplémentaires peuvent être demandés via une demande de service auprès du centre d'assistance Equinix. Cinq réseaux externes sont inclus dans le service EBC Core. Si plus de cinq réseaux externes sont utilisés par centre de données, ils sont facturés automatiquement tous les mois.

Routeurs personnels

Voir EBC Flex Network : Propres routeurs pour en savoir plus.

Mesure

Les services Equinix Managed Solutions sont facturés selon les modalités suivantes :

• Base - Quantité contractuelle du service (exemple : unité d'achat vCPU, vRAM)
• Dépassement - Le nombre de Go consommés au-delà de la valeur de référence (exemple : la valeur de référence du contrat de stockage est de 500 Go, 600 Go sont utilisés et le dépassement consommé est de 100 Go).
• Paiement à l'utilisation - Entièrement variable (exemple : utilisation d'un certain nombre de Go pour la sauvegarde)

Pour mesurer la quantité de la consommation de composants variables, Equinix utilise des outils de comptage liés à l’environnement de gestion des services. Seules les données nécessaires pour déterminer la quantité de service consommée sont exportées vers le système de facturation Equinix. Il est obligatoire d'installer les outils VMware sur chaque machine virtuelle de la plate-forme EBC.

Rapports

Le service EBC contient des options de reporting standard.

Licences

Pour les problèmes liés à la licence, accédez à licences.

Remarque :

• Le partage d'un disque virtuel entre plusieurs machines virtuelles n'est pas pris en charge dans l'EBC. L'application du clustering avec basculement Microsoft Windows Server (WSFC) avec des disques partagés à EBC n'est donc pas prise en charge.
• L'application de la virtualisation d'E/S à racine unique (SR-IOV) et l'accès physique au NIC à partir de la VM ne sont pas pris en charge.
• L'application de réservations de mémoire par VM n'est pas prise en charge.
• L'accès direct à l'hôte n'est pas possible.
• Il n'y a pas de gestion déléguée ni d'assistance aux clients pour accéder à la couche de gestion de la plateforme EBC.

Options

EBC Virtual GPU

Si vous avez besoin d'une accélération GPU dans votre environnement EBC, la plate-forme EBC Core offre cette option. En appliquant les cartes NVIDIA Tesla GP avec accès direct à la plate-forme, l'infrastructure de bureau virtuel (VDI) rend possibles les applications avec accélération GPU. Un environnement adapté est conçu avec un architecte Equinix basé sur des blocs de construction standardisés.

Reprise après sinistre EBC

EBC Core offre la possibilité de mettre en place un site de reprise après sinistre (DR) dans le cadre de votre plan de continuité des activités en appliquant une solution DR.

L'objectif de la fonctionnalité de reprise après sinistre est de réduire le temps nécessaire pour restaurer le service après une interruption. En appliquant une réplication asynchrone ou synchrone, EBC DR peut fournir un objectif de point de restauration (RPO) pouvant atteindre 0 minute.

Le secours EBC et les fonctionnalités DR ne sont disponibles que dans les centres de données IBX d'Amsterdam et de Zwolle.

Relations et dépendances

Voir les relations et dépendances avec les services suivants ci-dessous -

• Sauvegarde et restauration EBC
• Migration EBC
• Connexion EBC
• Connexion Client
• Connexions transversales
• Metro Connect
• Equinix Fabric

Pare-feu géré

Une partie optionnelle de l'environnement EBC est une solution Managed Firewall qui peut vous être utile dans les cas suivants :

• Faciliter l'accès sécurisé au nuage public et à d'autres réseaux externes.
• Ajouter des fonctions de détection d'intrusion (IDS) ou de prévention d'intrusion (IPS) à la plateforme EBC.
• Avoir un accès direct à la couche de gestion de la plate-forme EBC. Voir accès direct à la plate-forme pour plus de détails.
• Transférer la gestion opérationnelle du pare-feu à Equinix.

Les principales fonctionnalités du service Managed Firewall sont les suivantes :

• Coupe-feu
• Routage
• IDS/IPS (variante de commande)
• Équilibrage de la charge
• VPN

Routeur géré

La solution Managed Router est une option de l'environnement EBC qui peut vous être utile dans les cas suivants :

• Faciliter l'accès au nuage public, aux fournisseurs WAN et aux réseaux sur site.
• Transférer la gestion opérationnelle des routeurs à Equinix.

Les principales fonctionnalités du routeur géré sont les suivantes :

• Routage dynamique
• Routage statique
• NAT
• Protocole de redondance des routeurs virtuels (VRRP)