LG 노트북 P420-KE45K 하드디스크 교체기

4년전쯤에 노트북이 필요해서 둘러보던중에 14인치 노트북을 구매했습니다. LG 에서 나온 노트북인데,  i5(샌디브릿지), 4GB RAM, 640GB, 블루투스, Wifi 인터넷등 필요한 기능이 다 있으면서도 13인치 폼팩터에 화면크기는 14인치라서 휴대성도 높을거 같아서 구매했습니다. 제게 시간이 지났어도  이만한 노트북을 다시는 볼수 없더군요. (뭐.. Dell XPS13 도 있지만 13인치는 너무 작아서…)

 

그런데, 이 녀석의 단점이 하나 있습니다. 바로 HDD 교체가 힘들다는 겁니다. 대부분의 노트북은 뒷판에 일부분을 열어서 교체할 수 있도록 되어 있지만, 이 노트북은 뒷판에 나사를 풀고 키보드 상판을 뜯어야 합니다. 문제는 상판을 아주 시원하게 다른데로 옮길수 없습니다. 상판과 하판, 하판에는 메인보드가 있습니다, 을 이어주는 케이블들이 있고 이것을 빼내고 다시 끼우기가 매우 힘듭니다. 그런데, HDD 가 위치한 곳이 터치패드가 있는 곳이라 살짝 상판을 들고 나사를 풀면 교체할 수 있어서 그 과정을 기록해 봅니다.

준비물

준비물은 나사를 풀수 있는 +드라이버와 상판을 뜯을때 쓸 플라스틱 입니다. 보통 전자제품에 접합부분을 분리할때에 -드라이버를 이용하게되는데, 그렇게되면 플라스틱이 찌그러지는 불상사가 발생합니다. 이럴때 기타칠때 쓰는 초크? 그거하나 있으면 됩니다. 이음새 부분에 그것을 끼워넣고 힘을주어 위로 들어올리면 분해가 되고 플라스틱도 찌그러지지 않습니다.

노트북 분해 준비물

상판,하판 분해하기

뒷판에 나사를 전부 풀면 이제 상판과 하판을 분리해야 합니다. 일단 노트북 스크린을 최대한 폅니다. 이음새부분을 분리할때는 접합이 가장 강하게 된부분을 먼저하면 좋습니다. 이 노투북의 경우 스크린과 노트북 본체를 연결하고 있는 부분이 연결이 강하게 되어 있습니다.  이제 힘을 조금써서 틈을 벌리고 기타 초크를 끼워넣어서 위로 재끼면 ‘딱’ 하고 분리가 됩니다.

노트북 이음새 분리

 

한부분을 벌리고 분리를 해내면 이제 저 초크를 이음새 부분들을 옮기면서 상판,하판을 벌리도록 힘을주어 재끼면 됩니다.

노트북 이음새 분리

상판 들어올려 HDD 상태 체크.

대부분의 노트북은 상판과 하판을 붙여놓고 나사로 고정한 상태입니다. 상판에는 키보드를 비롯한 입력장치가, 하판에는 메인보드가 있지요. 이 둘에 데이터전송을 위한 케이블들이 서로 연결되어 있습니다. 그래서 상판과 하판은 분리했다고 하더라도 상판을 급하게 들어올리게되면 케이블이 끊어지는 불상사가 발생하고 수리하기도 힘듭니다. 매우 조심해야할 부분입니다.

이 노트북도 예외는 아니여서 이음새를 완전히 분리하고 나서 상판을 살짝 들어올려 실눈으로 하드가 어디에 있는지, 케이블은 어떤상태인지를 봐야 합니다.

노트북 상판, 하판 연결상태 확인

 

위 사진과 같이 케이블이 상판과 하판을 이으고 있어서 급하게 들어올리면 끊깁니다. HDD 는 터치패드 바로 밑에 있네요.

HDD 분리하기.

이 노트북의 경우에 나사 설꼐가 상당히 잘되어 있습니다. 고정 나사는 2개인데, 처음에 뒷판에 나사를 풀때에 ODD 고정을 위한 나사가 있습니다. 이 나사가 ODD뿐만 아니라 내부적으로 HDD 한쪽부분도 고정되도록 되어 있습니다. 그래서 ODD 나사를 풀게되면 자동으로 1개의 HDD 나사가 풀린것과 같게 됩니다. 그럼 나머지 나사는?

노트북 하드디스크 고정 상태

 

바로 앞부분에 고정나사가 있습니다. 그러면 상판과 하판을 연결하는 케이블을 분리하지 않고 위 사진과 같이 앞으로 조금만 들어올려서 나사를 풀면 됩니다. 케이블 분리없이 할 수 있습니다!

P420 노트북 하드디스크

HDD 를 분리해낸 사진 입니다. HDD 에 붙은 쇠는 노트북에 고정시켜주는 가이드 입니다. 이것을 분리해서 새로운 하드에 붙여 줍니다.

P420 노트북 하드 가이드

 

그런데, 요즘 나오는 SSD 에 HDD 고정 가이드를 붙였더니 위 사진처럼 공간이 나더군요. 그래도 뭐, SSD 는 진동이 없으니까 괜찮을 듯 싶습니다.

조립은 분해의 역순으로 하시면 됩니다. 조립할때, 상판과 하판을 붙일때도 역시 접합이 가장 강한부분부터 해주시면 됩니다.

노트북 이음새 접합

