Skip to main content

EBC Core

An EBC Core environment is set up for a single customer (single tenant) onvdedicated hardware. The infrastructure consists of compute, storage and network resources that can be configured and managed through a portal.

EBC Core Compute​

EBC Core offers a compute environment where the resources are used efficiently. A user’s EBC Core platform can include various compute clusters. Different compute clusters may be required for desktop virtualization, separate production and over-the-air (OTA) environments, license restrictions or CPU guarantees. EBC Core is supplied in a cluster consisting of a number of hosts.

EBC Core Host​

The host in an EBC Core environment is based on a standard server configuration. The ‘’EBC HV GC’’ server type is the standard server supplied and it’s supplied in the latest available version. For EBC environments with more demanding memory requirements, there is a High Memory hypervisor server type. This can be used on request. The table below lists the currently available hypervisor server types with the amount of usable capacity that a single hypervisor server adds to a cluster.

Hypervisor Server TypeDeploymentUse Case# Available GB RAM1# Available GB RAM1CPU Core Speed
EBC HV GC v2StandardGeneric Compute45028≥ 2.4GHz
EBC HV HM v2OptionalHigh Memory90028≥ 2.4GHz

Note: Net capacity of the cluster

An EBC Core environment has a cluster configuration of at least three hosts where two hosts are used and one is spare (N + 1 principle). The (N + 1) cluster has a maximum of 15 hosts (14 + 1); an extra spare server is required above this number. The maximum cluster size is 30 hypervisor servers (28 + 2). The capacity of the spare server(s) is not available for regular use and therefore is not a part of the net capacity. The overview below shows some examples of cluster sizes, including the minimum and maximum sizes, and the associated usable net capacity in the number of usable CPU Cores and GB RAM.

EBC Core Cluster SizeHypervisor Server Model# Spare Servers# Available CPU Cores1# Available GB RAM1
3 (2+1) minimumEBC HV GC v2156900
15 (14+1)EBC HV GC v213926.300
17 (15+2)EBC HV GC v224206.750
30 (28+2) maximumEBC HV GC v2278412.600

Note: Net capacity of the cluster

EBC Core Purchase Units Types​

  1. The number of hosts (hypervisor-servers) in the cluster
  2. The 50% commit on the net capacity in GB RAM
  3. The amount of GB RAM used

In EBC Core, the CPU cores are an integral part of the host purchase unit. The 50% commit is a minimum purchase in the net GB RAM capacity of the cluster. The full net RAM capacity of the cluster is available for purchase and the use of GB RAM capacity above 50% is charged per 1 GB of usage. The available net CPU resources can be used at your discretion.

The purchase units are described in the table below.

Purchase UnitType of HostBilling TypeDescription
EBC Core - Host• Generic • High MemoryBaselineAgreed number of hosts in the cluster
EBC Core - 50% CommitBaseline50% of the GB RAM associated with the host
EBC Core - 1GB RAM AdditionalOverageAmount of GB RAM consumption above the baseline

You can also expand your EBC Core environment. Expansion takes place in the form of 1 host plus 50% commit of net GB vRAM capacity.

EBC vCPU​

Within the EBC Core product, 1 CPU is equal to at least 2.4 GHz. You determine how to use the capacity of the net available physical CPU cores. There are guidelines for vCPU use for predictable application performance. The vCPU guarantee values of over-subscription, the guarantee value indicates how many vCPUs can be deployed for each physical CPU core present. EBC Core gives you freedom on the extent to which over-subscription is applied per compute cluster.

The most commonly used over-subscription levels are (as an indication):

vCPU VariantvCPU Guarantee ValueUse Case
EBC vCPU Standard Guarantee (Default)1:4 (25%)• Generic production servers • OTA servers
EBC vCPU High Guarantee1:2 (50%)• Medium-load application servers
EBC vCPU Full Guarantee1:1 (100%)• Terminal servers • High-load application servers • Latency-sensitive application servers

Calculation Example EBC Core​

