김마늘의 테크 레시피

ESXi 커스텀 USB NIC 드라이버 사용과 한계에 대하여

국내에도 생각보다 많은 분들이 홈 랩을 구축하고, 운용하고 있는 것으로 알고 있습니다. 베어메탈 환경에 직접 리눅스로 서버 환경을 구축할 수도 있지만, Hypervisor를 사용한다면 가상화를 통한 조금 더 유연한 인프라 환경을 구현할 수 있습니다. 저도 여러 Hypervisor들 중에 가장 익숙한 ESXi를 활용하여 인프라 가상화 환경을 구축하고 있습니다. 홈 랩의 숙명 - 하드웨어 호환성 VMware ESXi는 네트워크 인터페이스에 대한 호환성에 많이 인색한 편입니다. 오로지 Intel의 컨트롤러만을 사용하는 네트워크 인터페이스를 지원하기 때문에 ESXi를 하이퍼바이저로 선정한 사람들에게 숙명적으로 따라오는 것이 이 네트워크 인터페이스에 대한 고민입니다. 저 역시도 여기에서 자유롭지 못했습니다. 사용..

환경VMware vSphere 6.7U3 환경에 배포된 VMUbuntu 22.04포트 그룹에서 VLAN 사용증상apt update, apt install 등 apt 관련 명령어 사용 시 작동 안되는 현상[Waiting for headers] 문구와 함께 행 걸림물리적으로 서버의 외장 USB NIC을 업링크로 사용하는 분산 스위치의 포트 그룹에서는 행 걸림 현상 발생웹 브라우저를 통한 인터넷은 문제 없이 잘 작동속도 테스트, 설치 파일 다운로드와 같은 동작은 문제 없이 작동DNS 문제 없음nslookup, dig 모두 잘 작동대조군 설정 및 테스트 문제의 VM대조군 VM스펙4vCore/8GB RAM/60GB Storage4vCore/8GB RAM/60GB Storage네트워크외장 USB NIC을 업링크로 ..

구축 배경 홈 랩을 확장하면서 가정용 Wi-Fi 네트워크와 홉 랩 인프라용 네트워크 간의 분리 및 격리, 라우팅 및 접근 제어 그리고 그 외 서비스에 필요한 기능 구현이 필요했습니다. 그래서 네트워크 최상단에 방화벽과 라우터 역할을 할 수 있는 OPNsense를 직접 구축해 보기로 했습니다. 이번 포스팅에서는 시리즈로 하드웨어 선정부터 설치, 구성과 방화벽 규칙 설정, 그리고 각종 서비스 설정까지 전반적인 내용에 대해서 다뤄보고자 합니다. OPNsense란? OPNsense는 pfSense와 m0n0wall을 기반으로 개발이 시작되어 2015년 1월에 첫 공식 릴리즈가 이루어진 FreeBSD 기반의 오픈소스 방화벽 및 라우팅 플랫폼입니다. 발표된 지 딱 10년이 된 프로젝트로 Deciso B.V.에 의해..

홈 랩을 구축하면서 경험했던 많은 내용들과 좌절을 안겨준 많은 여러 상황들, 그리고 이를 해결하기 위해 했던 여러 시행착오들을 통해 얻은 노하우를 기록하고 또 공유하기 위해 이 포스팅을 시작합니다. 아마 상당히 긴 시리즈의 포스팅이 될 것 같습니다. 먼저, 홈 랩이 왜 필요하게 되었는지와, 이를 설계하면서 고려했던 내용들에 대해서부터 이야기를 시작해 보도록 하겠습니다. 그래서 홈 랩이 왜 필요했는데? 가장 큰 이유는, 경험이 필요했기 때문입니다. 저는 부끄럽게도 IT 전공자도 아니고, 또 국비지원 교육을 받은 양산형 인력이었습니다. 코로나 시기와 맞물려 개발자들이 양산되어 나오던 시기에 지방에서 개발자도 아닌 시스템 엔지니어 양성 과정을 수료하고 지방의 작은 회사에서 커리어를 시작했기 때문에 절대적인 경..

0. 들어가며 지난 포스팅에 이어 바로 2편을 작성하지 않고, 먼저 Kubernetes Cluster 구축 방법에 대한 내용으로 포스팅을 진행했습니다. 이유는, 단일 Control Plane(이전에는 Master 노드라고 이야기 해였습니다. 'Master'가 주종관계를 나타내는 단어라 앞으로는 Control Plane으로 사용하기로 하겠습니다. 여기서 또 PC가...)으로 Kunbernetes 환경을 구성하는 방법을 알아야 그 다음에 2대 이상으로 이루어진 멀티 Control Plane 구성이 가능하기 때문입니다. 그리고... 사실 제가 바쁘기도 했고 또, Home Lab 환경에 큰 변화가 있었던 것도 그 이유 중에 하나입니다. (그래서, IP 주소도 변화가 있었습니다.) 최대한 내용이 이어질 수 있도록..

0. 들어가며 Kubernetes 클러스터는 크게 Master 노드(Control Plane 역할)와 Worker 노드(워크로드 구동 역할)로 나뉩니다. 프로덕션 환경에서는 고가용성(HA) 및 로드 밸런싱을 위해 Master 노드를 여러대로 하여 클러스터 형식으로 구현하기도 합니다. 그런데 여기서 문제가 생깁니다. 1) 어떻게 단일 API End-Point를 제공할 것인가? 생각해 보면 Control Plane을 구성하는 노드가 1대만 존재한다면 크게 문제될 것이 없는 부분이지만, 여러 대가 존재 한다면 그때는 어떤 Master 노드가 제공하는 API 서버의 주소를 사용해야 할지 정하는 것이 좀 애매해집니다. 1대의 Master 노드가 대표로 API 서버 주소를 노출한다면 해당 노드에만 많은 부하가 걸려..