Cabinet build, switch configuration and Linux deployment with L3 support

The client is building an AI-powered database platform. They are a startup, which matters here. There is no network architect, no data centre team and no cabling specialist in separate departments. One small group of engineers covers everything, and physical infrastructure is the part furthest from what they do every day.

They were building out two racks. Dell servers were on order and a 10U Nvidia AI cluster was coming later, to be installed by a different supplier. Their technical team is remote.

Somebody had to receive and rack the hardware, but racking was the smaller half of the job. Switches had to be configured, iDRAC set up, Linux installed and IP addressing applied before the infrastructure was any use to them. That second half is where most smart hands engagements stop and the client’s own engineers have to get on a plane — which for a small team means days of scarce engineering time spent travelling instead of building the product.

The plan was sound in outline and had gaps in the detail, which is normal when the people writing it build software rather than IT infrastructure. The conventions that keep a rack organised are what make adding or reorganising hardware later a routine visit rather than a rebuild, and they make it safer. Where cabling is run and labelled properly, whoever does the next job is not disturbing neighbouring cables to reach the one they need — which is how a live service gets knocked offline by accident.

Rack accessories are the clearest example. Specify the cable management at the start and the racks stay workable for years. Leave it out and fitting it later means pulling existing cabling apart.

The AI cluster was the other gap. It was not in the building yet and someone else would install it, but the cabinet had to be set up for it now. The four vertical mounting posts carry every device in the rack and their depth is set once. Set them wrong, populate the cabinet, and every server comes out again before they can be moved.

These decisions are invisible from a desk, cost nothing to get right at planning stage, and the bill for getting them wrong arrives much later as downtime and rework.

We were brought in during planning, before anything was ordered. The client defined what the infrastructure had to do. We reviewed the design and suggested changes to the plan, specified the additional accessories and cabling routes it needed, built both racks, and configured the infrastructure to the point where their engineers could log in and start work.

Nobody from the client travelled to site at any point.

Reviewed the rack plan before anything was ordered. Our L3 engineer went through the design with the client. Switch airflow direction was clarified — a switch fitted the wrong way round fights the hot aisle. The layout was reworked so cable runs and access made sense once the racks were full rather than only on paper, and power connections were planned across the PDUs to balance load across the phases.

Checked the order and found what was missing. We advised on cabling and rack accessories and pointed the client at vendors. Going through the order line by line turned up cables that had not been included — and every one was needed. Missing cable is one of the most common reasons a build stalls: the engineer is on site, the racks are ready, and the job cannot be finished. Another day has to be booked and paid for, and completion slips by however long the part takes to arrive.

Checked the depth of every machine before setting the posts. Our method requires the dimensions of every unit to be confirmed before anything is fitted, including hardware that has not arrived. The Nvidia cluster turned out to be unusually long, so the posts were set for it and it dropped straight in months later. Had they been wrong, the install would have been cancelled on the day, the racks suspended, every device removed, the posts reset, everything reracked and rechecked, and a new date booked.

Used what we already knew about the building. We have worked at this site before, so we were familiar with its policies, working procedures, and how cross connects should be ordered and run. None of that had to be worked out on the day.

Recorded and labelled everything. Every device was unpacked on site and its serial number captured, so the client had a complete asset record before the first server was powered on. Part of the delivery went missing inside the building; our engineers worked with site security, traced it and recovered it. The client had no cable labelling convention, so we applied ours — including the runs left ready for the Nvidia cluster and for servers not yet installed. It is a documented standard, so the next person to open those racks can read it whether they work for us or not.

Put the right level of engineer on each part of the job. Once the plan was settled, the build was carried out by our L1 and L2 engineers. The L3 engineer came to site when configuration work needed doing and not before, so the client paid L3 rates only for L3 work.

Configured the infrastructure, not just the hardware. Our L3 engineers configured the switches, set up iDRAC across the Dell servers, installed Linux and applied the IP addressing. Several servers carried Mellanox network cards that needed a custom Linux driver compiled and installed before they would work. The backend runs at 100G. The internet connection the client had ordered was not working either, so our L3 engineer took it up with the ISP directly rather than handing the problem back, and stayed with it until the service was running.

At handover the client’s remote team had access to every server and began setting up their own systems. The switch configuration, the operating system builds, the Mellanox driver installation and the IP addressing were all done by DACPROS engineers on their behalf.

The build took four working days. Nothing had to be redone. The AI cluster fitted because the posts were right first time. No day was lost to missing cable because the order was checked before it was placed. The design problems were fixed while they were still on paper — which is the only point at which fixing them is free.

The infrastructure has not stood still. It has grown and been restructured more than once and the client has brought us back each time, sometimes after long gaps. Servers have been added on every return, and the racks are still as organised as the day they were built — because the layout, the accessories and the labelling were set up to take them.

Smart hands has run alongside the projects throughout: quick troubleshooting, hardware upgrades, memory and disk replacements.

The work comes irregularly and at very different scales. Some visits are a few hours for one L1 engineer. Adding a batch of servers is a project needing several people and a plan. In between there are months with nothing. Employing a team to cover that means paying all year for capability used a handful of times, including someone senior enough to configure a switch and build an operating system. The client pays for the days they use and gets one engineer or a full team depending on the job.

Rack and stack, with L3 network and systems engineering, design review, hardware specification, labelling and asset recording — run by DACPROS.

Tell us about the project and we’ll review the site and give you a plan before you commit to anything.