OpenStack Essentials - 1

SangYeon Min·2025년 1월 9일

STUDY-OPENSTACK

목록 보기

1/5

이전의 KDT 과정 및 여러 Spring Boot 기반의 프로젝트를 진행하면서, Infra 분야로 나아가고자 하는 의지를 항상 마음속에 담아두었다가, 이를 위한 준비는 이번 겨울이 졸업 이전까지의 마지막 시간이라는 것을 깨닫게 되었다.

따라서 Spring 및 Java에 대해 학습하고 있던 시점에 선배님들과 멘토분들과 여러 의견을 나눈 끝에 OpenStack에 대한 공부를 시작으로 이번 겨울에 Infra 직무를 위한 공부를 진행하고자 한다.

1. OpenStack 학습
2. 24시간 365일 서버/인프라를 지탱하는 기술
3. Linux 마스터 1급 취득
4. Cloud 구축 개인 프로젝트
5. `언제볼까?` 프로젝트 개인 Cloud 배포 및 서비스 
6. Infra 관련 졸업 프로젝트 아이디에이션 및 개발

현재 이번 겨울 내 완료하고자 하는 과제들은 위와 같다.

https://www.udemy.com/share/101X1I3@74H7jk28U4hXWsmmhv5SaRoGnB4A6ZQqAs314d1WCcAbTZ9svWEkjXtvkkNvEdsdvA==/

Cloud Computing

On-Demand Self-Service (주문형 셀프서비스)
사용자가 필요할 때마다 공급자의 개입 없이 자동으로 컴퓨팅 자원을 프로비저닝할 수 있도록 지원한다.
Broad Network Access (광범위한 네트워크 접근)
모바일폰, 태블릿, 노트북 등과 같은 표준 플랫폼을 통해 네트워크 상에서 서비스를 이용할 수 있도록 제공된다.
Resource Pooling (자원 풀링)
여러 사용자가 풀링된 컴퓨팅 자원을 공유하며, 수요에 따라 동적으로 할당된다.
Rapid Elasticity (신속한 탄력성)
컴퓨팅 자원을 빠르게 확장하거나 축소할 수 있어 사실상 무한 용량처럼 느껴지는 확장성을 제공한다.
Measured Service (측정 서비스)
자원 사용량을 자동으로 모니터링하고 측정하여, 공급자와 소비자 모두에게 투명한 사용 지표를 제공한다.

Traditional IT vs Cloud

Enabling Technologies

Virtualization

Computing
- Hypervisor는 기반의 HW를 추상화하여 여러 VM을 설치하고 구동할 수 있게 한다
- 가상화의 동적인 Migration은 서비스의 가용성을 높일 수 있다
Netkworking, Storage
- 전통적으로 VLAN과 같은 기술은 병렬적으로 가상 네트워크를 운용할 수 있게 하였다
- 이는 네트워크의 효율성, 보안, Scale을 증가시킬 수 있게 하였다
- 하지만 현재는 Scale이 가능한 L2 Swutching, East-West Communication 등이 필요하다
- 현재 SW Defined 네트워크에서는 네트워크 인프라 추상화 (prgrammable)이 가능하다

Automation & Orchestration

Automation과 Orchestration 없이는 Cloud Computing이 불가능하다
효율적인 Automation과 Orchestration 툴은 provisioning cost를 최소화할 수 있다

Traditional Infra vs Cloud Infra

Traditional Infra에서는 Server나 Application들이 Pet처럼 Individual하게 Care된다
Cloud Infra에서는 Server나 Application들이 가축 (소)처럼 취급된다
- CA-10450X와 같이 명명된다
- 만약 Server가 Down되면 Care를 받는 것이 아닌 Admin이 재설치한다
- 이러한 환경에 익숙하지 않은 Traditional Infra에 이와 같은 방법을 적용하면, 데이터 유실, 완전한 실패 등의 문제가 발생한다

Compute Stack

Traditional Computing Stack은 각각의 IT 부서에서 관리된다
Cloud Computing은 소비자가 요구하는 Computing 능력에 따라 다른 Service 모델을 제공한다

IaaS (Infrastructure As A Service)

Cloud Service의 Fudimental한 Building Block이다
OpenStack Cloud가 이에 해당
소비자는 Image, OS, App, Storage, Networking, CPU를 Manage
OS, Middleware, Runtime Data App을 자유롭게 선택할 수 있다
Storage의 경우 요구량만 결정하면 자동으로 Manage된다
Hypervisor의 경우도 CPU, RAM만 결정하면 자동으로 Manage된다

PaaS (Platform As A Service)

SW가 개발되고 배포되는 Platform을 제공한다
Runtime, Infra Middleware, OS를 추상화하여 제공한다
OS 시스템 라이브러리와 프로그래밍 언어를 제공한다
하위 Layer는 제공되지 않는다
ex. exlipse Java Programming Platform
ex. MS Azure

SaaS (Software As A Service)

Cloud Provider가 Application에 접근 권한을 제공하는 Delivery Model
Old Thin Client Model of SW Provisioning과 유사함

SW Provisioning: 소프트웨어를 특정 환경에 배포하고 구성하여 사용자가 즉시 사용할 수 있도록 준비하는 프로세스
- Web Browser : Server에 구동되고 있는 SW의 Access Point를 제공
ex. Salesforce, Google Service, Dropbox etc.

Cloud Deployment

Private Cloud
- Single Organiztaion을 위해 구동됨
- On Premise, Off Premise (as a public) 형태로 관리가 가능
- Private이라는 의미는 Access에 한정된다
  (Reource의 경우 어디에 존재하든 상관없다)
Public Cloud
- Public이나 Large Industry Group에 공개된 Infrastructure
- 보통 Cloud Service Company에 소유됨
Hybrid Cloud
- Private Cloud와 Third Party Public Cloud를 섞어서 사용하는 것
- 두 플랫폼 사이의 Orchestration까지 포함

Data Censter vs Cloud

Data Center : 물리적 서버와 네트워크 장비를 한 장소에 배치하여 기업이나 조직이 자체적으로 관리하는 IT 인프라
데이터에 대한 완전한 통제가 필요하거나 규제가 강한 환경에 적합

Cloud : 인터넷을 통해 제공되는 가상화된 IT 자원(서버, 스토리지, 네트워크 등)으로, 필요에 따라 유연하게 사용할 수 있는 서비스
유연성과 비용 효율성을 중시하는 기업에 적합

항목	Data Center	Cloud
소유 및 관리	기업이 직접 소유하고 유지 관리	서비스 제공업체(AWS, Azure 등)가 관리
초기 비용	높은 초기 투자 비용(서버, 시설, 네트워크 구축)	초기 비용이 적고 사용량 기반 과금
유연성	자원 확장이 제한적	자원 확장 및 축소가 빠르고 유연
위치 의존성	특정 물리적 위치에 제한	인터넷 연결만 있다면 어디서든 접근 가능
보안	내부적으로 관리하므로 통제력 강함	서비스 제공업체에 따라 보안 책임 공유
가용성	정전이나 장애 발생 시 백업 및 복구 시스템 필요	고가용성 및 글로벌 중복성 제공
업데이트 및 유지보수	직접 소프트웨어 및 하드웨어 업데이트 필요	서비스 제공업체가 업데이트 및 유지보수 담당
비용 구조	고정 비용(자산 소유, 전기, 냉각 비용)	사용량 기반 변동 비용

Introduction to OpenStack

OpenStack는 클라우드 컴퓨팅을 위한 오픈소스 플랫폼으로, IaaS(서비스형 인프라)를 구현하는 데 사용된다. 주요 목적으로는 데이터 센터 자원의 가상화를 통해 서버, 스토리지, 네트워크 등의 자원을 유연하게 관리하고, 사용자에게 필요한 자원을 제공할 수 있는 클라우드 환경을 구성하는 데 있다.

OpenStack은 DataCenter의 모든 가상화된 요소들 위의 Control Layer라고 생각할 수 있다
Openstack은 Computing, Networking, Storage Resources를 위한 단일의 verstile(다재한) platform을 제공한다
Nova : 같은 추상화 및 Orchestration Layer를 지닌 Compute Layer
KVM, Xen, Hyper-V, ESX 등 많은 Hypervisor를 동일한 API로 접근 가능하다
Storage와 Network의 경우에도 동일하게 Constant하게 접근이 가능하다

OpenStack Platform

OpenStack의 구조는 각각의 Component에 해당하는 프로젝트를 지닌 Modular Arhcitecture이다
OpenStack Foundation은 Core와 Optional Service로 이들을 나누었다
- 이를 통해 OpenStack Powered Cloud의 Architecting과 Deployment를 더 쉽게 할 수 있게 되었다
  
  https://www.openstack.org/software/project-navigator/openstack-components#openstack-services

Hypervisor

Hypervisor는 물리적 하드웨어 위에서 다수의 가상 머신(VM)을 생성하고 실행할 수 있도록 지원하는 소프트웨어이다. 하드웨어 자원을 가상화하여 각 VM이 독립적인 시스템처럼 작동하도록 한다.

Type 1 (Bare Metal)
- 하드웨어에서 직접 실행되며 성능이 뛰어나고 안정적
  (ex. VMware ESXi, Microsoft Hyper-V)
Type 2 (Hosted)
- 운영체제 위에서 실행되며 설치가 간편
  (ex. VirtualBox, VMware Workstation)

Component Services Overview

1. Identity

모든 OpenStack 서비스에 대해 인증 및 권한 부여를 제공한다.
서비스 카탈로그와 사용자 자격 정보를 관리한다.
OpenStack에서는 모든 요소들이 ID를 지니고 Authenticate 되어야 한다.

Image
- VM 이미지를 저장하고 배포 시 제공한다.
- 인스턴스가 특정 이미지에서 부팅될 수 있도록 지원한다.
  - Compute가 Provision 단계에서 이곳에 저장된 Image를 활용한다.
Network
- 인스턴스에 네트워크 연결을 제공한다.
- 가상 네트워크, IP 주소 및 라우팅을 관리한다.
Compute
- Nava는 Hypervisor의 최상단에 위치하며 Network Storage와 Coordinate한다.
  Hypervisor와 통신하여 VM이 실행될 수 있게 한다
