Abbiamo appena introdotto una funzione che consente di ridimensionare il proprio Linode da un piano all'altro con la semplice pressione di un pulsante. Ora è possibile aggiornare o declassare un Linode senza richiedere un ticket di assistenza o aspettare noi.
Si sceglie il piano, il conto viene fatturato (o accreditato) in base alla differenza di costo e al numero di giorni rimanenti nel ciclo di fatturazione, quindi Linode viene migrato sul nuovo server host. Semplice.
Il ridimensionamento è supportato nel metodo API tramite il nuovo metodo linode.resize().
Commenti (22)
Fantastic! I’ve only been with you guys for a little while, but so far haven’t had a single problem at all, and you just keep surprising me with nice new features and free upgrades. Keep it up!
Now, one obligatory question – iirc, the different linode sizes are hosted on different servers so that one server contains only a particular size of linode, right? Does this mean there is a downtime when resizing, or is it done on the fly like VMWare VMotion does?
Cheers,
–Chris
Chris: The Linode is moved, with minimal downtime. Within a datacenter, it would take about 1 to 3 minutes per GB of data (just for us to copy it).
That 1-3mins/GB is downtime or time until migration is done? In other word, how does your resizing downtime compare to Slicehost’s? The other does it like this: they make a snapshot of your VM, enlarge and/or copy it (while your VM is still running) and only when the copy is made, they stop your VM, rsync its filesystem with the copy to add changes made during copying, then boot up the new VM. Makes a tiny downtime.
finally got sick of my tickets eh?
Welcome change. Thanks!
You forgot Step 3. ???
Then Step 4. Profit.
@Chris – there is downtime, since live migration requires network storage.
@xxx – I presume Slicehost only migrates people off a server when it’s full, since they lob all plan types onto the same server. But anyway, no — we don’t do it like that since we support (and encourage use of) different filesystem types, so from our end we treat disk images as just block devices and not mountable filesystems. We actually do have an rsync based migration routine that’s been in our host library for ages — maybe it’s time we resurrect it for those filesystems we can actually mount.
If I upgrade my Linode, which are the network parameters that will change? (IP, machine name?) Or will my upgraded Linode just work exactly as it did the previous one?
@David – Your Linode’s IP(s) remain the same. The host you connect to for Lish would change, however.
Guys, this is great!
One suggestion: would it be possible to have the price for each Linode size be listed in the Resize screen? I can see why you wouldn’t want to, because it’s something that could get out-of-sync. But it would be handy.
GREAT!!!
Not having to do it manually is a great thing.
Very happy person.
caker: Why can’t you rsync a disk image?
1) Copy the live image over while the linode is running (filesystem not in consistent state, but most of the data is there)
2) Turn off the linode
3) rsync over the differences (make consistent)
4) Start the Linode on the new machine
If network bandwidth is your bottleneck, this will save a bunch of downtime. If disk IO is your bottleneck, sure, won’t help.
@Guspaz Some people manipulate their disk images in such a way that they’re not mountable by us (LVM, partitions, encrypted volumes, filesystems that our hosts don’t support, etc), so we just migrate the entire block device. As it is now, typical migration time of a Linode 360 is only about 8 minutes, so this isn’t that much of a priority.
What if I have my disk full and I want to downgrade my Linode?
Thanks.
@Terminator – You free up space and then resize your disk image to fit within the smaller plan’s disk quota. Click on your disk image, enter a new size, and hit save. Done.
@caker: rsync doesn’t just work by only sending files that are different, it can send just the differences on the binary level. It’s very efficient when trying to synchronize two 24GB images, for example. It’s quite good at finding only the part of the file that has changed.
As such, the disk images don’t need to be mountable. The entire disk image can be copied as a single image, and then after the linode is taken down, the differences of that single disk image can be rsynced on a binary level.
Someone needs to upgrade https://www.linode.com/faq.cfm#can-i-upgrade-my-linode
@Guspaz rsync is great when the bottleneck is the network connection, which ours is not. rsyncing a large binary file (the second time around) causes the entire file on both ends to be read in its entirety, which is bad for our environment where disk IO is a sacred resource. It’s far less resource intensive to just read the entire thing once on the sending side, and save it once on the receiving end, than it is to do that *plus* another full read on both sides (plus some writes on the receiving end) in the scenario you presented.
Great! thanks!, this you really do a great job!
@caker: Ah, that makes sense. I had assumed network IO was the primary bottleneck, although I guess if it’s going over a gigabit network, it probably isn’t really.
But what about in a few years, when multi-terabyte SSDs cost as much as swedish berries? 😛
Hi. Just a few questions..
I assume the linode has to be shutdown first before resizing?
If disk ‘usage’ (on a filesystem level) is low, lets say 10%, but disk allocation (on a linode level) is 100%, would it be better / “nicer” to resize things so that not as much data needs to be copied? Once migration is complete, images could be expanded into the new space availabe?
Thanks.
Very nice. The Linode service gets better all the time. Please continue.
@titan_rw: It will be a faster migration if you resize the image to as small as possible, make the migration, then resize it back, yes.