김마늘의 테크 레시피

 지난 포스팅에서 Oracle Cloud(이하 OCI)에서 무료로 제공하는 클라우드 리소스와, OCI CLI를 설치하고 세팅하는 방법에 대해서 알아보았습니다. 이번 포스팅에서는 IPsec VPN을 사용, BGP Site-to-Site VPN을 구현하여 OCI(Cloud)와 홉랩(On-premise)을 연결함으로써 하이브리드 클라우드 환경의 기본인 사이트 간 네트워크 연동을 구성하는 방법에 대해 알아보겠습니다.

1. 하이퍼바이저를 통한 인프라 가상화에서 Kubernetes Native로: Site-to-Site VPN 도입 배경

 지금까지 운영하던 홈랩은 On-premise 데이터센터를 모방한 모습이었습니다. 물론, 데이터 센터의 발끝도 따라가지 못했지만 그래도 하이퍼바이저를 통해 인프라를 가상화 하고, OPNsense를 통해 네트워크 Segmentation을 실현하여 용도에 맞게 네트워크를 격리하여 운영할 수 있었습니다.

 그러나 얼마전, 하이퍼바이저를 통한 인프라 가상화 환경을 버리고 Kubernetes Native 환경을 구축하기로 계획을 세웠습니다. 그러면서 자연스럽게, 지금까지 매뉴얼 한 인프라 조작 방식을 IaC(Infrastructure as Code)로 전환하기로 마음먹었습니다. 이를 구현하기 위해서 Cluster API를 도입이 필요하다 판단하였고, 이를 구현하기 위해 추가적인 인프라가 필요했습니다. Cluster API의 Management 클러스터 역할을 수행할 Kubernetes 클러스터가 필요했는데 이를 클라우드를 사용해서 구성해 보면 어떨까 하는 생각을 하게 되었습니다.

 가장 비용이 저렴하면서도 적당한 성능을 제공하는 클라우드 서비스를 찾던 중 눈에 띈것이 OCI였습니다. 그렇다면 OCI 내의 인프라와 홈랩을 구성하는 리소스들 간에 통신이 필요하게 됩니다.

 물론 퍼블릭 네트워크를 통해서도 충분히 구성이 가능하겠지만, Enterprise 환경을 모사하기 위해서 Site-to-Site VPN을 도입하기로 결정합니다. 이를 통해, 클라우드 인프라와 홈랩 리소스 간에 암호화된 통신을 제공하여 보안성과 기밀성을 향상할 수 있으며 두 Site 간의 네트워크를 L3 영역에서 통합할 수 있게 되어 더욱 유연한 인프라 구성이 가능할 것이라 판단하였습니다.

2. Site-to-Site VPN 구축을 위한 준비

1) 네트워크 준비

 Site-to-Site VPN을 구축하기 위해서는 우선적으로 두 Site간에 네트워크 CIDR 설계가 필요합니다. 두 Site가 VPN을 통해 거대한 L3 네트워크로 통합되기 때문에 네트워크 CIDR이 겹치게 되면 통신에 문제가 발생할 수 있습니다. 게다가 저의 경우 Cilium BGP Controlplane을 통해서 Service와 Pod CIDR을 투명하게 물리 네트워크 레벨로 광고할 계획까지 가지고 있기 때문에 네트워크 설계에 조금 더 주의가 필요했습니다. 아래 표는 네트워크 설계의 큰 틀로 이를 기반으로 상세한 네트워크를 설계하였습니다.

2) 인프라 준비

 OCI에는 VCN(Virtual Cloud Network, AWS의 VPC와 동일한 개념)와 Public Subnet이 필요합니다. 그리고 On-premise 환경(홈랩)에는 CPE(Customer-Premises Equipment)가 될 IPsec을 지원하는 장비가 필요합니다. 이번 포스팅에서는 공인 IP를 받는 OPNsense가 CPE 역할을 할 것입니다.

3. Site-to-Site VPN 네트워크 토폴로지

 다소 복잡한 Site-to-Site VPN의 토폴로지입니다. 각각의 요소들과 그 역할에 대해서 하나씩 정리해 보겠습니다. 각 요소들에 대해 잘 이해한다면, OCI와 OPNsense가 아닌 환경에서도 충분히 IPsec을 활용하여 Site-to-Site VPN 구축이 가능할 것입니다.

1) OCI 측 리소스

• DRG(Dynamic Routing Gateway) - 이름에서 알 수 있듯 VCN 내의 동적 라우팅 경로를 담당합니다. OCI VCN의 트래픽 중 인터넷을 향하는 트래픽이 아닌 Homelab을 향하는 트래픽에 대한 라우팅을 수행합니다. Site-to-Site VPN의 실제 구현을 담당하며, Oracle 측의 실제 라우터를 추상화한 요소라 보면 됩니다.
• Public Subnet - OCI 측 Subnet으로, 이곳에 인스턴스가 위치하고, 이 네트워크에 대한 정보를 BGP를 통해 라우팅 합니다.
• IGW(Internet Gateway) - OCI 측 인스턴스가 인터넷과 통신하기 위한 게이트웨이입니다. VPN 설정을 통해 홉랩으로 향하는 트래픽을 제외한 트래픽은 IGW를 향하게 됩니다.
• OCI IPsec Tunnel Interface(VTI, Vritual Tunnel Interface) - Site-to-Site VPN의 핵심 컴포넌트라 할 수 있겠습니다. OCI에서는 고가용성(HA)을 위해 2개의 터널 인터페이스를 제공하며, 이를 통해 CPE(Customer-Premisese Equipment)와 VPN 연결을 맺습니다. VTI는 Public IP와 Private IP 2개를 가지는데, Public IP는 OCI에서 랜덤 하게 제공해 주며, Private IP는 사용자가 직접 지정하게 됩니다.
• OCI BGP ASN - Homelab과 BGP 피어링을 맺을 때 사용할 AS Number입니다. BGP 피어링은 VTI의 Private IP를 통해서 이루어집니다.

2) Homelab 측 리소스

• CPE(Customer-premisees Equipment) - OCI와 Site-to-Site VPN을 맺기 위한 라우터로, 이번 포스팅에는 OPNsense를 기준으로 설명합니다. IPsec VPN 기능을 지원하여야 하며, BGP를 통한 동적 라우팅을 제공한다면 두 Site 간 네트워크 라우팅 정보 교환을 자동으로 할 수 있게 됩니다.
• Homlab IPsec Tunnel Interface - OCI 측의 VTI가 2개에 대응하는 Homelab 측 인터페이스로, Private IP를 가집니다. OCI 측 VTI와 쌍을 이루는 VTI는 같은 CIDR 블록(/31)에 속하게 됩니다. OCI 측과 다른 점은, OCI의 VTI의 경우 Public IP와 Private IP를 동시에 가지지만, Homelab의 VTI의 경우에는 OPNsense IPsec VPN 설정에서 생성하는 가상 인터페이스가 되며, Pirvate IP만을 가집니다. Public IP는 OPNsense가 ISP로부터 공급받는 IP 하나에 매핑됩니다.
• FRR Plug-in - BGP 피어링을 위해 플러그인으로, 간단히 설치가 가능합니다.

4. IPsec을 통한 Site-to-Site VPN 설정

 Site-to-Site VPN의 설정은 다음과 같은 절차를 거칩니다.

1. OCI Portal을 통한 IPsec 설정
2. CPE 설정을 통해 OCI가 Homelab을 인식하도록 설정
3. OPNsense(Homelab) 설정을 통해 CPE가 OCI를 인식하도록 설정
4. Homelab 측과 OCI 측의 BGP 피어링
5. Homelab 측 라우팅 경로 재분배 설정 및 방화벽 설정
6. OCI 측 라우팅 테이블 추가 및 Security List 설정
7. 두 Site 간 연결 테스트

 위 절차에 대해서 상세한 가이드는 다음과 같습니다. 처음 Site-to-Site VPN을 설정하는 분들도 그 개념을 이해하실 수 있도록 최대한 쉽게 설명해 보도록 하겠습니다.

1) OCI Portal을 통해 IPsec 설정

 먼저 OCI 측에 VCN(Virtual Cloud Network, AWS의 VPC와 동일한 개념)를 하나 생성해야 합니다. OCI 웹 콘솔에서 Networking > Virtual cloud networks > Actions > Start VCN Wizard을 선택합니다.

 VCN의 이름을 정해줍니다. CIDR값은 기본으로 입력된 값을 사용하도록 하겠습니다. 필요에 의해 변경할 수도 있습니다. 다음으로 다시 Start VCN Wizard 기능을 통해 Add Internet Connectivity and SIte-to-Site VPN to a VCN을 선택하여 Site-to-Site VPN을 구성합니다.

 Site-to-Site VPN을 설정한 VCN을 선택(방금 만든 VCN)하고, DRG를 생성합니다. 앞에서도 설명했지만 이 DRG를 통해 Site-to-Site VPN을 구성하고, On-Premise와 Cloud 간에 BGP를 통한 라우팅 정보 교환을 할 수 있게 됩니다.

 DRG와 연결되어 동적 라우팅 경로 광고 대상이 될 Subnet을 선택합니다. 여기에서는 Public Subnet을 선택하도록 하겠습니다.

 3단계에서는 라우팅 타입 선택 및 터널 인터페이스(VTI)에 대한 설정을 하게 됩니다. 우선 Routing type에 BGP dynamic routing을 선택합니다. 그리고 아래로 화면을 드래그하면 Tunnel 1 / Tunnel 2가 보이는데 이곳에서 VTI에 대해서 설정할 수 있습니다.

 Tunnel(VTI) 설정에 총 4가지 항목을 입력하게 됩니다. 각 항목에 대한 설정값은 아래와 같이 하였습니다. 이것은 절대적인 값은 아닙니다. 상황에 따라 변경해서 사용하면 됩니다.