- 가상 머신을 제공하고 그 수명 주기를 관리한다.
- 네트워크 및 블록 스토리지와 연계하여 인스턴스 운영을 지원한다.
Block Storage
- VM에 지속 가능한 저장소를 제공한다.
  - 일반적으로, VM은 ephemeral volume과 함께 부팅된다.
    
    Ephemeral Volume은 임시 저장소로, 가상 머신(VM)이나 컨테이너의 수명 동안에만 데이터를 저장한다. 주로 캐시 데이터나 일시적인 작업에 사용된다
  - 이후 VM이 제거되면 Persistent한 저장소를 Reattach한다
  - Shared Storage가 아니라 Block Storage이며
  - Instance와 Block Storage는 1:1 관계를 가진다
- 인스턴스에 연결하거나 분리할 수 있는 볼륨을 저장한다.
- Manilla: VM을 위한 Shared File System을 지원하는 프로젝트
Object Storage
- 비정형 데이터(Mpeg)를 객체 형태로 확장 가능한 방식으로 저장한다.
  - HTTP 기반의 API를 사용해 Object와 Metadata를 전달한다 (GET, PUT)
  - ex. Wikipedia의 경우 Object Storage를 통해 전체 서비스를 운영한다
- 대규모 백업, 아카이빙 및 데이터 저장에 적합하다.
Dashboard
- OpenStack 자원과 서비스를 관리할 수 있는 UI를 제공한다.
- 사용자가 OpenStack과 상호작용할 수 있는 진입점 역할을 한다.

OpenStack Architecture

OpenStack은 Multiple SW의 Collection이다
(하나의 큰 Monolithic SW가 아니다)
OpenStack Service라는 여러개의 독립적인 파트로 구성된다
각각의 서비스는 하나의 통합된 IaaS를 제공하기 위해 디자인되었다
Public API를 통해 Service간의 Integration이 가능하다
ex. Nova
- 외부에서는 Nova Service가 단일 Entitiy처럼 보여진다
- Nova가 메세지를 받으면, Queue를 통해 다른 Nova Component로 이를 전달한다
OpenStack을 통해 클라우드를 배포하고자 한다면 여러 서비스를 선택할 수 있다
(RabbitMQ, MySQL, MariaDB, SQLite etc.)
User는 Web-based UI인 Horizon이나 Command를 통해 OpenStack에 접근할 수 있다
Application의 경우 여러 SDK를 통해 OpenStack에 접근이 가능하다
최종적으로 이러한 접근은 OpenStack의 여러 Service들에 REST API 요청을 보낸다

3-ways to use OpenStack

Horizon DashBoard
CLI

openstack server create --image centos-7-x86_64-st --flavor ...

curl -s -H "X-Auth-Toke: $OS_TOKEN" \
	$OS_COMPUTE_API/flavors \
    | python -m json.tool

=> 이러한 세 개의 방식 모두 최종적으로 Backend에서는 Public API를 통해 접근된다.

VirtualBox CentOS Installation

VirtualBox Installation

이전 여름에 VBox를 설치하고 사용한 적 있으나, 구동이 되지 않아 재설치를 진행하였다.

https://www.virtualbox.org/wiki/Downloads?

CentOS

우선 강의에서 CentOS 7 Minimal Version을 사용하라고 하였지만, 오래된 강의이니만큼 최신 버전을 사용하기 위해 이미지에 대해서 더 깊게 살펴보았다

https://www.centos.org/download/

이때 추가적으로 존재하는 각 Architecture에 대해서 살펴보았다.

Streams: Red Hat Enterprise Linux(RHEL)과 관련된 "롤링 릴리스(Rolling Release)" 개발 브랜치로, RHEL의 새 버전이 출시되기 전에 미리 새로운 기능과 업데이트를 테스트할 수 있는 환경을 제공
RPMs: 개별 소프트웨어 패키지를 설치할 때 사용되는 파일. Minimal 설치가 아닌 추가 구성에 사용됨
Cloud: 클라우드 플랫폼(AWS, OpenStack 등)에서 CentOS 이미지를 실행할 때 사용
Containers: 컨테이너 환경(Docker 등)에서 실행되는 CentOS 이미지
Vagrant: Vagrant 개발 환경을 위한 CentOS 이미지

CentOS 7

Minimal 버전
- CentOS 설치 시 최소한의 패키지만 포함된 경량화된 버전
- 네트워크 구성, 기본적인 시스템 관리 툴 등 필수적인 운영체제 기능만 제공
- 주로 서버 환경에서 불필요한 패키지를 제외하고 가볍고 보안적인 환경을 구성하기 위해 사용
- 사용자가 원하는 추가 소프트웨어를 설치하여 필요한 기능을 구성할 수 있음

하지만 Minimal 버전을 사용할 수 있는 CentOS Linux 7은 2024년 6월 30일에 지원 종료(End of Life, EOL)되었기에 이미지를 구한다고 하더라도 여전히 아래와 같은 문제가 있을 것으로 예상한다.

보안 취약점
- CentOS 7의 지원 종료로 인해 보안 업데이트가 더 이상 제공되지 않음.
- 새로운 취약점이 발견되어도 패치가 불가능해 보안 사고 위험이 커짐.
호환성 문제
- 최신 소프트웨어 및 라이브러리와의 호환성 부족으로 인해 서비스 운영에 제약이 생길 수 있음.
- 커널 업데이트가 중단되면서 최신 하드웨어 지원도 어려워졌음.
규제 준수 문제
- 금융, 의료 등 보안 규제가 강한 산업에서는 지원 종료된 OS를 사용하는 것이 규제 위반이 될 수 있음.

CentOS 7의 대안점

Rocky Linux

CentOS와 비슷한 환경을 제공하며 안정적인 LTS 주기를 보장함.
CentOS 개발자들이 만든 프로젝트로, CentOS에 익숙하다면 금방 적응할 수 있음.
최신 보안과 커널 업데이트가 보장되며, 오픈소스 정신을 유지한 선택지임.

Oracle Linux

안정성과 기업 지원을 제공하는 대안이지만, 오라클의 오픈소스 정책에 대한 불신으로 인해 꺼려질 수 있음.

Ubuntu Server

기업과 개인 사용자 모두에게 검증된 안정적인 배포판임.
특히 GPU 연산 작업이나 NVIDIA 도구와의 호환성이 필요할 때 강력한 선택지임.
외국에서는 게이밍 플랫폼인 Steam 덕분에 Ubuntu 사용 사례가 늘어나는 추세임.
하지만 한국에서는 윈도우 사용 비중이 높아 활용도가 낮을 수도 있음.

SUSE

유럽에서 주로 사용되며, 한국에서도 일부 사례가 있지만 사용 빈도가 적음.
안정성과 기업 중심 지원을 제공하지만, 국내 환경에서는 덜 친숙한 선택지임.

하지만 현재 강의에서는 CentOS 7을 사용하고 있는 만큼, Minimal Version이 아닌 CentOS_10_x86_64 이미지를 통해 실습을 진행하고자 한다.

VirtualBox CentOS Installation

이후 CentOS 10 이미지로 위와 같이 VM을 세팅해주었다.

하드 디스크 크기의 경우, 조금 낮게 설정하더라도 추후에 Swap Disk Size를 늘릴 수도 있다.

또한 위와 같은 VM의 Network 설정을 NAT 모드에서 Bridge Adapter 모드로 변경하였는데, 이 둘의 특성은 아래와 같다.

1. NAT(Network Address Translation) 모드

VM은 호스트 머신의 IP를 통해 외부 네트워크와 통신하며, VM 자체는 사설 네트워크 내에서 동작
NAT 모드에서는 VM이 직접 외부 네트워크에서 접근받기 어려움
OpenStack 서비스가 외부와 통신하려면 포트 포워딩을 설정해야 함
NAT 모드에서는 외부 네트워크에서 OpenStack 대시보드나 API에 접근하는 데 제약이 있음
클라리언트로의 역햘은 가능하지만, 서버로서는 기능할 수 없다

2. Bridge Adapter 모드

VM이 호스트 네트워크와 동일한 네트워크에 연결되며, VM은 독립적인 IP를 가짐
VM이 외부 네트워크와 직접 통신할 수 있음
OpenStack 서비스가 독립적인 IP를 통해 네트워크에 연결되어 외부에서 접근 가능
다중 노드 배포 및 외부 클라이언트와의 원활한 통신을 지원
네트워크 격리 및 관리가 용이해 프로덕션 환경에 적합
클라이언트와 서버 모두로 기능이 가능하다

Name: Realtek PCIe GbE Family Controller #2
- VM이 사용할 네트워크 어댑터를 지정
- 호스트 머신의 실제 물리 네트워크 어댑터 이름을 나타냄
Adapter Type: Intel PRO/1000 MT Desktop (82540EM)
- VM에서 사용할 가상 네트워크 어댑터의 유형
- 일반적으로 호환성과 성능이 우수한 Intel PRO/1000 MT 시리즈가 기본 선택
Promiscuous Mode: Allow All
- 네트워크 어댑터가 모든 패킷(자신에게 목적지가 아닌 패킷 포함)을 수신하도록 설정
- OpenStack과 같은 네트워크 가상화 환경에서 트래픽 캡처 및 분석을 위해 필요할 수 있음
MAC Address: 08002793A1B9
- VM 네트워크 어댑터의 고유 식별자(MAC 주소)
- 가상 환경에서 자동 생성되며 필요 시 수동으로 변경 가능
Cable Connected
- 네트워크 어댑터가 활성화되어 네트워크에 연결된 상태를 시뮬레이션
- 체크가 해제되면 VM이 네트워크에 연결되지 않은 상태로 동작

이후 위와 같이 이전에 다운받은 CentOS 이미지 파일을 선택하고 부팅을 진행한다.

0.134609] Warning: Deprecated Hardware is detected: x86_64-v2:AuthenticAMD: AMD Ryzen 5 7535HS with Radeon Graphics will not be maintained in a future major release and may be disabled

하지만 위와 같이 오류가 발생하여 문제를 해결하고자 우선 마우스를 탈출시키게 되었다.

Ctrl + Alt + Delete 키로 마우스를 탈출시킬 수 있다

이후 우선적으로 Host Key Combo를 Ctrl + Alt로 지정해주었다.

현재 CPU가 OpenStack 또는 CentOS Stream 10이 요구하는 최신 x86_64-v3 ISA(Instruction Set Architecture)를 지원하지 않는 x86_64-v2라는 Warning 메세지를 확인하였기 때문에 우선 CentOS 버전을 다운그레이드 하기로 결정하였다.