위 사진에서 누르는 부분이 P420 노트북에서는 접합이 강하게 되는 부분이라 여러번 힘을 주어 꼭꼭 눌러 줍니다.

P420-KE45K 노트북은 HDD 가 터치패드 밑에 있고 이것을 교체하기 위해서는 상판과 하판을 분리해야 합니다. 이때 연결된 케이블이 있기 때문에 조심해야 합니다. 이상 P420-KE45K 노트북의 HDD 교체기 였습니다.

후속 작업

새롭게 교체한 SSD 에는 P420-KE45K 노트북에 함께 제공되는 Recovery Partition 이 들어 있습니다. 노트북 출고당시의 Windows 7 의 상태 그대로 들어 있어서 Recovery 소프트웨어를 이용하면 바로 복원을 해줍니다. 그러니까 윈도우즈를 다시 설치할 필요가 없이 언제든지 복원을하면 처음 구매당시로 돌아가게 되어 있습니다.

하지만 Recovery Partition 을 지워버리면 그렇게 할 수 없겠지요. 그래서 반드시 이 파티션은 건드리면 안됩니다.

노트북 복원

 

지난 7개월 동안(2015년 1월 1일 ~ 7월 17일까지) 프리랜서로 일하면서 써먹었던 노트북을 오늘(2015년 7월 18일) 복원 완료.

튜플(Tuple) 과 백쿰(VACUUM)

PostgreSQL 은 다른 데이터베이스 시스템은 테이블(Table)에 데이터를 레코드(Record) 혹은 로우(Row)라고 한다. 그런데, PostgreSQL 에서는 튜플(Tuple)이라는 것이 존재합니다. 이 튜플은 PostgreSQL 에서 매우 중요한 요소 입니다. 이에 대해서 간략하게 알아 보도록 하겠습니다.

통계정보 확보.

먼저 이 튜플을 알기 위해서는 PostgreSQL 이 제공하는 통계정보를 알아 볼 필요가 있다. 이 통계정보에는 로우 갯수와 튜플 갯수등을 볼 수 있고 로우에 변화에 따라서 이들이 어떻게 변하는지를 추적할 수 있으며 이를 토대로 튜플이 과연 무엇인지를 알 수 있게 된다.

샘플 테이블을 만들자.

그리고 샘플 데이터를 입력한다.

1000 로우를 입력된다.

통계정보를 통해서 튜플의 상태를 확인해보자.

테스트

튜플의 개수는 로우 개수와 같다. 데이터 입력이 들어오면 튜플의 개수는 입력되어 들어온 만큼 증가 한다.

그럼 튜플이 뭔지를 보여주는, 특성을 볼수 있는 실험을 해보자. 대부분의 RDBMS 에서는 트랜잭션을 지원한다. 이 트랜잭션의 결과는 COMMIT 아니면 ROLLBACK 이다. COMMIT이 되면 트랜잭션에서 했던 작업이 확정되어 그로 인해서 발생된 결과물은 실제 데이터로 고정된다. ROLLBACK 은 트랜잭션에서 했던 작업일 모두 취소하는 것으로 실제 데이터로 고정되지 않고 삭제처리된다. PostgreSQL 도 트랜잭션을 지원하기 때문에 동작방법은 동일하다.

COMMIT 후에는 확인결과 100개의 로우가 INSERT 되었고 튜플도 그만큼 늘었다. 그럼 ROLLBACK 도 테스트 해보자.

총 튜플 수가 증가했다. 그런데, dead_tup 에 100 이 있고 live_tup 에는 1100 으로 로우 개수와 동일하다. 또, 이전과 비교해서 테이블의 용량이 모두 증가했다. 트랜잭션을 롤백해서 실제 데이터가 반영이 안되었음에도 불구하고 어째서 테이블 용량이 증가하고 총 튜플수가 증가하는 걸까?

이번에는 다음과 같이 간단하게 UPDATE 문을 실행해보자.

데이터를 추가한것이 아닌 그냥 기존의 내용을 업데이트 했을 뿐인데, 총 튜플 수가 증가했다. 거기에 dead_tup 의 값도 증가했다. live_tup 만이 실제 데이터의 양이 바뀌지 않았음을 말해주고 있다. 데이터 용량을 말해주는 rel_size 는 저장되는 데이터의 증가와도 관련있어서 증가할 수도 있지만 그 증감이 너무나 크다.

도대체 왜 이러는 걸까? 왜 UPDATE, 트랜잭션의 ROLLBACK 시에 튜플이 증가하고 데이터 저장용량도 증가하는 걸까?

Dead Tuple 과 VACUUM FULL

결론부터 말하자면 MVCC 때문이다. 데이터베이스가 동시접속자 환경에서 데이터 일관성을 유지하기 위한 기법으로 ‘다중버전동시성제어’ 를 사용한다. PostgreSQL에서 트랜잭션이 발생하면 PostgreSQL 은 지금 있는 로우와 똑같은 것을 한번더 복제한다. 내부적으로는 테이블의 row 가 두가지가 생기는것이고 이는 두가지 버전이라고 생각하면 쉽다. 기존의 row 는 아직 COMMIT되기 이전에 사용자들이 보는 용도로, 복제된 또다른 버전의 row 는 트랜잭션 처리용으로 사용되어지게된다. 마치 스냅샷의 여러 버전들처럼 PostgreSQL은 row 에 다야한 버전을 생성하는데, 이것이 바로 튜플이다.

