abc94 님의 블로그

디스크 관리(1)

abc94 — Mon, 8 Jul 2024 21:30:45 +0900

안녕하세요

이번 시간에는 리눅스 시스템 내, 디스크가 어떻게 관리되는지 공부하는 시간을 갖고자 합니다.

리눅스를 운영 하다보면 디스크, 파일시스템 과 같은 용어들을 많이 접할 수 있는데요

볼륨, 파일시스템, 마운트, 블록 I/O 등 대충은 무얼 뜻하는지 알지만 정확하게 설명하기는 난해한 부분이 있습니다.

리눅스 커널이 어떻게 핸들링 하는지 확인해보면서 정확한 개념을 얻고자 하는게 이번 섹션의 목표입니다.

피드백은 언제나 환영입니다.

1. 물리 디스크

2. 파일시스템

3. 파티셔닝

4. 볼륨

1. 물리디스크

물리 디스크란, SSD,HDD 와 같은 하드 디스크를 의미합니다.

이러한, 디스크를 CPU가 인식하기 위해선 인터페이스 컨트롤러가 필요합니다.

인터페이스 컨트롤러란, 하드웨어와 소프트웨어의 결합체 입니다.

하드웨어 : HBA 카드 or 마더보드 컨트롤러 칩셋

소프트웨어 : 내장 펌웨어

SAS,SATA,NVME 중 어떠한 인터페이스를 사용할 지 여부는 하드웨어 인터페이스(HBA, 칩셋)에 의해 결정됩니다.

디바이스 드라이버는 OS의 커널에 로드되며, 드라이버 모듈을 통해 어떠한 장치를 인식하는지 알 수 있습니다.

외장 스토리지(SAN)의 경우, HBA 카드에 내장된 인터페이스 컨트롤러를 통해 CPU가 볼륨을 인식합니다.

로컬 디스크의 경우, 마더보드에 내장된 인터페이스 컨트롤러를 통해 CPU가 디스크를 인식할 수 있습니다.

특성	SAS	SATA	NVME
속도	12 Gbps	6 Gbps	32 Gbps
Latency	낮음	다소 높음	매우 낮음
사례	데이터 센터	PC	고성능 스토리지
비용	높음	낮음	높음

그러면, 신규 디스크를 OS에 인식하기 위해선 어떠한 과정이 필요할까요??

2. 파일시스템

해당 디스크를 어떠한 방법으로 OS가 읽기 / 쓰기를 할지 결정해줘야 합니다.

이를 "파일시스템으로 변환한다" 라고 표현 합니다.

파일시스템이란, RAW 디스크나 파티션을 OS 가 데이터를 저장하고 읽을 수 있도록 포맷한 상태 입니다.

파일 시스템을 생성하고 마운트하는 과정을 통해서 디스크를 사용합니다.

3. 파티셔닝

RAW 디스크를 그대로 사용하지 않고 디스크를 왜 논리적으로 나누어서 사용하는 것일까요?

가장 강력한 이유는 디스크 공간을 용도에 맞게 분리하여 사용할 수 있기 때문입니다.

각 파티션은 논리적으로 분리되어, 독립적으로 사용되며 서로의 파티션에 영향을 미치지 않습니다.

Disk /dev/xvda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D209C89E-EA5E-4FBD-B161-B461CCE297E0

Device       Start      End  Sectors  Size Type
/dev/xvda1    2048     4095     2048    1M BIOS boot
/dev/xvda2    4096   413695   409600  200M EFI System
/dev/xvda3  413696  2510847  2097152    1G Linux extended boot
/dev/xvda4 2510848 20971486 18460639  8.8G Linux filesystem

4. 논리 볼륨

데이터를 저장할 수 있는 논리적인 저장 공간을 의미 합니다.

파티션이랑 무슨 차이점이 있으며 왜 사용하는 것일까요?

결론부터 말씀드리며, 디스크 공간을 훨씬 유연하게 관리할 수 있습니다.

먼저, pvcreate, vgcreate, lvcreate 와 같은 명령어를 통해서 논리 볼륨을 생성할 수 있습니다.

하나의 파티션으로 파일시스템을 생성하게 되면, resize 하는데 매우 복잡합니다.

하지만, LVM을 통해 파일시스템 생성시, resize가 매우 간단하여, 필요에 따라 용량을 쉽게 조정할 수 있습니다.

sudo lvextend -L +50G /dev/myvg/mylv
sudo resize2fs /dev/myvg/mylv

이번 시간에는 간단하게 디스크 관련 개념을 익혀보는 시간을 가졌습니다.

두번째 챕터에서 뵙겠습니다.

오늘도 감사합니다.

가상메모리에 관하여(3)

abc94 — Sun, 7 Jul 2024 18:09:15 +0900

안녕하세요~

저번 시간에 가상 메모리의 생성 과정을 코드로 확인해보는 시간을 가졌습니다.

하지만, 실제 프로세스 구동에 필요한 코드나 데이터는 물리 메모리(RAM) 에 존재하는데요.

따라서, 오늘 시간에는 CPU가 어떻게 물리메모리를 접근할 수 있는지에 대해 알아보겠습니다.

0. 메모리 액세스

1. 페이지 테이블

2. 페이지 Fault

0. 메모리 액세스

메모리 액세스란, CPU 가 가상 메모리 주소를 사용하여 물리 메모리에 저장된 데이터나 명령어를 R/W 하는 과정입니다.

