Category: Linux

AWS-Linux-EBS-to-EFS

아키텍쳐를 수정중에 EBS에서 EFS로 파일을 넘길일이 생겼다.

300G 가량의 대량의 파일이 있는 디렉토리를 sync 해야했다.

EBS는 GP2로 400G, 1200IOPS를 가진 볼륨이었다. 스냅샷에서 볼륨을 생성해서 4T로 확장하여 12000IOPS를 가진 볼륨에서 테스트를 진행하였다.

새벽에 먼저 싱크를 진행한 내용이 있는데 network out 이 40mb를 넘지 않았다.

싱크는

rsync -av /src /dst

로 진행한것 같았다. rsync 의 속도를 끌어 올리기 위해 테스트했으나 실패. 속도는 40mb 에서 더 이상 올라가지 않았다.

그래서 강구한 방법이 tar 를 이용한 데이터 이동이었다.

tar -C <src> -cf - . | tar -C <dst> -xf -

속도는 170mb 정도 그러나, 치명적인 단점이 존재했다. 소유권과 퍼미션을 가져오지 않는것이었다.

-_-; 파일이동이라 함은..소유권과 퍼미션을 그대로 가져가야하는데...그게 안됬다. 그래서 임시 방편으로

tar -cvf /dst/file.tar /src

명령어로 EBS의 데이터를 tar 로 압축해서 EFS로 저장하는 명령어로 작업했다.

이때 속도는 170MB 정도.. tar로 압축하지 않고 pipeline 으로 보냈을때와 동일한 방식이지만 소유권과 퍼미션을 유지할수 있는 방법이다.

그렇지만 속도가 마음에 들지 않았다.

물망에 rclone / rdiff-backup 가 있었다.

rclone 은 씅광님이 추천해줘서 오후내내 테스트를 했다. 그런데 속도가 너무 잘나오는데 문제는 퍼미션과 소유권을 가져올수 없는것이다.

그래서 승광님께서 주신 힌트로 테스트를 진행했다.

clone sync /src /dst --checkers 128 --transfers 128

속도는 놀라웠다. T3a.medium type의 네트워크 성능(Gbps) 이라 표기된 5G를 모두쓰는것이었다.

이렇게 network 를 모두 사용하는것은 처음이라 신기할정도로 rclone는 빨랐다.

300G 모두 sync하는데 1시간 30분밖에 걸리지 않았으니까..

그런데 여기서 rclone은 문제가 발생한다.

https://rclone.org/local/#filenames

Filenames

Filenames should be encoded in UTF-8 on disk. This is the normal case for Windows and OS X.

There is a bit more uncertainty in the Linux world, but new distributions will have UTF-8 encoded files names. If you are using an old Linux filesystem with non UTF-8 file names (eg latin1) then you can use the convmv tool to convert the filesystem to UTF-8. This tool is available in most distributions' package managers.

If an invalid (non-UTF8) filename is read, the invalid characters will be replaced with a quoted representation of the invalid bytes. The name gro\xdf will be transferred as gro‛DF. rclone will emit a debug message in this case (use -v to see), eg

인코딩 문제인데 이건...하...나중에 rsync 로 남은파일을 채워볼까 생각했지만 불확실성이 너무 컷다. 파일의 누락이 너무많았다

그래도 테스트는 그냥 진행했고 싱크속도 무지빠르고 쓸만했다.

그래서 이후에 소유권과 퍼미션을 넣어주는 작업을 궁리했다.

getfacl -R /src > file.list
sed 's/src/dst/g' file.list
cd /dst
setfacl --restore=file.list

4줄의 명령어로 소유권과 퍼미션을 그대로 가져오는 방법을 찾았다.

이제 인코딩 문제만 해결하면된다 생각했지만, 안정성의 문제때문에

tar로 압축해서 넘기를 방식으로 계속진행하기로 생각했다.

오늘 적당한 낚시와 어드바이스를 주신 승광님께 감사드린다!

Linux-ping-test

http://ping.pe/