https://vault.centos.org/8.5.2111/isos/x86_64/

Boot 이미지 (CentOS-8.5.2111-x86_64-boot.iso)
- 최소 설치 이미지를 제공하며, 네트워크를 통해 필요한 패키지를 다운로드하여 설치함
- 인터넷 연결이 필요한 환경에서 사용되며, 빠르게 설치를 시작할 수 있음
DVD 이미지 (CentOS-8.5.2111-x86_64-dvd1.iso)
- 모든 주요 패키지를 포함한 전체 설치 이미지로, 네트워크 연결 없이도 설치 가능
- 인터넷 연결이 어려운 환경이나 오프라인 설치에 적합

이때 CentOS 9와 CentOS-8.5.211의 위 이미지들을 모두 다운로드 해주었다.

우선 안전하게 OS가 실행되는지 확인하기 위해 CentOS-8.5.211 DVD를 Check & Install 해주었다

다행이도 OS가 정상적으로 설치되었으며, 우선 Installation Destination을 지정해주었다

현재는 Automatic하게 설정해주지만 추후 수동으로 이를 설정할 때를 대비하여 해당 옵션을 살펴보았다.

각 dir의 의미는 다음과 같다
1. / (Root)

리눅스 파일 시스템의 최상위 디렉터리로, 모든 파일과 디렉터리가 이 아래에 존재함
시스템의 핵심 구성 요소와 애플리케이션 데이터를 저장하는 기본 영역

/boot
- 부팅에 필요한 파일을 저장하는 디렉터리로, 커널 및 초기 RAM 디스크 파일 등이 포함됨
- 일반적으로 크기는 1GB 정도로 설정하며, 부팅에 필요한 핵심 파일만 저장됨
swap
- 물리적 메모리가 부족할 때 디스크 공간을 임시 메모리로 사용하는 영역
- 시스템 성능 최적화를 위해 메모리 크기의 1~2배로 설정하는 것이 일반적임

이후 KDUMP 옵션을 해제하여준다.

KDUMP는 Linux 커널 충돌(Crash)이 발생했을 때 시스템 메모리의 상태를 저장하여 디버깅 및 분석에 활용할 수 있도록 해주는 커널 덤프 기법

이후 위와 같이 enp0s3 Ethernet을 On하여주고

위와 같이 IPv4 세팅에서 Method를 Manual로 변경하고 위와 같이 주소를 할당하여준다.

DHCP(Dynamic Host Configuration Protocol)는 네트워크 장치에 IP 주소, 서브넷 마스크, 게이트웨이, DNS 서버와 같은 네트워크 설정을 자동으로 할당하는 프로토콜
클라이언트가 네트워크에 연결되면 DHCP 서버가 자동으로 네트워크 설정 정보를 제공하고 수동 설정 없이 동적으로 네트워크를 구성 가능

Address: 192.168.0.11
- 장치에 수동으로 할당된 IPv4 주소
- 네트워크 내에서 고유한 장치 식별자로 사용됨
Netmask: 24
- 서브넷 마스크를 CIDR 표기법으로 나타냄 (255.255.255.0과 동일)
- 네트워크와 호스트를 구분하며, 24는 256개의 호스트 주소를 포함
Gateway: 192.168.0.1
- 네트워크를 외부와 연결하는 기본 게이트웨이 IP 주소
- 인터넷에 접근하거나 다른 네트워크로 데이터 전송 시 사용
DNS servers: 8.8.8.8
- 도메인 이름을 IP 주소로 변환해주는 DNS 서버
- 여기서는 Google Public DNS가 사용됨
Require IPv4 addressing for this connection to complete
- 해당 옵션이 활성화되면 IPv4 주소가 반드시 설정되어야 네트워크 연결이 완료됨
- 체크 해제 시 IPv4 설정 없이도 연결 가능

이후 현재 IPv6는 중요하지 않기 때문에 Ignore하고, Save로 이를 저장한다.

최종적인 네트워크 설정은 위와 같으며 root 비밀번호를 설정하고, Installation을 시작한다.

Trouble Shooting: Boot Order

이미 설치를 하고 난 뒤에도 VM을 다시 실행하였을때 여전히 Install 페이지가 나온다면

위와 같이 System의 Boot Order에서 HardDisk를 최상단으로 올리고

위와 같이 ISO를 제거하여

정상적으로 기존에 HDD에 설치된 CentOS를 불러올 수 있다.

Trouble Shooting: Internet Connection

현재 위와 같이 VM에서 네트워크 세팅이 되어 있고

위와 같이 CentOS 8에서 IPv4가 잘 세팅되어 있으며, 1000MB/s의 Link Speed로 연결되어 있다고 나오는 상태이다

하지만 위와 같이 google.com에 접속되지 않으며, ping 명령어, yum update 명령어 모두 작동하지 않았다.

1. Window 아웃바운드 규칙 허용

VirtualBox가 외부와 자유롭게 데이터를 주고받도록 네트워크 트래픽을 방화벽에서 허용하는 설정

우선 위와 같이 VirtualBoxVm.exe 프로그램에 대한 모든 아웃바운드 규칙을 허용해주었다.

2. 네트워크 서비스 및 방화벽 확인

NetworkManager: CentOS에서 네트워크 연결을 관리하고 구성하는 데 사용되는 백그라운드 서비스

Linux 배포판에서 네트워크 설정과 관리를 간소화하는 핵심 도구

네트워크 설정 파일(/etc/sysconfig/network-scripts/)을 대체하거나 통합적으로 제어

CLI nmcli 제공

sudo systemctl restart NetworkManager
sudo systemctl stop firewalld

위와 같이 NetworkManager를 재시작하고, 방화벽 서비스를 중지하였지만 여전히 문제가 해결되지 않았다.

3. VirtualBox Bridge 네트워크 테스트

Bridge Network: VirtualBox에서 가상 머신(VM)을 호스트(Windows PC)와 같은 네트워크에 연결해, VM이 실제 네트워크에 있는 독립적인 장치처럼 작동하도록 설정하는 방식

ping 192.168.0.11

이후 위 명령어로 Bridge 네트워크를 테스트해주었고

VM이 네트워크에 정상적으로 연결되어 있음을 확인할 수 있었다

이를 통해 호스트에서 VM(CentOS)의 IP 주소(192.168.0.11)에 핑이 정상적으로 전달되고 있어, VM과 호스트 간의 네트워크 연결은 문제가 없다는 것을 확인하였으나 VM에서 외부 네트워크(8.8.8.8)로의 핑이 실패하고 있으며, 이는 기본 게이트웨이 또는 라우팅 설정에 문제가 있으리라 유추할 수 있었다.

4. 기본 게이트웨이 설정 확인

게이트웨이 (Gateway) : 한 네트워크에서 다른 네트워크로 데이터를 전송할 때 사용하는 경로 또는 중간 장치
내부 네트워크(예: 사설 IP)와 외부 네트워크(예: 인터넷) 간에 데이터를 주고받을 수 있도록 연결

라우팅 테이블 (Routing Table): 네트워크 장치가 데이터를 어디로 전송해야 할지 결정하기 위해 사용하는 정보의 목록

목적지 네트워크: 데이터를 보내야 할 최종 목적지

게이트웨이: 데이터를 전달할 중간 경로

인터페이스: 데이터를 전송하는 데 사용되는 네트워크 포트

ip route

ip route: 네트워크 라우팅 테이블을 확인하거나 수정할 때 사용하는 명령어
ex. 특정 트래픽을 특정 네트워크 인터페이스로 보내는 경로를 설정

우선 위 명령어를 통해 라우팅 테이블을 확인해주었고

default via 192.168.0.1 dev <인터페이스 이름>
192.168.0.0/24 dev <인터페이스 이름> proto kernel scope link src 192.168.0.11

위와 같이 default via 192.168.0.1가 존재하는 정상적으로 게이트웨이가 설정되어 있는 것을 확인할 수 있었다.

5. Gateway 연결 상태 확인

ping 192.168.0.1

이후 위와 같이 VM 내부에서 Gateway와의 연결을 테스트 하였을 때 Destination Host Unreachable 상태가 되었기 때문에

VM이 Bridge Network와는 정상적으로 연결되어 있지만 Gateway와의 연결에는 문제가 있다는 결론을 내릴 수 있었다.

6. SELinux 비활성화

SELinux (Security-Enhanced Linux): 시스템 보안을 강화하기 위해 권한을 관리하는 Linux 보안 모듈

sestatus

SELinux status: enforcing 상태라면

/etc/selinux/config 파일을 편집하여 SELINUX=disabled로 설정한 후 시스템을 재부팅하여 SELinux의 보안 정책이 완전히 비활성화하였다.

7. 호스트 네트워크 공유 문제 확인

ipconfig/all

위와 같은 과정을 통해서 문제가 해결되지 않아 호스트 (Window) 네트워크에 대한 문제가 있지 않을까 싶어, 위 명령어를 통해 호스트 네트워크를 확인해보았다.

이더넷 어댑터 이더넷 2:

   연결별 DNS 접미사. . . . :
   설명. . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
   물리적 주소 . . . . . . . . : ...
   ...
   링크-로컬 IPv6 주소 . . . . : ...(기본 설정)
   IPv4 주소 . . . . . . . . . : xxx.xxx.xxx.1(기본 설정)
   서브넷 마스크 . . . . . . . : xxx.xxx.xxx.xxx
   기본 게이트웨이 . . . . . . :
   ...

이더넷 어댑터 이더넷 3:

   연결별 DNS 접미사. . . . : kornet
   설명. . . . . . . . . . . . : Realtek PCIe GbE Family Controller #2
   ...
   DNS 서버. . . . . . . . . . : xxx.xxx.xxx.1
                                 xxx.xxx.xxx.2

위와 같이 네트워크 정보를 확인했을 때 강의 자료와 나의 호스트의 네트워크 정보가 달라서 생기는 문제로 파악하여

위와 같이 일단 Automatic하게 할당하는 것으로 변경하니

최종적으로 인터넷 연결이 된 모습을 볼 수 있다.

이렇게 자동으로 IP 주소를 할당받을 경우 브리지 네트워크를 사용할 때, CentOS VM은 호스트 네트워크와 동일한 서브넷에서 IP 주소를 할당받게된다.

따라서 추후 OpenStack 강의와 같이 임의의 고정된 IP를 할당하기 위해서는 아래 세개의 정보를 확인해야 한다.