이때, CPU는 물리 메모리 주소에 접근하기 위 프로세스의 페이지 테이블을 참조합니다.

메모리 액세스의 순서는 다음과 같습니다.

(1) Fetch

CPU가 프로그램 카운터(PC)로 부터 다음에 실행되어야 할 instruction 을 가져 옵니다.

(2) Decode

해당 명령어를 해석하여 물리 메모리 r/w 여부를 판단합니다.

(3) Execute

명령어를 실행하는 과정인데, 메모리 접근이 필요할 시 CPU는 MMU(Memory Managemnet Unit) 을 통해 페이지 테이블을 조회하고 가상주소를 물리 주소로 변환합니다.

이후, 변환된 물리 주소를 사용하여 물리 메모리에 데이터를 읽고 씁니다.

그러면, objdump 를 통해서 해당 과정을 빠르게 해석해봅시다.

[root@ip-10-0-142-220 ~]# whatis objdump
objdump (1)          - display information from object files

root@ip-10-0-142-220 test]# objdump -d hello

000000000401136 <main>:
  401136:       55                      push   %rbp
  401137:       48 89 e5                mov    %rsp,%rbp
  40113a:       48 83 ec 10             sub    $0x10,%rsp
  40113e:       c7 45 fc 01 00 00 00    movl   $0x1,-0x4(%rbp)
  401145:       8b 45 fc                mov    -0x4(%rbp),%eax
  401148:       89 c6                   mov    %eax,%esi
  40114a:       bf 10 20 40 00          mov    $0x402010,%edi
  40114f:       b8 00 00 00 00          mov    $0x0,%eax

저희가, 참고해야 될 부분은 mov1 instruction 입니다.

movl $0x1, -0x4(%rbp) 명령어는 '1' 을 메모리 위치에 저장하는 명령어 입니다.

Execute 시, 메모리 액세스가 발생하는데 CPU는 %rbp 레지스터와 해당 코드의 offset 을 조합하여 가상 메모리 주소를 얻습니다.

이후, MMU 를 통해 페이지테이블 조회하여 변환된 물리주소에 '1' 을 저장합니다.

1. 페이지 테이블

CPU가 실제 메모리에 있는 데이터를 읽거나 쓰기 위해서 물리 메모리 접근(Memory Access) 과정이 필요합니다.

이때 OS 는 프로세스별 페이지 테이블을 생성하고, 이 페이지 테이블을 통해 가상 주소와 물리 주소간의 매핑이 이뤄집니다. CPU 는 페이지 테이블을 참조하여 물리 메모리에 접근합니다.

페이지 테이블

실제 코드를 통해 페이지 테이블을 이해해보겠습니다.

#include <stdio.h>
#include <unistd.h>

int main() {
  int a = 1;

  printf("Hello, World! %d\n", a);
  printf("Address of a: %p\n", (void*)&a);

  while (1){
    sleep(1);
  }

  return 0;
}

gcc 컴파일러를 통해 hello.c -> hello (ELF) 파일로 변환합니다.

hello 코드 내, 변수 a를 선언하였고, 이는 가상 메모리 내 스택 주소공간에 할당됩니다.

실제 변수 a가 stack 공간에 할당 되었는지 확인해보겠습니다.

[root@ip-10-0-142-220 test]# ./hello
Hello, World! 1
Address of a: 0x7ffc4f649e9c

[root@ip-10-0-142-220 ~]# pidof hello
35202
[root@ip-10-0-142-220 ~]# cat /proc/35202/maps
00400000-00401000 r--p 00000000 ca:04 9098393                            /root/test/hello
00401000-00402000 r-xp 00001000 ca:04 9098393                            /root/test/hello
00402000-00403000 r--p 00002000 ca:04 9098393                            /root/test/hello
00403000-00404000 r--p 00002000 ca:04 9098393                            /root/test/hello
00404000-00405000 rw-p 00003000 ca:04 9098393                            /root/test/hello
007ff000-00820000 rw-p 00000000 00:00 0                                  [heap]
7fed57c00000-7fed57c28000 r--p 00000000 ca:04 25540836                   /usr/lib64/libc.so.6
7fed57c28000-7fed57d9d000 r-xp 00028000 ca:04 25540836                   /usr/lib64/libc.so.6
7fed57d9d000-7fed57df5000 r--p 0019d000 ca:04 25540836                   /usr/lib64/libc.so.6
7fed57df5000-7fed57df6000 ---p 001f5000 ca:04 25540836                   /usr/lib64/libc.so.6
7fed57df6000-7fed57dfa000 r--p 001f5000 ca:04 25540836                   /usr/lib64/libc.so.6
7fed57dfa000-7fed57dfc000 rw-p 001f9000 ca:04 25540836                   /usr/lib64/libc.so.6
7fed57dfc000-7fed57e09000 rw-p 00000000 00:00 0
7fed57f56000-7fed57f5a000 rw-p 00000000 00:00 0
7fed57f5e000-7fed57f60000 r--p 00000000 ca:04 25540832                   /usr/lib64/ld-linux-x86-64.so.2
7fed57f60000-7fed57f86000 r-xp 00002000 ca:04 25540832                   /usr/lib64/ld-linux-x86-64.so.2
7fed57f86000-7fed57f91000 r--p 00028000 ca:04 25540832                   /usr/lib64/ld-linux-x86-64.so.2
7fed57f92000-7fed57f94000 r--p 00033000 ca:04 25540832                   /usr/lib64/ld-linux-x86-64.so.2
7fed57f94000-7fed57f96000 rw-p 00035000 ca:04 25540832                   /usr/lib64/ld-linux-x86-64.so.2
7ffc4f62a000-7ffc4f64b000 rw-p 00000000 00:00 0                          [stack]
7ffc4f6d2000-7ffc4f6d6000 r--p 00000000 00:00 0                          [vvar]
7ffc4f6d6000-7ffc4f6d8000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