세계 곳곳의 IPS에서 ping test를 해볼수 있는 사이트.

이사이트가 정말 좋은게....이미지 저장 기능을 지원한다.

http://i.ping.pe/x/O/img_xONzUz1e.png

이렇게 이미지를 저장해서 링크로 지원한다는 사실!

그리고 또

port 나 dig 를 지원하는데

이렇게 TTL까지 남은 값을 보여주므로...시안성이 폭발한다는거..

NCP-SSD-Server-IOPS

오늘 [7월] 네이버클라우드플랫폼 공인교육 - Professional을 다녀왔습니다.
교육을 받다보니 좀 흥미로운 내용이 있더군요.

NCP의 SSD VM은 최소 IOPS가 4000입니다.

블로깅을 하던때가 아니라서 포스팅이나 결과를 깔끔하게 정리한게 아니라 공개하긴 어렵지만 AWS에서도 비슷한 테스트를 한적이 있습니다.

EBS- GP2를 20개를 하나의 인스턴스에 붙여서 100 IOPS 인볼륨을 20개를 붙여서 2000 IOPS로 늘려서 디스크 자체의 퍼포먼스를 올리는 테스트를요.

이 테스트는 많은 엔지니어들이 장난식으로 테스트를 진행했고 유효한 결과를 얻은적이 있는 테스트 입니다. 물론 라이브 서버에 도입하기엔 부담이 따르고 리스크에 비해 얻을수 있는 장점이 크지 않다보니 테스트로만 끝낸적이 있습니다.

그런데 제앞에 10G의 기본 IOPS가 4000짜리가 나타난 것입니다.

NCP의 VM이 가진 제한이 볼륨 16개 까지 붙일수 있는데, OS 볼륨을 제외하면 15개 까지.

150G의 용량으로 60000 IOPS라는 계산이 나옵니다. 그럼 NCP 의 최대 IOPS는 얼마인지 볼까요?

NCP의 IOPS 계산은 1GB당 40IOPS가 증가합니다. 500GB 일때 20000 IOPS 그러니까 볼륨의 가성비는 10G일때 제일 높은셈입니다.

가성비가 제일 높은 볼륨 15개를 추가할 비용을 계산해보면 월 17280원이 추가되는군요.

그럼 월 17280 원으로 낼수있는 최대 성능을 테스트 해볼겁니다.

사실 객관성은 이쯤해선 망각해도 됩니다.
아무래도 서비스에선 사용하기 어려운 구성이니까요.

먼저 볼륨 15개를 인스턴스에 붙입니다.

그리고 아래 스크립트를 돌려서

#!/bin/sh
for VAR in `fdisk -l | grep "Disk /dev/" | grep -v xvda | awk -F: '{print $1}' | awk '{print $2}`';
do
(echo n; echo p; echo 1; echo 2048; echo; echo t; echo 8e; echo w) | fdisk $VAR
done
a=`fdisk -l | grep '/dev/xvd.1' | grep -v '/dev/xvda' | awk '{print $1}'`
pvcreate $a
vgcreate linuxer-lvm $a
lvcreate -l 38385 -n volume linuxer-lvm
mkdir /lvm
mkfs.xfs -f /dev/linuxer-lvm/volume
mount -t xfs /dev/linxer-lvm/volume /lvm

마운트 까지 완료했습니다.

[root@s1734ba4660a ~]# vgdisplay
--- Volume group ---
VG Name linuxer-lvm
System ID
Format lvm2
Metadata Areas 15
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 15
Act PV 15
VG Size 149.94 GiB
PE Size 4.00 MiB
Total PE 38385
Alloc PE / Size 38385 / 149.94 GiB
Free PE / Size 0 / 0
VG UUID YEEHFI-FpvU-fTmE-YnHx-9itm-mhH6-QUsz8j

vg도 잘만들어져서 마운트까지 정상적으로 됩니다.

속도 테스트하려니까 너무 귀찮아서..........................

으앙주금...

여러분 이포스팅은 언젠간 마무리 할테지만...

