Blogs

“내가 철들어 간다는 것이 제한몸의 평안을 위해 세상을 적당히 길드는 거라면 내결코 철들지 않겠다” 쉽지는 않지만…

이 글은 VMware vSphere ESXi Host의 원격 모니터링을 위하여 SNMP 서비스를 사용하는 과정에 대한 매우 간략한 기록이다. 이 글은 실전에서의 모니터링 상세를 다루지는 않으며, 다만, 모니터링 도구와 관계없이 그 시작을 위하여 공통으로 수행되어야 하는 ESXi Host에서 SNMP 서비스를 설정하고 활성화하는 등의 과정만을 다루고 있다. (SNMP 동작 확인을 위한 정도의 Client의 간략한 설정을 함께 포함하고 있다.)

지난 10월에 진행하던 BMT 중에 네트워크 성능 측정, 또는 사용량 확인을 위해 진행했던 MRTG 설치과정을 기록한다.

이 글은 NVM, Node Version Manager를 사용하여 Ubuntu 15.04 환경에서 Node.js와 npm 환경을 간단하게 구성하는 과정을 정리한 글이며, 궁극적으로 npm을 이용하여 Ember-CLI 환경을 구성하고 Ember.js 프로젝트를 진행할 수 있는 환경을 완성하는 과정의 기록이다.

VMware의 NSX 6.2에서 제공하는 SSL VPN-Plus 기능을 우분투 리눅스에서 사용하기 위한 간략한 설명이다. Java가 되네 안되네 해도 당황하지 말고, 아래와 같이 해주면 된다.

리눅스 서버를 이용하여 간단하게 VPN 환경을 구성할 수 있는 방법 중 하나가 GRE Tunneling 방식의 PPTP를 이용한 VPN 구성이다. 이 글은 PPTP를 이용하여 원격지의 망과 내 PC를 연결하는 방법에 대한 간단한 소개이다.

몇일 전에 PXE Mater 구성하기라는 글을 올렸다. 이것으로 PXE에 대한 이슈는 정리된 것으로 생각하고 있었는데, 또다른 복병이 나타났다. 바로 대상 Hardware의 PXE 설정!

PXE는 Preboot Execution Environment를 줄인 용어로, 서버 등의 IT 장비가 “본격적으로 부팅하기 전에 미리 실행되는 환경"이라고 풀이할 수 있다. 이 글은, 이런 PXE 부팅을 위한 Master 환경을 구성하는 과정의 이야기이다.

“Linux Bridge로 네트워크 문제 추적하기“에서 얘기했던 것과 같이, 리눅스의 내장 Bridge 기능은 네트워크 통신과 연관된 문제를 뭐랄까… 대상의 OS 또는 구성과 관계없이 객관적 위치에서 추적할 때 유용하게 사용할 수 있다. 이번엔 VMware vSphere 가상환경 속에 위치한 VM을 대상으로 한 네트워크 분석 방법이다.

리눅스는 스스로가 Network Bridge¹로 동작할 수 있는 커널 기능과 유틸리티를 기본적으로 제공하고 있는데, 이 기능이 시스템 간 통신을 끼고 발생하는 문제점을 추적하는 과정에서 유용할 때가 있다. 이 글은 리눅스 Bridge를 이용하여 시스템 바깥에서 네트워크 흐름을 분석했던 경험을 기록한 것이다.

나의 “생각저장소"를 이곳 Github Pages로 옮긴 이후, 몇 개의 더 글을 쓰면서 본격적으로 Jekyll, Markdown, 그리고 Liquid 이용한 정적 블로깅을 조금 더 경험해 봤다.
그 후 쓰게 된 이 글은, Jekyll의 성능에 대한 이야기이다.

몇 주 전 “블로그, Tistory로부터 Github Pages로 이주“라는 글을 통해서, “어떤 방식으로 Tistory로부터 Github Pages로 이사를 했는지“를 중심으로 기록을 남긴 바 있다. 이번에는 내 글들의 새 터를 “좀더 블로그답게 정비한” 이야기이다.