You have an environment for applications with an above-average load and therefore use the EBC vCPU with High Guarantee. The requested resources are:

  1. 500 vCPUs (High Guarantee 1:2)
  2. 4000 GB vRAM.
  3. 20% free space for growth

vCPU

Due to the 1:2 guarantee value, half of the requested vCPUs need to be present as physical CPU cores to meet the performance requirements.

500 vCPUs: 2 = 250 CPUs.

20% of 500 vCPUs = 100 vCPUs required as free space for growth.

100 vCPUs: 2 = 50 CPUs.

In total, you need 250 + 50 = 300 CPUs.

Memory

4000 GB of vRAM and 20% room for growth are needed.

4000 GB vRAM + 20% = 4400 GB vRAM.

Hosts

The standard hypervisor host adds a net of 28 CPUs and 450 GB to a VDC.

300 CPU : 28 = 10,7 — In terms of CPU, you need a capacity of 11 hosts.

4400 GB vRAM : 450 = 9,8 — In terms of memory, you need a capacity of 10 hosts.

The higher value of the two above is used, in this case, 11 hosts.

For every 15 hosts (up to a maximum of 30) in a cluster, 1 spare-host will be deployed. In this example, 1 spare-host is added to the configuration.

The total number of hosts in the cluster is therefore, 11 + 1 = 12 hosts.

An EBC Core cluster with 12 hosts is thus deployed with the net capacity shown in the table below.

EBC Core Cluster Size in # HostsHypervisor Server Type# Spare Servers# Available CPU Cores1# Available GB RAM1
(11 + 1) 12EBC HV GC v213084950

Note: Net capacity of the cluster

Within this cluster, you have a net capacity of 308 CPUs and 4950 GB RAM available. The requested and immediately required capacity is 500 vCPUs (1:2) and 4000 GB RAM.

  • This cluster contains 308 CPUs. The 500 High Guarantee vCPUs (1:2) use 250 CPUs. There is still 308 - 250 = 58 CPU of net capacity available. The CPUs are included in the host unit (Baseline). The use of CPUs has no (own) cost component.
  • This cluster contains 4950 GB RAM. This net capacity consists of 2 purchase units is as follows:

    • EBC Core – 50% Commit

      The 50% Commit is half the net capacity, in this example it’s 0.5 * (11 * 450) = 2475 GB RAM.

    • EBC Core – 1 GB vRAM Additional

      In this cluster, the remaining 50% (2475 GB RAM) per purchase-unit of 1 GB RAM is available as Overage. For the directly needed 4000 GB RAM, 4000 - 2475 = 1525 of this purchase unit is needed.

The additional available capacity in this example cluster is 4950 - 4000 = 950 GB RAM.

Calculation of purchase units in this example is depicted in the below table.

Purchase UnitCalculation TypeQuantityDescription
EBC Core – Generic Host 450 GB RAMBaseline12Cluster Size is 12 Hosts (11+1)
EBC Core – 50% CommitBaseline1150% commit at 11 net hosts (225 GB RAM/host)
EBC Core – 1 GB vRAM AdditionalOverage1525The difference between 4000 GB - 11 * 225 GB RAM

EBC Core In Use​

You choose the number of hosts and clusters that match the resource request that includes the below guidelines –

  • The minimum order is 50% of the usable capacity of a cluster.
  • Do you need more resources during work or regular growth? If so, you can access additional resources. The additional consumption is automatically billed monthly. The Equinix account manager can advise you on which purchase best suits your situation.
    • For EBC Core, the additional consumption is limited to the maximum available capacity (100%) of a cluster that is used for your environment.
  • Within the limits of the host, EBC Core does not have a maximum size of VM for the use of compute resources. There are recommendations for the best performance of a VM. Adding more compute resources to a VM above the recommended size does not always lead to performance improvements.
    • For EBC Core, the maximum recommended VM size is 8 vCPU and 64 GB vRAM.

Option EBC Core 3.0 No VMware Licenses (NVL)​