오늘은 아닌가 봅니다.

굿밤!

linux-유용한 명령어

7/6일 오픈카톡 대화에서 발췌

glances - top / htop 대용

yum install python-pip python-devel
pip install glances

lsof list open files

lsof 는 열려있는 파일리스트를 보여준다. 예를들어 pid 3222를 확인하려 한다고 하면 아래와 같이 쓰면 된다.

lsof -p 3222
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
httpd 3222 apache cwd DIR 202,1 278 96 /
httpd 3222 apache rtd DIR 202,1 278 96 /
httpd 3222 apache txt REG 202,1 553600 61998 /usr/sbin/httpd
httpd 3222 apache mem REG 202,1 26976 1392 /usr/lib64/libnss_dns-2.26.so
httpd 3222 apache mem REG 202,1 57296 1394 /usr/lib64/libnss_files-2.26.so
httpd 3222 apache mem REG 202,1 37032 35796 /usr/lib64/libnss_sss.so.2
httpd 3222 apache mem REG 202,1 62432 8533557 /usr/lib64/httpd/modules/mod_proxy_http2.so
httpd 3222 apache mem REG 202,1 2462992 86241 /usr/lib64/libcrypto.so.1.0.2k
httpd 3222 apache mem REG 202,1 158280 485506 /usr/lib64/libnghttp2.so.14.18.0
httpd 3222 apache mem REG 202,1 248888 8533556 /usr/lib64/httpd/modules/mod_http2.so
httpd 3222 apache mem REG 202,1 40152 8676027 /usr/lib64/httpd/modules/mod_cgid.so

awk 는 주로 sort 와 같이 사용된다.

220.122.174.19, 70.132.53.181 - - [06/Jul/2020:21:30:11 +0900] "GET /category/aws/ HTTP/1.1" 200 105327
220.122.174.19, 70.132.53.107 - - [06/Jul/2020:21:30:11 +0900] "GET /2020/06/aws-ec2-root-volume-resize-extending-linux/embed/ HTTP/1.1" 200 19832

위의 로그에서 IP 만 확인하고 싶다면

cat linuxer.name_access_log | awk '{print $1}'

같은명령어로 배열로 잘라서 출력할수 있다.

/ sed

ps -elf

ps afxuwww

ps afxuwww - 명령어는 전체를 다보여주면서 자식 프로세스까지 다보여준다...짱좋아

ps -ef -L

ss
tcp FIN-WAIT-1 0 1281 10.0.0.12:ssh 61.177.172.13:46933
tcp ESTAB 0 1280 10.0.0.12:ssh 61.177.172.13:40872
tcp ESTAB 0 0 10.0.0.12:ssh 61.177.172.13:48407
tcp ESTAB 0 0 10.0.0.12:57592 52.95.194.65:https
tcp ESTAB 0 1280 10.0.0.12:ssh 61.177.172.13:41761
tcp ESTAB 0 0 10.0.0.12:50144 52.95.195.99:https
tcp ESTAB 0 0 10.0.0.12:ssh 222.186.173.238:43018
tcp FIN-WAIT-1 0 1281 10.0.0.12:ssh 61.177.172.13:20460
tcp ESTAB 0 0 10.0.0.12:50104 52.95.195.99:https
tcp ESTAB 0 1280 10.0.0.12:ssh 61.177.172.13:19907
tcp FIN-WAIT-1 0 1 10.0.0.12:ssh 218.92.0.249:45695
tcp ESTAB 0 0 10.0.0.12:41014 52.95.195.109:https

tcpdump

ngrep - bpf filter가 되어서 L7 grep 가능

sar

iostate

strace / ftrace

NCP-CentOS7-to-CentOS8

NCP 에선 centos8을 지원하지 않는다. 그런데 yum update 를 해서 커널이 변경되면 정상적으로 부팅되지 않는다.

이런 내용들이 인스턴스를 생성할때 안내된다.

