반응형

 


작성한 날: 2024년 8월 7일
테스트했던 Pi 모델: Pi 4, Pi 5

 

터미널을 열어서 아래 명령(CLI)를 입력한다.

$ sudo  apt install -y fonts-unfonts-core

 

 

Raspbian Desktop 시작 메뉴에서 [ Raspberry Pi Configuration ] 창을 연다.

메뉴를 찾아가는 순서는 아래와 같다.

  [ 시작 메뉴 ]  ->  [ 기본 설정 ]  ->  [ Raspberry Pi Configuration ]  ->  [ Localisation ]

 

[ Locale ] 설정 항목에서 아래와 같이 설정한다.

 - Language : ko (Korean)

 - Character Set : UTF-8

 

[ Raspberry Pi Configuration ] 창을 닫는다.

 

아래와 같이 명령을 실행하여 한글 패키지를 설치한다.

 

$ sudo  apt install -y fcitx fcitx-hangul
... 출력 화면 생략 ...


$ vim  /etc/default/im-config
... 중간 생략 ...
IM_CONFIG_DEFAULT_MODE=fcitx     # <-- "auto" 값을 "fcitx" 값으로 수정 
... 중간 생략 ...


$ reboot

 

 

 

Raspberry Pi를 Reboot하고 나면, [한/영] 전환하는 키 조합을 설정한다. 메뉴를 찾아가는 순서는 아래와 같다.

 [ 시작 메뉴 ]  ->  [ 기본 설정 ]  ->  [ Fcitx 구성 ]  ->  [ 전역 설정 ] 탭 

 

[ 전역 설정 ] 탭에서 [ 트리거 입력기 ]를 설정한다.

나는 [ Shift + Space ] 키 조합과 [ Right Alt ] 키를 설정했다.  (아래아한글 프로그램의 한영 전환 키처럼 설정)

 

 


 

 

 

##
## 채용 관련 글
##
제가 일하고 있는 기업 부설연구소에서 저와 같이 연구/개발할 동료를 찾고 있습니다.
(이곳은 개인 블로그라서 기업 이름은 기재하지 않겠습니다. E-mail로 문의주시면 자세한 정보를 공유하겠습니다.)

근무지 위치:
  서울시 서초구 서초동, 3호선 남부터미널역 근처 (전철역 출구에서 회사 입구까지 도보로 328m)
필요한 지식 (아래 내용 중에서 70% 정도를 미리 알고 있다면 빠르게 협업할 수 있음):
  - 운영체제 (학부 3~4학년 때, 컴퓨터공학 운영체제 과목에서 배운 지식 수준):
    예를 들어, Processor, Process 생성(Fork)/종료, Memory, 동시성, 병렬처리, OS kernel driver  
  - Linux OS에서 IPC 구현이 가능
    예를 들어, MSGQ, SHM, Named PIPE 등 활용하여 Process간 Comm.하는 기능 구현이 가능하면 됨. 
  - Algorithm(C언어, C++ 언어로 구현 가능해야 함)
    예를 들어, Hashtable, B-Tree, Qsort 정도를 C 또는 C++로 구현할 수 있을 정도 
  - Network 패킷 처리 지식(Layer 2 ~ 4, Layer 7)
    예를 들어, DHCP Server/Client의 주요 Feature를 구현할 정도의 능력이 있으면 됨.
  - Netfilter, eBPF 등 (IP packet hooking, ethernet packet 처리, UDP/TCP packet 처리)
  - IETF RFC 문서를 잘 읽고 이해하는 능력 ^^
  # 위에 열거한 내용 외에도 제가 여기 블로그에 적은 내용들이 대부분 업무하면서 관련이 있는 주제를 기록한 것이라서
  # 이 블로그에 있는 내용들을 잘 알고 있다면, 저희 연구소에 와서 연구/개발 업무를 수행함에 있어서 어려움이 없을 겁니다.