실제 수행되고 있는 hello 프로세스의 맵을 확인하기 위해, /proc/[pid]/maps 를 확인합니다.

변수 a 의 가상주소가 stack 섹션에 위치 함을 알 수 있습니다.

그러면, 해당 가상주소가 어떠한 물리 주소에 매핑되어 메모리 액세스를 진행하는지 알아보겠습니다.

/proc/[pid]/pagemap 파일 시스템을 통해 알 수 있는데, pagemap 의 경우 바이너리 파일이라 신규 프로그램을 작성해야 합니다.

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <inttypes.h>

#define PAGEMAP_LENGTH 8

uint64_t get_pagemap_entry(uint64_t virt_addr) {
    FILE *f;
    uint64_t file_offset, pagemap_entry;
    ssize_t bytes_read;

    // Open the pagemap file for the current process
    f = fopen("/proc/self/pagemap", "rb");

    // Calculate the offset in the pagemap file
    file_offset = (virt_addr / getpagesize()) * PAGEMAP_LENGTH;

    // Read the entry from the pagemap file
    bytes_read = fread(&pagemap_entry, 1, PAGEMAP_LENGTH, f);

    fclose(f);

    return pagemap_entry;
}

int main() {
    int a = 1;
    uint64_t virt_addr = (uint64_t)&a;
    uint64_t pagemap_entry = get_pagemap_entry(virt_addr);

    // Extract the physical page number (PPN)
    uint64_t phys_addr = (pagemap_entry & 0x7FFFFFFFFFFFFF) * getpagesize();
    
    printf("Virtual address: 0x%" PRIx64 "\n", virt_addr);
    printf("Physical address: 0x%" PRIx64 "\n", phys_addr);

    return 0;
}

[root@ip-10-0-142-220 test]# ./hello_pagemap
Virtual address: 0x7ffc4fdc6254
Physical address: 0x1b02f000

실제 물리 메모리 접근 시, 컴파일된 프로그램의 offset 과 커널이 알고 있는 가상 메모리 주소를 결합하여 페이지 테이블을 생성합니다.

해당 코드를 통해, 대략적인 페이지 테이블을 그려보면 아래와 같습니다.

VA	PA
0x7ffc4dc6254	0x1b02f000

2. 페이지 Fault

Page Fault, ?

1. CPU 가 페이지 테이블을 참조하는데, 가상 주소와 물리 메모리 주소가 매핑되지 않은 상태.

VA	PA
0x7ffc4dc6254	?

2. 페이지 테이블에 매핑 되어 있으나, SWAP OUT 되어 해당 페이지가 디스크에 있는 경우.

swapping

이러한 경우, OS 는 어떠한 역할을 수행하게 될까요?

Page Fault 처리 과정

1. 페이지 폴트 핸들러 실행

2. OS 가 페이지 테이블을 검사 합니다.

3. 페이지 로드

- 페이지 스왑 아웃의 경우, 스왑 영역에서 해당 페이지를 찾아 물리 메모리에 로드합니다.

- 신규 페이지의 경우, 물리 메모리에서 빈 페이지를 찾아 페이지 테이블을 업데이트 합니다.

4. 프로세스 재개

오늘도 방문해주셔셔 감사합니다.

피드백은 언제나 환영입니다.

가상 메모리에 관하여(2)

abc94 — Sat, 15 Jun 2024 20:03:43 +0900

안녕하세요

저번 시간에 이어, 가상 메모리에 대한 이야기를 본격적으로 시작하고자 합니다.

0. 가상 메모리는 무엇일까?

1. 가상 메모리의 작동 원리

0. 가상 메모리는 무엇일까?

가상 메모리(Virtual Memory), 즉 가상의 메모리입니다.

메모리는 CPU와 함께 프로세스 수행 시 중요한 역할을 담당하고 있습니다. CPU는 특정 프로그램 내, 함수를 무수히 실행한다면, 메모리는 해당 함수(코드)가 저장될 수 있는 공간을 제공합니다.

가상 메모리는 OS에서 실제 메모리 보다 큰 주소 공간을 프로세스에게 제공하기 위해 고안된 메모리 관리 기법입니다.

하지만, "그래서 도대체 뭐야?"라는 의구심이 계속 생깁니다.

우리가 윈도우즈 PC에서 Excel.exe 프로그램을 더블 클릭하면 엑셀 프로그램이 실행됩니다.

그러면, 엑셀의 여러 기능들이 실행되기 위해선 CPU와 메모리가 필요하겠죠?

여기서 Excel 프로세스만의 함수가 저장되는 공간을 가상 메모리로 이해해 주시면 됩니다.

엑셀 프로그램 이외에, 크롬을 열었다고 생각해 봅시다. 그러면, 크롬 작업을 위한 별도의 가상메모리가 하나 더 할당됩니다.