그럼 UPDATE 할때는 어떻게 될까? 위 예제에서는 데이터가 얼마 없어서 순식간에 UPDATE 끝났지만 아주 큰 데이터가 있을경우에는 시간이 걸린다. 그렇다고 SELECT 사용자에게 기다리고 할 순 없어서 PostgreSQL은 row 를 또 다른 버전을 만들어 UPDATE를 실행하고 완료되면 이전 버전은 삭제처리하게 된다.

그래서 UPDATE 시에 보면 dead_tup 의 갯수가 이전 양인 100 에서 전체 row 갯수만큼 1100이 증가된 것이다. PostgreSQL에서 튜플은 바로 이런 것이다. 그런데 여기서 문제가 있다.

UPDATE, ROLLBACK 이 완료되면 이전 버전의 row 들은 실제 활용하는 데이터가 아니기 때문에 하드디스크에 남아있으면 안된다. 하지만 PostgreSQL은 실제 삭제처리를 하지않고 사용자들에게 보이지 않도록만 한다. 튜플에 dead 라고 마킹(marking)만 하고 끝내는 것이다. DELETE 시에도 이렇게 실제데이터는 지우지 않고 Dead Tuple 로 처리된다. 그런데 SELECT를 할때는 어떻게 할까? PostgreSQL 엔진이 데이터 파일에서 데이터를 읽어들일때 이것이 dead 튜플인지 live 튜플인지 분간할 수 없다. 그냥 데이터 크기만큼 읽어들인다. 쉽게 말해서 Dead tuple 도 읽는다는 거다. 이거는 대단히 불합리하고 SELECT 성능에 영향을 미칠 수 밖에 없다.

튜플중에서 Dead Tuple 이 많으면 SELECT 성능이 떨어진다. Row 가 1개 인데, rel_size 용량이 수십GB 일수도 있다. 그렇게되면 PostgreSQL이걸 다 읽어보게되고 실행시간이 길어진다.

그렇다면 Dead Tuple 을 없앨려면 어떻게 해야할까? VACUUM FULL 을 한번 돌려주면 된다. VACUUM은 Dead Tuple 을 삭제처리 해준다. 이는 UPDATE, DELETE, ROLLBACK 이 많은 서버에 경우 반드시 VACUUM FULL을 해줘야 한다는 것을 뜻한다.

“tuple_test”: found 1200 removable 이 문장이 Dead Tuple 삭제가 가능하다는 것을 말하는 것이다. 실제 데이터 양(rel_size)  도 줄었다.

Better VACCUM FULL For PostgreSQL 9.0

원문:https://wiki.postgresql.org/wiki/What’s_new_in_PostgreSQL_9.0#Better_VACUUM_FULL

지금까지 VACUUM FULL 은 매우 느렸다. 이 구문(Statement)는 테이블로부터 빈공간을 확보하고 그것의 크기(Size)를 줄였지만 VACUUM 은 만족할만큼 빠르게 동작하지 않았다.

이것이 느린 이유는 동작 방법에 문제가 있었기 때문이다. 레코드를 그들의 소스블럭으로부터 테이블에 시작점에 가까운 블럭으로 하나하나씩 읽어서 옮겼었다. 그리고 테이블에 끝이 빈공간이면 그 부분을 지웠다.

전략적으로 이러한 방법은 매우 비효율적(Inefficient) 이다. 레코드를 하나하나씩 옮기는 것은 랜덤 I/O를 발생시킨다. 게다가, 인덱스(Index)를 재구성하는 동안에 그것을 유지하고, 더 많은 비용이 들어가는, 인덱스는 파편화된다. 이럴바에는 VACUUM FULL이 다 끝나고 나서 재인덱스(reindex)를 하는 것이 낫다.

Version 9.0 에서 VACUUM FULL은 테이블과 동일한 또 하나의 테이블을 만들고 거거에 모든 레코드를 순차적이게 복사한다. 모든 레코드가 복사되고 나면, 인덱스를 재생성하고 예전 테이블은 삭제되고 새로운 테이블로 대체된다.

이것은 VACUUM 을 보다 빠르게 한다. 하지만 VACUUM FULL은 동작하는 동안에 AccessExclusiveLock 을 필요로 한다. 이전 방법과 비교했을때 이 방법의 결점은 VACUUM FULL을 했을 경우 새로운 버전의 테이블을 만들기 위해서 디스크에 테이블 크기의 2배의 용량을 사용할 수 있다는 것이다.

이제, 두가지 방법에 대해서 실시간으로 비교를 해보자. 먼저 아래와 같은 방법으로 테스트 데이터를 준비 했다.

8.4 버전에서는.

다 합해 대충 9초 정도 걸렸다.

9.0 버전에서는.

아직 이것은 제품에서(아마 서비스중에라는 뜻인듯..) VACUUM FULL 이 좋은 아이디어라는 뜻은 아니다. 만약 이것이 필요하다면, 아마도 VACUUM 정책이 올바르지 않기 때문일 것이다. (응?)

명시적 락킹(Explicit Locking)

이 문서는 PostgreSQL 9.1.2 문서중에 13.3 챕터를 해석한 것입니다. 전문 번역가도 아니고 중학교 영어만으로 해석한 것이어서 의미전달이 제대로 되지 않을 수도 있음을 미리 밝힙니다.

원문: http://www.postgresql.org/docs/9.1/static/explicit-locking.html

13.3 명시적 락킹(Explicit Locking)

