Xen Project in peril as colo provider housing test platform closes(theregister.com)
theregister.com
Xen Project in peril as colo provider housing test platform closes
https://www.theregister.com/2024/07/11/xen_project_colo_closes_warning/
11 comments
Why do they think their hardware would not survive a move? I've worked on a number of datacenter move, sometimes with very old sun hardware, and we had very little issues.
> Why do they think their hardware would not survive a move?
Stuff that is spinning and then stops may not come up again for mechanical reasons - there is relatively little energy required to keep it spinning, but to overcome the initial resistance and acceleration takes more energy than components might deliver as lube is dried out, gum and oil gotten sticky.
And that also holds true for solid state elements, particularly capacitors. They can simply blow up or otherwise fail under the strain of inrush current.
Other stuff can be mechanically damaged during disassembly, shipping and assembly. A worker lets something drop by accident, a cable isn't unplugged properly, damaging the socket as it's being ripped out, the truck drives over a pothole, the shipping container bakes in the sun for a few days leading to capacitors drying out or, in the worst case, cable insulations melting, flex cables where the softener has long since leeched out and now they're brittle, literally crumbling due to the vibrations and movement of a move...
And finally, there's the RoHS issue from the late '00s coming back to haunt us for really aged hardware - anything manufactured from a year before to two years after RoHS got in force can have issues with solder composition. Tin whiskers that get rattled loose by moving stuff around and cause shorts, solder-thickened traces that literally break under flex.
There's LOTS of stuff that can go wrong in a DC move.
Stuff that is spinning and then stops may not come up again for mechanical reasons - there is relatively little energy required to keep it spinning, but to overcome the initial resistance and acceleration takes more energy than components might deliver as lube is dried out, gum and oil gotten sticky.
And that also holds true for solid state elements, particularly capacitors. They can simply blow up or otherwise fail under the strain of inrush current.
Other stuff can be mechanically damaged during disassembly, shipping and assembly. A worker lets something drop by accident, a cable isn't unplugged properly, damaging the socket as it's being ripped out, the truck drives over a pothole, the shipping container bakes in the sun for a few days leading to capacitors drying out or, in the worst case, cable insulations melting, flex cables where the softener has long since leeched out and now they're brittle, literally crumbling due to the vibrations and movement of a move...
And finally, there's the RoHS issue from the late '00s coming back to haunt us for really aged hardware - anything manufactured from a year before to two years after RoHS got in force can have issues with solder composition. Tin whiskers that get rattled loose by moving stuff around and cause shorts, solder-thickened traces that literally break under flex.
There's LOTS of stuff that can go wrong in a DC move.
> There's LOTS of stuff that can go wrong in a DC move.
That can doesn't mean that will.
I am talking from experience, having worked on several moves that included some 15y old machines at the time that had some stupidly long uptimes and on different architectures: x86, sparc, amd64, powerpc. Stuff being pretty much more amd64 arch centric these days, especially in the virtualization world, I believe it should be easier to have a few spares.
That can doesn't mean that will.
I am talking from experience, having worked on several moves that included some 15y old machines at the time that had some stupidly long uptimes and on different architectures: x86, sparc, amd64, powerpc. Stuff being pretty much more amd64 arch centric these days, especially in the virtualization world, I believe it should be easier to have a few spares.
stuff I've seen go haywire during DC move includes PSUs frying themselves for no reason (so called magic smoke), cabling might be an unholy mess too, probably badly labelled.
Ultimately when you move to a new DC you don't care where cables were going. You care where you want them to be attached to in the new DC. You don't want to replicate the mess, rather to know which LANs/VLANs your servers need access to, so you have some planning to do, but the day you unplug everything you don't have to mind where the cables were going.
I've seen more hard drive than PSU dying in datacenter move, which is usually solved with having a few spares and good backups, obviously external from the datacenter being moved. But same can be said of PSUs. Obviously the more heterogeneous your servers are, the hardest it is to have spares for everything. Everytime we did some DC moves, we used that opportunity to replace a few old servers which meant we bought a few spares. The big question is if the Xen project has the financial capacity to buy a handful of servers.
Let's keep in mind we are talking about a relatively easy move. This might be inconvenient for the DEVs but this is an infrastructure (CI) that is not customer facing and that can survive being offline 2 or 3 days. Users can still download the deliverables, developers can still code in the meantime.
I've seen more hard drive than PSU dying in datacenter move, which is usually solved with having a few spares and good backups, obviously external from the datacenter being moved. But same can be said of PSUs. Obviously the more heterogeneous your servers are, the hardest it is to have spares for everything. Everytime we did some DC moves, we used that opportunity to replace a few old servers which meant we bought a few spares. The big question is if the Xen project has the financial capacity to buy a handful of servers.
Let's keep in mind we are talking about a relatively easy move. This might be inconvenient for the DEVs but this is an infrastructure (CI) that is not customer facing and that can survive being offline 2 or 3 days. Users can still download the deliverables, developers can still code in the meantime.
> You don't want to replicate the mess, rather to know which LANs/VLANs your servers need access to, so you have some planning to do, but the day you unplug everything you don't have to mind where the cables were going.
This assumes the Xen project keeps half decent, fairly up to date documentation. I could see them not founding admin work as much as they should.
This assumes the Xen project keeps half decent, fairly up to date documentation. I could see them not founding admin work as much as they should.
Perhaps a certain trillion dollar company who's cloud is based on Xen could chip in.
AWS' Nitro platform is no longer based on Xen and the Xen stuff is being replaced/deprecated, including moving some of the old Xen instance types to run on Nitro instead of Xen.
[deleted]