이 글에선 Proxmox 설치에 대해서 다룹니다.

준비물: Proxmox ISO 파일

Proxmox ISO 파일은 하기 링크에서 다운로드 받으실 수 있습니다.

https://www.proxmox.com/en/downloads/proxmox-virtual-environment/iso

1. ISO로 부팅 후 Install Proxmox VE (Graphical) 을 선택합니다.

보다 쉬운 설치를 위해 Graphical(GUI) 설치를 선택합니다.

2. EULA 에 동의합니다.

3. Proxmox OS가 설치될 Target Harddisk를 선택 후, Next를 누릅니다.

4. Country와 Time zone을 설정해줍니다.

5. 패스워드와 Email을 작성합니다. Email에 설정된 주소로 Proxmox 서버에서 중요한 알림을 발송하게 됩니다.

6. NIC, Hostname, IP, DNS를 지정해줍니다.

Management Interface: Proxmox의 웹 인터페이스 접속, API 통신, 클러스터 구성원 간의 통신 등에 사용되는 NIC을 지정해줍니다. 현재 체결되어있는 NIC은 좌측에 🟢표시됩니다.

Hostname (FQDN): Hostname + domain 주소로 작성합니다.

ex) hostname: pve-node01 / domain: hostway.co.kr 일 경우, pve-node01.hostway.co.kr

IP Address (CIDR): Proxmox Node에 부여할 IP를 Prefix, Gateway, DNS와 함께 작성합니다.

7. Summary에서 설정이 제대로 되었는지 확인 후, Install을 누르면 OS설치 후 재부팅이 됩니다.

8. 재부팅 후, Proxmox VE GNU/Linux를 선택합니다(별도의 조작이 없을 경우, Default입니다.)

9. shell, ssh, 웹콘솔 정상 접속이 되는지 확인합니다.

ssh: 22 port(default)

web console & API: 8006 port

상기 포트로 접근이 되지 않을 경우엔, 상단 방화벽 설정을 검토 합니다.(default open)

Proxmox Authenitcation 역할 기반 관리

역할 기반 권한 관리 시스템을 사용하여 모든 객체(VM, 스토리지, 노드 등)에 대한 세분화된 액세스를 정의할 수 있습니다. 이를 통해 권한을 정의하고 객체에 대한 액세스를 제어하는 ​​데 도움이 됩니다. 이 개념은 액세스 제어 목록이라고도 합니다. 각 권한은 주체(사용자 그룹 또는 API 토큰)와 특정 경로의 역할(권한 집합)을 지정합니다.

인증 영역

Proxmox VE는 Linux PAM(기존 Linux 계정), 통합 Proxmox VE(Web 계정) 인증 서버, LDAP, Microsoft Active Directory, OpenID Connect 등 여러 인증 소스를 지원합니다.

홈페이지 : Hostway Proxmox
문의 : Proxmox@hostway.co.kr

Proxmox Clstering

Proxmox Virtual Environment는 대규모 클러스터 노드 세트로 확장할 수 있습니다. (최대 32 노드) 클러스터 스택은 완전히 통합되어 있으며 기본 설치와 함께 제공됩니다.

Proxmox 클러스터 파일 시스템(pmxcfs)

Proxmox VE는 Proxmox가 개발한 데이터베이스 기반 파일 시스템인 고유한 Proxmox 클러스터 파일 시스템(pmxcfs)을 사용 합니다.

Proxmox 클러스터 파일 시스템(“pmxcfs”)은 구성 파일을 저장하기 위한 데이터베이스 기반 파일 시스템으로, corosync를 사용하여 모든 클러스터 노드에 실시간으로 복제됩니다 . 이를 사용하여 모든 Proxmox VE 관련 구성 파일을 저장합니다.

파일 시스템은 모든 데이터를 디스크의 영구 데이터베이스 내부에 저장하지만, 데이터 사본은 RAM에 상주합니다. 이는 현재 128MiB인 최대 크기에 제한을 가합니다. 이는 여전히 수천 대의 가상 머신 구성을 저장하기에 충분합니다.

