I have been combing through AWS webpages but am not sure exactly what the NVMe storage is used for.
From my research NVMe stands for non volatile memory express but it also seems like NVMe does not persist through stopping of the instance? Kind of confusing naming.
Why would one use NVMe over regular SSD storage?
Ephemeral disks -- also called Instance Store volumes -- whether NVMe or SATA SSD or HDD -- don't persist across an instance stop/start because that action deallocates the hardware associated with the instance on stop and reallocates it on start. The instance store is also wiped, so that the next instance to receive that hardware can't access what you stored. In EC2, content on NVMe drives is also transparently encrypted, with service-managed keys, and the encryption keys are wiped when the instance is stopped.
These volumes do persist across a normal reboot, just not a stop/start. When you "stop" an EC2 instance, the billing for the instance also stops, because a stopped instance exists only logically -- not physically. A stopped EC2 instance is assigned to no physical equipment.
Some instance types use NVMe or SATA-based solid state drives (SSD) to deliver high random I/O performance. This is a good option when you need storage with very low latency, but you don't need the data to persist when the instance terminates or you can take advantage of fault-tolerant architectures. For more information, see SSD Instance Store Volumes
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
NVMe is very high performance, but instance store volumes are (by design) not fault tolerant and not intended for use with data that can't be replaced (though of course, you can RAID them on machine types with more than one ephemeral disk). Unlike EBS volumes, which are network-attached storage (offering both SSD and magnetic types), are redundant, and support snapshots, the instance store is physically inside the host machine and these don't support snapshots. Kind of a classic trade-off. They're excellent for swap space and temporary files as well as other purposes mentioned at the links above.
As noted in the EC2 documentation, not all instance types offer ephemeral disks. On many smaller instance types, this isn't a choice that you need to make.
The "non-volatile" in NVMe is a name given to the technology in the storage industry, not really applicable to the way they are used in EC2.
Related
I read somewhere "A modern server has 144GB RAM memory", is that 144GB all used as cache?
When we talk about a server's cache, does that mean the server's memory?
It all depends on the caching method utilized by the applications that run on the sever. There are numerous caching methods, but two methods frequently used are persistent Caching and In Memory Caching.
With persistent cache, the application stores cache values somewhere intended to be “permanent”, such as the file system, database or otherwise.
Whereas, with In Memory Caching, the application uses the memory (AKA RAM, in your question 144GB) to store data. Using this method, the data is intended to be semi-permanent and not persist across reboots, application recycles, or otherwise.
If, when coding, you allocate a new object, dictionary, list or otherwise, these objects are stored in memory. Additionally, all of a servers memory is not available to the applications that run on said server. All operating systems and processes that are installed use the same RAM. Therefore, it’s common for a device that has 4GB RAM to only have 2GB reasonably usable, as the other 2GB is used by the operating system. Of course, these numbers depend on a lot of factors.
I am interested in understanding the way in which the hardware resources (CPU, disk, network, etc.) of an AWS physical server is shared between different applications. Do people have experiences about inexplicable performance changes in services running on AWS that you have successfully attributed to another application sharing the physical resources? If so, how did you go about debugging this?
In particular, I am interested in more complicated interactions between the resources, such as CPU->Memory bandwidth. If you run 15 VMs on a single machine, you will surely have worse performance than if you ran 2 VMs.
Perhaps this is a more general question about Xen virtualization, but I don't know if there is some kind of AWS magic happening under the hood that I don't know about.
I am not sure if this is the right forum for this kind of question; if not, it would be helpful if you could point me towards a resource or another forum.
Amazon EC2 instances are not susceptible to "noisy neighbour" problems.
Based upon the Instance Type selected, the EC2 instance receives CPU, Memory and (for some instance types) locally attached disk storage. These resources are dedicated to the instance and will not be impacted by other users nor other virtual machines. (An exception to this is the t1 and t2 instance types.)
Specifically:
The instance is allocated a number of vCPUs. These are provided to the instance and no other instance can use these vCPUs (see note about t1 and t2 below). The EC2 Instance Type page defines a vCPU as:
Each vCPU is a hyperthread of an Intel Xeon core for M4, M3, C4, C3, R3, HS1, G2, I2, and D2.
The instance is allocated an amount of RAM. No other instance can use this RAM. There is no oversubscription of CPU nor RAM.
The instance might be allocated locally-attached disk storage, known as Instance Store or Ephemeral Storage. This disk storage does not persist when the instance is Stopped or Terminated, so only store temporary data or data that is replicated elsewhere.
The instance is allocated network bandwidth that is dedicated to that instance. No other instance can impact this network bandwidth. The network performance is based upon the selected instance type. Basically, larger instances receive more network performance.
None of the above factors are impacted by other instances (virtual machines) running on the same host.
t1 and t2 instance types
An exception to the above statement are:
t1.micro instances "provide a small amount of consistent CPU resources and allow you to increase CPU capacity in short bursts when additional cycles are available".
t2 instances provide burst capacity based upon a system of CPU Credits. CPU Credits are earned at a constant rate depending upon instance type, and these credits can be used to burst the CPU when necessary.
For both these instance types, I would assume that this burst capacity is shared between instances, so it is possible that CPU burst might be impacted by other instances also wishing to burst. The t2 instances, however, would make this 'fair' by only consuming CPU credits when the CPU did actually burst.
Dedicated Instances and Dedicated Hosts
Dedicated instances are "Amazon EC2 instances that run in a virtual private cloud (VPC) on hardware that's dedicated to a single customer." Basically, your AWS account will be the only account running instances on that host computer.
A Dedicated Host is a "physical server with EC2 instance capacity fully dedicated to your use. Dedicated Hosts allow you to use your existing per-socket, per-core, or per-VM software licenses, including Windows Server, Microsoft SQL Server, SUSE, Linux Enterprise Server, and so on." Basically, you pay for the entire host computer and then launch individually instances on the host (at no additional charge).
The use of a Dedicated Instance or a Dedicated Host has no impact on resources allocated to each instance. They would receive the same resources as when running as a normal Shared Instance.
As far as I know instance storage on ec2 is ephemeral ie it is lost when the instance is restarted. Is this different for high storage instances? if not it would seem that you would lose any database data stored on the instance upon restart.
Ebs backed volumes should be used for storage. Either you can take standard storage or iops. This will avoid any data losses due to instance going down.
When you attach the ebs volume to instance, make sure a entry is made to fstab file. So when you reboot the instance the volume is still attached. When you stop an instance, the data is present but the hardware is released while reboot is just like your system restarts.
All ephemeral storage is lost if the instance is stopped. You can still use a database with the high IO storage instances, but you will need to replicate the data between several instances to attain persistence.
Storage
Trying to launch an Ubuntu 13.10 Amazon AWS instance I’ve started with a General Purpose m1.medium instance with 1x410 GB instance storage. When I come to tab 4: Add Storage it says 8 GB on the root device and N/A on another device called Instance Store 0. However I can increase the root device to up to 1024 GB. I can also change the Instance Store 0 to an EBS and get 1024 GB there.
How am I able to select more space than I have available (410GB)? Am I charged for that? Where can I see how much of each of my instances are costing? If I set the root device to 410GB will I then be charged exactly as on the Amazon list?
Reserved Instance
I also have purchased a Reserved Instance. How can I verify that the EC2 instance I have just created is actually using my reserved instance?
Storage
You have two storage options with instances. EBS and Instance storage:
EBS is somewhat like an SAN volume. It exists outside of the instance and is accessed via dedicated ethernet (This is shared between instances based on IO priority). Volumes are billed based on the provisioned size. It does have some benefits over instance storage in that it can be easily snapshotted and moved from instance to instance. EBS limits are practical ones, while you can attach quite a few volumes (up to 1TB each) the available bandwidth will likely be saturated before you can take advantage of all of them.
Instance storage is a disk attached directly to the host hardware. Its included in the instance cost. But it should not be treated as persistent. You will loose any data stored on this volume if your instance is stopped or fails for any reason. This is because at each boot, your instance is assigned to available host in a pool instead of being locked to a specific host.
You can use both types of storage on any instance (Except micro, no instance storage available). Instance storage options however need to be set at launch and can't be changed later. EBS volumes can be added/removed at any time. In most cases, instance storage is disabled by default and needs to be explicitly enabled. Helps avoid the situation of "Why did all my data get deleted?"
Reserved Instance
Reservations are a billing feature. As long as your instance matches the parameters of the reservation you will be billed at the reservation rates. Should be able to verify this with account activity.
I've browsed through other questions on SO concerning backing up EC2, and it has provided me with a good basis, but I'm still a bit confused as to how I should approach my solution and develop a contingency plan. Most questions are fairly specific, but I have a pretty vanilla setup, and I think this information will be beneficial to future users. Let me provide my basic setup:
Basic small instance
Pushing files to S3
Running MongoDB
Running nginx
Now, due to the ephemeral nature of EC2, it's apparent that I need to bind my EC2 instance to EBS to ensure persistent storage. The reason I'm attempting to develop a contingency plan is that I'm worried my instance may disappear at any time (due to outages, etc). If my instance were to disappear, I'm concerned that I would have to spin up a new instance and reinstall all my applications before getting everything up an running again. A few questions:
How do I backup my instance to ensure that if it were to disappear, I could quickly bring it back up (preferably without having to reinstall all previous software)? I don't need a series of backups, just the previous days (or weeks) backup to ensure that a previous working version exists that can be started quickly.
If I use EBS instead of instance storage, it essentially acts in place of my hard drive right? So if I have MongoDB installed, I'm assuming the database it is writing to cab placed on EBS?
If I go with the small instance with 160 GB of storage and I use EBS, would I need to allocate 160 GB of EBS out of the gate, or is the 160 GB for instance storage only?
So, in summary, I would like a solution (either manual or automatic) that can create a snapshot of my EC2 instance to ensure that if it were to disappear, it could be reconstructed without having to spend the time to manually reconstruct everything.
In an ideal world, if my instance were to disappear, I could spin up an version of my instance with everything intact (to a point where things were backed up). Any resources or suggestions? Thanks in advance.
OK, here we go:
For backups:
Create your instance from one of the stock AWS images. Make sure it is an EBS-backed VM - depending on the size of the VM you pick, you'll get a volume assigned with 'n' GB of space, attached as the boot volume (/dev/sda1).
Configure the VM with whatever software you need, apply patches, tune for disk fragmentation, CPU consumption (task priorities, etc), and any other configuration you need that makes the VM tailored to your requirements.
Stop the VM and take a snapshot of the EBS volume, then restart it (re-assigning the Elastic IP is there is one). This is your backup snapshot - repeat as desired at whatever frequency you like. Remember to stop the VM when you snap it to prevent the OS writing to the volume whilst you're taking a copy of it.
For recovery:
Your VM will fail, eventually. You'll break something and render it damaged or inoperative, or the hardware it's running on will suffer a fault. It will happen.
When it does, terminate it (if it didn't self-terminate) and spin-up a new VM of the same type from the AWS stock list. Wait until it shows as 'Running', and then stop it.
Detach its EBS volume and delete it.
Create a new EBS volume from whichever backup snapshot you last created, and attach that new volume to the VM as /dev/sda1.
Start the VM and assign your EIP if appropriate.
About EBS storage:
It's a chunk of storage space. If you format it to look like a standard disk, you can use it exactly as you would a physical disk. Install stuff on it, point software at it for use as storage space, whatever.
you have two options: (BUT NOT EXACTLY AS YOU WANT ;( )
1- Have an 'external' EBS attached into your EC2 instance, and manually (you can do automatically through cronjobs), make snapshots from it ! But it's not what you want, why ? If your EC2 instance disappears, you will need to re-create all your environment again and re-attach your EBS... So it's a nice way of having backups of HUGE datas on your EC2, but your enviroment is destructed...
2- The best way, but not so perfect, is after you finished configuring your EC2, make a private AMI from it, so anytime you want you can launch more instances like that , from that AMI, so everything is cloned.... BUT the worst part of it, is that every time you change a configuration from the instance, you still need to make a new AMI, and every time you make a new AMI, you need to reboot your instance to grant data integrity on your new private AMI !
I recommend you to take a closer look into RESERVED EC2 instances, that have a better stability from normal ones. BUT YOU STILL CAN HAVE HARDWARE DISASTERS as normal instances too...