In this video I will show you how you can replace a running EC2 instance with a larger one. You may want to do this if you find that you need bigger and better hardware to serve your website, or to move from a development system to a more powerful production system.
In this example my EC2 instance is an M1 Small which hosts a single WordPress website with about 500-700 hits per day. In the screencast I’m replacing it with an M3 Medium instance which really isn’t big enough to cope with the traffic.
I have since found that a C3 Large is a better fit. The total downtime to perform this depends on how big your current instance is. You can bring up a larger instance alongside a smaller one and then swap the Elastic IP over for minimum downtime.
Passive FTP connections should work out of the box in Plesk. If no other firewall or NAT is interfering with it.
I’ve recently noticed that when I install Plesk on Amazon EC2 every passive FTP connection fails with an error such as “Server sent passive reply with unroutable address. Passive mode failed.”
The reason for this mishap is twofold:
EC2 instances are behind a NAT, and therefore have an internal (unroutable) IP, and an external (public) IP. When a passive connection request comes in, ProFTP – Plesk’s default FTP Server – tells the connecting client its internal private IP address, and in turn quite rightly fails to connect to it.
On top of that, we need to make sure to open a range of ports we want to use for passive FTP connections and tell ProFTP only to use those.
I’ve just launched an EC2 instance from my own AMI. This time however I wanted it to have more storage so I increased the size of my disk space from 10 to 100GB.
Once the instance had launched I’ve noticed that – as before – only 10GB was actually available.
I’ve had this with other infrastructure before, and I knew that I had to extend the volume as well as the volume and the file system for the OS to recognise the extra space.
1
2
3
4
df-h
FilesystemSizeUsedAvailUse%Mountedon
/dev/xvde19.9G2.6G6.9G27%/
tmpfs1.8G01.8G0%/dev/shm
What puzzled me was the following error message when using the lvextend command:
1
2
3
4
5
lvextend-L+97G/dev/xvde
Pathrequired for LogicalVolume"xvde"
Pleaseprovideavolume group name
Run`lvextend--help'for more information.
Was I not using the command correctly? Had I miscalculated the space I had in addition? I checked again with fdisk -l:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
fdisk-l
Disk/dev/xvde1:107.4GB,107374182400bytes
255heads,63sectors/track,13054cylinders
Units=cylinders of16065*512=8225280bytes
Sectorsize(logical/physical):512bytes/512bytes
I/Osize(minimum/optimal):512bytes/512bytes
Diskidentifier:0x00000000
Disk/dev/xvdj:5368MB,5368709120bytes
255heads,63sectors/track,652cylinders
Units=cylinders of16065*512=8225280bytes
Sectorsize(logical/physical):512bytes/512bytes
I/Osize(minimum/optimal):512bytes/512bytes
Diskidentifier:0x00000000
Nope, I was right – but lvextend wasn’t happy.
The Solution
Amazon had already extended the volume – all I had to do was grow the file system:
1
2
3
4
5
6
7
resize2fs/dev/xvde1
resize2fs1.41.12(17-May-2010)
Filesystemat/dev/xvde1 is mounted on/;on-line resizing required
Amazon EC2 instances have seriously made my life a lot easier over the last year. And once you get the hang of the management console it’s actually not as scary as I always thought it would be 😉
I’d like to get away from annual contract bindings and “real” servers that could develop hardware faults. But if you wanted to run Plesk on top of CentOS then this was a bit of a headache – until Parallels launched their Plesk AMI on Amazon Marketpalce. With this release we get the convenience of running Plesk out of the box with a convenient one-click install!
I’ve just tried it and took some notes so I won’t forget. You can also take a peek at the KB Article provided by Parallels which also outlines this procedure:
Once you’ve created an EBS Volume in the AWS web interface and attached it to an EC2 instance, how do you actually use it on your virtual server?
Here’s how! The following commands assume you’re logged into your system as root. I’ve created a 13GB volume and attached it to my running instance.
Before we begin
Let’s get a quick overview of our file system before we get started:
1
2
3
4
# df -h
FilesystemSizeUsedAvailUse%Mountedon
/dev/xvde7.9G1.7G5.9G23%/
tmpfs296M0296M0%/dev/shm
Looks like right now I’ve only got one 8GB partition available. Let’s take a look at what else may be available to mount:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# fdisk -l
Disk/dev/xvde:8589MB,8589934592bytes
255heads,63sectors/track,1044cylinders
Units=cylinders of16065*512=8225280bytes
Sectorsize(logical/physical):512bytes/512bytes
I/Osize(minimum/optimal):512bytes/512bytes
Diskidentifier:0x00000000
Disk/dev/xvdj:14.0GB,13958643712bytes
255heads,63sectors/track,1697cylinders
Units=cylinders of16065*512=8225280bytes
Sectorsize(logical/physical):512bytes/512bytes
I/Osize(minimum/optimal):512bytes/512bytes
Diskidentifier:0x00000000
The second block tells us that an unused partition is at our disposal. That’s good news – let’s see how we can make that available for storage.
Find out what your EBS Volume is called
Depending on your Linux distribution, what you see in Amazon isn’t what your file system sees. Amazon may have told you that you’ve attached a volume as /dev/sdf, but your kernel may give it a different name – as seen with fdisk command above. Here’s another way to see your partitions using lsblk:
1
2
3
4
# lsblk
NAMEMAJ:MINRMSIZEROTYPEMOUNTPOINT
xvde202:6408G0disk/
xvdj202:144013G0disk
We can see that xvde is mounted on root (or /) and xvdj is not – that’s our new EBS volume. Let’s attach it so we can use it.
Format the EBS Volume
Before we do, we may have to format the partition. If you’ve used this EBS Volume before and it already contains data you don’t want to do this as it will – obviously – erase all your data. In our case however it’s a fresh volume so it needs formatting. This will take a moment, depending on the size of your volume:
Writingsuperblocks and filesystem accountinginformation: done
Thisfilesystem will be automatically checked every35mounts or
180days,whichever comes first.Usetune2fs-cor-ito override.
Nice! The above command formats our volume as ext3 filesystem and it’s now ready for use.
Mounting your EBS Volume
Let’s create a directory so that Linux can speak to the new partition. I’ll call mine “/storage” and mount the partition to it:
1
2
# mkdir /storage
# mount /dev/xvdj /storage
No news means good news. Let’s check what our file system looks like now:
1
2
3
4
5
# df -h
FilesystemSizeUsedAvailUse%Mountedon
/dev/xvde7.9G1.7G5.9G23%/
tmpfs296M0296M0%/dev/shm
/dev/xvdj13G161M12G2%/storage
Smashing! 12GB of usable storage has been attached to our EC2 instance, ready to be populated with tons of files.
EBS Volumes are persistent, which means that whatever is saved on it will remain intact, even if you terminate your instance. In fact, you can detach your volume and attach it to another running instance and start using your data. Here’s how:
Unmounting and reusing your EBS Volume
Rather than “force detaching” the volume in the web interface, let’s ask our instance to unmount it first. This is the equivalent of saying to Windows “Safely Eject my USB stick”:
1
2
3
4
5
6
# umount /storage
# df -h
FilesystemSizeUsedAvailUse%Mountedon
/dev/xvde7.9G1.7G5.9G23%/
tmpfs296M0296M0%/dev/shm
Make sure you’re not cd’d into your directory or you’ll get an error message that it’s “in use”. I’m also checking that I no longer have /storage in my file system.
You can now attach this volume to another instance, mount it again and see all your data on another server.