PostgreSQL 은 테이블의 데이터에 동시적 접근(concurrent access)을 제어하기 위해서 다양한 락 모드(Lock mode)를 제공합니다. 이러한 모드들은 MVCC(다중 버전닝 동시성 제어)가 바라던 해동을 제공해주지 않을때에 애플리케이션 제어 락킹을 하려고 할때에 사용되어질수 있습니다.  또 대부분의 PostgreSQL 명령어들(commands)은 명령어가 실행되는 동안에 비호환적인 방법으로 참조하는 테이블이 변경되거나 버려지진(Dropped)않도록 하기위해서 자동적으로  적절한 락을 획득합니다. (예를들어, TRUNCATE는  같은 테이블에서 다른 연산들을 가지고 안전하게 동시에 실행되어지지 않을 수 있습니다. 그래서 안전성을 획득하기 위해서 강정적으로 테이블에 배타적 락(Exclusive Lock)을 얻얼 수 있습니다.)

13.3.1 테이블 수준의 락들(Table-Level Locks)

아래의 리스트는 PostgreSQL에 의해서 자동적으로 사용되어지는 사용가능한 락 모드와 문맥(contexts)들을 보여줍니다. 당신은 LOCK 이라는 명령어를 통해서 명시적으로 이러한 락들을 획득할 수 있습니다. 한가지 주목할 것은, 비록 이름에 “row”라고 되어있어도 테이블 수준의 락들(Table-Level Locks)이라는 것입니다. 락 모드의 이름들은 역사적입니다.

몇몇 확장된(extent) 이름들은 각 락 모드마다 전통적인 사용법과 반대적입니다. 하지만 의미론적으로는 모두 같습니다. 하나의 락 모드와 다른 락과의 차이에 대한 한가지 사실은 각각 상충되는 락 모드가 설정된다는 것입니다. 두개의 트랜잭션(transaction)은 같은 시점에 같은 테이블에서 상충적인 락 모드(locks of conflicting, 서로 모순되는 락 모드) 를 가질 수 없습니다. (하지만, 하나의 트랙잭션은 그 자체적으로 출돌이 나지 않습니다. 예를 들면, 같은 테이블에서 ACCESS EXCLUSIVE LOCK을 획득하고 후에 ACCESS SHARE LOCK를 획득할 수 있습니다. ) 상충적이지 않은 락 모드는 많은 트랜잭션에 의해서 동시적으로 가질 수 있습니다. 주목할 것은 특정 상황에서 어떤 락 모드는 자체 상충적(self-conflicting)이 됩니다. (예를들어, ACCESS EXCLUSIVE LOCK는 같은 시점에서 하나의 트랜잭션보다 더 많이 가질 수 없습니다.)

Table-level Lock Modes

ACCESS SHARE

오직 ACCESS EXCLUSIVE 락 모드와 상충적입니다.

SELECT 명령어는 참조하는 테이블에 이 모드의 락을 획득합니다. 일반적으로, 테이블에서 수정은 하지 않고 오직 읽기만을 하는 모든 쿼리들은 이 락 모드를 획득합니다.

ROW SHARE

이것은 EXCLUSIVE 와 ACCESS EXCLUSIVE 락 모드와 상충됩니다.

