여기서 다루는 내용

· 들어가며
· 스냅샷 생성: As-Is
· 스냅샷 생성: To-Be
· 스냅샷 복원
· 마치며

들어가며

안녕하십니까. GS네오텍 최준승입니다.

오늘은 AWS에서 새로 나온 API 하나를 소개해 드리려고 합니다.
Amazon EBS adds ability to take point-in-time, crash-consistent snapshot across multiple EBS volumes

복수의 EBS 볼륨을 대상으로 “crash-consistent”한 스냅샷을 취득할 수 있는 API인데요.
하나의 인스턴스에 RAID로 묶여 있는 다수의 볼륨을 백업하는데 적합한 기능입니다.

기존엔 뭐가 불편했는지. 그리고 이번에 뭐가 간편해졌는지. 순서대로 살펴보도록 하겠습니다.

스냅샷 생성: As-Is

먼저 여러분이 특정 목적(?)으로 AWS 환경에서 RAID를 구성해서 쓰고 있고. 이 구성을 대상으로 백업이 필요하다고 가정해 보겠습니다.

제가 가끔 들여다보는 AWS knowledge-center에는 이렇게 하라고 적혀있습니다.
(`19년 6월 기준이며, 아마도 이 페이지 내용은 차후 변경될 수도 있습니다)
How do I create a snapshot of an Amazon EBS RAID array?

• RAID로 묶은 볼륨에 대한 모든 쓰기 작업을 중단하세요
• 캐시를 디스크에 플러싱하세요
• RAID로 묶은 볼륨을 언마운트하거나 연결된 EC2 인스턴스를 중지하세요
• 특이사항이 없는지 확인후, 각 EBS 볼륨의 스냅샷을 생성하세요

모두 맞는말이고. 여러 볼륨을 하나로 묶어 사용하는 RAID 특성상 응당 저렇게 하는게 맞습니다만.
실제 운영환경에서 저런 작업을 순서대로 진행하는것이 쉬운일일까요? 아마도 아닐겁니다.

수단이 심각한 문제가 된다면. 아마 백업을 포기하거나.
포기할 수 없다면. 별도 공유볼륨에 특정 경로만 주기적으로 백업하거나. 다른 방법을 썼겠죠.

이제 새로운 선택지가 하나 더 생겼습니다.
바로 이번에 나온 create-snapshots(create-snapshot 아님) API를 써서 백업하는 방법입니다.

스냅샷 생성: To-Be

새로 나온 API는 다음과 같습니다.
AWS API Reference – Actions – CreateSnapshots

3줄로 요약하면

• 필수 파라미터는 Instance-ID. 해당 인스턴스에 붙은 EBS 볼륨의 스냅샷을 생성합니다
• 부트 볼륨은 선택적으로 백업 대상에 포함시키거나 제외시킬 수 있습니다
• “crash-consistent”하게 스냅샷이 생성되며, 각 EBS 볼륨별로 스냅샷이 하나씩 별도로 생성됩니다

그럼 한번 해볼까요?
해보기 전에 기존 RAID 구성 과정을 짧게 훑고 지나가도록 하겠습니다.


$ ls -al /dev/sd*
lrwxrwxrwx 1 root root 7 Jun 5 04:52 /dev/sdb -> nvme1n1
lrwxrwxrwx 1 root root 7 Jun 5 04:52 /dev/sdc -> nvme2n1

$ sudo mdadm --create --verbose /dev/md0 --level=0 --name=jsc --raid-devices=2 /dev/sdb /dev/sdc
mdadm: chunk size defaults to 512K
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

두개의 EBS 볼륨으로 RAID 0 Array를 만들었습니다.


$ sudo mkfs.ext4 -L jsc /dev/md0
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=jsc
[중략]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

$ sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
ARRAY /dev/md0 metadata=1.2 name=jsc UUID=d6c40455:6466ae60:30b3a430:2019febc

파일시스템을 ext4로 만들고. 해당 Array값을 환경파일에 써줍니다.


$ sudo dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
$ sudo mkdir -p /mnt/raid
$ sudo mount LABEL=jsc /mnt/raid
$ df -h | grep raid
/dev/md0 20G 45M 19G 1% /mnt/raid

새경로를 만들어 마운트합니다. 10G 볼륨 두개를 스트라이핑해서 19G 크기로 마운트된것을 확인할 수 있습니다.


$ sudo fallocate -l 1G /mnt/raid/1Gfile
$ ls -al /mnt/raid/
total 1048600
drwxr-xr-x 3 root root 4096 Jun 5 05:12 .
drwxr-xr-x 3 root root 18 Jun 5 05:07 ..
-rw-r--r-- 1 root root 1073741824 Jun 5 05:12 1Gfile
$ md5sum /mnt/raid/1Gfile
cd573cfaace07e7949bc0c46028904ff /mnt/raid/1Gfile

1GB짜리 더미 파일을 만들어 넣고. (의미는 없지만) 체크섬값을 확인해 놓았습니다.

자, 이제 백업을 해봅시다.

※ Create Snapshot 메뉴에 Select resource type 항목이 새로 생긴것을 확인. 둘 중에서 Instance를 선택

※ 해당 인스턴스에 붙은 두개의 볼륨이 같은 시작시간으로 스냅샷이 각각 생성되었다

어때요? 참 쉽죠? 내부적으로 어떻게 동작하는지는 모르겠지만. 사용자 입장에서는 아주 쉽게 RAID 환경의 백업을 끝냈습니다.

여기서 약간 주의하셔야 할 부분은 스냅샷에 붙는 태그입니다.
어느 RAID 그룹의 볼륨 스냅샷인지. 마운트 포인트나 순서는 어떻게 되는지를 태그를 통해 구분할 수 있게 하는 것이 좋습니다.

그럼 다음장에서는 복원을 진행합니다.

스냅샷 복원

OS에서 마운트부터 해제하는게 순서겠지요.

$ sudo umount --verbose /mnt/raid
umount: /mnt/raid unmounted
$ sudo mdadm --misc --stop /dev/md0
mdadm: stopped /dev/md0


이어서 AWS 관리콘솔에서 EBS 볼륨을 Detach하겠습니다.

※ RAID 0으로 묶었던 두개 볼륨을 한꺼번에 Detach 수행

기존 볼륨해제가 완료되었습니다. 이제부터는 앞에서 생성한 스냅샷을 사용하여 복원을 진행해보겠습니다.

※ 각 스냅샷으로부터 새로운 볼륨을 하나씩 생성합니다. 총 2개의 EBS 볼륨을 생성

※ AWS 관리콘솔에서 기존과 동일한 순서와 마운트 포인트로 Attach 수행


$ ls -al /dev/sd*
lrwxrwxrwx 1 root root 7 Jun 5 05:38 /dev/sdb -> nvme1n1
lrwxrwxrwx 1 root root 7 Jun 5 05:38 /dev/sdc -> nvme2n1
$ sudo mdadm --assemble --scan /dev/md0
$ sudo mount LABEL=jsc /mnt/raid
$ df -h | grep raid
/dev/md0 20G 1.1G 18G 6% /mnt/raid
$ ls -al /mnt/raid
total 1048600
drwxr-xr-x 3 root root 4096 Jun 5 05:12 .
drwxr-xr-x 3 root root 18 Jun 5 05:07 ..
-rw-r--r-- 1 root root 1073741824 Jun 5 05:12 1Gfile
$ md5sum /mnt/raid/1Gfile
cd573cfaace07e7949bc0c46028904ff /mnt/raid/1Gfile


복원이 완료되었습니다. (의미는 없지만) 동일한 체크섬값의 파일이 존재하는걸 확인할 수 있습니다.

마치며

이것도 한번 생각해볼 문제입니다. AWS 환경에서 RAID 구성의 필요성이 있을까요?

여러분도 아시다시피 AWS같이 가상화된 환경(백업이 쉬운)에서는 RAID 1 구성을 권장하지 않습니다.
공식 문서에 보면 좀 다른 이유로 RAID 5나 6도 권장하지 않는다고 되어 있습니다. 그렇다면 결국 RAID 0이나 쓰라는 소린데.

스트라이핑 구성으로 볼륨 크기나 전체 성능을 병렬적으로 향상시키는 RAID 0 구성 또한
최근 EBS 볼륨 제약사항(크기/성능)이 점차 개선되면서. 필요성이 점점 옅어지는 과정에 있다는 생각이 들긴 합니다.

하지만 기존에 이미 부득이하게 RAID 구성을 했을수도 있고. 백업을 할수 없는것과 못하는 것은 또 다른 문제니까요.

만약 새로운 기능을 활용하셔야 하는 분이 있다면.
스냅샷 생성 과정에서 아주 약간의 I/O 지연이 발생할 수 있다는 점과 (off-peak에 수행 권장)
DLM과 연계하여 백업 정책을 만들 수 있다는 점도 팁으로 참고하세요.

그럼 마칩니다. 끝!