• IKE version: Internet Key Exchange 버전으로 IKEv2가 최신 버전이고 효율성이 더 높음
• Your BGP ASN: Homelab 측 OPNsense Router의 BGP ASN 번호
• IPv4 inside tunnel interface - CPE: Homelab 측의 VTI의 사설 IP 주소
• IPv4 inside tunnel interface - Oralce: 오라클 측의 VTI의 사설 IP 주소

 위 다이어그램을 보면 각 인터페이스가 서로 어떤 역할을 하는지 좀 더 쉽게 이해할 수 있을 것입니다. VTI는 내부적으로는 /31의 CIDR을 사용하며, 외부적으로는 공인 IP를 통해 통신하게 됩니다. 그러면서 IKE를 통해 IPsec Tunnel을 생성하게 됩니다. 또한 BGP ASN 설정에서 눈치채셨겠지만 이 VTI 들을 통해 BGP 피어링을 맺고, 라우팅 정보도 교환합니다.

 마지막으로, CPE(Homelab) 측의 IPsec Tunnel을 구성할 장비의 Public IP 주소를 입력합니다. 저의 경우에는 OPNsense의 공인 IP 주소를 입력하였습니다. 이렇게 하면 OCI가 CPE(Homelab)을 인식할 수 있도록 하는 설정은 마무리되었습니다.

 이번 단계에서 생성한 것들을 정리해 보면 아래와 같습니다.

• OCI VCN, Subnet
• Site-to-Site VPN을 위한 DRG
• IPsec Tunnel을 위한 Tunnel Interface 2개, Shared secret, 공인 및 사설 IP 주소
• CPE(OPNsense) 측 정보

2) CPE(OPNsense)측 설정을 통해 OPNsense 측에서 OCI를 인식하도록 설정

 앞선 설정이 잘 마무리되었다면, OCI 측에 Tunnel에 각각 Public IP 주소가 할당되며, IKE Secret이 생성됩니다. OCI의 Site-to-Site VPN 메뉴에서 Tunnels 탭을 통해 이 값들을 확인할 수 있습니다. 이 값들을 OPNsense에 설정하여 CPE 측에서 OCI 측을 인식할 수 있도록 합니다.

 위 스크린샷에서 처럼 확인된 Tunnel Interface(VTI)의 Public IP 주소와 Shared secret 정보를 OPNsense 측에 입력해 줍니다. 해당 정보들은 Site-to-Site VPN 메뉴에서 터널 인터페이스의 detail 정보를 확인하면 볼 수 있습니다.

 OPNsense 설정은 위와 같습니다. OPNsense의 VPN 메뉴에서 IPsec을 선택, Pre-Shared Keys 메뉴를 통해 새로운 항목을 생성합니다. Tunnel 1과 Tunnel 2의 정보를 사용하여 2개의 항목을 생성합니다.

 이제 OPNsense 측에 VTI(Virtual Tunnel Interface)를 생성하여 OCI와 IPsec VPN 생성으로 할 수 있도록 합니다. Reqid 값이 중요한데 이 값을 통해서 VTI와 아래 Connection 설정에 나오는 Child가 서로 연결되게 됩니다. 즉 VTI와 Child의 내부 연결을 위한 고유한 식별자라고 보면 됩니다.

 다음은 IPsec Connectios를 설정하는 작업입니다. advanced mode를 활성화하고, Proposals를 aes256-sha1-modp2048 [DH14]로 설정합니다. 이 옵션은 256비트 AES로 데이터를 암호화하고, SHA-1로 무결성을 검증하며, 2024 비트 Diffie-Hellman 그룹 14를 사용하여 세션키를 교환하는 보안 정책입니다. Vesion은 IKEv2로 설정하고, Local address에는 OPNsense의 Public IP 주소를, Remote addresses에는 OCI 측 Tunnel interface 1의 Pubclic IP 주소를 설정합니다. 그리고 맨 아래 Description을 작성하고 Save를 클릭합니다.

 Save 후에 아래에 새로운 메뉴가 생깁니다. Local Authentication을 추가합니다. 특별히 설정할 것은 없고 기본 값이 채워진 상태로 Save를 누르면 됩니다. Remote Authentication 역시 마찬가지입니다.

 다음으로 Child를 생성합니다. 여기에서 한 가지 주의할 점이 있는데, 반드시 Policies를 체크 해제 해야 합니다. 만약 이를 체크하고 만들게 되면 모든 트래픽이 하이제킹 당해 OCI 쪽으로 흘러가게 되어 네트워크가 마비될 수 있습니다. Reqid는 Local과 Remote 옵션에 모두 0.0.0.0/0을 입력합니다. Policies 체크를 반드시 해제하는 것에 주의하며, 위 과정을 한번 더 반복하여 Tunnel 2에 대해서도 설정을 생성합니다.

 마지막으로 IPsec VPN 서비스를 실행하여 Site-to-Site VPN을 구현합니다. 연결이 잘 되면 다음과 같은 화면을 확인할 수 있습니다.

이번 단계에서 생성한 것들을 다시 정리해 보면 다음과 같습니다.

• Pre-Shared Keys: OCI Tunnel Interface 생성하면서 함께 발급된 Secret 값 2개를 통해 생성
• VTI 2개 생성: OPNsense 및 OCI 측 Tunnel Interface의 공인 IP 주소 및 사설 IP 주소를 설정값으로 하여 생성
• Connection 2개 생성: Local/Remote Authentication 2개 생성, Child 설정에서 Reqid 값을 통해 VTI와 연결 

3) Homelab 측과 OCI 측의 BGP 피어링

  위 스크린샷에서 볼 수 있듯, 두 사이트 간 VTI 연결은 문제 없이 되었는데, BGP 설정이 되어 있지 않은것을 확인할 수 있습니다. 즉, 두 사이트간 VPN 터널은 생성되었으나, BGP를 통한 동적 라우팅 경로 생성은 되지 않고 있는 상태입니다. 우선 OPNsense 측 설정부터 시작하겠습니다.

 먼저 OPNsense의 Routing > BGP의 첫 화면에서 Route Redistribution을 리스트를 생성합니다. 경로 재분배 옵션을 Connected routes로 선택하여, 현재 OPNsense와 연결되어 있는 라우팅 경로를 광고 후보로 둡니다.

 다음은 실제로 광고할 네트워크 주소 대역을 설정하는 Prefix Lists입니다. 가상머신의 네트워크 대역인 192.168.2.0/24를 목록에 추가합니다. Premit 옵션은 Network 옵션에 있는 네트워크를 광고하겠다는 의미입니다. Name은 이 Prefix Lists를 대표하는 그룹의 이름으로 같은 Namse을 사용하는 Prefix Lists들은 동시에 네트워크 광고 옵션에 적용됩니다. Sequence Number를 통해 여러 규칙을 하나의 Prefix Name 안에 그룹화할 수 있습니다. 저는 추가로 172.24.0.0/24도 추가해 보았습니다.

 다음 단계는 BGP neighbor를 설정하는 단계입니다. Peer-IP는 OCI 측 Tunnel Interface의 Private IP가 됩니다. Remote AS는 OCI 측의 BGP ASN인데 이것은 특별한 설정을 하지 않았으면 31898이 기본값입니다. Update-Source Interface는 OPNsense 쪽 VTI가 됩니다. 주의할 점은 Peer-IP와 VTI가 앞선 IPsec 설정에서 서로 터널을 맺은 쌍이어야 한다는 점입니다. Soft reconfiguration inbound 옵션을 활성화하여 세션을 재시작하지 않고도 정책을 변경할 수 있도록 합니다. 마지막으로 Prefix-List Out을 통해 광고할 네트워크 대역을 설정합니다. Tunnel 1과 같은 내용으로 Tunnel 2에 대한 BGP Neighbor를 설정합니다.

 이번 단계에서는 아래와 같은 요소들을 만들고 설정하였습니다.

• Route Redistribution 리스트
• Prefix List

 추가로 OPNsense에 vtysh를 통해 BGP 상태를 확인할 수 있습니다. BGP를 통해 Static 하게 설정하지 않아도 네트워크 대역을 자동으로 광고하고 또 받고 있는 것을 확인할 수 있습니다.

4) 방화벽 설정 

 방화벽은 2가지 룰을 추가합니다. 하나는 OPNsense의 Public IP가 부여되는 WAN 인터페이스, 하나는 IPsec이라는 이름을 가진 인터페이스입니다. 우선 방화벽에서 Aliase를 만들어 줍니다. OCI 측 Tunnel Interface의 Public IP 주소에 대해서 하나, 그리고 Port 번호 500과 4500에 대해서 Aliase를 만듭니다. 이를 가지고 WAN Interface에 방화벽 설정을 진행합니다.

• WAN Interface 방화벽 규칙

 다음은 IPsec 인터페이스입니다. 이 인터페이스는 특이하게도 Interfaces 목록에는 보이지 않고, 방화벽 Rules 목록에만 존재합니다. 이 인터페이스에 대한 방화벽 설정은 매우 특이한 모습을 보이는데, Homelab에서 OCI 측으로의 통신이 아닌, OCI에서 Homelab 측으로의 통신에 영향을 주는 방화벽 룰이라는 것입니다. 따라서 OCI 측에서 Homelab으로의 접근을 제어하고 싶다면 이 방화벽 설정이 중요한 역할을 합니다. 이번 포스팅에서는 모든 소스에 대해서 모든 프로토콜에 대해 Pass 룰을 적용하겠습니다.

• IPsec 인터페이스 방화벽 규칙

5) OCI 측 Routing Tables 추가 및 Security List 설정

 BGP를 통해서 네트워크 대역이 광고되고 있긴 하지만, OCI VCN에 Routing rule을 설정해 주어야 합니다. 아래와 같이 OCI에서 Homelab의 Subnet으로 통신할 수 있도록 라우팅 경로를 추가해 줍니다.  라우팅 경로의 Target은 반드시 DRG가 되어야 다른 사이트로의 통신이 가능하다는 점에 유의해야 합니다.

 다음은 Security List로 방화벽 규칙과 같은 것을 적용해 줍니다. 이 VCN에 기본적으로 존재하는 규칙인 22번 포트에 대한 TCP 연결(SSH) 허용과, ICMP 프로토콜에 대한 차단 규칙 이외에, Homelab의 특정 네트워크에서 발생하는 ICMP 규칙도 추가합니다. 이를 통해서 Homelab 측 VM에서 OCI 측 Instance에 Ping 테스트를 할 수 있게 합니다.