IPv4 Address:
호스트 네트워크의 ipconfig에서 보이는 IPv4 주소는 CentOS VM과 동일한 서브넷에 있어야 한다
예를 들어, Windows 호스트에서 할당된 IP가 192.168.200.x 범위라면 CentOS VM도 같은 대역 내의 IP를 사용해야 연결이 가능하다
(이는 Subnet mask가 255.255.255.0이기 때문이다)
Default Gateway:
Windows 호스트의 기본 게이트웨이와 CentOS VM의 기본 게이트웨이는 동일해야 한다
브리지 네트워크를 사용하는 경우, VM은 호스트와 동일한 게이트웨이를 통해 인터넷에 연결된다
DNS Servers:
Windows 호스트가 사용하는 DNS 서버를 CentOS에서도 사용할 수 있다
브리지 네트워크 환경에서는 호스트와 VM이 동일한 DNS 서버를 사용하는 것이 일반적이다

ipconfig로 확인한 IP 주소, Gateway 주소가 다른 이유

호스트와 VM이 다른 서브넷에 연결됨
이는 브리지 네트워크를 통해 연결된 외부 네트워크에서 VM과 호스트에 다른 IP 대역을 할당했기 때문
네트워크 환경(예: 공유기 또는 회사 네트워크 구성)에 따라 다르게 설정됨
같은 네트워크 환경에서 분리된 DHCP 서버
브리지 네트워크에서는 VM이 독립적인 장치로 DHCP 서버에 요청을 보낸다
이 요청에 따라 다른 IP 주소 대역이 할당될 수 있다
호스트와 VM의 IP가 같은 대역으로 설정되지 않더라도, 게이트웨이와 DNS 서버를 통해 통신이 가능하기 때문에 인터넷 연결에는 문제가 없다

CentOS VM의 네트워크 설정은 호스트 네트워크 대역과 꼭 같을 필요는 없다
중요한 것은 VM이 현재 속한 서브넷의 규칙에 맞게 설정하는 것

DHCP(Dynamic Host Configuration Protocol): 네트워크에서 장치(클라이언트)들에게 IP 주소, 서브넷 마스크, 게이트웨이, DNS 서버 같은 네트워크 설정을 자동으로 할당해주는 서버

네트워크 관리 자동화: 수동으로 IP를 설정할 필요 없이 네트워크 장치에 동적 IP를 제공

IP 주소 충돌 방지: 사용 가능한 IP를 관리하여 충돌을 방지

Trouble Shooting: Static IP Configuration

하지만 이는 임시 방편에 불가했으며 OpenStack 환경(특히 Controller 노드)에서는 Static IP 사용이 권장된다.

Static IP 권장의 이유

OpenStack 서비스 엔드포인트(Endpoint) 등록

Keystone, Nova, Glance, Cinder 등 주요 OpenStack 서비스들은 엔드포인트 URL을 통해 서로 통신한다
이 URL에는 IP 주소(또는 호스트명)가 고정되어 있어야 다른 컴포넌트가 정상적으로 접근 가능하다
IP가 바뀌면 엔드포인트를 재설정해야 하므로 번거롭고, 운영상 문제가 발생한다

RabbitMQ / MySQL 연결

Controller 노드에서 RabbitMQ와 MySQL을 구동하는 경우, Compute/Storage 노드 등 다른 노드들이 Controller 노드의 IP로 접속한다
DHCP로 IP가 변경되면 다른 노드에서 접근할 수 없어, 서비스 장애가 발생하게 된다

호스트명(Hostname) 연동

클라우드 환경에서는 내부 DNS 또는 /etc/hosts 설정 등으로 controller.example.com 같은 호스트명을 써서 연결하기도 한다
DHCP로 IP가 바뀌면 DNS 레코드나 /etc/hosts를 계속 수정해줘야 할 수 있어, 유지보수가 복잡해진다

# 1) IP 및 서브넷 설정
nmcli connection modify enp0s3 \
    ipv4.addresses xxx.xxx.xxx.xxx/24

# 2) 게이트웨이 설정
nmcli connection modify enp0s3 \
    ipv4.gateway xxx.xxx.xxx.xxx

# 3) DNS 서버 설정
nmcli connection modify enp0s3 \
    ipv4.dns "xxx.xxx.xxx.1 xxx.xxx.xxx.2"

# 4) 수동 모드로 전환
nmcli connection modify enp0s3 \
    ipv4.method manual

# 5) 설정 적용
nmcli connection up enp0s3

이후 위와 같이 현재 Host (Window)의 환경에 맞추어 다시 고정 IP를 설정해주었고

reboot

$ ip a
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:cb:14:b0 brd ff:ff:ff:ff:ff:ff
    inet <이전에 설정한 Static IP>/24

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=32.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=32.7 ms
^C
--- 8.8.8.8 ping statistics ---

리부트 이후 정상적으로 인터넷이 연결된 모습을 확인할 수 있었다.

Trouble Shooting: Failed to download metadata from repository 'appstream'

이는 CentOS 8 지원이 2021년 말에 종료가 되어서 Mirror site 가 vault 로 전환되어 Mirror site 를 못 찾아 발생되는 문제이다.

따라서 CentO S9으로 버전업을 수행하고 네트워크 설정 또한 다시 수행해주었다.

정상적으로 yum을 통해 패키지를 설치할 수 있는 것을 확인할 수 있다.

Trouble Shooting: VirtualBox Guest Addition Installation

Verifying archive integrity... 100%   MD5 checksums are OK. All good.
Uncompressing VirtualBox 7.1.4 Guest Additions for Linux 100%
VirtualBox Guest Additions installer
Removing installed version 7.1.4 of VirtualBox Guest Additions...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Setting up modules
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules.  This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 5.14.0-547.el9.x86_64.

VirtualBox Guest Additions: Look at /var/log/vboxadd-setup.log to find out what went wrong
File context for /opt/VBoxGuestAdditions-7.1.4/other/mount.vboxsf already defined, modifying instead
VirtualBox Guest Additions: reloading kernel modules and services
VirtualBox Guest Additions: unable to load vboxguest kernel module, see dmesg
VirtualBox Guest Additions: kernel modules and services were not reloaded
The log file /var/log/vboxadd-setup.log may contain further information.

VBox에서 Bidirectional 복사 붙여넣기 및 마우스 공유를 위해 Guest Addition을 설치하는 과정에서 현재 버전에 맞는 kernel-devel을 설치하였음에도 불구하고 위와 같은 로그가 나오며, 복사 붙여넣기가 여전히 동작하지 않아 문제를 해결하고자 하였다.

sudo yum install "kernel-devel-uname-r == $(uname -r)"

우선 이를 설치하기 위해 시도했던 명령어는 위와 같다

kernel-devel은 현재 실행 중인 커널 버전에 맞는 커널 개발 파일(header, 모듈 등)을 포함하는 패키지
커널 모듈을 컴파일하거나 특정 드라이버를 빌드할 때 필요
uname -r : 현재 실행 중인 커널의 정확한 버전을 반환
$(...)은 명령어 치환으로, uname -r의 결과를 실행 후 해당 위치에 삽입

uname -r
rpm -q kernel-devel

커널 헤더(kernel headers): 커널과 사용자 공간 애플리케이션 간 인터페이스를 정의하는 파일

CentOS는 RPM에 기반하여 패키지를 관리한다

00:00:04.119368 Shared Clipboard: Initialized OLE
00:00:04.119412 Shared Clipboard: Service loaded
00:00:04.119418 Shared Clipboard: Mode: Bidirectional
00:00:04.119474 Shared Clipboard: Service running in normal mode
00:00:04.130123 Drag and drop service loaded
00:00:04.130135 Drag and drop mode: Bidirectional

또한 위와 같이 VM Log에서 Shared Clipboard가 켜져있는 것도 확인할 수 있었다.

VBox GA Version Upgrade

따라서 검색을 통해 현재 CentOS의 Kernel의 버전(5.14.0-547.el9.x86_64 )과 기존 GA의 버전(VBoxGuestAdditions_7.1.4)사이의 호환성 문제일 수도 있겠다는 힌트를 얻어

https://www.virtualbox.org/wiki/Testbuilds
위 웹에서 VBoxGuestAdditions_7.1.5-165916 이미지 파일을 받아 재설치를 진행하고 reboot 이후

성공적으로 GA를 설치할 수 있었다.

https://forums.virtualbox.org/viewtopic.php?t=110520
https://forums.virtualbox.org/viewtopic.php?t=110604
https://forums.virtualbox.org/viewtopic.php?t=111085

OpenStack Installation

PacketTracer

현재 VM 네트워크의 구성과, 추후 Neutron의 네트워크를 조금 더 직관적으로 이해하기 위해 Cisco의 PacketTracer를 설치하였다.

추후 복잡한 네트워크 구성 시 이를 통해 토폴로지를 시뮬레이션해보고 Trouble Shooting해볼 계획이다.

https://www.netacad.com/resources/lab-downloads?courseLang=en-US

PackStack

PackStack은 Red Hat 기반 배포(RHEL, CentOS 등)에서 OpenStack의 빠르고 간단한 설치를 자동화하기 위한 도구
Python으로 작성된 이 도구는 Puppet을 활용해 OpenStack의 주요 컴포넌트를 설치하고 구성한다
단일 또는 소규모 환경에서 OpenStack 설치를 간소화
설정 파일(answers file)을 사용해 설치를 사용자 정의 가능
테스트 환경 및 개발 목적으로 자주 사용됨

OpenStack Installation

$ cat /etc/redhat-release
CentOS Stream release 9

우선 OpenStack을 설치하기 이전에 위와 같이 CentOS 버전을 확인한다.

$ vi /etc/environment

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

/etc/environment: 시스템 전역 환경 변수를 정의하는 파일
모든 사용자와 세션에서 사용할 수 있는 기본 환경 변수를 설정
일반적으로 로그인 세션 및 GUI 데스크톱 환경에서 읽힘
직접 실행되지 않으며 PAM 모듈(pam_env.so)에 의해 로드

pam_env.so: 로그인 세션에서 환경 변수를 설정하거나 변경하는 PAM 모듈로, /etc/environment와 같은 파일을 통해 시스템 및 사용자 전역 환경을 관리하는 데 사용됨

/etc/profile: 쉘 세션에만 적용되는 환경 변수 설정

~/.bashrc, ~/.bash_profile: 사용자별 환경 변수 설정