회사에서 사용하는 프로그래밍 언어:
  - 프로그래밍 언어: C, C++, Go
    (참고: 아직 연구소 동료들이 Rust를 사용하진 않습니다만, 새 언어로써 Rust를 사용하는 것을 고려하는 중)
근무 시간:
  - 출근: 8~10시 사이에서 자유롭게 선택
  - 퇴근: 8시간 근무 후 퇴근 (오후 5시 ~ 7시 사이)
  - 야근 여부: 거의 없음 (내 경우, 올해 상반기 6개월간 7시 이후에 퇴근한 경우가 2회 있었음)
  - 회식 여부: 자유 (1년에 2회 정도 회식하는데, 본인이 집에 가고 싶으면 회식에 안 감. 왜 참석 안 하는지 묻지도 않음)
외근 여부:
  - 신규 프로젝트 멤버 -> 외근 전혀 하지 않음 (나는 신규 프로젝트만 참여해서 지난 1년 동안 한번도 외근 없었음)
  - 상용 프로젝트 멤버 -> 1년에 5회 미만 정도로 외근
팀 워크샵 여부:
  - 팀 워크샵 자체를 진행하지 않음. (워크샵 참석하는 거 싫어하는 개발자 환영 ^^)
연락처:
  - "sejong.jeonjo@gmail.com"  # 궁금한 점은 이 연락처로 문의주세요.
  - 블로그 비밀 댓글 (제가 하루에 한번씩 댓글 확인하고 있음)
원하는 인재상:
  - 우리 부설연구소는 "긴 호흡으로 프로젝트를 진행"하기 때문에 최소 2년간 한 가지 주제를 꾸준하게 연구/개발할 수 있는 개발자를 원함.
  - 우리 부설연구소는 자주적으로 연구 주제를 찾아서 업무를 하기 때문에 능동적으로 생각하고 행동하는 동료를 원함.
  - 차분하게 연구 주제에 몰입하고, 해법을 찾는 것을 즐기는 사람.
내가 느끼는 우리 연구소의 장점:
  - 갑/을 관계가 없음. (제가 근무하고 있는 연구소는 SI업종이 아니라서 갑/을 회사 개념이 없음)
  - 연구소 자체적으로 연구 주제를 발굴하고 시스템을 개발하기 때문에 개발 일정에 대한 스트레스가 적음
  - 빌딩 전체를 우리 회사가 사용하므로 분위기가 산만하지 않음.
  - 근처에 예술의전당, 우면산 둘레길이 있어서 점심 시간에 산책하기 좋음 ^^
  - 연구소 동료들 매너가 Good (2년간 일하면서 한번도 감정에 스크레치 생기거나 얼굴 붉히며 싸운 적 없음 ^^)

 

반응형
작성일: 2024년 3월 28일

 

Oracle Cloud Infra(OCI)에서 VM instance를 생성하는 것은 Web Console에서 권고값을 따라

"다음", "OK" 같은 버튼만 누르면 쉽게 처리할 수 있다.

 

그런데 이렇게 생성한 VM instance에 SSH 접속하려고 하면, Oracle 매뉴얼처럼 수행했을 때 잘 안 된다.

SSH 접속이 안 되는 원인이 OS Image 마다 조금 달랐다.

 

참고: VM instance에 기본 로그인 계정 설정하기

    Oracle OCI Web Console에서 VM instance에 console 화면에 접근하려면,
    VM instance를 생성하는 시점에 cloud-init 스크립트에 Login 계정을 설정해야 한다. (ID, Password 등)
    아래 블로그에 자세한 방법과 예제가 있다. 예제를 보고 따라하면 된다.

    https://andrewpage.tistory.com/171

 

 

Case: "Oracle Linux 8 Image"를 이용하여 VM Instance를 만든 경우

 방화벽이 활성화되어 있어서 Source IP address가 동일 Subnet이 아닌 경우 SSH 접속이 막고 있다.