그런데, 어제 퇴근후 Meetup과정에서 KR-2 zone은 yum update 가 가능하다는 내용을 전달 받았다. 어쩐지 가끔 yum update 해도 정상적으로 부팅되는 인스턴스가 있더라니..

퇴근길 Meetup - 퇴근길 Tech Meetup 서버 관리 자동화 자료이다.

여기에서 이상함을 느끼고 여쭤봤더니 KR-2에서 하라고 하셨다..그래서 오늘작업의 힌트를 얻었다...

최신의 OS 를 사용하고 싶은건 엔지니어의 본능이 아닌가? 그래서 테스트를 시작했다.

How to Upgrade CentOS 7 to CentOS 8

준비물은 다음과 같다.

서버이미지 centos 7.3으로 생성된 인스턴스 한대다.

ACG-포트포워딩-root password 확인 이런 부분은 서버생성 가이드를 참고하자.

https://docs.ncloud.com/ko/compute/compute-1-1-v2.html

인스턴스를 생성하고 인스턴스에 접속하자 마자 할일은 yum update 이다.

yum update -y

업데이트를 마무리하면 epel repo를 설치해 사용할 수 있다.

yum install epel-release -y

epel을 설치하는 이유는 dnf 를 사용하기 위함이다. yum->dnf 로 패키지 설치 방법을 변경할거다.

yum install -y yum-utils rpmconf
rpmconf -a

rpmconf -a 를 입력하면 패키지의 conf를 업데이트 할지를 물어본다.

/etc/sysctl.conf
/etc/profile
/etc/shells
/etc/login.defs
/etc/nsswitch.conf
다섯개의 파일에 대해서 물어보는데 나는 모두 새로 인스톨하는것을 택했다. centos8 로 갈꺼니까.

package-cleanup --leaves
package-cleanup --orphans

다음은 패키지를 cleanup 하고, epel 을 설치한 이유인 dnf 를 설치한다.

yum install dnf -y

dnf 는 centos8 부터 기본적용된 rpm 패키지 관리 패키지인데 yum 에서 dnf로 변경됬다.
dnf 를 설치했다면 yum 을 지우자.

dnf -y remove yum yum-metadata-parser
rm -Rf /etc/yum

yum 을 지우고,

dnf install -y http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-repos-8.2-2.2004.0.1.el8.x86_64.rpm http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-release-8.2-2.2004.0.1.el8.x86_64.rpm http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-gpg-keys-8.2-2.2004.0.1.el8.noarch.rpm

이제 centos8의 repo를 설치한다.

dnf -y upgrade https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

epel7 을 epel8로 업데이트 한다. 이제 centos8 패키지를 다운받을 수 있다.

dnf clean all

dnf 캐시를 clean 한다.

rpm -e `rpm -q kernel`
rpm -e --nodeps sysvinit-tools

rpm 명령어로 커널을 지운다. 여기서 모든 패키지가 삭제되지 않기때문에 후처리가 좀 필요하다.

dnf remove kernel-devel-3.10.0-1127.13.1.el7.x86_64 kernel-devel-3.10.0-327.22.2.el7.x86_64 kernel-devel-3.10.0-514.2.2.el7.x86_64 redhat-rpm-config iprutils-2.4.17.1-3.el7_7.x86_64 sysvinit-tools-2.88-14.dsf.el7.x86_64 sysvinit-tools-2.88-14.dsf.el7.x86_64 python36-rpmconf-1.0.22-1.el7.noarch

후에 의존성이 걸릴 패키지를 미리 삭제한다. 이 경우 NCP centos7.3 인스턴스에 맞춰서 의존성 패키지를 삭제한것이다. 의존성 문제가 발생하면 더삭제 해줘야 한다. 부담감 느끼지 말고 막 날리자. 안되면 처음부터 다시하면 된다.

dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync

명령어로 centos8 패키지를 설치한다. 새로 설치되는 패키지들을 유심히 보면 el8.x86_64 로 끝난다 centos8 사용하는 패키지 명으로 RHEL8 이라는 뜻이다. centos8 패키지가 잘설치된다는 소리다.