6) 두 Site 간 연결 테스트

 이제 정말 두 사이트 간 통신이 잘 작동하는지 확인할 차례입니다. 두 사이트에 테스트에 사용할 VM과 Intance를 생성합니다.

• Homelab VM(192.168.2.250)에서 OCI Instance(10.0.0.9)로 ping 테스트 및 ssh 접근 테스트 성공
• OCI Instance(10.0.0.9)에서 Homelab VM(192.168.2.250)으로 Ping 테스트 및 ssh 접근 테스트 성공

 OCI Home Region이 싱가포르이라 Ping이 약 100ms 정도에 달하긴 하지만, 통신 품질 자체는 아주 안정적인 것을 확인할 수 있습니다.

 이렇게 해서 두 Site 간 호스트들이 Private Network를 통해 통신할 수 있는 Site-to-Site VPN을 IPsec Tunnel을 사용하여 구현해 보았습니다. 구축하면서 방화벽 규칙 때문에 단방향으로만 통신이 된다던가, 혹은 BGP 피어링이 잘 맺어지지 않는 상황도 있었습니다. 대부분 저의 실수였고, 실수를 통해 많이 배울 수 있었습니다. 여담이지만, 엔지니어에게 이렇게 직접 핸들링할 수 있는 홈랩이 있다는 것은 여러 기술을 직접 채득 하기에 너무나도 좋은 환경인 것 같습니다.(망가지더라도 제가 고치면 되니까, 그 부분에 대한 부담도 적어서 좋구요...)

 어쨌든, 이번 구축을 통해 다음 단계로 나아갈 수 있게 되었습니다. 이제는 OCI Instance에 단일 노드 Kubernetes를 구성하고 Cluster API Managmenet Cluster를 구축할 차례입니다. 그리고 이를 통해 Homelab의 MiniPC 노드들을 프로비저닝 하는 것을 목표로 또 스터디해야겠습니다. 긴 포스팅 읽어주셔서 감사합니다.

 이전 포스팅에서, 오라클 클라우드의 Free Tier에서 제공하는 기능에 대해서 알아보았습니다. 이번 포스팅은 오라클 클라우드를 제어하는데 필요한 CLI 도구를 설치하고, 사용하는 방법에 대해서 알아보겠습니다.

1. OCI CLI 설치하기

 이번 포스팅에는 MacOS를 기반으로한 OCI CLI 설치 방법을 설명드립니다. 다른 운영체제에서 OCI CLI를 설치하는 방법은 위 링크를 통해 확인할 수 있습니다.

Brew Install

 MacOS에서는 Homebrew를 사용합니다. 따라서 Homebrew가 먼저 설치되어 있어야 합니다.

CLI Install

brew update && brew install oci-cli

CLI Upgrade

brew update && brew upgrade oci-cli

CLI Uninstall

brew uninstall oci-cli

 설치가 완료되면 아래 명령어를 통해 설치를 확인할 수 있습니다.

oci -v

# 2025년 10월 18일 기준
3.68.0

2. Configuration file 설정하기

명령어를 사용한 Setup

 oci setup config 명령어를 사용하면 대화 형식을 통해 Configuration file을 설정할 수 있습니다.

oci setup config

# 아래 내용이 출력됨
    This command provides a walkthrough of creating a valid CLI config file.

    The following links explain where to find the information required by this
    script:

    User API Signing Key, OCID and Tenancy OCID:

        https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#Other

    Region:

        https://docs.cloud.oracle.com/Content/General/Concepts/regions.htm

    General config documentation:

        https://docs.cloud.oracle.com/Content/API/Concepts/sdkconfig.htm


Enter a location for your config [/Users/<사용자 이름>/.oci/config]: # Enter를 입력하면 기본 경로에 config 파일이 생성됨
Enter a user OCID: # <사용자 OCID> 입력
Enter a tenancy OCID: # <Tenacy OCID> 입력
Enter a region by index or name(e.g.
1: af-johannesburg-1, 2: ap-batam-1, 3: ap-chiyoda-1, 4: ap-chuncheon-1, 5: ap-chuncheon-2,
6: ap-dcc-canberra-1, 7: ap-dcc-gazipur-1, 8: ap-delhi-1, 9: ap-hyderabad-1, 10: ap-ibaraki-1,
11: ap-melbourne-1, 12: ap-mumbai-1, 13: ap-osaka-1, 14: ap-seoul-1, 15: ap-seoul-2,
16: ap-singapore-1, 17: ap-singapore-2, 18: ap-suwon-1, 19: ap-sydney-1, 20: ap-tokyo-1,
21: ca-montreal-1, 22: ca-toronto-1, 23: eu-amsterdam-1, 24: eu-budapest-1, 25: eu-crissier-1,
26: eu-dcc-dublin-1, 27: eu-dcc-dublin-2, 28: eu-dcc-milan-1, 29: eu-dcc-milan-2, 30: eu-dcc-rating-1,
31: eu-dcc-rating-2, 32: eu-dcc-zurich-1, 33: eu-frankfurt-1, 34: eu-frankfurt-2, 35: eu-jovanovac-1,
36: eu-madrid-1, 37: eu-madrid-2, 38: eu-marseille-1, 39: eu-milan-1, 40: eu-paris-1,
41: eu-stockholm-1, 42: eu-zurich-1, 43: il-jerusalem-1, 44: me-abudhabi-1, 45: me-abudhabi-2,
46: me-abudhabi-3, 47: me-abudhabi-4, 48: me-alain-1, 49: me-dcc-doha-1, 50: me-dcc-muscat-1,
51: me-dubai-1, 52: me-ibri-1, 53: me-jeddah-1, 54: me-riyadh-1, 55: mx-monterrey-1,
56: mx-queretaro-1, 57: sa-bogota-1, 58: sa-santiago-1, 59: sa-saopaulo-1, 60: sa-valparaiso-1,
61: sa-vinhedo-1, 62: uk-cardiff-1, 63: uk-gov-cardiff-1, 64: uk-gov-london-1, 65: uk-london-1,
66: us-ashburn-1, 67: us-ashburn-2, 68: us-chicago-1, 69: us-gov-ashburn-1, 70: us-gov-chicago-1,
71: us-gov-phoenix-1, 72: us-langley-1, 73: us-luke-1, 74: us-newark-1, 75: us-phoenix-1,
76: us-saltlake-2, 77: us-sanjose-1, 78: us-somerset-1, 79: us-thames-1): # <사용자 Home region 번호> 입력
Do you want to generate a new API Signing RSA key pair? (If you decline you will be asked to supply the path to an existing key.) [Y/n]: y # 'y' 입력하여 새로운 api 키 생성
Enter a directory for your keys to be created [/Users/<사용자 이름>/.oci]: # Enter를 입력하면 key가 저장될 위치로 기본 위치가 지정됨
Enter a name for your key [oci_api_key]: # OCI Key 이름 지정, Enter를 입력하면 'oci_api_key'라는 기본 이름으로 지정
Public key written to: /Users/<사용자 이름>/.oci/oci_api_key_public.pem
Enter a passphrase for your private key ("N/A" for no passphrase): # Private Key의 passphrase를 입력, 'N/A'를 입력하면 passphrase 없이 진행
Repeat for confirmation: # 위에 입력했던 passphrase를 다시 입력, 'N/A'를 입력했어도 동일하게 입력
Private key written to: /Users/<사용자 이름>/.oci/oci_api_key.pem
Fingerprint: 74:5b:fa:ec:21:22:65:d6:31:c1:7a:08:12:41:0b:67
Config written to /Users/<사용자 이름>/.oci/config


    If you haven't already uploaded your API Signing public key through the
    console, follow the instructions on the page linked below in the section
    'How to upload the public key':

        https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#How2

 위 대화 형식의 configuration setup을 진행에 userOCID, teancy OCID, region index 정보를 입력해야 합니다. 각 정보를 확인하는 방법은 아래와 같습니다.

userOCID

 userID는 화면 우측 상단의 사람모양 아이콘을 클릭하고, 드롭다운 메뉴의 User settings를 클릭합니다.

 화면에 userOCID값이 출력됩니다. 가급적이면 이 값은 유출되지 않도록 하는게 좋습니다.

tenacyOCID / Home region / Home region key

 TenacyOCID 정보 역시 화면 우측 상단의 사람 모양 아이콘을 클릭하고 나타나는 드롭다운 메뉴에서 Teancy를 클릭하여 확인할 수 있습니다. 이 화면에서는 또한 Home region과 그에 대한 Key 값도 확인할 수 있습니다. Home region key 값을 통해 Region Identifier를 확인할 수 있기 때문에, 대화형 configration file setup에서 region index가 불확실한 경우 꼭 참고하여야 합니다.

 위 링크는 Region Key와 Region Identifier를 함께 확인할 수 있는 문서로 참고하여 region index를 확인하면 됩니다.

3. API Public key 업로드

 Configration file이 생성되면 기본적으로 홈(~/) 경로에 .oci/ 디렉토리 아래에 oci_api_key_public.pem이라는 파일이 생성됩니다. 해당 파일의 내용을 읽고 이를 OCI 콘솔에 업로드 합니다.

cat ~/.oci/oci_api_key_public.pem

# 아래 공개키 전체 내용을 복사
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA78+/qFddYMqYyA3Lvd9A
<중략>
AZmsXXl3seTPo189zcy3IwEC2PYeW/WLhc1QdINL6P7wWETLzNI0aDpNbNTL+HHH
3wIDAQAB
-----END PUBLIC KEY-----

4. OCI CLI 설정 확인

 아래와 같은 명령어를 통해 OCI CLI가 제대로 작동하는지 확인할 수 있다.

# 사용자 리스트업
oci iam user list