이 시스템은 다음과 같은 장점을 제공합니다.

• 모든 구성을 모든 노드에 실시간으로 원활하게 복제
• 중복된 VM ID를 방지하기 위해 강력한 일관성 검사를 제공합니다.
• 노드가 쿼럼을 잃었을 때 읽기 전용
• 모든 노드에 대한 Corosync 클러스터 구성의 자동 업데이트
• 분산 잠금 메커니즘이 포함되어 있습니다

라이브/온라인 마이그레이션

통합된 라이브/온라인 마이그레이션 기능을 사용하면 최종 사용자 측에서 다운타임이나 눈에 띄는 영향 없이 실행 중인 가상 머신을 한 Proxmox VE 클러스터 노드에서 다른 노드로 옮길 수 있습니다.

관리자는 웹 인터페이스나 명령줄에서 이 프로세스를 시작할 수 있습니다. 이를 통해 유지 관리를 위해 호스트 시스템을 오프라인으로 전환해야 하는 경우 다운타임을 최소화할 수 있습니다.

Live Migration이 작동하려면 몇 가지가 필요합니다.

• VM에는 마이그레이션할 수 없는 로컬 리소스가 없습니다. 예를 들어, 현재 통과하는 PCI 또는 USB 장치는 라이브 마이그레이션을 차단합니다. 반면 로컬 디스크는 대상으로 보내면 마이그레이션할 수 있습니다.
• 호스트는 동일한 Proxmox VE 클러스터에 있습니다.
• 호스트 간에는 작동하는(그리고 안정적인) 네트워크 연결이 있습니다.
• 대상 호스트에는 Proxmox VE 패키지와 동일하거나 더 높은 버전이 있어야 합니다. 때로는 반대로 작동할 수도 있지만, 보장할 수는 없습니다.
• 호스트는 유사한 기능을 가진 동일한 공급업체의 CPU를 가지고 있습니다. 다른 공급업체는 실제 모델과 구성된 VM CPU 유형에 따라 작동 할 수 있지만 보장할 수는 없습니다. 따라서 프로덕션에서 이러한 설정을 배포하기 전에 테스트하세요.

독특한 멀티마스터 디자인

클러스터 관리를 간소화하기 위해 모든 노드에서 클러스터 전체에 걸쳐 유지 관리 작업을 수행할 수 있습니다. 통합 웹 기반 관리 인터페이스는 클러스터 전체의 모든 KVM 게스트와 Linux 컨테이너에 대한 깔끔한 개요를 제공합니다. GUI에서 VM과 컨테이너, 스토리지 또는 클러스터를 쉽게 관리할 수 있습니다. 별도의 복잡하고 값비싼 관리 서버를 설치할 필요가 없습니다.

홈페이지 : Hostway Proxmox
문의 : Proxmox@hostway.co.kr

웹 기반 관리 인터페이스

Proxmox VE는 사용하기 쉽습니다. 통합 그래픽 사용자 인터페이스(GUI)로 모든 관리 작업을 수행할 수 있으며, 별도의 관리 도구를 설치할 필요가 없습니다. 중앙 웹 인터페이스는 ExtJS JavaScript 프레임워크를 기반으로 하며 모든 최신 브라우저에서 액세스할 수 있습니다. 관리 작업 외에도 각 노드의 작업 내역 및 시스템 로그에 대한 개요도 제공합니다. 여기에는 백업 작업 실행, 라이브 마이그레이션, 소프트웨어 정의 스토리지 또는 HA 트리거 활동이 포함됩니다. 멀티 마스터 도구를 사용하면 클러스터의 모든 노드에서 전체 클러스터를 관리할 수 있으며, 전용 관리자 노드가 필요하지 않습니다.

 Proxmox Virtual Environmemt 모바일

