몽고디비를 서비스에 도입해보려고 테스트 중이다.

여러가지 설치 방법이 있지만, 쿠버네티스 를 활용해서 하려한다.

1. microk8s 를 설치한다.
https://microk8s.io/docs/ 설치방법은 너무 쉽다.
몇몇 서비스를 활성화 시킨다.

microk8s.enable dns storage ingress registry

 

microk8s.kubectl 은 링크걸어두면 편하다.

sudo ln -s microk8s.kubectl /snap/bin/kubectl

or

sudo snap alias microk8s.kubectl kubectl

 

2. 몽고디비 replica set 설정을 사용한다.
https://maruftuhin.com/blog/mongodb-replica-set-on-kubernetes/ 의 설정을 참조

$ openssl rand -base64 741 > ./replica-set-key.txt
$ kubectl create secret generic shared-bootstrap-data \
  --from-file=internal-auth-mongodb-keyfile=./replica-set-key.txt

3. 설정을 사용해 몽고디비를 가동한다.

kubectl apply -f replica-sets/mongodb-rc.yaml

다음과 같은 명령으로 상황을 모니터링 하면 좋다.

kubectl get all -o wide
kubectl get pvc -o wide
kubectl get nodes -o wide

정상적으로 실행되지 않고, pending 으로 시간이 걸린다면, 삭제했다가 다시 실행해본다.

(전체 삭제)
kubectl delete -f replica-sets/mongodb-rc.yaml

(pvc 삭제)
kubectl delete pvc mongodb-persistent-storage-claim-mongod-0

 

정상적이라면 다음처럼 나온다.

kubectl get pods -o wide

NAME       READY   STATUS    RESTARTS   AGE     IP            NODE            
mongod-0   1/1     Running   0          6m45s   10.1.32.109   192.168.77.20   
mongod-1   1/1     Running   0          6m43s   10.1.70.10    kube-mk8s       
mongod-2   1/1     Running   0          6m42s   10.1.32.110   192.168.77.20   
mongod-3   1/1     Running   0          6m41s   10.1.70.11    kube-mk8s       

 

4. mongo 접속하여 replica set 설정한다. (세부 설정은 별도로 정리 예정)

(kube => pod 접속)
kubectl exec -ti mongod-0 -c mongod-container bash

(pod 내에서 mongo console 실행)
mongo

 

해당 replica set 의 몽고 서버에 접속하기 위해 dns 설정이 잘 되었는지 확인해본다.

kubectl apply -f https://k8s.io/examples/admin/dns/busybox.yaml
kubectl exec -ti busybox -- nslookup mongod-0.mongodb-service

설정을 확인해서 정상적으로 pod IP 가 나와야 한다.

이런식으로 나오면 실패.

Server:    127.0.0.53
Address 1: 127.0.0.53

nslookup: can't resolve 'mongod-0.mongodb-service'

아래처럼 나와야 정상.

Server:    10.152.183.10
Address 1: 10.152.183.10 kube-dns.kube-system.svc.cluster.local

Name:      mongod-0.mongodb-service
Address 1: 10.1.32.109 mongod-0.mongodb-service.default.svc.cluster.local

 

 

[추가]

혹시 microk8s 설치시 다음과 같은 메시지나 나오고 진행이 안된다면.

error: too early for operation, device not yet seeded or device model not acknowledged

snapd 를 삭제했다가 다시 설치해본다.

sudo apt purge snapd
sudo apt install snapd
반응형

WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

,

쿠버네티스 를 사용하기 위해 알아보고 있다. (이미 대세가 된지 오래)

단순 개발환경에 적용하기 보다. 실무에 적용하기 위해 연습/학습 단계 부터 단계적으로 해본다.

현재로서는 다음 단계로 진행예정.

1. microk8s (우분투 기반) - 로컬
2. kubeadm , kubespray 등을 이용한 세팅 - (클라우드 or 실서버)
3. helm 등의 패키지(?) 개념의 설치/세팅

아직 용어도 익숙치 않아서 시간이 걸리겠지만, 하나씩 해보면서 목표를 이뤄나간다.

장비도 노트북(그램) , 서버(PC) , 클라우드(D.O , GCP) 등 여러환경에서 해본다.

 

반응형

WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

,

LG 그램을 사용중이다. 윈도우가 기본 설치가 되어 있지만, 개발에 필요해서 우분투를 설치해서 사용하려 한다.

