SvHCI/SvSAN Architecture – StorMagic Support

This article is intended for administrators wishing to understand the internal architecture of both SvHCI and SvSAN VSAs.

Audience: AdministratorsProducts: SvHCI • SvSANTopic: Internal VSA ArchitectureIncludes: diagrams • disk layout • logs • partitions

Note: All images are clickable for enlarging, or can be opened in a new tab.

Important: Please ensure the VSA boot and journal disks are never running on SvSAN-presented storage that they themselves are presenting.

SvHCI and SvSAN Internal Architecture

Expand the sections below to review SvSAN and SvHCI architecture diagrams, appliance behavior, boot model, logging, and partition layout.

SvSAN Overview Diagram

SvSAN overview diagram

VSA disk layout on a hypervisor, SvSAN 6.3.x and previous.

VSA disk layout on a hypervisor, SvSAN 6.3.x and previous

SvSAN VSA disk layout

SvHCI Overview Diagram

SvHCI overview diagram

Internal Node Architecture

Both SvSAN and SvHCI have been developed in an appliance model.

Inside the appliance is a standard Linux kernel. For example, KERNEL=Linux 5.15.72 x86_64 in SvHCI 1.3.0.

As such it is not possible to install third party software inside the appliance running the StorMagic built and supported linux distribution we call StorMagic OS.

This closed appliance is tried, tested and supported by StorMagic to ensure operation and security at the Edge for Business Critical environments.

The appliance is modeled as a 'throwaway' appliance, such that a node can be quickly and easily redeployed in the event of server node replacement.

Dual Boot Model

Each appliance exists in a dual boot model:

Dual boot model

As such it is possible to back out and reboot into a prior version:

Reboot into a prior version

Or at boot up:

Boot selection

Each of these two partitions is a read only RAM disk, with persistent storage for logs and change block tracking held in another partition. On SvSAN this is the 20GB journal VMDK, on SvHCI this is a partition on the boot disk.

VSA Storage Placement Warning

When running as a VSA the VM cannot run on storage presented by themselves. Should a VSA be migrated onto storage it is presenting then a feedback loop of I/O will occur and definite issues triggered when VSAs are shut down.

Required: Please ensure the VSA boot and journal disks are never running on SvSAN presented storage, that they themselves are presenting.

Logs

Due to the RAM disk nature of the solution logs that have not yet been written to storage may be lost in the event of a hard power off of a node.

It is therefore recommended to clean shut down the appliance such that all log data is written back safely to disk.

The software also writes logs back to persistent storage in the event of an Error state on the appliance.

Partition Layout

The below is from an SvHCI 1.3 system install to a 512GB m.2 boot device.

Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: SSD 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD2813B3-9683-49B0-911C-3545ED653FC4

Device       Start        End   Sectors   Size Type
/dev/sda1     2048      67583     65536    32M EFI System
/dev/sda2    67584    2164735   2097152     1G Linux filesystem
/dev/sda3  2164736    4261887   2097152     1G Linux filesystem
/dev/sda4  4261888    4327423     65536    32M Linux filesystem
/dev/sda5  4327424 1000215182 995887759 474.9G Linux filesystem

Related articles