Tag Info

New answers tagged

0

I would not mix such different disks in a mirrored volumes. I would rather use frequent send/receive iterations to have consistent, point-in-time backups of the main volume.


0

Seems to me a perfectly acceptable setup if your spare writes to EBS (and you snapshot that), and you have some failover scenario, as obviously restoring your instance store cost time. What you describe was actually the only setup we had before we had EBS. People survived for years doing exactly that. Finally, Netflix moved away from EBS backed disks due ...


0

EBS is using networked storage for your EC2 instance's root device, it's easy to spin up an instance and create an AMI using EBS because the volume is already available outside your instance. EBS also allows for a larger root device -- greater than 8GB. Instance-store (or ephemeral) root devices are somewhat more resilient as they don't rely on a network ...


1

Note: I think that there's a typo and sudo mkfs.xfs -f /dev/xvdf should read sudo mkfs.xfs -f /dev/xvdb. Both of the approaches that you described are valid. There's absolutely no need to create a partition on an EBS block storage. What actually holds the files are filesystems. When you issue a command like sudo mkfs.xfs -f /dev/xvdb you will create a ...


1

Here's my suggestion: /dev/sda [root disk] filesystem mounted at / /dev/sdb [data disk] filesystem mounted at /var/www or /www /dev/sdc [log disk] filesystem mounted at /var/log Separating your application data to another disk is a good decision. If for some reason, e.g. faulty distro upgrade, your root disk becomes unbootable you could still be able to ...


0

Make sure there is no leading space in '/dev/sda' For some reason copying text out of the aws console often attaches a space in front of the string. A very annoying side effect that had me spinning my wheels for 15 minutes trying to get the primary drive on my production server remounted. I tried all of these solutions before figuring that out.


6

The amount of time it takes EC2 to build a snapshot is directly proportional to the number of modified blocks that volume has seen since the last snapshot. In the case of your journal, that sees a lot of write/delete operations, so it's not surprising that it would take a long time to snap. Keep in mind that these are truly block devices. They know nothing ...


0

I suspected for a while that human eyes might be involved in the approval. sometimes it is 3-4 minutes, other times almost 10 minutes. if my job only takes 10 minutes that's half of the run time waiting for launch. It is also too long for an automated patrol, unless there is an asynchronous feed to a central point of control and transmission delays are ...


0

I have been trying this for a while now, and there are still a number of issues with EC2 spot instances and attached storage. The volume you want to attach may not be in the same zone as the instance ? Zones cannot be specified at launch. Internally attaching with the init script will work, but is a little asynchronous so you will need to test for it or ...



Top 50 recent answers are included