즉, 프로세스의 개별 작업 공간입니다.

가상 메모리가 없으면 물리 메모리(RAM)를 크롬이나 엑셀 등이 같이 공유했겠죠?

이러한 가상 메모리는 OS 커널이 생성/관리합니다.

가상 메모리 구조

https://velog.io/@tjdtn0219/%EC%BB%B4%ED%93%A8%ED%84%B0-%EA%B5%AC%EC%A1%B0-%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8

위 사진을 통해 알 수 있듯이, 프로세스마다 개별 작업 공간이 존재하는 것을 볼 수 있습니다.

1. 가상 메모리의 작동 원리

그러면 가상 메모리는 어떻게 작동되는 것일까요?

먼저, 프로그램의 실행과정, 즉 프로세스 생성 과정을 이해해야 합니다.

처음에 실행되어야 할 파일, A.exe 가 SSD에 적재되어 있습니다.

1. User가 A.exe 실행 요청을 하면 A.exe 파일이 물리 메모리(RAM)에 로드됩니다.

2. 커널의 시스템 콜(execve)을 통해, A.exe 프로그램 경로와 실행에 필요한 인자를 커널에게 전달합니다.

3. 커널은 Process A를 생성합니다.

4. 커널은 Process A를 위한 가상 메모리 공간(Virtual Memory A)을 할당합니다.

5. execve 시스템 콜로부터 전달받은 프로그램 정보를 가상 메모리 공간에 매핑합니다.

직접, 프로그램을 실행하고 가상 메모리 매핑 과정을 살펴보겠습니다.

간단히, hello world를 print 하는 프로그램(ELF)을 만들었습니다.

#include <stdio.h>

int main() {
  printf("Hello, World!\n");
  return 0;
}

[root@ip-10-0-131-237 test]# ls -al
total 28
drwxr-xr-x.  2 root root    34 Jun 15 18:44 .
dr-xr-x---. 12 root root  4096 Jun 15 18:44 ..
-rwxr-xr-x.  1 root root 17504 Jun 15 18:44 hello
-rw-r--r--.  1 root root    75 Jun 15 18:44 hello.c
[root@ip-10-0-131-237 test]# file hello
hello: ELF 64-bit LSB executable, x86-64

1. hello라는 프로그램을 실행해 보고, strace를 활용하여 시스템 호출을 추적하자.

strace -o strace.hello ./hello

