iowait 원인파악

Rocky Linux 8.8에 올라가있는 k8s 클러스터에서 iowait가 발생하거나 Load가 치는 경우가 발생했다.

원인 파악하기 위한 해결 내용을 정리한다.

1. iostat 으로 어느 볼륨에서 io를 사용하는지 지켜본다.

    root # iostat -dx -c 1
    Linux 4.18.0-477.10.1.el8_8.x86_64 (dyms-kube-dev2)     2023년 08월 04일     _x86_64_    (16 CPU)
   
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               1.13    0.00    1.51    6.10    0.25   91.01
    Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
    xvda             0.00   12.00      0.00     32.00     0.00     0.00   0.00   0.00    0.00    0.17   0.00     0.00     2.67   0.33   0.40
    xvdb             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
    scd0             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

   ---

   xvda에서 io를 사용하고 있고 iowait 수치가 올라가 있는 것으로 보인다. xvda는 root 볼륨이다. 현재 k8s가 xvdb 에서 동작하고 있기 때문에 컨테이너의 영향이 아니라고 판단했다.

2. iotop으로 프로세스별 io 사용율을 본다.

    Total DISK READ :    0.00 B/s | Total DISK WRITE :     101.20 K/s
    Actual DISK READ:    0.00 B/s | Actual DISK WRITE:      97.46 K/s
        PID  PRIO  USER     DISK READ DISK WRITE>    COMMAND
     759729 be/4 root          0.00 B    408.00 K etcd
        949 be/4 root          0.00 B     16.00 K rsyslogd -n
        895 be/4 root          0.00 B      4.00 K containerd
     777256 be/4 root          0.00 B      0.00 B containerd-shim-runc-v2 -namespace k8s.io -id f4f8ff775ec9e2e752adaacafaa5e11ab09e1f5dcfe686712954fc6559a38276 -address /run/containerd/containerd.sock
     803824 be/4 root          0.00 B      0.00 B [kworker/3:1-mm_percpu_wq]

   ---

   etcd가 io를 지속적으로 사용하고 있는 것으로 보인다. 그렇다는거는 root 영역에서는 거의 io가 발생하고 있지 않다는 것을 의미하는거 같은데.. 무엇이 문제일까??

3. 프로세스 상태 체크

    root # ps -eo state,pid,cmd  | grep D
    S     PID CMD
    D     124 [khugepaged]
    S     856 /usr/sbin/sshd -D 
    S  964068 grep --color=auto D
    D 2607233 ps -efL

   ---

   프로세스의 S(state)를 보면 D인 프로세스를 발견했다.

   프로세스상태 중 D는 중지되지 않고 계속 wait 하고 있는 상태를 말한다. (아래는 ps의 man page이다)

    PROCESS STATE CODES
           Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a process:
                   D    uninterruptible sleep (usually IO)
                   R    running or runnable (on run queue)
                   S    interruptible sleep (waiting for an event to complete)
                   T    stopped by job control signal
                   t    stopped by debugger during the tracing
                   W    paging (not valid since the 2.6.xx kernel)
                   X    dead (should never be seen)
                   Z    defunct ("zombie") process, terminated but not reaped by its parent
           For BSD formats and when the stat keyword is used, additional characters may be displayed:
                   <    high-priority (not nice to other users)
                   N    low-priority (nice to other users)
                   L    has pages locked into memory (for real-time and custom IO)
                   s    is a session leader
                   l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)

   ---

4. 커널에서 사용 중인 PID 124인 khugepaged 프로세스가 계속 D 상태에 있는 것을 확인 하였다.

   lsof도 한번 체크는 해본다.

    root # lsof -p 124
    COMMAND   PID USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
    khugepage 124 root  cwd       DIR  202,6      272  128 /
    khugepage 124 root  rtd       DIR  202,6      272  128 /
    khugepage 124 root  txt   unknown                      /proc/124/exe

   ---