Android 앱이나 웹 인터페이스의 HTML5 기반 모바일 버전을 통해 모바일 기기에서 Proxmox VE에 액세스 할 수 있습니다. Proxmox VE Android 앱은 Flutter 프레임워크를 기반으로 하며, Proxmox VE 서버에 액세스하고 클러스터, 노드, VM 및 컨테이너를 관리할 수 있습니다. Proxmox VE HTML5 모바일 클라이언트를 사용하면 이동 중에도 Proxmox VE를 관리할 수 있으며, SPICE 및 HTML5 콘솔에 액세스할 수도 있습니다. 이를 통해 VM과 컨테이너를 관리하고 구성을 볼 수 있습니다.

명령줄 인터페이스(CLI)

Unix 셸이나 Windows Powershell의 편의성에 익숙한 고급 사용자를 위해 Proxmox VE는 가상 환경의 모든 구성 요소를 관리하는 명령줄 인터페이스를 제공합니다. 이 명령줄 인터페이스에는 지능적인 탭 완성 기능과 UNIX man 페이지 형태의 전체 설명서가 있습니다.

REST API

Proxmox VE는 RESTful API를 사용합니다. 우리는 JSON을 기본 데이터 형식으로 선택했고, 전체 API는 JSON 스키마를 사용하여 공식적으로 정의됩니다. 이를 통해 사용자 지정 호스팅 환경과 같은 타사 관리 도구에 대한 빠르고 쉬운 통합이 가능합니다.

홈페이지 : Hostway Proxmox
문의 : Proxmox@hostway.co.kr

Proxmox Virtual Environment 는 Debian 기반으로하는 오픈소스 Type1 Hypervisor 운영체제입니다.

단일 웹 기반 인터페이스로 두 가지 가상화 기술(가상 머신용 KVM(커널 기반 가상 머신) 및 컨테이너용 LXC)을 관리하는 강력한 오픈소스 서버 가상화 플랫폼입니다. 또한 서버 간 고가용성, 소프트웨어 정의 스토리지, 네트워킹 및 재해 복구를 구성하기 위한 기본 제공 도구도 통합합니다.

Proxmox Virtual Environment 의 특징

User Tools에 대한 기능을 통합 웹 기반 사용자 인터페이스로 사용할 수 있습니다. VM 및 Container 설정 및 뿐만 아니라 클러스터의 고가용성 또는 통합 재해 복구 도구를 쉽게 관리할 수도 있습니다. 모든 서비스 구성요소는 소프트웨어로 정의되며 호환됩니다.

Proxmox Virtual Environment 에 대한 Hostway가 제안하는 Modeling

Proxmox 설치는 특정 하드웨어에 종속되지 않습니다. Ubuntu Server certified hardware에 포함된 하드웨어의 경우 모두 구성 가능합니다. 3가지 모델로 구성 가능하며 HCI, Storage 모델을 권장 드립니다.

홈페이지 : Hostway Proxmox
문의 : Proxmox@hostway.co.kr

Proxmox Version

2025-03 기준으로 8.3.3 버전까지 출시 되었습니다.

Proxmox Roadmap

Roadmap

💡 Major 업데이트

• 주기: 2년
• 주요 변경 사항: 대규모 기능 추가, 성능 개선, 보안 강화 등
• 기존 시스템과의 호환성을 고려한 대대적인 업그레이드

🚀 Minor 업데이트

• 주기: 6개월
• 주요 변경 사항: 소규모 기능 개선, 버그 수정, 최적화 등
• 안정적인 운영을 위한 지속적인 유지보수

홈페이지 : Hostway Proxmox
문의 : Proxmox@hostway.co.kr

Proxmox Virtual Environmemt 란?

Proxmox Virtual Environment 는 Debian 기반으로하는 오픈소스 Type1 Hypervisor 운영체제입니다.

단일 웹 기반 인터페이스로 두 가지 가상화 기술(가상 머신용 KVM(커널 기반 가상 머신) 및 컨테이너용 LXC)을 관리하는 강력한 오픈소스 서버 가상화 플랫폼입니다. 또한 서버 간 고가용성, 소프트웨어 정의 스토리지, 네트워킹 및 재해 복구를 구성하기 위한 기본 제공 도구도 통합합니다.

Proxmox Virtual Environmemt 의 특징

