As part of our ongoing effort to provide you with the best Cloud Servers service possible, we routinely perform maintenance and upgrades of our underlying systems. The majority of these are performed transparently, however maintenances sometimes arise that impact Cloud Servers instances.
If you have Cloud Servers that are affected, you will receive notification of the specific servers impacted, steps required, and relevant dates. The purpose of this page is to provide more detailed information and answer common questions.
If you would like to view the Cloud Server and Maintenance video, please click here.
Some Cloud Servers need to be migrated so the underlying hosts (the physical servers under Cloud Servers) can be updated and those migrations require a Cloud Server reboot.
You only need to take action if you have Cloud Servers that are impacted (you will receive notification if you do) and wish to control when certain Cloud Servers are migrated. If you wish to manage your migrations, please see below for details on how to self-migrate. If you do not self-migrate, Rackspace will automatically migrate servers on your behalf.
Maintenance and upgrades are routinely performed on Cloud Servers systems, the majority of which are done transparently and with no impact to individual Cloud Servers. In some cases however, the host itself needs to be updated which renders it unable to run Cloud Servers for the duration of the update. Since the downtime associated with a Cloud Server migration is less than that of a host update, migrating Cloud Servers is the least impactful way of deploying the update.
No. All IP addresses associated with your cloud server will remain the same.
Simply use the Rackspace Cloud Control Panel, Cloud Servers API, or MyRackspace Portal to perform a soft reboot of the affected Cloud Server.The first time this is done after you are notified of a need to migrate, your Cloud Server will be migrated, then rebooted, instead of just rebooted.Please note that there will be a delay while your Cloud Server data is copied to the new host before the reboot occurs.Once migrated, any subsequent reboots of that Cloud Server will result in a traditional reboot.
To help, we have prepared a brief video and article that explains the migrations and walks you through an automated self-migration via the Rackspace Cloud Control Panel.
Please note: Rebooting from within your Cloud Server (e.g. via SSH or the console) will NOT initiate an automated self-migration.
While the Cloud Server is still running, a disk snapshot is transparently taken and the data copied to another host. During this time, the Cloud Server is still up and operational and any writes to disk are being tracked. After the base snapshot data has been fully copied to the new host, the Cloud Server is gracefully shut down, changes that have occurred since the beginning of the snapshot are synchronized, and the Cloud Server is booted. Albeit disruptive, the migration process minimizes downtime to a reboot plus the time it takes to copy over delta snapshot changes.
To further mitigate downtime you can prepare your instance for the migration by taking some of the steps described in this article.
Actual server downtime should not be much longer than a reboot, however, the length of time will vary based on the amount of data that changes during the snapshot process. If you are performing an automated self-migration, it is recommended that you minimize writes to disk (e.g. stop applications, shutdown databases, etc.) as much as possible before starting the migration.
Migrated Cloud Servers will remain in the same datacenter and will retain the same IP addresses, applications and data, server IDs, server metadata, etc.
We are in the process of moving to the XenServer hypervisor and some portion of Cloud Servers will be migrated to this platform. Should that occur, the below modifications will be made to the Cloud Server to support the new platform. All of these changes are now part of the default configuration for newly created Linux Cloud Servers and none should affect migrated Cloud Servers.
Instead of using a host-supplied kernel, an equivalent pv-grub kernel will be injected inside the Cloud Server. This doesn’t require you to do anything, but does allow you to manage and modify the kernel should you want to. For more information, please see this blog post first announcing the feature.
XenTools is installed to optimize performance of your Cloud Server on XenServer.
A Rackspace agent is installed that enables Cloud Servers control systems to configure and manage Cloud Servers instances.
If you are performing an automated self-migration, after initiating a reboot, the server “status” field in the Rackspace Cloud Control Panel, Cloud Servers API, and MyRackspace Portal will transition from “Queued for move” to “Preparing for move” to “Moving” and back to “Active” in lieu of the traditional reboot status changes.
This will allow you to monitor the migration progress. Once your Cloud Server has transitioned through these statuses and has returned to “Active”, the migration is complete and your server should be back online. For both self and managed migrations, you will also receive email confirmation for each server that is successfully migrated.
Once you have confirmation that a migration is complete, please take a moment to verify proper functioning of your Cloud Server and applications. If you have any questions or problems during or after a migration, please contact our support team immediately so we can investigate.
Existing Cloud Servers not listed in your maintenance notification as well as any new Cloud Servers you launch do not require a migration.
You will be given a period of time to self-migrate which will be clearly indicated in your notification of the need to migrate affected Cloud Servers. Once the self-migration window passes, automatic migrations will begin being scheduled for any Cloud Servers that have not been self-migrated.
You will be notified 24 hours in advance of any automatic migrations and will be provided a specific time window in which the migration will occur. Please note that automatic migrations may be spread out over a number of weeks and may also result in migrations occurring at inconvenient times or multiple of your Cloud Servers being migrated at the same time.
As such, please be sure to perform automated self-migrations for any Cloud Servers where this may be problematic.
Migrations should not interrupt RackConnect connectivity from your Cloud Server to your dedicated environment other than for the duration of the reboot. Please validate connectivity with your dedicated environment following the migration, and contact your support team if you experience any post-migration connectivity issues.
While we always seek to perform transparent maintenance and upgrades of underlying systems, it may be necessary in the future for various Cloud Servers to be migrated or rebooted. We are committed to continuously improving the performance, reliability, security, and feature set of Cloud Servers while at the same time engineering our systems for minimal disruption to customers.
Managed migrations cannot be postponed nor can affected cloud servers be opted out. Automated self-migrations are provided to allow you to control individual cloud server migrations at your convenience, within the provided self-migration window.
We have prepared a brief video that explains the migrations and walks you through an automated self-migration via the Rackspace Cloud Control Panel. As always, please don’t hesitate to contact our support team. We are here to serve you.
From the Rackspace Cloud Control Panel, select Live Chat then click Cloud Server Migrations
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License