CIO / VP of Infrastructure
Storage that supports critical applications without capacity crises, risky refreshes, or finger-pointing between the reseller, integrator and operator.
Storage · Platforms we sell and architect
Enterprise Storage.
A storage purchase sets the operating model for the next five to ten years. ModernOps measures how your data moves, then designs and sizes the platform around that profile, procures and deploys it, and migrates the data with a tested rollback at every step.
Storage / Data Center Architect
Defensible sizing and protocol design across block, file, object, parallel and software-defined platforms.
Platform Operations Lead
Visible latency, IOPS and capacity, documented failover, and migrations that follow runbooks instead of memory.
Data, AI and Research Computing Lead
Throughput and scale beyond what a general-purpose array delivers on its own.
The decision
Key design
considerations.
01 /
Performance class or capacity class.
Paying flash-performance prices for cold data is the sizing mistake we correct most often. The workload’s latency and concurrency profile determines the tier.
02 /
Full is a failure mode.
One assessment found a primary array at 91 percent capacity while still serving healthy 0.4 millisecond reads at 48,000 peak IOPS. Good latency says little about capacity risk. Growth projections do, and they have to include snapshot, replication and recovery overhead as well as raw terabytes.
03 /
One blast radius.
Production arrays doubling as backup targets is a pattern we have found in several assessments. An array failure or ransomware event then takes the data and its recovery copy together, so our designs place the recovery copy on separate infrastructure.
04 /
Own the refresh or subscribe to it.
Evergreen-style subscriptions and buy-and-refresh cycles produce different five-year costs depending on growth rate. We model both before the bill of materials exists.
05 /
Immutability has strings attached.
Time-locked snapshots, SnapLock-class retention and dual approval for destructive actions blunt ransomware. They also change how deletes, eradications and emergency capacity moves are authorized, so the authorization path has to be designed before it is needed at 2 a.m., and the recovery rehearsed along with the lock.
What we architect
Reference
architectures.
Pattern 01
HA controller pairs sized for hypervisor datastores, including the Proxmox VE decision our field guide exists for: shared block SAN with multipathing, NFS simplicity, or Ceph, chosen by snapshot behavior, thin-provisioning needs, failure domains and the team that has to run it. Includes migrations off ESXi-era designs.
Pattern 02
C-series and capacity-flash arrays consolidating aging spindles and file sprawl without tier-one performance pricing.
Pattern 03
Controller, NVMe and capacity-pack upgrades on running arrays, handled as scheduled operations rather than projects.
Pattern 04
Failed, unsupported or single-head arrays replaced with modern HA platforms, native file services included, through staged migration, demonstrated cutover procedures, rollback plans and knowledge transfer. One current implementation replaces an out-of-support single-controller array with a two-site platform, with file services on the array instead of on aging Windows servers.
Pattern 05
SnapMirror-class replication paired with tamper-proof snapshots, SnapLock retention, multi-admin verification for destructive actions, encrypted replication, anomaly detection feeding the SIEM, and recurring recovery validation. Designed with the data protection practice so storage-native protection and separate backup infrastructure cover different failure modes instead of sharing one.
Pattern 06
VAST-class disaggregated platforms, software-defined Ceph, and partner-delivered parallel architectures for research and AI pipelines, with cloud tiers like Azure NetApp Files, Managed Lustre and Blob where burst or archive economics win. One recent design scoped 500 terabytes to a petabyte of tiered parallel storage behind a 36-node accelerated cluster. Deep GPU-side design lives on the AI & Accelerated Compute page.
The platforms
Supported
platforms.
ONTAP across AFF and C-series: performance pairs, capacity consolidation, disk shelf expansion, SupportEdge lifecycles and deployment services, plus the resilience layer that many quotes leave out: SnapLock, tamper-proof snapshots, multi-admin verification and recovery modernization, designed and put into operation rather than licensed and left. Keystone is available where consumption pricing fits.
FlashArray from X-series performance to capacity tiers, Evergreen subscription economics modeled against buy-and-refresh, and in-place NVMe, port and capacity expansion on running arrays. Current work includes two-site implementations with native file services replacing aging Windows file servers.
Naming note: Pure Storage now operates under the Everpure brand; we use the name buyers still search.
Disaggregated shared-everything architecture for file, object and AI throughput at scales where controller-pair designs run out of road. We architect and quote VAST for data-intensive and research workloads.
PowerStore refreshes, expansions and ProSupport lifecycles for the most common midrange arrays in the field, with PowerScale designs where scale-out file is the requirement. APEX consumption modeled alongside Keystone and Evergreen where opex pricing fits.
ModernOps’ own production platform runs shared all-NVMe Ceph under Proxmox VE with replicated storage across the cluster, so our Ceph recommendations come from operating it. It suits larger clusters with an operations team behind them; small clusters and teams without that appetite are better served by an array.
PlatformCloud storage tiers
Azure NetApp Files for persistent shared file services, Managed Lustre for parallel scratch, Blob for object and archive, designed as tiers in one architecture alongside the owned platforms.
Also on the line card
Qumulo, DDN, VDURA.
The old model vs ModernOps
The ModernOps
difference.
| Dimension | The old model | ModernOps |
|---|---|---|
| Platform selection | The incumbent vendor or the renewal date decides | Workload behavior, protocol, growth and operating model decide, vendor-flexibly |
| Capacity planning | Expansion starts when the array is nearly full | Utilization, protection overhead, growth and recovery headroom are baselined before sizing |
| Performance | Investigated after users complain | Latency, IOPS, throughput and replication validated at handoff and monitored after |
| Architecture | Every workload forced onto one general-purpose array | Block, file, object, parallel, software-defined and cloud tiers matched to the workload |
| Migration | A maintenance window and an undocumented procedure | Sequenced waves, acceptance criteria, demonstrated cutover, documented rollback |
| Protection | Snapshots, replicas and backups configured separately, sometimes on one failure domain | Storage-native protection aligned with isolated backup and DR, immutability where supported |
| Lifecycle | Reseller ships it, someone else inherits it | One accountability line from design through optional managed operations |
The first 30 days
The first
30 days.
| Phase | What happens | What you hold at the end |
|---|---|---|
| Assess and architect · Days 0 to 10 | Inventory arrays, file services, protocols, fabrics, capacity, performance, support status, replication, backup dependencies and growth. Confirm success criteria and evaluate vendor architectures. | A current-state baseline, prioritized risks, workload requirements, target architecture and sizing assumptions. |
| Build and migrate · Days 10 to 24 | Finalize design and prerequisites, coordinate logistics, rack and configure, integrate with compute and network, create storage services, stage data, run migration waves under change control. | A new platform coming online in controlled checkpoints instead of one high-risk cutover. |
| Validate and optimize · Days 24 to 30 | Validate capacity, latency, IOPS, failover, snapshots, replication, backup integration and alerting. Deliver runbooks, as-built documentation and knowledge transfer or managed handoff. | An operable platform baseline, verified acceptance criteria and a prioritized optimization roadmap. |
Scope control
Thirty days gets you from assessment to a validated first production milestone. Hardware lead times, petabyte-scale data movement and application testing then run in planned waves on their own timeline.
Buy the arrays or use STaaS
Engagement
models.
We price both because we sell the arrays and we operate storage for managed clients every day. This page covers the assess, design, procure, deploy and migrate work. Ongoing capacity, performance, replication, firmware and health operations live in Storage as a Service, whether we sold the platform or inherited it.
Proof
Recent
engagements.
91 percent full at 0.4 milliseconds.
One assessment caught a primary array running healthy latency while nearly out of capacity. Performance dashboards say little about growth; capacity baselines are what catch it.
From one failed controller to two sites.
A current implementation replaces an out-of-support single-head array with a two-site platform, native file services and a demonstrated cutover with rollback, documented and handed over.
The platform we run ourselves.
ModernOps’ own platform runs shared all-NVMe Ceph in production, with the runbooks to prove it.
Field Notes · No. 07 · The reuse angle
MO Money, Fewer Problems: Your Old Array as Your DR Tier
Read the field note
Field Notes · No. 04 · The immutability angle
Immutable Backups: SafeMode, SnapLock and 3-2-1-1-0
Read the field note
Field Notes · No. 02 · The recovery angle
The Ransomware Recovery Playbook
Read the field note
FAQ
Frequently asked
questions.
01 /Performance flash or capacity flash: how do we decide?
By the workload’s latency, concurrency and data-movement profile, then the growth curve. Databases and virtualization datastores earn performance tiers; file shares and archives usually belong on capacity tiers.
02 /Do snapshots replace backups?
No. Snapshots and replication give fast local and remote recovery points, and they share fate with the array. Backup data lives on separate infrastructure so a single failure or ransomware event leaves one copy intact.
03 /Is an evergreen-style subscription cheaper than buying again?
Sometimes. It depends on growth rate, refresh horizon and how you capitalize. We model the five-year cost both ways before quoting either.
04 /Our array is end of life or already failing. How fast can you move?
The pattern is established: assess dependencies, stand up the replacement platform, stage data, demonstrate the cutover with a rollback path, then migrate in waves. The speed comes from the sequencing.
05 /How are cutovers managed?
Dependencies, ownership, change windows, sequencing and acceptance criteria are confirmed before anything moves. Every wave has validation and a documented way back, and you keep the runbooks.
06 /What storage should we run under Proxmox VE?
Shared block SAN, NFS or Ceph, depending on snapshot behavior, multipathing, thin provisioning, failure domains and your team’s operating appetite. We wrote a field guide on this decision and run Ceph in production ourselves.
07 /How is capacity planned?
On usable capacity rather than raw: after RAID or erasure overhead, snapshot and replication reserve, growth trend and recovery headroom. Consumption is then monitored at the physical array.
08 /What can the array itself do against ransomware?
Quite a lot when operationalized: time-locked and tamper-proof snapshots, SnapLock retention, dual approval for destructive actions, encrypted replication and anomaly detection feeding your SIEM. The operational cost is that locked snapshots consume capacity and change emergency procedures, so the design includes the authorization and recovery paths alongside the feature list.
09 /Can you handle AI, HPC or research-scale storage?
Yes, at design-and-quote depth: VAST, Ceph and partner-delivered parallel architectures, with cloud tiers for scratch and archive. Recent work scoped 500 terabytes to a petabyte behind a 36-node accelerated cluster.
10 /What is the difference between this and Storage as a Service?
This page is the buy-and-build motion: assessment, architecture, procurement, deployment and migration. STaaS is the recurring operating layer afterward: monitoring, capacity, performance, replication and lifecycle. The same team handles both.
Direct to an engineer
Tell us about
your arrays.
Platform, capacity and growth: whatever you have. We will map the sizing and migration path against it.