USB 부팅(설치) 디스크를 만들고 부팅을 시도 했는데. 다음과 같은 에러가 나면서 부팅이 되지 않는다.

Failed to open \EFI\BOOT\NULL - Not Found
Faild to load image \EFI\BOOT\NULL : Not Found
start_image() returned Not Found

위와 같은 에러가 나는 경우. USB 설치 디스크의 해당 위치를 보면

grubx64.efi
mmx64.efi
bootx64.efi

등의 파일이 있는데.

난 grubx64.efi 를 복사해서 NULL 파일로 이름을 바꿔줬다. (NULL.efi 가 아닌 그냥 NULL )

다시 재부팅을 해보니 정상적으로 부팅화면으로 넘어갔다.

ps. 여러가지 그램 바이오스 세팅을 바꾸는 방법이 구글링 하면 나오는데.
난 위 방법으로 했다. (secure boot : disable 등 몇가지는 설정했다.)

반응형

WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

,

예전 부터 가상서버를 써왔다. 국내/해외. 본격적으로 써온지도 5년이 넘었다.
(특히 해외업체들의 서비스가 괜찮아 많이 쓰고 있다. https://blog.1day1.org/564 에 소개를 하기도 했다)

국내업체들은 아직 불편한 부분이 많다.
그 사이 AWS 도 국내 서비스도 하고 있다.

이미 AWS 쪽은 대세가 된 kubernetes , 위 업체중 디지털오션 만 공식(?) 지원하고 있다. 서비스로서 지원.

디지털오션 - 쿠버네티스 서비스

벌쳐 / 리노드는 아직 공식 지원하지는 않는다. 별개로 kubernetes 설치해서 사용할 수는 있다.

디지털오션은 서비스로 지원해서, 쿠버네티스 클러스터를 구성하기 쉽도록 했다.(마스터는 별도 비용을 받지 않는 듯 하다)
노드 비용만 계산이 되는 듯 하다.(10$ 플랜부터 사용가능)

런칭한지는 좀 되었지만, 아직 실 사용은 해보지 않아 언급하진 않았다.
조만간 서비스를 쿠버네티스 기반으로 옮길것을 검토중이라 정리 차원에서 글을 쓴다.

도입하면서 나오는 이슈들을 정리할 생각이다.

반응형

WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

,

사용중인 시스템에 HDD 관련 커널에러가 발생하였다.

보통 여러가지 이유가 많지만, 이런 에러가 생기면 그냥 AS 보낸다.

그런데, 이번에는 디스크 관리를 보니 배드섹터 1 개 라고 나온다. 애매하네...
당장 시스템 교체할 하드가 마땅치 않아, AS 보내기전 잠시라도 계속 사용해야 하는 상황.

배드섹터를 기록(?)해서 에러가 발생하지 않도록 하고자 한다.

커널 에러 메세지는 이런식이다. (에러 종류에 따라 , 메시지가 다르다 )

[348303.307873] ata4: EH complete
[348305.814497] ata4.00: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x0
[348305.814503] ata4.00: irq_stat 0x40000008
[348305.814508] ata4.00: failed command: READ FPDMA QUEUED
[348305.814517] ata4.00: cmd 60/08:c0:78:3b:76/00:00:31:01:00/40 tag 24 ncq 4096 in
                         res 41/40:00:78:3b:76/00:00:31:01:00/40 Emask 0x409 (media error) <F>
[348305.814521] ata4.00: status: { DRDY ERR }
[348305.814524] ata4.00: error: { UNC }
[348305.815611] ata4.00: configured for UDMA/133
[348305.815625] sd 3:0:0:0: [sdc] tag#24 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[348305.815630] sd 3:0:0:0: [sdc] tag#24 Sense Key : Medium Error [current] [descriptor] 
[348305.815635] sd 3:0:0:0: [sdc] tag#24 Add. Sense: Unrecovered read error - auto reallocate failed
[348305.815639] sd 3:0:0:0: [sdc] tag#24 CDB: Read(16) 88 00 00 00 00 01 31 76 3b 78 00 00 00 08 00 00
[348305.815643] blk_update_request: I/O error, dev sdc, sector 5124799352

눈에 띄는 부분은 마지막줄.

blk_update_request: I/O error, dev sdc, sector 5124799352

배드 섹터가 생긴 것으로 보인다(다른 에러로 인해 나오는 경우도 있을 수 있을 듯 하다 - 입출력시 에러이니 다양한 원인이 있을 수 있음)


보통의 절차는 badblocks 로 배드섹터 위치를 찾고, fsck 로 배드섹터 표시를 해서 디스크사용시 해당 섹터를 건드리지 않도록 한다.

badblocks -v /dev/sdc1 > badsectors.txt

위 처럼 배드섹터 위치를 찾는다 ( /dev/sdc1 등은 본인의 HDD 명칭으로 쓰면 된다)
오래걸린다 (디스크 크기가 크면 클수록)
검색 범위를 정할 수 있는지 모르겠다. 2930265542

그 다음은 배드섹터를 파일시스템에 기록(?) 한다.

fsck.ext4 -l badsectors.txt  /dev/sdc1

fsck 명령은 본인의 파일시스템에 맞게 적절하게 바꿔준다. (fsck.ext2 , fsck.ext3 등)

끝.

이게 영구적인 해결방법은 아닐 듯 하다. 배드섹터가 계속 생길 수 있으니, AS 보내기 전까지 버텨보자.


추가

badblocks 가 너무 오래 걸린다. (거의 2시간 넘게 했는데, 반도 못했다. 6시간 넘게 걸릴 듯 하다 - 하드디스크 속도에 따라 차이가 있을 듯 함. 해당 HDD 는 7200 rpm )

badblocks -v /dev/sdc1 > badsectors.txt
Checking blocks 0 to 2930265542
Checking for bad blocks (read-only test): ^C

Interrupted at block 1102688832

block 범위를 정해서 다시 해본다. ( 전체가 5860533168 이다. 대략 배드섹터 위치는 5124799352 )

Disk /dev/sdc: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

위 처럼 한 블럭이 512 byte ( badblocks 의 기본값은 1024 - 그래서 0 to 2930265542 으로 나옴)
그런데, 512 로 하면 다음과 같은 메시지가 나온다.

badblocks: 정의한 자료형으로 쓰기엔 너무 큰 값 invalid end block (5860531087): must be 32-bit value

기본값 1024 로 해야겠다. 대신 뒤의 블럭을 반으로 나눠서 범위를 정해야 겠다. ( 2562399676 가 된다)
그러고 보니 기본값을 fsck 쪽과도 맞춰야 할까? 파일시스템마다 다를려나? ( 4096 이 기본값인가? 5124799352 x 0.125 = 640599919 이 된다.)

# badblocks -b 4096 -v /dev/sdc1 640600000 640590000 > badsectors.txt
Checking blocks 640590000 to 640600000
Checking for bad blocks (read-only test): done                                                 
Pass completed, 1 bad blocks found. (1/0/0 errors)
# cat badsectors.4096.txt 
640599663

뒤의 숫자는 640599919 의 대략 범위 위치를 {last block} {first block} ( 끝 / 시작 값을 약간 여유 잡고 지정한다 )
실제 블록 위치는 640599663 로 확인된다.

fsck 를 해보니.

# fsck.ext4 -l badsectors.4096.txt /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
/dev/sdc1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 110625949: 640599663
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 1 inodes containing multiply-claimed blocks.)

File { ================== 에러난 파일 =================== } (inode #110625949, mod time Wed Jun 26 16:35:07 2019) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
    <The bad blocks inode> (inode #1, mod time Sat Jul 27 21:54:33 2019)
Clone multiply-claimed blocks<y>? yes
Error reading block 640599663 (Attempt to read block from filesystem resulted in short read).  에러 무시<y>? yes
강제로 덮어쓰기<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? no
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23517, counted=23516).
Fix<y>? yes
Free blocks count wrong for group #19549 (65535, counted=0).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdc1: ********** WARNING: Filesystem still has errors **********

/dev/sdc1: 36792/183148544 files (0.0% non-contiguous), 632810807/732566385 blocks

위에서 Clone multiply-claimed blocks? yes => 이 부분을 그냥 n 로 건너뛰는게 좋다. 어차피 에러로 복사(clone) 실패 하는 듯 함.

일단 위와 같이 조치했는데, 잘 된 것인지는 좀더 체크해봐야 겠다. ( 특히 block 의 위치가 맞게 처리된 것인지... )

반응형

WRITTEN BY
1day1
하루하루 즐거운일 하나씩, 행복한일 하나씩 만들어 가요.

,