EBSI Environments
To ensure that software components and new features are tested appropriately before development, EBSI will follow the DTAP standard. As a consequence, 3 different networks (i.e., environments) are foreseen in the release orchestration for EBSI.
Node Operators can choose to operate a single or combination of networks. See below:
An EBSI node requires a virtual host with access to the Internet and with individual fixed IPV4 public IP addresses.
It can be either a physical server computer or a virtual machine running in a self-hosted data center infrastructure, a private cloud, or a public cloud, located in the European Economic Area.
For the EBSI project, 3 different environments are foreseen (meaning 3 different networks and 3 different virtual hosts). Each Virtual Host will be used to join a different environment - one virtual host per environment.
Before joining any EBSI Network, all 3 hosts will have to pass a technical check to validate that all the minimum requirements are respected. For the whole duration of the hosts being part of the EBSI network, all minimum requirements must be respected. A Node Operator can upgrade the performance, but can't lower it down at any moment.
Type of nodes: Validator vs Regular
Each EBSI environment contains two types of nodes:
- Validator nodes: have the role to propose and sign new blocks. Also, they maintain a copy of the ledger by staying in sync with the network
- Regular nodes: Maintain a copy of the ledger by staying in sync with the network.
The minimum technical requirements are similar for both types of nodes, validator or regular being only the role of the node in the network. What is different is the SLA requirements, for the Validator Nodes the SLA is more strict compared to the Regular Nodes.
A Node Operator can choose the role of its node(s) in the respective environment at the onboarding phase or later on, by opening a ticket to the EBSI Support Desk and requiring to upgrade a Regular Node to a Validator or to downgrade a Validator to a Regular Node.
Hardware
Each computer host – virtual machine – must have these minimum specifications and must be hosted in a dedicated technical room for servers, data center or cloud:
| EBSI V2 Pilot Environment VM | EBSI V2 Pre-Production Environment VM | EBSI V2 Production Environment VM |
|---|---|---|
| 4 vCPU * | 4 vCPU * | 8 vCPU * |
| 32 GB of RAM | 32 GB RAM | 64 GB RAM |
| 80 GB for the operating system** | 80 GB for storage Operating System** | 80 GB for storage Operating System** |
| 256 GB for data volume** | 256 GB for Data Volume** | 500 GB for Data Volume** |
* data center CPU (not consumer CPU), newer than 2016 generation, not having any vulnerability listed in the CVE database unless the vendor-supplied mitigation has been applied minimum 650 points for a Single Core Benchmark and 1300 points for a MultiCore Benchmark based on the geekbench 6 test/scoring (1)
** Minimum 2250 IOPs for reading and 750 IOPs for write operations based on the following command (2):
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
The host for the Pilot Environment must be hosted on a different physical host and network than the hosts provisioned for the Pre-Production and Production Environments.
Network
Each host must have a public IP address and must be connected to the Internet to get updated and communicate with other EBSI Nodes. The minimum specifications are:
- 3 fixed public IPs v4 (one for each environment),
- 100 Mbits/second for bandwidth (Internet),
- maximum latency 100ms (Internet),
- 1 GB Ethernet (local network).
EBSI VM Deliverables
EBSI provides two options for node operators:
- OVA image for Vmware ESX (minimum ESX 6.7)
- qcow2 images for qemu/KVM based systems (Ovirt, ect)
The VM images are pre-configured with all the needed software stack to easily bootstrap the node.
Firewall Requirements
Each virtual machine (EBSI Node) must be protected by an external/perimetral/datacenter firewall.
All the traffic will go through the Firewall. The configuration of the firewall will be presented in the node installation guide.
Hosting requirements
Security (only for PreProd and Prod Environments)
A Node Operator is responsible for Node's security compliance. Node Operators hosting PreProd and Prod nodes must provide evidence of a valid ISO 27001 certification or an equivalent national or regional standard approved by the EDIC Member Country where the Node Operator is located. The certification requirement does not apply to the hosted Pilot environment.
In PreProd and Prod, Node Operator must protect their nodes against Distributed Denial of Service attacks and must apply a Web Application Firewall to protect the nodes.
Domains
A domain must always start with the sub-domain parts of "convention" and must not have any extra path variables as a suffix, thus it should follow the template of "convention". The domain name cannot contain any words which can be considered rude or have any negative impact
The nodes will expose APIs documented in the EBSI API Catalog, where the paths will start immediately after the selected domain. A single node must have a single domain name, and multiple nodes can operate under multiple sub-domains, multiple domains, or in a combination of these.
Node Operators must own and be able to control the domain name(s) and the associated TLS certificates (minimum TLS v1.2). The TLS Certificates must be maintained and kept up to date by the Node Operator. Considering there are multiple subdomains, a Wildcard certificate is recommended.
Naming convention for the domains
| Pilot | Pre-Production | Production |
|---|---|---|
api-pilot.ebsi.[FREELY_CHOSEN.DOMAIN.TLD] | api-preprod.ebsi.[FREELY_CHOSEN.DOMAIN.TLD] | api.ebsi.[FREELY_CHOSEN.DOMAIN.TLD] |
In case you host multiple nodes in one environment:
- You will have to set a different domain for each node so that you will have different domains or subdomains for
[FREELY_CHOSEN.DOMAIN.TLD].
Examples:
- https://api-preprod.ebsi.node1.nask.pl and https://api-preprod.ebsi.node2.nask.pl
- https://api-preprod.ebsi.uefiscdi.ro and https://api-preprod.ebsi.uefiscdi.gov.ro
- Do not use a load balancer for your nodes (do not balance the load between your nodes)
Only for nodes that are voluntarily hosting the block explorer
| Pilot | Pre-Production | Production |
|---|---|---|
blockexplorer-pilot.ebsi.[FREELY_CHOSEN.DOMAIN.TLD] | blockexplorer-preprod.ebsi.[FREELY_CHOSEN.DOMAIN.TLD] | blockexplorer.ebsi.[FREELY_CHOSEN.DOMAIN.TLD] |
Recommendations
Node Operators should monitor the used CPU, disk space, memory, and network bandwidth and scale the resources if needed.
In the case of a node operator hosting multiple nodes, the Node Operator should consider re-routing traffic to other nodes upon disaster events.
This document will be updated often to reflect the new changes and the technology updates. We recommend that the Node Operators check periodically this document.
The Infrastructure Architecture and Setup Guidelines (ONLY for PreProd and Prod Environments)
The general architecture of how all the resources/appliances are connecting and interacting between them is presented in the discussion documents that will be shared only with the onboarded nodes.
(1) Ref: CPU benchmark: https://www.geekbench.com/
(2) Ref: Besu client requirements: https://lf-hyperledger.atlassian.net/wiki/spaces/BESU/pages/22156583/2024+-+Besu+Performance+Improvements+since+the+Merge