The storage is not located next to the cluster, but inside it: the local NVMe of all nodes form a shared pool. This saves the external datastore — and it ties the capacity to the number of nodes. How much of the raw capacity is usable is therefore not decided by the price, but by the size of the cluster.
The entry price is a node price, not a cluster price. PC-S32 is not approved: the class has no separate storage fabric — no dedicated network just for storage traffic —, and in a hyperconverged cluster all pool traffic would run over the same line as the guest traffic.
- Per node from
- €1,690.20$1,960.63
- PC-M64 incl. licence, net
- Minimum cluster
- 3 nodes
- €5,070.60$5,881.90 net, storage included
- Usable capacity
- 47% – 76%
- depending on the protection method, 3 to 24 nodes
- Licence
- €13.90$16.12
- per core and month
Four numbers before you read on
The pages on managed vSphere and datastores answer the same four questions in the same place. The second one is different here than there — and it decides how large a cluster must be.
- Cluster size
- 3 – 24 nodes
- Hyperconverged means: each node computes and stores simultaneously. Under 3 nodes, there is no majority after a failure to decide which copy of a block is valid.
- Usable after mirroring
- 47% – 76%
- Mirroring means: each block is located on two nodes. With 3 nodes, therefore, around half of the raw capacity remains. Only from 6 nodes does erasure coding replace it — a method that stores only parity blocks instead of full copies — and the share increases to 62%.
- Licence per core and month
- €13.90$16.12
- €4.00$4.64 per core more than under vSphere, already included in the price per node from €1,690.20$1,960.63. In return, the storage is included — an external datastore is not required. Minimum purchase 16 cores per socket.
- Who patches
- ENTRONYX CLOUD
- Hypervisor, BIOS and firmware, fabric switches, storage controllers — included in the node price. Guest operating system and application remain with you.
The storage pool is created from the local NVMe of all nodes — the flash drives plugged directly into the node. What remains for guest data is determined not by price, but by the protection method. Which one applies depends on the number of nodes.
Below 6 nodes, the pool runs two-way mirrored: every block is written twice, meaning half the raw capacity is allocated before a single guest byte is stored. An additional 3.0% goes to metadata and the reserve used to rewrite data after a node failure — leaving 47% usable.
From 6 nodes, erasure coding applies. Instead of a full copy, there are only 2 parity blocks alongside 4 data blocks. This is the most valuable jump on this page: double the number of nodes, 2.64 times the usable capacity. Every further step brings less — from 18 nodes onwards, it is only 5 percentage points.
The tiers are seamless: every permitted cluster size between 3 and 24 nodes falls into exactly one protection method. There is no size where you have to check what applies first.
In numbers for the entry-level class: a cluster of 3 × PC-M64 provides 11.52 TB raw and 5.41 TB usable. The same cluster with 6 nodes reaches 14.28 TB.
Hyperconverged
47% to 76% · baseline at zero
How much raw capacity remains usable
- Two-way mirroring (RF2) — usable 47%, one host failure
- Erasure coding — usable 62% to 76%, two host failures
- Not usable — Parity or mirror, metadata, recovery reserve
The full column height is the raw capacity of all local NVMe in the cluster. The capacity jumps, it does not grow: there is no intermediate value between two steps, hence rectangles and not a line. The gain at each edge becomes smaller — from 3 to 6 hosts it is 15 percentage points, from 12 to 18 only 5. From then on, expansion is worthwhile for computing power, no longer for storage.
Usable share of raw capacity per cluster size. The gain is given in percentage points compared to the level below, not as a relative increase.
| Protection method | Hosts | Usable | Not usable | Gain | Tolerated host failures |
|---|---|---|---|---|---|
| Two-way mirroring (RF2)selected | 3–5 | 47% | 53% | Base level | 1 |
| Erasure coding 4+2 | 6–11 | 62% | 38% | +15 percentage points | 2 |
| Erasure coding 6+2 | 12–17 | 71% | 29% | +9 percentage points | 2 |
| Erasure coding 8+2 | 18–24 | 76% | 24% | +5 percentage points | 2 |
Note per level
- Two-way mirroring (RF2)
- Every block resides on two hosts. Raw 50%, minus 3% metadata and recovery reserve.
- Erasure coding 4+2
- Stripes of 4 data blocks and 2 parities. Recovery after a host failure takes up to 6 hours at full capacity.
- Erasure coding 6+2
- Wider stripes reduce the parity overhead, but increase the number of hosts involved in every read operation.
- Erasure coding 8+2
- Upper limit of stripe width. Further widening would increase the recovery load beyond an acceptable level.
How the usable share is calculated
The raw share follows solely from the stripe geometry: data blocks divided by data blocks plus redundancy. What is deducted after that is the reserve for metadata and for the space to rewrite to after a node failure. Both values are small and both are unavoidable.
- Two-way mirroring (RF2)1 node failure
- Nodes
- 3–5
- Stripe (blocks)
- 1+1 (2)
- Raw
- 50.0%
- Reserve
- − 3.0%
- Usable
- 47%
- Raw capacity
- 11.52 TB
- Usable capacity
- 5.41 TB
- Erasure coding 4+22 node failures
- Nodes
- 6–11
- Stripe (blocks)
- 4+2 (6)
- Raw
- 66.7%
- Reserve
- − 4.7%
- Usable
- 62%
- Raw capacity
- 23.04 TB
- Usable capacity
- 14.28 TB
- Erasure coding 6+22 node failures
- Nodes
- 12–17
- Stripe (blocks)
- 6+2 (8)
- Raw
- 75.0%
- Reserve
- − 4.0%
- Usable
- 71%
- Raw capacity
- 46.08 TB
- Usable capacity
- 32.72 TB
- Erasure coding 8+22 node failures
- Nodes
- 18–24
- Stripe (blocks)
- 8+2 (10)
- Raw
- 80.0%
- Reserve
- − 4.0%
- Usable
- 76%
- Raw capacity
- 69.12 TB
- Usable capacity
- 52.53 TB
The two right columns apply to PC-M64 with 3.84 TB local NVMe per node, calculated at the lower limit of the respective tier. Within a tier, the capacity continues to grow with each node — the usable share remains the same until the next tier applies.
The licence surcharge is the price of the storage
The price of a managed node is the bare metal plus platform operations. The cluster licence is added per core and month — and with it the entire primary storage, for which a separate datastore is purchased under vSphere.
The licence costs €13.90$16.12 per core and month, with a minimum purchase of 16 cores per socket. On PC-M64, that is 48 cores and thus €667.20$773.95 per node and month. The minimum purchase does not apply to any released class today — the smallest comes with 48 cores per socket.
Compared to vSphere, that is €4.00$4.64 more per core, so €576.00$668.16 a month in the minimum cluster. In return, an entire item is omitted: the shared datastore. The 5.41 TB that a cluster of 3 × PC-M64 makes usable costs €389.81$452.18 a month calculated as Datastore NVMe Standard.
The minimum cluster comprises 3 nodes, not two. A pool of two nodes cannot decide which half is allowed to continue writing after a network split — both would see themselves as the survivor. Only the third node establishes the majority. At the upper end, the cluster is limited to 24 nodes.
The local NVMe is included in the bare metal price in both cases. The difference is not that hyperconvergence buys it in addition, but that it is interconnected into a shared pool instead of remaining as the storage of the individual node.
- Distributed storage pool across the local NVMe of all hosts
- Data locality: the active block resides on the VM's host
- Erasure coding or mirroring depending on cluster size
- Inline deduplication and compression, can be disabled per container
Minimum cluster, item by item
3 × PC-M64 — the smallest configuration in which the pool can form a quorum, i.e. a majority that decides after a failure. A datastore is not on the list because the storage is located in the nodes.
- 3 × node PC-M64
- €3,069.00$3,560.04
- 3 × licence, 48 cores each
- €2,001.60$2,321.86
- Platform operations
- in the node price
- Primary storage, 5.41 TB usable
- included in the cluster
- Net total per month
- €5,070.60$5,881.90
- Gross per monthincl. 19% VAT.
- €6,034.01$6,999.46
The same cluster under vSphere
3 × PC-M64, same number of nodes, same usable capacity — here via a booked Datastore NVMe Standard of 5.3 TB.
- 3 × node PC-M64
- €3,069.00$3,560.04
- 3 × licence, €475.20$551.23 each
- €1,425.60$1,653.70
- Datastore NVMe Standard, 5.3 TB
- €389.81$452.18
- Net total per month
- €4,884.41$5,665.92
- Difference from hyperconvergence
- − -€186.19-$215.98
The calculation applies to this one capacity. It tips as soon as the storage requirement grows faster than the computing requirement: the datastore can be expanded individually, the pool only via additional nodes.
HCI cluster versus cluster with external storage
Both stacks run on the same node classes. The difference lies in where the primary storage is located — and almost everything else follows from this: the minimum size, the maintenance duration, the recovery levels and the question of whether capacity can grow individually.
| Feature | ENTRONYX HCIStorage in the cluster | ENTRONYX Managed vSphereStorage in the external datastore |
|---|---|---|
| Location of primary storage | Local NVMe of all nodes, combined into a pool | External datastore, booked separately |
| Licence rate | €13.90$16.12 | €9.90$11.48 |
| Licence per PC-M641 sockets, 48 cores | €667.20$773.95 | €475.20$551.23 |
| Cluster from … to | 3 – 24 nodes | 2 – 32 hosts |
| Approved classes | 4 | 4 |
| External datastore required for operationswithout it, nothing restarts automatically under vSphere | ||
| Protection method follows cluster sizeMirroring or erasure coding, depending on the number of nodes | ||
| Capacity expandable independently of the number of nodes | ||
| Synchronous Metro mirroring bookableRPO 0 minutes | ||
| Management plane | Web console in the cluster, REST API v3, Prometheus endpoint | Dedicated vCenter per customer, API access, SSO against your directory |
| Maintenance windows | Tue 02:00–06:00 CET, rolling with data redistribution before each restart | Wed 02:00–06:00 CET, rolling host by host, announcement 14 days in advance |
- Location of primary storage
- ENTRONYX HCI
- Local NVMe of all nodes, combined into a pool
- ENTRONYX Managed vSphere
- External datastore, booked separately
- Licence rate
- ENTRONYX HCI
- €13.90$16.12
- ENTRONYX Managed vSphere
- €9.90$11.48
- Licence per PC-M641 sockets, 48 cores
- ENTRONYX HCI
- €667.20$773.95
- ENTRONYX Managed vSphere
- €475.20$551.23
- Cluster from … to
- ENTRONYX HCI
- 3 – 24 nodes
- ENTRONYX Managed vSphere
- 2 – 32 hosts
- Approved classes
- ENTRONYX HCI
- 4
- ENTRONYX Managed vSphere
- 4
- External datastore required for operationswithout it, nothing restarts automatically under vSphere
- ENTRONYX HCI
- ENTRONYX Managed vSphere
- Protection method follows cluster sizeMirroring or erasure coding, depending on the number of nodes
- ENTRONYX HCI
- ENTRONYX Managed vSphere
- Capacity expandable independently of the number of nodes
- ENTRONYX HCI
- ENTRONYX Managed vSphere
- Synchronous Metro mirroring bookableRPO 0 minutes
- ENTRONYX HCI
- ENTRONYX Managed vSphere
- Management plane
- ENTRONYX HCI
- Web console in the cluster, REST API v3, Prometheus endpoint
- ENTRONYX Managed vSphere
- Dedicated vCenter per customer, API access, SSO against your directory
- Maintenance windows
- ENTRONYX HCI
- Tue 02:00–06:00 CET, rolling with data redistribution before each restart
- ENTRONYX Managed vSphere
- Wed 02:00–06:00 CET, rolling host by host, announcement 14 days in advance
Where this setup is the right fit
One environment instead of two procurements
Computing power and storage come from the same order, grow at the same pace and are managed in the same console. If you do not have a storage department, you do not just save money here, but an entire operations discipline.
Uniform guest workloads in large numbers
Virtual workspaces, application servers, test environments: many guests with a similar profile are distributed cleanly across the nodes and keep data locality high. The pool then works predominantly locally.
Expansion in equal steps
An additional node brings cores, memory and capacity in a fixed ratio. This is a limitation and at the same time the reason why capacity planning here is a number instead of a table.
Where hyperconvergence is the wrong fit
Cross-checkIf storage and computing power grow at different speeds, each expansion pays for the other half as well. If you need a lot of capacity with little computing power — file services, archives, media inventories —, you are better off with dedicated hosts and a separate datastore.
Each node provides compute, memory and local NVMe in a fixed ratio. This is the condition of the design: if you need capacity, you choose either a denser class or more nodes — there is no third option.
- PC-M64PC-M
- Processor
- EPYC 9454P2.75 – 3.80 GHz · 1 sockets
- Cores / threads
- 48 / 96
- Allocatable RAM
- 232 GB
- NVMe per node
- 3.84 TB
- Connection
- 1 Gbit/s
- Usable with 3 nodes
- 5.41 TB
- Licence / month
- €667.20$773.95
- Total / month
- €1,690.20$1,960.63
- PC-M64iPC-M
- Processor
- Xeon 6741P2.50 – 3.80 GHz · 1 sockets
- Cores / threads
- 48 / 96
- Allocatable RAM
- 232 GB
- NVMe per node
- 7.68 TB
- Connection
- 1 Gbit/s
- Usable with 3 nodes
- 10.83 TB
- Licence / month
- €667.20$773.95
- Total / month
- €1,760.20$2,041.83
- PC-L128PC-L
- Processor
- EPYC 95543.10 – 3.75 GHz · 1 sockets
- Cores / threads
- 64 / 128
- Allocatable RAM
- 472 GB
- NVMe per node
- 7.68 TB
- Connection
- 5 Gbit/s
- Usable with 3 nodes
- 10.83 TB
- Licence / month
- €889.60$1,031.94
- Total / month
- €2,788.25$3,234.37
- PC-X256PC-X
- Processor
- 2× EPYC 99652.25 – 3.70 GHz · 2 sockets
- Cores / threads
- 384 / 768
- Allocatable RAM
- 960 GB
- NVMe per node
- 3.84 TB
- Connection
- 5 Gbit/s
- Usable with 3 nodes
- 5.41 TB
- Licence / month
- €5,337.60$6,191.62
- Total / month
- €11,130.78$12,911.70
The “Usable” column calculates with the method that applies in the minimum cluster: Two-way mirroring (RF2). If you deploy the same node 6 times, you get 14.28 TB instead of 5.41 TB with PC-M64. The route via the denser class leads to the same goal: PC-L128 carries 7.68 TB per node and thus twice as much as the entry-level class.
vCPU limit per class
- PC-M64
- 288 vCPU · 6:1
- PC-M64i
- 288 vCPU · 6:1
- PC-L128
- 256 vCPU · 4:1
- PC-X256
- 1.536 vCPU · 4:1
Allocatable, not recommended. In the cluster, a second reserve is added: the guests of a failed node must fit into the remaining space, and the pool needs compute time on the same nodes during recovery.
Largest permitted cluster
- Nodes
- 24
- Node class
- PC-X256
- allocatable vCPU
- 36,864
- Memory allocatable
- 22.5 TB
- Usable capacity
- 70.04 TB
- Calculated guests
- 15,360
The usable capacity calculates with the broadest protection method provided in the catalogue. Larger clusters are not created by more nodes, but by multiple clusters side by side.
What restricts each class in the cluster
A class without a stated limit is a class whose limit no one has looked for yet. Here it stands for each of the 4.
PC-M64
PC-MOne socket, one NUMA node: VMs over 232 GB RAM no longer fit on this class. For wider single VMs, PC-L128 or PC-X256 is the right fit.
PC-M64i
PC-MLive migration is only guaranteed between hosts of the same CPU generation. A mixed cluster of PC-M64 (AMD) and PC-M64i (Intel) does not migrate during operations.
PC-L128
PC-LThe boost ends at 3.75 GHz — the class wins on width, not on clock speed. Loads that depend on single threads run faster on PC-S32 with 5.7 GHz.
PC-X256
PC-XTwo sockets mean two NUMA nodes. VMs over 480 GB RAM or over 192 vCPU exceed one node and lose around 12% memory bandwidth — with licences per core, this host also pays for 384 cores.
PC-S32
Not approved3 Gbit uplink without a separate storage fabric. Shared NFS or iSCSI datastores are not permitted on this class so that replication and guest traffic do not share the same line. Without a shared datastore, there is no automatic HA restart.
Locations for the entry level
A cluster is located entirely at one location — the pool needs runtimes in the range of a few microseconds between its nodes. Distribution across two regions is only created via the recovery levels, not via the cluster itself. PC-M64 is available at 4 locations, PC-X256 at 3.
Available for PC-M64 4
Reads are local, writes are across the network
The pool is not located next to the nodes, but inside them. This makes reads short and writes a matter of the network — and it explains why the connectivity of a class is a prerequisite here, not an equipment option.
The number of involved nodes grows with the stripe width. With Two-way mirroring (RF2), a write operation touches 2 nodes, with Erasure coding 8+2 it is 10. This is exactly the trade-off behind the better usable capacity: Wider stripes save capacity and cost network paths. Reads remain unaffected by this — they hit the local block.
That is why the connectivity of the node class is not a side note. PC-M64 comes with 1 Gbit/s, PC-X256 with 5 Gbit/s — and both carry guest traffic, storage traffic and, after a failure, recovery on it simultaneously.
Data locality on read
The active block of a VM resides on the node where the VM is running. A read operation thus stays within the device and does not need the network. If the VM migrates to another node, its blocks follow in the background — until then, it reads over the network and is therefore slower.
- Read path
- local NVMe, no network path
- After a migration
- blocks follow, reading remains remote in the meantime
- Cold start of a VM
- initial reads remote until the copy is ready
- Visible in
- Prometheus endpoint of the cluster, metric per container
The write path always goes over the network
A write operation is only considered acknowledged when redundancy is established. With two-way mirroring, this is a partner node; with erasure coding, it is all nodes of a stripe. This is exactly where the higher usable capacity is paid for: not in euros, but in network paths per write operation.
- Mirroring
- one copy on a partner node
- Erasure coding
- data blocks and parity across the entire stripe
- Acknowledgement
- only after full redundancy, never before
- Consequence
- small write operations cost proportionally more than large ones
Deduplication and compression before writing
Both run inline, i.e. before storing, and both cost compute time on the same node that serves the guests. Therefore, it can be disabled per container: for databases that already write compressed data, the gain is zero and the overhead is not zero.
- Point of effect
- before writing, not as a downstream run
- Costs
- compute time on the node that also serves guests
- Can be disabled
- per container, not just for the entire cluster
- Sensible to disable
- for already compressed or encrypted data
One network for two types of traffic
Guest traffic and storage traffic share the node's connection. This is the actual condition of the design: if you bring the storage into the compute node, you also bring its traffic there. Classes without sufficient connection are therefore not approved — not as a precaution, but because the commitment could otherwise not be kept.
- Separation
- separate VLANs for guest, management and storage traffic
- Priority
- storage traffic takes precedence, otherwise the acknowledgement breaks off
- Recovery
- runs over the same network as ongoing operations
- Observability
- throughput per traffic type at the Prometheus endpoint
In a cluster, availability is not a property of a node, but a property of the group. What it can withstand is defined by the scaling tier — and what it can still withstand during a maintenance window follows from that by subtraction.
What happens after the loss of a node
- 1
Detect failure
under 30 secondsThe remaining nodes lose the heartbeat of the failed one and form a new quorum. Until that is established, nothing is switched over — a briefly disrupted network initially looks like a dead node, and a premature restart of duplicate running guests would be the more expensive mistake.
- 2
Restart guests
1 to 5 minutes per guestThe guests of the failed node restart on the remaining ones. Their data is fully available — it resides in the redundancy of the pool, not on the lost device. The restart is a cold start, not a migration: whatever was in the memory is lost.
- 3
Read remotely instead of locally
Until data locality is restored, the newly started guests read over the network. The cluster is fully usable during this time, but slower — and this is the most visible part of a node failure, not the restart itself.
- 4
Restore redundancy
The missing blocks are reconstructed from the remaining ones and distributed across the other nodes. Only then can the cluster fully tolerate the next failure again. The run does not need a replacement node — it needs free space on the existing ones.
- 5
Add replacement node
in the next maintenance windowThe replaced node joins the pool and takes over its share. This is no longer an emergency step, but a redistribution during operations — the cluster is already fully redundant again at this point.
How long recovery takes
Three factors determine the duration: what the failed node carried, how often each existing block must be read to replace a lost one, and how many nodes share the work. With Two-way mirroring (RF2), the read amplification is 1 — there is exactly one copy. With Erasure coding 8+2, it is 8 blocks per reconstructed block.
A recovery run takes up around 28% of the node connection; the remaining 72% are left for ongoing operations. This share is not fixed, but calculated backwards from the one value the catalogue states: 6 hours for a PC-M64 with 6 nodes and full utilisation.
- Two-way mirroring (RF2)Stripe 1+1
- Nodes
- 3–5
- Read amplification
- 1 : 1
- Network load
- 7.68 TB
- Duration with fewest nodes
- 3 h
- Duration with most nodes
- 1.5 h
- Erasure coding 4+2Stripe 4+2
- Nodes
- 6–11
- Read amplification
- 4 : 1
- Network load
- 19.2 TB
- Duration with fewest nodes
- 3 h
- Duration with most nodes
- 1.5 h
- Erasure coding 6+2Stripe 6+2
- Nodes
- 12–17
- Read amplification
- 6 : 1
- Network load
- 26.88 TB
- Duration with fewest nodes
- 1.9 h
- Duration with most nodes
- 1.3 h
- Erasure coding 8+2Stripe 8+2
- Nodes
- 18–24
- Read amplification
- 8 : 1
- Network load
- 34.56 TB
- Duration with fewest nodes
- 1.6 h
- Duration with most nodes
- 1.2 h
The network load is reading and writing combined — which is why it shows a multiple of the 3.84 TB that the node itself carried. Wider stripes do not prolong the run: they distribute it across more nodes, and the two largely cancel each other out. What really prolongs it is a more densely populated class — the worst case in the catalogue is 3.2 h.
A rolling maintenance window, step by step
The window is in the catalogue: Tue 02:00–06:00 CET, rolling with data redistribution before each restart. The difference to a cluster with external storage lies in the third step — before a node restarts, the pool must be rebalanced.
Announcement
10 calendar days in advance
The window, scope and sequence of the nodes are fixed in advance. A window without changes to your cluster will be cancelled, not silently run through empty.
Evacuate guests
5 to 25 minutes per node
The running VMs migrate to the remaining nodes. Up to this point, the process does not differ from a cluster with an external datastore.
Redistribute data
20 minutes to several hours per node
This step only exists here: before a node restarts, the pool is rearranged so that no redundancy level depends solely on it. The duration depends on the node's usage, not on the number of guests.
Firmware and cluster software
20 to 40 minutes per node
BIOS, storage controllers, network cards and the cluster software are updated to the target version. After that, the node restarts and rejoins the pool.
Catch up, then the next one
rolling
The returned node catches up on what was written during its absence. Only when the pool is fully redundant again does the next node begin. That is why the window length grows with the cluster size — and why the cluster remains usable throughout.
Recovery per node class
Loss of a node in the smallest erasure coding cluster — the worst case of this tier. The duration increases with the population, not with the price: PC-X256 carries 3.84 TB per node.
- PC-M64
- 3 h · 10 Gbit/s
- PC-M64i
- 6 h · 10 Gbit/s
- PC-L128
- 6 h · 10 Gbit/s
- PC-X256
- 1.2 h · 25 Gbit/s
The storage fabric is listed next to it because it significantly determines the duration: two classes with the same population but different fabric take different amounts of time.
Tolerance during maintenance
- 3 to 5 nodes
- 1 outage · 0 in maintenance
- from 6 nodes
- 2 outages · 1 in maintenance
- Free nodes per stripe
- 1 to 8
- Maximum size
- 24 nodes
The right number in the first two rows is the remaining failure tolerance while a node is scheduled out of operation — the tolerance of the tier minus one.
Expansion across a tier boundary
An additional node initially only brings cores, memory and raw capacity. The usable share only changes when the cluster size crosses a tier boundary — and then it changes for the entire existing written data.
The pool recodes the existing data in the background for this. This is a data movement across the cluster network, not a switchover: it is throttled, it runs alongside operations, and the new usable capacity is only available once it is complete. If you are planning the step from 5 to 6 nodes, you are therefore not only planning the delivery, but also the recoding.
Upper limit of stripe width. Further widening would increase the recovery load beyond an acceptable level.
No external primary storage, but a way out
The fast datastore classes cannot be booked under hyperconvergence — not by mistake, but because the primary storage is already in the cluster. What is added externally is capacity for cold data and replication to a second region.
Datastore Capacity
iSCSINFS 4.1NVMe cache in front of HDD capacity — for file services and quiet volumes.
- Price per GB and month
- €0.0290$0.0336
- Snapshots per GB per month
- €0.0060$0.0070
- Minimum and maximum quantity
- 8 TB – 512 TB
- Redundancy
- Erasure coding 8+2 in the location, cache triply mirrored
- Backup window
- Daily 21:00–06:00 CET, crash-consistent
Restriction: The NVMe cache covers 8% of the datastore size. Working sets beyond this pass through to the HDD tier; the 4 ms latency guarantee then no longer applies.
Datastore Archive
NFS 4.1Cold capacity for powered-off guests, templates and exports.
- Price per GB and month
- €0.0068$0.0079
- Snapshots per GB per month
- €0.0009$0.0010
- Minimum and maximum quantity
- 20 TB – 2048 TB
- Redundancy
- Erasure coding 8+2, second copy in another EU region
- Backup window
- Weekly Sat 20:00–08:00 CET
Restriction: Not approved as an operational datastore. Running VMs must not reside here — the class accommodates powered-off guests, templates and OVA exports.
Recovery to a second region
The pool's protection mechanism covers the failure of nodes, not the failure of the location. There are 3 tiers available for this. The example total calculates with 5.3 TB of protected capacity — the usable capacity of the minimum cluster.
- Secured recoverySocket €149.00$172.84
- RPO · maximum data loss
- 24 h
- RTO · maximum recovery time
- 8 h
- Replication interval
- 24 h
- Tests / year
- 1
- Target region
- Region in the EU, from 300 km
- per GB and month
- €0.0074$0.0086
- Example total
- €189.06$219.31
- Pilot LightSocket €490.00$568.40
- RPO · maximum data loss
- 4 h
- RTO · maximum recovery time
- 4 h
- Replication interval
- 4 h
- Tests / year
- 2
- Target region
- Region in the same country, from 200 km
- per GB and month
- €0.0190$0.0220
- Example total
- €592.87$687.73
- Asynchronous replicationSocket €990.00$1,148.40
- RPO · maximum data loss
- 15 min
- RTO · maximum recovery time
- 2 h
- Replication interval
- 15 min
- Tests / year
- 4
- Target region
- Region in the same country, from 200 km
- per GB and month
- €0.0340$0.0394
- Example total
- €1,174.08$1,361.93
- Secured recovery
- The restart uses free capacity in the target region. Without booked capacity reservation, the RTO commitment only applies Mon–Fri 08:00–18:00; outside this time, there is no guaranteed restart time.
- Pilot Light
- A single host runs in the target region with around 25% of the productive capacity. Full throughput is only available after adding more hosts — lead time up to 90 minutes.
- Asynchronous replication
- The RPO of 15 minutes applies up to a change rate of 40 MB/s per datastore. Above this, the replication lag grows, and the actual recovery point is further back than committed.
Read more
- Disaster recovery — replication topology, recovery test and the complete cost model of all tiers.
- Managed dedicated hosts — where the boundary between platform and guest operations lies and what the tiers above it cost.
- Security and certificates — tenant separation, certificates and the audit documents for the Private Cloud.
Who patches what
Platform operations are included in the node price and cannot be deselected. They end at a strict boundary: we work below the guest system, you work above it.
ENTRONYX CLOUD patches
- Hypervisor
- BIOS and firmware
- Fabric switches
- Storage controllers
Firmware maintenance requires a host evacuation. Without a second host in the cluster, this means downtime of up to 45 minutes per maintenance window.
You patch
- Guest operating system
- Middleware
- Application
- Application data
If you also want to hand over the guest system, book a higher operations level. The boundaries of the levels are on the managed hosts page.
If a node fails unexpectedly, the cluster restores the lost redundancy itself. In the smallest cluster, this takes 3 h. As long as this is running, the cluster cannot sustain a second failure: the mirroring can handle 1 missing node, not two.
Tailor cluster, check capacity
Node class, quantity, supplementary storage, recovery level and operations level are side by side in the configurator. The total is calculated using the same rates as this page — and the usable capacity is tracked, because it changes with every number of nodes.
- Per node from
- €1,690.20$1,960.63
- Minimum cluster
- €5,070.60$5,881.90
- Usable out of the box
- 5.41 TB
- Nodes per cluster
- 3 – 24