Complete!

이 단어가 보이면 거의 다된거다.

dnf -y install kernel-core
dnf -y groupupdate "Core" "Minimal Install"

dnf groupupdate 로 Core 와 Minimal Install 까지 업데이트 해주면 이제 된거다.

[root@s17308f26023 ~]# uname -a
Linux s17308f26023 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@s17308f26023 ~]# cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)

리부팅을 아직 안해서 릴리즈는 올라갔으나, 커널버전은 centos7 이다. 이제 리부팅 해주자.

[root@s17308f26023 ~]# date
Wed Jul 1 15:50:15 KST 2020
[root@s17308f26023 ~]# cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)
[root@s17308f26023 ~]# uname -a
Linux s17308f26023 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 10 11:09:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

이제 NCP에서 Centos8을 올렸다!

차후 커널지원이나 업데이트에 따라서 OS가 정상작동하지 않을수 있다. 모니터링이 문제가 될거라 생각했는데 잘돈다...

Centos8을 NCP에서 사용하고 싶다면 한번 진행해 보시기 바란다.

읽어 주셔서 감사하다!

AWS-userdata-glusterFS-install

#!/bin/bash
(echo n; echo p; echo 1; echo 2048; echo; echo t; echo 83; echo w) | fdisk /dev/xvdf
mkfs.xfs -i size=512 /dev/xvdf1
mkdir -p /bricks/brick1
echo "/dev/xvdf1 /bricks/brick1 xfs defaults 1 2" >> /etc/fstab
mount -a && mount
yum install -y centos-release-gluster
yum install -y xfsprogs glusterfs-server
systemctl enable glusterd
systemctl start glusterd
Setenforce 0
sed -i 's/^SELINUX=./SELINUX=disabled/g' /etc/sysconfig/selinux && cat /etc/sysconfig/selinux echo " soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf
chmod 744 /etc/rc.d/rc.local

ec2 userdata glusterfs install 스크립트 입니다.

https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart

AWS-EC2-Root-volume-downsize-amazonlinux2-xfs

AWS-EC2-Root-volume-downsize-amazonlinux1-ext4

작업의 흐름은 위 포스팅을 참고하기 바란다.

지금 포스팅은 xfs grug2 를 사용하는 사용자를 위한 포스팅이다.

amazon linux2 에 소스(xvdg)와 대상(xvdf)볼륨을 연결한다.

디렉토리를 생성하고

# mkdir /mnt/new
# mkdir /mnt/org

파티션을 생성하고

# fdisk /dev/nvme1n1

파일시스템을 생성하고

# mkfs.xfs -f /dev/nvme1n1p1

마운트한다

# mount -t ext4 /dev/xvdf1 /mnt/new
# mount -t ext4 /dev/xvdg1 /mnt/org

rsync 로 데이터를 복사해주고

# rsync -av /mnt/org/* /mnt/new

싱크가 끝나면 마운트한 경로로 이동한다.

# cd /mnt/new

그리고 blkid 를 이용하여 UUID 를 확인한다.

/dev/nvme1n1: PTUUID="9986d28e" PTTYPE="dos"
/dev/nvme1n1p1: LABEL="/" UUID="030df8fc-fb40-4ba6-af3e-662df2f52270" TYPE="xfs" PARTUUID="9986d28e-01"
/dev/nvme0n1: PTUUID="83181c97-6d5e-43c9-9ede-e2f50ead5338" PTTYPE="gpt"
/dev/nvme0n1p1: LABEL="/" UUID="55da5202-8008-43e8-8ade-2572319d9185" TYPE="xfs" PARTLABEL="Linux" PARTUUID="591e81f0-99a2-498d-93ec-c9ec776ecf42"
/dev/nvme0n1p128: PARTLABEL="BIOS Boot Partition" PARTUUID="4908ae49-9d5b-423e-a23c-a507a47bacf5"

일반적으론 UUID가 있을거지만.. 그경우엔 UUID 를 넣어주자.

# xfs_admin -U 'uuidgen' /dev/xvdf1