[root@ip-10-0-131-237 test]# cat strace.hello
execve("./hello", ["./hello"], 0x7ffc237213e0 /* 37 vars */) = 0
brk(NULL)                               = 0x14df000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffe417925e0) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=30887, ...}) = 0
mmap(NULL, 30887, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe4b6531000
close(3)                                = 0

실제, execve 시스템 콜을 호출하는 것을 볼 수 있습니다.

2. hello 프로세스의 가상 메모리 할당 주소와 gdb 디버거를 통해 비교해 보자.

2-1. 위 소스 코드를 실행하면 실제 프로세스를 확인할 수 없으니, sleep 함수를 추가한 뒤, gdb를 통해 디버그 합니다.

[root@ip-10-0-131-237 test]# gdb ./hello

2-2. run을 입력하여 실행시킵니다.

(gdb) run
Starting program: /root/test/hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Hello, World!

2-3. /proc/pid/maps를 통해 hello 프로세스가 할당받은 가상 메모리 주소를 확인합니다.

[root@ip-10-0-131-237 292146]# cat maps
00400000-00401000 r--p 00000000 ca:04 10501005                           /root/test/hello
00401000-00402000 r-xp 00001000 ca:04 10501005                           /root/test/hello
00402000-00403000 r--p 00002000 ca:04 10501005                           /root/test/hello
00403000-00404000 r--p 00002000 ca:04 10501005                           /root/test/hello
00404000-00405000 rw-p 00003000 ca:04 10501005                           /root/test/hello
00405000-00426000 rw-p 00000000 00:00 0                                  [heap]
7ffff7c00000-7ffff7c28000 r--p 00000000 ca:04 8544281                    /usr/lib64/libc.so.6
7ffff7c28000-7ffff7d9d000 r-xp 00028000 ca:04 8544281                    /usr/lib64/libc.so.6
7ffff7d9d000-7ffff7df5000 r--p 0019d000 ca:04 8544281                    /usr/lib64/libc.so.6
7ffff7df5000-7ffff7df6000 ---p 001f5000 ca:04 8544281                    /usr/lib64/libc.so.6
7ffff7df6000-7ffff7dfa000 r--p 001f5000 ca:04 8544281                    /usr/lib64/libc.so.6
7ffff7dfa000-7ffff7dfc000 rw-p 001f9000 ca:04 8544281                    /usr/lib64/libc.so.6
7ffff7dfc000-7ffff7e09000 rw-p 00000000 00:00 0
7ffff7fb5000-7ffff7fb9000 rw-p 00000000 00:00 0
7ffff7fc1000-7ffff7fc5000 r--p 00000000 00:00 0                          [vvar]
7ffff7fc5000-7ffff7fc7000 r-xp 00000000 00:00 0                          [vdso]
7ffff7fc7000-7ffff7fc9000 r--p 00000000 ca:04 8544277                    /usr/lib64/ld-linux-x86-64.so.2
7ffff7fc9000-7ffff7fef000 r-xp 00002000 ca:04 8544277                    /usr/lib64/ld-linux-x86-64.so.2
7ffff7fef000-7ffff7ffa000 r--p 00028000 ca:04 8544277                    /usr/lib64/ld-linux-x86-64.so.2
7ffff7ffb000-7ffff7ffd000 r--p 00033000 ca:04 8544277                    /usr/lib64/ld-linux-x86-64.so.2
7ffff7ffd000-7ffff7fff000 rw-p 00035000 ca:04 8544277                    /usr/lib64/ld-linux-x86-64.so.2
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

(gdb) info proc
process 292146
cmdline = '/root/test/hello'
cwd = '/root/test'
exe = '/root/test/hello'

2-4. main 함수의 가상 메모리 주소를 확인합니다.

(gdb) info address main
Symbol "main" is at 0x401136 in a file compiled without debugging.

디버거를 통해, main 함수의 가상 메모리주소가 0x401136 임을 알 수 있습니다.

아래의 가상 메모리 내, 텍스트 세그먼트에 위치해 있음을 알 수 있습니다.

[root@ip-10-0-131-237 292146]# cat maps
00400000-00401000 r--p 00000000 ca:04 10501005                           /root/test/hello
00401000-00402000 r-xp 00001000 ca:04 10501005                           /root/test/hello

오늘은 가상 메모리의 매핑 과정을 눈으로 확인해 보았는데요. 실제 write 시스템 콜이 호출되면 Physical Memory Access 가 일어나게 됩니다.

어떻게 가상 메모리 주소만으로 물리 메모리 주소에 접근할 수 있을까요?

바로, 페이지 테이블이 존재하기 때문인데요!

다음 시간에는 매핑된 페이지 테이블을 확인해 보고 코드 수행 동작을 살펴보는 시간을 갖겠습니다.

오늘도 감사합니다.

성능 지표(IOPS) 를 알아보자(2)

abc94 — Sat, 8 Jun 2024 17:19:27 +0900

저번 IOPS 측정 방법 시간에 이어, 추가적인 내용을 작성하고자 합니다.

이전 시간의 내용을 참고해보면, "IOPS 는 블록사이즈와 반비례 한다" 라고 전달드렸습니다.

그럼, 성능 측정을 하기위해 애플리케이션이 발생시키는 file I/O 의 블록 크기를 측정해야 하는데요.

이번 시간에는 블록 사이즈를 측정하는 방법에 대해 알아보겠습니다.

피드백은 언제나 환영 입니다.

#.테스트 시나리오

1. dd 를 통한 빈 파일 생성

2. blktrace를 활용하여 블록 디바이스 트래픽 추적

3. 결과 확인

1. dd 를 통한 빈 파일 생성

먼저, dd 명령은 무엇일까요?

[root@ip-10-0-131-237 ~]# whatis dd
dd (1)               - convert and copy a file

그러면, 해당 명령어를 통해 빈 파일을 생성함과 동시에, blktrace로 트래픽을 추적하겠습니다.

dd if=/dev/zero of=./file_2 bs=4K count=100000

4K 블록을 100,000 번 수행하여 file_2 라는 파일을 생성해보겠습니다.

100000+0 records in
100000+0 records out
409600000 bytes (410 MB, 391 MiB) copied, 3.49065 s, 117 MB/s

392MB의 파일이 생성되었습니다.

2. blktrace 를 통한 트래픽 추적

[root@ip-10-0-131-237 ~]# whatis blktrace
blktrace (8)         - generate traces of the i/o traffic on block devices

※ 주의점, dd 를 통한 빈 파일 생성 명령어를 추적을 해야 하므로, 다른 터미널에서 아래 명령어를 동시에 실행해주세요.

[root@ip-10-0-131-237 ~]# blktrace -d /dev/xvda4 -o - | blkparse -i -

-d 옵션 뒤에는, 파일이 생성될 파티션 이름, blktrace 로 추적된 바이너리 정보를 blkparse 를 통해 읽습니다.

해당 명령어를 실행하면 추적 결과를 아래와 같이 보실 수 있습니다.

blkparse

I/O 발생 CPU 번호, 이벤트 시퀀스, 타임스탬프, PID, 이벤트 타입, 블록번호와 길이 등이 보이네요.

여기서 블록 사이즈를 알기 위해선.. 블록번호와 길이 (ex. 4945936 + 256) 을 봐야 합니다.

해당 섹터에 +256 (섹터 단위) 를 Write 한다 라고 이해할 수 있겠네요.

그러면, 해당 디스크의 섹터 단위는 어디서 확인 할 수 있을까요?

[root@ip-10-0-131-237 ~]# fdisk -l
Disk /dev/xvda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D209C89E-EA5E-4FBD-B161-B461CCE297E0

해당 디스크는 1 섹터가 512 byte 라는 것을 알 수 있습니다.

결론적으로, 256 * 512 / 1024 = 128 KB 임을 알 수 있습니다.

근데, 여기서 의문점이 있습니다.. 분명 dd 를 통해 빈파일 생성 시, 4K 사이즈 단위의 블록을 생성한다고 했는데, 왜 128KB 씩 생성 했을까요?

이 부분은 sysfs 파라미터를 보면 알 수 있습니다.

3. 결과 확인

[root@ip-10-0-131-237 queue]# cat /sys/block/xvda/queue/max_sectors_kb
128

max_sectors_kb 파라미터의 값을 통해 원인을 알 수 있었습니다.

해당, 파라미터는 리눅스 커널에서 I/O 요청의 최대 크기를 조정하는 데 사용되는 파라미터 입니다.

단일 I/O 요청으로 디스크에 보낼 수 있는 최대 데이터 크기를 결정 할 수 있습니다.

* 해당 파라미터는 sysctl 명령어를 통해 관리되지 않습니다.

sysfs 인터페이스를 통해 관리되며, 해당 인터페이스는 특정 하드웨어나 커널 서브시스템 관련 설정을 제공합니다.

위 값을 조정해보십니다.

[root@ip-10-0-131-237 queue]# echo 4 > /sys/block/xvda/queue/max_sectors_kb

그리고, 테스트를 다시 수행하면 우리가 원했던 4K 블록 사이즈 Write 트래픽이 발생됨을 보실 수 있습니다.

이번 시간을 통해, blktrace 를 통해 트래픽을 추적해보고, 블록 사이즈를 실제 확인해 보는 시간을 가졌습니다.

오늘도 감사합니다.

성능 지표(IOPS) 를 알아보자(1)

abc94 — Thu, 6 Jun 2024 13:25:35 +0900

1. IOPS(Input/Output Operations Per Second)

스토리지 성능 평가 시, 중요하게 사용되는 지표 입니다.

스토리지 장치가 초당 수행할 수 있는 입출력 작업의 수를 나타냅니다.

각 작업의 평균 대기 시간(T)을 통해 IOPS를 계산할 수 있습니다:

IOPS = 1/T(초 단위)

입출력 작업이란, 서버와 스토리지 간에 읽기 또는 쓰기 작업을 의미합니다.

IDC 상에서 많이 사용되고 있는 디스크의 IOPS를 살펴보겠습니다.

- SSD : 10,000 - 100,000 IOPS

VMWARE ESXI 환경에서, 스토리지 성능 측정 시 HCI Bench를 많이 이용합니다. 간단하게 사용 예제를 보면서 해당 개념을 이해해봅시다.

HCI Bench 는 성능 지표로 사용될 VM 들을 클러스터로 묶어서 스토리지와 Block I/O 를 일으킵니다.

Number of Disks to Test : VM 에 할당된 디스크의 수

Number of Threads Per Disk : IO 를 발생시킬 쓰레드의 수

Block Size : 블록 크기 설정

- 4 KB : 데이터베이스 트랜잭션

- 64 KB : 혼합된 I/O 패턴, 일반적인 파일 서버

- 1 MB : 대용량 파일 전송

HCI Bench 는 위 사진처럼 스토리지 성능 테스트의 워크로드를 설계하고, 실제 테스트 수행은 VM 내, FIO 가 수행하게 됩니다.

3,000 IOPS 를 제공하는 EBS 볼륨을 대상으로 진행했습니다.

#1. block size = 4K

fio --name=small_block_test --filename=testfile --rw=randread --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting --ioengine=libaio --iodepth=32

#2. blcok size = 1M

fio --name=small_block_test --filename=testfile --rw=randread --bs=1M --size=1G --numjobs=1
 --runtime=60 --group_reporting --ioengine=libaio --iodepth=32

결과 비교

	Throuput(KiB/s)	IOPS
block size = 4K	6800	1700
blcok size = 1M	55296	64

일반적으로, 블록 사이즈의 크기의 반비례하게 IOPS 가 측정됩니다.

오늘의 결론!

성능의 좋다/나쁘다를 판가름할 시, IOPS 수치만 고려하는게 아닌, 애플리케이션의 I/O 블록 크기도 같이 고려해야겠죠?

다음 시간에는 latency 에 대해 공부해보고, 어느정도의 수치가 사용자가 느끼기에 느리다고 생각할지?? 에 대해 알아보겠습니다.

감사합니다.

성능 지표(Bandwidth, T-put) 를 알아보자 (1)

abc94 — Mon, 3 Jun 2024 21:16:33 +0900

안녕하세요 여러분

네트워크 성능 측정을 할때 좋다?? 나쁘다를 구분할 수 있는 기준들을 분석해 보는 시간을 갖겠습니다.

저도 장비 모니터링을 하면서 위와 같은 수치를 굉장히 많이 접할 수 있었는데요.

단순히, 어느 정도 수치가 객관적으로 좋은 수치인지는 환경에 따라 다르겠지만, 적어도 어떻게 계산되는지 알아야 할 필요는 있지 않을까요?

피드백은 언제나 환영입니다!

- 네트워크

Throughput (T-put)
Bandwidth (대역폭)

- 스토리지

IOPS
latency

1. 네트워크 - Bandwidth 란?

네트워크를 통해 일정 시간 동안 전달 할 수 있는 최대 데이터 양을 뜻합니다.

대역폭 = 데이터 양(Data Size) / 시간(Time)

ex) 10G 이더넷 케이블 / 32G FC 케이블