5. hugepaged 프로세스는 THP(Transparent Huge Page)를 사용하기 위한 프로세스인데, 제대로 활용되지 못하고 있는 것으로 보이며, z커널단에서 프로세스가 Hang 걸린 것처럼 보인다. never로 변경 하도록 한다.

    echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
    echo "never" > /sys/kernel/mm/transparent_hugepage/defrag

   ---

6. THP를 비활성화 설정을 하는데 갑자기 서버 세션이 Hang 걸려버림 (해당 프로세스가 원인인 것으로 확실해짐)

7. 다른 세션에서 확인 해보니 -bash 부분에서 또다시 D 상태로 확인 됨

    root # ps -eo state,pid,cmd | grep D
    S     PID CMD
    D     124 [khugepaged]
    S     856 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc -oMACs=hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512 -oGSSAPIKexAlgorithms=gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-,gss-gex-sha1-,gss-group14-sha1- -oKexAlgorithms=curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 -oHostKeyAlgorithms=ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,ssh-rsa,ssh-rsa-cert-v01@openssh.com -oPubkeyAcceptedKeyTypes=ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,ssh-rsa,ssh-rsa-cert-v01@openssh.com -oCASignatureAlgorithms=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-256,rsa-sha2-512,ssh-rsa
    S  748475 kube-apiserver--allow-privileged=true --anonymous-auth=True --apiserver-count=3 --authorization-mode=Node,RBAC --bind-address=0.0.0.0 --client-ca-file=/etc/kubernetes/ssl/ca.crt --default-not-ready-toleration-seconds=300 --default-unreachable-toleration-seconds=300 --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=False --enable-bootstrap-token-auth=true --endpoint-reconciler-type=lease --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem --etcd-certfile=/etc/ssl/etcd/ssl/node-dyms-kube-dev2.pem --etcd-keyfile=/etc/ssl/etcd/ssl/node-dyms-kube-dev2-key.pem --etcd- --event-ttl=1h0m0s --kubelet-client-certificate=/etc/kubernetes/ssl/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/ssl/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalDNS,InternalIP,Hostname,ExternalDNS,ExternalIP --profiling=False --proxy-client-cert-file=/etc/kubernetes/ssl/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/ssl/front-proxy-client.key --request-timeout=1m0s --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/ssl/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.dyms-dev.cluster.local --service-account-key-file=/etc/kubernetes/ssl/sa.pub --service-account-lookup=True --service-account-signing-key-file=/etc/kubernetes/ssl/sa.key --service-cluster-ip-range=10.233.0.0/18 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/etc/kubernetes/ssl/apiserver.crt --tls-private-key-file=/etc/kubernetes/ssl/apiserver.key
    D  870132 -bash

   ---

8. ioswait는 수치가 2배로 뛰었다.

    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               2.08    0.00    1.64   12.04    0.25   83.99
    Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
    xvda             0.00   58.00      0.00    206.50     0.00     0.00   0.00   0.00    0.00    0.24   0.01     0.00     3.56   0.28   1.60
    xvdb             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
    scd0             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

   ---

9. 강제 재부팅 하고 해당 THP를 never 설정을 해주었음

전제

CentOS 7에서 작업한 것입니다.

SSD를 물리적으로 달아 준 곳부터 시작입니다.

확인(작업 전)

lsblk, parted-l명령으로 확인

nvme0n1이 SSD블록 장치로 인식되고 있습니다.

파티션 설정

parted명령으로 실시한다.

여기에서는 전체를 1개의 파티션으로 구분하고 있다

포맷

XFS로 포맷

마운트 준비

다시 기동시 자동으로 마운트 하게/etc/fstab에 이하의 1줄을 추가

마운트 포인트(2칼럼번째)는 적절히 변경하세요.여기에서는/data2로 하고 있습니다.

마운트

확인(작업 후)

설정 → 앱 → 애플리케이션과 기능 → 옵션 기능 →(OpenSSH클라이언트가 없으면)기능의 추가 → OpenSSH클라이언트

비밀 키 등을 두는 폴더는 C:\Users\<USER_NAME>\. ssh

명령 프롬프트나 PowerShell로 ssh<user>@<host>처럼 한다.

사례 10.0.0.1에 admin사용자에서 SSH하는 명령