명령어로 UUID 생성해서 넣어줄수 있다. UUID 가 보인다면 new / org 변수에 UUID 를 export 해주자 UUID 는 사람마다 다들테니 각각 잘확인해서 복붙하자.

# export new=’3a26abfe-67eb-49e4-922a-73f6cd132402’
# export org=’781f875d-4262-4f01-ba72-d6bd123785f5’
# sed -i -e "s/$org/$new/g" etc/fstab
# sed -i -e "s/$org/$new/g" boot/grub2/grub.cfg
# mount -B /dev dev
# mount -B /proc /proc
# mount -B /sys sys
# chroot .

위 명령어를 치면 /mnt/new 경로에서 지정한 UUID 로 fstab 안의 UUID를 변경하고 grub.cfg 안의 UUID 또한 자동으로 치환해줄거다. 그런다음 3개의 경로를 bind mount 하고 현재위치에서 chroot . 를 치면 chroot 가 현재위치로 변경된다.

# grub2-install /dev/xvdf

chroot 가 정상적으로 먹는다면 볼륨을 변경하면 정상적으로 잘부팅된다.

테스트 해보고 꼭 작업하길 바란다.

수고하시라!

AWS-EC2-Root-volume-downsize-amazonlinux1-ext4

AWS-EC2-Root-Volume-Resize-Extending-linux

위에서 확장한 볼륨을 축소 할거다.

축소할 인스턴스의 OS 는 amazon linux 1 로 ext4 의 파일시스템을 가지고 있고 grub1을 사용한다. 따라서 아래 과정은 amazon linux 2 에 맞지 않는다.

볼륨 확장은 엄청 간단하다. 콘솔에서 늘리고 명령어 두줄이면 쨘!
근데..축소는? 축소는...?축소는!!!!!!! 간단하지 않다.

20G -> 5G 로 축소할거다. 가즈아!!!!!!!!!! 축소하기 위해선 먼저 준비물이 필요하다.

축소할 인스턴스의 루트 볼륨 스냅샷
위에서 만든 스냅샷으로 생성한 볼륨하나
루트볼륨을 복사할 볼륨
그리고 작업할 인스턴스. amazon linux 1

간략하게 설명하자면 현재 잘도는 인스턴스는 두고, 스냅샷으로 볼륨을 만들어서 다른 인스턴스에 연결한뒤에 거기서 축소...실은 복사 작업을 한뒤에 인스턴스 중지후 루트 볼륨 교체를 진행할거다. 그럼 볼륨을 먼저 생성하자.

볼륨은 이런식으로 xvdf(new) / xvdg(org) 로 연결한다. 작업할 인스턴스는 amazon linux 1이다.

Disk /dev/xvda: 15 GiB, 16106127360 bytes, 31457280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/xvda1 2048 31457246 31455199 15G 83 Linux

Disk /dev/xvdf: 5 GiB, 5368709120 bytes, 10485760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/xvfg: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ADC2A980-D341-46D7-9DA4-3652574FACDF
Device Start End Sectors Size Type
/dev/xvdg1 4096 41943006 41938911 20G Linux filesystem
/dev/xvdg2 2048 4095 2048 1M BIOS boot

세개의 파티션이 연결된걸 확인할수 있다.

작업전에 먼저 복사 대상 볼륨에서 파티션을 만들고 파일시스템을 생성해준다. 아래스크린샷은 이해를 돕기위해 찍은것이다.

# fdisk /dev/xvdf -> p (현재파티션확인) -> n(파티션생성) -> p(생성된 파티션확인) -> w(저장)

파티션을 만들었으면 linux dd 명령어로 복사해줘야한다.

아직 볼륨은 마운트하지 않은 상태에서 org 볼륨의 블럭사이즈를 확인해야 한다.

e2fsck -f /dev/xvdg1 명령어로 먼저 파일시스템을 체크한다.

[root@ip-172-31-12-119 mnt]# e2fsck -f /dev/xvdg1
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 40330/1310720 files (0.1% non-contiguous), 392822/5242363 blocks

