Showing posts with label EBS. Show all posts
Showing posts with label EBS. Show all posts

Tuesday, June 22, 2021

AWS : EBS Volumes : Attach and Mount on EC2

https://devopscube.com/mount-ebs-volume-ec2-instance/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html


  • lsblk
  • lsblk -f
  • df -h
  • less /etc/fstab


[ec2-user@ip-10-79-196-74 ~]$ lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

nvme0n1     259:0    0  150G  0 disk

├─nvme0n1p1 259:1    0    1M  0 part

└─nvme0n1p2 259:2    0  150G  0 part /

[ec2-user@ip-10-79-196-74 ~]$ lsblk -f

NAME        FSTYPE LABEL UUID                                 MOUNTPOINT

nvme0n1

├─nvme0n1p1

└─nvme0n1p2 xfs          77f1de26-38e6-4e1d-8a1e-baa1610669e6 /

[ec2-user@ip-10-79-196-74 ~]$ cat /etc/fstab


#

# /etc/fstab

# Created by anaconda on Mon Oct 28 17:51:10 2019

#

# Accessible filesystems, by reference, are maintained under '/dev/disk'

# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info

#

UUID=77f1de26-38e6-4e1d-8a1e-baa1610669e6 /                       xfs     defaults        0 0

[ec2-user@ip-10-79-196-74 ~]$ df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs         16G     0   16G   0% /dev

tmpfs            16G     0   16G   0% /dev/shm

tmpfs            16G   25M   16G   1% /run

tmpfs            16G     0   16G   0% /sys/fs/cgroup

/dev/nvme0n1p2  150G  6.5G  144G   5% /

tmpfs           3.1G     0  3.1G   0% /run/user/1000

[ec2-user@ip-10-79-196-74 ~]$

Thursday, June 17, 2021

Mount EBS to EC2

https://devopscube.com/mount-ebs-volume-ec2-instance/

sudo cp /etc/fstab /etc/fstab.bak

/dev/xvdf       /hdd2   ext4    defaults,nofail        0       0

EBS vs EFS - AWS - Elastic Block Storage vs Elastic File System

https://aws.amazon.com/getting-started/tutorials/create-network-file-system/

https://www.missioncloud.com/blog/resource-amazon-ebs-vs-efs-vs-s3-picking-the-best-aws-storage-option-for-your-business


EBS  --------> 1 EC2 Instance is mapped to EBS - Block Level Storage


EFS ----------> Multiple EC2 Instances - Mounted to this File System - Common across multiple Apps


The main differences between EBS and EFS is that EBS is only accessible from a single EC2 instance in your particular AWS region, while EFS allows you to mount the file system across multiple regions and instances.


S3 -->  S3 is Object Level storage. S3 is not limited to EC2, Its linked to CloudFront through which many Media etc are hosted there.


Thursday, April 1, 2021

EBS Volumes, AWS

 "Choose Storage"
EBS Volume Pros
Production Workloads
Highly Available - Automatically Replicated within a single Availability Zone to protect against H/W Failures
Scalable - Dynamically Upgrade Size of Volume
You can attach an available EBS volume to one or more of your instances that is in the same Availability Zone as the volume.
Storage Service Applications
BLOCK : EBS (Byte Level) - Transfers Data Fixed Size Block - Byte Level Interaction 
FILE : EFS (File Level) - File System Level Interaction with Disk
OBJECT : S3 (Object Level) / Glacier
3 Specific Block Store Offering
Instance Store  - Epheremal / Attached to Instance Host - No N/w Roundtrip - Physical Store - 1 Disk - Physical Disks Which are Local to Instances where EC2 is hosted.- Not replicated, No Snapshot
EBS - Persistent - Network Disk/Volume - Storage Volumes(Disk) attached to EC2 -Logical Store - Not real Piece of Disk (Its scattered across Many Disks)
EBS SDD
EBS HDD

Attach and Detach - Volume
Many Volumes are attached to Single Instance
AZ will be same - Replicated, Attach in same Instances in Same AZ

99.999%
0.1 to 0.2% AFR - Annual Failure Rate
We may loose 1/2 Out of 1000
So, We need to have Snapshot Service

Snapshot Service hosted on S3 which is Regional Service - Not specific to AZ
and has 99.9999999 Availability
For GP2 Instances,
 The gp2 storage type also has a base IOPS that is set when the volume is created. However, you don’t provide a value for the IOPS directly—instead, IOPS is a function of the size of the volume. The IOPS for a gp2 volume is the size of the volume in GiB x 3, with a minimum of 100 IOPS and a maximum of 16K IOPS( Max was 10K IOPS Earlier)
 How does this work? 
The gp2 volumes have a characteristic called burst mode.
To understand burst mode, you must be aware that every gp2 volume regardless of size starts with 5.4 million I/O credits at 3000 IOPS.
Well, as stated earlier, the gp2 volumes start with I/O credit that, if fully used, works out to 3000 IOPS for 30 minutes. 
The burst credit is always being replenished at the rate of 3 IOPS per GiB per second. 
Consider a daily ETL workload that uses a lot of I/O. For the daily job, gp2 can burst, and during downtime, burst credit can be replenished for the next day’s run.
Volume Type : General Purpose SSD (gp2)
Size (GiB) :33 (Min: 1 GiB, Max: 16384 GiB) 
IOPS : 100 / 3000
(Baseline of 3 IOPS per GiB with a minimum of 100 IOPS, burstable to 3000 IOPS)
Size (GiB) :34 (Min: 1 GiB, Max: 16384 GiB) 
IOPS : 102 / 3000
34 *2 = 102 Above Minimum Baseline
Burst is 3000 - > So , 3 * 1000 GB (1 TB) will have a minimum of 3000 So Burst does not Matter
Burst works on Concept of Credits - Max 5.4 Million IOPS
Burst is relevant for Smaller EBS having size < 1000 GiB (~1 TiB)
Kibibyte (KiB) 1024¹ = 1,024
Mebibyte (MiB) 1024² = 1,048,576
Gibibyte (GiB) 1024³ = 1,073,741,824
Tebibyte (TiB) 1024⁴ = 1,099,511,627,776
Pebibyte (PiB) 1024⁵ = 1,125,899,906,842,624
https://www.youtube.com/watch?v=1AHmTmCkdp8
https://docs.ukcloud.com/articles/other/other-ref-gib.html
https://aws.amazon.com/blogs/database/understanding-burst-vs-baseline-performance-with-amazon-rds-and-gp2
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html
EBS Volume Types :
    General Purpose SSD (GP2)
3 IOPS/16000 IOPS
Not for Latency Sensitive Applications
Moderately Expensive
Provisioned IOPS SSD (IO1)
50 IOPS Per GB
64,000 IOPS per Volume
99.9 % Durability
Most Expensive
Provisioned IOPS SSD (IO2) - New Version
500 IOPS Per GB
64,000 IOPS per Volume
Durability - 99.999 %
Same Price as IO1 but Durability is high as compared to IO1


Throughput Optimised  HDD (ST1)
Big Data , Warehouse 
Loads of Data and Needs to be accessed Frequently
Cannot be a Root Volume
500 MB per second per Volume

Lowest Cost - Cold HDD (Lots of Data , Slower)(SC1)
Cannot be a Root Volume
250 MB Per second per Volume

Burst  vs Baseline
Throughput - Size of Data - Number of bits to be read/written in 1 sec 
IOPS - Number of Read and Written Per second 

Azure - Pipeline - Add Approver for Stage

https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass