10 min read

Learning Objectives

By the end of this module, you will be able to:

  • Distinguish single-VM Block Storage from managed shared file access, and choose between them on access pattern rather than capacity
  • Match a storage tier to its workload, and reason about the storage-zone-versus-compute-zone asymmetry as a placement constraint
  • Provision a Network File Storage cluster and a share in the Data Center Designer and mount it from multiple Linux clients
  • Recognise where shared file storage stops (regional, private, Linux-only) and where Object Storage takes over

Unit 5.1: Block and File Storage

Introduction

The data tier begins with a decision that is easy to get wrong: who needs to read and write the same bytes. A Block Storage volume is a private disk that belongs to exactly one server at a time; it is the right answer for a boot disk or a single application's data, and unit 4.2 already covered attaching one. The moment two or more machines must see the same files at once, that model breaks, and the platform offers a separate managed product, Network File Storage, instead of any shared-block trick. This unit draws that line, surfaces a placement asymmetry that catches architects out, and then builds the shared file share that FinCorp's application tier needs.

1. Single-VM Block Storage Versus Managed Shared File Access

Block Storage presents an iSCSI block device to one virtual machine. You attach it, the guest OS formats it, and it behaves as a local disk. That disk is bound to its server: it is not a concurrent-access medium, and it does not move bytes between machines. For a single application's persistent data this is exactly what you want, and it is where most of the data tier's capacity lives.

Network File Storage solves the different problem of one filesystem mounted by many clients at once. It is a managed product: IONOS runs a cluster of two storage servers in an active-passive high-availability arrangement at the service layer, exports the data over NFSv4.2, and you mount it from your VMs. The clients see a shared POSIX filesystem; the durability, the failover between the two servers, and the underlying ZFS filesystem are operated for you. NFSv3 is not supported, so plan for NFSv4.2 clients only.

The two products also differ in performance delivery. Network File Storage is built on the Block Storage SSD Standard performance class, so a share inherits SSD-class behaviour, but its write path is gated by synchronous write latency of around 20 ms. Reaching high aggregate write IOPS therefore needs many concurrent writers, and a single mount's default NFS client RPC slot table (typically 64 to 128) can become the ceiling before the storage does. The documented guidance is explicit that it is not suitable for synchronous write workloads with tight timeout requirements. Read it as shared-file storage for assets, home directories, logs, and backup landing zones, not as a low-latency transactional disk. One more structural fact matters at design time: a cluster's size is chosen in TiB with a slider, the minimum is 2 TiB, the maximum is 42 TiB, and the size cannot be decreased after provisioning, so it is a one-way ratchet upward.

The following table from the product documentation lists the use cases Network File Storage is built for:

Use case What it covers
Shared configuration files, templates, and static assets across multiple VMs in a VDC One canonical copy instead of per-instance duplication
Media serving / content delivery origin Images, video, and media served without per-instance duplication
Backup target for databases, application data, and VM snapshots A shared landing directory, with encryption at rest
Log aggregation from multiple VMs into a single shared directory Centralised logs from many machines
Kubernetes ReadWriteMany (RWX) persistent volumes Shared volumes for containerised workloads

For FinCorp, the application tier runs several stateless VMs behind a load balancer, and they need one shared directory for uploaded documents and shared templates. That is precisely the first row above: a single share mounted read-write by every application node, rather than a copy of the assets baked into each VM image.

1.1 Regional and Private Scope, and Where Object Storage Takes Over

Network File Storage is regional and private. The cluster is associated with one data center LAN and reachable on a private IPv4 or IPv6 address inside that VDC; there is no public endpoint, and a share does not span regions. Clients mount it over the private LAN, which keeps the traffic off the internet and means data transfer to your VMs is not billed. The trade-off is reach: if FinCorp needs the same data available across regions, or accessible by S3-style tooling, the shared filesystem is the wrong layer. For cross-region shared data, reach for Object Storage instead (unit 5.2), which is the platform's geo-spanning, API-addressable store. Choose Network File Storage when many machines in one region need a live POSIX filesystem; choose Object Storage when reach, scale, or programmatic access dominate.

Access is also Linux-only and controlled per share through client groups. Each client group pairs an IP Networks list (the authorised private networks, in CIDR notation) with a squash mode that maps remote root and users to an anonymous identity. The IP Networks setting always supersedes the Hosts list, and the documentation recommends against the no-squash option for security reasons. This is the file-layer equivalent of the private-by-default posture the rest of the architecture follows.

2. Matching Tier to Access Pattern, and the Zone Asymmetry

The tier decision is driven by the access pattern, not the size. Single-writer persistent disk for one VM is Block Storage. Many-reader, many-writer POSIX filesystem within a region is Network File Storage. Geo-spanning, API-addressable bulk and archive is Object Storage. Within Block Storage, the SSD tiers carry a performance floor worth keeping in mind here because it recurs across the data tier: SSD volumes deliver full per-GiB performance only at 100 GiB and above, so a small SSD volume under-performs its tier. That floor is why undersized SSD volumes are discouraged for demanding workloads, a point unit 5.3 returns to for databases.

