Category: MongoDB

MongoDB 글을 모아놓은 카테고리

MongoDB 3.x 인증 알고리즘 변경

MongoDB 3.x 부터는 인증 알고리즘이 MONGODB-CR 에서 SCRAM-SHA-1 으로 변경되었다. 그런데 특정 사용자에 대해서 MONGODB-CR 방식을 적용해야할 필요가 생기기도 한다. 그래서 사용자마다 알고리즘을 달리 적용할 수 있을까?

결론부터 말하면 MongoDB 3.x 는 이를 지원하지만 지원하는 것 같지 않은 상태다. 공식적인 지원을 하지만 이를 구현하기 위해서는 서버를 중단해야하고 인증을 해제해야한 다음에 사용자 알고리즘을 고치고 다시 인증을 걸고 서버를 재시작해야 한다.

또, Replica Set 상태에서 Primary 에서 MONGODB-CR 인증을 설정한다고 하더라도 Secondary  에서는 SCRAM-SHA-1 으로 싱크가 된다. 그래서 프로그램상에서 Replica Set 에서 접속할때에 MONGODB-CR 인증방식으로 접속을 시도하면 Primary 에서는 정상으로 접속되나 Secondary 서버에서는 인증이 실패해 접속이 안된다.

이러한 한계에도 불구하고 MongoDB 3.x 인증 알고리즘 변경 은 다음과 같이하면 된다.

서버 셧다운

제일 번저 서버를 셧다운 해야한다. 이유는 인증모드를 해제하기 위해서다. 관리자로 로그인을 한 후에 다음과 같이 서버를 셧다운 한다.

 

무인증 설정

이제 MongoDB 설정 파일에서 인증 부분을 주석처리해 무인증으로 만들고 서버를 시작한다.

이렇게 한 후에 서버를 시작하면 인증없이 모든 것을 할 수 있게 된다.

 

MONGODB-CR 인증 계정 생성

MONGODB-CR  인증을 생성하기 위해서는  MongoDB  자체의 인증 방법을 먼저 변경을 해줘야 한다. 이 변경은 역시 무인증 서버상태에서만 가능하다.

authSchema 버전을 3으로 변경하는데 이게 MONGODB-CR 인증 방법을 말한다. 5번은 SCRAM-SHA-1 이다.

이제 생성하고자하는 계정의 데이터베이스로 가서 계정을 생성한다.

생성된 계정을 확인해보면 다음과 같다.

 

인증방법 복원

MONGODB-CR 을 위한 계정을 생성했다면 SCRAM-SHA-1 로 바꾸고 서버에 인증을 걸어야 한다.

그리고 설정파일에 인증을 걸어준다.

그리고 서버를 재시작해주면 된다.

문제점

문제점은 앞에서 이야기 했듯이 Replica Set 상태에서 Primary 에서 MONGODB-CR 인증으로 계정을 생성했다고 하더라도 Secodary 에서는 SCRAM-SHA-1 으로 싱크가 된다. 그래서 Secondary 서버에 MONGODB-CR로 인증할려면 오류를 낸다.

 

MongoDB Replica Set 구성하기

mongodb logoMongoDB 는 Replication 을 지원한다. 이는 서비스의 지속성과 안전성을 제공하는 데이터베이스 시스템의 설비다. MongoDB 는 단순하게 데이터 복제를 위한 것뿐만 아니라 Master 가 장애시에 이를 Slave 를 Master 로 자동승격시켜준다. 수 많은 Slave 중에 어떤 것을 Master 로 승격할지를 투표를 통해서 결정한다. MongoDB 는 투표에 참여하기만 하는 것으로 Arbiter 를 세팅할 수도 있다.

이글은 다음의 아키텍쳐를 기반으로 한다.

replica set primary with secondary and arbiter
replica set primary with secondary and arbiter

Replica Set 설정

replication 설정을 위해서 서버 두대에 etc/mongod.conf 파일을 다음과 같이 설정을 해준다.

oplogSizeMB 는 Replication 을 위해사용되는 로그파일의 용량을 지정하는 것이다. 메뉴얼에 따르면 파일시스템의 활용가능한 5% 를 지정하라고 되어 있지만 고용량 스토리지 시대에는 너무 큰 것 같다.

위와같이 하고 Replica Set 을 설정해주면 된다. 보통 Replica Set 은 적어도 3대로 구성하는데 Primary, Secondary, Aribter 가 바로 그것이다.

한가지 주의해야할 사항은 Replica Set 구성을 미리해놓은다고 서버가 한대인데도 mongod.conf 에 위 설정을 하고 서버에서 명령어를 치면 다음과 같은 오류를 만나게 된다.

위 설정은 Master/Slave 두 서버에 모두 해줘야 한다. 그리고 두 서버를 모두 재시작 해준다.

Replication 설정

어떤 블로그에는 Replication 설정을 위해서 다음의 명령어를 치라고 나온다.

적어도 MongoDB 3.2 버전에서는 절대로 위 명령어를 먼저 쳐서는 안된다. 내 경우에 멋모르고 위 명령어를 먼저 쳤다가 MongoDB 가 Primary 로 지정되지 않아 아무것도 할 수 없었다. 이럴 경우에 강제로 Primary 임을 지정해줘야 하는데 절차는 다음과 같다.

force 옵션을 주어서 강제로 설정을 지정하게 해줘야한다.

아무튼, 맨 처음에 아무런 생각없이 rs.initiate() 을 해서는 안된다. 특히나 Primary 임을 지정해야하는 서버의 경우에는 이렇게 해서는 안된다. 반드시 멤버지정을 수동으로 해줘야 한다.

