Products · Datacenter & servers
Capacity that has to sit somewhere.
Servers and the platforms built from them, for workloads that stay on-premise — because a residency rule keeps them there, because the latency to a plant or a network matters, or because the arithmetic simply works out that way.
This catalogue lists what Noble supplies and how it is specified. It carries no prices, no stock or availability position, no ratings or reviews, and no manufacturer specifications — everything technical is confirmed against the requirement at quotation, because a published figure nobody has verified is a figure somebody will procure against.
What this category is for
The decision that matters here is rarely the server. It is what the workload actually needs — cores against memory, local storage against shared, how much of the estate can be down at once — and that decision has consequences for the rack, the power draw and the cooling long before it has consequences for a purchase order.
Most estates in this region are hybrid rather than one thing or the other, so the useful question is which workloads stay and what the ones that stay are being sized against. Noble specifies to that answer and says where a smaller platform would do the same job.
What it covers
Product types rather than part numbers. The type is the decision; the model follows from the requirement and is confirmed at quotation.
Rack servers
The general case: standard rack units sized for virtualisation, databases or application hosting, chosen against a workload profile rather than a headline core count.
Tower and edge servers
For a branch, a site office or a plant room with no rack and no comms room — where the constraint is noise, depth and the fact that nobody local is going to maintain it.
Hyperconverged and virtualisation nodes
Compute and storage in the same node, scaled by adding nodes. It suits an estate that will grow in steps and a team that would rather operate one thing than three.
Out-of-band management
KVM, console access and remote management, which is the difference between a two-hour drive to a site and a five-minute reboot.
What decides the specification
The questions a quotation is built from. Answering these is usually faster than sending a part number, and it catches the requirement a part number would have got wrong.
- 01
What runs on it
Virtualisation, a database, an application tier or a backup target. Each of those sizes memory, cores and local storage differently, and getting the ratio wrong is more expensive than getting the model wrong.
- 02
How much can be down at once
One node, one rack or one site. That answer decides whether the requirement is a bigger server or a second one somewhere else.
- 03
The room it goes in
Rack depth and units available, power per rack, cooling capacity and floor loading. Equipment that will not fit or cannot be cooled is a specification failure, not a delivery one.
- 04
Who fixes it, and how quickly
On-site support level and spares strategy, which for a remote site is often a larger factor in the total cost than the hardware itself.
The work around it
Hardware arrives configured, installed and supported, or it arrives in a box. These are the services that make the difference.
Specified alongside
- StorageAlmost never specified separately. What the servers hold, and where a copy of it lives.
- Power & infrastructureRacks, uninterruptible supply, distribution and cooling. The room decides what fits in it.
- NetworkingNothing in a rack is reachable without it, and the uplink is usually the constraint nobody sized.
Brand and model names are used descriptively where a requirement names one. All marks belong to their owners.
Send the requirement.
A quantity, an environment and what it has to connect to is enough to start. Noble quotes against the requirement rather than from a price list, and says where a specification will not do what it is being asked to do.