먼저 위와 같이 environment에 언어관련 환경변수를 정의한다

systemctl status firewalld
systemctl stop firewalld
systemctl disable firewalld

systemctl stop: 현재 세션에서 실행 중인 서비스(firewalld)를 중지
systemctl disable: 부팅 시 서비스가 자동으로 시작되지 않도록 설정

systemctl status firewalld
○ firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:firewalld(1)

이후 위와 같이 방화벽을 해제한다.

NetworkManager 설정

systemctl status NetworkManager
systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl status NetworkManager

또한 NetworkManager도 중지한 이후 disable한다

systemctl enable network
systemctl start network
systemctl status network

이후 network.service를 enable하여 설치를 진행한다.

$ vi /etc/selinux/config

SELINUX=disables

또한 이후 위 파일에서 SELINUX를 diable하고 리부팅을 진행한다.

getenforce

이후 위 명령어로 Disabled를 확인할 수 있다.

yum install -y yum-utils

yum-utils 페키지 또한 필요하기 때문에, 이를 설치하여준다.

### CentOS Stream 9
# Enable PowerTools/CRB repository:
dnf install dnf-plugins-core
dnf config-manager --set-enabled crb

dnf-plugins-core: DNF에 플러그인 기능을 추가하는 패키지. 이를 통해 config-manager 명령어를 사용할 수 있음
config-manager --set-enabled crb: CRB(Codeready-Builder) 레포지토리를 활성화

### CentOS Stream 9
sudo yum install -y centos-release-openstack-zed
sudo yum-config-manager --enable openstack-zed

### So for example
### Zed
# dnf install centos-release-openstack-zed
### 2023.1 Antelope
# dnf install centos-release-openstack-antelope
### 2023.2 Bobcat
# dnf install centos-release-openstack-bobcat

Zed: 안정성과 확장성이 필요한 중소 규모의 클라우드 환경에 적합
Antelope: 장기 지원이 필요한 대규모 기업 환경에 최적화
Bobcat: 최신 기술과 보안이 중요한 클라우드 환경에 적합

위와 같은 릴리즈에 특성에 의거하여 Zed를 우선적으로 설치하여준다

dnf upgrade

### EL9
dnf install -y python3-openstackclient
dnf install -y openstack-selinux

python3-openstackclient: OpenStack 서비스를 SELinux 보안 정책과 호환되도록 설정하는 모듈 설치
openstack-selinux: SELinux 활성화 상태에서 OpenStack이 정상 작동하도록 보안 컨텍스트를 정의

sudo yum update -y
sudo yum install -y openstack-packstack

이후 최종적으로 packstack 패키지를 설치하여준다.

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    ...
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
	...

enp0s3는 현재 우리가 가지고 있는 유일한 Physical Interface이며, 앞으로 해당 인터페이스를 통해 네트워크 통신을 진행한다.

packstack --allinone --provision-demo=n --os-neutron-ovs-bridge-mappings=extnet:br-ex --os-neutron-ml2-mechanism-drivers=openvswitch --os-neutron-l2-agent=openvswitch --os-neutron-ovs-bridge-interfaces=br-ex:enp0s3 --os-neutron-ml2-type-drivers=vxlan,flat --os-neutron-ml2-tenant-network-types=vxlan

Open vSwitch(OVS)는 가상화 환경에서 네트워크 트래픽을 처리하기 위한 소프트웨어 기반의 가상 스위치로, 고성능의 네트워크 기능을 제공하며 OpenStack Neutron과 같은 클라우드 플랫폼과 통합 가능
OVS는 L2/L3 트래픽 처리, 플로우 기반 제어, 네트워크 가상화 등의 기능을 지원

VXLAN(Virtual Extensible LAN)은 L2 네트워크를 L3 네트워크 위에서 가상화하기 위한 오버레이 프로토콜로, 16백만 개의 격리된 가상 네트워크를 지원하며 테넌트 간 네트워크 트래픽을 분리
캡슐화된 패킷(UDP 기반)을 사용하여 물리적 네트워크를 통해 데이터 전송

Layer 2: Data Link Layer, Layer 3: Network Layer
L2 네트워크는 로컬 네트워크에서의 데이터 전송을, L3 네트워크는 다른 네트워크 간 데이터 전달을 처리

--allinone: 설치를 단일 노드에 구성하는 옵션으로, OpenStack의 모든 서비스를 한 서버에 설치
--provision-demo=n: 데모 프로젝트와 관련 리소스(네트워크, 인스턴스 등)를 생성하지 않음
--os-neutron-ovs-bridge-mappings=extnet:br-ex:
- extnet: 외부 네트워크 이름
- br-ex: Open vSwitch 브리지 이름
- 외부 네트워크와 Open vSwitch 브리지를 매핑
--os-neutron-ml2-mechanism-drivers=openvswitch: OpenStack Neutron의 ML2(Mechanism Layer 2) 드라이버로 Open vSwitch 사용
--os-neutron-l2-agent=openvswitch: OpenStack Neutron에서 L2(Layer 2) 에이전트를 Open vSwitch로 설정
--os-neutron-ovs-bridge-interfaces=br-ex:enp0s3:
- br-ex: Open vSwitch 브리지 이름
- enp0s3: 물리적 네트워크 인터페이스
- 브리지와 물리적 인터페이스를 연결
--os-neutron-ml2-type-drivers=vxlan,flat:
- vxlan: 가상 네트워크 격리를 위한 오버레이 기술
- flat: 네트워크 격리가 없는 단일 네트워크 유형
- 네트워크 유형으로 VXLAN과 Flat 네트워크를 활성화
--os-neutron-ml2-tenant-network-types=vxlan: 테넌트 네트워크 유형으로 VXLAN을 사용

위 명령어를 통해 Packstack을 사용하여 OpenStack을 단일 노드에 설치하며, 네트워킹 설정을 Open vSwitch 기반으로 구성한다.
또한 외부 네트워크 연결과 VXLAN 오버레이를 포함한 네트워크 유형을 설정한다.

OpenStack 설치는 30분에서 1시간정도 소요될 수 있다.

Trouble Shooting: root@xxx.xxx.xxx.xxx's password

Installing:
Clean Up                                             [ DONE ]
Discovering ip protocol version                      [ DONE ]
Setting up ssh keys                                  [ DONE ]
root@xxx.xxx.xxx.xxx's password:

중간에 CentOS VM이 갑자기 Down되어서 재설치를 시도했을때 위와 같이 이전과는 달리 비밀번호를 요구하였다.

Packstack uses passwordless ssh to install packages and run commands on each node in the Openstack enviroment. This include allinone installatoins.
https://access.redhat.com/solutions/1152983

$ vi /etc/ssh/sshd_config
PermitRootLogin yes
PasswordAuthentication yes

우선 sshd_config에서 PermitRootLogin, PasswordAuthentication를 허용한다.

$ systemctl restart sshd
Job for sshd.service failed because the control process exited with error code.
See "systemctl status sshd.service" and "journalctl -xeu sshd.service" for details.

$ journalctl -xeu sshd.service
Jan 08 17:51:10 localhost.localdomain sshd[9488]: error: Bind to port 22 on 0>
Jan 08 17:51:10 localhost.localdomain sshd[9488]: error: Bind to port 22 on :>
Jan 08 17:51:10 localhost.localdomain sshd[9488]: fatal: Cannot bind any addr>
Jan 08 17:51:10 localhost.localdomain systemd[1]: sshd.service: Main process

이후 systemctl restart sshd를 하는 도중 위와 같은 오류가 발생하면

$ sudo netstat -tulnp | grep 22
...
tcp6       0      0 :::22                   :::*                    LISTEN      811/systemd-worker

위와 같이 netstat을 통해 22번 포트를 점유하고 있는 프로세스를 확인한다.

이때 systemd-worker 프로세스는 시스템이 소켓 활성화(socket-activation)나 기타 systemd 관리 작업을 수행할 때 내부적으로 뜨는 systemd의 워커 프로세스 중 한다

socket-activation은 필요할 때만 데몬 프로세스를 실행하여, 리소스를 절약하거나 보안을 강화하려는 목적으로 사용되지만
일반적으로는 “sshd.service를 상시 구동”하는 방식을 더 많이 쓰고 익숙해한다.

위와 같이 config 수정 이후 sshd-service가 정상적으로 restart되지 못하는 이유를 발견하고 reboot를 해주어

$ systemctl status sshd
● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: e>
     Active: activating (auto-restart) (Result: exit-code) since Wed 2025-01->
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 4202 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=2>
   Main PID: 4202 (code=exited, status=255/EXCEPTION)
        CPU: 14ms

다시 정상적으로 sshd 서비스가 작동하는 것을 볼 수 있었다.

yum -y remove openstack-*

혹여나, 패키지 사이의 충돌이나 네트워크 문제를 방지하기 위해 openstack관련 패키지를 모두 제거하고 재설치한 뒤

root@xxx.xxx.xxx.xxx's password: root

이후 최종적으로 위와 같이 비밀번호를 입력하면

정상적으로 다시 설치가 진행되는 것을 볼 수 있다.

Trouble Shooting: (1045, "Access denied for user 'nova'@'xxx' (using password: YES)")

또한 설치 도중에 위와 같은 오류가 발생하였다.

이는 Nova 서비스가 MySQL/MariaDB에 접속하려고 했지만, 계정/비밀번호/권한 설정 문제로 접근이 거부된 것이기에

$ strings /root/packstack-answers-20250109-133708.txt | grep CONFIG_NOVA_DB_PW

CONFIG_NOVA_DB_PW=42c199ae5e114f27

우선 위와 같이 명령어를 구성하여 CONFIG_NOVA_DB_PW를 가져온다.

이떄 grep은 기본적으로 바이너리 파일에서 텍스트를 검색하려 하지 않으며, 이로 인해 제대로 된 결과가 표시되지 않기 때문에 strings 명령어를 통해 바이너리 파일에서 텍스트만 추출하여 grep한다.

추가적으로 수동으로 확인하기 위해 vi에서 /찾을문자열을 통해 검색을 수행할 수 있다

$ mysql

MariaDB [(none)]> SELECT user, host FROM mysql.user WHERE user='nova';
+------+------+
| User | Host |
+------+------+
| nova | %    |
+------+------+
1 row in set (0.065 sec)

'nova'@'%' 에 이미 계정이 존재하기 때문에, 호스트(IP) 접근 권한 자체는 열려 있는 상태임을 확인하고 다음 단게를 수행하였다