ssh admin@10.0.0.1

100ms지연을 설정

tc qdisc add dev eth0 root netem delay 100ms

100ms지연을 설정과 random에서+-10ms발생

tc qdisc add dev eth0 root netem delay 100ms 10ms

설정을 확인

tc qdisc show dev eth0

설정을 해제한다

tc qdisc del dev eth0 root

SSH session이 지나도 background에 session이 유지

screen install

yum install screen

환경 변수 설정

vi ~/.screenrc

defscrollback 5000
termcapinfo xterm* ti@:te@
startup_message off
hardstatus on
hardstatus alwayslastline
hardstatus string "%{.bW}%-w%{.rW}%n*%t%{-}%+w %= %c ${USER}@%H"
bindkey -k k1 select 0
bindkey -k k2 select 1
bindkey -k k3 select 2

session작성
사용방법

screen -S 세션 이름

session에서 나온다

exit

session리스트 확인

[root@test ~]# screen -ls
There is a screen on:
    14982.test  (Attached)
1 Socket in /var/run/screen/S-root.

session에 재접속

screen -r [pid].[세션이름]

crontab이 utc시간으로 기동될 경우의 설정 변경

cp /usr/share/zoneinfo/Asia/Seoul /etc/localtime
 
service crond restart
 
service rsyslog restart

EC2에서의 디스크 확장

Linux 디스트리뷰션 혹은 EC2의 가상화 형식에 따라 수행하는 내용이 다르다.

어떤 인스턴스 타입이 어느 가상화 형식에 대응하고 있는지는 → Amazon Linux AMI 인스턴스 타입 매트릭스

시작 중인 인스턴스가 어느 형식인지 알고 싶다면 Management 콘솔에서 인스턴스를 선택하고 Description 탭의 Virtualization 항목을 본다.

공통

볼륨 타입에 standard 이외를 사용하고 있는 경우는 재부팅하지 않고 디스크를 확장할 수 있게 되었습니다.

단, 변경 후 6시간이 지나지 않으면 같은 볼륨은 확장할 수 없다.

Standard 이외

AWS 매니지먼트 콘솔에서

1. 대상 볼륨을 선택하고

2. Modify Volume 변경하고 싶은 크기를 입력

3. in-use -optimizing (xx%) --> in-use - completed (100%)

Standard

AWS 매니지먼트 콘솔에서

1. 서버 셧다운

2. 스냅샷 생성

3. 볼륨을 작성 (정지한 서버와 같은 AZ로 작성할 것!)

4. 현재 볼륨을 디태치

5. 새로 작성한 볼륨을 어태치, 디바이스가 다르니 주의

1. CentOS 6 (paravirtual) /dev/sda
2. CentOS 6 (HVM) /dev/xvda
3. CentOS 7 (HVM) /dev/sda1

6. 서버 부팅

CentOS 7 / AmazonLinux2

CentOS 7의 AMI는 거의 HVM이므로 (적어도 여기에서 기동하고 있는 CentOS 7의 인스턴스는 모두 HVM)

PV냐 HVM이냐의 차이점을 신경 쓸 필요는 없어요

새로운 볼륨을 어태치하여 부팅한 타이밍에 이미 용량이 확장되어 있는 경우가 있습니다.

그런 경우는 아무것도 안해서 문제 없어요. (어떤 조건으로 그렇게 되는지는 미확인입니다. 볼륨 타입 또는 인스턴스 타입이 무엇인가였을 때라고 생각합니다.)

볼륨 어태치까지 완료하고 인스턴스를 기동한 뒤 아래 명령을 실행해 주세요.

2TB 이상의 확장은 반드시 gpt로 변환 후 실행할 것.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/ec2-centos-convert-mbr-to-gpt/

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

GPT로 변환한 후에는 gdisk 설치 필요

yum install gdisk

export LANG="en_US.UTF-8" && growpart /dev/xvda 1
xfs_growfs /

※ 디스크 타입 스탠다드, gp2 모두 확장 가능합니다.

CentOS7계열(t3,m5 최신 인스턴스)

