AWS EBS 볼륨을 수정해보자

윤학·2023년 3월 21일
0

Aws

목록 보기
3/7
post-thumbnail
post-custom-banner

수정 이유는?

처음 EBS 볼륨을 설정하고 난 후 개발을 하다보면 처음 설정했던 볼륨의 크기IOPS, 처리량의 한계에 부딪힐 때가 있다. (나는 불륨의 크기 때문에 수정을 하였다.)

이럴 때 이전의 데이터들과 함께 볼륨의 크기를 늘려주거나 볼륨의 유형을 변경해주어야 하는데 AWS에서는 쉽게 할 수 있는 방법 2가지를 제공해줘서 실제로 부족할 때 적용해 보았다.

시작하기 전에.. 이전 상태들을 안전하게 스냅샷으로 생성해두는 게 좋다.

생성 방법은 따라하면 간단하므로 여기를 참고하자.

그럼 시작!!

1. 미리 생성된 볼륨 자체 수정

첫번째 방법은 이미 생성되어 있는 볼륨을 수정하는 것이다.

나는 이미 볼륨을 하나 생성하고 그 볼륨을 하나의 인스턴스에 연결을 해둔 상태이다.

이 때 수정하고 싶은 볼륨을 선택해보자.

그러고 원하는 볼륨의 유형크기성능을 지정해준다.

수정 후 다시 접속해서 확인을 해보면 30G -> 40G로 늘어난 것을 확인할 수 있다.

사실 문서에는 볼륨 수정을 한 이후 인스턴스에 접속해 볼륨의 파일 시스템을 확장 해주어야 한다고 나와 있는데 나는 이미 확장이 되어 있었다.

아마도 /etc/fstab파일에 있는 장치들은 자동으로 재부팅시 마운트 된다고 해서 확인해보니 해당 파일에 존재하였다.

근데 왜 이름이 저런가 해서 보니 장치 이름은 변경할 수도 있으니 장치 이름보다는 UUID를 사용하는 것을 권장하고 있고, 해당 UUID 및 옵션들을 찾을 수 있도록 장치마다 라벨명을 붙여준 것 같다.

그래도 한번 과정을 따라해보자!

1) 파티션 확인

먼저 sudo lsblk 명령어로 해당 볼륨의 파티션이 존재하는지 확인한다.
만약 파티션이 존재하지 않으면 여기를 참고하자.

나는 현재 xvda라는 루트 볼륨에 xvda1, xvda14, xvda15 총 3개의 파티션이 있다.
그 중 xvda1 파티션이 루트 폴더에 마운트 되어 있고 해당 파티션을 확장 시킨다고 해보자.

2) 파티션 확장

sudo growpart /dev/xvda 1

lsblk 명령어로 출력되는 결과에는 /dev/ 접두사가 생략되어 나오기 때문에 /dev/를 붙여주어야 하며, 1은 파티션의 번호이다.


만약 위와 같이 뜬다면 이미 볼륨 확장에 성공한 것이니 안심해도 된다.

3) 파일 시스템 확인

파일 시스템 확장은 파일 시스템 종류에 따라 명령어가 다르기 때문에 먼저 해당 파일 시스템의 종류를 확인한다.
df -Th

확장하려는 파일 시스템의 종류는 ext4이다.

4) 파일 시스템 확장

이제 파일 시스템 종류에 맞는 명령어를 쳐준다.
sudo resize2fs /dev/xvda1

/dev/xvda1이라는 이름으로 마운트 된 파일 시스템을 확장한다.

여기까지가 첫번째 방법이며 바로 두번째 방법을 알아보자.

2. 볼륨 분리 후 새 볼륨 연결

사실 이 방법은 이전에 한번 해보았는데 그 이유가 1번과 같은 방법으로 한번 진행하고 나서 다시 볼륨을 수정한다면 다음과 같은 오류가 난다.

이유는 동일 볼륨에 대해서 수정하려하면 optimizing 되어 있는 볼륨 상태가 in-use 또는 available 상태가 되도록 6시간 정도를 기다려야 한다고 한다.

하지만 AWS에서는 이 상황에서 볼륨 수정을 원하면 연결되어 있는 볼륨을 인스턴스에서 분리 시킨 후 새로운 볼륨을 연결하도록 권장하고 있다.

그럼 그 과정을 살펴보자!!

1) 볼륨 분리


이렇게 수정하려는 볼륨을 연결되어 있는 인스턴스로부터 먼저 분리를 시켜준다.

2) 볼륨 연결

이 과정 전에 연결 할 볼륨을 생성해야 하는데 생성해 놓은 스냅샷으로부터 생성을 하고 해당 볼륨을 연결을 한다.

연결을 원하는 인스턴스를 고르고 볼륨 이름을 정해주는데 루트 볼륨의 경우 권장 디바이스 이름인 /dev/sda1을 사용하자

그러고 다시 접속을 해 확인을 하면 볼륨의 크기가 잘 늘어난 것을 확인할 수 있다.

마치면서..

볼륨을 교체하는 작업은 문서를 잘 따라가면 쉽게 교체할 수 있었다.

알게된 점은 스냅샷으로부터 생성된 볼륨의 경우 백그라운드로 느리게 로드되는데 스토리지 블록에 접근하려면 먼저 S3에서 스토리지 블록을 가져와서 볼륨에 기록한다고 한다.

여기서 각 블록에 접근 시 I/O 작업 대기 시간이 증가할 수 있어 초기 성능 저하를 막으려면 볼륨 초기화를 진행하는 것을 알려주고 있다.

그러니 다음번에 볼륨 생성시에는 꼭 적용해 보기로...

참고

Request modifications to your EBS volumes
Replace a volume using a previous snapshot
Make an Amazon EBS volume available for use on Linux
Extend a Linux file system after resizing a volume
Initialize Amazon EBS volumes

profile
해결한 문제는 그때 기록하자
post-custom-banner

0개의 댓글