Establishing your cloud configuration
Use the Rackspace cloud core infrastructure services–Cloud Servers, Cloud Networks, Cloud Images, Cloud Block Storage, and Cloud Files–to create the core of your cloud configuration. After you’ve done that, take further action to make your cloud configuration secure, recoverable, and manageable.
The core infrastructure services are grouped here consistently with the categories introduced in Touring the Rackspace cloud, service by service:
- Core infrastructure in the Compute category discusses Cloud Servers and Cloud Images, introducing key concepts and basic actions for each.
- Core infrastructure in the Network category discusses Cloud Networks, introducing key concepts and basic actions.
- Core infrastructure in the Storage category discusses Cloud Block Storage and Cloud Files, introducing key concepts and basic actions for each.
Each service is described in terms of key ideas and specific actions:
- A concepts section introduces terminology and ideas to help you understand how you can use that service to optimize your cloud configuration.
- An actions section introduces concrete things you can ask the service to do, such as listing or creating or deleting virtual devices.
For details about how to accomplish those actions using the interface of your choice, begin at Interacting with the cloud.
Core infrastructure in the Compute category¶
Cloud Servers and Cloud Images are core infrastructure products in the Compute category.
Everything in the cloud begins with the computing power of Cloud Servers. After you create one or several cloud servers, you might need to add other services to create a configuration that is ideal for your workload.
- To learn key concepts about Cloud Servers, begin at Understanding Cloud Servers.
See also
Understanding Cloud Servers introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Servers.
- To see a list of actions that Cloud Servers can perform, visit Actions for Cloud Servers.
- To learn how to perform Cloud Servers actions using your choice of interface, begin at
- To learn key concepts about Cloud Images, begin at Understanding Cloud Images.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
- To see a list of actions that Cloud Images can perform, see Actions for Cloud Images.
- To learn how to perform Cloud Images actions using your choice of interface, begin at
Understanding Cloud Servers¶
Create one or many cloud servers to give yourself computing power in the Rackspace Managed Cloud.
If you create a server and decide that it doesn’t meet your needs (for example, if an application that you want to install is not compatible with the operating system), simply delete that server and create a new one.
You can create virtual cloud servers and OnMetal™ cloud servers:
Virtual cloud servers¶
Virtual cloud servers allow for configurations that handle general-purpose workloads and highly optimized workloads.¶
In the configuration above, a web instance server pulls data from the database. The server then communicates the data to the web through a public network. Dashed lines represent an optional branch of the configuration. In this case, you have the option to add more servers to account for greater workloads.
OnMetal™ cloud servers¶
OnMetal cloud servers are API-driven, which adds a performance boast.¶
OnMetal™ servers are highly optimized for specific workloads. OnMetal Compute is the best option for high traffic web servers, application servers, load balancers, and queue processing, while OnMetal Memory is better suited for large scale caches, index searches, and in-memory analytics. OnMetal I/O is optimized for large relational databases and Online Transaction Processing (OLTP) applications.
See also
Understanding Cloud Servers introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Servers.
Actions for Cloud Servers¶
You can perform the following actions against an active, running server in the Cloud Control Panel and the API.
Note: Rackspace technical documentation for each cloud service describes all the actions that can be performed with that service’s public API. However, because role-based access control (RBAC) makes it possible to allow some users to perform actions that cannot be performed by other users, your ability to perform the actions listed here depends on the specific permissions granted to the ID you use.
You can learn more about RBAC at Getting Started with Role-Based Access Control (RBAC).
To learn how to perform Cloud Servers actions by using your choice of interface, begin at the following sections:
- Cloud Servers and the Cloud Control Panel
- Cloud Servers and CLIs: rack, nova, and supernova
- Cloud Servers and APIs
Rebuild¶
The rebuild action rebuilds a server on the same physical host with a selected base image or saved snapshot. The image that you select must be within the same operating system family (Windows or Linux). Your public and ServiceNet IP addresses are retained. All data and disk formatting is lost.
See also
Learn how to perform this action with the interface of your choice:
Resize¶
The resize action enables a server to sized up or down within the same flavor class. The server is offline during the resize. A new server on a different physical host is reserved, and data is transferred from the source to the destination. After all of the data has been transferred and the public and private IPs have been remapped, the newly sized server is brought online. You have 24 hours to confirm the resize by checking to ensure that your server is working as intended. Confirming destroys the original source server, while reverting moves you back to it. After 24 hours, your resize is automatically confirmed.
Note: This action is not available for all flavor classes. Depending on the presentation of the disks, the option might be limited to up only or disallowed entirely.
Learn how to perform this action with the interface of your choice:
Rescue¶
Rescue mode builds a new server by using the current server’s image. If the system is unable to access the current server’s image, it uses the base image that server was built from. For example, if you have a server running a CentOS 6.5 snapshot with changes that you have created, the system tries to use that snapshot. If that snapshot is not available, the system uses the base CentOS 6.5 image.
When a server enters rescue mode, a temporary password is issued for logging in to the server. At this point, you can access the file system to recover or troubleshoot any issues. The exact process varies based on the operating system.
You can exit rescue mode at any time, returning your VM to its original state with any changes made. Rescue mode is automatically exited after 24 hours.
See also
Learn how to perform this action with the interface of your choice:
Reboot¶
The reboot action performs a soft or hard reboot of the server. A soft reboot is a graceful shutdown and restart of the server’s operating system. A hard reboot power cycles your server, which performs an immediate shutdown and restart.
See also
Learn how to perform this action with the interface of your choice:
Console¶
The console action opens a Java web terminal emulator window with a login prompt to the server over a secure HTTPS connection. This action gives you access to the server when access from SSH or RDP might be inhibited because of the server’s configuration or an error state. It might be necessary to install or update Java on the web browser used to access the console or to switch web browsers to ensure proper operation. The console is a backup means to access a server and should not be the primary method of access.
See also
Learn how to perform this action with the interface of your choice:
Delete¶
The delete action permanently deletes a server. Latent data is not recoverable from the disk of a deleted server.
See also
Learn how to perform this action with the interface of your choice:
Understanding Cloud Images¶
A virtual machine image (“image”) is a single file that contains a virtual disk that contains a bootable operating system.
Images come in several formats. The Rackspace Managed Cloud uses images in the Virtual Hard Disk (VHD) format. The VHD format was developed by Microsoft and is used by the Microsoft Hyper-V and Citrix XenServer hypervisors, among others.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Image properties¶
When we talk about images in the Rackspace Cloud, what we are really referring to is an image record with which the image data file is associated.
- An image data file can be a virtual hard disk (VHD).
- An image record consists of a set of image properties (also known as image metadata) that describes the image.
Image properties have several functions:
- They are used by the image owner to catalog the image. For example, public images provided by Rackspace have the
com.rackspace\_\_1\_\_release\_idproperty, which you can use to locate all available versions of a particular image. For images that you own, you can add your own cataloging properties so that you can efficiently search through your set of images. - They are used by the Cloud Servers API to determine whether a request to boot a server from a particular combination of image and flavor makes sense. For example, if the
min\_ramproperty of an image has a value of 512, then the specified flavor must provide at least 512 MB of RAM or the boot request is rejected. - They are used by the Cloud Servers scheduler to locate a host for a server. For example, the
hypervisor\_version\_requiresproperty specifies what version of XenServer the image expects to find when it is booted. - They are used by the hypervisor during the process of booting a server from an image. For example, the
auto\_disk\_configproperty indicates whether the hypervisor should expand the disk partition and file system found on the image to fit the server’s system disk. - They are used by Cloud Images in its handling of images. For example, if the
visibilityproperty indicates that an image is public, the image is included in each user’s image list.
A set of image properties is maintained by Cloud Images itself. Users (and in some cases, even system administrators) cannot modify these properties. Among these properties are:
checksum: The MD5 sum of the image data filestatus: The current state of the image. An image must be inactivestatus to be used to boot a server.owner: Indicates who owns the imageid: A universally unique identifier (UUID) assigned to this image
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Data immutability¶
An important aspect of how Cloud Images treats images is that image data is immutable. After the image data has been uploaded and the checksum and location are set, the image data cannot be modified. Thus you are guaranteed that whenever you boot a server from the image with ID da455637-9ff1-43e9-bb81-0f9e5498a913, you will always receive the exact same set of bits (and hence, the exact same operating system kernal and configuration) every time.
Consider this immutablity if you plan to create your own set of custom images. If you create an image and then discover, for example, that it’s missing a security update so important that you don’t want anyone to use the original image, you can’t simply swap out the image data. Instead, you must delete the original image and create a new one.
The new image will be assigned a different UUID. Thus, if you are writing scripts to use an image that contains the SuperOS operating system, it’s a good idea not to use the image UUID in your script. Instead, you should use some custom image property to identify an image as containing the SuperOS operating system, and then program your script to use the filtering abilities of the Cloud Images API to locate the image that you want.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Creating cloud servers from base images¶
You can create a cloud server from a cloud image that you created, or you can create it from an image that Rackspace created.
We maintain the images that we create; you are responsible for maintaining the images that you create.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Sharing images¶
Cloud images can be created as snapshots of a cloud server. They can also be imported using the Cloud Images Import feature.
No matter how you create an image, you can share it from one Rackspace cloud account to another, on an on-demand basis. This can be useful for many scenarios:
- Share an image of a new server that you have created or customized with a colleague for testing and comments.
- If you have multiple cloud accounts at Rackspace, for example to support different internal organizations or company branches, you can create a single central image and then share it with other accounts so they do not have to create one themselves.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Importing and exporting images¶
The Rackspace cloud runs on OpenStack, open-source software that runs in many data centers in addition to Rackspace data centers. In addition to running on open-source software, our cloud is open in the following ways:
- You can export a virtual machine image that you own out of the Rackspace cloud. You might want to do this, for example, if you’d like to store an image in a non-Rackspace location.
- You can import a properly prepared virtual machine image into the Rackspace cloud. You might want to do this if you want to move a workload into the Rackspace cloud from another cloud provider, or if you prefer to prepare your virtual machine images on your own hardware.
You can find more information about image importing and exporting in the Cloud Images FAQ.
Exporting an image¶
When you tell Rackspace Cloud Images to export one of your virtual machine images, the service retrieves the image from its Cloud Images storage location, prepares the image for export, and place sthe image in your Rackspace Cloud Files account. You can download it from Cloud Files to export it.
Not all images can be exported. Rackspace has licensing agreements with some providers of Rackspace public images that prohibit us from exporting any images of servers created from these public images. For example, Windows Server images cannot be exported.
Additionally, you cannot export an image that you do not own. For example, you cannot export a Rackspace public image or an image that has been shared with you.
Importing an image¶
When you use Rackspace Cloud Images to import a virtual machine image, Cloud Images stores your image data in a special location and creates an image record so that your image can be used to boot servers in the Rackspace cloud. Thus, to import an image, you must perform the following actions:
- Upload your image data to your Cloud Files account
- Create a Cloud Images import task
An image must consist of a single file in the VHD format, and the image import limit is 160 GB.
Export-import asymmetry¶
Although you can export a virtual machine image that you own (subject to licensing restrictions), you might not be able to import that image back into the Rackspace public cloud. Cloud Server flavors that have system disks exceeding 160 GB can be difficult to export. You might need to request a manual export from the hypervisor, which has a maximum import size of 160 GB. License restrictions prevent you from exporting Windows or RedHat Images.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
On-demand images¶
When you use the Cloud Control Panel or the Cloud Servers API to create an image of one of your servers, you get a copy of your server’s system disk. The image does not include any server state stored in memory, and for flavors that contain more than one disk, it does not include the data disk or disks. Thus an on-demand image is not really a server backup; it is more of a template that you can use to create other servers just like the one you already have.
When you create an on-demand image of your server, ensure that any running applications have their states saved to disk before you create the snapshot. Otherwise, these applications might not start correctly when you boot a server from the image. The time that such applications should be quiesced is fairly brief and can be monitored by observing your Cloud Server’s task state. For more information, see Using Task States with Server Imaging in Rackspace How-To.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Scheduled images¶
In addition to on-demand images, you have the ability to enable scheduled images on any servers for which the service is appropriate. The scheduled images service automatically creates a daily or weekly image of the server. Remember that a virtual machine image is not really a backup of a server, so whether scheduled images are an appropriate solution for you depends on your use case. For more information, see the Scheduled Images FAQ in Rackspace How-To.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Creating custom images from servers¶
The first time that you boot a cloud server, you’ll probably use an image supplied by Rackspace. We supply images of many different operating systems, all configured to run optimally in the Rackspace cloud.
Because the images supplied by Rackspace need to appeal to a wide range of customers with varying use cases, you might find that you have to manually install some of the packages that your applications require, and you might have unique configuration needs. For example, you might prefer to run httpd on port 8080 instead of its default port 80. If you have only one server, such customization might not be an issue, but if you’re using the cloud, you might find that you need to scale horizontally by creating more servers of the same kind.
There are two general approaches that you can take for this task: bootstrapping and baking.
- Bootstrapping: Whenever you need a new server, use a Rackspace base image to boot your server and then use a configuration management tool such as Chef or Puppet to install the extra packages and make the appropriate configuration changes.
- Baking: Use a Rackspace base image to boot your first server. Then install your packages on the server, make the appropriate configuration changes. When the server is set up properly, create an image of the server. Then when you need to scale horizontally, you can use the image to boot the new servers, which will contain all of your customizations.
Each approach has advantages and disadvantages. Which one you pick depends on your application and workflow needs.
- With bootstrapping, your cloud server is likely to boot quickly. Because so many users utilize the Rackspace base images, they tend to be cached close to most hypervisors and download quickly. After the server initializes, you must run your configuration management tool to install the software and modify the server before it is ready for your application.
- With baking, as soon as your cloud server initializes, everything is installed and configured, so your application should be ready to use. Because you’re using your own private virtual machine image, however, it’s unlikely that the image is cached anywhere, and it might take longer to download your image from Cloud Images to the host machine where your server will be built.
It’s also possible to combine the two approaches. Many people use bootstrapping to prepare and test a server, and then they bake an image of that server to use for deployments. One advantage to the combined approach is that you can benefit from updates Rackspace makes to its base images. For example, when a base image is updated to address a security vulnerability, you can use your bootstrapping tools to prepare an updated image of your particular application server.
See also
Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.
Actions for Cloud Images¶
You can perform the following actions to create and manage cloud images. Actions can relate to an image, image sharing, image tags, image tasks, and image schemas.
Note: Rackspace technical documentation for each cloud service describes all the actions that can be performed with that service’s public API. However, because role-based access control (RBAC) makes it possible to allow some users to perform actions that cannot be performed by other users, your ability to perform the actions listed here depends on the specific permissions granted to the ID you use.
You can learn more about RBAC at Getting Started with Role-Based Access Control (RBAC).
To learn how to perform Cloud Images actions by using your choice of interface, begin at one of the following topics:
Create an image backup¶
The create image action allows you to create an image of a cloud server (also known as cloning a server). When you create an image from a server, you are essentially saving that servers operating system for a later use. Creating an image can also assist in restoring a server from a saved image.
- To find out how to create an image using the Cloud Control Panel click here.
- To find out how to create an image by using the API click here.
Update an image¶
This action allows you to update an image that you own. Properties that can be updated includes the name of the image, any associated tags included in the image, the version of the operating system utilized by the sever, and minimum disk and ram requirements which affects which flavors can be used with the image.
- The Cloud Control Panel can update certain properties of a saved image. To do so, click on Saved Images under the Servers tab on the top of the page. On your list of saved images, click the cog next to the name of the image you wish to update. A drop down menu of attributes you can update will appear. Simply click the property you wish to update.
- To find out how to update an image by using the API click here.
Create an image member¶
This action allows you to add users to the list of members with whom the image is shared. This process is also called image sharing. You can find more information on image sharing on the page, :ref: cloud-images-sharing-models.
- To find out how to create an image member by using the Cloud Control panel click here.
- To find out how to create an image member by using the API click here.
Core infrastructure in the Network category¶
Cloud Networks is a core infrastructure product in the Network category.
- To learn key concepts about Cloud Networks, begin at Understanding Cloud Networks.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
- To see a list of actions that Cloud Networks can perform, visit Actions for Cloud Networks.
- To learn how to perform Cloud Networks actions using your choice of interface, begin at
Understanding Cloud Networks¶
Your cloud server configuration can include several kinds of networks, connected as appropriate for your needs.
Using Cloud Networks, you can connect virtual cloud servers with other virtual cloud servers, with OnMetal cloud servers, and, by using RackConnect, with dedicated servers operating outside the cloud.
You can manage the networking capabilities of your cloud servers in many of the same ways you manage your other networks, including PublicNet, ServiceNet, DNS, and security groups.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Typical use cases for Cloud Networks¶
Cloud Networks is especially useful for tightening security, increasing flexibility, and maintaining uninterrupted availability.
Secure east and west traffic
Get fully isolated, single-tenant Layer 2 networks designed to securely transfer sensitive information between servers located in the same region.
Enforce consistent network configuration
Program static routes, the gateway IP, and DNS servers into the Cloud Network API and have them automatically injected in your servers at boot time or when the network is attached. Use a Gateway Instances to connect your isolated Cloud Servers to the Internet.
VPN endpoint
Securely connect to remote resources via VPN. By programming static routes into your Cloud Networks subnet, you can ensure that all servers attached to your Cloud Network can access the remote networks connected via VPN.
High availability
Because multiple servers can share the same IP address, you can use fast IP address failover to enable high availability without making a separate API call.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Customer benefits from Cloud Networks¶
These are some of the ways in which Cloud Networks can be useful within your Cloud Servers configuration:
- Isolate your servers
You can create servers without public or private (ServiceNet) network interfaces, making them accessible only through Cloud Networks.
- Full control over IP addresses
Unlike PublicNet and ServiceNet, it is possible to assign specific Cloud Networks IPs to Cloud Servers, either at build time (by creating a port with a fixed IP) or to an existing server (by creating a port with a fixed IP and the existing server’s UUID as device ID). - Enforce consistent network configuration
Program routes, the gateway IP, and DNS servers into the Cloud Network API and have them automatically injected in your servers at build time or when the network is attached. Use a Gateway Instance to connect your isolated Cloud Servers to the Internet. - NAT or VPN endpoint or network segmentation
Combine Cloud Networks with Gateway Instances to connect your isolated Cloud Servers to the Internet. You can also use Cloud Networks to connect your isolated Cloud Servers to a VPN endpoint, enabling secure connectivity to resources outside Rackspace Cloud. Within Rackspace Cloud, you can also use multiple Cloud Networks to segment traffic.
- Cluster your applications
Cloud Networks includes full support for broadcasting and multicasting as required for some clustering technologies.
- Simplify network changes
You can make networking changes to existing deployments without having to rebuild your server.
- Automate network changes
By using the Cloud Networks API or Cloud Orchestration, you can develop custom software to automatically create networks and attach or detach servers based on workload requirements.
- Scale networks as you grow
You can attach up to 250 servers to a single cloud network. You can have up to 10 cloud networks per region.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Gateway Instances in Rackspace Cloud¶
A Gateway Instance is a Rackspace Cloud Server that routes traffic between the public internet and any other Rackspace Cloud Servers that do not have a public IP. A Gateway Instance is typically a virtual network appliance.
In the diagram below, the web server and database server do not have PublicNet attached. Instead, their outbound internet access is routed through the Gateway Instance by using Cloud Networks. This reduces exposure to attackers.
The web server also has public-facing services exposed by using a Cloud Load Balancer, which connects over ServiceNet.
Creating a Gateway Instance in Rackspace Cloud¶
From the Cloud Control Panel, navigate to Servers > Create Resources. On the Create Server page, choose a virtual network appliance image, such as the Fortinet Fortigate-VM. Under Advanced Options, ensure that Configure as Gateway is checked (as it is by default).
After the server is built, Rackspace’s post-build automation software (ServerMill) automatically performs all steps described in the section entitled “How to set up Internet access for servers without PublicNet or ServiceNet” within the Building servers without PublicNet or ServiceNet section of this guide.
Note: You can also use these Cloud Orchestration templates, which create the Gateway Instance and a Cloud Network with all needed configuration at the same time.
Building Servers Behind Your Gateway Instance¶
-
On the Cloud Control Panel server creation page, scroll down to Advanced Options.
-
Click Select Networks and uncheck PublicNet.
-
Select the Cloud Network that has the name of your Gateway Instance.
-
Optional Enable ServiceNet if you use Rackspace products
such as Cloud Backups or Cloud Files.
-
Click Create Server. The server builds without a public IP address. However, since NAT is configured on the Gateway Instance, the server can connect outbound to the Internet.
Accessing Servers Behind Your Gateway Instance¶
You can access servers behind the FortiGate-VM in a variety of ways:
- Using the Gateway Instance to forward remote access ports to the server behind the Gateway Instance.
- Configuring VPN on the Gateway Instance, then connecting to VPN. Once connected to VPN, you can access servers across the VPN via their Cloud Networks (private) IP addresses.
- Using the Emergency Console available on the Server Details page in the Cloud Control Panel.
Networking considerations for cloud servers¶
Cloud Networks are user-defined Layer 2 networks that are fully isolated and single-tenant, and offer users a way to securely connect their application servers.
IP addressing on Cloud Networks¶
Cloud Networks can be provisioned as either IPv4 or IPv6. Unlike PublicNet and ServiceNet, it is possible to assign specific Cloud Networks IPs to Cloud Servers, either at build time (by creating a port with a fixed IP) or to an existing server (by creating a port with a fixed IP and the existing server’s UUID as device ID).
Communicating securely between Rackspace Cloud Servers¶
Cloud Networks is recommended for all inter-server communication. Even though ServiceNet can also be used for server east-west (backend) connectivity, we do not recommend ServiceNet for that purpose because, unlike Cloud Networks, ServiceNet is multi-tenant.
You cannot NAT by using ServiceNet¶
To prevent spoofing, ServiceNet is filtered on the source and destination MAC, and destination IP. Thus, NAT will not work via ServiceNet. If you want to NAT, create a Gateway Instance and use Cloud Networks.
Additional Cloud Networks limits and features¶
Up to 10 cloud networks are supported per region, with 250 hosts per network. Cloud Networks can be attached to and detached from live servers, making it possible to change the network while rebuilding Cloud Servers. Cloud Networks also includes full support for broadcasting and multicasting required for some clustering technologies.
Throughput in Rackspace Cloud¶
Aggregate outbound bandwidth limits across all attached network interfaces (PublicNet, ServiceNet, and Cloud Networks) are defined for each Cloud Server based on its performance characteristics.
By choosing a flavor class and then a specific flavor within that class, you can configure your Cloud Server’s network speed within the range available to it.
In the Cloud Control Panel, use the slider to change network speed and other characteristics. For virtual Cloud Servers, the “Comparison Chart” link provides a detailed comparison of the configuration available for each flavor.¶
You can read more about how choosing a flavor class influences your cloud server’s configuration at Understanding flavor classes.
Working with networked Cloud Servers¶
As with physical servers, networked Cloud Servers are subject to relevant limitations and requirements. Throughput is called “Network” in the mycloud portal.
Network limits¶
- Only outbound throughput is limited. (Inbound traffic is not limited.)
- Throughput values listed in mycloud are theoretical maximums.
- There is no SLA for throughput.
- QoS is set across 2 sides of a bond, which means that any single layer 4 connection will get at most 1/2 of the maximum throughput advertised in the portal.
- There are 2 QoS buckets - one for PublicNet and one for ServiceNet/Cloud Networks.
- PublicNet throughput is exactly one-half of ServiceNet/Cloud Networks throughput.
Host networking on Cloud Servers is redundant, with bandwidth delivered over two separate bonded interfaces, each able to carry 50 percent of the aggregate limit.
Practical throughput example¶
With all those caveats in mind, let’s consider a theoretical cloud flavor whose throughput is listed as 4 Gbps in the portal. The following QoS limits apply:
| Flavor throughput | Max/L4 connection on Cloud Networks/ServiceNet | Max/L4 connection on PublicNet |
|---|---|---|
| 4 Gbps | 2 Gbps | 1 Gbps |
Rackspace recommends using multiple Layer 4 connections to maximize throughput.
Attaching or detaching networks from a server¶
You can attach networks to or detach networks from a Cloud Server through the Rackspace Cloud Control Panel or an API.
Attaching any single network to or detaching it from a live server results in a full reset of networking on the server. This reset causes a brief disruption in network connectivity on all network interfaces on the server and should be used with caution.
For OnMetal servers, attaching and detaching networks is not supported. Managed Operations customers may not detach ServiceNet.
Note
Detaching PublicNet and ServiceNet results in a permanent loss of the IPs attached to those networks.
Programming additional network config into your Cloud Network¶
You can add values such as gateway IP, DNS server IPs, and static routes into your Cloud Networks subnet and have them automatically injected to your Cloud Servers at build time, or when they are attached. For more details, see “How to set up Internet access for servers without PublicNet or ServiceNet” on the Building servers without PublicNet or ServiceNet page.
Adding public IPv4 addresses to Cloud Servers¶
Rackspace offers the ability to add IPv4 addresses to Cloud Servers for a fee.
Because of the global shortage of IPv4 address space, you might be asked to justify your request for additional public IPv4 addresses.
Rather than assign multiple IPv4 addresses on a single Cloud Server, we highly recommend using Cloud Load Balancers. Multiple Cloud Load Balancers can have the same Cloud Server in their pools.
If you still want to obtain an additional IPv4 address for your server, open a ticket through the Support section of the Rackspace Cloud Control Panel to get policy details and request approval. In some circumstances, we might ask you to provide an SSL certificate.
We cannot allocate more than four additional IPv4 addresses to a single server. This limit gives each server a maximum capacity of five IPv4 addresses, including the originally assigned public IP address.
Rackspace Cloud, IP addressing, netranges, and gateways¶
Rackspace Cloud uses static addressing. IPs are assigned as follows:
| Network | Address range | Gateway |
|---|---|---|
| PublicNet v4 | /24 for virtual servers, /30 for OnMetal | First usable IP in range (.1) |
| PublicNet v6 | /64 for virtual servers and OnMetal | fe80::def for virtual servers, varies for OnMetal |
| ServiceNet v4 | Varies, /17 or smaller for virtual servers, /30 for OnMetal | First usable IP in range |
| Cloud Networks | Can be IPv4 or IPv6. For v4, choose a range between /28 and /24. | Gateway IP and DNS Servers not defined by default. Must be defined for Gateway Instances to work properly. |
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Networking considerations for OnMetal servers¶
OnMetal servers are provisioned with redundant 10 GigE connections, which enables them to run high-bandwidth applications without data throughput issues.
Unlike virtual servers, OnMetal servers cannot add or remove networks.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Networking considerations for RackConnect¶
RackConnect® refers to the technology (F5 Big-IP Load Balancer, Cisco ASA firewall, Private Network) used to connect the cloud and managed network segments. In a hybrid enterprise configuration such as the one shown in the following figure, RackConnect® enables cloud-based and physical resources to cooperate behind the same load balancers and firewalls.
RackConnect enables cloud servers and physical servers to cooperate behind the same load balancer and firewall.¶
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
PublicNet in the cloud¶
Rackspace PublicNet connects cloud infrastructure components such as cloud servers, cloud load balancers, and network appliances to the Internet.
PublicNet is optimized for traffic flowing to and from the Internet (north-south traffic). It follows a direct addressing model, so all public IP addresses are directly configured on the servers without being Network Address Translated.
PublicNet is dual-stacked for IPv4 and IPv6. When you create a server with PublicNet, your server receives an IPv4 address and an IPv6 address by default.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
ServiceNet in the cloud¶
ServiceNet is an internal, IPv4-only multi-tenant network within each Rackspace cloud region. ServiceNet is optimized to carry traffic across servers within your configuration (east-west traffic). It provides servers with no-cost access to regionalized services such as Cloud Files, Cloud Load Balancers, Cloud Databases, and Cloud Backup.
You can configure a cloud server without ServiceNet, but Rackspace recommends that all servers be connected to ServiceNet so that they can access the aforementioned services.
ServiceNet is required for Windows cloud server activation and Managed Operations support.
The networks 10.176.0.0/12 and 10.208.0.0/12 are reserved for ServiceNet. Any servers that have ServiceNet connectivity will be provisioned with an IP address from one of these networks.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Building servers without PublicNet or ServiceNet¶
If a server is built without a PublicNet or ServiceNet network, it cannot access certain Rackspace products and services. However, it is possible to access some of these products (and the Internet) indirectly by using a Gateway Instance.
In the diagram below, the web server and database server do not have PublicNet attached. Instead, their outbound Internet access is routed through the Gateway Instance by using Cloud Networks. The web server also has public-facing services exposed by using a Cloud Load Balancer, which connects over ServiceNet.
- PublicNet provides a server with direct access to the Internet.
- ServiceNet provides a server with access to Cloud Databases, Cloud Load Balancers, Cloud Files, Cloud Backup, Managed Cloud Support, and Windows activation. This network is required for all Managed Operations customers.
- Cloud Networks provides single-tenant, inter-server communication and can provide indirect Internet access by using a Gateway Instance.
How to manually set up Internet access for servers without PublicNet¶
For added security, you may opt to build servers without PublicNet and/or ServiceNet.
Note: It’s much easier to build a Gateway Instance which performs all the steps below automatically.
-
Create a Cloud Network with the Neutron API or via the neutron CLI. You cannot create the network by using the Cloud Control Panel.
-
Within the Cloud Network you just created, create a subnet including the following information:
- IP version: We use version 4 in these examples, but version 6 will work. Only one IP version (4 or 6) may be created per Cloud Network.
- Gateway IP: We recommend specifying the first available IP in your network range, such as ‘.1’ for a /24 network.
- DNS servers: We recommend using the Rackspace DNS servers. Check the DNS configuration of your Cloud Servers to find the Rackspace DNS server IPs. Note that these vary per region.
- Allocation pool start and end: This is the pool of IPs that are assigned to any servers that you build in the network. Do not include the gateway IP in this allocation pool because you can’t assign the gateway IP manually if it’s in the allocation pool. To be safe, we recommend marking the 9th available IP as the start of the allocation pool. That allows you to manually assign the first 8 IPs in the range as needed.
- (Optional) host routes: These are additional static routes that are included in the routing table of any server connected to this subnet. Typically they are only needed when a VPN endpoint is a different host than the default gateway.
-
Create a fixed IP port with the Gateway IP that you specified in the previous step.
-
Build a Gateway Instance with PublicNet, and the fixed IP port that you created in the previous step. (ServiceNet is optional.)
-
Configure NAT and routing on the Gateway Instance. Consult your OS distributor’s documentation as necessary.
-
To test routing, build a server with the Cloud Network attached, but without PublicNet. (ServiceNet is optional.) Via the emergency console or ServiceNet, log in and verify that Internet access works. If it does not, verify your previous steps.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
DNS in the cloud¶
When you create a cloud server, it is assigned an IP address. You can access the server by its IP address, but you might prefer to associate the IP address with a domain name such as www.example.com and access the server by that name. You can connect an IP address and a domain name in the following ways:
- Use forward DNS to map a domain name to an IP address.
- Use reverse DNS to map an IP address to a domain name.
Forward DNS¶
Most DNS lookups are forward DNS lookups, in which a search is based on the DNS name of another computer as it is stored in a host (A) resource record. For example, when you ask your web browser to display www.example.com, you are asking for a forward DNS lookup. To enable users to locate your cloud server by forward DNS lookup, register a domain name, using the registrar of your choice. Then associate the domain name with the server’s IP address. You can use Cloud DNS to associate a domain name with a cloud server. In the Cloud Control Panel, select Networking > Cloud DNS > Create Domain:
Networking > Cloud DNS > Create Domain¶
For more information about using the Cloud Control Panel to manage DNS information, read Create DNS Records for cloud servers with the Control Panel.
You can also use the Cloud DNS API to manage DNS information programmatically. Begin reading about that in the Cloud DNS API Getting Started Guide.
Reverse DNS¶
For each cloud server that you create, you can assign a reverse DNS record. A reverse DNS record, also known as a PTR record, is used to assist in the resolution of a specific IP address to a fully-qualified domain name (FQDN) such as mail.example.com.
When you enter a domain name in your browser, the DNS system finds the IP address of the server with which the domain is associated.
A reverse DNS lookup works in the opposite direction. It establishes which domain is associated with the IP address.
Reverse DNS importance with hosted mail servers¶
Reverse DNS is especially important if you are running an application like a mail server on your cloud server, because many recipient servers reject, or mark as spam, all email that originates from an “unauthenticated” server.
This basically means that after the sending IP address is checked, if the reverse DNS does not match the sending domain, then it is classified as “unauthenticated”.
Note: Having a reverse DNS record attached to your domain does not automatically guarantee acceptance of email that originates from your domain by the recipient’s email server. Having a reverse DNS record for your domain can prevent email that originates from your domain from being immediately rejected. Non-matching or generic reverse DNS lookup settings are often rejected out of hand, but rejection can occur for other reasons.
Creating a reverse DNS record for your cloud server¶
You can set up a reverse DNS record through the Rackspace Cloud Control Panel by performing these steps:
- Log in to your Rackspace account.
- In the list of cloud servers, click the link for the server for which you want to add reverse DNS.
- On the Server Details page, click Add Record next to the Reverse DNS option.
While displaying details for a server, click Add Record to begin defining a reverse DNS record.¶
- In the group dialog box, enter the following information:
- Enter your domain name (for example mail.example.com) in the Hostname field.
- Set the Time to Live (TTL) value for the record.
- Click Save Record.
On the Server Details page, one record will be listed next to the Reverse DNS option. Click this link to display the details for the reverse DNS record that you just added.
After adding a reverse DNS record to a server, click 1 Record to confirm the association between the domain name and the server’s IP address.
Troubleshooting your reverse DNS record¶
If you need to verify or troubleshoot your reverse DNS record, you can use a tool called dig. You can learn about dig at the dig man page.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Security groups¶
A security group is a named container for security group rules. Security group rules provide Rackspace Public Cloud users the ability to specify the types of traffic that are allowed to pass through, to, and from ports on a cloud server.
Security groups are available to all customers through the Cloud Control Panel. Security Groups are available for PublicNet and ServiceNet, but not for Cloud Networks because Cloud Networks are already isolated by tenant.
To work with security groups, use one of the following portals:
Actions related to managing security groups are listed in Actions for Cloud Networks. You can read full details about API operations related to security groups in the Cloud Networks API documentation under Security groups operations.
To learn more about security groups, read Security groups FAQ and Use security groups to control traffic.
See also
Understanding Cloud Networks introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Networks.
Actions for Cloud Networks¶
You can perform the following actions to create and manage cloud networks. Actions can relate to a network, a subnet, or a port.
Note: Rackspace technical documentation for each cloud service describes all the actions that can be performed with that service’s public API. However, because role-based access control (RBAC) makes it possible to allow some users to perform actions that cannot be performed by other users, your ability to perform the actions listed here depends on the specific permissions granted to the ID you use.
You can learn more about RBAC at Getting Started with Role-Based Access Control (RBAC).
To learn how to perform Cloud Networks actions by using your choice of interface, begin at one of the following topics:
Network actions¶
- Retrieve a list of networks
- Create a network
- Show a network
- Update a network
- Delete a network
Subnet actions¶
- Retrieve a list of subnets
- Create a subnet
- Show a subnet
- Update a subnet
- Delete a subnet
Port actions¶
- Retrieve a list of ports
- Create a port
- Show a port
- Update a port
- Delete a port
Security group actions¶
- List security groups
- Create a security group
- Show a security group
- Delete a security group
- List security group rules
- Create a security group rule
- Show a security group rule
- Delete a security group rule
Core infrastructure in the Storage category¶
Cloud Block Storage and Cloud Files are core infrastructure products in the Storage category.
When you create a cloud server, storage of several kinds is allocated to that server based on the choices that you make.
Cloud Servers handles initial storage allocations; you can use Cloud Block Storage and Cloud Files to add more storage to your core infrastructure.
- To learn key concepts about Cloud Block Storage, begin at Understanding Cloud Block Storage.
See also
Understanding Cloud Block Storage introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Block Storage.
- To see a list of actions that Cloud Block Storage can perform, visit Actions for Cloud Block Storage.
- To learn how to perform Cloud Block Storage actions by using your choice of interface, begin at one of the following topics:
- To learn key concepts about Cloud Files, begin at Understanding Cloud Files.
See also
Understanding Cloud Files introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Files.
- To see a list of actions that Cloud Files can perform, visit Actions for Cloud Files.
- To learn how to perform Cloud Files actions by using your choice of interface, begin at one of the following topics:
Understanding Cloud Block Storage¶
Cloud Block Storage provides persistent block-level storage volumes for use with Rackspace cloud servers. Cloud Block Storage enables customers to scale their storage independently of their compute resources.
Cloud Block Storage is based on the OpenStack Block Storage service (project named cinder) and leverages open-source software and commodity hardware components to provide a low-cost alternative to traditional third-party SAN (storage area network) vendors. The underlying hardware consists of individual storage nodes that provide either standard or SSD disks in a protected RAID10 configuration. The distributed storage node system of Cloud Block Storage makes it horizontally scalable and free from monolithic failure scenarios.
Cloud Block Storage volumes can be provisioned in 1 GB increments, ranging from 100 GB to 1 TB in size. You can attach up to 10 Cloud Block Storage volumes per cloud server. Volumes are exposed to the hypervisor via iSCSI over a logical network and are presented to servers as virtual devices (local disks). After a volume is attached to a server, you must prepare the volume for use by partitioning, formatting, and mounting it through the server operating system.
Most servers can boot from a network-attached Cloud Block Storage volume. You can create a bootable Cloud Block Storage volume and launch a server instance from that volume. Booting from a volume enables diskless servers, new server configurations such as high RAM/low storage, and staging of common server images in Cloud Block Storage.
Tip
For instructions on using the Cloud Block Storage boot-from-volume feature, see Boot a server from a Cloud Block Storage volume.
The Rackspace technical documentation provides many more details about Cloud Block Storage. Begin exploring at Cloud Block Storage support.
See also
Understanding Cloud Block Storage introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Block Storage.
System and data disks for cloud servers¶
Different flavors of cloud servers are allocated different sizes and numbers of system and data disks.
To see what disk configuration is associated with each flavor, use the Cloud Control Panel to display the options available to you when you create a server.
For example, compare the disk configuration offered for a server with 60 GB of RAM in two different flavor classes:
- In the I/O flavor class, the configuration for this server includes a 40-GB system disk and 600-GB data disk (addressable as two disks).
- In the Compute flavor class, the configuration for this server includes a 50-GB system disk and no data disk.
System disk¶
The system disk, also called the boot disk, is the first disk from which the server will attempt to access and boot, much like the first physical hard drive plugged into a physical computer. Operating systems are installed on this disk by default. Data can be stored on a system disk, although it might have less capacity than any attached data disks.
Tip: To make a backup copy of a system disk, use Cloud Images to create a bootable backup.
Data disks¶
Data disk space is in addition to the system disk. Some Cloud Servers flavors do not have data disks assigned to them. If your server has a data disk, it is available to use for your application data, caching, or other purposes.
Data disks are provided as empty or raw disks in some cases, to provide you maximum flexibility in how you use them. Before you can use a data disk, you might need to format it, partition it, or group it into a software RAID group.
To prepare a data disk for use on a cloud server, follow the steps appropriate for that server’s operating system:
- For Linux, see Preparing Data Disks on Linux Cloud Servers.
- For Windows, see Preparing Data Disks on Windows Cloud Servers.
Tip: To make a backup copy of a data disk, use one of the following services:
- Cloud Backup for incremental backups, such as for disaster recovery
- Cloud Block Storage for portable backups, such as for relocation to new servers
See also
Understanding Cloud Block Storage introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Block Storage.
Local storage for cloud servers¶
Cloud servers are generally created with a given amount of local storage available to them in the form of one or more virtual hard disks. To best use this local storage, you should understand the different types of storage that are available.
Local storage technologies and terminology¶
The virtual hard disks allocated to a cloud server are backed by one of several different physical technologies, depending on how you choose to configure the server. Each storage technology has specific performance and cost characteristics.
Following is a high-level comparison of the technologies:
| Server type | Speed | Cost (relative) |
|---|---|---|
| SATA (Standard Cloud Servers) | Average | Lowest |
| SSD (I/O and General Purpose Cloud Servers) | Fast | Medium |
| PCI (OnMetal) | Fastest | Highest |
Measuring local storage performance: IOPS¶
One way to compare the performance metrics of storage is by using Input/Output Operations per Second (IOPS). IOPS reports the maximum number of operations per second the storage can handle. For the purpose of calculating IOPS, an operation is typically a read or write of data.
Several factors can cause the effective measured IOPS capability of a storage medium to fluctuate, including system load, background operations, and traffic from other virtual machines residing on the same physical disks. Because of this, consider any IOPS measurements you obtain as describing the upper limit of each local storage option’s range, identifying the highest possible IOPS that the device can process. Although this provides information about performance, it is important to remember that many factors can affect the IOPS rate during operation. IOPS is most useful as a basis of comparison if you can control all other factors and run identical workloads on systems that differ only in their storage configuration.
You can see the results of a performance experiment comparing Rackspace storage technologies at Determining Optimal Storage based on IOPS. In that experiment, Cloud Block Storage on SSD performed better than any other option tested. In a white paper on Cloud Block Storage (CBS) Benchmarking, performance quadrupled using Cloud Block Storage with SSD as compared to Cloud Block Storage with SATA.
Local storage types associated with Cloud Servers flavors¶
Choosing a flavor class for your server also means choosing what kind of local storage is available to that server.
- For Compute and Memory flavor classes, storage is entirely backed by Cloud Block Storage.
- For I/O and General Purpose flavor classes, storage is RAID 10 SSD.
- For Standard flavor classes, storage is RAID 10 SATA hard disk drives.
SATA local storage¶
Also known as spinning disk, Serial Advanced Technology Attachment (SATA) disks are the traditional hard drives with physical platters with which most people are familiar. Because of efficiencies in engineering and manufacturing over time, they can provide large capacities at relatively low prices. However, because of the physical spinning platters and moving write heads of SATA disks, they are slower than newer technologies such as SSD in many situations.
SSD local storage¶
Solid State Disk (SSD) uses persistent RAM technology to store data. Because SSD has no moving parts, locating and reading any given bit of data from the disk is extremely fast when compared to SATA, which is delayed by the movements of platters and write heads. This speed comes at a literal cost because SSD components are more expensive than SATA components.
Local storage types associated with OnMetal flavors¶
OnMetal Cloud Servers are backed by storage that complies with the Peripheral Component Interconnect (PCI) local bus standard.
OnMetal Cloud Servers offer the benefits of the following kinds of configuration:
- the elasticity of cloud computing
- the consistent performance of colocated hosting
When you create a server, if you make it an OnMetal server, you can choose one of the following flavor classes designed to support specific workloads:
- OnMetal I/O, optimized for databases
- OnMetal Memory, optimized for caching
- OnMetal Compute, optimized for CPU-intensive workloads
Every OnMetal flavor class provides 32 GB for the system disk. The OnMetal I/O flavor class also provides Dual 1.6 TB PCIe flash cards for the data disk.
For more information about OnMetal, see the following resources:
- OnMetal Cloud Servers
- OnMetal: The Right Way To Scale
- What is new with OnMetal Cloud Servers
- Create OnMetal Cloud Servers
See also
Understanding Cloud Block Storage introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Block Storage.
Block storage for cloud servers¶
Using Cloud Block Storage, you can add disk space to your cloud servers by attaching storage volumes.
Cloud Block Storage offers volumes in the following flavors:
- Standard (spinning hard disk, or SATA)
- High-performance (SSD)
Standard (SATA) volumes are suitable for customers who need traditional high-capacity storage at a low price. SSD volumes are suitable for customers who intend to run databases or other highly transactional or high-I/O applications in the cloud.
Cloud Block Storage for OnMetal servers¶
If you need more than 32 GB of storage, but do not have a requirement for the fast I/O normally provided by an OnMetal server, you can connect your OnMetal server to a Cloud Block Storage volume.
Connecting your OnMetal server to a Cloud Block Storage volume is particularly useful for OnMetal Compute and Memory v1 flavors.
To learn how to attach a volume to your OnMetal server, begin with Attach a Cloud Block Storage Volume to an OnMetal server.
See also
Understanding Cloud Block Storage introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Block Storage.
Backup methods¶
The virtual storage presented to your cloud server is backed by physical hardware in RAID 10 configurations. RAID 10 means that multiple physical disks in the same physical host would have to fail before there would be a chance of data loss on your server. Extensive hardware failure of this nature is extremely unlikely, especially within the protective environment of Rackspace data centers, but you might still be at risk for data loss caused by human errors or human malice.
Rackspace strongly recommends that you use one or more of the following methods to create and manage backup copies of your system and data disks, providing an extra layer of protection and recoverability for your cloud servers.
Backup method: snapshots¶
You can create snapshots (also known as saved images or server images) by using the API or Cloud Control Panel. Snapshots save a complete copy of your system disk. The image is saved in your account and you can build a new cloud server from the image.
Data disks are not captured when you create snapshots. Only the system disk is captured. You should use additional forms of backup if your data disks hold critical data that must be protected.
Backup method: Cloud Backup¶
Cloud Backup is a file-based backup application that enables you to choose which files and folders to back up from your server. If you have created a backup copy of your data, you can restore all your folders and files from the backup, you can restore individual files or folders from a given date, or you can restore to an entirely different server. For more information about Cloud Backup, begin at Rackspace Cloud Backup - Overview.
Backup method: Cloud Block Storage¶
You can use Cloud Block Storage to create and manage disk images that are portable among your cloud servers. Cloud Block Storage is part of our core infrastructure; learn more about it at Understanding Cloud Block Storage.
Backup methods: custom¶
You can establish a custom backup process by using a utility such as rsync, an open-source utility that provides fast incremental file transfer.
Storage-related offerings from Rackspace partners are listed in the Rackspace Marketplace. You might find one or more of these that directly addresses your specific needs.
See also
Understanding Cloud Block Storage introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Block Storage.
Actions for Cloud Block Storage¶
You can use Cloud Block Storage to perform the following actions.
Note: Rackspace technical documentation for each cloud service describes all the actions that can be performed with that service’s public API. However, because role-based access control (RBAC) makes it possible to allow some users to perform actions that cannot be performed by other users, your ability to perform the actions listed here depends on the specific permissions granted to the ID you use.
You can learn more about RBAC at Getting Started with Role-Based Access Control (RBAC).
To learn how to perform Cloud Block Storage actions by using your choice of interface, begin at one of the following topics:
- Cloud Block Storage and the Cloud Control Panel
- Cloud Block Storage and CLIs: cinder
- Cloud Block Storage and APIs
Create a volume¶
This action provisions a volume on a Cloud Block Storage storage node. As part of the volume creation request, you can specify the following values:
- Volume name
- Description
- Storage type (SATA or SSD)
- Volume size
Immediately after a volume is created, it cannot have any data written to it. To make the volume available for further operations, you must attach it to a cloud server.
Attach a volume to a cloud server¶
This action creates an iSCSI connection between the storage node on which the volume resides and the hypervisor of the cloud server specified in the attachment request.
After attaching the volume to a cloud server, you must partition, format, and mount it before you can use it. A volume can be attached only to a cloud server that resides in the same region as the volume.
Detach a volume from a cloud server¶
This action releases the iSCSI connection between the storage node and the cloud server hypervisor, and logically removes the volume as a usable disk for the server.
The detach request can succeed only if the volume is unmounted and is not in use by the host operating system.
Detaching a volume does not affect data on the volume. User data stored on Cloud Block Storage volumes is persistent and remains on the volume even after the volume has been detached from the server.
Create a snapshot of a volume¶
This action instructs the Linux Logical Volume Manager (LVM) Copy on Write (CoW) mechanism to create consistent point in time snapshots of Cloud Block Storage volumes.
Snapshots are stored redundantly (three copies) as objects in a backend master Cloud Files account. Snapshots use data deduplication at the volume level, so that only the data blocks that have changed since the last snapshot are uploaded the next time the volume snapshot is taken.
Although not required, we recommended that you detach a volume before creating a snapshot of it to avoid losing any in-flight data while the snapshot is being created.
Creating a snapshot of a Cloud Block Storage volume is a two-step process:
- Create the LVM snapshot on the local storage node.
- Upload that snapshot to Cloud Files.
After you receive an HTTP 200 status from the snapshot create request, you can safely reattach the volume and continue normal operation. It is not necessary to keep the volume detached while the snapshot is being uploaded to Cloud Files.
Create a volume from a snapshot¶
You can create new volumes by using existing snapshots as the source data. After you create a volume from a snapshot, you can switch the storage type (SATA or SSD) and increase the volume size. If you increase the volume size, you must also resize the cloud server file system (if that action is supported).
Volumes can be created only from snapshots that reside in the same region as the volume.
Delete a snapshot of a volume¶
Deleting a snapshot of a volume removes the objects associated with that snapshot from Cloud Files.
This action cannot be reversed.
Clone a volume¶
Volume cloning enables you to create a new Cloud Block Storage volume by using an existing volume as the source data. Although similar in some aspects to creating a volume from a snapshot (both use LVM CoW), volume cloning removes Cloud Files as the intermediary and copies volumes directly between storage nodes. This provides the ability to make faster copies of volumes. Additionally, clones are attachable volumes and thus are immediately usable upon creation. Clones differ from snapshots in this way, because a snapshot must be restored to a volume before it can be attached to a cloud server for use.
Delete a volume¶
This action deprovisions a volume and deletes the resulting data from the backend storage node. After a volume has been deleted, the volume receives a single-pass wipe with zeros before the blocks are returned to the storage pool and made available for other customers to use.
A volume cannot be deleted if it is currently attached to a cloud server or has a dependent snapshot.
Understanding Cloud Files¶
The Rackspace Cloud Files storage system provides a secure, network-accessible way to store an unlimited number of files. Each file can be as large as 5 gigabytes.
You can store as many files as you want and only pay for the storage space you actually use.
Cloud Files also provides a simple yet powerful way to publish and distribute content behind a content delivery network (CDN). As a Cloud Files user, you get access to this network automatically.
Cloud Files enables you to store and retrieve files and CDN-enabled content through a RESTful (Representational State Transfer) web services interface. There are also language-specific APIs that use the RESTful API and make it easy for integration into your applications.
The process for distributing content over the CDN is straightforward: authenticate, create a container, upload objects, mark the container as public, and begin serving that content from a powerful CDN.¶
See also
Understanding Cloud Files introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Files.
Ideal uses for Cloud Files¶
The Cloud Files service is an excellent storage solution for a number of scenarios and is well suited to numerous applications. Following are some of the ideal uses for Cloud Files:
- Backing up or archiving data
- Serving images and videos (streaming data to users’ browsers)
- Serving content with a world-class CDN (Akamai)
- Storing secondary, or tertiary, static, web-accessible data
- Developing new applications with data storage integration
- Storing data when predicting storage capacity is difficult
- Storing data for applications affordably
The Rackspace technical documentation provides many more details about Cloud Files. Begin exploring at the Cloud Files introduction page.
See also
Understanding Cloud Files introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Files.
Object storage¶
At its core, Cloud Files is an object storage solution and is not designed for high IOPS (Input/output Operations Per Second). Instead, Cloud Files is designed for consistent reliability of data. The primary function of Cloud Files is to ensure that your data is available when you ask for it. This works best with relatively static files, as opposed to files that are frequently updated.
An object is the basic storage entity and its metadata that represent the files that you store in Cloud Files. When you upload data to Cloud Files, the data is stored as-is (no compression or encryption) and consists of a location (container), its name, and optional metadata consisting of key/value pairs.
Objects are grouped into containers, and you can have any number of objects within a container.
See also
Understanding Cloud Files introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Files.
Web acceleration¶
When using Cloud Files for web acceleration, you can use a basic organizational structure to separate your content into different containers based on object type, such as images, css, javascript, videos, or uploaded content.
Building this structure enables you to quickly locate your objects when you need them.
Container management¶
A container is a storage compartment for your data and provides a way for you to organize that data. You can think of a container as a folder in Windows or a directory in Unix. The primary difference between a container and these other file system concepts is that containers cannot be nested.
You can create up to 500,000 containers under your account.
Using multiple containers¶
If you have an extremely large number of objects, it is most effective to store them in multiple containers. When writing large numbers of objects to a single container, the limit of 100 object write requests per second per container may reduce overall performance.
Labeling containers¶
When organizing your containers for an object storage solution, give each container a two-part name:
- Identify the container’s contents, such as the segment of the application accessing it.
- Attach an incremental number to plan ahead for multiple containers.
For example, if you begin with one container of data related to a personnel-management application, you might someday need multiple containers of data related to that application; labeling the first personnel-related container personnel-00000 makes your labeling standard extensible as your data collection grows.
Keeping a local database of container structure¶
If you have a large number of files, it might be useful to keep a local copy of your container structure and listing. You can do this in a local database, significantly reducing the chance of a naming conflict and location of a specific object. By keeping a local copy of your container structure, you can more easily update objects, if needed, without having to list all your containers to discover which one contains the relevant object. This can significantly reduce the preparation time required for updates.
Keeping a local database is most useful to customers using Cloud Files for an object storage solution, since these are frequently accessed programmatically and will also grow organically over time. This also applies to any site that allows for additional content, such as an uploads section, which may quickly grow beyond expectations.
Pathing¶
Because containers, and their objects, do not nest, there are applications which will fake a folder structure by adding a path to the beginning of the object name.
For object storage, this enables better subdivision of slow growing, closely-grouped data that you are unlikely to divide out again later.
For web acceleration, this enables pathing that displays in the browser. For example, a pathed object named ducks/funny/duckling.jpg would become
http://c123456.r02.cf3.rackcdn.com/ducks/funny/duckling.jpg
Tip: You can use CNAME records to link your Cloud Files container to a branded URL that you display instead of a CDN URL. To learn more about CNAMEs, check out Using CNAMEs with Cloud Files containers.
See also
Understanding Cloud Files introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Files.
Cloud Files tools¶
There are a number of tools and extensions designed to help you manage your Cloud Files. Following are a few of the available options:
- Rackspace CDN is a WordPress plug-in that allows any media in your WordPress uploads folder to be uploaded to Rackspace Cloud Files, powered by CDN. Once the file is uploaded, it is deleted from the local server. You can find more information about Rackspace CDN at Rackspace Cloud Files CDN.
- Django-Cloudfiles is an extension to the management system of the website framework, Django. Django-Cloudfiles enables you to synchronize the static content delivery of your Django-powered website to your Cloud Files account. You can find Django-Cloudfiles at GitHub.
- Media Manager is a plug-in that will mirror your media library to your Cloud Files CDN. All URLs to this content use the Cloud Files path when you insert them using the Media manager. You can import all of your media to the CDN.
See also
Understanding Cloud Files introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Files.
Actions for Cloud Files¶
You can use Cloud Files to perform the following actions.
To learn how to perform Cloud Files actions by using your choice of interface, begin at one of the following topics:
- Cloud Files and the Cloud Control Panel
- Cloud Files and CLIs: swift and swiftly
- Cloud Files and APIs
Create a Container¶
Before uploading any data to Cloud Files, you must create a storage container. Containers cannot be created within another container, however you can create up to 500,000 containers in your Cloud Files account. Each container can store an unlimited number of objects.
Delete a Container¶
All objects within a container must be deleted before the container itself can be deleted. Multiple containers allow for better threading of the deletion scripts.
Deleting a container is a permanent action and cannot be reversed.
Create or Update an Object¶
Each container can store an unlimited number of objects.
For large files support, Cloud Files enables you to upload multiple file segments and a manifest file to map the segments together. When uploading large files:
- Files larger than 5 GB must first be segmented into smaller files
- File segments should not be smaller than 100-200 MB
- Files larger than 10 GB cannot be served from the CDN
Copy an Object¶
You can copy an existing object to a new object in the Cloud Files storage system. The new object can be in the same container, but must have a different name from the original object. If the new object is located in a different container, you can either use the same name as the original or a new name.
Delete an Object¶
By deleting an object, you are permanently removing the object from the storage system (data and metadata). Deletion is processed immediately and cannot be reversed.
Updated 5 months ago