[root ~]# export LANG="en_US.UTF-8" && growpart /dev/nvme0n1 1
CHANGED: partition=1 start=2048 old: size=419428319 end=419430367 new: size=461371359,end=461373407
[root ~]# xfs_growfs /

CentOS6

CentOS 6의 인스턴스에는 PV와 HVM 두 종류가 있으며 그에 따라 작업이 다릅니다.

- PV

AWS 매니지먼트 콘솔에서 볼륨 확장을 실시하고, 이하의 순서를 서버에서 실시한다.

덧붙여 서비스 정지는 발생하지 않는다.

1. 디스크 용량이 확장되었는지 확인한다.

infra-misc-3 # lsblk
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvde 202:64   0  150G  0 disk /

2. 인식용량 확인

infra-misc-3 # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvde       119G   90G   23G  81% /
tmpfs           7.4G     0  7.4G   0% /dev/shm

3. 확장 명령어를 실시한다.

infra-misc-3 # resize2fs /dev/xvde
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/xvde is mounted on /; on-line resizing required
old desc_blocks = 8, new_desc_blocks = 10
Performing an on-line resize of /dev/xvde to 39321600 (4k) blocks.
The filesystem on /dev/xvde is now 39321600 blocks long.

4. 인식용량 확인

infra-misc-3 # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvde       148G   90G   51G  65% /
tmpfs           7.4G     0  7.4G   0% /dev/shm

- HVM

HVM 형식의 가상화의 경우 GPT로 구성되어 있기 때문에 디스크 파티션부터 만지지 않으면 안 됩니다.

서버 재부팅이 필요합니다.

참고. Resize base XenServer 6.0 partition - Server Fault

1. 부팅하고 gdisk 명령어를 실행합니다.

 # gdisk /dev/xvda
GPT fdisk (gdisk) version 0.8.10
 
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
 
Found valid GPT with protective MBR; using GPT.
 
Command (? for help): x
 
Expert command (? for help): e
Relocating backup data structures to the end of the disk
 
Expert command (? for help): m
 
Command (? for help): d
Using 1
 
Command (? for help): n
Partition number (1-128, default 1):
First sector (34-125829086, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-125829086, default = 125829086) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
 
Command (? for help): w
 
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
 
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/xvda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.

2. 서버를 재부팅하여 파일 시스템 리사이즈를 실행한다.

resize2fs /dev/xvda1

Ubuntu 14.0.4

대수는 적지만, 현시점에서 몇개의 Ubuntu 14.04 인스턴스가 존재함

HVM 형식으로 파일 시스템은 EXT4 입니다. parted 명령으로 파티션을 확장한 후 resize2fs를 사용하여 리사이즈합니다.

parted /dev/xvda
 
GNU Parted 2.3
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number  Start   End     Size    Type     File system  Flags
 1      8225kB  16.1GB  16.1GB  primary  ext4         boot
(parted) resizepart 1
Warning: Partition /dev/xvda1 is being used. Are you sure you want to continue?
Yes/No? Yes
End?  [16.1GB]? 42.9GB
(parted) p
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number  Start   End     Size    Type     File system  Flags
 1      8225kB  42.9GB  42.9GB  primary  ext4         boot
(parted) q
Information: You may need to update /etc/fstab.

resize2fs /dev/xvda1

Amazon Linux 1

- 증가된 디스크 크기 확인

＃ df -h
＃ lsblk

- 파티션의 확장

＃ growpart /dev/xvda 1

- 파일 시스템 확장

＃ resize2fs /dev/xvda1
＃ df -h

Alibaba CentOS 7

- 증가된 디스크 크기 확인

＃ df -h
＃ lsblk

-growpart 설치

# yum install cloud-utils-growpart

- 파티션의 확장

＃ growpart /dev/vda 1

- 파일 시스템 확장

＃ resize2fs /dev/vda1
＃ df -h

Windows

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/WindowsGuide/recognize-expanded-volume-windows.html

MBR의 2TB 제한을 우회하기 위해 MBR에서 GPT로 변환하는 방법

https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-centos-convert-mbr-to-gpt/