we've got to replace a disk.
update: it is coming back up now, restoring domains. those of you running debian might need another reboot (I've had problems with debian save/restore)
update: it looks like all domains but one came back up successfully (with a save/restore, no reboot)
we'll be rebuilding the RAID now, so expect disk performance to suck for a while.
in order to replace a bad disk
we will do our best to put anyone who is in the preorder queue who needs something larger on an older server.
There are two reasons why I am doing this. First, I want to move to a system where the small accounts are segregated from the large accounts; ultimately, I'd like to put all the 64MiB customers on one server, all the 128MiB customers on one server, etc... but I don't have enough servers for that, so I'm starting this way.
The reason to segregate in this manner is to isolate performance problems that might be caused by the smaller domains using swap more, ah, vigorously than the larger domains. As you all know, the sata disk I use is by far the weakest link in my setup, and I hope this change will help people 'get what they pay for' (I will be implementing other procedures to see to it that everyone gets a fair shake at the disk on these smaller servers)
The other (and perhaps larger) reason why I want to do this is financial. Right now, prgmr.com has more available labor than capital, and we are bottlenecking pretty hard on capital, as evidenced by the fact that the 'we are out of servers' sign is up more often than not. Now, there are several ways this could be solved
1. I could raise prices
2. I could charge a setup fee whenever I got below a certain capacity (Like 1, but temporary)
3. I could see to it that my more profitable customers have access to new capacity before my less profitable customers do.
(Yes, I could also get investors or a loan, but those both come with their own irritations. I'm considering doing contracting, but that has it's own irritations as well.)
I am trying 3, mostly because I don't like the idea of raising prices. (In this industry, you raise your prices by keeping your prices the same) My pricing model is $4 per month per account, plus $1 per month per every 64MiB ram, so a 64MiB ram guest is $5, a 128MiB guest is $6, a 256MiB guest is $8, etc... so obviously, for any given amount of ram, I make more money the more small guests I sell.
So, here is the plan. Knife, the next server, will host 64MiB, 128MiB, 256MiB, and 512MiB guests. this server should be up within a day or two. (if I haven't made any more mistakes, it will be done tonight. ) Note, I don't know if it will get filled by the waiting list or not. It very well might.
Then, within the next two weeks (I have all the parts; ram is in the mail) I plan on setting up a 16GiB/ single socket server for 64MiB guests only.
Also within the next two weeks I will have another 32MiB/8 core server returned from a dedicated server customer who is leaving. If knife fills up with 512MiB and below domains, it will be another 512MiB and below server. Otherwise, it will service 1024MiB and above domains.
Beyond that, I need to buy more hardware, something that this new scheme will hopefully facilitate.
expect slow I/O while I rebuild the raid on robe.
uh, happened just a bit ago. maybe 15 minutes of downtime. SVTIX warned me of emergency maintenance of a UPS maybe three hours before that. Nothing was rebooted; we just lost network for a bit.
http://accu.org/index.php/accu_branches/accu_usa/next
I'm heading out to fix it right now.
(there are only a few of you on it)
we're rebooting our experimental IPv6 router for testing... it shouldn't be more than a few minutes downtime for IPv6.
my provider tells me there was an intermittent network outage at my Fremont he.net location (my reseller, not he.net) from 11pm to 1am PST.
they are in one of our supermicro 2 in 1u units
Recent Comments