따지자면 5년 전에 적었던 “Jekyll로 github에 블로깅하기“의 2탄인 샘이고, 얼마 전, 좀 대충 적은 듯 한 “Setup Jekyll for Github Pages“와 함께 읽으면 Github Pages를 이용한 블로깅을 새로 시작하는 사람들에게는 그럭 저럭 읽어볼만한 “시작하기+@ Guide"가 될 수 있을 것이다.

“디스크 구멍내기” 사건 이후로 OS를 다시 설치하고 설정하는 중에, 회사 VDI 접속을 위한 Citrix Receiver도 다시 설치했다. 지난번에 비해 많은 변화가 있었는데, Google Chrome App 버전도 있고 리눅스 버전에도 꽤 변화가 있었나보다. 그 내용을 정리한다.

뭐, 낯 뜨거운 일이지만 IT를 생업으로 하고 있고, 십년이 넘도록 친구나 가족보다 컴퓨터와 보내는 시간이 훨씬 많았던 난데, 말이 안되는 실수를 했다. 업무용으로 사용하는 내 랩탑에서 SSD Disk에 대한 I/O 시험을, Write 모드로 해버린 것! 이 글은 그 쌩고생에 대한 기록이면서, 동시에 이런 일을 당한 사람들에게 드리는 “해! 하지마!” 가이드이다.

얼마 전에 Ember.js와 Semantic-UI를 사용한 프로젝트를 진행하고 나서, 발표 초기에 얼마간 맛보기로만 사용해본 후 방치해오던 Github Pages를 다시 사용하는 것이 어떨까… 하는 생각을 하게 됐다. 그래서, 일단 2007년부터 2012년까지 사용하다가 역시 방치하고 있었던 Tistory의 글들을 여기로 옮겨왔다.
이 글은, 옮기기로 결정한 이유와 옮긴 과정, 그리고 그로 인한 변화를 담고 있다.

너무 쉽다. Jekyll Local 환경 만들기

Java 기반의 Web Application Server(WAS)를 이용하여 서비스를 제공하는 경우, 특정 Thread의 이상 폭주로 인하여 전체 서비스 품질에 영향을 미치는 경우가 발생할 수 있다. Thread 별로 CPU 사용량을 Capping할 수 있다면 좋겠지만, 이 글은 그렇지 못한 경우에 유용하게 활용할 수 있는 방법을 기록한다.

그 겨울, Thread를 골라 죽이고 싶은 상황을 만났었다.

물론, 대충 Apache Site에서 내려받은 것을 풀고 거기에 내 war 파일만 추가해도 잘 돌아가는 훌륭한 Tomcat이다. 하지만, 되는 거 말고 맞는 거!

프로그램에 알고리즘과 데이터구조가 따로 존재하듯이, 연습 경기가 아닌 실 운영 환경에서는 제공자에 의해 배포(또는 판매)되는 프로그램과 그것을 사용하는 사용자 영역의 것을 구조적으로 분리하는 것이 꼭 필요하다. (그렇다면 연습 경기도 실전과 같이 그렇게…)

Git의 매력에 빠져 절/친/ Subversion을 따돌림 시킨 지 꽤 오랜 시간이 지났음에도, 서버 측 Git 저장소 설정은 이번이 처음이다. 뭐, Github, Bitbucket 등의 개인들이 무료로 사용할 수 있는 훌륭한 저장소 서비스 겸 “Social 개발” 커뮤니티가 있다 보니, 그 필요성을 느끼지 못했던 것이 사실.

JVM을 사용하는 웹서비스에서 OOM(Out of Memory) Exception이 발행해 서비스 불가상태가 된 상황에서 JVM Heapdump를 받아 OOM 발생 원인을 분석한 사례에 대한 이야기이다. 안타깝게도 스크린샷을 충분히 확보하지 못해 내용이 좀 부실하다. 어쨌든, JVM 기반 WAS 장애 시 Heapdump를 이용하여 OOM의 원인을 찾는 과정에 대한 간략한 예시로써 작성한다.