Over the past few years, we’ve written several blog posts about various disaster recovery methods for your applications running atop of Cloud-A’s infrastructure. If you take a look at these various articles, which highlight software and tools to help you achieve your disaster recovery requirements, you’ll notice that there there is more than one way to skin this cat.
The method you use to backup and recover your applications and data should vary depending on the technical requirements of a given application and/or data store and your organization’s tolerance for downtime for that app or data store.
Let’s dig into three conceptual models for disaster recovery on Cloud-A. We’ve ranked these methods 1-5 by data resiliency, time to recover and cost.
We all know that backing up data is important. Whether it’s a corporate Windows file server, or our treasured family photos, we make sure that we can recover our data in the case of a hardware failure. Oddly enough, most folks tend to skip over their website data when considering their backup strategy.
Although WordPress is the most used CMS in the world, many users still struggle to find a good backup solution. Thankfully, using a combination of Cloud-A’s Bulk Storage and the popular Updraft Plus WordPress Backups plugin, automatically backing up and restoring your website is extremely easy and cost effective. This makes it an ideal solution for WordPress users of any skill level.
At Cloud-A we enable our users to signup and manage their own infrastructure, giving them full control to configure and secure their own instances, networks and storage as they wish. We like to provide tips, tricks and best practises to give you the information you need to ensure that your instances are secure. Here are a few best practises for hardening and securing your Linux instances on Cloud-A.
Eliminate Unneeded Service
Do not run any unneeded services such as FTP.
If you are running DNS, be sure to close it off from being an open resolver so that you do not become part of a DDoS attack.
Lock down SSH
Disable root login via SSH
Only allow specified IPs to connect via SSH
Only allow SSH Key based authentication – Do not allow password authentication
Whether it is for compliance purposes, protecting trade secrets, or safeguarding sensitive client information, data security is a priority for every organization in any industry. With the rapid adoption of public cloud environments, it is imperative to understand how cloud affects how you secure your data. At the most basic level, it is understanding which parties are responsible for the different layers of security, so to clarify how this works with Cloud-A, we have created the Guide to Securing Your Data with Cloud-A.
It is Cloud-A’s responsibility to ensure that our infrastructure is bulletproof and that we follow security best practises, but once a client launches an instance, they have free reign to manage their cloud infrastructure as they please.
Here are some best practices and client responsibilities for securing your data with Cloud-A
Password strength is the most basic layer of security in any scenario, but it is of the utmost importance. Weak passwords are a simple point of failure that the most amateur attacker can take advantage of. A strong password should be between 10 and 12 characters, it should have a mixture of uppercase and lowercase letters, as well as numbers and symbols. There are tools available to assist with creating and keeping track of your passwords.
Although the infrastructure that your Cloud-A instances reside on and the OpenStack platform that orchestrates and manages that infrastructure is built and managed with security as the top priority, it is the users responsibility to ensure that the drives of their cloud servers are protected. We recommend encrypting the drives (volumes) that are attached to your Cloud-A instances. Encryption is a great way to keep your valuable data safe at rest, as it make your data unreadable to any unintended recipient. For more details on configuration and benefits, you can check out our blog post: Encrypted Volumes: Linux Edition
Lock Down Security Groups
Cloud-A’s security group functionality allows you to create firewall rules that can be applied to your instances. Instances are launched with all of the ports locked down and you can create your own firewall rules that you can allocate to your instances. It is important to use inclusive firewall rules rather than exclusive. Exclusive firewall rules allow all traffic through except for the traffic matching the ruleset. Inclusive firewall rules do the reverse as they only allow traffic matching the rules through and block everything else. When creating your firewall rules, It is best practice to only allow internet access to servers that require it. You can use your internal networks created with Cloud-A’s virtual private networking to connect servers that do not require internet access.
Understand that Cloud Security is a Partnership
Once you launch an instance on Cloud-A, you have full control over that virtual machine. It is up to the end user, or the Cloud-A integration partner to manage that virtual machine, ensure that it is patched, updated and that it is used appropriately. There is a level of knowledge that is required to operate a server securely. If you do not have that level of knowledge in-house, we advise that you seek out an organization that can provide these services. Cloud-A can help recommend partners who can assist with these services. Many organizations with stringent requirements for data security require advanced security services such as intrusion protection and detection and live security monitoring. Cloud-A’s go-to security partner for these advanced security services is GoSecure.
A few months ago, we showed you how to associate a single public IP to your instance. For most use cases, this functionality does everything that you need. However, one request we find ourselves seeing occasionally is the desire to allocate more than one IP address from the same subnet to an instance, with the driver being that it provides the ability to have multiple public IPs pointing at a particular NIC/port. Currently, this requires some more advanced command line work.
We are often asked about whether or not you can attach additional storage onto instances. Occasionally the base disk size just won’t do, or you have special storage requirements. The answer is Volumes. You can think of Volumes like portable hard drives you can add to your server. The data remains on the volume even as you connect it to various servers (one at a time). A common use case is to attach a Volume for consolidated backups for multiple servers.
Volumes are ideal for adding additional storage for existing servers without having to pay for additional compute resources. So you can spin up a small VM and use volumes to supplement your storage requirements.
For example, provisioning a 512MB VM with 10GB of disk and using volumes to make up the next (20GB) tier’s disk of 30GB would only cost an additional $5 (20GB * $0.25). You aren’t charged for incoming traffic or the amount of I/O you do. You are simply charged for the amount of storage you have. This is measured by GBs of provisioned storage and charged at $0.25 / GB / month, or ~$0.0003 / GB / hr. This can enable huge cost savings by only provisioning exactly what you need.
Have a Cloud-A account (don’t have one yet?), and at least one instance spun up. You can follow the start of this post for how to get started spinning up a Windows instance on our platform.
In the modal window, enter a Volume Name, optional Description, select the Type (Regular) and your desired Size in GB. We’ll just make a small 2GB Volume for this demo. After hitting “Create Volume”, you’ll see a “Creating Volume” message while it is being provisioned.
Once you have your Volume created you need to Attach it to the desired Instance. Click Edit Attachments to open the Manage Volume Attachments window. Under Attachments you will see any Instances the volume is currently attached to. (It should be blank now).
Open the Attach to Instance dropdown and select the instance you wish to connect the volume to, then “Attach Volume”.
Just like that, your Volume is attached to your instance, and available to be formatted & mounted in the OS.
Formatting & Mounting Your Volume
Before you can make use of your volume in your operating system of choice, you’ll need to format the disk and mount it so you can start using it for storage. Below you’ll find some basic instructions for Linux and Windows instances that will get your disk mounted and ready.
For linux servers (ubuntu 12.04 is used in the example below), it’s a quick process using fdisk, mkfs and mount.
$ ssh ubuntu@<my-instance-ip>
$ sudo -i
$ fdisk /dev/vdb
# create new partition (n),
# primary (1),
# answer yes to start and end blocks to use entire disk.
$ mkfs.ext4 /dev/vdb1
$ mkdir /mount
$ mount /dev/vdb1 /mount
If you would like the Volume to be mounted on boot (permanently attached). You can add an entry in your /etc/fstab that looks something like the following.
/dev/vdb1 /mount ext4 defaults 0 2
For Windows servers (Windows Server 2008 R2 is used in the example), You can do it all from the console. If you’re still on the Volumes screen, you can click the link to the server, and then click the “Console” tab to get to it quickly.
Once logged in and set up, click on Server Manager – on bottom left next to the Start button. Then click on Storage and then Disk Management.
Right click the Volume you added (labelled Disk 1), and select New Simple Volume. That will launch a Wizard to format the new disk. Following the prompts and using the default values will be fine. Once it finishes formatting (this may take a few moments), you’re done!
If you flip back to your dashboard, you should see that the Status is “In-Use”. Success!
What is the max number of volumes that can be connected to any one server? As many as you like, it is bottlenecked by the OS that you’re connecting it to.
What are the smallest / largest size volumes? We have customers with volumes sizes from 1GB through to 10TB.
How are volumes metered? Usage is added up at the end of the month, and calculated based on $0.25/gb/month. Point in time snapshots are taken of usage, and added up for each second of use. i.e. day 1 you’re using 1GB, for the time of that day, you’re charged that much, day 30 you’re using 1TB, only the last day are you charged the 1TB amount for usage.
Are Volumes slow storage? No, Volumes are very fast! – SSD Backed storage, the same stuff that gives you blazing fast IO on your VMs.