아래 명령을 수행해서 방화벽을 끄면 된다.

$ systemctl stop firewalld

$ systemctl disable firwalld

 

초기 작업을 위해 위와 같이 방화벽을 우선 끄고 SSH 접속하고, 어느 정도 Network과 관련한 설정을 변경하고 나면 

다시 firewalld 서비스를 활성화해야 한다. (보안을 위해서 꼭 잊지 말고 해야 한다)

 

 

Case: "Ubuntu 22.04 Image"를 이용하여 VM Instance를 만든 경우

Ubuntu 22.04 VM instance는 다행히 Ubuntu Firewall 서비스가 꺼져 있다.

그런데 Netfilter가 특정 몇개 Port를 제외하고 모두 Reject 하도록 설정되어 있다.

그러므로 Netfilter의 Rule을 조정할 필요가 있다. (아래 명령을 참고)

$ iptables -F

 

그리고 아래와 같이 iptables rule을 다시 구성했다. 

아래 스크립트 중에서 "FIXME" 라고 코멘트 추가한 부분을 참고하면 된다.

$ cat /etc/iptables/rules.v4

# CLOUD_IMG: This file was created/modified by the Cloud Image build process
# iptables configuration for Oracle Cloud Infrastructure

# See the Oracle-Provided Images section in the Oracle Cloud Infrastructure
# documentation for security impact of modifying or removing these rule

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [463:49013]
:InstanceServices - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp --sport 123 -j ACCEPT

## FIXME: Domain Name Server 접근을 허용하는 Rule 추가
-I INPUT -p udp -m udp --dport 53 -j ACCEPT

## FIXME: SSH 접속할 포트를 변경
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2022 -j ACCEPT 

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

... 이하 생략 ...

 

위와 같이 /etc/iptables/rules.v4 를 수정하고, 깔끔하게 VM instance를 Restart하고 SSH를 접속해보자~

잘 접속될 것이다. ^^

 


 

반응형

Ceph storage를 사용하다가 Ceph cluster node 중 일부 Node를 강제로 재기동하다보면

아래와 같은 에러 로그를 Dashboard에서 보게 된다.

 

...

3/6/23 3:00:00 PM [WRN] overall HEALTH_WARN 1 mgr modules have recently crashed

3/6/23 2:50:00 PM [WRN] overall HEALTH_WARN 1 mgr modules have recently crashed

3/6/23 2:40:00 PM [WRN] overall HEALTH_WARN 1 mgr modules have recently crashed

...

 

위 로그가 출력되거나 Dashboard 화면에서 Unhealth warning 정보가 출력될 때,

아래처럼 `ceph crash archive-all` 명령을 수행하면 간단하게 해결된다.

 


$  kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

##
## Ceph tool container 내부로 접속하여, ceph crash 목록을 확인
##

bash-4.4$ ceph crash ls

ID                                                                ENTITY  NEW
2023-02-01T07:02:56.432333Z_6ab1d847-9cbc-449b-9167-8b53e96774d8  mgr.a    *
2023-02-22T05:18:10.263896Z_7321ae9d-7dd8-49c9-a9e0-18ff892e3050  mgr.a    *

##
## ceph crash 상세 정보를 확인 (특이 사항이 있는지 확인하는 차원에서~)
##

bash-4.4$ ceph crash info 2023-02-22T05:18:10.263896Z_7321ae9d-7dd8-49c9-a9e0-18ff892e3050

{
    "backtrace": [
        "  File \"/usr/share/ceph/mgr/nfs/module.py\", line 154, in cluster_ls\n    return available_clusters(self)",
        ... 중간 생략 ...
        "orchestrator._interface.NoOrchestrator: No orchestrator configured (try `ceph orch set backend`)"
    ],
    "ceph_version": "17.2.5",
    "process_name": "ceph-mgr",
    ... 중간 생략 ...
    "utsname_version": "#66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023"
}

##
## 아래 명령을 수행하여 crash 상태를 정리
## 