[root@ip-172-31-12-119 mnt]# resize2fs -M -p /dev/xvdg1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdg1 to 461003 (4k) blocks.
Begin pass 2 (max = 103395)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 160)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 4575)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/xvdg1 is now 461003 (4k) blocks long.

The filesystem on /dev/xvdg1 is now 461003 (4k) blocks long. 이부분에서 461003이게 현재 blockcount 다. 여기서 16MB 의 블럭사이즈를 계산해야 한다.

blockcount * 4 / (16 * 1024) 이렇게 계산해야 한다.

461003 * 4 / (16 * 1024) = 112.549560546875 로 계산되어 걍 올림해서 113이다. 이 16mb의 블록사이즈는 113개로...

dd bs=16M if=/dev/xvdg1 of=/dev/xvdf1 count=113 명령어로 블록단위 복사를 해줄거다.

[root@ip-172-31-12-119 mnt]# dd bs=16M if=/dev/xvdg1 of=/dev/xvdf1 count=113
113+0 records in
113+0 records out
1895825408 bytes (1.9 GB) copied, 29.3328 s, 64.6 MB/s
[root@ip-172-31-12-119 mnt]# resize2fs -p /dev/xvdf1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdf1 to 1310464 (4k) blocks.
The filesystem on /dev/xvdf1 is now 1310464 (4k) blocks long.

[root@ip-172-31-12-119 mnt]# resize2fs -p /dev/xvdf1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdf1 to 1310464 (4k) blocks.
The filesystem on /dev/xvdf1 is now 1310464 (4k) blocks long.

[root@ip-172-31-12-119 mnt]# e2fsck -f /dev/xvdf1
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 40330/327680 files (0.2% non-contiguous), 329605/1310464 blocks

정상적으로 복사가되면 resize2fs 와 e2fsck 가 먹는다. 그럼 이제 거의 다왔다.

마운트할 디렉토리를 생성한다.

# mkdir /mnt/new
# mkdir /mnt/org

파티션을 마운트한다.

# mount -t ext4 /dev/xvdf1 /mnt/new
# mount -t ext4 /dev/xvdg1 /mnt/org

마운트 확인한다.

df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 408K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/xvda1 15G 13G 2.3G 86% /
tmpfs 389M 0 389M 0% /run/user/1000
/dev/xvdf1 4.8G 20M 4.6G 1% /mnt/new
/dev/xvdg1 20G 1.3G 19G 7% /mnt/org

정상적으로 마운트가 됬다.

amazon linux 의 path는 uuid 가 아니라 label 기반이므로 그냥 복사한 파티션에 label 을 붙여 준다. 붙여 줄 라벨은 / 다.

# e2label /dev/xvdf1 /

라벨 지정이 완료 되었다면 blkid 를 이용해서 확인한다. 아래 화면은 이해를 돕기위한 내용이다.

# blkid
/dev/xvda1: LABEL="/" UUID="781f875d-4262-4f01-ba72-d6bd123785f5" TYPE="ext4"

그리고 grub install 을 해줘야한다.

먼저 마운트를 해줘야 한다.

#cd /mnt/new
# mount -B /dev dev
# mount -B /proc /proc
# mount -B /sys sys
# chroot .

제일 중요한 부분은 /proc 부분이다. mount bind 해주지 않으면 정상적으로 파티션 포지션을 불러오지 않는다.

chroot 까지 정상적으로 마쳐 지면 이제 거의 다왔다.
그냥은 안되고 몇가지를 수정해줘야 한다. 근래에 사용하는 aws 의 HOST가 변경되어서 볼륨 포지션이 좀 변경되었기 때문이다. amazon linux 1 에서는 /boot/grub/device.map의 수정이 필요하다. 하이퍼 바이저가 디바이스를 호출하는 이름이 변경된것이므로 수정하지 않으면 grub-install 이 불가능하다.

전) device.map 이 없을수도 있다. 없으면 걍 만들어 줘도 괜찮다.