IDC 를 경험해본 분들이라면, 위와 같은 케이블을 많이 접할 수 있습니다.

1) 10G 이더넷 케이블의 경우, 초당 10 Gigabit 의 데이터 양을 전송할 수 있는 케이블 입니다. 주로, (서버-스위치) / (스위치-네트워크 장비) 연동 구간에 많이 사용됩니다.

2) 32G FC 케이블의 경우, 초당 32 Gigabit의 데이터 양을 전송할 수 있겠죠? 주로, (서버HBA 카드 - SAN 스위치) / (SAN 스위치 - 스토리지) 연동 구간에 많이 사용됩니다.

이게 얼만큼의 수치인지 가늠하기가 어렵기에, 바이트로 변환해보겠습니다.

32 기가비트는 약 4GB 로 환산할 수 있습니다. 따라서, 초당 4GB를 전송할 수 있습니다.

즉, 4GB 짜리 영화 한편 정도는 1초만에 다운로드 할 수 있겠네요?

2. 네트워크 - Throughput 이란 ?

제 기준, Bandwidth 보다 살짝 더 감이 오지 않는데요.. 한번 같이 살펴보도록 하죠

wireshark_statistics

오른쪽 축을 보시면, Average Throughput (bits/s) 로 표시 된걸 확인 하실 수 있을 겁니다.