{
  "data": [
    {
      "capabilities": {
        "can-use-api-keys": true,
        "can-use-auth-tokens": true,
        "can-use-console-password": true,
        "can-use-customer-secret-keys": true,
        "can-use-db-credentials": true,
        "can-use-o-auth2-client-credentials": true,
        "can-use-smtp-credentials": true
      },
      "compartment-id": "<compartment OCID>",
# ... 생략

# 사용자 정보 확인
oci iam user get --user-id <사용자 OCID>
{
  "data": {
    "capabilities": {
      "can-use-api-keys": true,
      "can-use-auth-tokens": true,
      "can-use-console-password": true,
      "can-use-customer-secret-keys": true,
      "can-use-db-credentials": true,
      "can-use-o-auth2-client-credentials": true,
      "can-use-smtp-credentials": true
    },
# ... 생략
}

 위 설정을 통해 Oracle Cloud의 CLI 툴을 로컬에 설치하고, API 공개키 등록을 통해 클라우드 인프라에 명령어를 통해 제어할 수 있는 환경을 구성해 보았습니다.

 본격적인 홈랩 구성을 위한 준비단계가 잘 진행되고 있는것 같습니다.

 홈랩의 확장을 위해 여러 CSP를 찾아보던 중 오라클 클라우드의 혜자(?) Free Tier 정책이 있어 소개하고자 합니다. CSP 메이저 3사는 아니지만, 랩 환경에서는 충분한 기능과 사용량을 보장하기 때문에 1일 개발자나 테스트 용도의 인프라가 필요한 분들이라면 아주 매력적인 클라우드 서비스라 생각됩니다.

Free Tier 가입하기

 오라클 클라우드 Free Tier 가입은 위 페이지를 통해 할 수 있습니다. 가입 절차는 간단한 편이고, 신용 카드 정보를 입력하면 여느 클라우드처럼 해외 결제가 이루어졌다가 취소됩니다. 저의 경우에는 홈 리전을 싱가포르로 설정하였기 때문에 1.38 싱가포르 달러가 결제되었다가 취소되었습니다.

 최초 가입 시 홈 리전을 선택하게 되는데, 이때 선택된 홈 리전은 변경이 불가능합니다. 또한 홈 리전에서만 Free Tier 제품들을 사용할 수 있으므로 선택에 신중을 가해야 합니다. 저의 경우에는 ARM 기반의 Compute Instance 사용이 주목적이었는데, 한국 리전에는 해당 자원의 여유가 없다는 경고가 있어, 싱가포르를 홈 리전으로 선택하게 되었습니다.

Free Tier에서 제공하는 기능들

 오라클 Free Tier는 상당히 다양하고, 넉넉한 기능과 자원을 Free Tier로 제공합니다. 위 페이지에서 다양한 Free Tier 제품군들을 검색해 볼 수 있습니다. 총 27개의 서비스를 Always Free로 제공하고 있으며, 추가로 가입한 30일 동안 300$ 상당의 크레디트를 제공하여 Free Tier가 아닌 제품도 사용해 볼 수 있습니다. 아래는 주요 리소스 카테고리 별 Free Tier 서비스에 대한 요약입니다.

1. Infrastructure

2. Database

3. Networking

4. Observability & Management

5. 추가 서비스

 이 정도 수준이면, Compute Instance의 유휴 인스턴스 정책만 잘 준수한다면 소규모 서비스를 하는 데에도 부족함이 없는 수준의 강력한 기능이라 할 수 있겠습니다. 웬만한 개발 환경이나 테스트 환경은 찜 쪄먹는 수준이 아닐까 합니다.

 오라클 클라우드의 Free Tier를 활용해서 도전적인 홈랩 프로젝트를 시작해 보려고 합니다. 기존 On-Premise 장비와 클라우드 인프라를 엮어서 하이브리드 클라우드로 진화시켜 볼 예정입니다. 시간은 좀 걸리겠지만, 재미있는 여정이 될 것 같습니다.

 이전 포스팅 'PXE 부팅으로 Ubuntu 22.04 설치하기 [1편]'에서 이어지는 포스팅입니다. 이전 포스팅을 보지 않았다면 먼저 보고 오시는 것을 추천드립니다.

PXE 부팅을 위한 준비

 PXE 부팅을 위해서는 PXE 부팅의 대상이 되는 PXE 클라이언트와, DHCP 서버, TFTP 서버와 HTTP 서버가 필요합니다. 규모에 따라서 DHCP, TFTP, HTTP 서버 3대를 모두 통합해서 운영할 수도 있고, 각각을 분리해서 운영할 수 도 있습니다. 이번 포스팅에서는 총 3대의 서버로 PXE 부팅 환경을 구성하고 실습해 보도록 하겠습니다.

 DHCP 서버는 독립적으로 구성하고 TFTP와 HTTP 서버의 역할을 통합하여 하나의 서버에서 PXE 부팅 서비스를 제공하고자 합니다. 그러면 각 서버에 어떤 서비스와 어떤 설정을 구성해야 하는지 알아보도록 하죠. Ubuntu 22.04를 기준으로 살펴보도록 하겠습니다. 

1. DHCP 서버

 DHCP서버는 PXE 부팅에서 두 가지 역할을 합니다. 첫 번째는 PXE Client에게 IP 주소를 부여하는 것으로, PXE 부팅의 여러 단계들이 각 서버와의 통신을 통해 이루어 지므로 PXE Client의 IP 주소는 필수입니다. 두 번째는 TFTP 서버의 IP 주소 정보와 부팅 파일의 이름입니다. 이를 통해 PXE Client는 TFTP 서버로부터 부팅의 가장 첫 번째 작업을 수행할 수 있게 됩니다. 우선 Ubuntu에서 흔히 사용되는 ISC DHCP를 기준으로 이러한 설정을 적용하는 방법에 대해서 알아보겠습니다.

(1) ISC DHCP 서버 설치 및 설정 파일 수정

• DHCP 서버 설치

sudo apt update
sudo apt install isc-dhcp-server

• DHCP 서버 설정파일 수정

#설정 파일 편집
sudo vim /etc/dhcp/dhcpd.conf

#/etc/dhcp/dhcpd.conf

subnet 192.168.100.0 netmask 255.255.255.0 {
  range 192.168.100.241 192.168.100.250;  #DHCP IP 주소 범위
  option routers 192.168.100.1;           #Gateway 주소
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  next-server 192.168.100.200;  # TFTP 서버 IP (PXE 서버 IP)
  filename "pxelinux.0";      # 부팅 파일 이름
}

 DHCP 설정에서 next-server는 TFTP 서버의 IP 주소를 입력합니다. filename은 부트로더의 파일 이름을 지정해 줍니다. 이런 설정을 통해 PXE Client가 DHCP 서버에 IP 주소 할당을 요청하면, DHCP 서버에서는 IP 주소와 PXE 부팅의 시작점이 되는 TFTP 서버의 정보를 제공하게 됩니다.

• DHCP 서비스 시작

sudo systemctl enable isc-dhcp-server
sudo systemctl restart isc-dhcp-server

(2) OPNsense Kea DHCP 서버 설정

 아래 내용은 OPNsense의 Kea DHCP를 설정하는 방법입니다. 웹 GUI를 통해 쉽고 간단하게 설정할 수 있습니다.

•  Kea DHCP 서비스 실행

 위 그림과 같이 OPNsense 관리 웹 페이지 왼쪽 메뉴의 Service > Kea DHCP > Kea DHCPv4 메뉴로 진입하여 Settings 탭에서 Enabled 체크박스를 활성화합니다. Interface는 DHCP 서비스를 실행할 인터페이스인데 PXE 클라이언트가 속할 네트워크의 인터페이스를 선택해 줍니다. 그리고 Apply 버튼을 클릭하여 DHCP 서비스를 실행합니다.

• DHCP 서비스 설정

 DHCP 서비스가 실행되고 나면 Subnets 탭으로 이동하여 [+] 버튼을 눌러 DHCP 서비스 설정을 생성합니다. 위 그림과 같은 창에서 Subnet, Pools, Routers, DNS Servers와 같은 일반적인 DHCP 설정과 함께 PXE 부팅을 위한 Next Server, TFTP bootfile name 설정을 해줍니다. Next server에는 PXE 서버의 IP 주소(정확히는 부트로더를 제공하는 TFTP 서버의 IP 주소)를 입력하고, TFTP bootfile name에는 부트 파일의 이름을 입력해 줍니다. 이 설정을 Save 한 후 Kea DHCPv4 데몬을 재시작(Save 후 빠져나온 Subnets 탭 화면의 우측 상단 리프레시 버튼 클릭)하여 설정을 로드시킵니다.

 여기서 주의할 점은 TFTP server를 공란으로 둔다는 것입니다. 저의 테스트 환경에서는 PXE Client가 Next server의 정보를 통해 부팅을 시작할 수 있었습니다.

2. PXE 서버

 이번 실습에서 PXE 서버는 TFTP 서버와 HTTP 서버 두 가지 역할을 모두 수행합니다. 역시 Ubuntu 22.04를 기준으로 설명하겠습니다.

(1) TFTP 서버 설치 및 설정

• TFTP 서버 설치

sudo apt update
sudo apt install tftpd-hpa

• TFTP 설정 파일 수정

#설정 파일 편집
sudo vim /etc/default/tftpd-hpa

#/etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"

 이 파일의 내용을 조금 살펴보겠습니다. 우선 TFTP_USERNAME의 경우 TFTP 서버 데몬이 실행될 때 사용할 사용자 계정을 지정하는 것으로, 일반적으로 보안상 루트 권한이 아닌 비특권 사용자(not-privileged user)를 사용합니다. 해당 사용자 계정을 다른 것으로 변경해도 상관은 없으나 그렇게 되었을 때는 변경된 사용자 계정이 TFTP_DIRECTORY에 접근할 수 있는 권한이 있어야 합니다.

 TFTP_DIRECTORY는 TFTP 서버가 파일을 제공할 루트 디렉터리를 지정하는 역할을 하고 클라이언트가 TFTP 프로토콜을 요청할 때, 이 디렉토리를 찾습니다.

 다음으로 TFTP_ADDRESS는 TFTP 서버가 수신 대기할 네트워크 주소와 포트를 의미하고, 현재의 설정은 서버의 모든 IP 주소의 포트 69번에서 수신을 대기하는 의미입니다. 참고로 TFTP의 경우 UDP 프로토콜을 사용합니다.

 마지막으로 TFTP_OPTIONS에 --secure의 경우 TFTP 서버가 chroot 환경에서 실행되게 하는 것으로 클라이언트가 TFTP 서버에 접근할 때 TFTP_DIRECTORY 이외의 다른 디렉터리로 접근하는 것을 막는 역할을 하여 보안성을 강화합니다.

• TFTP용 디렉토리 생성 및 권한 설정

sudo mkdir -p /var/lib/tftpboot
sudo chmod -R 777 /var/lib/tftpboot

 이후 이 디렉터리에 PXE 부팅에 필요한 파일들이 위치하게 됩니다.

• TFTP 서비스 시작

sudo systemctl enable tftpd-hpa
sudo systemctl restart tftpd-hpa

(2) HTTP 서버 설치

 HTTP 서버는 nginx, apache2 등 어떤 것을 사용해도 상관은 없습니다. 이번 포스팅에서는 nginx를 기준으로 하겠습니다.

• nginx 설치

sudo apt udpate
sudo apt install nginx
sudo systemctl enable nginx --now

• ISO 이미지용 디렉터리 생성

sudo mkdir -p /var/www/html/ubuntu

 이 디렉터리에 Ubuntu 22.04 이미지를 복사하여 이후 PXE Client가 다운로드할 수 있도록 합니다.

(3) ISO 이미지 준비

• Ubuntu 22.04 ISO 이미지 다운로드

wget https://releases.ubuntu.com/jammy/ubuntu-22.04.5-live-server-amd64.iso

• HTTP 서버에 ISO 이미지 제공

sudo cp ubuntu-22.04.5-live-server-amd64.iso /var/www/html/ubuntu/

• ISO 이미지 마운트 및 부팅 파일 복사

#ISO 이미지 마운트
sudo mkdir /mnt/iso
sudo mount -o loop ubuntu-22.04.5-live-server-amd64.iso /mnt/iso/

#부팅 파일 복사
sudo cp /mnt/iso/casper/vmlinuz /var/lib/tftpboot/
sudo cp /mnt/iso/casper/initrd /var/lib/tftpboot/

#ISO 이미지 마운트 해제
sudo umount /mnt/iso

(4) PXELINUX, Syslinux 설치 및 PXE 부팅 설정

 PXELINUX는 PXE 부팅 환경에서 사용하는 부트로더입니다. 정확히는 Syslinux 프로젝트의 일부로, PXE 부팅을 지원하는 부트로더인 pxelinux.0 파일을 의미합니다.

• PXELINUX, Syslinux 설치

sudo apt update
sudo apt install pxelinux syslinux-common

sudo cp /usr/lib/PXELINUX/pxelinux.0 /var/lib/tftpboot/
sudo cp /usr/lib/syslinux/modules/bios/* /var/lib/tftpboot/

 앞선 DHCP 설정에서 filename(ISC DHCP) 또는 TFTB bootflie name(Kea DHCP)으로 설정했던 pxelinux.0이 드디어 등장했습니다. 이 파일을 tftp 서비스 대상 디렉터리인 /var/lib/tftpboot/ 경로로 복사해 두면, PXE Client가 IP를 할당받은 다음 이 파일을 다운로드하여 실행하게 됩니다.

• 설정 디렉토리 및 파일 생성

sudo mkdir /var/lib/tftpboot/pxelinux.cfg
sudo vim /var/lib/tftpboot/pxelinux.cfg/default

#/var/lib/tftpboot/pxelinux.cfg/default

DEFAULT ubuntu
LABEL ubuntu
  MENU LABEL Install Ubuntu 22.04
  KERNEL vmlinuz
  APPEND initrd=initrd ip=dhcp url=http://192.168.100.200/ubuntu/ubuntu-22.04.5-live-server-amd64.iso

 위 파일 설정에서 PXE 부팅에 사용할 커널과 ISO 이미지의 위치, 부팅 관련 옵션들을 정의할 수 있습니다. PXE Client는 pxelinux.0 파일을 다운로드하여 실행하게 되면 설정파일인 pxelinux.cfg/default를 읽어서 부팅 메뉴를 표시합니다. 현재의 설정은 커널로 vmlinuz로 하고, initrd 경로를 알려주며, ISO 파일은 http 서버로부터 얻도록 되어 있습니다. 다시 한번 각 파일의 역할에 대해서 정리해 보면 아래와 같습니다.

• /var/lib/tftpboot/pxelinux.0: PXE 부트로더
• /var/lib/tftpboot/pxelinux.cfg/default: 부팅 메튜와 설정(커널, initrd 경로, ISO 이미지 위치 등)을 정의
• /var/lib/tftpboot/vmlinuz: 부팅할 커널 이미지
• /var/lib/tftpboot/initrd: 초기 RAM 디스크 이미지

(5) 방화벽 설정

 방화벽 설정은 옵션사항입니다. 보안성 강화를 위해서는 방화벽을 설정하고 필요한 포트만 개방하는 것이 좋습니다.

sudo ufw allow 69/udp  # TFTP
sudo ufw allow 80/tcp  # HTTP
sudo ufw enable

(6) PXE Clinet 준비 및 PXE 부팅 테스트

 이제 기본적인 설정은 마무리되었습니다. PXE Client를 준비하고 부팅하여 잘 작동하는지 확인해 봅시다. 베어메탈 서버(PXE Client)를 DHCP 서비스가 가능한 LAN 영역에 연결한 후, BISO/UEFI에서 네트워크 부팅(PXE)을 활성화한 후 재부팅합니다. 단, 이번 포스팅에서 사용되는 PXE Client는 VMware vSphere 환경에서 생성된 VM을 기준으로 합니다. VMware vSphere의 VM들은 기본적으로 PXE 부팅이 활성화되어 있습니다.

• VM의 전원을 켠 후 PXE 부팅 테스트

• PXE 부팅의 상세 프로세스
  
  1. PXE 부팅 기능이 활성화된 Client가 DHCP 서버에 IP를 요청
  2. DHCP 서버는 PXE Client에 IP 주소를 할당하면서 TFTP 서버의 IP와 bootfile((pxelinux.0)의 경로를 전달
  3. PXE Client는 해당 정보를 바탕으로 TFTP 서버(이번 포스팅에서는 PXE Server)에 접근
  4. pxelinux.0를 다운로드하여 실행한 후, TFTP 서버의 /var/lib/tftpboot/pxelinux.cfg/default를 읽고 설정에 따라 추가 파일(vmlinuz, initrd)을 다운로드하고 부팅 시작
  5. HTTP 서버(PXE Server)에 ISO 파일을 요청
  6. HTTP 서버에서 ISO 파일을 다운로드하여 OS 설치 수행

 PXE Client의 전원을 켜고 조금 기다리면 위와 같이 IP 할당부터 ISO 이미지 다운까지의 과정을 확인할 수 있으며, 최종적으로는 부팅 USB로 서버를 부팅했을 때와 같은 화면을 볼 수 있습니다.

 그런데 문제는, 이렇게 하면 결국 설치 작업은 수동으로 진행해야 한다는 단점이 그대로 남습니다. 사용자 이름, 네트워크 설정, 디스크 사이즈 등의 작업들 말이죠. 이러한 작업들 역시 완전히 자동화할 수 있어야 PXE 부팅의 의미가 있을것 같습니다.

PXE 부팅 후 Ubuntu 설치 자동화

 Ubuntu의 경우에는 20.04부터 Autoinstall 기능을 지원하여 설치 과정을 자동화 할 수 있습니다. 이를 PXE 부팅과 통합하면 수동 입력 없이 Ubuntu가 자동으로 설치된 상태로 부팅되게 할 수 있습니다. 이를 위해서는 몇 가지 파일과 설정에 변경이 필요합니다.

1. Cloud-init 설정파일 준비

 Cloud-init을 위해 user-data와 meta-data 두 가지 파일을 준비해야 합니다. 이 두 파일은 HTTP 서버에 위치하여 Ubuntu 22.04 부팅 시에 사용되게 됩니다.

(1) 설치 자동화용 파일이 위치할 디렉터리 및 파일 생성

sudo mkdir -p  /var/www/html/ubuntu/autoinstall
sudo touch /var/www/html/ubuntu/autoinstall/user-data
sudo touch /var/www/html/ubuntu/autoinstall/meta-data

(2) user-data 파일

sudo vim /var/www/html/ubuntu/autoinstall/user-data

#/var/www/html/ubuntu/autoinstall/user-data

autoinstall:
  version: 1
  locale: en_US
  keyboard:
    layout: us
  network:
    network:
      version: 2
      ethernets:
        all:
          match:
            name: "en*"
          dhcp4: true
  storage:
    layout:
      name: lvm
      match:
        size: largest
  identity:
    hostname: ubuntu-server
    username: admin
    password: "$6$2SoqtUzTTiK9X8lA$.8t0lttpdPFsYdGPzP9kCXeeKZa9681K4U.4OBbZPgva2vbZxRu1zn9sAz4rHvfqoMvmvOHKT4mRNoe6yu/ko1"
  ssh:
    install-server: true
    allow-pw: true
  late-commands:
    - lvresize -l +100%FREE ubuntu-vg/ubuntu-lv -r

 이 설정파일의 몇 가지 내용들을 살펴보고 넘어가겠습니다.

• network 필드에서는 'en'으로 시작하는 이더넷 인터페이스를 모두 DHCP4를 통해 자동으로 IP 할당을 받도록 하겠다는 의미입니다.
• storage 필드에서는 PXE Client의 스토리지 중 가장 큰 것(size: largest)을 골라 LVM(name: lvm) 형식으로 볼륨을 구성하겠다는 의미입니다.
• identity 필드에서는 hostname과 username, password를 설정할 수 있습니다. password에는 sha-512 해시값이 들어가야 합니다. 아래 명령어를 통해 이를 확인할 수 있습니다. 사용할 password의 경우 필요에 따라 바꾸어 사용하길 권장합니다.

#'passwd' 문자열의 sha-512 해시값 출력
mkpasswd -m sha-512 'passwd'

$6$2SoqtUzTTiK9X8lA$.8t0lttpdPFsYdGPzP9kCXeeKZa9681K4U.4OBbZPgva2vbZxRu1zn9sAz4rHvfqoMvmvOHKT4mRNoe6yu/ko1

• ssh 필드에서는 ssh 데몬 설치 여부 및 password 사용한 로그인 여부를 선택할 수 있습니다.
• late-command 필드에서는 설치가 완료된 후 실행할 명령어로 여러 가지를 입력할 수 있습니다. 위 설정 파일에서는 lvm 사이즈를 디스크 여유공간을 모두 사용하도록 확장하는 명령어입니다. 위 명령어 없이 기본 lvm으로 설치 시에 디스크의 50%가 사용되지 않기에 위와 같은 명령어를 통해 모든 공간을 사용할 수 있도록 합니다.

(3) meta-data

sudo vim /var/www/html/ubuntu/autoinstall/meta-data

#/var/www/html/ubuntu/autoinstall/meta-data

instance-id: iid-ubuntu-pxe

2. PXE 설정 수정

 /var/lib/tftpboot/pxelinux.cfg/default 파일을 아래와 같이 편집합니다.

#/var/lib/tftpboot/pxelinux.cfg/default

DEFAULT ubuntu-autoinstall
LABEL ubuntu-autoinstall
  MENU LABEL Install Ubuntu 22.04
  KERNEL vmlinuz
  APPEND initrd=initrd ip=dhcp url=http://192.168.100.200/ubuntu/ubuntu-22.04.5-live-server-amd64.iso autoinstall ds=nocloud-net;s=http://192.168.100.200/ubuntu/autoinstall/

 기존 설정의 APPEND 필드 마지막에 autoinstall ds=nocloud-net;s=http://192.168.100.200/ubuntu/autoinstall/를 추가하였습니다. 이렇게 Autoinstall 옵션이 적용되고, 앞서 만들었던 user-data와 meta-data의 설정을 통해 자동으로 설치를 진행하게 됩니다.

 위와 같이 Autoinstall 설정을 통해 PXE 부팅 후 자동으로 IP 주소 할당 및 OS 설치와 설치 후 명령어까지 잘 적용되는 것을 확인할 수 있었습니다.

 이 외에도 OS 종류를 골라서 설치한다거나, 사용자 이름이나 기타 설정을 다르게 하여 설치하는 등 다양한 옵션을 통해 인프라 환경에 맞춰 PXE 부팅을 설정할 수 있습니다. 해당 내용은 PXE 부팅 심화 과정으로 다루도록 하고, 이번 PXE 부팅 시리즈는 여기서 마무리하도록 하겠습니다. 감사합니다.

 소수의 베어메탈 서버 또는 가상 머신(VM)의 경우에 수동으로 OS를 설치하는 작업은 크게 어렵지 않습니다. 베어메탈의 서버의 경우 부팅 USB를 통해서, VM의 경우 ISO 파일을 Import 하는 형식으로 합니다. 그러나, 다수의 베어메탈 서버나 VM을 대상으로는 이러한 방식이 매우 비효율적이 됩니다. 이런 경우 동시에 여러 대의 노드에 OS를 설치할 수 있는 방법이 필요한데 이번 포스팅에서는 그 방법 중 하나인 PXE 부팅에 대해서 알아보겠습니다.

일반적인 부팅 프로세스

 PXE 부팅에 대해서 학습하기 전에, 우선 일반적인 컴퓨터의 부팅 프로세스에 대해서 알아 보겠습니다.

1. 전원 공급(Power-On)

 컴퓨터의 전원이 켜지면 CPU, 메모리, 저장 장치 등 하드웨어에 전기가 공급됩니다. 이때 CPU는 초기화되고, 어디서부터 명령을 실행할지 찾기 시작합니다.

2. BIOS/UEFI 실행

 전원이 들어오면 가장 먼저 실행되는 건 BIOS(Basic Inpout/Output System) 또는 UEFI(Unifed Extensible Firmware Interface)입니다. (최근의 컴퓨터의 경우에는 대부분 UEFI를 사용하지만, 이를 BIOS라 칭하기도 합니다.) 이는 컴퓨터 메인보드에 내장된 작은 소프트웨어로, 하드웨어를 초기화하고 기본적인 동작을 점검합니다. 이를 POST(Power-On Self-Test)라고 하는데, 참고로 일반 사용자 PC의 경우에 이 과정이 상당히 짧지만, 서버의 경우에는 수십 초에서 수분이 걸리기도 합니다.

3. 부트로더 로드

 BIOS/UEFI는 부팅할 디스크를 찾아서 그 안에 있는 부트로더(Bootloader)를 메모리에 적재합니다. 이 부트로더는 운영체제(OS)를 실행하기 위한 준비를 하는 작은 프로그램으로 Windows는 Windows Boot Manager, 리눅스의 경우에는 GRUB이 그 역할을 합니다. 부트로더는 보통 저장 장치의 특정 영역(MBR 또는 EFI 파티션)에 저장되어 있습니다.

4. 운영체제 커널 로드

 부트로더가 실행되면 운영체제의 핵심 부분인 커널(Kernel)을 메모리에 불러옵니다. 커널은 하드웨어와 소프트웨어를 연결하는 역할을 하며, 파일 시스템, 네트워크, 프로세스 관리 등을 준비합니다.

5. 운영체제 초기화 및 사용자 환경 로드

 커널이 기본 설정을 마치면 나머지 운영체제 구성 요소(드라이버, 서비스 등)를 로드하고, 마지막으로 로그인 화면이나 데스크톱 같은 사용자 인터페이스를 띄웁니다.

OS 설치 절차

 OS 설치 절차 역시 초기 과정은 부팅과 거의 흡사합니다. 다만 부팅에 사용되는 매체가 USB와 같은 외부 장치라는 점에서 차이가 발생합니다. 최초에 OS를 설치하기 위해서는 BIOS/UEFI에서 부팅 순서를 USB와 같은 설치할 OS가 담겨 있는 매체로 변경합니다. 일반적으로 컴퓨터의 전원을 켰을 때 F2, Del, F12와 같은 키를 누르면 BIOS/UEFI로 진입하게 되는데 여기에서 부팅 순서를 변경할 수 있습니다.

 OS를 설치하는 과정은 일반적인 부팅 프로세스의 첫 두 단계(1. 전원 공급, 2. BIOS/UEFI 실행)까지는 동일합니다. 하지만 부팅 순서를 미리 USB와 같은 부팅 매체가 첫 번째가 되도록 변경하였기 때문에, 해당 매체의 부팅 섹터(MBR 또는 EFI 파티션)에 있는 부트로더를 읽어 메모리로 로드합니다. 그리고 커널을 로드하고 ISO 이미지를 통해 설치 작업을 수행하게 되죠. 사실상 일반적인 부팅 순서와 크게 다르지 않습니다. 부트로더를 읽는 매체가 바뀌었을 뿐이죠.

Concept of PXE Booting

 PXE란 Preboot Execution Environment의 줄임말입니다. 우리 말로는 '사전 부팅 실행 환경' 정도로 해석해 볼 수 있을 것 같습니다. 그래서 PXE 부팅은 로컬 디스크나 USB 대신 네트워크 서버에서 부팅 이미지를 가져와 운영체제를 부팅하는 방식을 의미합니다.

 이 기술은 이미 나온 지가 제법 된 기술입니다. 1990년대 후반 인텔 주로도 만들어졌으며, 네트워크 기반의 시스템 관리와 배포를 목적으로 설계되었습니다. 앞서 살펴본 것처럼 부팅에 필요한 모든 파일(부트로더, 커널, OS 이미지 등)을 네트워크 서버에서 가져와 메모리로 로드한 뒤 실행하도록 합니다. 쉽게 말해, PXE는 '네트워크로 컴퓨터를 부팅하는 방법'이라고 생각할 수 있습니다.

PXE 부팅의 상세 작동 원리

1. PXE 클라이언트 준비

(1) 하드웨어 요구사항

• PXE 기능이 지원되는 NIC(대부분의 현대의 NIC는 PXE를 지원함)
• BIOS/UEFI에서 PXE 부팅 옵션이 활성화

(2) 초기 동작

• 전원이 켜지면 BIOS/UEFI가 POST를 거친 후, PXE 부팅을 시도하도록 설정된 NIC의 PXE 코드를 실행
• 이 PXE 코드는 네트워크를 통해 외부 서버와 통신할 수 있는 최소한의 네트워크 스택을 제공

2. DHCP와의 상호작용

(1) DHCP의 역할

• PXE 클라이언트가 네트워크에 접속하려면 IP 주소가 필요하고, 이를 위해 DHCP 서버에 요청을 보냄
• 일단 DHCP 요청과 달리, PXE 요청은 자신이 PXE 클라이언트임을 알리는 플래그(Option 60: PXEClient)를 포함

(2) DHCP 응답

• IP 주소, 서브넷 마스크, 게이트웨이 제공
• 추가로 부팅서버(TFTP 서버) IP와 부팅 파일 이름(예: pxelinux.0)을 알려줌(Option 66, 67)

3. TFTP를 통한 부트로더 전송

(1) TFTP란?

• Trivial File Transfer Protocol은 가볍고 단순한 파일 전송 프로토콜로, PXE에서 부팅 파일을 빠르게 가져오는 데 사용됨
• TFTP는 속도가 빠르고 UDP 기반이라 초기 부팅에 적합하나, 대용량 파일 전송에는 한계가 있어 주로 부트 로더만 전달

(2) 동작

• PXE 클라이언트는 DHCP가 알려준 TFTP 서버에 접속해 부팅 파일을 다운로드
• 이 부팅 파일은 네트워크 부팅용 부트로더로, 메모리에 로드된 후 실행

4. 부트로더의 역할과 설정

(1) 부트로더 종류

• PXE 환경에서는 PXELINUX(SYSLINUX 계열)나 네트워크 지원 GRUB이 자주 사용됨

(2) 설정 파일

• 부트로더는 TFTP 서버에서 추가 설정 파일(예: pxelinux.cfg/default)을 가져옴
• 이 파일에 커널 위치, 초기 RAM eltmzm(initrd), 부팅 옵션이 정의되어 있음

#pxelinux.cfg/default 예시

DEFAULT ubuntu-autoinstall
LABEL ubuntu-autoinstall
  MENU LABEL Install Ubuntu 22.04
  KERNEL vmlinuz
  APPEND initrd=initrd ip=dhcp url=http://192.168.100.200/ubuntu/ubuntu-22.04.5-live-server-amd64.iso

5. 커널과 OS 로드

(1) 커널과 RAM 디스크

• 추가 설정파일에 정의된 커널과 RAM 디스크를 TFTP나 NFS등에서 다운로드하여 메모리에 적재

(2) OS 설치 진행

• 커널이 실행되면서 OS를 설치하는 작업을 수행
• OS 이미지는 HTTP 서버에서 제공
• 사전 정의된 설정이 있다면 자동 설치도 가능

 이번 포스팅에서는 컴퓨터의 부팅부터 시작하여 PXE 부팅의 개념과 그 절차에 대해서 알아보았습니다. 다음 포스팅에서는 실제 데모 환경을 구축하여 PXE 부팅을 진행해 보도록 하겠습니다.

 지난 포스팅에서 이어집니다. 처음 보시는 분들은 지난 포스팅을 참고해 주시기 바랍니다.

 우선 구축이 완료된 모습입니다. 생각보다 좀 과한 규모가 되었습니다. 총 6대의 물리 서버와 방화벽/라우터 역할을 겸하는 미니 PC, L2 스위치와 관리자 전용 무선 Access Point를 제공하는 공유기까지... 많은 시간과 금액이 들었습니다. 그리고 생각보다 많은 시행착오를 격였습니다. 그 내용을 한번 공유해 보고자 합니다.

확장을 위해 고려했던 사항들

 인프라 확장 진행하면서 많은 것들을 고려했습니다. 하드웨어 스펙부터, 네트워크 설계, 보안, 운영 방식, 소음, 발열, 전력... 정말 작은 데이터 센터를 구축하는 느낌이었습니다. 다시 한번 클라우드 서비스를 하기 위해서 고려해야 할 사항이 얼마나 많은지 느꼈습니다. 그중 중점적으로 고려했던 사항들에 대해서 설명을 드려봐야 할 것 같습니다.

1. 서버 스펙

 앞선 포스팅에서도 언급했지만, '약 10 - 20개 규모의 중소규모 Kubernetes 클러스터를 통시에 운영할 수 있는 규모의 인프라 구축'을 목표로 하였고 그에 준하는 하드웨어 스펙이 필요했습니다. 소규모와 중규모 Kubernetes 클러스터의 서버 사양은 아래와 같이 계획했습니다.

 소규모 클러스터는 개발 및 테스트 용도로, 중규모 클러스터는 실제 서비스를 배포하고 운영하는 용도입니다. 소규모 클러스터를 4개, 중규모 클러스터를 3개 운영한다고 가정하면 총 128 vCPU/322GB RAM/2680GB Storage 리소스가 필요합니다. 그렇다면 10 - 20개 규모를 운영하려면? 아... 정말 엄청난 하드웨어 스펙이 필요하더군요. 어쩔 수 없이 비용과 스펙 사이에서 타협을 했습니다. 그래서 최종적으로 다음 항목들을 기준으로 서버를 구성했습니다.

• 기존에 가지고 있던 서버 2대를 6대까지 증설
• 각 서버의 RAM를 64GB로 업그레이드
• USB 이더넷 랜카드를 통해 Storage 전용 네트워크를 구성

 이렇게 하면 CPU는 총 48 코어 96 스레드로 보통 가상화 환경에서 생각하는 vCPU:CPU 압축비인 3:1 내지는 4:1 정도에서 144 - 192 vCPU를 사용할 수 있어 충분하다 판단했습니다. 문제는 메모리와 네트워크였습니다. 우선 메모리의 경우 가상화 환경이라 할지라도 1:1 비율로 사용하는 것이 일반적이며 64GB * 6EA를 해도 384GB밖에 나오지 않습니다. 중규모 클러스터 하나에 메모리 요구량이 72GB나 되었기 때문에 기껏해야 클러스터 5개 정도밖에는 구동할 수 없는 수준이었습니다. 서버를 증설하면 문제는 해결되겠지만, 역시 가장 큰 걸림돌은 예산이겠죠. 거기다가 공간도 문제이고, 네트워크와 스토리지의 한계도 무시할 수 없었습니다.

 서버당 네트워크 인터페이스를 2개 사용할 계획이었기 때문에 물리적으로 2개의 포트가 필요했고, 이미 6대의 서버를 사용하게 되면 12개의 포트, 거기다가 NAS가 사용할 포트와 업링크 등을 생각하면 홈 랩 수준에서는 너무 고사양의 스위치가 필요했습니다. 게다가 서버가 늘어나고 거기에 호스팅 되는 VM이 늘어날수록 스토리지에서 오는 병목도 무시할 수 없는 수준이 될 것이었습니다. 서버는 최대 1 Gbps로 구성된 스토리지 전용 네트워크를 사용하고, NAS는 관리용이 아닌 스토리지용으로 3개의 네트워크 인터페이스를 LACP로 구성한다 해도 그 한계는 명확했습니다.

 거기다 발열이나 전기료 같은 것도 생각해야 했기에 마냥 서버를 증설하는 것은 한계가 있고, 이 정도 수준도 홈 랩에서는 충분히 과한 수준이기에(사실 이전 회사에서는 이보다도 못한 서버에서도 서비스를 구현하기도 했고...) 더 이상 서버를 추가하기보다는 6대로 최대의 효율을 뽑아내는 쪽으로 방향을 정했습니다.

2. 네트워크 고도화

 네트워크 역시 이제는 조금 더 고도화가 필요했습니다. 앞선 포스팅에서의 기본적인 홈 랩 환경에서는 네트워크 최상단에 ipTIME 공유기를 사용하였습니다. 물론 작은 규모에서는 크게 문제가 없었고, 네트워크 분리를 위해서 VM을 통해 오픈소스 방화벽인 OPNsense를 활용하기도 했지만 규모가 확장되면서 네트워크 환경 역시도 변화가 필요했습니다.

 우선 방화벽 및 라우터 역할을 수행할 수 있는 최상단 장비가 필요했습니다. 이전 홈 랩 구축에 사용해 보았던 OPNsense를 VM이 아닌 물리 장비로 구축하여 방화벽과 라우터 역할을 수행하도록 하였습니다. 이미 가상머신으로 구성 및 간단한 운영을 해본 상태라 크게 어렵지 않았습니다. 물리 장비 선택과 OPNsense에 관한 자세한 내용은 아래 포스팅을 참고해 주시면 감사하겠습니다.

 OPNsense는 정말 강력한 기능을 가지고 있습니다. 이를 통해 일반적인 인터넷 서핑 및 업무를 위한 Wi-Fi용 무선 네트워크와 서버 및 인프라 관리를 위한 네트워크, 가상머신을 위한 네트워크와 스토리지 전용 네트워크, 또 서비스를 위한 네트워크 등 다양한 네트워크를 손쉽게 구성할 수 있었습니다.

 또한 늘어난 서버에 물리적인 네트워크 인터페이스 제공을 위해서 L2 스위치 역시 필요하게 되었습니다. 중점적으로 본 기능은 LACP와 VLAN, 그리고 편리한 사용자 인터페이스를 제공하느냐는 것이었습니다. 물론 네트워크 인터페이스는 최소 1 Gbps 이어야 했고, 16개 이상이 필요했습니다. 가격 역시 저렴하면 더 좋구요. 메이저급 밴더사의 제품은 너무 비쌌거든요. 그래서 찾아낸 제품이 바로 TP-Link사의 TL-SG2218입니다.

 기본적인 기능에 충실하면서도 저렴한 가격, 그리고 사용하기 쉬운 Web 형식의 사용자 인터페이스와 CLI 모두 지원하는 것이 매우 매력적으로 보였습니다.

 물리 장비로 구축한 방화벽 겸 라우터 역할을 하는 OPNsense와 꼭 필요한 기능을 제공하는 Managed L2 스위치를 통해서 물리적, 논리적 네트워크를 원하는 형태로 구현하였습니다. 네트워크 간 접근에는 필요한 구간에 필요한 단말만이 접근할 수 있도록 방화벽 규칙을 설정하여 최소한의 접근 제어와 보안을 구현해 냈습니다.

3. 스토리지 업그레이드

 Synology의 NAS에는 여러 가지 기능이 있는데 이 중 블록 스토리지를 제공하는 기능인 iSCSI가 제가 구축하려는 홈 랩에서는 매우 중요한 역할을 하였습니다. 서버가 늘어나서 이전보다 더 많은 수의 VM을 동시에 운영할 예정이기 때문에 기존 HDD기반의 NAS의 스토리지로는 한계가 있다고 판단하였습니다. 그래서 2.5인치 SATA SSD를 하나 더 구입하여 총 3개의 SSD를 RAID 5로 구성하고 이를 iSCSI를 통해 블록 스토리지로 제공하기로 하였습니다. 네트워크 대역폭을 위해 3개의 네트워크 인터페이스를 LACP로 구성하여 iSCSI를 서비스하는 용도로 사용하고, 나머지 하나는 관리를 위한 네트워크 인터페이스로 사용하기로 결정합니다.

 NAS 모델이 워낙 구형인 데다, 네트워크의 한계로 그다지 뛰어난 성능은 아니지만, 그래도 간단한 워크로드 정도는 구동할 수 있는 수준의 환경을 구성하였습니다.

실 구축에 어려웠던 점들

Everyone has a plan, 'till the get punched in the mouth.
누구나 그럴싸한 계획을 가지고 있다. 쳐 맞기 전까지는...
- 마이클 타이슨 -

 네 맞습니다. 저도 그랬습니다. 개념적인 설계는 완벽하다고 생각했습니다. 하지만... 실 구축에 많은 장애를 겪게 됩니다. 그중 가장 대표적인 게 바로 아래 USB 확장 이더넷 어뎁터의 MTU 설정 문제입니다.

 이 외에도 가상 네트워크와 물리 네트워크 간 VLAN 연동, NAS에 추가 네트워크 인터페이스 설치(재부팅 시 네트워크 설정이 날아가는 현상 때문에 포기), 내부 DNS/DHCP 세팅에 나타났던 여러 문제점들... 여러 가지 문제가 수없이 발생했습니다. 그럼에도 불구하고 현재는 제법 안정 적힌 환경을 구축하였고 많은 테스트와 서비스를 할 수 있는 인프라를 구축하였습니다.

그래도 얻은 게 많은 홈 랩 구축

 그럼에도 불구하고 홈 랩을 구축하면서 정말 많은 부분을 이해할 수 있었습니다. 장비 구입부터 시작하여, 네트워크 설계 및 구축, 트러블 슈팅을 통한 각 종 기술적인 이해도 향상, 그 외에 운영 방침 설정 및 실 운영에서 겪게 되는 여러 가지 시행착오들... 이런 경험들은 정말 값진 경험이라 할 수 있겠습니다.

 앞으로 이 홈 랩 인프라를 통해서 여러 가지를 테스트해보고 실제 서비스도 만들어볼 생각입니다. 물론 엔터프라이즈 급의 운영과는 확연한 차이가 있을 것이기에 이것이 곧바로 실전적인 경험은 아닐 수 있으나, 그럼에도 불구하고 많은 통찰을 얻을 수 있는 재미난 시도가 아닌가 생각합니다.

 아무래도 이번 홈 랩 구축기는 용두사미의 포스팅이 되는 거 같습니다. 이렇게 큰 주제보다는 작은 주제들에 대해서 좀 더 심도 있게 다뤄보는 쪽으로 방향을 설정할까 합니다. 부족한 포스팅 읽어 주셔서 감사합니다.

 홈 랩을 구축하면서 경험했던 많은 내용들과 좌절을 안겨준 많은 여러 상황들, 그리고 이를 해결하기 위해 했던 여러 시행착오들을 통해 얻은 노하우를 기록하고 또 공유하기 위해 이 포스팅을 시작합니다. 아마 상당히 긴 시리즈의 포스팅이 될 것 같습니다. 먼저, 홈 랩이 왜 필요하게 되었는지와, 이를 설계하면서 고려했던 내용들에 대해서부터 이야기를 시작해 보도록 하겠습니다.

그래서 홈 랩이 왜 필요했는데?

 가장 큰 이유는, 경험이 필요했기 때문입니다. 저는 부끄럽게도 IT 전공자도 아니고, 또 국비지원 교육을 받은 양산형 인력이었습니다. 코로나 시기와 맞물려 개발자들이 양산되어 나오던 시기에 지방에서 개발자도 아닌 시스템 엔지니어 양성 과정을 수료하고 지방의 작은 회사에서 커리어를 시작했기 때문에 절대적인 경험이 부족했습니다.

 운이 좋아서 서울로 이직하긴 했지만 역시나 현장 경험이 그다지 없다 보니 항상 경험에 목말라 있었습니다. 이대로 가다가는 이도저도 아닌 연차만 쌓이는 엔지니어가 될 것 같아 사비를 들여서라도 무언가 해보고 싶었습니다. 그래서 기존이 있던 놀고 있던 NAS도 활용할 겸 홈 랩을 구축하게 되었습니다.

 물론 클라우드를 선택할 수도 있었지만, On-premise 환경을 택했습니다. 원래 VMware를 기반으로 한 업무를 해왔고 그래서 온프레미스 환경이 조금 더 익숙하기도 했으며, 클라우드의 완성된 서비스를 사용하기보다는 직접 구축하면서 더 많은 것들을 배울 수 있을 것이라 생각했습니다. 그렇다고 클라우드의 여러 다양한 서비스를 사용하는 게 마냥 쉽고 배울게 없다는 뜻은 아닙니다. 다만 Low-Level의 인프라부터 다루어 보면서 부족한 기초를 다지고 싶었습니다.

홈 랩을 통해 이루고자 하는 목표

 목표는 크게 두 개로 첫째는 '약 10 - 20개 정도의 중소규모 Kubernetes 클러스터를 동시에 운영할 수 있는 규모의 인프라 구축'이고 둘째는 'Self-Service 형식의 기본 기능을 갖춘 Kubernetes 서비스 제공'입니다. 결론부터 말씀드리자면 현재 첫 번째 목표는 대부분 이룬 상태입니다. 그래서 앞으로의 포스팅은 첫 번째 목표를 이룬 과정에 대해서 상세하게 기술하려고 합니다.

기존 보유 중이던 인프라

 개발자 친구들과 토이 프로젝트를 진행하면서 구축한 아주 작은 수준의 인프라를 가지고 있었습니다. 이를 통해 Kubernetes 클러스터를 제공하고 개발했던 애플리케이션을 배포, 서비스를 외부로 노출한 경험을 기반으로 하여 확장된 규모의 인프라를 구축하려고 했습니다. 우선 기존 인프라부터 이야기를 해 보겠습니다.

1. Server

 물리적인 서버 역할을 담당할 장치입니다. 중국의 Beelink사의 SER 5 MAX라는 Mini PC입니다. 인텔의 NUC와 매우 흡사한 폼팩터를 가지고 있습니다. 적당한 성능과 가격이 가장 큰 메리트였습니다. 물론 중국 제품이라는 데에 다소 불신도 있고 또 보안상 위협도 있을 수 있다는 점은 충분히 인지하고 있습니다. 하지만 예산이 가장 큰 걸림돌이었기 때문에 어쩔 수 없이 가성비 제품을 선택하게 되었습니다. 국내외 리뷰를 찾아보니 제법 인지도도 있는 것 같고 사용자들도 있는 것 같아 총 2대 구매를 결심했습니다.

 구매 시 가장 확인이 어려웠던 부분은 네트워크 인터페이스입니다. 하이퍼바이저로 VMware ESXi를 사용할 예정이었는데 VMware에서는 공식적으로 리얼텍 제품에 대한 드라이버를 제공하지 않고 있습니다. 아무래도 엔터프라이즈급 제품이 아니라는 이유가 크다는데 홈 랩을 구성하는 입장에서는 매우 아쉬운 부분입니다.

 사실 구매 전에 이를 확인했어야 하는데 확인하지 않은 제 실수도 있었구요. 열심히 구글링을 하여 여러 자료를 찾아보았는데 다행히 커스텀 드라이버를 통해 리얼텍의 네트워크 인터페이스를 사용하는 방법[자료 링크]을 찾을 수 있었습니다. 여러 시도를 해 보았으나 제대로 작동하는 것은 ESXi 6.7 버전이었습니다. 혹시라도 따라 해 보실 분들은 참고하시면 될 것 같습니다.

2. Network

 네트워크는 기존에 사용하던 ipTIME AX2004 BCM 공유기를 사용하기로 했습니다. 이 제품은 지금은 단종되었습니다. 공유기 치고는 고가에 구입했던 걸로 기억합니다. 현재는 ipTIME AX300 BCM이 그 후속으로 조금 더 저렴한 가격에 나와있습니다. 개인적으로 처음 홈 랩을 구축하는 분들이라면 ipTIME을 추천드립니다. 국내에는 이를 통해 홈 랩이나 홈 네트워크 구축한 사례가 많아 자료도 많고, 가격대가 좀 있는 제품은 그 기능도 준수해서 사용하게에 충분하다고 생각합니다.

 꼭 위 제품을 선택할 필요는 없지만, 그래도 제품을 고르실 때 VPN과 DDNS 기능이 있는지 살펴보는 것을 추천드립니다. 집 밖에서 원격으로 홈 랩 인프라를 제어해야 하는 상황에서 매우 유용하기 때문입니다. 저는 여기에 추가로 브로드컴 칩셋 사용 여부도 고려 사항으로 추가하는 것을 추천드립니다. 물론 다른 제조사의 칩셋을 사용하는 제품도 문제는 없지만, 그래도 브로드컴 칩셋의 성능과 신뢰도가 조금 더 뛰어나기 때문입니다.

 위 구조가 바로 초창기 구축했던 홈 랩 네트워크의 구조입니다. 특징적인 것은 ISP로부터 제공되는 공인 IP 주소를 통신사 모뎀의 Bridge Mode를 통해 공유기에 바로 제공할 수 있게 하였습니다. 이유는 앞서 말씀드린 VPN과 DDNS 때문인데, 이는 추후에 더 다루어 보도록 하겠습니다. 어쨌든, 이렇게 구축을 하게 되면 공유기의 WAN 포트 1개와 LAN 포트 4개를 모두 사용하게 됩니다.(여기서 인프라를 더 확장하기 위해서는 필수적으로 스위치가 필요해집니다.)

3. Storage

 VMware ESXi를 하이퍼바이저로 사용하면서 iSCSI 방식의 블록스토리지가 필요했습니다. 기존에 가지고 있었던 오래된 NAS가 있어서 이를 활용하기로 했습니다. 예전에 한창 사진에 취미가 있을 때 장만했던 장비인데, 당시에는 여러 스터디 자료나 Linux 배포판 이미지를 모아두거나 하는 용도로 사용하고 있었습니다.

 Disk Bay 5개와 1Gbps 네트워크 인터페이스 4개를 가지고 있는, 구매 당시에는 제법 괜찮은 스펙의 NAS였습니다. 4TB HDD도 3개를 장착하여 RAID 5 구성을 한 상태로 공유 스토리지로 사용하기에는 충분한 성능과 용량을 가지고 있습니다. NAS가 필수는 아니지만 ESXi의 기능을 제대로 사용하려면 공유 스토리지가 필요합니다. 물론 네트워크로 연결된 iSCSI, HDD라는 스펙적인 한계가 있지만 홈 랩 정도의 수준에서는 충분한 성능을 제공합니다.

 또한 Synology NAS는 다양한 기능을 제공합니다. 자체적으로 VM을 호스팅 할 수도 있으며, DDNS(Synoloby NAS가 있으면 공유기의 DDNS 기능은 없어도 됩니다.), DNS, 리버스 프록시, Let's Encrypt와 연동한 인증서 발급 및 자동 갱신, 인증서 종단점 역할 등 다양한 서비스를 제공합니다. 제대로 된 홈 랩을 구성하려면 구매를 고려해 볼 만한 장비가 아닌가 생각합니다.

 사실 위 정도의 장비만 갖추어도 홈 랩을 통해 많은것들을 테스트해볼 수 있습니다. 그러나 저는 여기서 조금 더 높은 수준의 서비스를 제공하는 인프라를 구성하고, 또 이를 사용자 셀프서비스 방식으로 고도화하기 위해 인프라를 확장하기로 마음먹습니다. 확장된 인프라에 대한 계획과 규모, 그리고 설계에 대해서는 다음 포스팅에서 다뤄 보도록 하겠습니다.