1. DB 비밀번호 재설정

MariaDB [(none)]> SELECT password FROM mysql.user WHERE user='nova';
+-------------------------------------------+
| Password                                  |
+-------------------------------------------+
| *327EE456B04FBA0B60C208CA4FF73D74FE4A9D90 |
+-------------------------------------------+

위와 같이 CONFIG_NOVA_DB_PW 비밀번호가 다른 것을 확인하였기에

ALTER USER 'nova'@'%' IDENTIFIED BY '42c199ae5e114f27';
FLUSH PRIVILEGES;

위와 같이 비밀번호를 변경해주었다.

만약 0 rows affected라는 로그가 나타난다면, 이미 같은 설정이었다는 의미일 가능성이 높으며 Query OK가 함께 뜬다면 정상적으로 적용됐다고 볼 수 있다.

mysql -u nova -p -h xxx.xxx.xxx.xxx
Enter password: 42c199ae5e114f27

또한 이후 위와 같이 직접 nova user로 MySQL에 접속 가능한지 확인한다.

2. DB bind-address 설정 (원격 접속 허용 여부)

/etc/my.cnf.d/server.cnf에 bind-address가 127.0.0.1 등으로 설정돼 있으면 외부 IP에서 접속이 불가하기 때문에, 이를 추가적으로 확인해주었다.

3. 방화벽, SELinux 확인

$ systemctl status firewalld.service 
○ firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; pre>
     Active: inactive (dead)
       Docs: man:firewalld(1)

$ sestatus
SELinux status:                 disabled

$ getenforce
Disabled

또한 위와 같이 방화벽과 selinux에 대해서도 추가적으로 확인해주었다.

이후 packstack을 통한 설치 시간을 단축시키기 위해 위와 같이 Memory와 CPU를 증가시켰다.

4. 기존에 생성된 Packstack Answer파일을 통한 실행

$ strings /root/packstack-answers-20250109-144919.txt | grep -E 'NOVA|NOVADB|NOVAAPI'
CONFIG_NOVA_INSTALL=y
CONFIG_NOVA_DB_PURGE_ENABLE=True
CONFIG_NOVA_DB_PW=d53737976fcd41f6
CONFIG_NOVA_KS_PW=9d90202996044ee7
CONFIG_NOVA_MANAGE_FLAVORS=y
CONFIG_NOVA_SCHED_CPU_ALLOC_RATIO=16.0
CONFIG_NOVA_SCHED_RAM_ALLOC_RATIO=1.5
CONFIG_NOVA_COMPUTE_MIGRATE_PROTOCOL=ssh
CONFIG_NOVA_PCI_ALIAS=
CONFIG_NOVA_PCI_PASSTHROUGH_WHITELIST=
CONFIG_NOVA_LIBVIRT_VIRT_TYPE=%{::default_hypervisor}
CONFIG_TROVE_NOVA_USER=trove
CONFIG_TROVE_NOVA_TENANT=services
CONFIG_TROVE_NOVA_PW=PW_PLACEHOLDER

우선 위와 같이 새롭게 packstack 설치를 진행하였을 때 생성된 answers 파일을 확인하고

$ strings packstack-answers-20250109-133708.txt | grep NOVA
CONFIG_NOVA_INSTALL=y
CONFIG_NOVA_DB_PURGE_ENABLE=True
CONFIG_NOVA_DB_PW=42c199ae5e114f27
CONFIG_NOVA_KS_PW=394f1a27cd51401a
CONFIG_NOVA_MANAGE_FLAVORS=y
CONFIG_NOVA_SCHED_CPU_ALLOC_RATIO=16.0
CONFIG_NOVA_SCHED_RAM_ALLOC_RATIO=1.5
CONFIG_NOVA_COMPUTE_MIGRATE_PROTOCOL=ssh
CONFIG_NOVA_PCI_ALIAS=
CONFIG_NOVA_PCI_PASSTHROUGH_WHITELIST=
CONFIG_NOVA_LIBVIRT_VIRT_TYPE=%{::default_hypervisor}
CONFIG_TROVE_NOVA_USER=trove
CONFIG_TROVE_NOVA_TENANT=services
CONFIG_TROVE_NOVA_PW=PW_PLACEHOLDER

DB 비밀번호를 맞춘 20250109-133708 answers 파일을 확인해본 결과
매 packstack 설치시 새롭게 NOVA 및 비밀번호가 생성된 것을 확인할 수 있었다.

$ mv packstack-answers-20250109-133708.txt 0-def-packstack-answers-20240109-133708.txt

$ packstack --answer-file=0-def-packstack-answers-20240109-133708.txt

따라서 기존의 answers 파일의 이름을 변경하고, 이를 통해 packstack 설치를 진행하였다.
(--gen-answer-file을 통해 새로운 answers 파일을 생성하는 것은 별도로 설정한 parameter 값을 수동으로 변경해주어야 하므로 기존의 answers 파일을 활용했다)

5. nova.conf 확인

$ cat /etc/nova/nova.conf | grep connection=mysql
#connection=mysql://nova:nova@localhost/nova
connection=mysql+pymysql://nova_api:42c199ae5e114f27@xxx.xxx.xxx.xxx/nova_api
connection=mysql+pymysql://nova:42c199ae5e114f27@xxx.xxx.xxx.xxx/nova

이후에도 정상적으로 설치가 진행되지 않아 nova.conf를 살펴보았다.
우선 /etc/nova/nova.conf에는 위와 같이 정상적으로 mysql connection 엔트포인트가 설정되어있었으나

$ cat /usr/share/nova/nova-dist.conf | grep connection
connection = mysql://nova:nova@localhost/nova

# connection = mysql+pymysql://nova:42c199ae5e114f27@xxx.xxx.xxx.xxx/nova

/usr/share/nova/nova-dist.conf에는 위와 같이mysql://nova:nova@localhost/nova로 엔드포인트가 설정되어 있어, 이를 갱신해주었다

/etc/nova/nova.conf : Nova 서비스의 실제 동작을 제어하는 주요 설정 파일
/usr/share/nova/nova-dist.conf : 기본 Nova 설정 옵션을 참고하는 템플릿 파일로, 시스템 업데이트나 참고용으로만 사용

항목	`/etc/nova/nova.conf`	`/usr/share/nova/nova-dist.conf`
역할	Nova의 실제 동작을 제어하는 설정	기본 Nova 설정 템플릿
사용자 편집 여부	사용자가 직접 편집 가능	사용자가 직접 수정하지 않음
우선순위	Nova 서비스에서 최우선적으로 사용	`/etc/nova/nova.conf`가 없을 때 참조

https://pnyet.web.id/solved-openstack-nova-access-denied-user-nova-localhost

Trouble Shooting: Testing if puppet apply is finished: xxx.xxx.xxx.xxx_network.pp

이후 정상적으로 설치를 진행하던 도중 위 단계에서 설치가 진행되지 않고 2시간정도 멈추어 있어, 문제를 해결하고자 하였다.

1. Network Configuration 확인

If you plan on having external network access to the server and instances, this is a good moment to properly configure your network settings. A static IP address to your network card, and disabling NetworkManager are good ideas.
https://garrett.github.io/jekyll-springboard-rdo/install/quickstart/

공식 문서에서도 NetworkManager를 disable하고 network.service를 사용하는 방법을 권장하고 있기에

ping 8.8.8.8
ping xxx.xxx.xxx.xxx

우선 위와 같이 이전에 설치한 IP와 8.8.8.8에 대해서 테스트를 진행하고, 이더넷 연결이 끊겨 있다는 사실을 알고난 후

$ ip addr
...
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
    link/ether x:x:x:x:x brd ff:ff:ff:ff:ff:ff
5: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
...

ip addr 명령어를 통해 OpenStack의 네트워크 인터페이스가 세팅되어가고 있으며, enp0s3에 대한 연결이 끊긴 것을 확인하였다.

2. /etc/sysconfig/network-scripts/ifcfg-enp0s3 설정

$ cat /etc/sysconfig/network-scripts/ifcfg-enp0s3 

TYPE=OVSPort
NAME=enp0s3
DEVICE=enp0s3
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
BOOTPROTO=none

이후 network.service에서 이전에 설정해둔 Static IP로서 enp0s3 인터페이스가 기능하도록 하기 위해 우선 enp0s3 인터페이스를 확인하고

Open vSwitch: 가상화된 환경에서 네트워크 트래픽을 처리하기 위한 소프트웨어 기반의 가상 스위치
OpenStack과 같은 클라우드 플랫폼 및 하이퍼바이저(KVM, Xen 등)에서 사용됨

DEVICETYPE=ovs, TYPE=OVSPort: enp0s3 인터페이스는 Open vSwitch 브리지(br-ex)에 연결된 포트 역할을 한다.
또한 OVS_BRIDGE=br-ex는 br-ex 브리지와 물리 NIC(enp0s3)를 연결하여 외부 네트워크와 OpenStack의 가상 네트워크를 통신하게 만들고 OpenStack의 Neutron 서비스는 이 구성을 통해 외부 네트워크와 가상 네트워크를 연결

3. /etc/sysconfig/network-scripts/ifcfg-br-ex 설정

$ vi /etc/sysconfig/network-scripts/ifcfg-br-ex

DEVICE=br-ex
NAME=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
OVSBOOTPROTO=“none”
IPADDR=<your_IP>
PREFIX=24 # <your_prefix>
GATEWAY=<your_gateway_IP>
IPV4_FAILURE_FATAL=no
IPV6INIT=no
DNS1=<DNS_Server_IP>
DNS2=<DNS_Server_IP>
ONBOOT=yes

위와 같이 설정을 ifcfg-br-ex 설정을 완료하고 network.service를 restart 한다.

ovs-vsctl add-port br-ex enp0s3

이후 위 명령어를 통해 Open vSwitch 브리지(br-ex)를 유지한 채 VM과 Host 간 통신을 보장하도록 한다.

위 명령어는 br-ex 브리지에 enp0s3를 연결하는 명령어로 다음과 같은 동작이 이루어진다
1. enp0s3 인터페이스는 Open vSwitch 브리지(br-ex)의 포트로 동작
2. br-ex를 통해 가상 머신 네트워크와 물리 네트워크 간의 통신 가능
3. 물리 네트워크에서 들어오는 트래픽은 enp0s3을 통해 브리지로 전달되며, 브리지는 이를 OpenStack 가상 네트워크로 라우팅

