sejong.jeonjo@gmail.com

작성일: 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를 접속해보자~

잘 접속될 것이다. ^^

작성한 날: 2023년 12월 20일
테스트했던 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 ] 키를 설정했다.  (아래아한글 프로그램의 한영 전환 키처럼 설정)

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   ## 이렇게 홀수인 정수를 설정한 것이 에러를 발생시킴.
... 중간 생략 ...

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

위 문서의 요지는 이렇다.

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에서 인용한 그림.

첫번째 조치: 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