Nalee와 함께 떠나는 IT이야기

얼마전에 클라우드 가상화 비율이라는 글을 포스팅한적이 있었다. 그때 나는 클라우드 시스템은 70%를 유지하는 것이 좋다고 포스팅을 했었다. 그런데, 많은 사람들이 왜 70%을 권장하는지를 물어봤었고, 궁금해 하는 분들이 꽤 있었다. 일반적으로 시스템을 운영할때는 70% ~ 80% 이상을 사용하지 말라고 학교에서 그리고, 많은 운영부서에서 선배들로부터 그렇게 배워왔던것 같다. 그래서, 그냥 그렇게 사용해야 되는거구나! 라고 생각을 했지 왜 70% 이상을 사용하면 안되는건지에 대해서는 사실 생각해 본적은 없는것 같다. 그런데, 사람들하고 이야기를 하다보니 그럴걸 궁금해 하는 사람들이 많이 있다는 사실을 알았다. 그래서, 이번 포스팅에서는 클라우드 시스템의 운영 비율에 대해 알아보고자 한다. 클라우드의 핵심 ..

요 근래에 고객사에서 프로젝트를 하면서 클라우드 가상화 비율에 대해 고민을 한 적이 있다. 요즘에는 클라우드 하면 가상머신과 컨테이너 기반의 오픈스택이나 쿠버네티스와 같은 환경을 클라우드 서비스라고 한다. 가상머신 서비스(*가상머신 서비스를 컴퓨트 서비스라 부르기도 함)를 제공하는 오픈스택과 컨테이너 서비스를 하는 쿠버네티스는 비슷하면서 성격이 매우 다르다고 볼 수 있다. 가상머신(컴퓨트) 서비스 - 오픈스택 가상머신을 제공하는 컴퓨트 서비스인 오픈스택은 일반적으로 모든 클라우드 자원을 사용하지 않는다는 특성이 있다. 예를 들어 특정 컴퓨트 노드에 10개의 가상 머신을 생성했다면 여기서 실제로 호스트 노드의 자원을 사용하는 가상머신은 10개 중 5개라고 가정을 하는것이다. 따라서, 효율적으로 가상자원을 ..

오픈스택에서 가장 중요한 것은 아마도 네트워크일 것이다. 사실 레드햇 오픈스택의 기본 네트워크는 ML2기반의 OVS였다. 그런데, 지난 2월에 릴리즈된 레드햇 오픈스택 16.1 (커뮤니티 버전: Train)부터는 운영체제가 RHEL 7에서 RHEL 8로 변경되었고, Neutron 네트워크는 ML2기반의 OpenvSwitch 에서 Open Virtual Network라는 SDN 으로 변경되었다. 기본 오버레이 패킷 변경 기존 ML2/OVS 환경에서 오버레이 패킷은 VXLAN이였고, 패킷 헤더는 아래와 같이 생겼었다. OVN 환경에서 오버레이드 패킷은 Geneve로 변경이 되었고, 패킷 헤더는 아래와 같이 VXLAN보다 훨씬 길어졌다. Geneve 패킷은 VXLAN보다 길이가 길다. 정확하게 세어보지 않아서..

요 근래에 고객사에서 KVM 하이퍼바이저에서 생성된 VM이 사용하고 있는 자원 사용률을 확인할 일이 있었습니다. 그때 저는 virsh 명령어를 이용해 유용하게 VM의 자원 사용률을 확인을 했었습니다. 그런데, KVM에 위에 생성된 VM에 할당해 준 VCPU는 호스트의 몇 번 CPU를 사용할까? 하고 궁금증이 일어났습니다. 분명히 봤는데, 기억이 안나서 오늘 virsh 명령어를 살펴보다가 내가 생성한 VM의 VCPU가 호스트의 몇번 CPU를 사용하는지 알 수 있는 virsh 명령어를 찾아냈습니다. 그래서, 잃어버리전에 블로그에 적어놓아야겠다는 생각을 했습니다. 그럼, 시작해 볼까요? 제가 사용하는 노트북에는 오픈스택을 설치하기 위한 VM들이 KVM 하이퍼바이저 위에 생성되어 있어요. 제 노트북의 CPU는 ..

안녕하세요~!! 지난 포스팅에서 KVM 이 설치된 호스트의 시스템 정보와 사용량을 알아보았다면, 이번에는 KVM 위에 생성된 VM의 자원 정보 및 사용량에 대해 어떻게 모니터링하면 되는지 알아보도록 하겠습니다. 이건 오픈스택의 컴퓨트 노드에 생성된 인스턴스를 이미 고객이 사용하고 있다고 가정했을 경우 운영자는 고객의 VM에 접속하여 시스템 정보를 확인하거나 모니터링을 할 수는 없을 것입니다. 그렇지만, VM의 자원정보와 사용량을 모니터링하여 자원 증설 계획을 세울 경우 유용하게 활용할 수 있습니다. 물론 모니터링 시스템을 준비하는 동안에 잠시 사용하는것이 좋겠지요~!! 인스턴스(VM) 자원 정보 확인하기 이번에는 주변에 있는 리눅스 서버에 먼저 접속을 해 봅시다. 그리고, 해당 서버에 KVM이 설치되어 ..