With EBC Core 3.0, the hosts are configured in a VMware cluster. The host price includes the VMware licenses. EBC Core 3.0 NVL offers an option to settle the VMware licenses separately as VMware license points. In this case, you pay a lower price for the Commit 50% of the GB vRAM and for the Additional GB vRAM. The advantage of this option is that licenses are only settled for the time that one VM on the platform actually uses VMware in accordance with the definition of VMware.

EBC Core Storage​

EBC storage is a fixed part of the EBC platform. The storage can be purchased at four performance levels (tiers), in the form of data stores on which VMs can be placed. The performance of the data store depends on the size of the data-store and is expressed in I/O operations per second (IOPS). The performance of each of the data stores is shared among the VMs on it.

In terms of performance, each tier has a guarantee and a limit value. The guarantee is the value that Equinix is obligated to deliver. You can use more than the guarantee value for short periods, up to the limit value, according to the fair use principle. An Equinix account manager can advise you on which performance levels best suit your situation. The storage performance specification of the deliverable tiers is shown below.

TierNameUseImpact
1High performanceDB (Logs), RDS/ SBC, VDI Low-latency beneficial workloads• IOPS guarantee: 1.000 IOPS per TB; max. • 30.000 per data-store1 • IOPS limit: 1.500 IOPS per TB; max. • 45.000 per data-store2 • Latency: 5 ms3 • Size: Min 250 GB, max. 30 TB per volume4, 5, 6
2Performance (Default)Generic VMs, App / Web services, High performance File services / Object storage• IOPS guarantee: 250 IOPS per TB. max.7.500 per data-store1 • IOPS limit: 500 IOPS per TB. max. 15.000 per data-store2 • Latency: 10 ms3 • Size: Min 250GB, max. 30TB per volume4, 5, 6
3StandardBack-up, Generic File services / Object storage• IOPS guarantee: 100 IOPS per TB. max. 3.000 per data-store1 • IOPS limit: 250 IOPS per TB. max. 7.500 per data-store2 • Latency: 15 ms3 • Size: Min 250 GB, max. 30 TB per volume4, 5, 6
4ArchiveArchive, Cold storage• IOPS guarantee: 50 IOPS per TB. max. 1.500 per data-store1 • IOPS limit: 75 IOPS per TB. max. 2.250 per data-store2 • Latency: 20 ms3 • Size: Min 250 GB, max. 30 TB per volume4, 5, 6

Note:

  1. IOPS – Maximum value by 65% read / 35% write with 8 KB block size.

  2. Limit – Based on fair use. In the event of long-term exceeding of the guarantee (fair use), Equinix reserves the right to set the guarantee as a limit.

  3. Latency – Average per 5 minutes within IOPS guarantee.

  4. Size – Expansion per 250 GB.

  5. Rounding – GB is implemented based on multiples of 1024.

  6. Rounding – 1 TB equals 1000 GB.

EBC Core Storage Features​

  • The minimum recommended virtual disk size is 40 GB.
  • The maximum virtual disk size is 8 TB.
  • The performance of each data-store is shared among those VMs that use it.
  • The available IOPS performance is shared with the EBC back-up solution.
  • The storage capacity is allocated in multiples of 250 GB.
  • The storage capacity is allocated per compute cluster.
  • Capacity management of the storage is carried out by the customer.
  • Data-stores are listed per tier in their own data store cluster.

EBC Core Storage Purchase Units​

EBC Core storage is purchased in data-stores per the storage policy, with purchase units of 1 GB. A minimum commit or baseline of 250 GB per data store cluster applies to each policy.

Calculation Examples for EBC Core Storage​