오픈소스 소프트웨어를 기반으로 구축하면 많은 글로벌 커뮤니티와 협력하고 최첨단 기술을 공동으로 사용하고 개발할 수 있습니다. Proxmox에서는 모든 사람이 소프트웨어의 소스 코드에 액세스하여 실행하고, 이를 기반으로 구축하거나, 프로젝트에 변경 사항을 다시 제출할 권리가 있어야 한다고 생각합니다. 이를 통해 모든 사람이 모든 기능에 완벽하게 액세스할 수 있으며, 높은 보안과 안정성도 보장됩니다. Proxmox에서는 가능한 한 오픈소스 소프트웨어를 사용하기 위해 최선을 다하고 있습니다.

Proxmox Virtual Environmemt 의 개발 및 서비스

Proxmox Virtual Environment(VE)를 개발한 회사는 Proxmox Server Solutions GmbH(이하 “Proxmox”)입니다. Proxmox는 엔터프라이즈 소프트웨어 개발사로, 오픈 소스 서버 솔루션을 개발합니다. 

Proxmox 기술을 사용하면 항상 원하던 포괄적이면서도 사용하기 쉬운 소프트웨어 솔루션을 얻을 수 있습니다. 또한 비즈니스 연속성이 조직의 핵심이라는 사실도 알고 있습니다. 운영 중단을 최소화하기 위해 기술 지원 및 기타 엔터프라이즈 지원 서비스도 제공하여 비즈니스를 계속 운영할 수 있도록 합니다.

매일 우리는 사용자의 의견을 경청하고, 문제를 해결하고, 이를 통해 제품과 서비스를 지속적으로 개선하기 위해 함께 모입니다. 전 세계 파트너 네트워크와 방대하고 활발한 오픈소스 커뮤니티와 함께, 우리는 여러분의 효율적인 워크플로를 보장하기 위해 여기 있습니다. 모든 규모, 부문 또는 산업의 기업과 NPO 또는 교육 부문은 모두 Proxmox의 오픈소스 플랫폼을 사용합니다.

홈페이지 : Hostway Proxmox
문의 : Proxmox@hostway.co.kr

GFS Volume Features – Dispersed Volume

GFS Volume type 
이해 편의상 비슷한 HW RAID 레벨의 특성을 같이 기재하였다 
- Distribute Volume ( RAID 0 )
- Replicate Volume ( RAID 1 )  
- Distribute + Replicate Volume ( RAID 0+1 ) 
- Dispersed Volume ( RAID 5,6 ) 
- Dispersed + Replicate Volume ( RAID 50 , 60 ) 

# Dispersed Volume? 
HW RAID Level 에서의 비슷한 유형을 찾는다면 RAID 5 와 6의 중간 단계에 있다.
최소 3개 이상의 Brick 부터 구성이 가능하며
볼륨 구성 시 복구 가능한 분산 패리티의 수량을 명시할 수 있어(Redundancy)
RAID 5 보다 복구 유연성이 좋다고 볼 수 있다.

Replicate 보다 가용량을 확보하며 최소한의 안전장치를 확보한다고 볼 수 있다.

# Distribute 과의 차이점?
같은 분산의 의미이지만 Distribute 는 순수한 파일을 각 Brick 에 분배하는 것이고
Dispersed 는 erasure coding 방식 ( 패리티와 사실상 유사 ) 의
인코딩된 전용 데이터를 만들어 Brick 에 분산한다.

Create Command 
e.x ) 
$ gluster volume create NEW-VOLNAME [disperse-data COUNT] [redundancy COUNT] [transport tcp | rdma | tcp,rdma] NEW-BRICK...

disperse-data COUNT : 실제 사용되는 용량에 들어가는 Brick 의 수

redundancy COUNT : 데이터 분산 패리티의 수량 지정 가능. 
해당 수량만큼 Brick 을 가진 물리 디스크가 Failed 되어도 클러스터는 유지된다.
RAID 5가 1개의 패리티. RAID 6 이 2개의 패리티만이 가능한 것보다 유연하다.
이 값만 지정해 줄 시 자동적으로 disperse-data COUNT 가 계산된다.