SELECT FOR UPDATE 와 SELECT FOR SHARE 명령어들은 대상 테이블에서 이 모드의 락을 획득합니다. (추가적으로 ACCESS SHARE 는 selected FOR UPDATE/FOR SHARE 가 아닌 참조되어지는 다른 모든 테이블을 락 합니다.

ROW EXCLUSIVE

이것은 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE 와 ACCESS EXCLUSIVE 락 모드와 상충됩니다.

UPDATE, DELETE, INSERT 명령어는 대상 테이블에서 이 락 모드를 획득합니다. (추가적으로 ACCESS SHARE 는 다른 참조되어지는 모든 테이블을 락 합니다. 일반적으로, 이 모드는 테이블에서 데이터를 수정하는 모든 명령어들에 의해서 이 모드는 획득되어 집니다.

SHARE UPDATE EXCLUSIVE

SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 락 모드와 상충됩니다. 이 모드는 VACUUM 실행과 동시적 스키마 변화에 대해서 테이블을 보호합니다.

VACUUM( FULL 제외), ANALYZE, CREATE INDEX CONCURRENTLY, 그리고 특정한 ALTER TABLE 폼에 의해서 획득됩니다.

SHARE

ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE 그리고 ACCESS EXCLUSIVE 락 모드와 상충됩니다. 이 모드는 동시적으로 데이터를 변경하는 것에 대해 테이블을 보호 합니다.

CREATE INDEX(CONCURRENTLY 제외) 에 의해서 획득되어 집니다.

SHARE ROW EXCLUSIVE

ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 락 모드와 상충 됩니다. 이 모드는 동시적 데이터 변경과 특정시점에서 한 세션이 그것을 가지고 있기위해서 자체 exclusive(self-exclusive) 한 것에 대해서 테이블을 보호 합니다.

이 락 모드는 PostgreSQL의 어떤 명령어로도 자동적으로 획득되어지지 않습니다.

EXCLUSIVE

ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 락 모드와 상충 됩니다. 이 모드는 오직 동시적 ACCESS SHARE 락만을 허용합니다. 예를들어, 테이블로부터 읽을때에 한 트랜잭션이 이 락 모드로 홀딩되면 다중으로 실행을 할수 있습니다.

이 락 모드는 PostgreSQL의 어떤 명령어로도 테이블에 자동적으로 획득되어지지 않습니다.

ACCESS EXCLUSIVE

모든 모드의 락과 상충됩니다. 이 모드는 어떤 방법으로든 트랜잭션이 테이블에 접근하는 것을 보장합니다.

ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, 그리고 VACUUM FULL 명령어에 의해서 획득되어 집니다. 또, 이 모드는 LOCK TABLE 구문에 대한 기본적인 락 모드 입니다.

Tip: 오직 ACCESS EXCLUSIVE 는 SELECT 구문을 블럭하는 락입니다.

한번 획득되어진 락은 트랜잭션이 끝날때가지 들고 있습니다. 하지만 만약에 저장시점이 설립된 이후에 락이 획득되어진 것이라면, 저장시점이 롤백되는 즉시 해제 됩니다. This is consistent with the principle that ROLLBACK cancels all effects of the commands since the savepoint. The same holds for locks acquired within a PL/pgSQL exception block: an error escape from the block releases locks acquired within it.

외부에서 Postgresql 접속할 수 있도록 설정하기

Postgresql 설치를 하게되면 외부에서 접속을 기본적으로 할 수 없게 되어 있다. 호스트 기반 인증 파일인 pg_hba.conf 파일만 고친다고 되지 않는다. 외부에서 접속하는 서버의 IP를 192.168.0.18 이라고 가정한다.

pg_hba.conf 파일

Postgresql 은 Host Based Authorization 기반으로 외부 접속을 제어 한다. 이는 pg_hba.conf 파일을 다음과 같이 편집함으로써 가능하다.

위 설정은 모든 데이터베이스에 대해서 모든 사용자에 대해서 192.168.0.18 에서 접속을 허용한다는 내용이다.

postgresql.conf 파일

이 파일도 반드시 설정을 바꿔줘야 외부에서 접속을 할 수 있다. 바꿔야 할 설정은 다음과 같다.

이걸하지 않하면, 외부에서 접속을 할 수 없다. 그리고 이 설정은 반드시 서버를 재시작 해줘야 한다. 따라서 보통 Postgresql 을 설치를 하면 기본적으로 이 설정을 해주고, pg_hba.conf 파일에서 모두 외부접속을 제어한다.

iptables 설정

보통 많은 사람들이 iptables 를 내려놓고 서버를 운영하는데, 매우 위험한 짓이다. 이를 내려놓고 하는 이유는 귀찮기 때문이다. 뭔가를 하는데 자꾸 않되고 하다가 찾다보면 결국 iptables 때문인걸 알게 되면 매우 화가나고 다음부터 이를 피하기위해서 iptables 를 꺼놓는다. 바보같은 짓거리에 서버 관리자로서 자질도 의심되는 행동이다.

Postgresql 을 위한 iptables 설정은 다음과 같다. 참고로 배포판에 rpm 으로 설치된 iptables 를 이용하는 방법이다.

이렇게 한 후에 iptables 를 재시작 해주면 된다.

PostgreSQL 과 문자셋

PostgreSQL 도 문자셋에 관해서 많은 옵션들을 제공한다. 그런데, 대부분은 이에 대해서 잘 모르는 듯해서 여기서 정리해 본다.

PostgreSQL 에서 문자셋 지정을 처음 하는 부분은 바로 설치를 마친후에 initdb 명령어를 사용하면서 부터다 대충 다음과 같이 사용한다.

문제는 저러한 문제셋 설정이 과연 향후 PostgreSQL 을 사용하는데 있어 어떤 영향을 주는가 하는 것이다. 먼저 PostgreSQL 은 ISO C 와 POSIX 등의 언어표현에 관해 지원 한다.

Locale

보통 initdb –locale=ko_KR.UTF-8 로 사용되어지는 것으로 운영체제에 종속적이다. 운영체제에서 지원하는 locale 만 사용할 수 있는데, 리눅스의 경우에는 ‘locale -a’ 명령어로 확인 가능하다.

이는 운영체제의 사용자에게 보여주는 메시지 문자를 지정한다. 만일 영어로 운영체제를 사용하고 싶다면 바로 이 locale 를 변경하면 된다. 그런데, locale 의 설정은 ‘ko_KR.UTF-8’ 처럼 나오는데 이는 language_territory.codeset 형태이다.

language 는 인간의 사용하는 언어이고 territory 는 ‘한 국가가 다스리는 영토, 지역’을 뜻한다. 예를들어서 fr_CA 도 있는데 이는 캐나다에서 사용하는 프랑스어라는 뜻이 된다. codeset 은 이러한 언어를 컴퓨터 언어로 표현하는 문자 셋이다.

이러한 형태가 나온 이유는 한 국가(영토, 지역)에서 두가지 이상의 언어를 사용할 경우를 대비한 것으로 풀이된다.

LC_COLLATE

이는 매우 중요한 것으로 다음과 같은 것에 영향을 미친다.

  1. 대소문자를 구분하는 기능.
  2. 문자열 정렬
  3. ‘like’ 문에서 인덱스를 사용여부 결정

이는 데이터베이스를 생성할때에도 지정할 수가 있는데, 지정하는 방법은 locale 과 같이 language_territory.codeset 형식이지만 codeset 은 생략하는 경우가 있다. 다음과 같은 명령어로 확인 가능하다.

문제는 이 LC_COLLATE 는 initdb 시에 한번 결정이 되면 바꿀 수 없고 하지만, Template 을 1번이 아닌 0번으로 할 경우에는 가능하다. Template1 은 initdb 때 생성되는 일종의 Master  DB라 보면되고 모든 데이터베이스는 이 Template1 을 기반으로 생성되어진다.

LC_CTYPE

이는 문자의 범주를 정하는 것으로 각 언어마다 가지고 있는 고유한 특성을 타나내기도 한다. 예를들면 단어가 무엇인지, 대문자와 소문자,one byte 문자인지 multi byte 문자인지에 대한 정의등에 대한 것이다. 이는 initdb 실에 결정되면 바꿀 수 없다.

대부분 Locale 을 따라 지정하는게 낫다.

LC_MESSAGE  

이는 접속한 클라이언트에게 어떤 언어로 보여줄지를 결정한다.

LC_MONETARY 

이는 접속한 클라이언트에게 어떤 화폐단위로 보여줄 것인지를 결정한다.

LC_NUMERIC

이는 접속한 클라이언트에게 어떤 숫자단위로 보여줄 것인지를 결정한다.

LC_TIME

이는 접속한 클라이언트에게 날짜와 시간에 대한 포맷을 결정한다.

 

CHEF CLIENT 설치 – PART4

앞에서 chef 운영을 위한 server와 workstation 을 설치했다. 이제 chef 를 가지고 관리를 할 대상인 서버에 chef client 를 설치하는 방법에 대해서 설명한다.

chef 에서 관리해야할 대상 서버를 Node혹은 Client 라고 부른다. 이러한 서버들은 chef server와 통신을 통해서 각종 작업을 수행하는데, 이 역활을 담당하기는게 바로 chef-client 이다.

chef client 설치는 서버에 직접 들어가서 프로그램을 설치하고 관련 파일을 업데이트하는 작업을 통해서도 할 수 있지만 Chef 스럽게 workstation에서 knife 명령어를 이용해서 간단히 Chef Client 를 설치할 수 있다. 이뿐 아니라 설치와함께 이 서버를 Chef Servr 에 관리대상 서버로 등록해준다.

Chef Client 설치

설치에 앞서 Chef Client 가 될 서버에서 Chef Server 에 호스트네임과 IP를 다음과 같이 등록해준다.

Chef Client 설치는 Chef Workstation 에서 다음과 같이 명령어로 진행한다.

이 한줄이면 아무것도 없는 서버에 Chef Client 가 설치되고 Chef Server 에 Node로 등록된다.

Chef-client 12.4.0-1 에서 문제

아무 위에처럼하면 Chef-client 가 설치가 되어도 Chef Server 와 통신문제를 겪게 된다. 다음과 같은 오류 메시지를 받게 될 것이다.

핵심은 인증키인 validation_key 가 맞지 않다는 것이다.

Chef Workstation 에서 Chef Client 설치 명령어를 수행하면 Chef Client 에 접속해 Chef Client 최신버전은 chef-12.4.0-1 버전을 더운받아서 설치하고 Chef Client 설정파일들이 /etc/chef 디렉토리에 모인다.

그중에 validation.pem 파일이 맞지 않다는 것이다.

Chef Server 는 Chef Client 와 통신을 위해서 공개키/비밀키 기반으로 한다. Chef Server 는 공개키를 각 Chef Client 에 제공하고 Chef Client 는 비밀키를 Chef Server 에 보낸다. 그러면 통신을 할때에 이것을 가지고 인증을 한다.

하지만 chef-12.1 이상 버전부터는 이 키, 더 정확하게는 validation.pem 이 필요없게 되었다. 이에 대한 내용은 다음 링크에서 확인할 수 있다.

결국에는 Chef Workstation 이 가지고 있는 공개키를 삭제하면 된다는 것이다.

그리고 난 후에 방금 실패했던 Chef Client 에서 /etc/chef 디렉토리를 삭제한다.

Chef Workstation 에서 다시 한번 bootstrap 명령어를 주면 Chef Client가 다음과 같이 설치되고 Node 로 등록된다.

Chef Client 등록 확인

Chef Workstation 에서 등록 확인.

Chef Workstation 설치 – Part 3

chef workstation 은 knife 를 설정면 하면된다. 다시말해서 별다른 패키지가 필요없고 특정 시스템 계정사용자에게 knife 를 사용할 수 있도록 설정만하면 그게 바로 workstation 이 되는 것이다.

하지만 별도의 시스템에 workstation 을 설치하고자 할 경우에 knife 명령어가 없다. 그렇다고 chef server 패키지를 설치할려고 하니 불필요한 서비스들이 너무 많은게 문제다. 이럴때는 chef develoment kit 를 설치하면 된다.

chef development kit 은 말그대로 chef 관련 개발을 위한 kit 을 제공하는 것으로 이는 chef workstation 환경을 기반으로 한다. 따라서 chef development kit 패키지를 설치하면 chef workstation 구성을 위한 chef 관련 명령어들이 당연히 들어 있게 되는 것이다.

chef development kit 역시 chef 홈페이지에서 다운로드 가능하다. 레드햇과 우분투 배포판 패키지가 준비되어 있어 패키지를 다운받아 설치하면 된다.

이제 chef 명령어를 이용해서 알맞은 환경을 조성할 수 있도록 다음과 같이 해준다.

앞에서 chef 서버 설치하면서 만들어놓은 자격증명 파일을 복사해 와야 한다. scp 를 이용하던 ftp 를 이용하던 어떻게든 복사하면 되는데, 중요한 것은 복사할 디렉토리가 chef 저장소 디렉토리이다. 이것은 자동으로 생성되는 것이 아니기 때문에 다음과 같이 수동으로 생성해주자.

위 디렉토리에 chef 서버 설치할때 만든 자격증명 파일을 복사 넣는다.

이제 knife.rb 파일을 작성한다. 이 파일 역시 ~/chef-repo/.chef 디렉토리 작성한다. 주요한 파일 내용은 다음과 같다.

이것을 기반으로 환경에 맞게 변경을 하면 다음과 같다.

이렇게 한 후에 다음과 같이 테스트 해본다.

위 에러 메시지는  chef  서버의 SSL 인증서가 없어서 나는 오류다. 오류가 나왔지만 위 메시지만으로 chef 서버와 통신은 성공했다는 것을 알 수 있다. 이제부터는 knife  명령어로 chef  서버와 명령어를 주고받을 수 있다. SSL 인증서가 없다고 하니 chef 서버로부터 받아오자

다시 다음과 같이 나오면 정상적으로 작동하는 것이다.

 

Chef 서버 설치하기 – Part 2

이번 시간에는 Chef 서버를 설치해보도록 한다. 설치에 앞서 Chef 서버를 설치할 서버들에 대한 정보는 다음과 같다.

  • 배포판: Ubuntu 14.04.2 LTS
  • CPU: 1 core
  • RAM: 1024

여기서 중요한 것은 배포판이다. 최근들어 많은 배포판들이 init 에서 systemd 로 바꾸는 추세다. 우분투(Ubuntu)에 경우 systemd 를 도입할 생각이 없다라고 했었지만 14.10 에서 이를 뒤집어 systemd 를 도입했다. init 과 systemd 는 서버 프로그램 시작과 종료하는 방법만 다른게 아니기 때문에 이를 구분하는 것은 매우 중요하다. 여기서 설치할 14.04 는 현재 init 을 따른다.

Download

다운로드는 chef 홈페이지에서 무료로 다운로드 할 수 있다. 그런데, 약간 실망스러운게 다운로드를 하기 위해서는 여기저기 단계를 거쳐야 한다는 것이다. 무료로 다운로드 되는 링크가 바로 나오지 않고 hosted, primium 과 같은 상품을 먼저 전시하고 링크를 찾아 클릭해야만 무료 다운로드 링크가 나오는 구조다.

무료 chef 다운로드
무료 chef 다운로드

우선 서버를 설치해야 하기 때문에 Chef Server 를 다운로드 받는다. Chef Server 는 레드햇 배포판 계열과 우분투 계열은 패키지를 제공한다. 단, 제공되는 배포판 버전은 제한적일 수 있다. 우리는 우분투 14.04 배포판에서 설치할 것이고 지금 현재 Chef 홈페이지에서는 다행이도 이 배포판 버전에 패키지를 제공한다.

Installation

설치는 여러가지 방법이 있는데 여기서는 dpkg 명령어를 이용해 패키지를 설치한다. 이렇게하면 Standard 형식으로 설치가 된다.

설치는 간단하다. 하지만 여기서 끝나는 것이 아니라 이제 시작이다.

Setting

설치가 끝나다면 이제 chef 가 동작하기 위해서 설정을 해준다. chef 서버의 설정은 ‘chef-server-ctl 명령어를 이용해 거의 모든것을 할 수가 있다. Standard 형식의 설치이기 때문에 다음과 같이 해준다.

chef 서버는 다양한 서비스들이 필요하다. 이러한 것을 일일이 다하기보다는 chef 자체의 기능인 자동화 기능을 이용할 수 있는데 그것은 다음과 같다.

과정을 유심히 보면 nginx 웹서버도 설치된것을 알 수 있다.

여기서 잠깐 chef-server-ctl 는 그야말로 chef server 를 컨트롤하기위한 명령어이기 때문에 서버의 상태뿐만 아니라 각종 서비스들에 대한 설정을 변경할 수 있다. 여기서 간단히 알아보도록 하자.

상태보기

서비스 내리기

nginx 서비스를 내린 예지다. 서비스를 올릴려면 start 옵션을 주면 된다.

서비스 로그들 보기

서비스 로그들도 다음과 같이 한번에 볼 수 있다.

chef 이기 때문에 관련 서비스들 관리도 chef 로 한다.

현재 설정들 보기

각 서비스들에 설정상태를 보여준다.

간단하게 chef-server-ctl 에 대해서 알아봤다.

여기까지만 해도 사실 chef server 설치는 끝난다. 하지만 chef server 를 운영하기 위한 계정을 만들어야 할 필요가 있다.  chef-server 를 매니징할 수 있는 서버는 chef workstation 이라는 점이다. chef client 에 chef server 를 매니징 할 수는 없다. chef 로 무엇을 하기위한 관련된 모든 것은 chef workstation 에서 이루어진다고 보면 맞다.  따라서 chef server 에 접근할 수 있는 것도 오직 chef workstation 으로 한정된다.

이를 위해 다음과 같은 추가 작업이 필요하다.

  1. 관리자 계정 생성
  2. 관리자 조직 생성

관리자 계정 생성

조직 생성

위에 sbhyun.pem 와 systemv.pem 은 chef server 에 연결위한 자격증명서다. chef workstation 은 chef server 와 연결해 작업을 수행하는데, 이때 chef server 가 과연 올바른 chef workstation 연결인지를 판별하기 위해서 필요한 것이 바로 이 자격증명 파일이다. 따라서 이 자격증명 파일은 chef workstation 에 복사해주어야 한다.

따라서 이 자격증명 파일은 꼭 잘 간수해야 한다.

다음시간에는 chef workstation 설치에 대해서 알아보자.

Chef 에 대해서 – Part 1

OC_Chef_Logo

서버환경이 분산화되면서 수많은 서버들을 관리해야 문제가 생긴다. 대략 1,000대 서버에 Apache 웹서버 설정을 변경하고 그것을 적용하라고 한다면 단시간내에 어떻게 할 것인가와 같은 문제들이다.

프로그램을 개발하고 그것을 서버에서 돌리기위해서는 기본적인 인프라 관리가 필수인데 최근에 글로벌 서비스가 많아지면서 분산된 대랭의 서버들을 어떻게 다룰것인가 하는 문제대한 해답으로 Chef, Puppet 과 같은 인프라스트럭쳐 자동화 프로그램들이 등장했다.

이 문서는 Chef 에 대한 기초적인 내용을 다룬다. 범위는 다음과 같다.

  • Chef 에 대해서
  • 설치
  • 레시피, 쿡북 작성
  • 다양한 예제들.

Chef 에 대해 

Chef 는 서버나 애플리케이션을 쉽게 배포하기 위한 시스템이나 클라우드 인프라 자동화 프레임워크이다. 여기서 중요한 것이 프레임워크(Framework) 라는 사실이다.

시스템이나 애플리케이션을 배포한다는 개념을 단순하게만 봤을때 그냥 관련 파일들을 배포하면 된다. 하지만 대량의 시스템은 다양한 변수들이 존재하고 이러한 변수들을 모두 수용하고 조작하기 위해서는 프로그래밍만한 방법도 없다.

Chef 는 Ruby 로 작성되었다. 따라서 Chef 를 확장하거나 커스터마이징을 하고 싶다면 Ruby 를 잘 알아야 한다. 특히나 특정 조건에 한해 특정 시스템이나 애플리케이션에만 적용되도록 무언가를 만들고 싶을때 Ruby 프로그래밍 지식은 많은 도움이 된다.

Chef 서버 구성도
Chef 서버 구성도

Chef 의 서버 구성은 다음과 같다.

Chef 는 이와같이 Server, Workstation, Client(Node) 로 나뉜다.  Client 는 Chef 에서는 Node 라 불리며 자동화를 시킬 서버 혹은 클라우드 시스템이다. Server 는 Chef 의 모든 것이다. 배포할 Node 목록과 이 Node 들에 대한 정책을 적용할 Rule, 각종 설정내용을 저장하는 저장소, 손쉽게 Node 를 추가하고 정책들을 적용하기 위한 웹 매니저 등을 포함한다. 물론 모든 작업은 Command-line 으로 가능하다. Workstation 은 배포할 애플리케이션에 대한 설정이나 명령어들을 만드는 서버다. Chef 에 이렇게 Node 적용하기 위한 것을 레시피(Recipe) 라고 부르며 레시피 묶음을 쿡북(Cookbook) 이라고 부른다.

당연한 이야기지만 위 서버들이 모두 필요한 것은 아니다. 단일 서버에 Chef 구성이 모두 포함될 수 있다. 아니면,  Server 와 Workstation 을 한 서버에서 모두 구성할 수 있다.

Chef 구성도
Chef 구성도. (출처:Chef 문서)

이러한 개념들은 다음과 같이 Chef 구성도로 나타낼 수 있다.  Chef 를 가지고 할 수 있는 주요한  것들을 나열해 보면 다음과 같다.

  1. 시스템에 명령어 보내고 출력값을 받기
  2. 각종 프로그램 설정 파일들 배포하기
  3. 서비스 프로그램 정지, 시작, 재시작하기
  4. 각종프로그램 설치 – 패키지 설치 or 컴파일 설치

서버나 클라우드 시스템을 다룰때에 대부분은 위 네가지 경우로 수렴된다. Chef 를 이용해 위와같은 작업을 할 경우에는, 첫째로 시스템을 등록하고(이걸 Node라 부른다) 두번째로 레시피를 작성한다. 셋째로 그 레시피를 쿡북에 반영시키고 넷째로 Node 에 명령어를 보내면 Node 는 쿡북을 다운받아 그것을 실행 시켜준다.

그래서 Chef 서버가 모두 구성되고 나서부터 대부분의 작업은 Workstation 에서 다 이루어진다고 보면 된다.

물론 인프라 관리 자동화 프로그램으로 Chef 만 있는 것이 아니다. Puppet 도 나름 꽤 유명하다. 하지만 내가 보기에 Chef 만큼이나 쉽고 간단한 것은 없는 것 같다. 용어들도 마치 시스템 관리를 요리에 빗대어 놓은것도 재미와함께 이해력을 높여준다. 실제로 Workstation 에서 뭔가를 할때에 쓰이는 도구가 나이프(knife)다. 요리를 할때 칼질은 기본이지!!

Chef 에 대해서 간단히 알아봤다. Chef 구성도를 보면 참 많은 것들이 눈에 들어오는데, 지금은 몰라도 된다. 왜냐하면 나도 모르니까. 차차 알아가면 될 문제이니 너무 서둘을 필요는 없을듯 싶다.

다음 시간에는 Chef Server 설치에 대해서 알아보자.