Hyperconverged infrastructure for schools and universities
A campus has a load shape that suits consolidation and a budget cycle that does not suit growing into it gradually. Teaching demand is concentrated into timetabled hours, near zero overnight and in vacations, and purchasing happens once a year against a capital grant. That combination is what makes hyperconverged infrastructure worth considering here: it collapses compute, storage and networking into units you can add one at a time.
Size from the timetable, not the headcount
The number that matters is concurrent desktops at the busiest timetabled hour, not enrolled students. A university with eight thousand students may never exceed four hundred concurrent sessions, and sizing from enrolment produces a cluster that is idle for most of its life and paid for in one go.
The addition people skip is the failure allowance. A cluster sized exactly to peak has nowhere to restart the workloads from a failed node, so the failure becomes an outage during a timetabled session — the one hour it must not. Size for peak plus one node, and treat that node as insurance rather than spare capacity to be filled.
Where a campus workload is unusual
Everyone logs in at once
A lab session starts on the hour and sixty desktops boot in the same two minutes. This is a burst of storage I/O far above the steady-state figure, and it is what determines whether the first ten minutes of the class are spent waiting. Sizing on average I/O misses it entirely; the mitigations are pre-booting sessions before the hour and keeping the desktop images small.
Images change on a semester boundary
Course software is rebuilt between terms rather than continuously, which is an advantage: a single golden image per course, rebuilt on a known date, is far easier to manage than continuous drift. It only works if the platform makes rebuilding cheap enough that nobody is tempted to patch a running image by hand.
Research and teaching are different tenants
Research workloads are long-running, unpredictable and occasionally enormous; teaching is short, bursty and timetabled. Running them on one undivided cluster means a research job can spoil a lab session. Separate them with resource limits at minimum, or with separate clusters where the research load justifies it.
When it is not the right answer
Hyperconverged is a good fit for many small-to-medium workloads with similar shapes. It is a poor fit for a handful of very large ones — a database needing far more memory than compute, or storage growing much faster than the compute alongside it — because the units scale together and you end up buying processors to obtain disk. Where a campus has one or two workloads like that, keep them separate and consolidate the rest.
Where this fits
The service is Hyperconverged Infrastructure, and the sector context is Education and E-Learning. Day-to-day operation is Infrastructure Managed Services; the capacity habits it depends on are covered in capacity planning when the cloud makes it feel unnecessary.