약, 1.8 * 10^8 임을 확인할 수 있고, 이는 180 Mbps 로 환산 할 수 있습니다. (1 Mbps = 1,000,000 bps)

= 22.5MB/s

이는, 약 10GB 크기의 파일을 전송하는데, 7분 정도가 소요되는 시간 입니다.

※ IDC 기존, 1Gbps 이상의 대역폭을 제공하는 케이블들로 네트워크가 구성되어 있습니다.

병목 현상, 네트워크 혼잡 등을 고려하더라도, 위 속도는 그저그런(?) 속도라고 보여집니다.

Throughput = 총 전송된 데이터 양(bits) / 측정 시간(seconds)

https://forum.huawei.com/enterprise/en/network-latency-vs-bandwidth-vs-throughput/thread/789837-861

오늘 시간은 네트워크 성능 지표 측정은 위 수치 말고도 다양한 값들이 존재합니다.

이러한 부분은 추후 wireshark 편에서 공부해보도록 하겠습니다..

스토리지 부분은 금방 업로드 하겠습니다.

오늘도 감사합니다!

com.jcraftjschJSchException-Auth-fail

abc94 — Sun, 2 Jun 2024 16:53:51 +0900

회사 내부에서 겪었던 오류와 문제 해결 과정에 대해 공유하고자 합니다.

사실 원인 자체는 단순했습니다만, 원인을 찾고 해결하는 과정에서 얻은 러닝 포인트를 기록하고자 합니다.

원인 자체는 서버 계정 패스워드 변경 이슈 였습니다;;

인프라 구조
발생 원인
해결 과정

1. 인프라 구조

원인을 파악하기 전, 이해를 돕기 위해 내부 인프라 구조를 간략하게 전달드립니다.

인프라 구조

모니터링 서버(Jeus8)을 통해 San storage의 Health Check / Lun 생성 등을 진행합니다.

특이하게, 특정 SAN 장비만 SSH 프로토콜을 이용해서 통신을 진행했었고, 별도의 Managing 서버를 통해 해당 Storage 에 명령어를 전달 하였습니다.

2. 발생 원인

웹에서 표현되는 오류 만으로는 어떠한 이슈인지 알 수 없었기에, 소스를 통해 해당 원인을 분석하고자 했습니다.

원인이 되는 소스는 대략 아래와 같습니다.

JSCH 라이브러리를 통해 JAVA 에서 원격으로 SSH 명령어를 전달할 수 있습니다.

아래 소스는 계정 정보를 통해 해당 서버와 Session을 맺기 위한 소스로 볼 수 있겠군요

import com.jcraft.jsch.JSch;
import com.jcraft.jsch.JSchException;
import com.jcraft.jsch.Session;
import com.jcraft.jsch.SftpException;

public class Main {

    public static void main(String[] args) throws JSchException, SftpException, IOException {
        
        String username = "XXXXXX";
        String host = "XXXXXX";
        String passwd = "XXXXXX";
        JSch conn = new JSch();
        Session session = null;
        session = conn.getSession(username, host, 22);
        session.setPassword(passwd);
        session.setConfig("StrictHostKeyChecking", "no");
        session.connect();

        channel.disconnect();
        session.disconnect();   

    }

}

3. 해결 과정

실제 모니터링 서버에서는 Storage managing 서버와 SSH 접속이 잘 되는가?
Storage managing 서버에서 secure 로그는 어떻게 찍혔을까?

3-1 실제 모니터링 서버에서는 Storage managing 서버와 SSH 접속이 잘 되는가?

테스트 결과, 모니터링 서버와 Storage managing 서버와의 세션 연결은 잘되었습니다. 하지만, 간과하고 있었던 점이 하나 있었는데, SSH 프로토콜의 인증 방식은 두가지가 있다는 점이었습니다.

키 인증 방식
패스워드 인증 방식

해당 부분에 대해서는 SSH 프로토콜 편에서 자세히 다루겠습니다.

3-2. Storage manaing 서버에서 secure 로그는 어떻게 찍혔을까?

/var/log/secure

ssh 로그인 시도 / 인증 시도와 같은 로그를 저장하는 파일입니다.

해당 파일을 통해 com.jcraftjschJSchException-Auth-fail - password 오류 관련된 메시지를 발견할 수 있었습니다.

(위 사진과는 무관합니다)

