Hello,
TL;DR:
This email is purely informational and there's no need for you to
take any action as a result of it.
The base VPS memory will go from 480M to 1,024M soon, and the
incremental upgrade will go from 240M to 256M, with the prices
remaining the same for those line items. It will take some time
(months) for this to be phased in. You don't need to do anything at
present.
Not Long Enough, Give Me More Info To Read:
Ideally I wanted to avoid saying anything about this until it had
started affecting csutomers, but I'd already given some time
estimates to a few people ("somewhere around the first week of
July"). Now there's been a few delays and some would be left
wondering what is going on, so I thought I better say something.
Clearly an upgrade of VPS specs has been well overdue for ages. In
June, hardware orders were made and this process is now under way.
It's not quite as simple as just buying "the same, but new". The
current BitFolk customer base is spread across 9 servers, and every
single one of them is basically not upgradeable at this stage. I
don't really want to replace them with 9 new ones, so a little more
scalability is required.
The bottleneck at present is either IOPs or CPU. IOPs is the hardest
one to solve so to increase scalability, new hardware must be
SSD-only. That's obviously really expensive, so this is not
something I want to get wrong.
There was quite a long lead time on the hardware I'd selected. I
felt it was worth the wait because the motherboard and CPU have a
really good bang per Watt factor, and the predominant cost for
BitFolk is power. That's now arrived, is in colo, and is being
worked on, so hopefully won't be as much of an issue in future.
The delaying issue now is software. There's a bunch of changes in
both Debian¹ and Xen² which I need to account for in BitFolk's own
software infrastructure.
Once that's progressed a bit more I will need to start putting
BitFolk's own infrastructure VMs on the new hardware to give things
a bit more of a soak test³. Around that time I will also be talking
to those I have already spoken to about this—and seeking some more
volunteers—to have their VPSes moved to the new hardware. There's
no need to contact me now to volunteer. I have to select the most
suitable customers for this and then ask them.
A key thing I need to discover is when the CPU and IOPs will run
out for this specification. For that reason the initial candidates
will have only the base amount of RAM (1G), so that the maximum
number of them can be packed on, and only the base amount of storage
(10G), again so hopefully that doesn't run out before another limit
is reached.
For some sense of comparison, the 3 busiest current servers look
something like this:
Name | # VPSes | RAM used | Storage used
----------+---------+----------+-------------
bellini | 74 | 47G | 2.71T
president | 60 | 45G | 2.71T
sol | 50 | 47G | 1.69T
The new hardware has 1.6T of usable SSD per box, and I want to fit
more customers on each, so obviously I have to start with low
storage VPSes first if I don't want storage to run out first.
Obviously SSD storage costs vastly more than HDD storage. Not very
many BitFolk customers order more storage, but it is unclear at this
stage if I can continue to offer additional (SSD-backed) storage for
the same price as the current HDD-backed storage. I do not want to
put both HDDs and SSDs into the same hosts, so I want to avoid
selling a mixture. I will know more once I've found out where the
CPU and IOPs limits lie.
The backup storage that is currently sold at the same price as live
storage is going to remain on HDD and so will remain at the same
price as now (or cheaper), whatever the case.
Even after I am satisfied that the setup is working well, and the
limits have been found, still I can't just move absolutely anyone in
any order. The next priority will be to decommission the most
power-hungry hosts. By this stage I will be continually ordering and
commissioning new hardware and then migrating customers to it.
During this time, as hosts are emptied, it will be possible to
increase the RAM of some customers without moving them. Eventually
however it will be necessary for every customer to have their VPS
moved between hosts because existing hardware probably run around 3
to 4 times as power hungry than new hardware that should support more
customers per box.
So, there is no need for you to take any action at this time, other
than to ask any questions you may have. I will be in touch with you
directly once it is time for anything to happen. I just wanted to
let you know what was going on, and to reassure those who I've
already spoken to that I have not forgotten about this! The first
set of hardware is bought already, the money is spent, and having
both new and older hardware live is costing BitFolk even more money,
so it is definitely going ahead. :)
Cheers,
Andy
¹ Debian jessie comes with systemd. I have to make sure I'm
comfortable with this and that other various bits of software are
integrated.
I use Puppet for config management. Debian jessie comes with a
version of puppet client which will not talk to the puppetmaster
that is packaged with Debian wheezy. Upgrading the puppetmaster
may necessitate wide-ranging changes elsewhere.
As an aside, upgrades forced by Puppet are probably in my top 5
annoyances with it and I probably wouldn't use it in a new
development. So I don't need to hear about your Puppet hate. :)
² The major piece of work here is accounting for the removal of
Python code from Xen (guest) config files.
At the moment each VPS has a config file which is actually a
fragment of Python that only has variables in it, with a call to a
Python script at the bottom. That script decides whether to just
boot your VPS, or in fact to boot the rescue VM or to download an
installer kernel/initramfs and boot that.
The ability to do that has now gone away and a guest config file
is now just a set of key/value pairs. This means that the Xen
Shell will need to write a new config file for each command or
change you make, and boot that one.
³ Obviously it's already been punished with memtest86+ and IO
throughput tests. I mean more operational testing.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
I've just installed PuTTY on a new PC running Windows 10. When I attempt
to connect to my VPS console (on bellini) PuTTY immediately disconnects
with the message
"Disconnected: No support authentication methods available (server sent:
publickey,keyboard-interactive)"
I can connect to my VPS using PuTTY without any problems. I can also
connect to the console on bellini from my home Linux box (using openssh
on CentOS 6).
This was working (PuTTY, Windows 10) a couple of weeks ago - has
anything changed?
Thanks,
Mike
