跳到主要内容
博客Linode自助服务的Linode调整规模

自助服务的Linode调整规模

我们刚刚推出了一项功能,允许你按下按钮,将你的Linode从一个计划调整到另一个计划。现在你可以升级或降级一个Linode,而不需要支持票或等待我们。

你选择计划,你的账户根据成本的差异和你的计费周期的剩余天数开具发票(或贷记),然后你的Linode被迁移到新的主机服务器。 简单。

在API ,通过新的linode.resize()方法支持调整大小。


评论 (22)

  1. Author Photo

    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

  2. Author Photo

    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).

  3. Author Photo

    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.

  4. Author Photo

    finally got sick of my tickets eh?

    Welcome change. Thanks!

  5. Author Photo

    You forgot Step 3. ???

    Then Step 4. Profit.

  6. Christopher Aker

    @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.

  7. Author Photo

    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?

  8. Tom Asaro

    @David – Your Linode’s IP(s) remain the same. The host you connect to for Lish would change, however.

  9. Author Photo

    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.

  10. Author Photo

    GREAT!!!

    Not having to do it manually is a great thing.

    Very happy person.

  11. Author Photo

    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.

  12. Christopher Aker

    @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.

  13. Author Photo

    What if I have my disk full and I want to downgrade my Linode?

    Thanks.

  14. Christopher Aker

    @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.

  15. Author Photo

    @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.

  16. Author Photo
  17. Christopher Aker

    @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.

  18. Author Photo

    Great! thanks!, this you really do a great job!

  19. Author Photo

    @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? 😛

  20. Author Photo

    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.

  21. Author Photo

    Very nice. The Linode service gets better all the time. Please continue.

  22. Author Photo

    @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.

留下回复

您的电子邮件地址将不会被公布。 必须填写的字段被标记为*