Affectionately named "big64" for its 64 CPU threads and 64GB of RAM, I've turned off and unplugged my Sun Enterprise T5220.

I got it a decade ago, a bargain from Ebay (which it turned out is where the machine was last licensed by Sun/Oracle). I'd used servers from the T1 and T2 lines previously, and when this thing popped up for its low price, I jumped at it. I found and tossed in a bank of additional drives, and installed the last version of Solaris it could use.

I had visions of leveraging its zones for a distribution of software that is now done using Docker (or similar) on Linux (and others). Shortly after I got the machine running, it got left in the dust. It still performed, and a decade ago having that much RAM and CPU in one machine was cost prohibitive, but the software support shifted and even the big projects that had SPARC/Solaris branches stopped having those. Even Java! Invented at Sun, and a key component on the server stopped being updated on the platform.

For the last half of its life, it's simply run my SQL databases. With all that RAM and CPU, it cached and queried and delivered very quick responses for a 1.2GHz machine. Its line of drives was set up in a RAID, offering peace of mind. I never wanted for space, at first, so I even used some of it as a backup for the other servers.

Its hard drives seem to have been the cause of much of my recent problems. Not the database, or any activity, like I had thought. I get so many requests for so much garbage, and some of them hit counters or try to authenticate in mail, which is backed by SQL queries, that I thought maybe that was it. But it would happen "randomly" and not always when there was suspect activity.

I happened to be watching as I rebooted the server and saw a bevy of drive failure messages, this time stopping the boot process. I have spare drives, I can go down and diagnose which have failed and replace at least some of them, or remove them from the RAID. But I've already moved almost all the databases to other containers, paired in Docker Compose groups with the software that is using them, to the other server. I decided it's time to let this thing go.

I took the time to identify the last databases to migrate, and moved them to an instance I'd built for use by machines outside of the containers. The mail server, for example, which authenticates IMAP/POP3 as well as SMTP via SQL, is neither in a container, or on the same server. I used the last dump of the databases and restored it to that SQL server, and reconfigured the software to be able to reach them. It took a lot longer than I wanted, but it was the middle of the night, so I don't think I interrupted anyone trying to check their mail. I'll lose some hit counters, but they're not as useful as they used to be with other log analysis. There are still about a dozen databases that don't have a home. Most are for projects that never matured, and probably will remain off until I decide to revive them.

Today, since I was near the machine for other reasons. I took some moments to appreciate it in person. I said some kind words, and carefully pulled its power and network cables out. I also took the time to remove the old gateway router, since the new one has been working. I considered removing the server from its spot on the rack, but decided to let it rest there, as it's unwieldy and I don't have a better place to put it. I might pull the drives and replace the blanks in their places and offer it to another hobbyist, or maybe online to someone looking to replace something they've got running. It still performs, except for the failing drive. I could fix the drives and sell them with the unit, maybe installing an empty Solaris on it, but as nonsense as the data is, I don't want to risk leaving something behind.

It's a little quieter in the basement now that the server's fans are off. There's one less blinking light, as it has been warning whoever walked by that it is plugged in but not turned on for a few days.

Rock on little SPARC.