실제 패스워드가 변경되었는지 확인하기 위해, Storage Managing 서버에 저장된 모니터링 서버의 공개키를 제거하였습니다.

패스워드가 어떠한 이유 때문인지는 모르겠지만, 모니터링 서버 DB 에 저장된 Password 와 달랐었습니다;;

이후, 패스워드 동기화를 통해 해당 문제를 해결했습니다.

4. 마치며..

사실 원인 자체는 되게 단순하였습니다.

하지만, 러닝 포인트는 크게 두가지가 있었습니다.

/var/log/secure 파일의 역할
SSH 프로토콜의 인증 방식

오늘도, 방문해 주셔셔 감사합니다.

안녕하세요

abc94 — Sat, 1 Jun 2024 23:26:19 +0900

리눅스 / 네트워크에 호기심이 많은 시스템 엔지니어의 블로그 입니다.

가상 메모리에 관하여(1)

abc94 — Sat, 1 Jun 2024 21:35:42 +0900

가상 메모리의 도입 배경과 어떤 방식으로 작동하는지 알아보겠습니다.

피드백은 언제나 환영입니다!

0. 우리는 왜 가상메모리에 대해 알아야 할까요?

사실, 해당 개념을 모르더라도 프로그램 개발에 있어서 문제 될 건 없습니다. 물리적 메모리의 위치를 신경 쓰지 않아도, OS 가 메모리 관리를 해주고 있기 때문입니다.

시스템 엔지니어 기준, 가상 메모리에 대한 개념을 알아야 하는 이유는 다음과 같을 것입니다.

시스템 엔지니어
- 리눅스 기준, top, vmstat, free 명령어를 통해 프로세스 메모리 모니터링을 합니다.
- 우리는 아래와 같은 상황을 주로 접하게 됩니다.
- 메모리 누수를 유발하고 있는 프로세스는 무엇이고, 해결을 어떻게 해야 하는지?
- 특정 가상 메모리 주소를 사용하고 있는 코드에 문제가 있는 것은 아닌지?
- 메모리 증설해야 될 상황에 대한 기준을 어떻게 잡을지?

1. 가상 메모리의 도입 배경

- 메모리 의존성

- 메모리 단편화(Memory Fragmentation)

- 보안

메모리 의존성

가상 메모리의 개념이 도입되기 전, 무슨 어려움이 있었을까요? 가장 까다로웠던 것은 개발자가 아닐까 싶습니다.

프로그램이 개발되고, 해당 프로그램이 실행되기 위해서는 메모리 자원을 활용해야 합니다. 즉, 프로그램의 코드와 데이터를 메모리에 로드를 해야 합니다.

Q. 메모리 규격이 서버마다 다르면 무슨 문제점이 있을까요?

결론부터 말씀드리면, 개발자분들은 시스템의 메모리 구조와 크기에 맞춰 프로그램을 재컴파일 해야 합니다.

즉, 프로그램의 호환성이 매우 떨어지게 됩니다.

프로그램을 개발하는 것도 어려운데, 해당 코드의 물리적 메모리 위치까지 고려해서 만들면.. 굉장히 많은 노력이 들어가겠죠??

특히, 32bit 시스템의 경우 (2^32) 4GB의 메모리 주소를 갖게 됩니다. 해당 운영체제가 사용하는 공간도 있을 것이고, 여러 프로그램이 메모리를 공유해서 사용하기에, 프로그램의 메모리 배치는 더욱 까다로웠을 겁니다.

메모리 단편화

외부 메모리 단편화 현상이 자주 발생되어 메모리의 효율성이 매우 떨어졌습니다.

메모리 단편화는 외부 / 내부로 나눠지는데, 해당 내용은 추후에 같이 공부해 보는 걸로..

우선, 외부 메모리 단편화는 물리적 메모리의 비연속적인 공간을 활용할 수 없는 문제입니다.

아래의 그림처럼, Process D에 할당해 줄 물리적 자원은 있지만, 연속된 공간이 필요한 Process D는 메모리를 할당받을 수 없는 상황이 발생됩니다.

https://sycho-lego.tistory.com/9

하지만, 가상 메모리 개념과 페이징 기법으로 인하여 해당 문제를 해결할 수 있었습니다.

보안

가상 메모리 시스템에서는 각 프로세스 별로 고유한 가상 주소 공간을 사용할 수 있습니다. 즉, 이러한 공간은 하나의 프로세스의 것으로 자신만의 공간이 생겼다는 의미입니다. 이 주소 공간은 다른 프로세스와 격리되어 타 프로세스가 해당 메모리 영역에 접근할 수 없도록 보장합니다.

Q. 이를 역으로 생각해면.. 가상 메모리의 개념이 없었을 시절에는 무슨 문제점들이 있었을까요?

여러 프로세스들이 물리 메모리 주소 공간을 공유했기 때문에, 타 프로세스의 영역을 침범할 수 있었습니다.

또한, 자신에게 할당되지 않은 메모리 영역에 접근함으로써, 타 프로세스의 코드나 데이터를 변경할 수도 있었죠..

오늘은 가상 메모리 개념을 왜 알아야 하며, 가상 메모리의 개념이 왜 도입이 되었는지 고민해 보는 시간을 가졌습니다.

다음 편에, 가상메모리의 구조를 알아보고 리눅스를 통해 직접 살펴보는(?) 시간을 갖겠습니다.

방문해 주셔서 감사합니다.