N5105 (NUC 11,NUC11ATKC4) 조립 및 설치하기
안녕하세요? 도정진입니다.
최근에 아마존에 11세대 N5105 NUC가 싸게 나와 구매를 하게 되었습니다.
1. 현 상황 부족 체감
실은 J5005 로도 부족함은 없었지만, 결국에 구매를 하게된 계기가... 메모리가 너무 부족해서 그랬네요.
8기가 램에 여러가지를 구동하다 보니, SWAP 메모리를 운영함에 있어서 아래의 기법도 사용해 보았지만, 실은 .. 물리 메모리가 큰게 중요했습니다.
https://blog.djjproject.com/818
물론 J5005에 램을 업글하면 되지 않는지? 에 대한 의문을 품으실 수 있습니다만, 공식 사양이 MAX 8GB 제품으로 조금 애매한 점이 있었습니다.
https://ark.intel.com/content/www/kr/ko/ark/products/126137/intel-nuc-kit-nuc7pjyh.html
2. 구매 욕구 및 주문 배송
물론 양면? 램인지 특수 램을 사용하여 32기가까지 인식시키신 분이 계시기는 한데요. 그런 리스크를 짊어지기가 싫었습니다. 그래서 그냥 새로운 NUC를 알아보다가 적당한 가격의 11세대 N5105 제품을 보게 됩니다.
당시 가격은 아래와 같았고, 지금은 조금 오른 가격이네요.
직배로 주문했고, 위의 금액 이외에는 추가 금액이 발생하지 않았습니다.
그리고 SSD와 메모리를 주문해야하는데 SSD를 사타를 재활용 하려고 하였으나, M.2만 사용이 가능하여 SSD도 같이 주문하게 됩니다.
메모리 용량은 16기가 2개를 주문했습니다.
이 배송건은 델라웨어 배대지를 사용하였고, 직배도 되지 않는 물건이라 몰테일을 사용하여 받았습니다.
이런 짜잘한 부품들은 몰테일에 합배송을 시키는게 괜찮은 것 같습니다.
몰테일의 경우 2월 초경에 도착했고, 1월 28일에 주문하여 2월 8일 정도에 제가 만질 수 있었습니다.
몰테일 배송이 조금 많이 느려졌네요.
델라웨어에 배송하여 NJ로 이동하고 이런 시간이 많이 소요되었지만, 국내로 들어오는 송장이 나오고 나서는 이틀만에 도착하였습니다.
3. 성능 차이
J5005 와 N5105는 아래 passmark 로 간단하게 확인해보면 조금 성능 차이가 나긴합니다만, 크게 체감될 정도는 아니네요.
결과적으로는 본래 사용하는 환경에서 NUC만 바뀌었을 때, 전력차이는 거의 없네요.
4. 개봉기 및 조립
사진 나갑니다.
일단 가격이 저렴한 제품이라 그런지 박스는 일반적으로 보는 NUC 박스가 아니네요.
마이크론 16기가 2개 / 저렴이 1TB SSD 부속까지 준비되었습니다.
특히 킹스톤 NV2 SSD의 경우 DRAM 없기 때문에 성능이 조금 떨어지지만, HDD 사용하는 것 보다는 빠르기 때문에 크게 성능에 민감하지 않으시면 이 제품을 매우 추천하는 편입니다.
가격도 50불 정도로 매우 저렴합니다.
NUC의 경우 상단에 파워서플라이와 M.2 나사 몇개 이렇게 구성되어 있고 윗 서랍을 들어내면 아래에 NUC가 있습니다.
사이즈는 기존 J5005 NUC 보다 넓으며 높이는 낮습니다.
2.5인치 SATA 슬롯이 없어서 높이가 조금 낮네요.
하단 케이스를 분해해서 열어보시면 DDR 넣는 곳과 M.2 NVME 자리 그리고 그 밑에 M.2 WIFI 가 있습니다.
어쩌면 M.2 와이파이를 들어내고 아래와 같이 외장 GPU를 연결해볼 수 도 있겠습니다.
https://blog.djjproject.com/630
와이파이 모듈은 일반 보급 모델로써 9462NGW 모델이 들어있고 AX200 AX201 등의 조금 안정적인 칩셋을 넣어주지 않은것에 조금 아쉬움이 있네요.
아래와 같이 장착이 완료되었습니다.
후면 포트에 DP / HDMI / USB2.0 2개 / USB3.0 2개 / RJ45 존재하며, 이더넷은 R8169 입니다.
바이오스 화면입니다. 여느때 NUC 와 동일하게 바이오스 디자인은 동일하네요.
32GB 인식됨을 알 수 있고 N15105 임을 알 수 있습니다.
5. Proxmox 설치
이제는 저는 proxmox 만 설치하기로 했습니다.
https://blog.djjproject.com/714
https://blog.djjproject.com/740
그래서 바로 Proxmox 설치했습니다.
일단 Ventoy 로 부팅하여 설치를 진행했습니다.
위와 같이 설치 끝나자 마자 바로 신발장에 배치 했습니다.
6. 새로운 시스템 및 이전 시스템에서의 이전
일단 새로운 시스템에 SSD 부터 확장을 진행했습니다.
이전에 아래 글 처럼 동일하게 진행하시면 되며, 구성이 아래와 같습니다.
https://blog.djjproject.com/723
| boot : fat 파티션의 efi 파티션 pve : 물리 파티션의 2번째 파티션의 볼륨 그룹 root : 100GB 정도의 proxmox rootfs data : 나머지 공간의 proxmox userdata logical 볼륨 |
이런 구성에서 저는 SSD나 HDD를 LVM 으로 구성하는 것을 그렇게 좋아하지 않는 편이라, 하나의 파티션으로 합치겠습니다.
일단은 pve webui 에 잡혀있는 /dev/pve/data lv볼륨을 free 해주고 아래 명령어로 lv 를 지웁니다.
| root@debian:~# lvremove /dev/pve/data Do you really want to remove active logical volume pve/data? [y/n]: y Logical volume "data" successfully removed # lv 물리 공간 확장 root@debian:~# lvextend -l +100%FREE /dev/pve/root Size of logical volume pve/root changed from 96.00 GiB (24576 extents) to <923.01 GiB (236290 extents). Logical volume pve/root successfully resized. # /dev/pve/root 확장 root@debian:~# resize2fs -p /dev/pve/root resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/pve/root is mounted on /; on-line resizing required old_desc_blocks = 12, new_desc_blocks = 116 The filesystem on /dev/pve/root is now 241960960 (4k) blocks long. root@debian:~# sync # 변경된 용량을 확인합니다. root@debian:~# df -h Filesystem Size Used Avail Use% Mounted on udev 16G 0 16G 0% /dev tmpfs 3.2G 1.3M 3.2G 1% /run /dev/mapper/pve-root 908G 2.5G 868G 1% / tmpfs 16G 46M 16G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/nvme0n1p2 511M 336K 511M 1% /boot/efi /dev/fuse 128M 16K 128M 1% /etc/pve tmpfs 3.2G 0 3.2G 0% /run/user/0 |
그리고 docker 이미지를 이전 시스템에서 스크립트로 일괄 백업합니다.
아래 스크립트는 docker ps -a 해서 나오는 container nickname 을 가지고 docker stop 후 export 하는 명령을 for 문 돌리는 것으로 큰 기교라는 것이 없습니다.
| root@debian:/opt/docker-backup# cat backup.sh #!/bin/bash CONTAINERS="$(docker ps --format '{{.Names}}')" echo "$CONTAINERS" | while read LIST do echo "$LIST" docker stop $LIST docker export $LIST > $LIST.container docker start $LIST done |
실행중에는 아래와 같이 docker 명령을 친 결과가 나오게 됩니다.
| root@debian:/opt/docker-backup# ./backup.sh hass hass hass plex plex plex zw2m zw2m zw2m |
백업된 결과물은 아래와 같습니다.
| root@debian:/opt/docker-backup# ls backup.sh hass.container nginx-proxy.container xteve.container zw2m.container mqtt_wan.container plex.container transmission.container z2m.container |
| root@debian:/opt/docker-backup# ls -lih total 6.0G 2108849 -rwxr-xr-x 1 root root 211 Feb 14 20:52 backup.sh 2108767 -rw-r--r-- 1 root root 1.5G Feb 14 20:53 hass.container 2108929 -rw-r--r-- 1 root root 12M Feb 14 20:55 mqtt_wan.container 2108847 -rw-r--r-- 1 root root 785M Feb 14 20:54 nginx-proxy.container 2108602 -rw-r--r-- 1 root root 632M Feb 14 20:54 plex.container 2108921 -rw-r--r-- 1 root root 90M Feb 14 20:55 transmission.container 2108926 -rw-r--r-- 1 root root 590M Feb 14 20:54 xteve.container 2108927 -rw-r--r-- 1 root root 297M Feb 14 20:55 z2m.container 2108509 -rw-r--r-- 1 root root 631M Feb 14 20:54 zw2m.container |
새로운 시스템에서 아래 스크립트로 복원을 하면 됩니다.
| root@debian:/opt/docker-backup# cat restore.sh #!/bin/bash CONTAINERS="$(ls -1 | grep container)" echo "$CONTAINERS" | while read LIST do echo "$LIST" docker import $LIST done |
로그는 아래와 같습니다.
| root@debian:/opt/docker-backup# ./restore.sh buildx_buildkit_multiarch-builder0.container sha256:11152cd75d1554f34c69eadfb2da702cb0f6ea363a27c20af897c0441a8fd50f guacd.container sha256:b5615fc7019f97072a4eda9138addd1fad586444f430f21e944474bc7faa4128 guacd_mysql.container sha256:09aa574f3831238a9741a50fc6f72027ca61c27f79fa150a640de17675ff16d6 guacd_web.container sha256:dec5cc4ff3a3f745e01f0e6c01b4b33b0050d1b6f3f212a89907c5dc75e8612b hass.container |
이렇게 이미지들을 옮기고 난 후, 컨테이너를 새로 하나 하나 생성하면 됩니다.
실은 이런 경우를 대비하여 script 로 아래와 같이 만들어 둔게 많은 도움이 되네요.
어쩌면 어차피 여러개 컨테이너를 쓰는 것도 아니고 한 상태에서는 yaml 로 작성하는게 오히려 효율 성이 떨어질 수도 있겠습니다만, 요즘 container 들은 2개 3개 연동하여 운영되는 것이 조금 있어서... 다음에는 docker-compose 로 구성을 해두어야겠습니다.
| root@debian:/backup/opt/xteve# cat create.sh #!/bin/bash docker run -it -d --name=xteve --network=host --restart=unless-stopped -v /opt/xteve:/home/xteve/conf dnsforge/xteve:latest |
기타 나머지 시스템들은 수동으로 설치하여 이전을 마쳤습니다.
7. 넓은 마음의 포근함
이전 시스템에서 zram 을 설정하여 얼마동안은 잘 사용중이였습니다만, 아래와 같은 상황을 한번 만나 oom 이 나고 나서는 도저히 스트레스 받아서..
따로 당시에 로그를 수집하진 않았지만 아래 그래프처럼 중간에 oom 으로 panic 이 발생하여 재부팅된 상황이 자주 생겼습니다.
물론 ssd 에 물리 swap 을 하면 되지 않는지? 이런 생각을 하실 수도 있는데요.
스왑이 중요한게 swap 을 하게 되면 swap in 과 swap out 에 시간이 너무 오래 걸려, http timeout 이 걸리거나 이러한 증상이 너무 많이 생겼습니다.
특히, esphome http websocket 이 끊어지는 경우가 너무 많았습니다.
이번에 N5105로 이전하고는 마음이 너무 편안해졌네요.
물리 disk 로의 스왑 제거하였고 절반 정도만 zram 설정하여 운영하고 있습니다.
아래 이미지는 HomeAssistant 를 이전하고 부팅하고 나서의 그래프입니다.
현재 모든 서비스를 이전하고 아래와 같이 안정적으로 운영중에 있습니다.
8. 마치면서
항상 지름은 옳다. 현재 상황을 개선하는 것은 튜닝도 있지만 돈을 쓰는 것도 빠른 마음 회복에 도움이 되는 것? 같습니다.
이만 마치겠습니다.
감사합니다.