Skip to content

25.10.5

Simplyblock is happy to release the general availability release of Simplyblock 25.10.5.

New Features

  • Storage Plane: Storage nodes and storage clients (via the nvme connect command) can now be force-bound to a specific network interface on their host.
  • Control Plane: The requirement for a route between the control plane nodes and storage plane nodes on the data network interface has been removed.
  • Control Plane: The simplyblock cluster can now be configured with variable port ranges to allow for mitigation of port collisions on specific environments (mostly hyperconverged).
  • Control Plane: The activation speed of large clusters and storage nodes has been improved by parallelizing internal state creation.
  • Control Plane: The restart performance of large clusters has been improved by parallelizing reconnection to other storage nodes.
  • Kubernetes: The CSI driver now automatically reconnects lost NVMe-oF connections on a multipathed logical volume as long as there is at least one healthy connection remaining.
  • Kubernetes: The Kubernetes-based deployment now supports Kubernetes topology management.

Fixes

  • Control Plane: Fixed an issue where a new device on a storage node would disappear immediately after being added (new state)..
  • Control Plane: Fixed multiple issues related to journaling and placement which could cause node-affinity issues, I/O interruptions, device formating issues on 2+2 clusters after multiple 2-node outages in a row.
  • Control Plane: Fixed an issue where multiple outages in a row could cause I/O interruptions.
  • Control Plane: Fixed an issue where deleting a snapshot failed when the logical volumes' primary storage node had an outage.
  • Control Plane: Fixed an issue where DPDK would fail to initialize in rare cases.
  • Control Plane: Fixed an issue where deleting a logical volume failed when the logical volume's secondary storage node was in down state.
  • Control Plane: Fixed an issue where the --force option would not work for the device removal.
  • Control Plane: Fixed an issue where the get-io-stats command would return the same record for all rows.

Upgrade Considerations

It is possible to upgrade from 25.10.4 and 25.10.4.2.

Known Issues

  • At the moment, we see unnecessary retries of data migration while a storage node is down in m+2 schemas (2+2, 4+2). Data migration should pause once all migratable chunks that haven't been moved yet and resume once all nodes are online. Currently, it retries without success until all nodes are online. Which will be fixed as soon as possible.
  • At the moment, to sustain full fault-tolerance, we require more nodes than the theoretical minimum. This is due to a missing feature in the placement, which will be addressed as soon as possible.
  • At the moment it is only possible to define one erasure coding schema per cluster.

Features to Expect with Next Major Release

  • The ability to use different erasure coding schemas within the same cluster.
  • The ability to replicate snapshots to a foreign (remote) simplyblock cluster.
  • The ability to asynchronously replicate volumes via snapshots in regular intervals and support fail-over in Kubernetes.
  • The integration via a new Simplyblock Kubernetes Operator which uses CRDs to specify, create and track a cluster, storage nodes, volumes and snapshots, and replications.
  • A significant performance optimization during node outages (journal writes).
  • The integration of cluster-internal multi-pathing for both RDMA- and TCP-based NVMe connections.
  • The ability to send snapshot backups to remote S3-compatible storage.
  • The ability to support multiple NVMe-oF failover connections with one primary and two secondary storage nodes for higher availability.