There is a placement asymmetry that surprises architects coming from other platforms. Availability zones are not symmetric between compute and Block Storage. A Block Storage volume can be placed in Zone 1, Zone 2, Zone 3, or Auto. Compute, however, only offers Zones 1, 2, and Auto: there is no compute Zone 3. The practical consequence is that you cannot pin a server into a "Zone 3" to match a Zone 3 volume, because no such compute zone exists. When you are deliberately spreading a redundant pair across zones, design around the compute reality of Zones 1 and 2, and do not assume a volume's Zone 3 placement buys you a corresponding compute domain. Treat zone selection as an explicit decision for any redundant pair rather than leaving it on Auto, which can co-locate resources you intended to separate.

DCD Implementation Walkthrough

This walkthrough provisions the shared file storage FinCorp's application tier needs: one Network File Storage cluster on the application LAN, one share, and the mount from multiple Linux clients. It realises the section 1 decision to keep a single canonical copy of shared assets rather than duplicating them per VM. The prerequisite is an existing VDC with a private application LAN (built in unit 3.1) and the Access and Manage Network File Storage privilege on your group; without that privilege a user has read-only access and cannot provision.

Build goal: Provision shared file storage mounted by multiple clients.

Steps (in the Data Center Designer):

  1. In the DCD, open Menu > Storage & Backup > Network File Storage, then select Create Cluster.
  2. Define the cluster properties: enter a Cluster Name; select the Location (the server location where the cluster will live); set the Size in TiB with the slider, remembering the 2 TiB minimum and that size cannot be reduced later; leave File System Version at the default NFSv4.2.
  3. Associate the cluster with a data center: select the Datacenter (the choices depend on the chosen Location) and the Datacenter LAN, which must be the private application LAN. Enter a private IPv4 (or IPv6) address with CIDR for the cluster, using the Finding your Private IP panel on the right to pick a free address that does not collide with your DHCP range.
  4. Click Save. The cluster is created and enters the BUSY state; wait until it becomes AVAILABLE before creating shares.
  5. From the cluster list, select Manage Shares from the OPTIONS column (or open the cluster and use the Manage Shares tab), then select Create Share.
  6. Define share properties: enter a Directory Name; optionally set a Quota in MiB to cap the share (set zero to disable the quota); optionally set the owning Group Id and User Id, both of which default to 65534.
  7. Add a client group: optionally add a Description; choose an NFS Squash Mode (map root to anonymous is the recommended baseline; avoid no-squash); under IP Networks, add the authorised private network in CIDR notation (for example the application LAN subnet) so only those clients can mount.
  8. Click Save to create the share.
  9. On each Linux client, mount the share using the cluster's private IP and the share UUID: mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Every application VM that mounts the same cluster IP and UUID now sees the same files.

Common mistakes:

  • Over-sizing the cluster on day one. Size only ratchets up; you cannot shrink it, so start at the real requirement above the 2 TiB minimum and grow when needed.
  • Leaving the squash mode at None. The documentation recommends against it; map root (or all users) to the anonymous identity instead.
  • Forgetting that IP Networks supersedes the Hosts list. If access is wrong, check the IP Networks CIDR first, because it always wins.
  • Assuming NFSv3 will work. Only NFSv4.2 is supported; older clients fail to mount.
  • Expecting cross-region or public access. The share is private and regional; if you need either, use Object Storage, not a wider NFS export.
  • Trying to mount from Windows. Client support is Linux-only.
  • Choosing Network File Storage for a tight-timeout synchronous-write workload. The ~20 ms synchronous write latency and the per-mount RPC slot ceiling make it unsuitable; that data belongs on a Block Storage volume attached to the single VM that owns it.

Summary

Block Storage is a private, single-VM iSCSI disk; Network File Storage is a managed, regional, private NFSv4.2 filesystem that many Linux clients mount at once; Object Storage is the geo-spanning, API-addressable store. The tier follows the access pattern, not the capacity, and a deliberate zone choice matters because Block Storage offers Zone 3 while compute does not. FinCorp's stateless application tier gets one shared share for its assets, sized for growth and locked down to the application LAN.

Key Points:

  • Block Storage = one VM, private disk (attachment covered in 4.2); Network File Storage = many Linux clients, one regional private filesystem; Object Storage = cross-region, API-addressable.
  • Network File Storage is NFSv4.2 only (no NFSv3), Linux-only, built on the SSD Standard class, with a ~20 ms synchronous-write floor; it is not a low-latency transactional disk.
  • A cluster is sized 2 to 42 TiB and cannot be shrunk after provisioning; access is gated by client groups where the IP Networks list always supersedes the Hosts list.
  • Block Storage availability zones are 1, 2, 3, and Auto; compute zones are only 1, 2, and Auto. There is no compute Zone 3, so set explicit zones for any redundant pair rather than relying on Auto.

Important Terminology:

  • Cluster (Network File Storage): the managed two-server, active-passive unit you provision and size in TiB; it holds one or more shares and attaches to a single data center LAN.
  • Share: an individual exported filesystem within a cluster, with its own quota, owner IDs, and client groups; multiple shares can live in one cluster.
  • Squash mode: the mapping of remote root or all users to an anonymous identity (default UID/GID 65534) that limits what a mounting client can do as a privileged user.