RMW(Read-Modify-Write) 방식으로 데이터를 기록하기 때문에
효율적인 I/O 를 위한 Brick 비율이 존재한다 
( e.x DISPERSE 6 REDUNDANCY 2 )

GFS Volume Create

100GB * 3개의 Brick 을 Redundancy 1개 ( RAID 5 ) 방식으로 구성

# Peer Probe
Node01)

노드들을 우선 인식해야 한다. 마스터 자기 자신은 제외 

gluster peer probe 211.239.151.197 
gluster peer probe 211.239.151.198
gluster peer status

# Volume Create
노드마다 100GB 씩 할당한 파티션을 묶어서 클러스터를 구성한다.

gluster volume create data disperse-data 2 redundancy 1 transport tcp 211.239.151.196:/gfs_node 211.239.151.197:/gfs_node 211.239.151.198:/gfs_node force

# check
volume create: data: success: please start the volume to access data

# 기본 상태 확인
gluster volume info

# 볼륨 시작. 처음 생성시 stop 되어 있으니 반드시 시작해야 함
gluster volume start 
volume start: data: success

# 볼륨 확인
gluster volume status
Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 211.239.151.196:/gfs_node             49152     0          Y       65695
Brick 211.239.151.197:/gfs_node             49152     0          Y       13261
Brick 211.239.151.198:/gfs_node             49152     0          Y       13513
Self-heal Daemon on localhost               N/A       N/A        Y       65712
Self-heal Daemon on 211.239.151.198         N/A       N/A        Y       13530
Self-heal Daemon on 211.239.151.197         N/A       N/A        Y       13278

Task Status of Volume data
------------------------------------------------------------------------------

# 마운트 및 용량 확인
(All Node)
brick 2개 만큼의 용량 확보 되었고 1개는 redundancy(패리티) 상태이다.

mount -t glusterfs gfs-node01:/data /mnt
df -h /mnt
Filesystem        Size  Used Avail Use% Mounted on
gfs-node01:/data  200G  2.1G  198G   2% /mnt

# fstab 자동 마운트 등록
클러스터이기 때문에 어떤 노드의 엔드포인트를 지정하여도 마운트에 문제는 없다. 

echo "gfs-node01:data /mnt glusterfs defaults,_netdev 0 0" >> /etc/fstab

Node Fail-over TEST

( 노드 다운 )
** 1 node down 
# Node 하나를 Poweroff 시 약 1분 정도의 딜레이가 걸리지만 
클러스터는 정상 작동한다
gluster status volume

** 2 node down
# Redundancy 가 1개이므로 노드 2개가 다운되면 클러스터 볼륨은 연결 실패하게 된다.
[root@node01 mnt]# ll
ls: cannot open directory .: Transport endpoint is not connected

( 노드 업 )
** 1 node up
노드 2개가 살아났을 경우 남아있던 노드는 자동으로 다시 연결된다.
up 노드는 리마운트 해주어야 한다.

[root@node01 mnt]# ll
ls: cannot open directory .: Transport endpoint is not connected
[root@node01 mnt]# ll
total 0
-rw-r--r--. 1 root root 0 Jan 13 10:42 a
-rw-r--r--. 1 root root 0 Jan 13 10:44 b
-rw-r--r--. 1 root root 0 Jan 13 10:44 c

[root@node01 mnt]# gluster volume status
Status of volume: data
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 211.239.151.196:/gfs_node             49152     0          Y       67046
Brick 211.239.151.197:/gfs_node             49153     0          Y       3551
Self-heal Daemon on localhost               N/A       N/A        Y       67063
Self-heal Daemon on 211.239.151.197         N/A       N/A        Y       3108

Task Status of Volume data
---------------------------------------------------------

** 2 node up
정상화 된 것으로 보인다.
다수의 다량 데이터 검증은 필요하다

** 3 ( all ) node up 
부팅 순서에 따라 자동 마운트는 안 되지만 스토리지 볼륨은 정상 online 된다.

Volume Expansion (ADD-BRICK)