안녕하세요~!! 오늘은 모니터링 시스템이 없을경우 오픈스택의 컴퓨트 노드에 구성된 하이퍼바이저인 KVM을 virsh 명령어를 통해 모니터링할 수 있는 방법들에 대해서 알아보고자 합니다. 최근에 제가 고객사에 오픈스택 환경을 점검하러 갈 사례가 꽤 있었는데요~!! 그럴때마다 물어보는게 모니터링은 어떻게 하나요? 라는 질문이였어요. 물론 모니터링 시스템을 직접 구축하거나, 그럴 역량과 시간이 되지 않는다면 누군가가 개발해 놓은 모니터링 시스템을 사용하면 됩니다. 물론, 시스템을 구축하기까지는 시간이 필요하므로, 그동안은 KVM을 관리할 수 있는 명령어인 virsh 명령어를 이용해 컴퓨트 노드의 VM 개수 및 해당 VM의 상태를 확인할 수 있습니다. 뿐만 아니라, 호스트 노드(여기서는 컴퓨트 노드가 되겠죠~!..

안녕하세요~!! 오랜만에 블로그에 글을 써 보는것 같습니다. 오늘은 다름이 아니라, 지난해에 우연히 쉘 스크립트를 작성하고나서 기억을 오랫동안 간직하기 위해 블로그에 글을 올린적이 있습니다. 그때 그 글을 보고 책을 내면 좋겠다는 분이 계셨어요. 그리고, 현재 몸담고 있는 회사 팀장님이 책을 하나 써보라는 권유를 자주 하셨었어요. 그래서, 이번 기회에 그동안 현장에서 느끼고 적용했던 수많은 경험들을 정리한다는 생각으로 쉘 스크립트 책을 쓰게 되었어요. 저는 사실 쉘 스크립트를 자주 사용하거든요. 그래서, 기존에 나와 있던 쉘 스크립트 서적들을 조사해 보니, 해당 서적들은 쉘 스크립트 문법 위주이거나, 아니면 쉘 스크립트 예제 중심의 서적들이 주로 많이 있었어요. 저는 항상 옆에다 두고 필요할때 찾아볼수 ..

지금까지 GlusterFS를 설치하고 Heketi를 설치하여 heketi-cli를 이용해 gluster에 볼륨이 생성되는지를 테스트해 보았다. 이는 전부 쿠버네티스를 이용하여 생성되는 컨테이너의 퍼시스턴트 볼륨으로 사용하기 위해서였다. 이번 포스팅에서는 앞에서 설치한 쿠버네티와 glusterfs 그리고 heketi를 연동하여 어떻게 컨테이너의 퍼시스턴스 볼륨으로 사용하는지에 대해 알아보겠다. 5. 쿠버네티스와 GlusterFS 연동 5.1 네트워크 연동 테스트 먼저 쿠버네티스 마스터 노드(여기서는 control 노드가 마스터 노드임)에 들어가서 heketi 서버로 통신이 되는지 ping 테스트를 먼저 해본다. [root@control ~]# ping 192.168.0.199 PING 192.168.0.1..

이전 포스팅에서 Glusterfs를 설치하기 위해 vm를 생성하고, vm의 환경설정을 해주었다. 그리고, glusterfs 패키지를 설치하고, 첫번째 glusterfs 서버인 gfs-server1에서 gfs-server2와 gfs-server3을 peer로 등록해 주었다. 이번에는 glusterfs의 API 서버가 될 heketi 서버를 설치하고 glusterfs와 연동 작업해 보도록 하겠다. 4. Heketi API 서버 설치 앞에서 우리는 heketi 서버용 vm를 생성하고 환경설정을 완료하였다. 앞서 설정한 heketi 서버에 접속하여 heketi를 설치해 보자. 4.1 Heketi 패키지 설치 이미 앞에서 서브스크립션을 등록하고 필요한 패키지 레파지토리를 활성화하였다. 이때 활성화한 rh-glus..

이번에는 쿠버네티스에서 필요한 퍼시스턴트 볼륨을 생성하기 위한 GlusterFS를 설치해 보고, GlusterFS의 RestAPI 서버 역할을 해 주는 Heketi 서버를 설치해 보고자 한다. 우선, 설치 순서는 아래와 같다. 1. VM 생성 GlusterFS용 VM 생성 Heketi API 서버용 VM 생성 2. VM 환경설정 네트워크 설정 SSH keygen 설치 및 설정 서브스크립션 등록 및 시스템 업데이트 3. GlusterFS 설치 GlusterFS 패키지 설치 GlusterFS 방화벽 설정 GlusterFS Peer 등록 4. Heketi API 서버 설치 Heketi 패키지 설치 Heketi SSH 인증키 생성 및 복사 Heketi와 GlusterFS 연동을 위한 환경설정 파일 생성 Heke..