Calculation Example 1 You purchase an EBC cluster with 5 TB of tier 2 storage. You then have access to 1 data store tier 2 since the requested capacity is less than 30 TB, with the following:

  • Guarantee – 1250 IOPS
    • Per data store: Max. 2500 IOPS
    • Per TB: 5 TB x 250 IOPS = 1250 IOPS
    The lowest value of the two above is used, in this case, 1250 IOPS.
  • Limit – 2500 IOPS
    • Per data store: Max. 15000 IOPS
    • Per TB: 5 TB x 500 IOPS = 2500 IOPS
    The lowest value of the two above is used, in this case, 2500 IOPS.

Calculation Example 2 You order an EBC cluster with 20 TB of tier 1 storage and 50 TB of tier 2 storage. You then have access to:

Tier 1 – One data store since the requested capacity is less than or equal to 30 TB, with the following:

  • Guarantee – 20.000 IOPS
    • Per data store: Max. 30.000 IOPS
    • Per TB: 20 TB x 1000 IOPS = 20.000 IOPS
    The lowest value of the two above is used, in this case, 20.000 IOPS.
  • Limit – 30.000 IOPS
    • Per data store: Max. 45.000 IOPS
    • Per TB: 20 TB x 1500 IOPS = 30.000 IOPS
    The lowest value of the two above is used, in this case, 30.000 IOPS.

Tier 2 – Two data stores of 25 TB, as the requested capacity is larger than 30 TB, with the following:

  • Guarantee – 2500 IOPS
    • Per data store: Max. 7500 IOPS
    • Per TB: 25 TB x 250 IOPS = 6250 IOPS
    The lowest value of the two above is used, in this case, 6,250 IOPS per data store.
  • Limit – 5000 IOPS
    • Per data store: Max. 15000 IOPS
    • Per TB: 25 TB x 500 IOPS = 12,500 IOPS.
    The lowest value of the two above is used, in this case, 12,500 IOPS per data store.

EBC Core Storage Usage​

Charges for Shared Storage are based on consumption of the allocated capacity of all linked virtual disks and the capacity in use. This is measured from the following, per policy:

  • VM swap files
  • Snapshots
  • Files in a Library (vApp templates and ISOs)

When you want to link more than 4 TB to one or more VMs, in some situations, it may be advisable to use the Equinix Managed Storage Service (EMSS). While using the EMSS, storage can be linked within the client’s VMs without the intervention of the EBC platform. Use cases are the use of a virtual file or back-up server. Optional snapshots or extra copies of the data stored within the EMS service can be created in a second IBX data center.

EBC Core Network​

The EBC platform offers various virtual network functionalities that you can configure through the self-service portal. Equinix offers this functionality on five Network Functions Virtualization (NFV) feature levels:

  1. Basic
  2. Standard
  3. Advanced
  4. Enterprise
  5. Enterprise Plus

NFV–self-service​

Most NFV functions are available through the self-service web portal, automation tooling and API. This gives the organization the opportunity to implement the desired network configuration without having to invest in equipment in advance. Equinix architects can advise on this if necessary. Here are some examples of NFV functions:

  • Firewalling up to Layer-4 (L4).
  • NAT
  • Routing
  • Load–balancing
  • VPN

Virtual Routers​

The features and functionalities offered by Virtual Routers are similar to those in Shared Network, except that their deployment ranges only cover Large, Extra Large, and Quad Large.

Micro-segmentation​

Micro-segmentation, also known for distributed firewalls (DFW), is an important feature of the EBC ST-platform and is available from the Advanced NFV feature level. The DFW function allows users to dynamically apply firewall rules based on VMs, tags, port groups, type of OS and so on. This contrasts with traditional situations where it is only possible to firewall on an interface of a router based on IP-address or IP-segment. Applying DFW rules makes the principle of zero-trust networking possible where there is no longer any need to configure an IP segment, router and firewall for each application or collection of virtual machines that protect the user.

EBC Core Network purchase units​

See EBC Flex Network Purchase Units offered by EBC Core Network.

Internal networks​