# node03 에 100GB Brick 3EA 추가할 것이다..
Dispersed 타입 볼륨은 3(1패리티) 비율의 Brick 으로 구성하였고 
6(2 패리티) 조합이 밸런스가 권장된다. 
- 기존 GFS Volume 에 증설  
- 기존 브릭 교체 실습

# Check now
[root@node02 ~]# gluster volume info | egrep -iE "brick|t
ype"
Type: Disperse
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: 211.239.151.196:/gfs_node
Brick2: 211.239.151.197:/gfs_node
Brick3: 211.239.151.198:/gfs_node

# 추가할 BRICK 파티셔닝 ( sdc , sdd , sde 3개 구성하자 ) 
fdisk /dev/sdc <<EOF
n
p



w
EOF
mkfs.xfs -i size=512 /dev/sdc1
mkdir -p /add_brick1
mount /dev/sdc1 /add_brick1

echo "/dev/sdc1       /add_brick1       xfs     defaults        0 0" >> /etc/fstab

# check
[root@node03 ~]# df -h | grep brick
/dev/sdc1                100G   33M  100G   1% /add_bric
1
/dev/sdd1                100G   33M  100G   1% /add_bric
2
/dev/sde1                100G   33M  100G   1% /add_bric
3

# Volume ADD issue
3개 미만의 브릭을 추가하려고 하면 에러가 발생한다
[root@node03 ~]# gluster volume add-brick data gfs-node03:/add_brick1
volume add-brick: failed: Incorrect number of bricks supplied 1 with count 3

새 Peer ( 물리적 노드 ) 가 아닌 같은 서버에 Brick 다수 중첩될 경우 경고 발생
[root@node03 ~]# gluster volume add-brick data gfs-node03:/add_brick1 gfs-node03:/add_brick2 gfs-node03:/add_brick
3
volume add-brick: failed: Multiple bricks of a disperse volume are present on the same server. This setup is not optimal. Bricks should be on different nodes to have best fault tolerant configuration. Use 'force' at the end of the command if you want to override this behavior.

force 옵션을 요구함
volume add-brick: success

# Volume brick check
체크 시 6개의 브릭 중 2개가 패리티로 설정된 균형비율 확인
[root@node03 ~]# gluster volume info | egrep -iE "brick"
Number of Bricks: 2 x (2 + 1) = 6
Bricks:
Brick1: 211.239.151.196:/gfs_node
Brick2: 211.239.151.197:/gfs_node
Brick3: 211.239.151.198:/gfs_node
Brick4: gfs-node03:/add_brick1
Brick5: gfs-node03:/add_brick2
Brick6: gfs-node03:/add_brick3

# Volume Size Check
brick 추가시 volume size 도 라이브하게 변경되었다.
[root@node03 ~]# df -h | grep mnt
gfs-node01:data          400G  4.2G  396G   2% /mnt


# Rebalance
추가된 Brick 으로의 고른 데이터 분산을 위해 사용
gluster volume rebalance data start
volume rebalance: data: success: Rebalance on data has been started successfully. Use rebalance status command to check status of the rebalance process.
ID: 9782e187-6cda-4e2b-aae9-0b78746d69fa


# check
1) status 에서 내용을 확인할 수 있다
Task Status of Volume data
------------------------------------------------------------------------------
Task                 : Rebalance
ID                   : 9782e187-6cda-4e2b-aae9-0b78746d69fa
Status               : completed

2) 리밸런스 후 추가된 brick 에 패리티가 일부 분산된 내용을 확인할 수 있었다
[root@node03 add_brick3]# ll ( 리밸런스 전 ) 
total 0
[root@node03 add_brick3]# ll ( 리밸런스 후 ) 
total 8
-rw-r--r--. 2 root root 512 Jan 13 14:57 d
[root@node03 add_brick3]#

Setting Up Volumes – Gluster Docs

리눅스에서 패스워드 리셋이나 마운트 에러 등의 이슈로 응급 모드로 진입하여 작업해야 할 때가 있는데 AWS는 기본적으로 원격 관리이기 때문에 콘솔 화면이 보이지 않습니다.