ovs-vsctl show

또한 위 명령어를 통해 Open vSwitch 브리지 및 포트 목록이 정상적으로 존재하는 것을 확인하였으며

Applying xxx.xxx.xxx.xxx_network.pp
xxx.xxx.xxx.xxx_network.pp: [ DONE ]
Applying xxx.xxx.xxx.xxx_compute.pp
Testing if puppet apply is finished: xxx.xxx.xxx.xxx_compute.pp [/]

다음 단계로 성공적으로 넘어갈 수 있었다

이전까지의 진행상황을 완료하고 Host 머신과 VM을 재시작한 이후 위와 같이 VM 내에서는 OpenStack이 활성화되었지만

Trouble Shooting: Network Connection after Host reboot

하지만 이전 상황과 동일하게 VM에서 외부로, Host에서 내부로의 네트워크 연결이 불가하였다.

Host와 VM 네트워크 정보를 확인한 결과

Host의 경우 DHCP를 사용하고, VM의 경우 고정 IP를 사용하고 있기 때문에 이러한 문제가 발생한 것으로 확인하였다.

하지만 Host PC의 경우 DHCP를 사용하는 것이 훨씬 안정적이고 안전한 방법이기에, Host와 Static IP를 사용하는 VM의 상태를 유지시키면서 이를 해결할 방법을 모색하였다.

1. ARP reset

Flat Provider에서 외부로 연결되는 Traffic의 Flow는 위와 같다

# Host (Window)
ping <br-ex의 게이트웨어_IP_주소>

따라서 위 Flow를 기반으로 우선Host 머신에서 VM의 br-ex에 설정된 Gateway의 주소로 ping을 전달하였고, 성공하는 것을 확인할 수 있었다

$ ip neigh show
<게이트웨이_IP> dev br-ex INCOMPLETE

$ arp -a
_gateway (<게이트웨이_IP>) at <incomplete> on br-ex

ARP (Address Resolution Protocol): 네트워크에서 IP 주소를 기반으로 해당 장치의 MAC 주소를 찾아주는 프로토콜
1. 장치가 네트워크에서 특정 IP로 데이터를 보내기 전에 ARP 요청(브로드캐스트)을 보낸다
2. 해당 IP를 가진 장치가 ARP 응답(유니캐스트)으로 자신의 MAC 주소를 알려준다

MAC 주소가 incomplete로 표시되는 것은 ARP 요청이 게이트웨이에 도달하지 못했거나 응답을 받지 못했음을 나타내는 것이기에

br-ex 인터페이스가 물리적 NIC와 제대로 연결되지 않았을 수 있어

# Host (Window)
> arp -a

인터페이스: xxx --- xxx
  인터넷 주소           물리적 주소           유형
  ...
  <게이트웨어_IP_주소>         <게이트웨이_MAC_주소>     동적
  ...

위와 같이 Host에서 관리하는 CentOS VM의 Gateway에 매핑된 MAC 주소를 알아낸 후

sudo arp -s <게이트웨어_IP_주소> <게이트웨이_MAC_주소>

IP 주소는 네트워크 계층(L3)에서 데이터 패킷을 목적지로 라우팅하기 위한 논리적 주소

MAC 주소는 데이터 링크 계층(L2)에서 물리적 장치 간 통신을 위해 사용

실제 네트워크 전송은 L2에서 이루어지기 때문에, 데이터가 IP 주소에서 MAC 주소로 매핑되어야 전송이 가능

위와 같이 arp에 Gateway의 MAC 주소를 다시 설정해주었다.

2. tcpdump

이후 더 자세하게 상황을 확인하기 위해 tcpdump를 통해 테스트를 수행하였다

# 기본 ARP 및 ICMP 트래픽 확인
sudo tcpdump -i br-ex arp or icmp

ARP 요청만 있고 응답이 없다면
게이트웨이가 ARP 요청에 응답하지 않거나, ARP 패킷이 게이트웨이에 도달하지 않았을 가능성이 있음
ICMP 요청만 있고 응답이 없다면
게이트웨이에서 ICMP 요청을 차단하거나 응답을 보내지 않을 가능성이 있음.
아무 트래픽도 보이지 않는다면
트래픽이 br-ex를 통해 전달되지 않거나, 라우팅 설정 문제일 가능성이 있음

# 특정 IP와의 통신 확인
sudo tcpdump -i br-ex host <게이트웨어_IP_주소>

ICMP 요청/응답
요청만 표시되고 응답이 없다면 게이트웨이가 패킷을 차단하거나 물리적 연결 문제가 있을 수 있음
ARP 요청
게이트웨이에 대한 ARP 요청이 보이지 않는다면, ARP가 제대로 작동하지 않을 가능성이 있음

Trouble Shooting: NAT Network Scenario

https://www.virtualbox.org/manual/ch06.html

하지만 이러한 방식은 여전히 Ethernet 어댑터가 변경되거나 DHCP에 의한 MAC 및 기타 충돌 문제가 있을 것이라고 판단하여

NAT Network를 기반으로 CentOS 9의 Network 세팅을 다시 진행하고자 하였다.

1. NAT Network

항목	NAT	NAT Network
외부 네트워크 연결	지원	지원
VM 간 통신	불가능	가능
설정 난이도	단순	복잡 (네트워크 세부 설정 필요)
사용 사례	단일 VM의 인터넷 연결	여러 VM 간 네트워크 구성 필요

NAT는 단일 VM의 외부 네트워크 연결에 적합하고, NAT Network는 여러 VM 간의 통신과 외부 연결을 동시에 지원한다.

따라서 위와 같이 VBox의 Network Tool에서 새로운 NAT Nertwork를 생성해주고

VM의 Adapter 1에 해당 인터페이스를 연결한 뒤

VM 내부에서 ping 8.8.8.8을 통해 인터넷에 연결된 것을 확인할 수 있다.

NAT 모드에서 네트워크가 실패하는 주된 이유는 라우팅 테이블, 게이트웨이 설정 부족 또는 VirtualBox 내부의 한계 때문이다
반면 NAT Network는 별도의 가상 네트워크를 생성하여 이러한 문제를 해결하고, 네트워크 연결이 안정적이게 가능하다

2. /etc/sysconfig/network-scripts/ifcfg-enp0s3

TYPE=Ethernet
BOOTPROTO=none
NAME=enp0s3
DEVICE=enp0s3
ONBOOT=yes

# NAT Network Static IP
IPADDR=10.0.2.15
PREFIX=24
GATEWAY=10.0.2.1

# DNS
DNS1=8.8.8.8
DNS2=8.8.4.4

따라서 OpenStack 통신을 위한 주소와 VM 자체의 인터넷 연결을 위해서 NAT Network 서브넷 범위 내에서 enp0s3 인터페이스에 고정 IP룰 할당하고 사용하는 시나리오 하에서 진행하고자 한다.

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:d9:c7:ca brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global noprefixroute enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fed9:c7ca/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ ip route
default via 10.0.2.1 dev enp0s3 proto static metric 100 
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100

$ ip neigh show
10.0.2.1 dev enp0s3 lladdr 52:54:00:12:35:00 REACHABLE

최종적으로 세팅된 네트워크들의 인터페이스는 위와 같다.

# ping -s <패킷 크기(byte)> -i <간격(s)> <목적지>
ping -s 1 -i 5 10.0.2.1

또한 Packstack 재설치를 진행하는 도중 이전에 사용하던 인터페이스의 Gateway로의 연결이 끊겨 진행되지 않았던 적이 있었기 때문에 위 명령어를 통해 네트워크 연결을 헬스체킹 하며 설치를 진행하였다.

systemctl enable network
systemctl start network
systemctl status network

또한 NAT Network 하에서 packstack을 통해 설치를 시작한 이후 network를 활성화 해야만한다.

3. /etc/sysconfig/network-scripts/ifcfg-br-ex

이전에 Bridge Adapter 인터페이스로 세팅하는 것과 동일하게

Applying 10.0.2.15_network.pp

위 단계에서 PackStack 설치가 멈춰있다면

Static IP 할당으로 인해 다른 NAT Network 상의 IP와의 충돌을 막기 위해 해제한 DHCP 설정으로 인해, PackStack의 br-ex 인터페이스가 IP를 받아오지 못하는 것일 확률이 높기 때문에

ONBOOT=yes
PEERDNS=no
NM_CONTROLLED=no
NOZEROCONF=yes
DEVICE=br-ex
NAME=br-ex
DEVICETYPE=ovs
OVSBOOTPROTO="none"
IPADDR=10.0.2.15
PREFIX=24
GATEWAY=10.0.2.1
IPV4_FAILURE_FATAL=no
IPV6INIT=no
DNS1=8.8.8.8
DNS2=8.8.4.4
TYPE=OVSBridge
OVS_EXTRA="set bridge br-ex fail_mode=standalone -- br-set-external-id br-ex bridge-id br-ex"

/etc/sysconfig/network-scripts/ifcfg-br-ex를 위와 같이 설정하고

systemctl restart network

network를 재시작해주면

설치를 정상적으로 완료할 수 있다.

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
    link/ether 08:00:27:d9:c7:ca brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fed9:c7ca/64 scope link 
       valid_lft forever preferred_lft forever
5: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether da:94:c0:b9:d1:fc brd ff:ff:ff:ff:ff:ff
6: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 08:00:27:d9:c7:ca brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::802a:d3ff:fe12:c94f/64 scope link 
       valid_lft forever preferred_lft forever
7: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 32:69:6e:12:b8:44 brd ff:ff:ff:ff:ff:ff
8: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a2:c1:0d:b5:c1:49 brd ff:ff:ff:ff:ff:ff

NAT Network Interface를 통해 설치한 OpenStack의 최종 네트워크 정보는 위와 같다.

Provider Network Creation

source keystonerc_admin

우선 위 명령어를 통헤 openstack admin privileges를 획득하고

neutron net-create external_network --provider:network_type flat \
	--provider:physical_network extnet --router:external

위 명령어를 실행해 Instance를 위한 새로운 Provider Network를 생성해 외부 세계와 통신할 수 있게 하고

Provider Network

OpenStack Neutron의 Provider Network는 가상 네트워크를 제공하지 않고, 기존 물리 네트워크와 직접 연결되는 네트워크 유형