Internal networks are Layer 2 (L2) networks to which VMs can be connected that can only exist within an EBC Core environment in a single data center. These networks are based on overlay technology and are available in port-groups. They transcend compute clusters and can only be accessed via virtual routers (L3) outside the data center. Use cases include zoning and segmentation of the EBC network. Additional internal networks can be requested via a service request to the Equinix Support Desk. If you need L2 and/or L3 networks that are available outside your EBC Core environment, see External Networks. Five internal networks are included as part of the EBC Core service. If more than five internal networks are used per data center, these are invoiced automatically every month.

External Networks​

External networks are Layer 2 (L2) networks to which VMs or routers can be connected. To enable external connectivity, you must purchase EBC Connect services in combination with other Equinix services, like Metro Connect or ECX Fabric. External networks are based on VLANs and are made available in the form of port-groups. They transcend compute clusters and can be accessed outside the data center without the intervention of routers. Use cases include connectivity to a second data center, on-premises environment or public cloud providers. Additional external networks can be requested via a Service Request from the Equinix Support Desk. Five external networks are included as part of the EBC Core service. If more than five external networks are used per data center, they are invoiced automatically every month.

Own Routers​

See EBC Flex Network: Own Routers to learn more.

Metering​

Equinix Managed Solutions are billed in the following ways:

  • Baseline – The contracted quantity of the service (example: purchase unit vCPU, vRAM)
  • Overage – The amount of GB consumed above the baseline value (example: the contracted storage baseline is 500 GB, 600 GB are used and the overage consumed is 100 GB)
  • Pay per use – Fully variable (example: used amount of GB for back-up)

To measure the quantity of the variable component consumption, Equinix uses metering tools linked to the service management environment. Only the data required to determine the quantity of service consumed are exported to the Equinix billing system. It is mandatory to install the VMware tools on every VM in the EBC Platform.

Reporting​

The EBC service contains standard reporting options.

Licensing​

For license-related issues, go to Licensing.

Note:

  • Sharing a virtual disk between multiple VMs is not supported within the EBC. Applying Microsoft Windows Server failover clustering (WSFC) with shared disks to EBC is therefore not supported.
  • Application of single root I/O virtualization (SR-IOV) and physical NIC access from the VM are not supported.
  • Applying memory reservations per VM is not supported.
  • Direct access to the host is not supported.
  • There is no delegated management and support for customers to access the EBC platform management layer.

Options​

EBC Virtual GPU​

If you need GPU acceleration within your EBC environment, the EBC Core platform offers this option. By applying NVIDIA Tesla GP–cards with direct platform access, virtual desktop infrastructure (VDI) makes applications with GPU acceleration possible. A suitable environment is designed with an Equinix architect based on standardized building blocks.

EBC Disaster Recovery​

EBC Core offers the option to set up a disaster recovery (DR) location as part of your business continuity plan by applying a DR solution.

The purpose of DR functionality is to shorten the time needed to restore service after disruption. By applying asynchronous or synchronous replication, EBC DR can deliver a recovery point objective (RPO) of up to 0 minutes.

EBC fallback and the DR functionalities are available only at the Amsterdam and Zwolle IBX data center locations.

Relations and Dependencies​

See Relations and Dependencies with the following services below -

Managed Firewall​

An optional part of the EBC environment is a Managed Firewall solution which may be relevant to you in the following scenarios:

  • Facilitate secure access to the public cloud and other external networks.
  • Add functions for intrusion detection (IDS) or intrusion prevention (IPS) to the EBC platform.
  • Have direct access to the management layer of the EBC platform. See Direct platform access for details.
  • Transfer operational firewall management to Equinix.

Important features of the Managed Firewall service include:

  • Firewalling
  • Routing
  • IDS/IPS (order variant)
  • Load balancing
  • VPN

Managed Router​

The Managed Router solution is an optional part of the EBC environment which may be relevant to you in the following scenarios:

  • Facilitate access to the public cloud, WAN providers and on-premises networks.
  • Transfer operational router management to Equinix.

Important features of the Managed Router include:

  • Dynamic routing
  • Static routing
  • NAT
  • Virtual Router Redundancy Protocol (VRRP)