Nitro Hypervisor 를 지원하는 T3 급 이상의 인스턴스는 AWS Console 에서 직접 시리얼 콘솔을 접근할 수 있는 옵션이 추가가 되었는데

GRUB Timeout 설정 시간이 짧아서 응급모드 진입이 어려운 이슈가 있습니다.
Amazon Linux 2 OS 의 GRUB 타임아웃 시간을 늘려서 확인할 수 있도록 해 봅니다.

마운트 실패로 인한 응급 모드의 큰 틀은 다음의 2가지로 분류가 됩니다.

1) GRUB TIMEOUT 변경
2) 응급 모드 진입 후 mount 옵션에 nofail 추가 시, 실패해도 진행 가능

IAM 접근 최소 조건

# IAM이 Administrator Group 이라면 상관 없으나, 디테일 권한 관리될 경우
다음의 정책을 추가합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:GetSerialConsoleAccessStatus",
                "ec2:EnableSerialConsoleAccess",
                "ec2:DisableSerialConsoleAccess"
            ],
            "Resource": "*"
        }
    ]
}

GRUB TIMEOUT 값 수정하기

# root 권한에서 Default GRUB 의 값을 수정 및 추가합니다.
Console Serial 은 root 패스워드가 콘솔 로그인 가능해야 합니다. 
아마존의 타임아웃 권장값은 1입니다만 넉넉하게 10(초)로 변경합니다. 

sed -i 's/GRUB_TIMEOUT=0/GRUB_TIMEOUT=10/g' /etc/default/grub
sed -i 's/GRUB_TERMINAL="ec2-console"/GRUB_TERMINAL="console serial"/g' /etc/default/grub
 echo -e GRUB_SERIAL_COMMAND=\"serial --speed=115200\" >> /etc/default/grub

# check
cat /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
GRUB_TIMEOUT=10
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console serial"
GRUB_X86_USE_32BIT="true"
GRUB_SERIAL_COMMAND="serial --speed=115200"

# 실제 GRUB 에 적용합니다
grub2-mkconfig -o /boot/grub2/grub.cfg

EC2 Reboot 후 직렬 콘솔 확인

10초 지연 후 지나가므로 e 키를 바로 눌러 응급모드 진입

응급모드 진입

# 해당 위치에 single 구문을 추가 후 Ctrl + x 로 부팅

FSTAB 에서 nofail 옵션 사용

# 추가 마운트 옵션에 nofail 을 넣으면 부팅 시 실패해도 정상 진행됩니다

AWS 의 Amazon-Linux OS 로 생성한 이미지 등의 경우 기본적으로 Password 방식의 로그인이 허용되어 있지 않으며, ssh 설정에서 주석처리를 해제하여도 이미지 백업 후 복원 시 Cloudinit 에 의해 다시 주석이 잠기는 보안성이 존재합니다.

이는 다량의 작업을 해야 할 때 번거로움으로 작용할 수 있는데
패스워드 로그인을 허용하는 방법은 2가지로 구분할 수 있습니다.

1. 이미지에서 인스턴스 생성 시에 Advance의 User-data 에서 리눅스 스크립트로 부팅 시 root 잠금 해제
2. 기존 이미지에서 Cloudinit Config 의 설정 변경

# 이미지에서 인스턴스 생성 시 다음의 스크립트를 추가한다.

# sshd Permitrootlogin 
sed -i 's/#PermitRootLogin yes/PermitRootLogin yes/g' /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config

# Key root account permit
sed -i 's/^.*10" //g' /root/ssh/authorized_keys

# set root password
echo "P@ssw0rd" | passwd root --stdin 

# sshd restart
systemctl restart sshd

이미지에서 인스턴스 생성 시 User-data 추가

생성 후 직렬 콘솔을 통해 root password 로그인이 가능하다.

이미지 생성 시에 리셋되지 않도록 하려면 Cloudinit 설정을 변경한다

disable_root : true --> false ( 0 ) 
ssh_pwauth:  false --> true ( 1 )