이렇게 하면 이 서버는 이제 Primary 로 지정된다. 상태를 살펴보면 다음과 같다.

“stateStr” 이 PRIMARY 라고 나와야 정상이다.

이제 슬레이브를 붙이면 되는데, MongoDB 는 이를 아주 쉽게 명령어로 할 수 있다. Slave 서버를 구동하고 다음과 같이 Primary 서버에서 명령어를 입력해주면 된다.

Slave 를 붙이자마자 상태를 확인해보면 stateStr 이 STARTUP2 로 나온다. 하지만 시간이 지나서 다시 확인해보면 SECONDARY 가 되어 있는 것을 확인할 수 있다.

PRIMARY 와 SECONDARY 가 동기화가 잘되고 있는지는 optime 의 수치가 모두 동일한지를 보고 판단할 수 있다.

Aribter 추가

Aribter 는 PRIMARY 가 장애가 발생했을시에 이를 감지하고 SECONDARY 중에 하나를 PRIMARY 로 선택할때 투표에 참여하는 역화을 한다. 즉, 오직 투표만을 위한 시스템이라고 보면 된다. 따라서 데이터 복제, 데이터 저장이 없기 때문에 저장소를 위한 설정은 다 필요가 없다. 따라서 mongod.conf 설정은 다음과 같다.

MongoDB 3.2 메뉴얼에 따르면 Aribter 로 동작하는 Node 의 경우에 storage.journal.enabled 를 false 로 설정하도록 권장하고 있다. 그리고 Engine 관련 설정은 모두 주석처리를 한다.

이렇게 설정한 후에 Aribter 서버를 시작시킨다. 그리고 Master 서버에서 다음과 같이 Aribter 를 추가해 준다.

위와같이 하면 Arbiter 가 Replica Set 에 추가 된다. 그리고 Master 가 장애가 발생하면 투표에 참여해 SECONDARY 서버중에 하나를 Master 로 지목하게 된다.

MongoDB 설치 및 환경설정

mongodb logo

이 글은 MongoDB 설치 및 환경설정에 관한 글이다. 환경설정은 슈퍼유저의 인증을 설정하는 것까지 한다.

Download and Extract

Mongodb 는 Binary 배포를 하고 있다. 홈페이지에 접속해서 설치할 컴퓨터의 운영체제에 맞는 압축 파일을 다운로드 하면 된다. Downlaod URL 도 제공하기 때문에 서버에서 wget, curl 을 이용해서 바로 다운로드도 할 수 있다.

Binary 파일이기 때문에 압축해제 하기만하면 설치가 완료 된다. 압축을 해제하고 나면 다음과 같은 파일들이 나온다.

보면알겠지만 달랑 실행을 위한 디렉토리와 파일만 존재한다. 이제 하나하나 설정을 해보자.

디렉토리 생성

먼저, 디렉토리를 생성해야 한다. 설정파일을 담을 디렉토리, 로그 파일을 담을 디렉토리, 데이터를 저장할 디렉토리등이다.

디렉토리를 생성하고 나면 위와같은 상태가 된다.

mongod.conf 파일 생성

mongodb 를 운영하기 위해서는 설정파일이 필요하다. 이를 위해서 설정파일을 생성해야 한다. 이는 다음의 주소에서 샘플을 구할 수 있다.

기본적인 내용만 되어 있다. 하지만 mongodb 는 Replica set 를 염두해야하기 때문에 이를 위한 설정을 포함하면 다음과 같다.

위 설정 파일을 실제 서버에서 운영하기에는 문제가 있다. 문제가 될만한 설정들은 다음과 같다.

  • cacheSizeGB – 엔진의 캐쉬 크기이다. 메뉴얼에 따르면 최소 1GB 이상이여야 한다.
  • oplogSizeMB – 리플리케이션을 위한 로그 파일 크기다. 메뉴얼에 따르면 활용가능한 디스크 공간의 5% 다.

실제 서버에서 운영한다면 위 두개의 파라메터를 반드시 운영환경에 맞게 설정을 해야한다. 그리고 운영환경을 위해서 슈퍼유저에 대한 인증을 반드시 설정해야 한다.

슈퍼유저 인증 설정

MongoDB 는 설치를 완료하고 나면 아무런 보안 설정이 없다. 누구나, 아무나 슈퍼유저가 될수 있다. 이를 제안하기 위해서 슈퍼유저에 인증을 설정해야 한다. 이는 서버를 구동하고 나서 해야 한다.

mongod.conf 의 인증과 Replica set 을 해제한 상태에서 해야지만 가능한다. 만일 최초 설치 후에 securiry, replication 부분이 설정이 되어 있다면 위 명령어는 듣지 않는다.

keyFile 생성

keyFile 은 sharded cluster 나 replica set 을 위해서는 keyFile 을 필요로한다. 각 노드간 자신들의 멤머인지 아닌지를 알기 위한 수단이 된다. 이 파일은 각 노드마다 모두 동일해야 한다.

shared cluster, replica set 을 구성한다면 구성을 위한 서버에 이 파일을 각각 배포를 해야 한다.

그리고 다음과 같이 mongod.conf 파일에 keyFile 을 인식시켜준다.

위와 같이 한 후에 서버를 다시 시작한다. (앞에서 서버를 shutdown 시켰놨었다.)

위와같이 서버로 접속하고 정상적으로 인증이 될 경우에 ‘1’ 을 리턴한다. 그리고 명령어를 쳐보면 실행이 되는 것을 알 수 있다.