클라우드 인프라의 네트워크 트래픽을 기존 네트워크 인프라(스위치, 라우터 등)와 직접 연결하여 처리

flat

네트워크가 VLAN 태그 없이 물리적 네트워크와 직접 연결

flat 네트워크는 단일 물리 네트워크와만 연결될 수 있음

VLAN 분리가 필요하지 않을 때 적합

extnet: Neutron 설정 파일(ml2_conf.ini)에 정의된 물리적 네트워크 이름

--router:external

네트워크가 라우터의 외부 네트워크로 사용될 수 있음을 지정

이 옵션이 설정된 네트워크는 라우터의 게이트웨이로 지정될 수 있음

주로 외부 네트워크(인터넷 연결)를 표현

neutron subnet-create \
  --name public_subnet \
  --enable_dhcp=False \
  --allocation-pool start=<IP_pool_first_address>,end=<IP_pool_last_address> \
  --gateway=<linux_gateway_IP> \
  external_network <your_network_in_CIDR>

neutron subnet-create \
  --name public_subnet \
  --enable_dhcp=False \
  --allocation-pool start=10.0.2.100,end=10.0.2.200 \
  --gateway=10.0.2.1 \
  external_network 10.0.2.0/24

Created a new subnet:
+-------------------+----------------------------------------------+
| Field             | Value                                        |
+-------------------+----------------------------------------------+
| allocation_pools  | {"start": "10.0.2.100", "end": "10.0.2.200"} |
| cidr              | 10.0.2.0/24                                  |
| created_at        | 2025-01-12T05:46:38Z                         |
| description       |                                              |
| dns_nameservers   |                                              |
| enable_dhcp       | False                                        |
| gateway_ip        | 10.0.2.1                                     |
| host_routes       |                                              |
| id                | 5a7d4bd3-011c-4c42-9f77-15c1fa9d8b83         |
| ip_version        | 4                                            |
| ipv6_address_mode |                                              |
| ipv6_ra_mode      |                                              |
| name              | public_subnet                                |
| network_id        | 61af13ca-6eb4-4916-9fe7-2e28d401e2bd         |
| project_id        | 8dc84595f82b4e6dac4a18f990b05c6d             |
| revision_number   | 0                                            |
| service_types     |                                              |
| subnetpool_id     |                                              |
| tags              |                                              |
| tenant_id         | 8dc84595f82b4e6dac4a18f990b05c6d             |
| updated_at        | 2025-01-12T05:46:38Z                         |
+-------------------+----------------------------------------------+

VM의 CentOS가 연결되어 있는 LAN 세팅에 맞추어서 Provider Network를 에 attach 된 subnet을 생한다.

CIDR:
- “네트워크 주소/마스크”를 한 번에 표기한 것
- 여기서는 xxx.xxx.xxx.0 네트워크에 서브넷 마스크가 255.255.255.0이란 의미
IP 풀 범위(start/end):
- OpenStack이 “Floating IP” 등으로 동적으로 할당할 수 있는 IP 구간
- 이미 사용 중인 IP(예: VM IP, 게이트웨이 IP)는 제외하고, 남는 구간을 범위로 지정

=> CIDR로 서브넷 범위를 정하고, 그 서브넷의 출입문(게이트웨이)를 지정한 뒤, 남은 IP들을 Floating IP 풀(할당 풀)로 설정해 OpenStack이 할당하도록 한 것

openstack security group rule create --proto icmp --dst-port -1 default
openstack security group rule create --proto tcp --dst-port 22 default

또한 이후 OpenStack에서 OpenStack에서 ICMP 및 SSH와 같은 프로토콜을 허용하면

http://<IP address>/dashboard

브라우저를 열고 위 URL로 접속하여

OpenStack 대시보드를 VM 에서 확인할 수 있다.

또한 설치에 굉장히 많은 시간이 들었기 때문에, VM의 snapshot을 생성해준다.

Installation Verification

$ more keystonerc_admin 
unset OS_SERVICE_TOKEN
    export OS_USERNAME=admin
    export OS_PASSWORD='8cbcacb658684041'
    export OS_REGION_NAME=RegionOne
    export OS_AUTH_URL=http://10.0.2.15:5000/v3
    export PS1='[\u@\h \W(keystone_admin)]\$ '
    
export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3

우선 keystonerc_admin에서 Dashboard에서 접속을 위한 Username과 Password를 확인할 수 있다.

이후 위와 같이 DashBoard에 정상적으로 접속된다면 OpenStack이 Healthy한 것을 확인할 수 있는 것이다.

Admin -> System -> SystemInformation -> Services에서 각 서비스 엔드포인트를 알 수 있으며

Compute Service 탭에서 모든 서비스가 UP 되어 있는 것을 확인할 수 있다.

동일하게 Block Storage와 Network Agent 탭에서 모든 cinder, neutron 서비스들이 Enabled되어 있고 Up 되어 있는 것을 확인할 수 있다.

또한 Compute -> Hypervisor 텝에서 Hypervisor의 상태가 정상인 것도 확인할 수 있다.

또한 위 DashBoard에서도 비밀번호를 업데이트 할 경우 KeyStone의 RC 파일도 업데이트 해주어야 CLI에서 정상적으로 사용할 수 있다.

$ cd /etc/systemd/system/multi-user.target.wants/ && ls *.service
atd.service              neutron-destroy-patch-ports.service        openstack-nova-conductor.service              openvswitch.service
auditd.service           neutron-dhcp-agent.service                 openstack-nova-novncproxy.service             rabbitmq-server.service
avahi-daemon.service     neutron-l3-agent.service                   openstack-nova-scheduler.service              redis.service
chronyd.service          neutron-metadata-agent.service             openstack-swift-account-auditor.service       rpcbind.service
crond.service            neutron-metering-agent.service             openstack-swift-account-reaper.service        rsyncd.service
cups.service             neutron-openvswitch-agent.service          openstack-swift-account-replicator.service    rsyslog.service
gnocchi-metricd.service  neutron-ovs-cleanup.service                openstack-swift-account.service               smartd.service
gnocchi-statsd.service   neutron-server.service                     openstack-swift-container-auditor.service     sshd.service
httpd.service            nftables.service                           openstack-swift-container-replicator.service  sssd.service
ip6tables.service        openstack-aodh-evaluator.service           openstack-swift-container.service             target.service
irqbalance.service       openstack-aodh-listener.service            openstack-swift-container-sharder.service     tuned.service
iscsid.service           openstack-aodh-notifier.service            openstack-swift-container-sync.service        vboxadd.service
kdump.service            openstack-ceilometer-notification.service  openstack-swift-container-updater.service     vboxadd-service.service
libstoragemgmt.service   openstack-ceilometer-polling.service       openstack-swift-object-auditor.service        virtlockd.service
libvirtd.service         openstack-cinder-api.service               openstack-swift-object-expirer.service        virtlogd.service
mariadb.service          openstack-cinder-backup.service            openstack-swift-object-reconstructor.service  virtqemud.service
mcelog.service           openstack-cinder-scheduler.service         openstack-swift-object-replicator.service     vmtoolsd.service
mdmonitor.service        openstack-cinder-volume.service            openstack-swift-object.service
memcached.service        openstack-glance-api.service               openstack-swift-object-updater.service
ModemManager.service     openstack-nova-compute.service             openstack-swift-proxy.service

만약 Dashboard로 사용중 문제가 생긴다면 위 서바스들을 Systemctl로 직접 검사할 수 있다.

$ systemctl status openstack-cinder-api.service 
● openstack-cinder-api.service - OpenStack Cinder API Server
     Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-api.service; enabled; preset: disabled)
     Active: active (running) since Sat 2025-01-11 23:49:12 EST; 1h 31min ago
   Main PID: 42241 (cinder-api)
      Tasks: 7 (limit: 50401)
     Memory: 190.7M
        CPU: 1min 42.121s
     CGroup: /system.slice/openstack-cinder-api.service
     ...

위는 openstack-cinder-api.service의 status를 살펴보는 예시이다.

SangYeon Min

다음 포스트

OpenStack Essentials - 1

STUDY-OPENSTACK

Cloud Computing

Traditional IT vs Cloud

Enabling Technologies

Traditional Infra vs Cloud Infra

Compute Stack

Cloud Deployment

Data Censter vs Cloud

Introduction to OpenStack

OpenStack Platform

Hypervisor

Component Services Overview

OpenStack Architecture

3-ways to use OpenStack

VirtualBox CentOS Installation

VirtualBox Installation

CentOS

CentOS 7

CentOS 7의 대안점

VirtualBox CentOS Installation

Trouble Shooting: Boot Order

Trouble Shooting: Internet Connection

1. Window 아웃바운드 규칙 허용

2. 네트워크 서비스 및 방화벽 확인

3. VirtualBox Bridge 네트워크 테스트

4. 기본 게이트웨이 설정 확인

5. Gateway 연결 상태 확인

6. SELinux 비활성화

7. 호스트 네트워크 공유 문제 확인

ipconfig로 확인한 IP 주소, Gateway 주소가 다른 이유

Trouble Shooting: Static IP Configuration

Static IP 권장의 이유

Trouble Shooting: Failed to download metadata from repository 'appstream'

Trouble Shooting: VirtualBox Guest Addition Installation

VBox GA Version Upgrade

OpenStack Installation

PacketTracer

PackStack

OpenStack Installation

NetworkManager 설정

Trouble Shooting: root@xxx.xxx.xxx.xxx's password

Trouble Shooting: (1045, "Access denied for user 'nova'@'xxx' (using password: YES)")

1. DB 비밀번호 재설정

2. DB bind-address 설정 (원격 접속 허용 여부)

3. 방화벽, SELinux 확인

4. 기존에 생성된 Packstack Answer파일을 통한 실행

5. nova.conf 확인

Trouble Shooting: Testing if puppet apply is finished: xxx.xxx.xxx.xxx_network.pp

1. Network Configuration 확인

2. /etc/sysconfig/network-scripts/ifcfg-enp0s3 설정

3. /etc/sysconfig/network-scripts/ifcfg-br-ex 설정

Trouble Shooting: Network Connection after Host reboot

1. ARP reset

2. tcpdump

Trouble Shooting: NAT Network Scenario

1. NAT Network

2. /etc/sysconfig/network-scripts/ifcfg-enp0s3

3. /etc/sysconfig/network-scripts/ifcfg-br-ex

Provider Network Creation

Installation Verification

OpenStack Essentials - 2

0개의 댓글