#cat /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdf
(hd2) /dev/sdg

후)

#vi /boot/grub/device.map
(hd0) /dev/xdva
(hd1) /dev/xvdf
(hd2) /dev/xvfg
:wq!

변경을 완료하였다면 이제 grub-install 이 가능한 상태가 되었다.

# grub-install /dev/xvdf
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/xvda
(hd1) /dev/xvdf
(hd2) /dev/xvdg

이제 복구를 위해만든 인스턴스를 종료한다.

볼륨을 분리하면 정상적으로 분리가 된다. 이제 교체할 20G 볼륨인 인스턴스를 중지하고

원본 볼륨을 분리한다.

/dev/xvda 로 볼륨을 연결한다. 정상적으로 연결이 끝나면 인스턴스를 시작한다.

드디어 인스턴스가 떳다. 그럼 파티션을 확인해보자

[root@ip-172-31-43-226 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 4.9G 1.3G 3.6G 27% /

정상적으로 파티션이 보이면 축소가 완료된것이다.

OS마다 방법이 다르지만 centos6 amazonlinux1 / centos7 amazonlinux2 이렇게 동일할것이다. 참고하자.

읽어주셔서 감사하다!

좋은하루 되시라!

AWS-EC2-Root-Volume-Resize-Extending-linux

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

리눅스 볼륨 확장은 이 docs 를 참고하자. 먼저 오늘 테스트할 ami 는 amazon linux 1 이다.

[root@ip-172-31-43-226 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 7.9G 1.2G 6.6G 15% /

root 볼륨은 8G 로 1.2G를 사용중이다. 이걸 20G로 늘릴거다.

먼저 볼륨 태그를 잘확인한다.

amazon linux 1 은 ext4 에 /dev/xvda1 로 / 가 설정되고
amazon linux 2 는 xfs 에 /dev/nvme1n1p1 으로 / 가 설정 된다

확장 자체는 디바이스의 파티션을 지정해서 확장하므로 일반적으로 볼륨 하나당 하나의 파티션을 사용하는것을 권장한다. on-prem 처럼 하나의 볼륨에 여러개의 파티션을 사용한다면 확장은 힘들다.

볼륨수정을 눌러서 진행한다.

볼륨을 수정하면 optimizing 과정을 거쳐서 확장된다. 디스크를 사용중에도 확장할수 있으나, 안전한 작업을 위한다면 스냅샷을 생성하고 확장하자.

Disk /dev/xvda: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/xvda1 1 16777215 8388607+ ee GPT

/dev/xvda: 21.5 GB 볼륨이 확장된게 보인다.

현재 상태는 볼륨만 확장된것이고 파티션을 확장해야 한다.

# growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=16773086,end=16777182 new: size=41938910,end=41943006

amazon linux 1 의 경우엔 파티션이 xvda 로 보여서 xvda 의 첫번째 파티션은 1번을 확장한다.

amazon linux 2 의 경우엔 파티션이 nvme1n1p1 으로 보이므로 실제 명령어는

# growpart /dev/nvme1n1 1

로 명령어를 쳐야 한다. growpart 로 파티션을 확장하면 Disk label type: dos -> Disk label type: gpt 변경되고,

위처럼 디스크 라벨 부터 파티션 타입까지 변경된다.

fdisk -l 명령어로 확인하며 진행하자.

이제 다음은 파일시스템의 확장이 필요하다. 파일시스템 확장은 resize2fs 명령어로 확장한다.

# resize2fs /dev/xvda1
resize2fs 1.43.5 (04-Aug-2017)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5242363 (4k) blocks long.

그럼 볼륨 확장이 완료된다.

볼륨확장에 대해 정리하자면 이렇다.

실제 볼륨을 확장하고 파티션을 확장하고 파일시스템을 확장한다.

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 20G 1.3G 19G 7% /

정상적으로 확장된 파티션을 확인할수 있다.

xfs 에서 파티션 확장은 xfs_growfs 명령어를 사용한다. 참고하자.