bash-4.4$ ceph crash archive-all

 

 

확인하는 차원에서 아래 명령으로 한번 더 ceph 상태를 확인한다.

 

bash-4.4$ ceph status
  cluster:
    id:     4e855f4b-085d-45d4-b713-19fc82d1a2a5
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,d (age 11d)
    mgr: b(active, since 11d), standbys: a
    osd: 3 osds: 3 up (since 11d), 3 in (since 4w)

  data:
    pools:   2 pools, 33 pgs
    objects: 3.69k objects, 13 GiB
    usage:   40 GiB used, 710 GiB / 750 GiB avail
    pgs:     33 active+clean

 


 

 

 

 

반응형

Kubernetes 1.23 이상 또는 OCP 4.10 이상을 사용하는 Cluster에서 Pod를 구동하다보면, 

Pod Status가 SMTAlignmentError 에러 상태가 되면서 구동하지 못하는 경우를 만난다.

 

CPU Pinning을 위해 아래처럼 Pod Spec을 설정한 경우에 볼 수 있는 에러이다.

아래 YAML 예시에서 cpu 개수를 5개 설정한 것이 문제를 발생시킨다. (홀수로 설명하는 것이 문제)

kind: Pod
metadata:
  name: myapp
spec:
... 중간 생략 ...
  containers:
    resources:
      limits:
        cpu: 5   ## 이렇게 홀수인 정수를 설정한 것이 에러를 발생시킴.
... 중간 생략 ...

 

관련 자료를 찾아보니, 아래 문서가 가장 설명을 잘 해주고 있다.

 

 

Best practices for avoiding noisy neighbor issues using cpu manager behaves wrt hyper-threading - Red Hat Customer Portal

Best practices for avoiding noisy neighbor issues using cpu manager behaves wrt hyper-threading

access.redhat.com

 

위 문서의 요지는 이렇다.

 

X86_64 CPU는 아래 그림처럼 1개의 물리 Core가 2개의 논리 CPU(Thread)로 구성되어 있고, 
이 2개의 논리 CPU(Thread)가 1개의 L2 Cache를 공유하기 때문에
만약 홀수 개로 CPU를 Pinning(즉, Isolation)하면, L2 Cache의 Hit Ratio가 확 떨어지기 때문에
Core의 처리 속도가 겁나게 떨어진다는 것이다.

즉, L2 Cache 1개를 두고 LCore-0과 LCore-1이 치고 박고 시끄럽게 싸우는 꼴~~~
X86_64 CPU 구조에는 늘상 발생하는 현상으로써, "noisy neighbors"라고 표현한다.

 

쉽게 이해하기 위해 일상 생활과 비유해본다면,

2명의 사람이 한 집에 살면서 요리를 하는데

주방이 1개라서 홍길동은 된장찌개(Job-A)를 만들어 먹고 싶고, 이순신은 김밥(Job-B)을 만들어 먹고 싶다면

홍길동이 된장찌개 요리를 마무리하고 주방(L2 Cache)를 비워줘야, 이순신이 그 주방(L2 Cache)에서 김밥을 만들 수 있는 것과 같다.

여기서 핵심은 "주방(L2 Cache)를 비워줘야" 한다에 있다.

Local Thread가 서로 다른 일을 할 경우, L2 Cache에 담을 내용이 서로 다르기 때문에 L2 Cache 메모리에 있는 데이터를 재사용할 수 없고(즉, Hit Ratio가 떨어지고) 실제 L2 Cache는 Cache 로써의 역할을 못하게 된다.

L2 Cache의 내용 싹~~~ 갈아 엎어버리고 다른 CPU Core가 해야 할 일과 관련된 데이터를 복사해야 하니까~~~

 

이렇기 때문에 비슷한 Job(프로그램, 또는 Process)에 대해서 L2 Cache를 같이 사용하도록 2개씩 쌍으로 할당하는 것이 최고의 성능을 낼 수 있다.

