Hardware refresh, 2015-2016
From late 2015 into 2016 BitFolk is performing a hardware refresh which means you'll be contacted at some point about having your VPS moved and upgraded.
- 1 Progress
- 2 Normalisation of disk layouts
- 3 FAQ
- 3.1 What will the upgrades be?
- 3.2 Will I be able to buy extra CPU cores?
- 3.3 I don't need 1GiB of memory, can I downgrade?
- 3.4 I was happy with slower storage, can I downgrade?
- 3.5 When will I be contacted to arrange my upgrade?
- 3.6 What does migrating my VPS involve?
- 3.7 Can I have the memory upgrade without being moved to a different host?
- 3.8 My VPS already had extra memory and the upgrade is more than I need. Can I downgrade?
- 3.9 I don't need swap. Can I use xvdb for something else?
- 3.10 I have more than 1GiB of swap and I need that much. Can I keep it?
- 3.11 I have a question that's not answered here. Where do I send it?
Migration of existing customer base was completed on 2016-04-01.
Normalisation of disk layouts
Over time BitFolk has used a variety of disk layouts for VPSes.
The old state of the art
Immediately prior to the beginning of the hardware refresh the favoured disk layout was two disks, xvda and xvdb, each of which was treated as a partitioned disk (MSDOS partitions). xvda1 was then used for the VPS root filesystem and xvdb1 was used for the swap partition. xvda would be the correct capacity as purchased by the customer and xvdb was equal to RAM size (so base VPS would have a 480MiB xvdb).
The new state of the art
A minor tweak is being made for SSD-backed VPSes. As SSD-backed storage costs a lot more, it seems wasteful to give large amounts of it away for use as swap. Therefore the size of xvdb is being capped at 1GiB. That means that basically everyone migrated is going to have a 1GiB xvdb disk.
Those customers that currently have a VPS with more than 1GiB RAM currently have an xvdb that is larger than 1GiB. Although it has never been spelled out that the swap disk layout was part of the contractual agreement, we do regard it as so, so you are going to end up with an xvdb disk that is larger than what we would sell to new customers. We reserve the right to take that away from you at a mutually convenient point after your next contract renewal, and replace it with one that is 1GiB in size.
Those customers who previously had just a single block device are going to find themselves with a new one that is unused by the VPS. We won't be meddling with your VPS to make it use the new xvdb1 block device as swap.
Making use of the extra swap space
Assuming you have an xvdb disk that you only ever used for swap, as is the BitFolk norm, you can grow it without a reboot with a process like:
# swapoff -a
Re-create partition for swap
# fdisk /dev/xvdb
- Delete the swap partition (d, 1)
- Create new swap partition using whole disk (n, 1)
- Set type to swap (t, 1, 82)
- Write changes (w)
# mkswap -L SWAP /dev/xvdb1
Fix up /etc/fstab
Check your /etc/fstab to see if your swap partition was referenced by UUID or LABEL. The label set above is "SWAP", but if it was by UUID then you will need to change that (see blkid command to see the new UUID).
# swapon -a
What will the upgrades be?
At the moment it's looking like the base memory allocation will go up from 480MiB to 1,024MiB. The incremental upgrade will change from 240MiB to 256MiB. So, if you started with the base 480MiB VPS you'd end up with a 1,024MiB VPS. If you started with a 960MiB VPS it would go to 1,536MiB.
Storage allocation is going to remain the same but will be backed by enterprise SSDs behind software RAID instead of 3.5" SATA drives behind hardware RAID.
It's still an open question what to do about storage costs, because SSDs obviously cost a lot more than HDDs do (even when you have a bunch of them behind battery-backed hardware RAID). The initial customer upgrades will be for low-storage customers, and as time goes on we'll be able to make a decision on whether costs for additional storage need to change.
Costs for backup storage space are currently rolled into generic storage, and this is very likely to change with the backup storage costs being broken out into a separate cheaper line item.
Will I be able to buy extra CPU cores?
Most likely not. Previously all BitFolk VPSes were limited to one CPU core (not dedicated). The plan is to increase this to two cores per VPS, and to scale that up linearly in some fashion with the amount of memory purchased. We don't want to split out CPU cores into a separate line item at this time.
I don't need 1GiB of memory, can I downgrade?
No. The base VPS that we're selling is the smallest thing we want to sell for now.
I was happy with slower storage, can I downgrade?
The intention is to go all-SSD for scalability reasons, and initially the prices for storage are going to remain the same. At some point we probably do have to revise this since SSD storage does cost so much more to provision, but we will not alter the prices until we have viable cheaper archive storage for those who want that.
When will I be contacted to arrange my upgrade?
It's difficult to predict. It will be as soon as possible. The following hosts are most likely to be emptied first:
Every customer will have a support ticket opened with them to plan the upgrade (can be as simple as you just saying "yes, do it any time" or as complicated as agreeing a specific date/time for the work).
If you're experiencing performance problems with your service then please contact support and as always we'll see what we can do about it. If it is down to our platform not performing as well as we expect then we'll do our best to find a solution that you're happy with.
What does migrating my VPS involve?
Either you will have agreed a time with us for the work or you'll have indicated that any time is fine. When the time comes we'll:
- Shut your VPS down.
- Do a final sync of its storage to the new host.
- Boot it up on the new host with an increased amount of RAM (or the amount you agreed to downgrade to).
You do not need to be around for the migration to take place.
You should ensure that all your services start correctly on boot.
None of your IP addresses will change.
After your VPS has booted again we will do simple checks to give confidence that it's working. These including:
- Pinging it. So please make sure it at least responds to ping from our monitoring hosts.
- Checking there is nothing marked down on Nagios that was not showing as down before.
Nagios checks are available for free for most of your services so if you would like those added, please contact support with a list of services you'd like monitored.
Can I have the memory upgrade without being moved to a different host?
Initially not. After some time, legacy hosts will be empty enough that increasing the remaining customers' memory allocations would be possible, and we will do that as soon as we can. However, it is our intention to eventually decommission all legacy hardware since it is much less power-efficient, so you will definitely need to have your service moved at some point in the coming months.
My VPS already had extra memory and the upgrade is more than I need. Can I downgrade?
If you're on a monthly contract then just ask support to remove the extra memory line items that you don't need and that will take effect from your next monthly payment.
If you're on a quarterly or yearly contract then we're happy to remove the extra line items and provide a pro rata amount of service credit for them. Service credit can be used to pay any future invoices. We won't refund you, however.
I don't need swap. Can I use xvdb for something else?
xvdb is provided to you with the idea you'll use it as a swap device. It is not accounted for as part of the storage capacity that you order. Before the migrations it was the same size as the RAM you ordered. After the migrations each VPS is getting a 1GiB xvdb.
We don't care if you put a filesystem on it instead of using it as swap. You can do what you like with it. You could use no swap at all (many people prefer this), or you could use a swap file somewhere on your xvda disk, and use xvdb for something else.
Two words of caution however:
- Your xvdb was never intended to be fast. It was intended for use as swap. It's to make your greedy processes stay alive even if they have to become slow as a result. Although we do not employ any such measures right now, we reserve the right to prioritise IOs to xvdb disks after IOs to xvda disks, which may result in swap storage not being very fast.
- If you're one of the anomalous customers who have ended up with an xvdb disk that is larger than 1GiB we do reserve the right to take that back from you after your next contract renewal. So you should not put anything on this anomalous additional capacity that you can't shrink and/or relocate when asked.
I have more than 1GiB of swap and I need that much. Can I keep it?
At the moment the intention is to only sell SSD-backed VPSes that have 1GiB of swap thrown in. Existing VPSes with more than 1GiB of swap would need to be meddled with in order to shrink that, and we're not going to do that, so you'll get to keep your larger swap disk for a while at least.
At some point after your next contract renewal we may tell you that we're taking back some of your swap disk by reducing it down to 1GiB. You'll get to agree when that happens, but if we ask for it then it is going to have to happen. If you still need more than 1GiB of swap then you can easily get that by adding a new swap file somewhere on your xvda disk, i.e. on storage you are paying for. Swap files perform exactly the same as swap partitions.
Do consider checking if using that much swap is sensible though; even SSD-backed swap is slow because it's stuff that should be in memory. If you're regularly in swap then you're asking too much of your VPS.
I have a question that's not answered here. Where do I send it?
Sorry about that! Please send it to our users mailing list. It will be answered and the answer written up here. Thanks!