Skip to main content
Regulaxy

Storage systems

The storage register: what earns a row and what is only counted, how a system is detected automatically, and how the suggested upgrade window is derived.

A row in the register is the system. The rule that decides what earns a row is written once and holds for the whole family:

An object earns a row when a change can be scheduled against it, or when it is the only thing connecting two other rows.

A volume is neither, so it is not a row — it is a count in a column. Order of magnitude is the reason: an enterprise storage system holds thousands of volumes per controller, and a register with a row for each is a log, not a register. Capacity pools are kept, as a list inside the card rather than as a screen.

A dedicated backup appliance is a storage system whose role is Backup, not a family of its own. The protection policy itself — what is protected, under what policy, and when a restore was last tested — is a backup service.

The columns

ColumnWhat it says
System nameThe system's identity, and its record key
VendorThe vendor, as the source reports it
PlatformONTAP, PowerStore, PowerMax, FlashArray
RolePrimary · Secondary · Backup · Archive · Object · Files · DR
StatusThe five status values shared across infrastructure
SiteWhere the system sits
UtilizationOne meter over Used and Raw capacity
ControllersThe controller count. The basis for the derived upgrade window
Pools · VolumesCounts only
ProtocolsFC, iSCSI, NFS, SMB… as separate chips
Model · Serial number · VersionThe system's identifying detail
Support endsThe recorded date; turns red once it has passed
Owning teamWho is responsible for the system

Pools, Volumes, Protocols, Model, Serial number, both halves of the utilization meter and Owning team are not in the default set. They are added through the column picker, and they are always in the export.

Capacity is stored in GB and displayed in TB once it passes 1024. Two units for one quantity is how a total comes out 1024× wrong exactly once, so the conversion is a display decision made in one place.

The serial number has no quick filter. One distinct value per row is not a filter, it is the column again.

Automatic detection from the equipment register

A system already in the equipment register is detected automatically and appears here with no configuration at all. Two tests have to pass: the equipment record must be classified as storage, and the model must name a system family the vendor publishes.

The double test deliberately excludes Fibre Channel directors. An FC director does belong in the storage band on the connection map, but it is not a thing you schedule a controller upgrade with a capacity pool against — and promoting eight switches into "Storage systems" is exactly the sort of confident wrong answer the product is built to refuse.

A system present in both registers carries the same record key in both. The connection map folds it into one node, and the storage card offers a link to the equipment record.

The derived change window

For a nondisruptive ONTAP upgrade, the product derives a suggested change window from the controller count. It is the only object in the product that gets a derived window.

The formula is shown, not only the result:

(controllers × stabilization wait) + (controllers × controller reboot) + checks and overhead

TermDefaultChargedBasis
Stabilization wait8 minutesPer controllerStandard
Controller reboot30 minutesPer controllerConvention
Checks and overhead30 minutesPer upgradeConvention

Only one of the three terms is the vendor's. NetApp's documentation states that the upgrade waits eight minutes after each takeover/giveback cycle so that client applications can recover from the pause in I/O, and adds that this is a tunable parameter (-stabilize-minutes). The other two terms are product defaults nobody published, and they are labeled "Convention" in the table itself. The row marked "Standard" carries a link to its source; the row marked "Convention" carries a link to nobody. The total is never presented as a vendor-derived figure.

Four more things the calculation says out loud:

  • The result is rounded up to a quarter hour. Windows are booked in quarter hours, and rounding down would suggest a window the work does not fit into.
  • An odd controller count is stated explicitly. The last controller has no partner to take over for it, so upgrading it is disruptive. That is not an error — a single-controller system is a real configuration — but it is not smoothed over either.
  • At eight controllers and above the result is reported as an upper bound. At that size the vendor switches to a concurrent batch method, and the concurrency factor is not documented on the page cited. Rather than divide by a number nobody published, the serial figure is shown with an "upper bound" label.
  • A platform with no model gets no window at all. Running ONTAP's arithmetic against a PowerMax would produce a confident number about a procedure nobody has described.

Every term can be changed on screen and the result updates immediately. That change is local and is not saved — it changes what is drawn, never what is stored, and the panel says so. A site that has measured its own controller reboot records the value on the system card, and the server-side calculation follows it.

The change window travels with the collision warning: when a storage upgrade overlaps a patch window for servers whose storage sits on that system, the warning carries the calculation too — because how long the upgrade needs is what makes the overlap actionable rather than merely true.

Updated

This page is the file content/docs/en/v1/infra/storage.mdx