그럴 일은 없겠지만, 만약 논리 쓰레드 3개가 1개의 L2 Cache를 공유하는 CPU 제품이 있다면 3개씩 쌍으로 할당해야 최고의 성능을 낼 수 있다. (이것은 그냥 가정이다)

 

 

 

내 생각에는
처음부터 Intel x86 CPU가 Hyper Threading 구조가 아니였다면, 즉 Logical Core가 L2 Cache Memory를 공유하지 않는 구조였다면 CPU Pinning 설정할 때 짝수로 설정해야 하는 제약도 없었을 것 같다.

 

 

 

 

아래 그림은 Red Hat Web Docs에서 인용한 그림.

CPU Core 개수를 홀수로 설정하여 SMTAlignmentError 발생

 

CPU Core 개수를 짝수로 설정하여 CPU의 Virtual Thread가 L2 Cache 영역을 공유하지 않도록 함

 

 

반응형

첫번째 조치: macOS 업그레이드 (2021년 12월)

 

나는 MacBook을 2대 쓰고 있다.

- MacBook Air M1 2021

- MacBook Pro 2015 Mid

 

둘 다 4K 모니터에 연결해서 사용하고 있는데, 그 구성은 이렇다.

- MacBook Air M1과 4K 모니터를 USB-C(썬더볼트) 케이블로 연결

- MacBook Pro를 썬더볼트 to DP 케이블로 연결

 

이렇게 쓰면 화질이 끝내주게 좋고, 눈이 편하다.

그런데 MacBook Air M1와 4K 모니터를 USB-C(썬더볼트) 케이블로 연결한 구성에서는 4K 모니터가 깜빡이거나

크램쉘 모드에서 깨어날 때 모니터 화면에 "입력 신호 없음"이라고 화면에 보여지면서 모니터가 꺼지는 현상이 있다.

 

내 추측에는 위 2가지 다른 구성에서 가장 영향을 미친 것은 USB-C(썬더볼트) 케이블로 모니터를 연결할 때,

Macbook의 전원을 모니터의 USB-C 포트에서 가져오다보니, 전원 부족으로 발생한 것이 아닌가 싶다.

(그냥 나의  추정일 뿐~)

 

여하튼, 그건 그렇고...

어떤 Macbook 사용자가 Monterey(몬테레이)로 업그레이드하고 나서 외부 모니터의 깜빡이는 현상이 사라졌다고 하여 나도 따라해봤다.

업그레이드하고 3개월이 지났는데, 일주일에 3~5번 정도 깜빡일 정도로 깜빡이는 현상이 많이 줄었다.

Big Sur(빅서)를 사용할 때는 하루에 3~4번 정도 깜빡였으니까, Monterey(몬테레이) 설치한 효과가 확실히 있는 것 같다.

 

 

두번째 조치: USB-C(썬더볼트) 영상 케이블 바꾸기 (2022년 3월)

macOS 업그레이드 이후에도 가끔 모니터가 깜빡여서, 케이블을 바꾸어봤다.

기왕 바꾸는거 비싼 걸로 바꿨다.

제품 광고는 아니고, 그냥 내가 구입했던 것을 공개하면 아래와 같은 제품이다. 

 

 

5개월째 사용하고 있는데, 아직 모니터가 한번도 깜빡이지 않았다.

아주 만족스럽다 :)

 

 

 

결론

 

Macbook에 USB-C(썬더볼트)로 연결한 4K Monitor가 자주 깜빡인다면, Monterey로 업그레이드를 하는 것이 좋다.

USB-C 영상 케이블도 좀더 USB 버전이 높고, 완성도가 높은 영상 케이블로 바꿔야 한다.

 

암튼, 내 모니터의 깜빡이는 문제는 해결 !!!   

Mission Clear !!!  

 

게시물 작성자: sejong.jeonjo@gmail.com

 

 

+ Recent posts