ITinfra

[완벽 가이드] NAS 마이그레이션 중 배드섹터 에러 해결법: rsync 무한루프부터 ddrescue까지

Itlee — Thu, 19 Mar 2026 13:05:49 +0900

문제 상황: NAS 데이터 이전 중 발생한 배드섹터와 rsync 멈춤 현상

노후화된 NAS 장비를 새 장비로 교체하거나 데이터를 마이그레이션 할 때 가장 많이 사용하는 도구가 바로 rsync입니다. 하지만 소스(원본) NAS의 하드디스크에 배드섹터(Bad Sector)나 파일 시스템 손상이 있는 경우, rsync가 특정 파일에서 진행되지 않고 무한 대기(Hang) 상태에 빠지거나 에러를 뿜으며 연결이 끊어지는 답답한 상황이 발생합니다.

이때 급한 마음에 디스크를 통째로 복제하는 dd 명령어를 떠올리기 쉽지만, 이는 매우 위험한 선택입니다. 오늘은 배드섹터가 존재하는 악조건 속에서 데이터를 가장 안전하게 마이그레이션하는 두 가지 실무 전략을 정리해 보겠습니다.

❌ 왜 일반적인 dd 명령어 사용을 비추천할까?

서비스를 중지(Offline)한 상태라 하더라도, 배드섹터가 있는 디스크에 일반 dd 명령어를 사용하는 것은 강력히 비권장합니다. 그 이유는 다음과 같습니다.

동일한 I/O 에러 발생: dd 역시 배드섹터 구간을 만나면 읽기 오류로 명령어가 중단되거나 시스템 전체가 먹통이 됩니다.
파티션 및 RAID 정보 충돌: NAS는 제조사마다 OS 영역, 스왑, 데이터 영역의 파티션 구조가 다릅니다. dd로 디스크를 통째로 밀어버리면 타겟 NAS의 OS나 RAID 정보까지 덮어써져 부팅 불능 상태가 될 수 있습니다.
비효율적인 전송 시간: 파일의 유무와 상관없이 빈 공간까지 모두 복사하므로 시간이 기하급수적으로 늘어납니다.

따라서 데이터의 성격(일반 파일 vs 통짜 볼륨)에 따라 아래의 해결책 1 또는 해결책 2를 선택해야 합니다.

️ 해결책 1. 파일 레벨 마이그레이션: rsync 무한 루프 스크립트 적용 (추천)

일반적인 문서, 이미지, 동영상 파일(SMB/NFS 공유)을 넘기는 상황이라면 rsync에 타임아웃(Timeout)과 무한 재시도 로직을 장착하는 것이 가장 확실합니다.

배드섹터가 있는 파일에서 잠시 멈췄다가 강제로 끊어내고, 다음 정상 파일부터 이어받기를 수행하는 강력한 쉘 스크립트입니다.

rsync 자동 재시도 쉘 스크립트 (migration.sh)

Bash

#!/bin/bash

echo "  배드섹터 대응 NAS 마이그레이션을 시작합니다..."

# rsync가 완전히 성공(종료 코드 0)할 때까지 무한 반복하는 루프
while [ 1 ]
do
    # 핵심 옵션: --timeout=60 (60초 응답 없으면 강제 종료 후 루프 재시작)
    # --inplace 및 --partial 옵션으로 끊긴 부분부터 이어받기 수행
    rsync -avh \
          --update \
          --ignore-errors \
          --partial \
          --inplace \
          --timeout=60 \
          --log-file=/var/log/nas_mig.log \
          /source_dir/ \
          /target_dir/
    
    # rsync 종료 코드 확인
    if [ "$?" = "0" ] ; then
        echo "✅ 마이그레이션이 성공적으로 완료되었습니다."
        break # 루프 탈출
    else
        echo "⚠️ 배드섹터/네트워크 오류(타임아웃) 발생! 10초 대기 후 이어받습니다..."
        sleep 10
    fi
done

실무 꿀팁: 백그라운드로 스크립트를 실행한 뒤, /var/log/nas_mig.log 파일에서 rsync error나 Input/output error 키워드만 추출(grep)해보세요. 어떤 파일이 배드섹터 때문에 복사를 실패했는지 정확히 리스트업 할 수 있습니다.

️ 해결책 2. 블록 레벨 마이그레이션: ddrescue를 활용한 디스크 복제

만약 NAS를 가상머신(VM) 저장소나 데이터베이스용 iSCSI LUN으로 사용 중이라면, 파일 단위 복사가 불가능하므로 디스크(블록) 단위로 복원해야 합니다. 이때는 dd가 아닌 **데이터 복구 전용 도구인 ddrescue**를 사용해야 합니다.

ddrescue는 배드섹터를 만나면 즉시 건너뛰고 정상 데이터부터 빠르게 복사한 뒤, 나중에 건너뛴 배드섹터 영역만 다시 찾아가 정밀 타격(Scraping)을 시도하는 지능형 복구 툴입니다.

ddrescue 2단계 복구 시나리오

주의사항: 절대 원본 고장 디스크를 마운트(Mount)하지 마시고, 타겟 디스크의 용량이 원본보다 같거나 커야 합니다. (원본: /dev/sda, 대상: /dev/sdb 가정)

1단계: 정상 데이터부터 대피시키기 (Fast Pass) 배드섹터를 긁어내려 애쓰지 않고(-n), 정상적인 블록들만 최대한 빠르게 대상 디스크로 넘깁니다.

Bash

# -f: 물리 디스크 강제 덮어쓰기 허용 / -n: 배드섹터 스크래핑 건너뛰기
# /root/rescue.map 파일은 작업 지도로 반드시 필요함!
ddrescue -f -n /dev/sda /dev/sdb /root/rescue.map

2단계: 건너뛴 배드섹터 정밀 복구 (Scraping & Retry) 1단계가 끝나면 동일한 맵 파일(rescue.map)을 사용하여, 앞서 실패했던 구간만 Direct I/O(-d) 모드로 최대 3번(-r3) 재시도합니다.

Bash

ddrescue -d -f -r3 /dev/sda /dev/sdb /root/rescue.map

마무리 요약

NAS 간 마이그레이션 시 배드섹터가 의심된다면 절대 일반 dd를 사용하지 마세요.
파일/폴더 기반 동기화는 rsync 타임아웃 옵션 + 무한 루프 스크립트가 정답입니다.
디스크 통짜 복제가 불가피한 환경이라면 ddrescue를 이용해 Multi-pass 복구를 진행하세요.

데이터 마이그레이션은 엔지니어에게 가장 피 말리는 작업 중 하나입니다. 위 가이드가 무사히 데이터를 넘기는 데 도움이 되길 바랍니다.

CentOS 7 EOL 완벽 대응 가이드 — Rocky Linux vs AlmaLinux 차이점 비교 및 마이그레이션 방법

Itlee — Thu, 19 Mar 2026 10:05:03 +0900

CentOS 7, 이제 정말 끝났다

2024년 6월 30일, CentOS 7이 공식 지원 종료(EOL, End of Life)를 맞이했습니다. 이후로는 보안 패치와 버그 수정이 전혀 제공되지 않습니다. 아직도 CentOS 7을 운영 중인 서버가 있다면 보안 취약점에 그대로 노출된 상태라는 의미입니다. 더 이상 미룰 수 없는 상황에서 가장 현실적인 대안으로 꼽히는 것이 바로 Rocky Linux와 AlmaLinux입니다.

두 배포판 모두 RHEL(Red Hat Enterprise Linux)과 1:1 바이너리 호환을 목표로 만들어진 무료 엔터프라이즈 리눅스입니다. 이 글에서는 두 배포판의 차이점을 비교하고, CentOS 7에서 마이그레이션하는 실전 절차를 정리합니다.

왜 CentOS 8이 아닌 CentOS 7이 문제인가

많은 분들이 혼동하는 부분입니다. CentOS 8은 이미 2021년 12월에 지원이 종료됐고, Red Hat은 CentOS를 롤링 릴리즈 방식의 CentOS Stream으로 전환했습니다. CentOS Stream은 RHEL의 업스트림 개발 브랜치 성격이라 기존 CentOS처럼 안정적인 엔터프라이즈 서버 운영에는 적합하지 않습니다. 결국 CentOS의 공백을 메우기 위해 커뮤니티 주도로 탄생한 것이 Rocky Linux와 AlmaLinux입니다.

Rocky Linux vs AlmaLinux — 탄생 배경

Rocky Linux

Rocky Linux는 CentOS의 공동 창립자인 Gregory Kurtzer가 주도해 만든 배포판입니다. "CentOS가 원래 하려던 것을 우리가 한다"는 철학으로 시작했으며, Rocky Enterprise Software Foundation(RESF)이 운영합니다. RHEL 소스 코드를 기반으로 1:1 바이너리 호환성을 보장하며, 커뮤니티 중심의 거버넌스 구조를 강조합니다.

개발 주체: Rocky Enterprise Software Foundation(RESF), 커뮤니티 중심
최신 버전: Rocky Linux 9.x (RHEL 9 기반)
지원 기간: 메이저 버전 기준 10년 (Rocky Linux 8: 2029년까지, 9: 2032년까지)
특징: FIPS 140-2/3 인증, 강력한 커뮤니티 생태계

AlmaLinux

AlmaLinux는 웹 호스팅 기업 CloudLinux가 주도해 만든 배포판으로, AlmaLinux OS Foundation이 운영합니다. 기업 후원이 탄탄한 편이며, Red Hat이 RHEL 소스 공개 정책을 변경한 이후에는 RHEL 1:1 호환 대신 ABI(Application Binary Interface) 호환 방식으로 전환해 독립성을 강화했습니다.

개발 주체: AlmaLinux OS Foundation (CloudLinux 후원)
최신 버전: AlmaLinux 9.x (RHEL 9 기반)
지원 기간: 메이저 버전 기준 10년 (AlmaLinux 8: 2029년까지, 9: 2032년까지)
특징: FIPS 140-3 인증, ELevate 마이그레이션 툴 제공, 기업 지원 옵션 있음

두 배포판 핵심 비교

RHEL 호환성: Rocky Linux는 바이너리 1:1 호환 / AlmaLinux는 ABI 호환 (실사용 환경에서 차이 거의 없음)
거버넌스: Rocky Linux는 순수 커뮤니티 중심 / AlmaLinux는 기업(CloudLinux) 후원 기반
마이그레이션 툴: AlmaLinux의 ELevate 툴이 더 성숙하고 다양한 경로 지원
기업 지원: AlmaLinux는 유료 상업 지원 옵션 제공 / Rocky Linux는 커뮤니티 중심
패키지 업데이트 속도: 두 배포판 모두 RHEL 패치 후 수일 내 반영으로 큰 차이 없음

결론적으로 어느 쪽을 선택해도 실제 운영 환경에서 체감 차이는 거의 없습니다. 순수 커뮤니티를 선호하면 Rocky Linux, 기업 지원과 안정적인 마이그레이션 툴을 원하면 AlmaLinux를 권장합니다.

마이그레이션 전 반드시 해야 할 준비

전체 백업: 시스템 스냅샷 또는 전체 백업 필수. 마이그레이션 실패 시 롤백 수단이 없으면 복구 불가.
운영 중인 패키지 목록 확인: rpm -qa > /root/pkg_list_before.txt 로 현재 설치 패키지 기록
서드파티 저장소 확인: EPEL, Remi, SCLo 등 외부 저장소 패키지는 마이그레이션 후 재설치 필요할 수 있음
테스트 서버에서 먼저 검증: 동일 구성의 테스트 서버에서 마이그레이션 절차를 먼저 수행하고 이상 없을 때 운영 서버에 적용
커널 및 패키지 최신화: yum update -y 후 재부팅으로 최신 상태 유지

AlmaLinux ELevate로 CentOS 7 마이그레이션 (권장)

AlmaLinux가 제공하는 ELevate 프로젝트는 CentOS 7에서 AlmaLinux 8로의 인플레이스(In-place) 업그레이드를 지원하는 공식 툴입니다. 재설치 없이 기존 서버에서 직접 OS를 전환할 수 있습니다.

ELevate 마이그레이션 절차

# 1. ELevate 저장소 설치
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm

# 2. leapp 및 데이터 패키지 설치
sudo yum install -y leapp-upgrade leapp-data-almalinux

# 3. 사전 점검 실행 (실제 업그레이드 없이 문제 항목만 탐지)
sudo leapp preupgrade

# 4. 점검 리포트 확인
cat /var/log/leapp/leapp-report.txt

preupgrade 실행 후 리포트에서 inhibitor(차단 요소)로 표시된 항목은 반드시 해결해야 업그레이드가 진행됩니다. 자주 나오는 차단 요소는 다음과 같습니다.

# PAM 설정 관련 차단 요소 해결 예시
sudo rmmod pata_acpi

# GRUB 설정 확인
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# 5. 차단 요소 해결 후 실제 업그레이드 실행
sudo leapp upgrade

# 6. 재부팅 (업그레이드는 재부팅 중 자동 진행, 10~30분 소요)
sudo reboot

재부팅 완료 후 AlmaLinux 8로 전환된 것을 확인합니다.

cat /etc/os-release
rpm -qa | grep almalinux

Rocky Linux 직접 설치 후 데이터 이전 방식

인플레이스 마이그레이션 대신 새 서버에 Rocky Linux를 클린 설치하고 데이터와 서비스를 이전하는 방식도 많이 사용됩니다. 인플레이스 방식보다 안전하며, 레거시 설정이 그대로 이전되는 부작용이 없습니다.

Rocky Linux 9.x ISO 다운로드 후 설치 (rockylinux.org/download)
기존 서버의 애플리케이션 설정 파일, 데이터 디렉터리 rsync로 이전
패키지 목록 기반 재설치: yum install $(cat /root/pkg_list_before.txt | awk '{print $1}')
서비스 기동 및 검증 후 DNS/로드밸런서 전환

마이그레이션 후 점검 사항

SELinux 상태 확인: sestatus — 정책이 변경됐을 경우 서비스 접근 거부 발생 가능
방화벽 규칙 확인: firewall-cmd --list-all
서비스 자동 시작 확인: systemctl list-unit-files --state=enabled
크론탭 이전 확인: crontab -l, /etc/cron.d/ 내용 점검
애플리케이션 정상 동작 확인: 웹서버, DB, 미들웨어 순서로 기동 및 로그 점검

마무리

CentOS 7 EOL은 단순한 버전 업그레이드가 아니라 서버 운영 기반 자체를 재정비하는 기회입니다. Rocky Linux와 AlmaLinux 모두 훌륭한 대안이며, 어떤 배포판을 선택하든 체계적인 백업과 테스트 검증을 거친 마이그레이션이 가장 중요합니다. 아직 CentOS 7 서버가 남아있다면 지금 바로 마이그레이션 계획을 수립하시기 바랍니다.

SSH 접속 지연·Connection refused 오류 해결 — 5가지 필수 점검 사항 완전 정리

Itlee — Thu, 19 Mar 2026 08:54:57 +0900

SSH가 안 된다 — 어디서부터 봐야 할까

리눅스 서버 관리에서 SSH 접속 문제만큼 긴장되는 상황도 없습니다. 특히 원격지에 있는 서버에서 Connection refused 오류가 뜨거나, 접속은 되는데 패스워드 입력 화면까지 수십 초가 걸리는 경우 막막하게 느껴질 수 있습니다. 하지만 SSH 접속 문제는 원인이 몇 가지로 압축됩니다. 아래 5가지 항목을 순서대로 점검하면 대부분의 문제를 빠르게 해결할 수 있습니다.

점검 1 — SSH 데몬(sshd) 서비스 상태 확인

가장 먼저 확인해야 할 것은 SSH 서비스 자체가 실행 중인지 여부입니다. 서비스가 죽어있으면 어떤 설정을 바꿔도 접속이 불가능합니다. 콘솔 또는 BMC(iLO/XCC) 접근이 가능하다면 서버에 직접 로그인해 확인합니다.

systemctl status sshd           # 서비스 상태 확인
systemctl start sshd            # 서비스 시작
systemctl enable sshd           # 부팅 시 자동 시작 등록

상태가 failed 또는 inactive라면 서비스를 시작하고, 왜 죽었는지 로그를 확인합니다.

journalctl -u sshd -n 50        # 최근 50줄 sshd 로그 확인
journalctl -u sshd --since "1 hour ago"  # 최근 1시간 로그

자주 보이는 오류 메시지와 원인은 다음과 같습니다.

error: Could not load host key: SSH 호스트 키 파일 손상 또는 없음 → ssh-keygen -A로 재생성
Address already in use: 22번 포트를 다른 프로세스가 점유 → ss -tlnp | grep 22로 확인
Permission denied on /etc/ssh/sshd_config: 설정 파일 권한 문제 → chmod 600 /etc/ssh/sshd_config

점검 2 — 포트 및 방화벽 설정 확인

sshd는 실행 중인데 외부에서 접속이 안 된다면 방화벽이 SSH 포트를 차단하고 있을 가능성이 높습니다. 또한 기본 22번 포트가 아닌 다른 포트로 변경된 경우도 있습니다.

sshd 리스닝 포트 확인

ss -tlnp | grep sshd             # sshd가 어느 포트에서 리스닝 중인지 확인
grep -i "^Port" /etc/ssh/sshd_config  # 설정 파일에서 포트 확인

방화벽 규칙 확인 및 허용

# firewalld 사용 환경 (RHEL/CentOS/Rocky)
firewall-cmd --list-all
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

# ufw 사용 환경 (Ubuntu/Debian)
ufw status
ufw allow 22/tcp
ufw reload

# iptables 직접 사용 환경
iptables -L -n | grep 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

클라우드 환경(AWS, Azure, GCP)이라면 OS 방화벽과 별도로 보안 그룹(Security Group) 또는 네트워크 ACL에서도 인바운드 22번 포트가 허용되어 있는지 반드시 확인해야 합니다. OS 방화벽은 열려있어도 클라우드 레이어에서 막혀있는 경우가 매우 흔합니다.

점검 3 — SSH 접속 지연 원인: DNS 역조회 문제

접속은 되는데 패스워드 입력 화면까지 10~30초 이상 지연된다면 거의 대부분 DNS 역조회(Reverse DNS Lookup) 문제입니다. sshd는 기본적으로 접속을 시도한 클라이언트 IP에 대해 역방향 DNS 조회를 수행하는데, 이 조회가 실패하거나 타임아웃되면 그만큼 접속이 지연됩니다.

vi /etc/ssh/sshd_config

아래 항목을 추가하거나 수정합니다.

UseDNS no
GSSAPIAuthentication no

systemctl restart sshd

UseDNS no는 역방향 DNS 조회를 비활성화하고, GSSAPIAuthentication no는 Kerberos 기반 인증 시도를 끄는 설정으로, 사내 Kerberos 환경이 아닌 경우 불필요한 대기 시간을 유발합니다. 두 설정 적용 후 재시작하면 접속 지연이 즉시 해소되는 경우가 대부분입니다.

점검 4 — TCP Wrapper 및 hosts.deny 설정 확인

최신 리눅스 배포판에서는 비중이 줄었지만, 오래된 시스템이나 보안 정책이 적용된 환경에서는 TCP Wrapper(/etc/hosts.allow, /etc/hosts.deny)가 SSH 접속을 차단하는 경우가 있습니다.

cat /etc/hosts.deny
cat /etc/hosts.allow

hosts.deny에 아래와 같은 설정이 있으면 SSH 접속이 전면 차단됩니다.

ALL : ALL              # 모든 서비스, 모든 IP 차단
sshd : ALL             # SSH만 전체 차단

특정 IP만 허용하려면 hosts.allow에 추가합니다.

# hosts.allow — 특정 대역만 SSH 허용
sshd : 192.168.1.0/255.255.255.0
sshd : 10.0.0.0/255.0.0.0

# 또는 전체 허용으로 임시 해제
sshd : ALL

TCP Wrapper는 hosts.allow가 hosts.deny보다 우선 적용된다는 점을 기억하세요. allow에 명시된 항목은 deny 설정에 관계없이 접속이 허용됩니다.

점검 5 — sshd_config 설정 오류 및 인증 문제

설정 파일을 수정한 뒤 sshd를 재시작했는데 접속이 안 된다면 설정 파일 문법 오류를 의심해야 합니다. sshd는 설정 오류가 있으면 재시작 자체가 실패하거나 조용히 이전 설정으로 유지되는 경우가 있습니다.

설정 파일 문법 검사

sshd -t                          # 설정 파일 문법 검사 (오류 시 메시지 출력)
sshd -T | grep -i "permitroot"   # 현재 적용된 설정값 확인

자주 확인해야 할 sshd_config 항목

PermitRootLogin no               # root 직접 로그인 차단 여부
PasswordAuthentication yes       # 패스워드 인증 허용 여부
AllowUsers user1 user2           # 특정 사용자만 SSH 허용 (미설정 시 전체 허용)
AllowGroups sshusers             # 특정 그룹만 SSH 허용
MaxAuthTries 3                   # 인증 시도 횟수 제한

AllowUsers 또는 AllowGroups 설정이 있는 경우, 해당 목록에 없는 계정은 패스워드가 맞아도 접속이 거부됩니다. 계정이 추가됐는데 접속이 안 된다면 이 항목을 먼저 확인하세요.

공개키 인증 실패 시 권한 점검

키 기반 인증을 사용하는데 접속이 거부된다면 파일 권한 문제일 가능성이 높습니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

sshd는 ~/.ssh나 authorized_keys의 권한이 너무 열려있으면 보안상 키 인증을 거부합니다. 권한이 700/600이어야 정상 동작합니다.

빠른 점검 순서 요약

Connection refused: sshd 서비스 상태 → 방화벽/포트 → TCP Wrapper 순서로 점검
접속 지연 (타임아웃): UseDNS no, GSSAPIAuthentication no 설정 즉시 적용
패스워드 맞는데 거부: AllowUsers/AllowGroups, PasswordAuthentication 항목 확인
키 인증 실패: ~/.ssh 및 authorized_keys 권한(700/600) 확인
설정 변경 후 문제 발생: sshd -t로 문법 검사 후 재시작

마무리

SSH 접속 문제는 원인이 다양해 보이지만 서비스 → 포트/방화벽 → DNS → TCP Wrapper → 설정 파일 순서로 레이어를 좁혀가면 빠르게 해결됩니다. 특히 원격 서버의 sshd_config를 수정할 때는 반드시 기존 세션을 유지한 채로 새 세션 접속 테스트를 먼저 하고, 문제없을 때 기존 세션을 닫는 습관을 들이는 것이 중요합니다. 설정 실수로 모든 SSH 세션이 끊기면 BMC 콘솔 없이는 복구가 어려워집니다.

리눅스 디스크 100% 꽉 찼을 때 완전 해결 가이드 — Disk Full 원인 분석부터 재발 방지까지

Itlee — Thu, 19 Mar 2026 08:44:51 +0900

디스크가 꽉 찼다 — 지금 당장 무엇을 해야 하나

리눅스 서버 운영 중 갑자기 애플리케이션이 로그를 못 쓴다거나, 파일 저장이 안 된다거나, 심한 경우 서비스가 아예 다운되는 상황이 발생합니다. 원인을 추적하다 보면 상당수가 디스크 사용률 100%에서 비롯된 문제입니다. 당황하지 않고 체계적으로 접근하면 대부분 30분 안에 해결할 수 있습니다. 원인 파악부터 즉시 조치, 재발 방지까지 단계별로 정리합니다.

1단계 — 디스크 상태 전체 파악

가장 먼저 어느 파티션이 꽉 찼는지 확인합니다.

df -h

출력 결과에서 Use% 항목이 100%인 마운트 포인트를 찾습니다. 자주 문제가 되는 파티션은 /, /var, /home, /tmp입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   50G     0 100% /
/dev/sdb1       200G   80G  120G  40% /data

여기서 한 가지 더 확인해야 할 것이 있습니다. 디스크 용량은 남아있는데 파일 생성이 안 되는 경우라면 inode 고갈을 의심해야 합니다.

df -i

IUse% 항목이 100%라면 inode가 부족한 것입니다. 이 경우 실제 디스크 공간이 남아있어도 파일을 새로 만들 수 없습니다. 소용량 파일이 수백만 개 이상 쌓인 환경(로그, 캐시, 세션 파일)에서 주로 발생합니다.

2단계 — 어디서 공간을 잡아먹는지 찾기

문제 파티션을 찾았다면 그 안에서 가장 많은 공간을 차지하는 디렉터리를 추적합니다.

대용량 디렉터리 찾기

du -sh /* 2>/dev/null | sort -rh | head -20

루트(/)가 꽉 찬 경우 위 명령으로 1차 범위를 좁히고, 용량이 큰 디렉터리 안으로 반복해서 파고들어 갑니다.

du -sh /var/* 2>/dev/null | sort -rh | head -20
du -sh /var/log/* 2>/dev/null | sort -rh | head -20

대용량 파일 직접 찾기

find / -xdev -type f -size +1G 2>/dev/null | xargs ls -lh
find /var -type f -size +500M 2>/dev/null | xargs ls -lh

-xdev 옵션은 다른 파일 시스템으로 넘어가지 않고 현재 마운트 포인트 안에서만 탐색합니다. 루트 파티션 점검 시 필수 옵션입니다.

삭제됐지만 공간이 반환되지 않은 파일 찾기

실무에서 자주 놓치는 함정이 있습니다. 파일을 삭제했는데 df에서 공간이 줄지 않는 경우입니다. 이는 프로세스가 해당 파일을 열어두고 있어 실제로 공간이 반환되지 않은 상태이기 때문입니다.

lsof +L1 | grep -i deleted

출력 결과에서 SIZE 컬럼이 큰 항목을 확인합니다. 해결 방법은 해당 프로세스를 재시작하거나, 열린 파일 디스크립터를 통해 파일 내용을 비우는 것입니다.

# 예: PID 1234번 프로세스가 /var/log/app.log를 잡고 있는 경우
> /proc/1234/fd/3       # 파일 디스크립터 번호는 lsof 출력에서 확인

3단계 — 즉시 공간 확보 방법

로그 파일 정리

디스크 풀의 가장 흔한 원인입니다. 무작정 삭제하지 말고, 확인 후 조치합니다.

ls -lh /var/log/*.log | sort -k5 -rh | head -20

# 오래된 압축 로그 삭제 (30일 이상)
find /var/log -name "*.gz" -mtime +30 -delete
find /var/log -name "*.log.*" -mtime +30 -delete

# 특정 로그 파일 내용만 비우기 (삭제 아님 — 서비스 유지 중 안전)
> /var/log/application.log

journal 로그 정리 (systemd 환경)

journalctl --disk-usage           # 현재 journal 용량 확인
journalctl --vacuum-time=7d       # 7일 이전 journal 삭제
journalctl --vacuum-size=500M     # 500MB 이하로 줄이기

패키지 캐시 정리

# Ubuntu / Debian
apt-get clean
apt-get autoremove

# RHEL / CentOS
yum clean all
dnf clean all

/tmp 및 코어 덤프 정리

find /tmp -mtime +7 -delete        # 7일 이상 된 임시 파일 삭제
find / -name "core" -type f -size +100M 2>/dev/null -delete  # 코어 덤프 삭제

inode 고갈 해결

inode가 부족한 경우 소용량 파일이 대량으로 쌓인 디렉터리를 찾아 정리합니다.

# 디렉터리별 파일 수 확인
find / -xdev -type d 2>/dev/null | while read d; do
  echo "$(find "$d" -maxdepth 1 -type f | wc -l) $d"
done | sort -rn | head -20

# PHP 세션 파일 등 오래된 소용량 파일 정리 예시
find /var/lib/php/sessions -type f -mtime +7 -delete

4단계 — 재발 방지 설정

logrotate 설정 점검

로그가 무한정 쌓이지 않도록 logrotate가 올바르게 동작하는지 확인합니다.

cat /etc/logrotate.d/application   # 애플리케이션 logrotate 설정 확인
logrotate -d /etc/logrotate.conf   # 드라이런 — 실제 실행 없이 동작 확인

logrotate 설정의 핵심 항목은 rotate(보존 개수), size 또는 daily/weekly(순환 기준), compress(압축 여부)입니다.

디스크 사용률 모니터링 알림 설정

디스크가 80% 이상이 되면 미리 알림을 받도록 간단한 cron 스크립트를 설정합니다.

#!/bin/bash
THRESHOLD=80
df -h | grep -vE '^Filesystem|tmpfs|cdrom' | while read line; do
  USAGE=$(echo "$line" | awk '{print $5}' | tr -d '%')
  MOUNT=$(echo "$line" | awk '{print $6}')
  if [ "$USAGE" -ge "$THRESHOLD" ]; then
    echo "[ALERT] $MOUNT 디스크 사용률: ${USAGE}%" | \
    mail -s "[디스크 경고] $(hostname)" admin@example.com
  fi
done

# crontab에 등록 (매 시간 실행)
0 * * * * /usr/local/bin/disk_check.sh

마무리

리눅스 디스크 풀 문제는 당황스럽지만, df → du → lsof 순서로 범위를 좁혀가는 체계적 접근이면 대부분 빠르게 해결됩니다. 특히 삭제해도 공간이 안 줄어드는 lsof +L1 케이스와 inode 고갈은 놓치기 쉬운 함정이니 반드시 기억해 두세요. 사후 조치만큼 중요한 것이 logrotate와 모니터링 알림 설정을 통한 재발 방지입니다.

리눅스 파일 타임스탬프 완전 정복 — ctime, mtime, atime 차이점과 실무 활용법

Itlee — Wed, 18 Mar 2026 17:58:12 +0900

리눅스 파일에는 시간이 세 개 있다

리눅스에서 파일을 다루다 보면 ls -l 명령어로 날짜 정보를 확인할 때가 많습니다. 그런데 사실 리눅스 파일 시스템은 파일 하나당 세 가지 타임스탬프를 별도로 관리합니다. 바로 atime(접근 시간), mtime(수정 시간), ctime(변경 시간)입니다. 이 세 가지는 이름이 비슷해서 혼동하기 쉽지만, 각각 전혀 다른 상황에서 갱신됩니다.

단순히 개념을 아는 것을 넘어, 백업 스크립트 작성, 보안 감사, 성능 최적화 등 실무에서 이 차이를 정확히 알아야 하는 상황이 자주 생깁니다. 세 가지 타임스탬프의 정확한 정의와 동작 방식, 그리고 실무 활용법까지 정리합니다.

세 가지 타임스탬프 정의

atime — Access Time (접근 시간)

파일의 내용이 마지막으로 읽힌 시각입니다. cat, less, grep 등으로 파일 내용을 읽으면 atime이 갱신됩니다. 파일을 수정하지 않고 단순히 열어보기만 해도 변경된다는 점이 핵심입니다.

갱신 시점: 파일 내용 읽기 (cat, less, grep, cp의 소스 파일 등)
갱신되지 않는 경우: 파일 속성만 조회 (ls -l, stat)
주의: 현대 리눅스는 성능 이슈로 relatime 옵션을 기본 적용 — mtime이나 ctime보다 atime이 오래됐을 때만 갱신

mtime — Modify Time (수정 시간)

파일의 내용(데이터)이 마지막으로 변경된 시각입니다. 파일을 편집하거나 새로운 내용을 추가·삭제할 때 갱신됩니다. ls -l로 기본 출력되는 날짜가 바로 mtime입니다.

갱신 시점: 파일 내용 쓰기 (vi 저장, echo 리다이렉션, 프로그램이 파일에 데이터 기록)
갱신되지 않는 경우: 파일 권한 변경(chmod), 소유자 변경(chown), 파일명 변경(mv)
mtime이 변경되면 ctime도 반드시 함께 변경됨

ctime — Change Time (변경 시간)

파일의 inode 정보가 마지막으로 변경된 시각입니다. 여기서 많은 분들이 헷갈리는데, ctime은 "Created Time(생성 시간)"이 아닙니다. 파일 내용뿐 아니라 권한, 소유자, 링크 수 등 메타데이터 변경까지 모두 추적합니다.

갱신 시점: 파일 내용 변경(mtime 갱신 시 포함), chmod, chown, ln(하드링크 추가), mv(같은 파일 시스템 내)
갱신되지 않는 경우: 파일 내용 읽기만 하는 경우
ctime은 사용자가 임의로 변경할 수 없음 — 보안 감사에서 중요한 이유

타임스탬프 확인 방법

ls -l은 mtime만 보여줍니다. 세 가지 타임스탬프를 모두 확인하려면 stat 명령어를 사용합니다.

stat filename.txt

출력 예시는 다음과 같습니다.

  File: filename.txt
  Size: 1024
Access: 2025-03-15 09:00:00.000  ← atime
Modify: 2025-03-14 18:30:00.000  ← mtime
Change: 2025-03-14 18:30:05.000  ← ctime

각 타임스탬프를 기준으로 파일을 찾으려면 find 명령어의 옵션을 다르게 사용합니다.

find /var/log -mtime -1      # mtime 기준 — 최근 1일 이내 내용이 수정된 파일
find /etc -ctime -7          # ctime 기준 — 최근 7일 이내 속성이 변경된 파일
find /home -atime +30        # atime 기준 — 30일 이상 접근하지 않은 파일

atime 성능 이슈와 마운트 옵션

atime은 파일을 읽을 때마다 디스크에 쓰기 작업이 발생한다는 단점이 있습니다. 읽기 작업이 많은 서버에서는 이 오버헤드가 성능에 영향을 줄 수 있어, 리눅스는 마운트 옵션으로 atime 동작을 제어합니다.

strictatime: 파일 접근 시 항상 atime 갱신. 가장 정확하지만 성능 부하 최대.
relatime (기본값): mtime 또는 ctime보다 atime이 오래됐을 때만 갱신. 성능과 정확성의 균형.
noatime: atime을 전혀 갱신하지 않음. 성능 최적화 목적. 빈번한 읽기가 발생하는 고성능 서버에 적용.
nodiratime: 디렉터리의 atime만 갱신하지 않음.

# /etc/fstab에서 noatime 적용 예시
/dev/sda1  /  ext4  defaults,noatime  0 1

실무 활용 시나리오

백업 스크립트 — mtime 활용

증분 백업(Incremental Backup)을 구현할 때 mtime을 기준으로 변경된 파일만 선별합니다. 파일 내용이 실제로 바뀐 것만 추적하기 때문에 가장 정확합니다.

find /data -mtime -1 -type f | xargs tar -czf /backup/incremental_$(date +%F).tar.gz

보안 감사 — ctime 활용

해커가 파일 내용을 수정한 뒤 touch 명령으로 mtime을 위조하더라도, ctime은 시스템 내부에서 관리되므로 사용자가 임의로 변경할 수 없습니다. 침해사고 분석 시 ctime을 기준으로 의심 파일을 추려내는 이유가 여기에 있습니다.

# 최근 24시간 이내 ctime이 변경된 시스템 파일 탐지
find /etc /bin /usr/bin -ctime -1 -type f

스토리지 정리 — atime 활용

오랫동안 아무도 접근하지 않은 파일을 찾아 아카이브하거나 삭제할 때 atime을 기준으로 삼습니다.

# 180일 이상 접근하지 않은 파일 목록 출력
find /home -atime +180 -type f -ls

세 타임스탬프 비교 요약

atime: 파일 내용을 읽으면 갱신 / noatime으로 비활성화 가능 / 장기 미접근 파일 탐지에 활용
mtime: 파일 내용을 쓰면 갱신 / ls -l 기본 출력값 / 증분 백업 기준으로 활용
ctime: 내용·메타데이터 모두 변경 시 갱신 / 사용자 임의 변경 불가 / 보안 감사 기준으로 활용

마무리

ctime, mtime, atime은 단순한 날짜 정보가 아니라 파일 시스템이 파일의 상태 변화를 추적하는 핵심 메커니즘입니다. 세 가지의 차이를 명확히 이해하고 find 명령어와 조합하면 백업 자동화, 보안 감사, 스토리지 최적화 등 다양한 실무 작업의 정확도와 효율을 크게 높일 수 있습니다.

재해복구(DR) 센터 구축의 핵심 지표: RPO(목표 복구 시점)와 RTO(목표 복구 시간)의 이해

Itlee — Wed, 18 Mar 2026 17:55:17 +0900

재해복구, 숫자로 말해야 한다

장애가 발생했을 때 "최대한 빨리 복구하겠습니다"라는 말은 운영 계획이 아닙니다. 얼마나 빨리, 어느 시점까지라는 구체적인 수치가 있어야 비로소 복구 계획이 됩니다. 재해복구(DR, Disaster Recovery) 센터 구축의 출발점은 바로 두 가지 지표, RPO(Recovery Point Objective, 목표 복구 시점)와 RTO(Recovery Time Objective, 목표 복구 시간)를 정의하는 것입니다.

이 두 숫자는 DR 인프라의 규모, 비용, 기술 선택 전부를 결정하는 기준이 됩니다. 개념을 정확히 이해하고 자사 환경에 맞게 설정하는 방법을 정리합니다.

RPO란 무엇인가 — 데이터 손실을 얼마나 허용할 것인가

RPO는 재해 발생 시 어느 시점까지의 데이터를 복원할 수 있어야 하는가를 정의하는 지표입니다. 쉽게 말해, "데이터를 최대 몇 시간치까지 잃어도 괜찮은가"입니다.

RPO = 0: 데이터 손실 제로. 재해 발생 직전까지의 모든 데이터가 복원돼야 함. 실시간 동기 복제(Synchronous Replication) 필수.
RPO = 1시간: 최대 1시간치 데이터 손실 허용. 1시간 주기 비동기 복제 또는 스냅샷으로 대응 가능.
RPO = 24시간: 하루치 데이터 손실 허용. 일 1회 백업으로도 충족 가능.

RPO가 짧을수록 복제 주기가 짧아지고, 그만큼 네트워크 대역폭과 스토리지 비용이 증가합니다. 특히 RPO = 0을 목표로 하는 동기 복제는 DR 사이트와의 거리가 멀어질수록 네트워크 지연(Latency)으로 인해 운영계 성능에 직접 영향을 줄 수 있습니다.

RTO란 무엇인가 — 서비스를 얼마나 빨리 재개해야 하는가

RTO는 재해 발생 이후 서비스가 정상 운영으로 복구되기까지 허용되는 최대 시간입니다. "장애 발생부터 서비스 재개까지 몇 시간 안에 완료해야 하는가"로 이해하면 됩니다.

RTO = 수 분: Hot Standby 구성. DR 서버가 항상 가동 중이며 즉시 절체 가능. 가장 높은 비용.
RTO = 수 시간: Warm Standby 구성. DR 서버는 기동 상태지만 트래픽을 받지 않다가 장애 시 전환.
RTO = 수십 시간 이상: Cold Standby 구성. DR 서버는 꺼져 있으며 장애 시 부팅부터 시작. 비용은 낮지만 복구 시간이 김.

RTO가 짧을수록 DR 인프라를 운영계와 유사한 수준으로 상시 유지해야 하므로 비용이 급격히 올라갑니다. RTO 목표 설정 시에는 기술적 가능성뿐 아니라 서비스 중단으로 인한 비즈니스 손실 비용과 DR 구축·운영 비용을 함께 비교해야 합니다.

RPO·RTO와 DR 구성 방식의 관계

RPO와 RTO 목표값에 따라 적합한 DR 구성 방식이 달라집니다.

Active-Passive (Warm/Cold Standby)

운영 사이트가 장애 시 DR 사이트로 전환하는 구성입니다. DR 사이트는 평상시 트래픽을 처리하지 않습니다.

RPO: 복제 주기에 따라 수 분 ~ 수 시간
RTO: 수십 분 ~ 수 시간 (Warm), 수 시간 이상 (Cold)
비용: 중간 ~ 낮음

Active-Active (Hot Standby)

운영 사이트와 DR 사이트가 동시에 트래픽을 처리하며, 한쪽이 장애 나도 나머지가 즉시 전체 부하를 수용합니다.

RPO: 0 (동기 복제 기반)
RTO: 수 분 이내 (자동 절체 구성 시 수 초)
비용: 가장 높음 (운영계 동일 수준의 DR 인프라 필요)

백업 기반 DR (Backup & Restore)

정기 백업 데이터를 DR 사이트로 전송하고, 장애 시 복원하는 가장 기본적인 방식입니다.

RPO: 백업 주기에 따라 수 시간 ~ 24시간 이상
RTO: 수 시간 ~ 수십 시간 (데이터 규모에 따라 상이)
비용: 가장 낮음

RPO·RTO 설정 시 고려해야 할 사항

시스템 등급 분류부터 시작하라

모든 시스템에 동일한 RPO·RTO를 적용하는 것은 과잉 투자입니다. 시스템을 비즈니스 중요도에 따라 등급으로 분류하고, 등급별로 다른 목표값을 설정하는 것이 현실적입니다.

1등급 (Critical): 결제, 핵심 거래 시스템 — RPO 0~15분, RTO 15분~1시간
2등급 (Essential): 내부 업무 시스템 — RPO 1~4시간, RTO 4~8시간
3등급 (Normal): 개발·테스트 환경 — RPO 24시간, RTO 24~48시간

목표값은 반드시 실제 훈련으로 검증하라

문서상의 RTO와 실제 복구에 걸리는 시간은 다를 수 있습니다. 정기적인 DR 훈련(DRT, Disaster Recovery Test)을 통해 목표값이 실제로 달성 가능한지 검증하고, 미달 시 구성을 보완해야 합니다. 연 1회 이상 실전 절체 훈련을 수행하는 것을 권장합니다.

마무리

RPO와 RTO는 DR 구축의 시작이자 끝입니다. 이 두 숫자가 명확하지 않으면 DR 인프라에 얼마를 투자해야 하는지, 어떤 기술을 선택해야 하는지 결정할 수 없습니다. 비즈니스 요구사항을 기반으로 RPO·RTO를 먼저 정의하고, 그에 맞는 기술과 인프라를 역순으로 설계하는 접근법이 성공적인 DR 구축의 핵심입니다.

리눅스 시스템 엔지니어 필수 네트워크 트러블슈팅 명령어 완전 정복

Itlee — Wed, 18 Mar 2026 17:45:03 +0900

네트워크 문제, 어디서부터 시작해야 할까?

리눅스 서버를 운영하다 보면 "갑자기 외부에서 접속이 안 된다", "특정 포트가 응답하지 않는다", "패킷이 어디선가 막힌다" 같은 상황을 반드시 마주치게 됩니다. 이럴 때 당황하지 않고 체계적인 순서로 명령어를 실행할 수 있느냐가 숙련된 엔지니어와 그렇지 않은 사람의 차이입니다.

이 글에서는 실무에서 자주 쓰는 네트워크 트러블슈팅 명령어를 레이어별로 정리하고, 각 명령어가 어떤 상황에서 유효한지 함께 설명합니다.

1단계 — 기본 연결 확인: ping / traceroute

가장 먼저 해야 할 건 물리적·논리적 연결 자체가 살아있는지 확인하는 것입니다.

ping

ICMP 패킷을 보내 응답 시간과 패킷 손실률을 확인합니다.

ping -c 4 8.8.8.8          # 4번만 보내고 종료
ping -i 0.2 -c 20 192.168.1.1  # 0.2초 간격으로 20번 전송

응답 없음: 방화벽에서 ICMP가 차단됐거나 호스트 자체가 다운된 상태
패킷 손실 발생: 네트워크 구간 어딘가에 불안정한 링크 존재
RTT가 비정상적으로 높음: 대역폭 포화 또는 라우팅 문제 의심

traceroute / tracepath

패킷이 목적지까지 어느 경로로 이동하는지, 어느 구간에서 지연이 발생하는지 확인합니다.

traceroute -n 8.8.8.8        # DNS 조회 없이 IP로만 표시 (빠름)
tracepath google.com          # 루트 권한 없이 사용 가능

특정 홉(hop)에서 * * *가 반복된다면 해당 구간에서 패킷이 차단되거나 응답하지 않는 것입니다. 그 이후 홉이 정상이면 단순 ICMP 차단일 가능성이 높습니다.

2단계 — 인터페이스 및 라우팅 확인: ip / ss / netstat

ip 명령어

ifconfig는 구형 명령어입니다. 현대 리눅스에서는 ip 명령어를 사용하는 것이 표준입니다.

ip addr show                  # 전체 인터페이스 IP 확인
ip addr show eth0             # 특정 인터페이스만 확인
ip link show                  # 인터페이스 UP/DOWN 상태 확인
ip route show                 # 라우팅 테이블 전체 출력
ip route get 8.8.8.8          # 특정 목적지로 가는 경로 확인

ip route get은 특정 IP로 트래픽이 어느 인터페이스를 통해 나가는지 한 줄로 보여주는 매우 실용적인 명령어입니다.

ss — 소켓 상태 확인

netstat의 후속 명령어로 훨씬 빠르고 상세한 정보를 제공합니다.

ss -tlnp          # TCP 리스닝 포트 + 프로세스 이름
ss -ulnp          # UDP 리스닝 포트
ss -s             # 소켓 통계 요약
ss -tnp state established  # 현재 연결된 TCP 세션 전체

-t: TCP, -u: UDP
-l: 리스닝 상태만, -n: 숫자(IP/포트)로 표시, -p: 프로세스 정보 포함

3단계 — DNS 문제 진단: dig / nslookup / resolvectl

외부 접속이 안 될 때 DNS 해석 자체가 실패하는 경우가 생각보다 많습니다.

dig

가장 상세한 DNS 조회 결과를 보여주는 표준 도구입니다.

dig google.com                     # 기본 A 레코드 조회
dig google.com MX                  # MX 레코드 조회
dig @8.8.8.8 google.com            # 특정 DNS 서버(8.8.8.8)에 직접 질의
dig +short google.com              # IP 결과만 간단히 출력
dig +trace google.com              # 루트 DNS부터 전체 해석 과정 추적

dig +trace는 DNS 위임 체계 전체를 추적하므로, 특정 레코드가 왜 잘못 응답되는지 원인을 찾을 때 매우 유용합니다.

resolvectl (systemd-resolved 환경)

resolvectl status          # 현재 DNS 설정 및 상태 확인
resolvectl query google.com  # DNS 조회

4단계 — 포트 및 서비스 연결 확인: telnet / nc / curl

nc (netcat) — 포트 연결 테스트

특정 호스트의 포트가 열려있는지 가장 직접적으로 확인하는 방법입니다.

nc -zv 192.168.1.100 80       # TCP 포트 80 열려있는지 확인
nc -zv -u 192.168.1.100 53    # UDP 포트 53 확인
nc -zv 192.168.1.100 8080-8090  # 포트 범위 스캔

curl — HTTP/HTTPS 레벨 진단

curl -v https://example.com              # 전체 요청/응답 헤더 출력
curl -I https://example.com             # 헤더만 확인
curl -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
# 응답코드와 응답시간만 출력
curl --resolve example.com:443:1.2.3.4 https://example.com
# 특정 IP로 강제 접속 (DNS 우회 테스트)

5단계 — 패킷 수준 분석: tcpdump

위 명령어로도 원인을 찾지 못했다면 실제 패킷을 직접 들여다봐야 합니다.

tcpdump -i eth0 -nn               # eth0 인터페이스 전체 패킷 캡처
tcpdump -i eth0 port 80 -nn       # 80 포트 트래픽만 필터
tcpdump -i eth0 host 192.168.1.100 -nn  # 특정 호스트 트래픽만
tcpdump -i eth0 -w /tmp/capture.pcap    # 파일로 저장 (Wireshark 분석용)

-nn 옵션은 DNS 역조회와 포트명 변환을 생략해 출력 속도를 높여줍니다. 실시간 트래픽이 많은 환경에서는 필수 옵션입니다.

트러블슈팅 흐름 정리

네트워크 문제를 만났을 때 아래 순서로 접근하면 빠르게 원인을 좁힐 수 있습니다.

1. ping — 기본 연결 확인
2. traceroute — 경로 및 지연 구간 확인
3. ip addr / ip route — 인터페이스, 라우팅 테이블 점검
4. ss -tlnp — 서비스가 포트를 정상적으로 리스닝하는지 확인
5. dig — DNS 해석 문제 여부 확인
6. nc / curl — 실제 포트 및 HTTP 응답 확인
7. tcpdump — 패킷 레벨 분석으로 최종 원인 규명

마무리

네트워크 트러블슈팅은 레이어를 낮춰가며 원인을 좁히는 과정입니다. 모든 명령어를 외울 필요는 없지만, 각 명령어가 OSI 어느 계층을 담당하는지 이해하고 있다면 문제 상황에서 빠르게 판단할 수 있습니다. 여기서 소개한 명령어들을 테스트 환경에서 직접 실행해보며 익혀두는 것을 강력히 권장합니다.

IBM Spectrum Scale(GPFS) 성능 모니터링 및 트러블슈팅 실전 노하우 완전 정리

Itlee — Wed, 18 Mar 2026 17:41:25 +0900

IBM Spectrum Scale(GPFS)란 무엇인가?

IBM Spectrum Scale(구 GPFS, General Parallel File System)은 IBM이 개발한 고성능 병렬 분산 파일 시스템입니다. 수천 개의 노드가 동시에 하나의 파일 시스템에 접근할 수 있으며, HPC(고성능 컴퓨팅), 빅데이터 분석, AI 워크로드 환경에서 폭넓게 사용됩니다. 페타바이트 규모의 데이터를 안정적으로 처리할 수 있다는 점이 핵심 강점이지만, 그만큼 성능 문제가 발생했을 때 원인을 찾는 과정이 복잡합니다.

이 글에서는 실무 운영 환경에서 바로 적용할 수 있는 Spectrum Scale 성능 모니터링 방법과 자주 발생하는 문제의 트러블슈팅 접근법을 정리합니다.

기본 상태 점검 명령어

Spectrum Scale 문제가 발생하면 가장 먼저 클러스터 전체의 기본 상태를 확인해야 합니다.

클러스터 및 노드 상태 확인

mmgetstate -a                  # 전체 노드의 GPFS 데몬 상태 확인
mmlscluster                    # 클러스터 기본 정보 출력
mmlsnode -a                    # 노드 목록 및 역할 확인
mmdiag --network               # 네트워크 연결 상태 진단

mmgetstate -a 실행 시 노드 상태가 active가 아닌 arbitrating이나 down으로 표시된다면 해당 노드부터 우선 점검해야 합니다.

파일 시스템 상태 확인

mmlsfs all                     # 전체 파일 시스템 설정 정보
mmlsmount all -L               # 마운트 상태 및 마운트된 노드 확인
mmlsdisk  -L          # 디스크(NSD) 상태 확인
mmdf                  # 파일 시스템 사용량 확인

mmlsdisk에서 디스크 상태가 failed 또는 missing으로 표시되면 즉각 스토리지 레이어를 점검해야 합니다. 이 상태가 지속되면 데이터 접근 불가 또는 성능 급저하로 이어집니다.

성능 모니터링: mmpmon 활용

Spectrum Scale의 핵심 성능 모니터링 도구는 mmpmon입니다. 실시간으로 I/O 통계를 수집하고 분석할 수 있습니다.

기본 I/O 통계 수집

echo "io_s" | mmpmon -p -r 0   # 전체 I/O 통계 출력
echo "fs_io_s" | mmpmon -p -r 0  # 파일 시스템별 I/O 통계
echo "nsd_io_s" | mmpmon -p -r 0  # NSD(디스크)별 I/O 통계

출력 항목 중 주목해야 할 값은 다음과 같습니다.

_br_ / _bw_: 읽기/쓰기 바이트 수 (처리량 확인)
_rdc_ / _wrc_: 읽기/쓰기 요청 횟수
_oc_: open 호출 횟수 (메타데이터 부하 지표)
_cc_: close 호출 횟수

주기적 통계 수집 스크립트

실시간 추이를 보려면 일정 간격으로 mmpmon을 반복 실행해 비교하는 방식이 효과적입니다.

#!/bin/bash
while true; do
  echo "=== $(date '+%Y-%m-%d %H:%M:%S') ==="
  echo "fs_io_s" | mmpmon -p -r 0 | grep "_fs_io_s_"
  sleep 10
done

이 스크립트를 백그라운드로 실행하면서 성능 이슈 발생 전후 값을 비교하면 어느 파일 시스템에서 부하가 집중되는지 빠르게 파악할 수 있습니다.

메타데이터 성능 문제 진단

Spectrum Scale 환경에서 성능 저하의 원인 중 상당수는 메타데이터 병목입니다. 특히 소용량 파일이 수백만 개 이상 존재하거나, open/stat/readdir 호출이 집중될 때 발생합니다.

메타데이터 관련 점검

mmlsconfig  | grep -i meta  # 메타데이터 설정 확인
mmlsfileset  -L             # 필레셋 구성 확인
echo "io_s" | mmpmon -p -r 0 | grep _oc_  # open 호출 횟수 확인

메타데이터 전용 NSD가 분리되어 있는지 확인 (메타데이터와 데이터 디스크 분리는 성능의 핵심)
inode 크기 설정이 워크로드에 적합한지 검토 (기본값 4096 bytes)
디렉터리 내 파일 수가 수십만 개를 넘는 경우 해시 디렉터리 구조 적용 검토

네트워크 성능 문제 진단

GPFS는 노드 간 통신에 인터커넥트 네트워크를 적극 활용합니다. InfiniBand 또는 이더넷 성능 저하가 전체 파일 시스템 성능에 직접 영향을 줍니다.

네트워크 진단 명령어

mmdiag --network               # 클러스터 내 노드 간 네트워크 연결 진단
mmnetverify                    # 네트워크 성능 검증 (패킷 손실, 대역폭)
mmlsconfig | grep subnets      # 서브넷 구성 확인

InfiniBand 환경이라면 별도로 ibstat, perfquery 명령어로 포트 상태와 오류 카운터를 확인하고, 오류 카운터가 지속적으로 증가하면 케이블 또는 HCA 교체를 검토해야 합니다.

자주 발생하는 문제와 해결 방법

1. 파일 시스템 마운트 불가

mmgetstate -a로 모든 노드 데몬 상태 확인
쿼럼(Quorum) 미달 여부 점검 — 전체 노드의 과반수 이상이 active 상태여야 마운트 가능
/var/adm/ras/mmfs.log.latest 로그에서 구체적 오류 메시지 확인

2. 특정 노드에서 성능 저하

해당 노드의 CPU, 메모리, 네트워크 사용률 확인 (top, sar, ss)
mmdiag --network로 해당 노드의 네트워크 연결 상태 점검
pagepool 설정 확인: mmlsconfig | grep pagepool (권장값: 물리 메모리의 25~50%)

3. 디스크 응답 지연

mmlsdisk -L로 NSD 상태 확인
스토리지 컨트롤러 레벨에서 I/O 대기 시간(latency) 별도 모니터링
NSD 서버 노드 부하 집중 여부 확인 후 NSD 서버 분산 검토

핵심 로그 파일 위치

트러블슈팅 시 반드시 확인해야 하는 로그 파일 경로입니다.

/var/adm/ras/mmfs.log.latest: GPFS 데몬 메인 로그 (가장 중요)
/var/adm/ras/mmfs.log.previous: 이전 로그 (재시작 전 이벤트 추적)
/var/log/messages: 커널 및 시스템 레벨 이벤트 확인

마무리

IBM Spectrum Scale은 강력한 만큼 운영 복잡도도 높습니다. 평소에 mmpmon으로 베이스라인 성능 수치를 축적해두는 것이 가장 중요합니다. 문제가 발생했을 때 비교할 기준값이 없으면 트러블슈팅 시간이 크게 늘어납니다. 클러스터 상태 점검, 성능 통계 수집, 로그 분석을 루틴화하면 대부분의 문제를 조기에 발견하고 대응할 수 있습니다.

리눅스 시스템 엔지니어를 위한 필수 네트워크 트러블슈팅 명령어 총정리

Itlee — Wed, 18 Mar 2026 17:36:46 +0900

네트워크 문제, 어디서부터 시작해야 할까?

이 글에서는 실무에서 자주 쓰는 네트워크 트러블슈팅 명령어를 레이어별로 정리하고, 각 명령어가 어떤 상황에서 유효한지 함께 설명합니다.

1단계 — 기본 연결 확인: ping / traceroute

가장 먼저 해야 할 건 물리적·논리적 연결 자체가 살아있는지 확인하는 것입니다.

ping

ICMP 패킷을 보내 응답 시간과 패킷 손실률을 확인합니다.

ping -c 4 8.8.8.8          # 4번만 보내고 종료
ping -i 0.2 -c 20 192.168.1.1  # 0.2초 간격으로 20번 전송

응답 없음: 방화벽에서 ICMP가 차단됐거나 호스트 자체가 다운된 상태
패킷 손실 발생: 네트워크 구간 어딘가에 불안정한 링크 존재
RTT가 비정상적으로 높음: 대역폭 포화 또는 라우팅 문제 의심

traceroute / tracepath

패킷이 목적지까지 어느 경로로 이동하는지, 어느 구간에서 지연이 발생하는지 확인합니다.

traceroute -n 8.8.8.8        # DNS 조회 없이 IP로만 표시 (빠름)
tracepath google.com          # 루트 권한 없이 사용 가능

2단계 — 인터페이스 및 라우팅 확인: ip / ss / netstat

ip 명령어

ifconfig는 구형 명령어입니다. 현대 리눅스에서는 ip 명령어를 사용하는 것이 표준입니다.

ip addr show                  # 전체 인터페이스 IP 확인
ip addr show eth0             # 특정 인터페이스만 확인
ip link show                  # 인터페이스 UP/DOWN 상태 확인
ip route show                 # 라우팅 테이블 전체 출력
ip route get 8.8.8.8          # 특정 목적지로 가는 경로 확인

ip route get은 특정 IP로 트래픽이 어느 인터페이스를 통해 나가는지 한 줄로 보여주는 매우 실용적인 명령어입니다.

ss — 소켓 상태 확인

netstat의 후속 명령어로 훨씬 빠르고 상세한 정보를 제공합니다.

ss -tlnp          # TCP 리스닝 포트 + 프로세스 이름
ss -ulnp          # UDP 리스닝 포트
ss -s             # 소켓 통계 요약
ss -tnp state established  # 현재 연결된 TCP 세션 전체

-t: TCP, -u: UDP
-l: 리스닝 상태만, -n: 숫자(IP/포트)로 표시, -p: 프로세스 정보 포함

3단계 — DNS 문제 진단: dig / nslookup / resolvectl

외부 접속이 안 될 때 DNS 해석 자체가 실패하는 경우가 생각보다 많습니다.

dig

가장 상세한 DNS 조회 결과를 보여주는 표준 도구입니다.

dig google.com                     # 기본 A 레코드 조회
dig google.com MX                  # MX 레코드 조회
dig @8.8.8.8 google.com            # 특정 DNS 서버(8.8.8.8)에 직접 질의
dig +short google.com              # IP 결과만 간단히 출력
dig +trace google.com              # 루트 DNS부터 전체 해석 과정 추적

dig +trace는 DNS 위임 체계 전체를 추적하므로, 특정 레코드가 왜 잘못 응답되는지 원인을 찾을 때 매우 유용합니다.

resolvectl (systemd-resolved 환경)

resolvectl status          # 현재 DNS 설정 및 상태 확인
resolvectl query google.com  # DNS 조회

4단계 — 포트 및 서비스 연결 확인: telnet / nc / curl

nc (netcat) — 포트 연결 테스트

특정 호스트의 포트가 열려있는지 가장 직접적으로 확인하는 방법입니다.

nc -zv 192.168.1.100 80       # TCP 포트 80 열려있는지 확인
nc -zv -u 192.168.1.100 53    # UDP 포트 53 확인
nc -zv 192.168.1.100 8080-8090  # 포트 범위 스캔

curl — HTTP/HTTPS 레벨 진단

curl -v https://example.com              # 전체 요청/응답 헤더 출력
curl -I https://example.com             # 헤더만 확인
curl -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
# 응답코드와 응답시간만 출력
curl --resolve example.com:443:1.2.3.4 https://example.com
# 특정 IP로 강제 접속 (DNS 우회 테스트)

5단계 — 패킷 수준 분석: tcpdump

위 명령어로도 원인을 찾지 못했다면 실제 패킷을 직접 들여다봐야 합니다.

tcpdump -i eth0 -nn               # eth0 인터페이스 전체 패킷 캡처
tcpdump -i eth0 port 80 -nn       # 80 포트 트래픽만 필터
tcpdump -i eth0 host 192.168.1.100 -nn  # 특정 호스트 트래픽만
tcpdump -i eth0 -w /tmp/capture.pcap    # 파일로 저장 (Wireshark 분석용)

-nn 옵션은 DNS 역조회와 포트명 변환을 생략해 출력 속도를 높여줍니다. 실시간 트래픽이 많은 환경에서는 필수 옵션입니다.

트러블슈팅 흐름 정리

네트워크 문제를 만났을 때 아래 순서로 접근하면 빠르게 원인을 좁힐 수 있습니다.

1. ping — 기본 연결 확인
2. traceroute — 경로 및 지연 구간 확인
3. ip addr / ip route — 인터페이스, 라우팅 테이블 점검
4. ss -tlnp — 서비스가 포트를 정상적으로 리스닝하는지 확인
5. dig — DNS 해석 문제 여부 확인
6. nc / curl — 실제 포트 및 HTTP 응답 확인
7. tcpdump — 패킷 레벨 분석으로 최종 원인 규명

마무리

Bash 쉘 스크립트로 리눅스 서버 일일 점검(Daily Check) 완전 자동화하기

Itlee — Wed, 18 Mar 2026 17:33:58 +0900

왜 서버 일일 점검을 자동화해야 할까?

리눅스 서버를 운영하다 보면 매일 반복해야 하는 점검 항목들이 있습니다. CPU 사용률은 정상인지, 디스크가 꽉 차가고 있지는 않은지, 핵심 서비스는 살아있는지 — 이걸 매일 수작업으로 확인하는 건 시간 낭비이자 실수의 원인이 됩니다. Bash 쉘 스크립트와 cron을 조합하면 이 모든 점검을 완전 자동화하고, 이상 발생 시 즉시 알림까지 받을 수 있습니다.

이 글에서는 실무에서 바로 쓸 수 있는 Daily Check 스크립트를 단계별로 구성하는 방법을 다룹니다.

점검 항목 설계

일일 점검 스크립트는 크게 5가지 영역을 커버해야 합니다.

시스템 리소스: CPU, 메모리, Load Average
디스크 사용량: 마운트 포인트별 사용률
서비스 상태: nginx, mysql, sshd 등 핵심 데몬
네트워크: 포트 오픈 여부, 외부 통신 가능 여부
로그 이상 감지: /var/log/syslog에서 ERROR, CRITICAL 키워드 탐지

스크립트 전체 구조

아래는 실무에서 사용할 수 있는 daily_check.sh의 전체 구조입니다. 각 섹션별로 함수로 분리해서 유지보수가 쉽게 작성했습니다.

기본 설정 및 변수 선언

#!/bin/bash
# daily_check.sh — 리눅스 서버 일일 점검 스크립트

DATE=$(date '+%Y-%m-%d %H:%M:%S')
HOSTNAME=$(hostname)
LOG_FILE="/var/log/daily_check.log"
ALERT_EMAIL="admin@example.com"
CPU_THRESHOLD=80
MEM_THRESHOLD=85
DISK_THRESHOLD=90

RESULT=""
ALERT=0

log() {
  echo "[$DATE] $1" | tee -a "$LOG_FILE"
  RESULT+="$1\n"
}

CPU / 메모리 점검 함수

check_cpu() {
  log "=== CPU 점검 ==="
  CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1 | cut -d',' -f1)
  CPU_INT=${CPU_USAGE%.*}
  if [ "$CPU_INT" -ge "$CPU_THRESHOLD" ]; then
    log "[WARNING] CPU 사용률 높음: ${CPU_USAGE}%"
    ALERT=1
  else
    log "[OK] CPU 사용률: ${CPU_USAGE}%"
  fi
}

check_memory() {
  log "=== 메모리 점검 ==="
  MEM_TOTAL=$(free -m | awk '/Mem:/{print $2}')
  MEM_USED=$(free -m | awk '/Mem:/{print $3}')
  MEM_PERCENT=$(echo "scale=1; $MEM_USED * 100 / $MEM_TOTAL" | bc)
  MEM_INT=${MEM_PERCENT%.*}
  if [ "$MEM_INT" -ge "$MEM_THRESHOLD" ]; then
    log "[WARNING] 메모리 사용률 높음: ${MEM_PERCENT}% (${MEM_USED}MB / ${MEM_TOTAL}MB)"
    ALERT=1
  else
    log "[OK] 메모리 사용률: ${MEM_PERCENT}%"
  fi
}

디스크 점검 함수

check_disk() {
  log "=== 디스크 점검 ==="
  df -h --output=pcent,target | tail -n +2 | while read -r line; do
    USAGE=$(echo "$line" | awk '{print $1}' | tr -d '%')
    MOUNT=$(echo "$line" | awk '{print $2}')
    if [ "$USAGE" -ge "$DISK_THRESHOLD" ]; then
      log "[WARNING] 디스크 사용률 높음: $MOUNT — ${USAGE}%"
      ALERT=1
    else
      log "[OK] $MOUNT — ${USAGE}%"
    fi
  done
}

서비스 상태 점검 함수

SERVICES=("nginx" "mysql" "sshd" "cron")

check_services() {
  log "=== 서비스 상태 점검 ==="
  for SERVICE in "${SERVICES[@]}"; do
    if systemctl is-active --quiet "$SERVICE"; then
      log "[OK] $SERVICE: 실행 중"
    else
      log "[CRITICAL] $SERVICE: 중지됨!"
      ALERT=1
    fi
  done
}

로그 이상 감지 및 알림 발송

check_logs() {
  log "=== 로그 이상 감지 ==="
  ERROR_COUNT=$(grep -c -iE "error|critical|failed" /var/log/syslog 2>/dev/null || echo 0)
  log "최근 syslog ERROR/CRITICAL 건수: ${ERROR_COUNT}건"
  if [ "$ERROR_COUNT" -gt 10 ]; then
    log "[WARNING] 오류 로그 다수 감지"
    ALERT=1
  fi
}

send_alert() {
  if [ "$ALERT" -eq 1 ]; then
    echo -e "$RESULT" | mail -s "[ALERT] $HOSTNAME 일일 점검 이상 감지 — $DATE" "$ALERT_EMAIL"
    log "알림 이메일 발송 완료: $ALERT_EMAIL"
  else
    log "모든 점검 정상. 알림 없음."
  fi
}

# 메인 실행
log "=============================="
log "서버 일일 점검 시작: $HOSTNAME"
log "=============================="
check_cpu
check_memory
check_disk
check_services
check_logs
send_alert
log "점검 완료"

cron으로 매일 자동 실행 설정

스크립트 작성이 끝났다면 실행 권한을 부여하고 cron에 등록합니다.

chmod +x /usr/local/bin/daily_check.sh
crontab -e

crontab에 아래 줄을 추가하면 매일 오전 8시에 자동 실행됩니다.

0 8 * * * /usr/local/bin/daily_check.sh >> /var/log/daily_check.log 2>&1

실무 활용 팁

알림 채널 확장: mail 대신 curl로 Slack Webhook이나 Telegram Bot API를 호출하면 모바일로 즉시 알림을 받을 수 있습니다.
점검 항목 모듈화: 함수 단위로 분리되어 있으므로 서버 역할에 따라 필요한 함수만 골라서 실행할 수 있습니다.
로그 로테이션: logrotate 설정으로 daily_check.log가 무한정 쌓이지 않도록 관리하세요.
임계값 외부화: 임계값 변수를 별도 설정 파일(.conf)로 분리하면 스크립트 수정 없이 값을 바꿀 수 있습니다.

마무리

Bash 스크립트 하나로 CPU, 메모리, 디스크, 서비스, 로그까지 한 번에 점검하고 이상 시 자동 알림까지 보내는 시스템을 구축할 수 있습니다. 처음에는 단순한 스크립트로 시작해서 운영 환경에 맞게 점진적으로 확장하는 것이 가장 현실적인 접근 방법입니다. 서버가 늘어날수록 자동화의 가치는 더욱 커집니다.

부부 공동 미국 배당주 엑셀 템플릿 공유 (배당금/추가투자/재투자 자동 집계)

Itlee — Thu, 8 Jan 2026 17:26:12 +0900

미국 배당주를 와이프랑 같이 투자하다 보니,
“이번 달 배당금이 얼마였지?”, “추가로 넣은 돈은?”, “배당금 재투자는 얼마나 했지?”
이걸 매달 정리하는 게 은근 번거롭더라고요.

그래서 부부 공동으로 관리하기 좋은 배당주 엑셀 템플릿을 만들었습니다.
거래내역만 입력하면 월별/연간으로 배당금(세후), 추가 투자, 배당금 재투자가 자동으로 집계되게 구성했어요.

✅ 이런 분들에게 추천

부부(또는 2명이) 함께 미국 배당주 투자하면서 각자 실적을 분리해서 보고 싶은 분
**배당금(세후)**과 추가 투자금, 배당 재투자를 한 번에 정리하고 싶은 분
월별로 **원화 환산(KRW)**까지 같이 보고 싶은 분

템플릿 구성 (시트 설명)

1) 설정

시작년도
기본 환율(USD→KRW)
사람 목록(예: 철수/영희)
티커 목록(JEPQ, JEPI 등) 관리
티커를 늘리고 싶으면 여기 목록에 추가해두면 드롭다운에 자동으로 잡혀요.

2) 환율

YYYY-MM별 환율 입력용 시트
월별로 환율이 다르면 원화 환산도 그에 맞게 자동 반영됩니다.

3) 거래내역 (✅ 여기만 입력하면 끝)

한 줄이 “이벤트 1개”예요.

BUY : 추가 매수(현금 투입)
REINVEST : 배당금으로 재투자 매수
DIV : 배당금 수령 (세후 실수령 기준 추천)
FEE : 수수료(선택)

금액 입력도 편하게 두 가지 방식으로 가능해요.

금액(USD)만 바로 입력
또는
수량(주) + 단가(USD) 입력 → 금액 자동 계산

4) 월별요약_철수 / 월별요약_영희

사람별로 자동 집계됩니다.

배당금(세후) DIV
추가 투자금(현금투입) BUY
배당금 재투자 REINVEST

각각이 티커별 1~12월 / 연간 합계 / 비중(%)까지 자동 계산돼요.

5) 대시보드

사람별 월별 배당금(세후, KRW) 그래프
연간 합계 확인

✍️ 사용 방법(진짜 간단)

배당 들어오면 → 거래내역에 DIV 입력
배당 재투자했으면 → 거래내역에 REINVEST 입력
생활비/추가자금으로 매수했으면 → 거래내역에 BUY 입력
한 달에 한 번 정도 → 환율 시트에 평균 환율 입력

다운로드

※ 파일은 아래에서 다운로드하세요. (비밀번호는 구독하시고 댓글 작성해주시면 쪽지드려요)

미국배당_부부_트래커.xlsx

0.06MB

linux disk 삭제 쉘

Itlee — Wed, 22 Oct 2025 11:28:55 +0900

DR 구성 환경에서 발생한 디스크 인식 문제 대응

DR(Disaster Recovery) 구성된 VM위에 Linux 서버에서 DR 스토리지를 Split한 뒤,
간헐적으로 디스크가 인식되지 않는 버그가 발생했다.

이 문제를 해결하기 위해,
DR 복제 중인 디스크를 제거한 후 rescan 명령으로 재인식시키는 자동화 스크립트를 작성하였다.
아래의 쉘 스크립트는 RDM(Raw Device Mapping) 형태로 연결된 IBM 스토리지 디스크를
자동으로 삭제 후 재인식시키는 역할을 수행한다.

디스크 재 인식 쉘

#!/bin/bash

### disk info ###
RDM_LIST="lsscsi | grep IBM"
RDM_DISK='lsscsi | grep IBM | awk '{print $6}' | cut -c 6-8'

#1. List RDM Disk
echo "### 1. RDM Disk List ###"
lsscsi | grep IBM

#2 Delete RDM Disk
echo "###2. Delete RDM Disk info ###"
for RDM_DISK in $RDM_DISK
do
echo "1" > /sys/block/$RDM_DISK/device/delete;
done


#3. After Disk List
echo "### 3. After Delete RDM Disk ###"
lsscsi

#4. Re-attach RDM DISK
echo "### 4. Re-attach RDM DISK ###"

/bin/scsi-rescan -a

#5. Final RDM disk list
echo "### 5. Final RDM DISK info ###"
lsscsi | grep IBM

echo "FINISH!"

AIX GPFS에서 NSD 추가 및 제거 하기

Itlee — Tue, 27 May 2025 09:58:18 +0900

1. 신규 디스크 준비 & NSD 생성

스토리지에서 1 TB LUN을 호스트에 매핑
AIX에서 cfgmgr로 신규 hdisk 인식
NSD 정의용 파일 작성(nsd_file)

/dev/hdiskXX:nsd_new01:::dataAndMetadata:1

4. NSD 생성

mmcrnsd -F nsd_file

5. 파일시스템에 추가

mmadddisk <filesystem> nsd_new01

다수의 디스크를 병렬로 추가할 때는 mmadddisk -r 5 옵션으로 추가/재밸런스 동시에 수행 가능

2. 제거 대상 디스크 I/O 중지

파일시스템당 LUN이 약 70 개라면 한 번에 1 개씩 suspend하여 동작 확인 → 이후 5~10 개씩 묶어 진행
Suspend 명령

mmchdisk <filesystem> suspend -d <nsd_old##>

mmlsdisk <filesystem> -L 로 상태가 suspended인지 확인

3. 데이터 재밸런스

mmrestripefs <filesystem> -r

mmrestripefs -r 는 suspend된 디스크를 제외하고 데이터를 균등하게 재분배
진행 상태는 mmdf <filesystem> -r 또는 mmrestripefs -q 로 모니터링

4. 파일시스템에서 디스크 삭제

재밸런스가 완료된 뒤:

mmdeldisk <filesystem> <nsd_old##>

mmlsdisk로 status=deleted 확인

5. NSD 정의 삭제

mmdelnsd <nsd_old##>

6. AIX 장치 제거

rmdev -dl <hdiskXX>

ODM에서 삭제된 뒤 lsdev -Cc disk 로 사라졌는지 재확인
다중경로(MPIO) 사용 시 lsmpio 또는 lspath로 경로가 남아 있지 않은지 점검

7. 마무리 점검 리스트

점검명령기대 결과

파일시스템 상태	mmlsfs <filesystem> -f	삭제한 NSD 미표시
디스크 목록	mmlsdisk <filesystem>	status=ok 디스크만 존재
클러스터 헬스	mmhealth node show	모든 노드 OK

실전 팁

백업: 명령 실행 전 mmlsbkpfs 로 구성 백업을 남겨두면 롤백 가능성이 높아집니다.
병렬 처리: 대량 디스크 삭제 시 mmchdisk -a suspend 후 mmrestripefs -p <num_threads> 로 속도 향상.
로그: /var/adm/mmfs/log 경로나 /tmp/mmfs.* 파일을 모니터링해 이상 여부 즉시 파악.

HPE ProLiant server - BIOS에서 코어 수 줄이는 완전 가이드

Itlee — Wed, 21 May 2025 09:30:36 +0900

Enabled Cores per Processor 옵션을 이용해 소켓당 활성 코어 개수를 4개로 낮춘 실제 캡처를 기반으로 정리했습니다. 라이선스 이슈, 전력/발열 제약, 특정 워크로드 튜닝 등 “코어 다이어트”가 필요한 상황에서 그대로 복사-붙여넣기 해도 될 만큼 단계별로 담았습니다.

1. 왜 코어를 줄일까?

사용 사례기대 효과

코어 기반 라이선스(Oracle, vSphere Essentials 등)	과금 범위 최소화
전력 한도 또는 발열 관리	소비전력·쿨링 비용 절감
일부 싱글-스레드 왕귀 워크로드	터보 부스트 헤드룸 확보
테스트·디버그 환경	CPU 자원 고정으로 시나리오 재현

2. 테스트 환경

서버: HPE ProLiant DL380 Gen11 (System ROM U54 v2.44)
CPU: Intel Xeon Gold 5415+ (16C/32T)
Firmware: iLO 6 2.90
OS 검증: CentOS 7.9 (커널 3.10.0-1160.el7)
목표: 소켓당 4 코어 + Hyper-Threading 유지

3. 단계별 작업 - BIOS (UEFI System Utilities)

캡처단계

그림 1 – System Utilities 메인	① 재부팅 → POST 중 F9 → System Utilities 진입
그림 2 – System Configuration 선택	② System Configuration 선택
그림 3 – RBSU 진입	③ BIOS/Platform Configuration (RBSU) 클릭
그림 4 – Processor Options 상세	④ Processor Options ▸ Enabled Cores per Processor ⑤ 원하는 숫자(예: 4) 입력 → F10 Save ⑥ F12 Save and Exit → Reboot

TIP 0 또는 CPU가 지원하지 않는 값을 넣으면 전 코어가 다시 활성화됩니다.
절반·쿼터처럼 배수로만 제한되던 Gen10 이전 세대와 달리, Gen11은 ‘임의 정수’ 지정이 가능합니다. ManualsLib


그림1	그림2

그림3	그림4

4. 재부팅 후 POST에서 즉시 확인

캡처확인 포인트

POST 메시지

1 Processor(s) detected, 4 total cores enabled, Hyper-threading is enabled 문구로 목표 달성

5. Linux에서 코어 수 검증

캡처명령 & 결과

CentOS 콘솔

```bash lscpu

7. 주의할 점

Hyper-Threading를 끄면 논리 코어가 절반으로 추가 감소. → Processor Options ▸ Intel Hyper-Threading Options 에서 Disabled 선택.
벤치마크 필수: 일부 멀티-스레드 앱은 처리량 감소가 크다.
펌웨어 버전: 초기 ROM(2023년 이전)에서는 56 코어 이상 입력 시 저장 오류가 보고됨. 최신 v2.x로 업데이트 권장.
라이선스 검증: 일부 소프트웨어는 BIOS에서 코어를 막아도 sockets × full cores 로 탐지되므로, 벤더 가이드라인 확인.

GPFS에서 PermitRootLogin "No" 설정 시 조치 방법

Itlee — Wed, 26 Feb 2025 17:32:19 +0900

서버 보안을 강화하기 위해 PermitRootLogin no 설정을 적용하면, root 계정으로 직접 SSH 접속이 차단됩니다. 이 경우 GPFS(IBM Spectrum Scale)를 운영하기 위해 sudo를 활용해야 합니다. 이번 글에서는 GPFS에서 PermitRootLogin이 "No"로 설정된 경우 Sudo를 이용한 운영 방법을 정리해 보겠습니다.

사전작업

gpfsadmin계정 gpfs 그룹 생성

# id gpfsadmin
uid=208(gpfsadmin) gid=202(gpfs)

1. Sudo 구성 및 설정

1) Sudo 설치

GPFS에서 sudo를 사용하려면 먼저 패키지를 설치해야 합니다.

sudo-1.8.15-1noldap.aix6.1.ppc.rpm

2) sudoers 파일 수정

visudo 명령어를 사용하여 /etc/sudoers 파일을 편집합니다.

root    ALL=(ALL) ALL
Defaults env_keep += "MMMODE environmentType GPFS_rshPath GPFS_rcpPath mmScriptTrace GPFSCMDPORTRANGE GPFS_CIM_MSG_FORMAT"
%gpfs ALL=(ALL) PASSWD: ALL, NOPASSWD: /usr/lpp/mmfs/bin/mmremote, /usr/bin/scp, /bin/echo, /usr/lpp/mmfs/bin/mmsdrrestore
Defaults:%gpfs !requiretty

⚠️ 중요:

IBM Storage Scale 5.1.0 이상에서는 scp, echo, mmsdrrestore를 sudoers에 추가할 필요 없음
GPFS 관련 환경 변수를 유지하도록 Defaults env_keep 설정 추가

3) sudoers 파일 권한 변경 (보안 설정 필수)

sudoers 파일 수정 후 보안을 위해 읽기 전용으로 설정해야 합니다.

chmod 0440 /etc/sudoers

잘못된 권한 설정 시 sudo가 정상적으로 동작하지 않을 수 있습니다.

2. SSH 및 SCP 래퍼 스크립트 테스트

IBM Spectrum Scale에서는 원격 쉘 실행을 위한 sudo 래퍼 스크립트(sshwrap, scpwrap)를 제공합니다. 정상적으로 동작하는지 확인해야 합니다.

1) sshwrap 테스트

sudo /usr/lpp/mmfs/bin/mmcommon test sshwrap nodeName

출력 예시:

mmcommon test sshwrap: Command successfully completed

2) scpwrap 테스트

sudo /usr/lpp/mmfs/bin/mmcommon test scpwrap nodeName

출력 예시:

mmcommon test scpwrap: Command successfully completed

이 과정에서 문제가 발생하면 sudoers 설정이 올바르게 적용되었는지 다시 확인해야 합니다.

3. GPFS 클러스터 설정 및 운영

1) 신규 클러스터 생성 (PermitRootLogin no 환경에서)

GPFS 클러스터를 새로 생성할 경우 --use-sudo-wrapper 옵션을 추가해야 합니다.

sudo /usr/lpp/mmfs/bin/mmcrcluster --use-sudo-wrapper -N /home/gpfsadmin/node.txt -C aix72 -A

2) 기존 클러스터를 sudo 래퍼 방식으로 변경

이미 운영 중인 클러스터가 있다면, 아래 명령어로 sudo 래퍼를 적용할 수 있습니다.

sudo /usr/lpp/mmfs/bin/mmchcluster --use-sudo-wrapper

3) 설정 확인

GPFS 클러스터가 sudo 래퍼를 정상적으로 사용하는지 확인하려면 다음 명령어를 실행합니다.

sudo /usr/lpp/mmfs/bin/mmlscluster

4) CCR 설정 변경 (필요 시)

일부 환경에서는 ccrEnabled 값을 변경해야 할 수도 있습니다.

sudo /usr/lpp/mmfs/bin/mmchcluster ccrdisable

정리 및 결론

PermitRootLogin no 설정 시 GPFS 운영자는 root 계정 대신 sudo를 활용해야 함
/etc/sudoers 파일을 수정하고 권한을 0440으로 변경하여 보안 강화
GPFS 환경 변수 유지 설정 추가 (Defaults env_keep 설정 활용)
IBM Spectrum Scale sudo 래퍼(sshwrap, scpwrap) 정상 작동 여부 확인 필수
기존 클러스터는 --use-sudo-wrapper 옵션을 사용하여 sudo 방식으로 변환 가능

Tip: mmlscluster 실행 결과에서 "sudo 래퍼 설정이 적용됨" 문구를 꼭 확인하세요!

#mmlscluster
GPFS cluster information
========================
  GPFS cluster name:         rpodbd_cluster.rpodbd01
  GPFS cluster id:           5439007699037552173
  GPFS UID domain:           rpodbd_cluster.rpodbd01
  Remote shell command:      sudo wrapper in use
  Remote file copy command:  sudo wrapper in use
  Repository type:           CCR

vios cd삽입

Itlee — Wed, 26 Feb 2025 16:18:43 +0900

mkvopt -name aix72 -file /ibm/aix72_tl5_sp06flash.iso -ro
- 가상 Optical 미디어(ISO 이미지)를 VIOS 내부의 가상 미디어 라이브러리에 등록하는 명령이다.
- -name aix72: 가상 미디어(이미지)에 붙일 이름을 지정한다.
- -file /ibm/aix72_tl5_sp06flash.iso: 실제 물리적(혹은 다운로드된) ISO 파일 경로를 지정한다.
- -ro: 읽기 전용(READ ONLY) 속성으로 생성한다.
mkvdev -fbo -vadapter vhost6 -dev dvd_aix72
- 등록한 가상 Optical 미디어를 “가상 Optical 디스크 드라이브”로 매핑해주는 명령이다.
- -fbo: File-backed optical 장치를 의미한다(ISO 이미지를 가상 장치로 에뮬레이션).
- -vadapter vhost6: VIOS에서 제공하는 가상 SCSI 어댑터 이름이다. 이를 통해 LPAR에 Optical 장치가 연결된다.
- -dev dvd_aix72: 새롭게 생성될 가상 Optical 장치의 디바이스 이름을 dvd_aix72로 지정한다.
loadopt -vtd dvd_aix72 -disk aix72
- 가상 Optical 디스크 드라이브(dvd_aix72)에 “aix72”라는 ISO 이미지를 로드(삽입)한다.
- 문서상 일반적으로 “loadopt” 명령이 쓰이나, 환경에 따라 “oadopt”라는 별칭 스크립트를 사용하는 경우도 있다.
- -vtd dvd_aix72: 대상 가상 Optical 장치(VTD, Virtual Target Device) 이름을 지정한다.
- -disk aix72: 로드할 ISO 이미지(가상 미디어) 이름을 지정한다(앞서 mkvopt로 만든 이름).
unloadopt -vtd dvd_rhel57 -release
- 가상 Optical 장치에서 ISO 이미지를 언로드(제거)하는 명령이다.
- -vtd dvd_rhel57: 언로드할 대상 가상 장치 이름을 지정한다.
- -release: 장치에 삽입되었던 미디어를 해제하여 가상 미디어 라이브러리 상태로 되돌린다.
rmdev -dev dvd_rhel57
- VIOS 상에 생성되었던 가상 Optical 장치 자체를 삭제한다.
- -dev dvd_rhel57: 삭제할 디바이스 이름을 지정한다.
- 언로드와 장치 제거를 모두 진행해야 실제 LPAR에서 미디어가 더 이상 보이지 않는다.
rmvopt -name rhel57
- 가상 미디어 라이브러리에 등록되어 있던 ISO 이미지를 제거한다.
- -name rhel57: 제거할 가상 미디어(ISO 파일) 이름을 지정한다.
- 가상 장치를 삭제(rmdev)한 뒤, 라이브러리에 남아 있는 실제 ISO 정보까지 완전히 제거할 때 사용한다.

lsrep

lsmapp -all

IBM AIX에서 GPFS(Spectrum Scale) 설치 방법

Itlee — Wed, 26 Feb 2025 15:00:31 +0900

안녕하세요! 이번에는 IBM AIX 환경에서 GPFS(General Parallel File System), 현재는 IBM Spectrum Scale로 알려진 파일 시스템을 설치하는 방법을 안내해드릴게요. 이 과정은 두 대의 서버를 기반으로 진행하며, 각 단계별로 상세히 설명해드릴게요.

1. 사전 준비

1.1. 서버 목록

설치를 진행할 두 대의 서버는 다음과 같아요:

오라클 개발 서버 01
오라클 개발 서버 02

1.2. SSH 키 생성 및 배포

두 서버 간 패스워드 없이 통신하기 위해 SSH 키를 생성하고 배포해야 해요.

# SSH 키 생성
ssh-keygen -t rsa

# 생성된 공개 키를 authorized_keys에 추가
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

이 과정을 두 서버 모두에서 수행하고, 각 서버의 ~/.ssh/authorized_keys 파일에 상대 서버의 공개 키를 추가해주세요.

2. GPFS 패키지 설치

2.1. 패키지 다운로드 및 압축 해제

IBM에서 제공하는 GPFS(Spectrum Scale) 패키지를 다운로드하여 각 서버의 동일한 디렉터리에 저장해주세요. 예를 들어, /tmp/download 디렉터리에 Spectrum_Scale_Standard-5.0.1.0-ppc64-AIX-install.tgz 파일을 저장했다면, 다음과 같이 압축을 해제합니다:

# 압축 해제
gzip -dc Spectrum_Scale_Standard-5.0.1.0-ppc64-AIX-install.tgz | tar xvf -

2.2. 패키지 설치

압축을 해제하면 여러 개의 파일셋이 생성돼요. 이를 설치하기 위해 smit 유틸리티를 사용합니다:

# smit 인터페이스 실행
smit installp

INPUT device / directory for software: 패키지가 있는 디렉터리 경로를 입력 (예: /tmp/download)
SOFTWARE to install: _all_latest 선택
ACCEPT new license agreements?: yes로 변경

나머지 옵션은 기본값으로 두고 설치를 진행해주세요.

설치가 완료되면 다음 명령어로 설치된 패키지를 확인할 수 있어요:

# 설치된 GPFS 패키지 확인
lslpp -l | grep -i gpfs

3. 클러스터 구성

3.1. 노드 리스트 작성

클러스터를 구성할 노드들의 정보를 담은 파일을 생성해야 해요. 예를 들어, /var/mmfs/etc/node.list 파일을 생성하고 다음과 같이 작성합니다:

rpodbd01:quorum-manager
rpodbd02:quorum-manager

3.2. NSD(Network Shared Disk) 정의

GPFS에서 사용할 디스크를 정의하는 파일을 생성합니다. 예를 들어, /var/mmfs/etc/data.txt 파일을 생성하고 다음과 같이 작성합니다:

/dev/hdisk0:rpodbd01::dataAndMetadata::data_nsd01:

또한, Tiebreaker 디스크를 정의하는 /var/mmfs/etc/tie.txt 파일도 생성합니다:

/dev/hdisk3:rpodbd01,rpodbd02::dataAndMetadata::tbnsd1:
/dev/hdisk4:rpodbd01,rpodbd02::dataAndMetadata::tbnsd2:
/dev/hdisk5:rpodbd01,rpodbd02::dataAndMetadata::tbnsd3:

3.3. 클러스터 생성

다음 명령어를 통해 클러스터를 생성합니다:

# 클러스터 생성
mmcrcluster -n /var/mmfs/etc/node.list -p rpodbd01 -C rpodbd_cluster

생성 후 라이선스를 수락합니다:

# 라이선스 수락
mmchlicense server --accept -N rpodbd01
mmchlicense server --accept -N rpodbd02

3.4. 클러스터 시작

클러스터를 시작하려면 다음 명령어를 사용합니다:

# 클러스터 시작
mmstartup -a

3.5. NSD 생성

정의한 NSD를 생성합니다:

# 데이터 NSD 생성
mmcrnsd -F /var/mmfs/etc/data.txt

# Tiebreaker NSD 생성
mmcrnsd -F /var/mmfs/etc/tie.txt

Tiebreaker 디스크를 설정합니다:

# Tiebreaker 디스크 설정
mmchconfig tiebreakerDisks="tbnsd1;tbnsd2;tbnsd3"

3.6. 파일 시스템 생성

마지막으로, GPFS 파일 시스템을 생성합니다:

# 파일 시스템 생성
mmcrfs /data /dev/data_nsd01 -F /var/mmfs/etc/data.txt -A yes -B 512k -N 50000

생성된 파일 시스템을 마운트하려면 다음 명령어를 사용합니다:

# 파일 시스템 마운트
mmmount /data

마무리

이제 IBM AIX 환경에서 GPFS(Spectrum Scale) 설치 및 구성이 완료되었어요! 각 단계별로 차근차근 진행하시면 무리 없이 설정하실 수 있을 거예요. 설치 과정 중 문제가 발생하거나 추가적인 도움이 필요하시면 언제든지 문의해주세요.

IBM GPFS(Spectrum Scale) 파일시스템 제거 방법

Itlee — Wed, 26 Feb 2025 10:09:44 +0900

IBM AIX 환경에서 GPFS(General Parallel File System), 현재의 IBM Spectrum Scale을 제거하는 방법을 정리해볼게요. GPFS는 고성능 병렬 파일 시스템으로, 많은 기업에서 클러스터 환경에서 활용하지만, 특정 환경에서 제거해야 할 필요가 생길 수도 있어요.

아래 단계에 따라 안전하게 GPFS를 제거하는 방법을 설명해드릴게요.

1. 모든 GPFS 파일 시스템 언마운트

먼저, 시스템에 마운트된 모든 GPFS 파일 시스템을 언마운트해야 해요.

# 모든 GPFS 파일 시스템 언마운트
mmumount -a /gpfs1
mmumount -a /gpfs2
# 필요에 따라 추가적인 파일 시스템 언마운트

2. GPFS 파일 시스템 삭제

언마운트한 후에는 GPFS 파일 시스템 자체를 삭제해야 해요.

# GPFS 파일 시스템 삭제
mmdelfs gpfs1
mmdelfs gpfs2
# 필요에 따라 추가적인 파일 시스템 삭제

3. NSD(Network Shared Disk) 삭제

파일 시스템을 삭제한 후에는 해당 파일 시스템에서 사용하던 NSD를 삭제해야 해요.

# NSD 삭제
mmdelnsd nsd1
mmdelnsd nsd2
# 필요에 따라 추가적인 NSD 삭제

4. GPFS 데몬 종료

NSD 삭제 후, GPFS 데몬을 종료해야 해요.

# GPFS 데몬 종료
mmshutdown -a

5. Tiebreaker 디스크 삭제

Tiebreaker 디스크를 사용 중이라면, 삭제 전에 GPFS 데몬을 종료하고 설정을 변경해야 해요.

# GPFS 데몬 종료
mmshutdown -a

# Tiebreaker 관련 설정 변경
mmchconfig tiebreakerDisks="no"

설정 변경 후, Tiebreaker 디스크를 삭제하세요.

# Tiebreaker 디스크 삭제
mmdelnsd tiebreakerDiskName

6. 노드 삭제

클러스터에서 모든 노드를 제거해야 해요.

# 노드 삭제
mmdelnode -a

7. GPFS 관련 디렉터리 정리

패키지를 제거한 후에도 일부 설정 파일이나 로그 파일이 남아 있을 수 있어요.
필요에 따라 아래 디렉터리를 정리하면 돼요.

rm -rf /var/mmfs
rm -rf /usr/lpp/mmfs

8. GPFS 패키지 제거

AIX 시스템에서 GPFS(Spectrum Scale) 패키지를 제거하려면 installp 명령어를 사용하면 돼요.

smit

Software Installation and Maintenance >  Software Maintenance and Utilities  > Remove Installed Software
또는
smit remove


########################################################################
#  PREVIEW only? (remove operation will NOT occur)     no                                                                                                                  +
#  REMOVE dependent software?                          yes 
########################################################################
gpfs 검색 후 gpfs 패키지 제거

마무리

GPFS(Spectrum Scale) 제거 작업을 진행하기 전에 반드시 백업을 확인해야 해요.
또한, 클러스터 환경에서 운영 중이라면, 모든 노드에서 GPFS 구성이 올바르게 정리되었는지 점검하는 게 중요해요.

필요한 경우, GPFS 재설치를 위해 관련 패키지를 미리 준비해두는 것도 좋은 방법이에요.
IBM 공식 문서를 참고하면 더욱 정확한 정보를 얻을 수 있어요.

리눅스에서 Network Teaming과 Bonding의 차이점 완벽 비교

Itlee — Thu, 20 Feb 2025 13:13:50 +0900

서버 네트워크 환경에서 **이중화(High Availability)**와 **부하 분산(Load Balancing)**은 필수 요소입니다.
리눅스에서는 이를 구현하기 위해 Bonding과 Teaming 두 가지 방법을 제공합니다.
그렇다면, 어떤 차이가 있으며, 어떤 상황에서 선택해야 할까요?
오늘은 Red Hat Enterprise Linux(RHEL) 7, 8, 9 환경을 기준으로 Bonding과 Teaming의 차이점을 자세히 비교해보겠습니다.

1️⃣ Bonding과 Teaming 개요

Bonding이란?

Bonding은 여러 개의 네트워크 인터페이스를 하나의 논리적 인터페이스로 묶는 기술입니다.
주로 커널 모듈(kernel module)에서 동작하며, 다양한 모드로 설정할 수 있습니다.

특징:

커널에서 직접 관리하여 안정성이 높습니다.
다양한 모드를 제공하여 유연한 설정이 가능합니다.
네트워크 장비와의 호환성이 뛰어납니다.
오래된 기술로 대부분의 리눅스 배포판에서 지원됩니다.

Teaming이란?

Teaming은 Bonding보다 새로운 기술로, 사용자 공간(user space)에서 관리되는 더 유연한 방식입니다.
RHEL 7부터 공식적으로 지원되기 시작했습니다.

특징:

사용자 공간에서 관리되어 동적인 설정이 가능합니다.
Bonding보다 빠른 장애 감지 및 전환을 제공합니다.
JSON 기반의 설정을 지원하여 설정이 더 직관적입니다.
NetworkManager와의 통합이 용이합니다.

2️⃣ Bonding과 Teaming의 차이점

비교 항목BondingTeaming

동작 방식	커널 모듈에서 동작	사용자 공간에서 동작
설정 방법	ifcfg 파일을 통한 설정	nmcli 또는 teamd를 통한 설정
지원 모드	7가지 모드 제공	다양한 러너 모드 제공
성능	안정적이나 유연성 제한	빠른 장애 감지 및 전환
유연성	정적 설정	동적 설정 가능
지원 버전	모든 RHEL 버전	RHEL 7 이상
장점	전통적이고 안정적	빠른 장애 감지 및 유연한 설정
단점	설정 복잡, 유연성 제한	최신 기술로 일부 환경에서 미지원 가능

3️⃣ Bonding과 Teaming 설정 방법

Bonding 설정 예제 (RHEL 7, 8, 9 기준)

1. Bonding 모듈 활성화:

modprobe bonding

2. Bonding 인터페이스 설정 파일 생성:

vi /etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=100"

3. 물리 인터페이스 설정:

vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
NAME=eth1
MASTER=bond0
SLAVE=yes
ONBOOT=yes

4. 네트워크 재시작 및 확인:

systemctl restart network
cat /proc/net/bonding/bond0

Teaming 설정 예제 (RHEL 7, 8, 9 기준)

1. Teaming 인터페이스 생성:

nmcli connection add type team con-name team0 ifname team0 config '{"runner": {"name": "activebackup"}}'

2. 물리 인터페이스를 Teaming에 추가:

nmcli connection add type ethernet con-name team0-port1 ifname eth1 master team0
nmcli connection add type ethernet con-name team0-port2 ifname eth2 master team0

3. IP 주소 설정:

nmcli connection modify team0 ipv4.addresses 192.168.1.100/24 ipv4.method manual

4. 연결 활성화:

nmcli connection up team0

5. 상태 확인:

teamdctl team0 state

4️⃣ 어떤 경우에 Bonding과 Teaming을 선택해야 할까?

Bonding이 적합한 경우:

네트워크 장비와의 호환성이 중요한 경우
기존의 RHEL 6 이하 환경에서 적용해야 하는 경우
단순하고 안정적인 네트워크 이중화가 필요한 경우

Teaming이 적합한 경우:

RHEL 7 이상을 사용하며, 최신 기술을 적용하고 싶은 경우
빠른 장애 감지 및 동적 설정이 필요한 경우
JSON 기반 설정을 활용하여 유연하게 관리하고 싶은 경우

결론: Bonding vs Teaming, 어떤 것을 선택해야 할까?

Bonding과 Teaming 모두 네트워크 이중화와 부하 분산을 위한 강력한 기술입니다.
다만, 기존의 안정성을 원한다면 Bonding, 더 유연하고 빠른 설정이 필요하다면 Teaming을 선택하면 됩니다.

RHEL 6 이하: Bonding이 적합
RHEL 7 이상: Teaming이 더 효율적

최근에는 Teaming이 점점 더 많이 사용되는 추세이므로,
새로운 환경을 구축할 때는 Teaming을 고려하는 것이 유리합니다.

더 자세한 내용은 공식 문서를 참고하세요!
Red Hat 공식 네트워크 설정 가이드

FCM 디스크란? NVMe 디스크와의 차이점 총정리!

Itlee — Wed, 19 Feb 2025 16:59:56 +0900

서버와 스토리지 관리하시는 분들!
디스크 종류 선택할 때 고민 많으시죠?
특히 NVMe 디스크 중에서도 IBM의 FCM 디스크(FlashCore Module)가 눈길을 끌고 있어요.
오늘은 FCM 디스크란 무엇인지, NVMe 디스크와 어떤 차이가 있는지 자세히 알아볼게요!

1️⃣ FCM 디스크란?

**FCM(FlashCore Module)**은 IBM이 직접 개발한 엔터프라이즈급 NVMe 디스크예요.
기존 일반 NVMe SSD보다 뛰어난 성능과 효율성을 제공해요.
대표적인 IBM 스토리지 제품에 포함되어 있죠.

FCM 디스크 특징
✅ NVMe 기반 초고속 스토리지
✅ 하드웨어 가속 압축으로 CPU 부하 최소화
✅ 중복 제거 기능으로 저장 공간 절약
✅ AES-256 암호화 및 데이터 보호 기능 지원
✅ 4.8TB~76.8TB까지 다양한 용량 옵션 제공

FCM 디스크는 특히 IBM FlashSystem 시리즈에서 사용돼요.
IBM FlashSystem 5200, 7300, 9500 같은 모델이 대표적이에요.

2️⃣ FCM 디스크의 강력한 압축 & 중복 제거 기능

일반적인 NVMe 디스크와 달리 FCM 디스크는 하드웨어 가속 압축과 중복 제거 기능을 지원해요.

하드웨어 가속 압축 (Hardware-accelerated Compression)

**FPGA(하드웨어 가속 엔진)**을 활용해 실시간 압축
CPU 부하 없이 성능 유지
최대 3:1~5:1의 압축 효과 제공
RAID 보호 기능과 함께 압축 상태에서도 데이터 복구 가능

중복 제거 (Deduplication)

Inline 방식으로 실시간 중복 제거
Variable Block Size 적용해 데이터 유형별 최적화
압축과 함께 적용되면 스토리지 공간 절약 효과 극대화

예를 들어, 100TB의 데이터를 저장할 때
✔️ 압축 및 중복 제거를 적용하면 20~30TB로 감소 가능(5:1 효과)!

특히 VDI(가상 데스크톱), 데이터베이스 환경에서 큰 장점을 보여요.

3️⃣ FCM 디스크 vs 일반 NVMe 디스크 차이점

비교 항목IBM FCM 디스크일반 NVMe 디스크

인터페이스	NVMe (PCIe 기반)	NVMe (PCIe 기반)
압축 지원	✅ 하드웨어 가속 압축 지원	❌ 지원 안 됨
중복 제거	✅ Inline Deduplication 지원	❌ 지원 안 됨
보안 기능	✅ AES-256 암호화, FIPS 140-2 인증	일부 모델만 지원
성능 최적화	✅ Adaptive Flash Technology 적용	❌ 일반적인 SSD 알고리즘
수명 관리	✅ 엔터프라이즈급 내구성 및 최적화된 가비지 컬렉션	일반적인 SSD 수명

결론적으로, NVMe 기반 디스크 중에서도 FCM 디스크는 최고 수준의 성능과 효율성을 자랑해요!

4️⃣ FCM 디스크가 탑재된 IBM 스토리지 제품

IBM의 FlashSystem 시리즈에 FCM 디스크가 적용되어 있어요.

대표 제품 라인업
✅ IBM FlashSystem 5200 – 엔트리급 NVMe 스토리지
✅ IBM FlashSystem 7300 – 미드레인지급 엔터프라이즈 NVMe 스토리지
✅ IBM FlashSystem 9500 – 하이엔드 NVMe 기반 올플래시 스토리지

이 스토리지 제품들은 FCM 디스크의 압축 및 중복 제거 기능을 최대한 활용할 수 있도록 설계되었어요.

5️⃣ FCM 디스크 도입 시 고려할 점

✔️ FCM 디스크의 장점은 명확해요!
✅ 스토리지 공간 절약 (3~5배 감소)
✅ CPU 부담 없이 고성능 유지
✅ 데이터 보호 및 보안 강화

하지만 몇 가지 고려할 점도 있어요!
암호화된 데이터는 압축 효율이 낮을 수 있음
**미디어 파일(예: 동영상, 이미지)**은 압축 효과가 제한적

이 점들을 고려해서, 적절한 환경에 FCM 디스크를 도입하면 최고의 성능을 발휘할 수 있어요!

마무리

이제 FCM 디스크가 무엇인지, 일반 NVMe 디스크와 차이가 무엇인지 감이 잡히셨죠?
FCM 디스크는 단순한 NVMe SSD가 아니에요!
✅ 하드웨어 가속 압축 및 중복 제거
✅ 엔터프라이즈급 성능과 보안
✅ IBM FlashSystem과 완벽 호환

Lenovo XClarity Essentials OneCLI: 통합 서버 관리 솔루션

Itlee — Wed, 19 Feb 2025 14:53:58 +0900

Lenovo XClarity Essentials OneCLI(이하 OneCLI)는 Lenovo 서버의 효율적인 관리를 위한 통합 명령줄 도구 모음입니다. 이를 통해 시스템 구성, 인벤토리 수집, 펌웨어 및 드라이버 업데이트 등 다양한 작업을 일관된 인터페이스에서 수행할 수 있습니다.

과거엔 dsa를 사용했다. dsa 사용법 링크 : https://frog11.tistory.com/80

OneCLI란 무엇인가?

OneCLI는 Lenovo의 ThinkSystem, ThinkServer, System x 등 다양한 서버 제품군을 지원하는 명령줄 기반의 관리 도구입니다. 이를 통해 시스템 관리자들은 복잡한 서버 관리 작업을 단순화하고 자동화할 수 있습니다. OneCLI는 다음과 같은 주요 기능을 제공합니다:

시스템 구성 관리: UEFI, BMC, RAID 설정 등을 명령어를 통해 확인하고 변경할 수 있습니다.
인벤토리 및 서비스 데이터 수집: 서버의 하드웨어 및 소프트웨어 구성 정보를 수집하고, 문제 해결을 위한 로그 및 진단 데이터를 생성합니다.
펌웨어 및 드라이버 업데이트: 서버의 펌웨어와 장치 드라이버를 최신 버전으로 유지하여 안정성과 보안을 강화합니다.
다운로드 링크 : https://support.lenovo.com/kr/ko/solutions/ht116433-lenovo-xclarity-essentials-onecli-onecli

OneCLI의 주요 기능 및 사용법

1. 시스템 구성 관리

OneCLI를 사용하여 서버의 다양한 설정을 확인하고 변경할 수 있습니다. 예를 들어, 현재 시스템의 UEFI 설정을 확인하려면 다음과 같은 명령어를 사용할 수 있습니다:

OneCli.exe config show --imm USERID:PASSW0RD@<ip_address>

특정 설정을 변경하려면 set 명령어를 사용합니다. 예를 들어, 시스템의 전원 복구 정책을 'Restore'로 설정하려면 다음과 같이 입력합니다:

OneCli.exe config set IMM.PowerRestorePolicy Restore --imm USERID:PASSW0RD@<ip_address>

2. 인벤토리 및 서비스 데이터 수집

서버의 상세한 인벤토리 정보를 수집하고 HTML 형식의 보고서를 생성하려면 다음 명령어를 사용합니다:

OneCli.exe inventory getinfor --htmlreport --ffdc --output C:\Logs

이 명령어는 시스템의 하드웨어 및 소프트웨어 구성 정보를 수집하고, 결과를 지정한 디렉토리에 저장합니다.

3. 펌웨어 및 드라이버 업데이트

OneCLI를 통해 서버의 펌웨어와 드라이버를 최신 버전으로 업데이트할 수 있습니다. 다음 명령어를 사용하여 업데이트를 수행합니다:

OneCli.exe update flash --source <패키지_경로> --imm USERID:PASSW0RD@<ip_address>

이 명령어는 지정한 소스에서 업데이트 패키지를 가져와 서버에 적용합니다.

OneCLI 다운로드 및 설치

OneCLI는 Lenovo의 공식 지원 페이지에서 다운로드할 수 있습니다. Windows와 Linux 운영 체제를 모두 지원하며, 각 플랫폼에 맞는 설치 파일을 제공하고 있습니다. 다운로드 및 설치에 대한 자세한 내용은 Lenovo XClarity Essentials OneCLI 공식 웹사이트를 참고하시기 바랍니다.

결론

Lenovo XClarity Essentials OneCLI는 서버 관리 작업을 단순화하고 효율성을 높여주는 강력한 도구입니다. 명령줄 인터페이스를 통해 다양한 관리 작업을 자동화할 수 있으며, 이를 통해 시스템 관리자는 더 중요한 업무에 집중할 수 있습니다.

Lenovo BMC, IMM 비밀번호 분실 시 복구 방법

Itlee — Fri, 3 Jan 2025 13:22:25 +0900

레노버 SR650 V2 XCC 암호 분실 문제에 대한 심층적 해결 방안

SR650 V2 서버의 XCC 암호 분실은 서버 관리 환경에서 빈번히 발생하는 문제로, 본 가이드는 ipmitool 및 Onecli 유틸리티를 활용한 암호 초기화 방법을 다루며, 암호 정책 준수와 보안 유지의 중요성을 강조합니다.

ipmitool 유틸리티를 이용한 암호 초기화 절차

1. USERID의 ID 탐색

ipmitool은 Intelligent Platform Management Interface(IPMI) 기반의 관리 도구로, 사용자 계정 정보를 조회할 수 있습니다. 다음 명령어를 통해 USERID의 ID를 확인하십시오.

# ipmitool user list 1

USERID의 ID는 기본적으로 2로 설정되어 있지만, 환경에 따라 다를 수 있으므로 반드시 확인이 필요합니다.

2. 암호 초기화

확인된 ID를 기반으로 암호를 변경합니다. 초기 암호는 보안 정책에 부합해야 하며, 권장값은 Password1@입니다.

# ipmitool user set password 2 Password1@

2: USERID의 ID를 나타냅니다. USERID의 ID가 다를 경우, 해당 번호를 사용해야 합니다.
Password1@: 최소 암호 요구사항(대문자, 소문자, 숫자, 특수문자 포함)을 충족합니다.

3. ✅ 로그인 및 확인

변경된 암호로 XCC에 접속하십시오.
성공적으로 로그인한 후, 시스템 정책에 맞는 새로운 암호로 변경하십시오.

Onecli 유틸리티를 이용한 암호 초기화 절차

1. IMM 설정 확인

Onecli는 레노버 시스템 관리 환경을 위한 통합 명령줄 도구입니다. IMM 설정 정보를 다음 명령어를 통해 확인하십시오.

# OneCli config show IMM

2. 암호 변경

IMM 계정의 암호를 다음 명령어로 변경합니다. 초기 암호로는 Password1@를 사용합니다.

# OneCli config set IMM.Password.1 Password1@

3. ✅ 로그인 및 확인

변경된 암호를 사용해 XCC에 로그인하십시오.
로그인 후, 보안 강화 및 관리 편의를 위해 적합한 암호로 재설정하십시오.

추가 고려사항

암호 변경 후, XCC 접속 및 관련 서비스의 정상 동작 여부를 철저히 확인하십시오.
위 방법으로도 문제가 해결되지 않을 경우, 레노버 기술 지원팀에 문의하여 추가 조치를 받으시기 바랍니다.
암호 설정 시, 기본 정책 외에도 조직의 보안 지침을 준수하는 것이 필수적입니다.

NTP를 통한 서버 시간 동기화 완벽 가이드: 설정, 문제 해결, 보안 강화까지

Itlee — Thu, 12 Dec 2024 11:21:00 +0900

1. NTP의 기본 개념 이해

NTP란?: NTP는 분산 인터넷 상의 서버와 클라이언트 간 시간 동기화를 위해 사용되는 프로토콜이다. Stratum 레벨을 통해 시간 계층 구조를 형성하며, 상위(낮은 수치의 Stratum) 서버로부터 신뢰도 높은 시간을 받아 점진적으로 퍼트려 나간다.
Stratum: Stratum 0은 GPS나 원자시계 등 물리적으로 매우 정확한 시간원을 의미한다. Stratum 1 서버는 이 원천으로부터 직접 시간을 받아 Stratum 2 서버에게 전달하고, 이러한 계층적 구조를 통해 인터넷 전반에 정확한 시간이 확산된다.
Offset과 Jitter: Offset은 서버와 NTP 소스 간 시간 차이이며, Jitter는 시간 측정 값의 변동성을 의미한다. 이를 모니터링함으로써 시간 정확도와 품질을 판단할 수 있다.

2. 환경별 NTP 설정 방법

Linux 환경(CentOS, RHEL, Ubuntu 등)
- yum install ntp 또는 apt-get install ntp 명령으로 NTP 패키지 설치
- /etc/ntp.conf 수정: 신뢰할 NTP 서버 목록 추가
- systemctl start ntpd로 서비스 시작 후 systemctl enable ntpd로 부팅 시 자동 시작 설정
- ntpq -p 또는 ntpq -qn 명령으로 동기화 상태 확인
Windows 서버 환경
- W32time 서비스 활용: w32tm /config /syncfromflags:manual /manualpeerlist:"ntp.server.com" 명령으로 동기 대상 설정
- w32tm /resync로 즉각 재동기화
클라우드 환경(AWS, GCP, Azure)
- 각 클라우드 제공자별 NTP 서비스(예: Amazon Time Sync Service) 활용
- 가상머신 수준이나 컨테이너 오케스트레이션 레벨에서 일관된 시간 제공 전략 수립
- 인프라 초기 프로비저닝 시 Ansible 등 자동화 도구를 통해 NTP 설정 반영

3. Chrony vs NTP 비교 및 선택 기준

Chrony 특징:
- 빠른 동기화 속도, 변동성 큰 네트워크 환경에서 안정적 동작
- 경량화된 메모리 사용량, 동적 호스트 환경에 유리
NTP 데몬 전통성:
- 역사적으로 사용 빈도가 높고 문서나 레퍼런스가 풍부
- 아주 안정적이고 수십 년간 검증된 구현체
선택 기준:
- 빈번한 VM 재시작 환경, 불규칙한 네트워크 대역폭이라면 Chrony 권장
- 전통적인 온프레미스 서버 환경에서 이미 NTP에 익숙하다면 기존 NTP 유지
- 운영 규범, 사내 표준, 레거시 시스템 호환성을 종합 고려

4. 고정밀 시간 동기화를 위한 전략

내부 NTP 서버 구축:
- 사내 Stratum 1/2 서버를 두어 내부 서버에 시간 제공
- 외부 인터넷 연결 문제나 보안 정책에 대한 독립성 확보
GPS, PTP(Precision Time Protocol):
- 밀리초 이하 정밀도를 요구하는 금융권, 방송, 분산 데이터 처리 환경에서 PTP 활용
- GPS 기반 NTP 서버 구성으로 외부 시간 소스의 정확도 극대화

5. ntpq -qn 결과 출력 해석 가이드

ntpq -qn 명령어를 실행하면 아래와 같은 형태의 출력이 나타난다. 이는 NTP 피어 리스트와 해당 피어로부터 수집한 상태 정보를 수치화한 테이블 형태다. 각 컬럼은 다음과 같은 의미를 가진다.

예시 출력(형식 예):

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*203.0.113.1    203.0.113.100    2 u   25   64   377    0.123   -0.050   0.005
+203.0.113.2    203.0.113.200    2 u   14   64   377    0.145    0.002   0.010
 203.0.113.3    203.0.113.300    3 u   32   64   376    0.200    0.050   0.020

remote: 현재 서버가 시간 동기화를 시도하고 있는 NTP 피어(서버) 주소를 표시. -n 옵션 사용 시 IP 주소 형태로 나타난다.
refid: 해당 피어가 참고하고 있는 상위 시간 소스. Stratum 2 서버라면 Stratum 1 서버의 IP나 주소가 나타나며, Stratum 1 서버라면 GPS나 원자시계 등 특별한 출처가 나타날 수 있다.
st: Stratum 레벨을 나타낸다. 0은 물리적 시간원(원자시계 등), 1은 그 시간원을 직접 참조한 서버, 숫자가 커질수록 시간 정확도가 낮아진다.
t: 피어 유형(Type)으로 일반적으로 u는 unicast(일반적인 서버-클라이언트 관계), l은 로컬(ref clock) 등을 의미한다.
when: 마지막으로 해당 피어로부터 시간을 받아온 후 경과한 시간(초).
poll: 현재 피어에 대한 폴링 간격(초)을 나타낸다. NTP는 동적 폴링을 통해 네트워크 환경에 따라 시간 질의를 최적화한다.
reach: 8비트 마스크 형태로 해당 피어에 대한 최근 통신 성공 여부를 나타낸다. 377(8진수)면 최근 8번의 폴링 모두 성공했다는 의미이며, 0은 최근 8번의 시도 모두 실패한 상태를 의미한다.
delay: 서버와 해당 피어 간 왕복 패킷 지연 시간(밀리초 단위). 낮을수록 좋다.
offset: 현재 서버 시간과 피어 시간 간의 차이(밀리초). 이 값이 0에 가깝도록 유지하는 것이 목표다. 음수 값이면 로컬 서버 시간이 피어 시간보다 앞서 있는 상황을 의미한다.
jitter: 오프셋 측정 값의 변동성(밀리초). 안정적인 시간 동기화를 위해서는 jitter 값이 낮을수록 이상적이다.

앞에 붙는 기호의 의미:

* (asterisk): 현재 메인 동기화 소스로 사용 중인 피어
+ (plus sign): 선택된 추가 후보 피어
- (minus sign): 동기화 후보에서 제외된 피어
(blank): 아직 평가 중이거나 신뢰성이 낮은 피어

이러한 값을 지속적으로 관찰하면서 오프셋 증가나 reach 값 변동, delay 급증 등을 모니터링함으로써 NTP 동기화 상태가 건전한지 평가할 수 있다.

6. 문제 해결 및 튜닝 방법

초기 큰 시간 오프셋(패닉 상황) 대처:
- ntpd 시작 전 ntpdate나 chronyc makestep 명령을 활용해 대략적인 시간 맞춤
- tinker panic 0 옵션 활용해 패닉 임계값 조정 가능
정밀 모니터링:
- ntpq -pn, ntpq -qn으로 주기적 확인
- Offset, Jitter 값으로 네트워크 안정성 판단
로그 분석:
- /var/log/messages, journalctl -u ntpd.service 등을 통해 장애 원인 파악
- 오프셋 급증 시 특정 시간대나 특정 피어 문제 여부 점검

7. 보안 고려사항

ACL 설정:
- /etc/ntp.conf 내 restrict 구문을 사용해 외부 접근 제한
- Amplification Attack 등 NTP 기반 보안 위협 방지
인증 및 암호화:
- 대규모 인프라에서 대칭 키 인증 사용
- NTS(NTP over TLS) 도입 고려
- 무결성 검증을 통한 시간 변조 방지

8. 자동화 및 모니터링 전략

자동화 도구 활용:
- Ansible, Chef, Puppet 등 CM 도구를 통한 일괄 설정 배포
- 인프라 구성 시 초기 스크립트로 NTP 셋업 자동화
모니터링 및 알람:
- Zabbix, Prometheus, Grafana 등 툴 사용해 Offset, Delay 추이 시각화
- 임계값 초과 시 알림 전송 및 자동 복구 스크립트 실행
지속적 개선:
- 정기 점검 및 소스 교체로 외부 NTP 서버 장애 대응
- DNS 기반 NTP 풀 사용으로 가용성 극대화

마무리

시간 동기화는 단순히 로그 시간 정렬을 넘어, 보안, 분석, 장애 대응, 운영 효율성에 결정적 영향을 미친다. 위 가이드를 참조하여 정확하고 안전하며 효율적인 시간 동기화 환경을 구현해보자.

Centos Redhat 백업 복구(OS영역 참고)

Itlee — Fri, 22 Nov 2024 09:36:43 +0900

1. dd와 OS 영역

dd는 디스크의 모든 데이터를 원본 그대로 섹터 단위로 복사합니다. 따라서 OS 영역(부팅 섹터, GRUB, 파티션 테이블 등)도 완벽히 복사됩니다.

dd의 OS 영역 복원 특성

가능한 경우:
- 동일한 하드웨어 환경에서 복원하면 별도 설정 없이도 OS가 정상적으로 동작합니다.
주의할 점:
- 하드웨어가 다른 경우, GRUB(부트 로더)를 다시 설정하거나 드라이버를 수정해야 할 수 있습니다.
- 디스크 크기가 달라지면 파티션 크기를 조정해야 할 수 있습니다.

2. Clonezilla와 OS 영역

Clonezilla는 dd처럼 전체 디스크를 섹터 단위로 백업할 수도 있고, 파일 시스템 레벨에서 OS 영역만 선택적으로 백업할 수도 있습니다.

Clonezilla의 OS 영역 복원 특성

가능한 경우:
- 전체 디스크나 특정 파티션을 백업할 수 있으므로 OS 영역과 데이터 영역 모두 복원 가능합니다.
- 하드웨어가 달라도 Clonezilla는 GRUB 설정 재구성을 도와줄 수 있습니다.
장점:
- 압축 및 선택적 복원이 가능하므로 용량을 절약할 수 있습니다.

3. rsync와 OS 영역

rsync는 파일과 디렉터리를 복사하는 방식이므로 디스크의 파일 시스템이 복구 가능한 상태에서만 OS 영역을 복원할 수 있습니다.

rsync의 OS 영역 복원 특성

가능한 경우:
- OS 파일이 손상되지 않았고 GRUB 및 부트 로더가 정상 작동 중이라면, OS 영역만 복사하여 복원 가능합니다.
주의할 점:
- 부팅 관련 데이터(예: MBR, GPT, GRUB)는 rsync로 복사되지 않으므로 별도로 설정해야 합니다.
- GRUB 부트 로더 재설치 및 chroot 환경에서 설정을 수정해야 할 수 있습니다.

4. tar와 OS 영역

tar는 OS 파일 및 디렉터리를 압축하여 백업하므로, rsync와 유사하게 파일 시스템에 접근할 수 있는 상태에서 OS 영역을 복원할 수 있습니다.

tar의 OS 영역 복원 특성

가능한 경우:
- OS의 모든 파일을 포함해 백업했다면, 압축 해제 후 기본 설정만으로 OS를 복원할 수 있습니다.
주의할 점:
- GRUB 및 부팅 섹터는 별도로 설정해야 합니다.
- 파일 시스템 자체가 손상되었거나 디스크 구조가 변경된 경우엔 tar만으로 복원이 어렵습니다.

OS 영역 복원 시 추가 작업

1. GRUB 재설치

OS 영역을 복원했는데 부팅이 되지 않으면 GRUB(부트 로더)를 다시 설치해야 합니다.

grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg

2. 부팅 드라이버 및 네트워크 설정 수정

하드웨어가 다른 환경에서 복원할 경우, 네트워크 인터페이스 이름이나 디바이스 드라이버가 달라져 OS 부팅 중 문제가 발생할 수 있습니다.
/etc/fstab, /etc/sysconfig/network-scripts/ifcfg-* 등을 확인해야 합니다.

정리

도구OS 영역 포함 여부추가 작업 필요 여부

dd	완전 포함	GRUB 재설치 필요 가능성 있음
Clonezilla	완전 포함	하드웨어 변경 시 GRUB 설정 필요 가능성
rsync	파일만 복사 가능	부팅 섹터 및 GRUB 별도 설정 필요
tar	파일만 복사 가능	부팅 섹터 및 GRUB 별도 설정 필요

CentOS Redhat 백업 및 복원 방법

Itlee — Fri, 22 Nov 2024 09:33:17 +0900

CentOS 7 운영 체제를 백업하거나 다른 서버로 이동할 때 가장 기본적인 방법은 dd 명령어를 사용하는 것입니다. 그러나 하드웨어 호환성과 디스크 크기 제한 등 몇 가지 중요한 점을 고려해야 합니다. 이 글에서는 dd 사용 방법과 함께 효율적인 대안 도구를 소개합니다.

1. dd 명령어를 활용한 백업 및 복원

1-1. 디스크 백업

dd 명령어는 디스크를 원본 그대로 이미지 파일로 복사합니다. USB나 외장 하드에 저장하려면 다음과 같이 명령어를 실행하세요.

dd if=/dev/sdX of=/path/to/usb/backup.img bs=1M status=progress

if=/dev/sdX: 백업할 원본 디스크(예: /dev/sda).
of=/path/to/usb/backup.img: 백업 이미지 파일을 저장할 위치.
bs=1M: 블록 크기를 1MB로 지정해 성능을 최적화.
status=progress: 진행 상태를 표시.

1-2. 디스크 복원

다른 서버에서 이미지를 복원하려면 다음 명령어를 사용합니다.

dd if=/path/to/usb/backup.img of=/dev/sdY bs=1M status=progress

if=/path/to/usb/backup.img: 백업 이미지 경로.
of=/dev/sdY: 복원할 디스크(예: /dev/sdb).

1-3. dd 사용 시 주의사항

하드웨어 호환성
원본 서버와 복원할 서버의 하드웨어 구성이 다를 경우 부팅 문제가 발생할 수 있습니다. GRUB 부팅 문제를 해결하려면 GRUB를 재설치하거나 네트워크 설정 등을 수정해야 할 수 있습니다.
디스크 크기
복원할 디스크의 크기가 원본 디스크보다 작으면 복원이 실패합니다. 디스크 크기를 미리 확인하세요.
데이터 손실 주의
복원할 디스크의 모든 데이터는 복원 과정에서 덮어씌워지므로 중요한 데이터는 미리 백업해야 합니다.

2. Clonezilla를 활용한 백업 및 복원

2-1. Clonezilla란?

Clonezilla는 무료 오픈 소스 디스크 이미징 도구입니다. GUI 기반으로 사용하기 쉬우며, 전체 디스크나 파티션을 빠르고 효율적으로 백업 및 복원할 수 있습니다.

2-2. Clonezilla 사용 방법

Clonezilla 라이브 USB 생성
Clonezilla ISO 파일을 다운로드하고 USB에 부팅 가능한 디스크로 만듭니다.

sudo dd if=clonezilla.iso of=/dev/sdX bs=4M status=progress

2. 시스템 백업
Clonezilla로 부팅 후, "device-to-image" 옵션을 선택하고 저장 경로를 설정합니다.

3.복원
"image-to-device" 옵션을 선택해 백업 이미지를 복원할 디스크를 지정합니다.

2-3. Clonezilla의 장점

효율적인 압축으로 디스크 크기를 줄임.
GUI 기반으로 초보자도 쉽게 사용 가능.
파티션 또는 전체 디스크 선택 가능.

3. rsync를 활용한 시스템 백업

3-1. rsync란?

rsync는 파일과 디렉터리를 효율적으로 복사하고 동기화하는 도구입니다. 시스템 파일만 백업하고 디스크 이미징은 필요하지 않을 때 적합합니다.

3-2. rsync 사용 방법

백업 명령어

rsync -avz --progress / /mnt/backup/

- /: 시스템 전체를 백업.
- /mnt/backup/: 백업을 저장할 경로.
- -a: 파일 속성 보존(archive).
- -v: 진행 상황 표시(verbose).
- -z: 데이터 압축.

2. 복원 명령어 동일한 명령어를 사용해 복원할 서버로 복사합니다.

rsync -avz --progress /mnt/backup/ /

3-3. rsync의 장점

네트워크를 통해 원격 서버로도 백업 가능.
디스크 이미징 대신 파일 단위로 백업하므로 유연성 높음.
증분 백업을 지원해 속도가 빠르고 효율적.

4. tar를 활용한 시스템 백업

4-1. tar란?

tar는 파일 및 디렉터리를 하나의 아카이브로 묶어 백업합니다. 압축을 지원하며 단순 백업 작업에 적합합니다.

4-2. tar 사용 방법

백업 명령어

tar -cvpzf /mnt/backup/system-backup.tar.gz --exclude=/mnt --exclude=/proc --exclude=/tmp --exclude=/sys /

-c: 새 아카이브 생성(create).
-v: 진행 상황 표시(verbose).
-p: 권한 보존(preserve permissions).
-z: gzip 압축.
--exclude: 백업 제외 디렉터리 지정(예: /mnt, /proc 등).

2. 복원 명령어

tar -xvpzf /mnt/backup/system-backup.tar.gz -C /

- -x: 아카이브 풀기(extract).
- -C /: 루트 디렉터리 기준으로 복원.

4-3. tar의 장점

간단한 명령어로 빠르게 아카이브 생성 가능.
백업 파일을 직접 탐색할 수 있음.
gzip 또는 bzip2 압축으로 용량 절감 가능.

5. 각 방법 비교

방법장점단점

dd	모든 데이터 원본 그대로 백업	속도 느림, 하드웨어 의존성 있음
Clonezilla	GUI로 간단한 디스크 백업 및 복원	라이브 USB 부팅 필요
rsync	파일 단위로 유연하게 백업 가능	디스크 전체 이미징 불가
tar	간단한 파일 아카이브 생성	실시간 증분 백업 기능 없음

이 방법들 중 하드웨어가 동일한 경우에는 dd, 복잡한 설정이 필요 없으면 Clonezilla, 특정 파일만 백업하려면 rsync 또는 tar를 사용하는 것을 추천합니다.

참고 OS 영역을 백업 및 복원할 경우 : https://frog11.tistory.com/108

서버 내 CMOS 배터리의 역할과 중요성

Itlee — Thu, 21 Nov 2024 11:32:01 +0900

서버를 운영하거나 관리하다 보면 한 번쯤은 CMOS 배터리에 대해 들어보셨을 것입니다. 작은 크기지만 서버의 안정성과 연속성에 큰 영향을 미치는 이 배터리는 정확히 어떤 역할을 하고 있을까요? 이번 포스팅에서는 서버 내 CMOS 배터리의 역할과 그 중요성에 대해 자세히 알아보겠습니다.

CMOS 배터리란?

CMOS 배터리는 메인보드에 장착된 작은 버튼형 배터리로, 주로 CR2032 모델이 많이 사용됩니다. 이 배터리는 서버가 전원에 연결되어 있지 않을 때도 CMOS 메모리와 **실시간 시계(RTC)**에 전원을 공급하는 역할을 합니다.

CMOS 배터리의 주요 역할

1. 시스템 설정 정보 유지

서버의 BIOS 설정과 시스템 구성 정보는 CMOS 메모리에 저장됩니다. 이러한 설정에는 부팅 순서, 하드 드라이브 구성, 메모리 타이밍 등이 포함됩니다. CMOS 배터리가 없다면 전원이 차단될 때마다 이 설정들이 초기화되어 매번 재설정해야 하는 불편함이 발생합니다.

2. 실시간 시계(RTC) 전원 공급

정확한 시간과 날짜는 서버 운영에 있어서 매우 중요합니다. 로그 기록, 작업 스케줄링, 인증 프로세스 등 다양한 시스템 기능이 정확한 시간 정보를 필요로 합니다. CMOS 배터리는 서버가 꺼져 있어도 RTC에 전원을 공급하여 시간과 날짜를 정확하게 유지합니다.

3. 서버의 안정성과 신뢰성 보장

CMOS 배터리가 정상적으로 작동하면 서버는 항상 올바른 설정과 시간을 유지하여 예측 가능한 방식으로 동작합니다. 이는 서버의 **업타임(Uptime)**을 높이고 예상치 못한 오류나 문제를 방지하는 데 도움이 됩니다.

CMOS 배터리 관리의 중요성

CMOS 배터리는 영구적인 부품이 아니며 시간이 지나면 방전됩니다. 일반적으로 3~5년의 수명을 가지므로 정기적인 점검과 교체가 필요합니다. 배터리가 방전되면 다음과 같은 문제가 발생할 수 있습니다:

시스템 시간이 초기화되어 로그 및 일정 관리에 혼선 발생
BIOS 설정이 기본값으로 리셋되어 부팅 문제 발생
하드웨어 인식 오류로 인한 시스템 불안정

CMOS 배터리 교체 방법

서버 전원 차단: 안전을 위해 서버의 전원을 완전히 끕니다.
케이스 열기: 메인보드에 접근할 수 있도록 서버 케이스를 엽니다.
기존 배터리 제거: 메인보드의 CMOS 배터리를 찾아 조심스럽게 제거합니다.
새 배터리 삽입: 동일한 모델의 새로운 배터리를 올바른 방향으로 삽입합니다.
설정 확인: 서버를 부팅한 후 BIOS 설정과 시스템 시간을 확인하고 필요시 재설정합니다.

마무리

작지만 중요한 역할을 하는 CMOS 배터리는 서버의 안정적 운영에 필수적입니다. 정기적인 점검과 적절한 관리로 예상치 못한 서버 다운타임을 방지하시기 바랍니다.

RAID 컨트롤러의 가상 디스크 캐시 설정 옵션 설명

Itlee — Mon, 18 Nov 2024 17:09:17 +0900

RAID 컨트롤러의 캐시 설정은 시스템 성능과 데이터 안전성에 직접적인 영향을 미칩니다. 적절한 캐시 옵션을 선택하는 것은 워크로드에 따라 매우 중요한 결정입니다. 이번 포스팅에서는 Read Policy, Write Policy, Disk Cache Policy의 각 옵션을 상세히 설명드리겠습니다.

1. Read Policy (읽기 정책)

RAID 컨트롤러의 Read Policy는 데이터 읽기 작업의 캐시 동작을 정의합니다. 주요 옵션은 다음과 같습니다.

Adaptive Read Ahead:
- RAID 컨트롤러가 읽기 패턴을 분석해 순차적인 데이터 읽기를 예측합니다. 데이터가 순차적으로 읽혀야 하는 경우, 성능을 크게 향상시킬 수 있습니다. 반면, 랜덤 읽기에서는 Read Ahead가 자동으로 비활성화됩니다.
- 적합한 경우: 순차적인 읽기 작업이 많을 때.
No Read Ahead:
- 데이터 읽기 작업이 요청될 때만 디스크에서 데이터를 가져옵니다. 랜덤 I/O 작업이 많을 때 유용하며, 불필요한 캐시 자원을 절약할 수 있습니다.
- 적합한 경우: 랜덤 읽기 작업이 대부분인 경우.
Read Ahead:
- 모든 읽기 작업에 대해 데이터를 미리 캐시에 로드합니다. 순차적인 데이터 접근이 많을 때 성능이 개선되지만, 랜덤 접근이 많을 경우 캐시 낭비가 발생할 수 있습니다.
- 적합한 경우: 데이터가 항상 순차적으로 접근될 때.

2. Write Policy (쓰기 정책)

쓰기 정책은 데이터가 디스크에 기록되는 방식을 정의하며, 성능과 데이터 안전성에 중요한 영향을 미칩니다.

Write Through:
- 데이터가 RAID 컨트롤러의 캐시를 거치지 않고 즉시 디스크에 기록됩니다. 데이터의 안정성이 높지만, 쓰기 성능은 상대적으로 낮습니다.
- 적합한 경우: 데이터 무결성과 안정성이 중요한 환경.
Write Back:
- 데이터가 먼저 RAID 컨트롤러의 캐시에 저장된 후, 디스크에 나중에 기록됩니다. 쓰기 성능이 크게 향상되지만, 전원 장애가 발생하면 데이터 손실의 위험이 있습니다. BBU(Battery Backup Unit)를 사용하면 데이터 손실 위험을 줄일 수 있습니다.
- 적합한 경우: BBU가 설치되어 있고 성능이 중요한 경우.
Force Write Back:
- BBU가 비정상적인 상태에서도 Write Back 캐시를 강제로 사용합니다. 성능을 극대화할 수 있지만, 데이터 손실 가능성이 높아질 수 있습니다.
- 적합한 경우: 최고 성능이 필요하지만 데이터 손실 위험을 감수할 수 있는 경우.

3. Disk Cache Policy (디스크 캐시 정책)

디스크 캐시 정책은 개별 디스크의 내장 캐시 사용 여부를 결정합니다.

Default:
- 디스크 제조사의 기본 설정을 사용합니다. 일부 디스크는 기본적으로 캐시가 활성화되어 있을 수 있습니다.
- 적합한 경우: 특별한 요구사항이 없을 때.
Enabled:
- 디스크의 내장 캐시를 활성화하여 데이터를 디스크 캐시에 임시로 저장한 후 디스크에 기록합니다. 성능이 향상되지만, 전원 장애가 발생할 경우 데이터 손실 위험이 있습니다.
- 적합한 경우: 성능을 최우선으로 하는 환경.
Disabled:
- 디스크의 내장 캐시를 비활성화하여 데이터를 즉시 디스크에 기록합니다. 데이터 안전성이 높아지지만, 성능은 떨어질 수 있습니다.
- 적합한 경우: 데이터 안정성이 최우선일 때.

요약 및 권장 설정

읽기 작업이 많을 경우: Adaptive Read Ahead 또는 Read Ahead를 설정하여 성능을 최적화할 수 있습니다.
쓰기 작업이 중요할 경우: Write Back을 선택하고, 데이터 안전을 위해 BBU를 사용하는 것이 좋습니다.
데이터 안전이 최우선일 경우: Write Through와 No Read Ahead를 사용하여 최대한의 안정성을 확보합니다.

metro mirror와 global mirror 비교

Itlee — Fri, 15 Nov 2024 08:47:20 +0900

Metro Mirror와 Global Mirror는 IBM의 고가용성 및 재해 복구 솔루션에서 사용되는 데이터 복제 기술입니다. 두 방식 모두 IBM 스토리지 솔루션의 중요한 구성 요소이지만, 복제 방식과 사용 목적이 다릅니다. 다음은 두 기술의 주요 차이점과 비교입니다.

1. 복제 거리 및 대기 시간

Metro Mirror:
- 거리: 짧은 거리 복제(일반적으로 300km 이내).
- 대기 시간: 낮은 대기 시간을 요구하는 환경에 적합합니다.
- 동기식 복제: 데이터가 원본 스토리지에서 기록되면 즉시 원격 스토리지로 전송되며, 데이터가 두 위치에 모두 기록될 때까지 응답을 기다립니다. 이로 인해 데이터 일관성이 높아집니다.
Global Mirror:
- 거리: 장거리 복제(수천 킬로미터 이상).
- 대기 시간: 대기 시간이 긴 환경에서도 사용할 수 있습니다.
- 비동기식 복제: 원본 스토리지는 데이터가 원격 스토리지에 기록되는 것을 기다리지 않고 응답을 반환합니다. 데이터 전송은 비동기적으로 수행되며, 이는 긴 거리에서도 효율적인 복제를 가능하게 합니다.

2. 복제 방식

Metro Mirror:
- 동기식 복제: 데이터 일관성을 보장합니다. 데이터가 원본과 복제본에 동시에 기록되므로, 주 스토리지와 복제 스토리지의 데이터가 항상 일치합니다.
- 즉각적인 복구 가능: 장애 발생 시 거의 실시간으로 데이터 복구가 가능하여 짧은 복구 시간을 보장합니다.
Global Mirror:
- 비동기식 복제: 데이터 전송이 지연될 수 있으며, 원본과 복제본 간의 데이터가 일정 시간 동안 불일치할 수 있습니다. 하지만 긴 거리에서 데이터 복제를 효율적으로 수행할 수 있습니다.
- 복구 시 지연 가능: 데이터 전송 지연으로 인해 장애 발생 시 일부 데이터 손실이 발생할 수 있습니다. 주로 재해 복구를 목적으로 사용됩니다.

3. 성능 영향

Metro Mirror:
- 성능 영향: 동기식 복제 방식이기 때문에 대기 시간이 짧은 경우에도 스토리지 성능에 영향을 줄 수 있습니다. 특히, 고속 응답이 필요한 애플리케이션에서는 주의가 필요합니다.
- 네트워크 요구사항: 안정적이고 낮은 대기 시간의 고속 네트워크가 필요합니다.
Global Mirror:
- 성능 영향: 비동기식 복제이기 때문에 대기 시간의 영향이 적습니다. 네트워크 지연으로 인해 주 스토리지의 성능에 미치는 영향이 최소화됩니다.
- 네트워크 요구사항: 네트워크 대역폭이 크고 장거리 전송에 적합한 네트워크가 필요하지만, 대기 시간에 민감하지 않습니다.

4. 사용 사례

Metro Mirror:
- 비즈니스 연속성: 데이터 센터 간의 짧은 거리에서 높은 데이터 일관성과 즉각적인 장애 복구가 필요한 경우.
- 고가용성: 금융 서비스나 중요한 데이터베이스 애플리케이션 등, 데이터 무결성이 최우선인 환경.
Global Mirror:
- 재해 복구: 지리적으로 먼 거리에서 데이터 복구가 필요할 때. 예를 들어, 천재지변이나 대규모 재해에 대비해 원거리 복제본을 유지하고자 할 때 사용.
- 장거리 백업: 데이터 손실 가능성을 최소화하면서 장거리 복제를 통해 데이터 보호를 보장합니다.

요약 비교

특성Metro MirrorGlobal Mirror

복제 거리	짧은 거리 (300km 이내)	긴 거리 (수천 km 이상)
복제 방식	동기식 복제	비동기식 복제
대기 시간	낮은 대기 시간 요구	긴 대기 시간 지원
데이터 일관성	높은 데이터 일관성	일관성이 약간 낮을 수 있음
성능 영향	더 많은 성능 영향 가능	성능 영향이 적음
사용 목적	고가용성 및 즉각적인 복구	장거리 재해 복구 및 데이터 보호

결론

Metro Mirror는 즉각적인 데이터 일관성과 고가용성이 중요한 환경에 적합합니다. 예를 들어, 금융 서비스와 같이 실시간 데이터 복구가 필요한 경우에 사용됩니다.
Global Mirror는 장거리 복제와 재해 복구가 필요한 환경에 적합하며, 비동기식 복제를 통해 데이터 손실을 최소화하면서도 네트워크 성능을 효율적으로 사용할 수 있습니다.

엑셀 '저장 안 함' 실수 시 데이터 복구 방법

Itlee — Thu, 14 Nov 2024 12:29:42 +0900

엑셀은 사용자가 작업 중 실수로 저장하지 않고 파일을 닫더라도, 자동 복구 기능을 통해 데이터를 복구할 수 있도록 설정되어 있습니다. 아래의 단계를 따라 복구를 시도해 보세요.

1. 엑셀 실행 후 '파일' 탭 클릭

엑셀을 실행한 후 상단의 '파일' 탭을 클릭합니다.

2. '열기' 선택 후 '최근에 사용한 통합 문서' 클릭

'열기' 메뉴를 선택한 후, 왼쪽 사이드바에서 **'최근에 사용한 통합 문서'**를 클릭합니다.

TIP: '최근에 사용한 통합 문서'는 최근에 열었던 문서 목록을 보여줍니다.

3. '저장되지 않은 통합 문서 복구' 클릭

화면 하단에서 '저장되지 않은 통합 문서 복구' 버튼을 찾아 클릭합니다.

4. 복구할 파일 선택 후 열기

자동 복구된 파일 목록이 나타나면, 복구하려는 파일을 선택한 뒤 **'열기'**를 클릭합니다.

5. 파일 저장

파일이 정상적으로 열리면 **'다른 이름으로 저장'**을 눌러 원하는 위치에 파일을 저장하세요. 이렇게 하면 중요한 작업이 손실되지 않도록 보호할 수 있습니다.

자동 복구 기능 설정 확인하기

자동 복구 기능이 제대로 설정되어 있는지 확인하는 것도 중요합니다. 다음 방법을 따라 설정을 확인하고 필요한 경우 변경해 보세요.

자동 복구 기능 설정 방법

엑셀에서 '파일' 탭 클릭 > '옵션' 선택.
'저장' 메뉴에서 **'자동 복구 정보 저장 간격'**이 활성화되어 있는지 확인합니다.
자동 저장 간격을 5분 정도로 설정하면, 데이터 손실을 최소화할 수 있습니다.

추가 팁: 데이터 손실을 예방하는 방법

수시로 저장하기: 중요한 작업을 할 때는 습관적으로 저장 버튼을 누르는 것이 좋습니다.
자동 저장 간격 단축: 자동 복구 기능을 사용 중일 때, 간격을 짧게 설정하면 더 자주 데이터를 백업할 수 있습니다.

결론

실수로 저장하지 않고 닫은 엑셀 파일도 복구할 수 있습니다. 평소 자동 복구 기능이 잘 작동하도록 설정해두고, 수시로 저장하는 습관을 들이면 데이터 손실 위험을 줄일 수 있습니다. 이 방법이 도움이 되셨길 바랍니다!

Vmware ESXi 인벤토리에서 제거, 디스크 삭제 차이

Itlee — Tue, 12 Nov 2024 14:54:35 +0900

VMware ESXi에서 VM을 제거할 때, “인벤토리에서 제거”와 “디스크에서 삭제”는 서로 다른 두 가지 작업을 수행합니다. 각 옵션의 차이점을 살펴보겠습니다.

1. 인벤토리에서 제거

설명: “인벤토리에서 제거”를 선택하면 ESXi의 vCenter 또는 관리 인터페이스(예: vSphere Client)에서 해당 가상 머신(VM)이 더 이상 보이지 않게 됩니다. 하지만 VM의 데이터(예: 가상 디스크, 설정 파일 등)는 여전히 데이터스토어에 남아 있습니다.
사용 시점: 나중에 해당 VM을 다시 등록하거나 다른 용도로 사용할 계획이 있을 때, VM의 데이터를 보존해야 하는 경우 이 옵션을 사용합니다.
결과:
- VM이 인벤토리에서 사라지지만, VM의 모든 파일은 데이터스토어에 그대로 존재합니다.
- 필요할 때 "등록" 옵션을 사용하여 VM을 다시 인벤토리에 추가할 수 있습니다.
파일 위치: VM의 구성 파일(.vmx), 디스크 파일(.vmdk) 등 모든 데이터는 ESXi 데이터스토어에 그대로 보존됩니다.

2. 디스크에서 삭제

설명: “디스크에서 삭제”를 선택하면 해당 VM이 인벤토리에서 제거되는 것뿐만 아니라 VM에 관련된 모든 파일이 데이터스토어에서 완전히 삭제됩니다. 이 작업은 복구가 불가능하므로 매우 신중해야 합니다.
사용 시점: VM을 완전히 삭제하고, VM의 데이터가 더 이상 필요하지 않을 때 이 옵션을 선택합니다.
결과:
- VM이 인벤토리에서 사라지고, 데이터스토어에서 VM의 구성 파일 및 가상 디스크가 모두 삭제됩니다.
- 삭제된 파일은 데이터스토어에서 복구할 수 없습니다(백업이 없는 경우).
데이터 관리: 중요한 데이터가 포함되어 있는지 반드시 확인한 후 삭제해야 하며, 필요한 경우 삭제 전에 백업을 수행하는 것이 좋습니다.

요약 비교

인벤토리에서 제거 : VM은 더 이상 vSphere Client 등에서 보이지 않지만, 데이터스토어에 VM의 데이터는 여전히 존재합니다. 나중에 다시 등록할 수 있습니다.
디스크에서 삭제: VM은 인벤토리에서 사라지고 데이터스토어에서 관련 파일이 완전히 삭제됩니다. 복구가 어렵기 때문에 주의가 필요합니다.

예제 시나리오:

인벤토리에서 제거 : VM을 일시적으로 사용하지 않지만 나중에 다시 사용할 계획이 있는 경우, VM을 데이터스토어에 남겨두고 인벤토리에서만 제거합니다.
디스크에서 삭제: VM이 완전히 필요 없어졌거나, 데이터를 완전 삭제해야 할 때 이 옵션을 선택합니다.

주의사항

백업 필수: "디스크에서 삭제"를 하기 전에 중요한 데이터는 반드시 백업하세요.
디스크 공간 관리: 불필요한 VM 파일이 데이터스토어에 남아있는 것을 방지하기 위해 정기적으로 공간을 관리하는 것이 좋습니다.

Linux, Windows Server 시스템 성능 최적화 방법: 실무 팁과 필수 설정

Itlee — Mon, 11 Nov 2024 16:51:35 +0900

IT 인프라에서 성능 최적화는 비용 절감과 서비스 안정성을 위해 매우 중요한 과제입니다. 특히 대규모 시스템 환경에서는 자원의 효율적 활용이 핵심입니다. 이번 글에서는 Linux, Windows Server, AIX의 성능을 최적화하는 방법과 실무에서 바로 적용할 수 있는 팁을 소개합니다.

1. Linux 성능 최적화

1) CPU 및 메모리 관리

top, htop 명령어 사용: 시스템 리소스 사용 현황을 실시간으로 모니터링해 성능 병목을 파악합니다.
swap 공간 관리: 메모리 부족 시 사용하는 swap을 적절히 설정해 성능 저하를 방지합니다.

top  # 기본 리소스 사용 현황 확인
htop  # 더 시각적으로 리소스 사용 현황 파악

2) 디스크 I/O 최적화

iostat: 디스크 입출력 속도를 모니터링해 디스크 병목 현상을 분석합니다.
```
iostat -x 5  # 디스크 사용률과 I/O 상태 실시간 모니터링
```
파일시스템 튜닝: noatime 옵션을 사용해 파일 접근 시간을 기록하지 않음으로써 디스크 I/O를 줄입니다.

mount -o remount,noatime /  # noatime 옵션 활성화

3) 네트워크 최적화

sysctl 설정: 네트워크 성능을 향상시키기 위해 커널 매개변수를 조정합니다.

sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216

실무 팁:
자동화 도구인 Ansible이나 Puppet을 사용해 성능 최적화 설정을 대규모로 배포할 수 있습니다.

2. Windows Server 성능 최적화

1) CPU 및 메모리 성능 관리

작업 관리자 사용: 실시간으로 CPU, 메모리, 디스크, 네트워크 사용량을 모니터링하고, 리소스를 많이 사용하는 프로세스를 확인합니다.
RAM 최적화: 페이지 파일 크기를 최적화하고, 물리적 메모리를 확장해 성능을 개선합니다.
- 페이지 파일 설정: Control Panel > System > Advanced System Settings > Performance에서 조정 가능합니다.

2) 디스크 최적화

디스크 조각 모음: defrag 명령어를 사용해 디스크 조각화를 줄여 I/O 성능을 향상시킵니다.
```
defrag C: /O  # 최적화 및 조각 모음 실행
```
스토리지 관리: 디스크 공간을 주기적으로 점검하고 불필요한 데이터를 삭제해 여유 공간을 확보합니다.

3) 네트워크 성능 최적화

QoS 설정: 네트워크 트래픽 우선순위를 설정해 중요한 서비스의 대역폭을 보장합니다. Group Policy Editor에서 설정할 수 있습니다.
TCP 설정 최적화: 레지스트리에서 TCP/IP 관련 설정을 조정해 네트워크 성능을 향상시킵니다.

실무 팁:
Windows PowerShell을 사용해 성능 점검과 최적화 작업을 자동화하는 스크립트를 작성해보세요.

추가 팁: 성능 최적화를 위한 모니터링 도구 소개

1) Prometheus 및 Grafana

설명: 오픈 소스 모니터링 툴로, 시스템 리소스 사용량을 시각화할 수 있습니다. 대시보드를 구성해 실시간으로 성능 상태를 확인하세요.

2) Nagios

설명: 서버 및 네트워크를 모니터링하고, 문제가 발생할 경우 알림을 보내주는 도구입니다. 주요 서비스의 가용성을 관리하는 데 유용합니다.

결론:

시스템 성능 최적화는 운영 환경을 안정적으로 유지하기 위해 필수적인 작업입니다. 이 글에서 소개한 성능 최적화 방법과 실무 팁을 참고해 시스템의 효율성을 극대화해 보세요. 앞으로도 지속적인 모니터링과 최적화 작업을 통해 더욱 안정적인 인프라를 구축할 수 있습니다.

Linux, Windows Server 보안 강화 가이드: 필수 보안 설정과 실무 팁

Itlee — Mon, 11 Nov 2024 16:40:26 +0900

서버 보안은 기업의 IT 인프라에서 가장 중요한 요소 중 하나입니다. 오늘날 점점 증가하는 보안 위협 속에서 시스템 관리자는 서버의 보안 설정을 강화해야 할 책임이 있습니다. 이번 글에서는 Linux, Windows Server, AIX의 보안 설정을 단계별로 설명하고 실무에서 바로 활용할 수 있는 팁을 제공하겠습니다.

1. Linux 보안 강화 설정

1) SSH 보안

기본 포트 변경: 기본 포트 22는 공격에 가장 많이 노출됩니다. SSH 설정 파일(/etc/ssh/sshd_config)에서 포트를 변경해보세요.

Port 2222  # 예: 2222로 포트 변경

루트 로그인 차단: 루트 계정으로 직접 로그인하는 것은 보안 위험을 높입니다. 설정 파일에서 PermitRootLogin을 no로 변경해 차단합니다.

PermitRootLogin no

키 기반 인증 설정: 비밀번호 대신 공개 키를 사용해 보안성을 높입니다. /etc/ssh/sshd_config에서 PasswordAuthentication을 no로 설정하세요.

PasswordAuthentication no

2) 방화벽 설정

UFW: Ubuntu 기반 시스템에서 쉽게 사용할 수 있는 방화벽 도구입니다. 기본 규칙을 설정하고 필요한 포트만 허용하세요.

sudo ufw enable
sudo ufw allow 80/tcp  # HTTP 포트 허용
sudo ufw allow 443/tcp  # HTTPS 포트 허용

firewalld: RHEL 계열에서 사용합니다. 서비스와 영역을 설정해 보다 세분화된 보안 정책을 적용할 수 있습니다.

sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

3) 로그 모니터링

로그 관리: journalctl 명령을 사용해 시스템 로그를 점검하고, 자동화된 알림을 설정해 중요한 로그 이벤트를 실시간으로 감시합니다.

journalctl -xe  # 최근 에러 로그 확인

실무 팁:
정기적으로 시스템을 업데이트하고 불필요한 서비스는 비활성화해 공격 표면을 줄이세요. cron을 이용해 자동 패치 스크립트를 작성하는 것도 좋습니다.

2. Windows Server 보안 강화

1) Active Directory 보안

권한 최소화: 사용자 계정에 최소 권한만 부여해 보안을 강화합니다. 그룹 정책(GPO)을 활용해 사용자와 컴퓨터에 대한 정책을 설정합니다.
감사 정책 설정: 보안 로그를 모니터링하고 비정상적인 활동을 감지합니다. gpedit.msc에서 로컬 보안 정책을 구성하세요.
- 로그온 실패: 실패한 로그인 시도를 기록해 무차별 공격을 감지합니다.
- 계정 변경: 사용자 계정에 대한 변경 내역을 모니터링합니다.

2) WSUS 설정

Windows Update Server 관리: WSUS(Windows Server Update Services)를 사용해 보안 패치를 중앙에서 관리합니다. 모든 클라이언트 시스템이 최신 보안 업데이트를 적용하도록 설정합니다.
자동 승인: 중요 업데이트를 자동 승인하도록 설정해 신속히 패치를 적용합니다.

3) BitLocker

드라이브 암호화: BitLocker를 사용해 디스크 전체를 암호화하고 물리적인 데이터 유출을 방지합니다. TPM(신뢰할 수 있는 플랫폼 모듈)을 사용해 추가 보안을 설정하세요.
- BitLocker 활성화: Control Panel > System and Security > BitLocker Drive Encryption에서 설정할 수 있습니다.

4) RDP 보안

포트 변경: RDP의 기본 포트 3389를 변경해 공격을 방지합니다. 레지스트리 편집기를 사용해 포트를 변경하세요.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber

네트워크 레벨 인증: RDP 연결 시 추가 인증 단계를 추가해 보안을 강화합니다. 서버 관리자에서 설정할 수 있습니다.

실무 팁:
Windows Defender와 같은 내장 보안 솔루션을 활성화하고, EDR 솔루션을 도입해 실시간으로 위협을 탐지하세요. PowerShell을 이용해 자동화된 보안 점검 스크립트를 실행하는 것도 추천합니다.

추가 팁: IT 보안에 대한 최신 동향

1) 제로 트러스트(Zero Trust) 보안 모델

설명: 모든 접근을 신뢰하지 않고 검증하는 보안 모델입니다. 네트워크 내외부를 불문하고 모든 요청을 검증해 보안을 강화합니다.
도입 방법: MFA(다중 인증)와 마이크로세그먼테이션을 사용해 네트워크를 보호하세요.

2) 보안 자동화

Ansible: 보안 설정을 자동화하고 반복 작업을 줄일 수 있습니다. SSH 키 배포, 방화벽 설정 등을 자동화할 수 있습니다.
실행 예시: Ansible Playbook을 사용해 여러 서버의 보안 설정을 동시에 관리하세요.

3) 클라우드 보안

온프레미스 vs. 클라우드 보안: 두 환경에서 보안 요구 사항이 다릅니다. 클라우드 환경에서는 CSP의 보안 도구를 활용하고, 데이터 암호화를 필수로 적용하세요.

결론:

이 글에서 설명한 보안 설정을 활용해 여러분의 시스템을 더욱 안전하게 보호할 수 있습니다. 각 서버에 적합한 보안 정책을 적용하고, 정기적인 점검과 모니터링으로 위협을 최소화하세요. 앞으로도 지속적인 보안 개선을 통해 IT 인프라를 안전하게 운영하시길 바랍니다.

SAS와 SATA: 속도와 성능의 차이 알아보기

Itlee — Thu, 22 Aug 2024 09:28:53 +0900

컴퓨터와 저장 장치 간의 연결 인터페이스로 많이 사용되는 SAS(Serial Attached SCSI)와 SATA(Serial ATA). 두 기술은 모두 데이터를 전송하지만, 속도와 성능, 그리고 용도에서 큰 차이가 있습니다. 이 글에서는 SAS와 SATA의 주요 차이점에 대해 쉽게 설명해 드리겠습니다.

1. SAS(Serial Attached SCSI)

전송 속도: 최대 24 Gbps까지 지원
- SAS 3.0: 12 Gbps
- SAS 4.0: 24 Gbps
주요 특징:
- 고속 데이터 전송이 가능하며, 많은 데이터를 빠르게 처리할 수 있습니다.
- 높은 신뢰성과 데이터 무결성을 제공, 기업의 서버와 데이터 센터에서 주로 사용됩니다.
- 동시 다중 작업 처리에 강점이 있으며, 핫 스왑(Hot Swap) 기능도 지원해 서버 유지보수가 용이합니다.
사용 환경:
- 주로 서버, 데이터 센터, 고성능 컴퓨팅 환경에서 사용

2. SATA(Serial ATA)

전송 속도:
- SATA I: 1.5 Gbps
- SATA II: 3 Gbps
- SATA III: 6 Gbps
주요 특징:
- 비용 효율적으로, 저렴한 가격에 구매 가능.
- 낮은 소비전력으로 일반적인 데스크탑 PC나 노트북에 적합.
- 설치가 쉽고, 개인용으로 사용하기에 충분한 성능을 제공합니다.
사용 환경:
- 가정용 PC, 노트북, 저장 장치 등에 주로 사용

3. SAS vs SATA: 주요 차이점 정리

속도: SAS는 최대 24 Gbps, SATA는 최대 6 Gbps로 SAS가 훨씬 빠릅니다.
신뢰성 및 성능: SAS는 고성능과 높은 신뢰성이 필요한 환경에서, SATA는 일반 사용자용으로 적합합니다.
비용: SAS는 가격이 비싸지만 그만큼 성능이 뛰어나며, SATA는 경제적입니다.

결론

SAS와 SATA는 각기 다른 용도와 목적을 가진 인터페이스입니다. 기업용 서버나 데이터 센터처럼 높은 성능과 신뢰성이 중요한 환경에서는 SAS를, 일반적인 가정용 PC나 노트북에서는 SATA를 선택하는 것이 적합합니다.

LVM 생성

Itlee — Thu, 30 May 2024 15:34:49 +0900

LVM이란?

LVM(Logical Volume Manager)은 물리적인 저장 장치들을 논리적으로 관리할 수 있게 해주는 시스템입니다. 이를 통해 저장 장치를 보다 유연하고 효율적으로 사용할 수 있습니다. LVM은 여러 디스크를 하나의 논리적 볼륨으로 묶어서 관리하거나, 기존의 논리 볼륨을 쉽게 확장하거나 축소할 수 있게 해줍니다.

LVM의 주요 구성 요소

Physical Volume (PV):
- 물리적인 저장 장치를 의미합니다. 예를 들어, 하드 디스크나 SSD 등이 이에 해당합니다.
- 명령어: pvcreate
Volume Group (VG):
- 여러 개의 Physical Volume을 묶어서 하나의 논리적 단위로 관리합니다.
- 명령어: vgcreate
Logical Volume (LV):
- Volume Group 내에서 논리적인 파티션을 의미합니다. 실제 데이터를 저장하는 공간입니다.
- 명령어: lvcreate

LVM의 장점

유연성:
- 디스크 추가 및 제거가 쉽습니다. 예를 들어, 데이터베이스의 크기가 커짐에 따라 쉽게 디스크를 추가하여 논리 볼륨을 확장할 수 있습니다.
크기 조정:
- 논리 볼륨의 크기를 동적으로 조정할 수 있습니다. 디스크 공간이 부족해지면 기존 논리 볼륨을 확장하고, 필요에 따라 축소할 수도 있습니다.
스냅샷:
- 스냅샷 기능을 통해 특정 시점의 데이터를 백업할 수 있습니다. 이를 통해 데이터 손실 시 빠르게 복구할 수 있습니다.
성능:
- 여러 디스크를 하나의 논리 볼륨으로 묶어 병렬로 데이터를 읽고 쓸 수 있어 성능을 향상시킬 수 있습니다.

LVM 생성

1. PV 생성

새로운 물리 볼륨(Physical Volume, PV)을 생성합니다

pvcreate /dev/sdb

2. VG 생성

생성된 PV를 사용하여 볼륨 그룹(Volume Group, VG)을 생성합니다

vgcreate vgname /dev/sdb

3. LV 생성

볼륨 그룹 내에서 논리 볼륨(Logical Volume, LV)을 생성합니다. 각각 3GB 크기의 세 개의 논리 볼륨을 만듭니다

 lvcreate -L 3g -n lvname vgname
 lvcreate -L 3g -n lvname2 vgname
 lvcreate -L 3g -n lvname3 vgname

4. LV 확인

생성된 논리 볼륨을 확인합니다:

lvs

출력 예시

  LV      VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root    centos -wi-ao---- <17.00g                                                    
  swap    centos -wi-ao----   2.00g                                                    
  lvname  vgname -wi-a-----   3.00g                                                    
  lvname2 vgname -wi-a-----   3.00g                                                    
  lvname3 vgname -wi-a-----   3.00g

5. 파일 시스템 생성

논리 볼륨에 파일 시스템을 생성합니다

 mkfs -t ext4 /dev/mapper/vgname-lvname
 mkfs -t ext4 /dev/mapper/vgname-lvname2
 mkfs -t ext4 /dev/mapper/vgname-lvname3

6. UUID 확인

논리 볼륨의 UUID를 확인합니다

blkid

출력 예시

/dev/mapper/vgname-lvname: UUID="0459e228-ec66-4404-a4bc-96f622247fb5" TYPE="ext4" 
/dev/mapper/vgname-lvname2: UUID="1a51f530-dcca-45bf-8cbb-30549ed93aa9" TYPE="ext4" 
/dev/mapper/vgname-lvname3: UUID="d48114f6-545f-4594-af49-b961a855cd8d" TYPE="ext4"

7. fstab에 추가

UUID를 /etc/fstab 파일에 추가하여 부팅 시 자동으로 마운트되도록 설정합니다.

vi /etc/fstab

다음 내용을 추가합니다.

UUID=0459e228-ec66-4404-a4bc-96f622247fb5       /lvname ext4    defaults        0       0
UUID=1a51f530-dcca-45bf-8cbb-30549ed93aa9       /lvname2        ext4    defaults        0       0
UUID=d48114f6-545f-4594-af49-b961a855cd8d       /lvname3        ext4    defaults        0       0

8. 마운트 포인트 디렉토리 생성

논리 볼륨을 마운트할 디렉토리를 생성합니다:

 mkdir /lvname
 mkdir /lvname2
 mkdir /lvname3

9. 마운트

모든 파일 시스템을 마운트합니다.

mount -a

10. 확인

마운트된 파일 시스템을 확인합니다.

df -h

출력 예시

/dev/mapper/vgname-lvname   2.9G  9.0M  2.8G   1% /lvname
/dev/mapper/vgname-lvname2  2.9G  9.0M  2.8G   1% /lvname2
/dev/mapper/vgname-lvname3  2.9G  9.0M  2.8G   1% /lvname3

이로써 새로운 디스크를 추가하고 논리 볼륨을 생성하여 파일 시스템을 설정하고 마운트하는 작업이 완료되었습니다.

LVM 파일시스템 용량 증설

Itlee — Thu, 30 May 2024 15:21:00 +0900

리눅스 시스템에서 디스크를 추가하고, 논리 볼륨(Logical Volume, LV)을 확장하는 과정입니다. 각각의 단계는 다음과 같습니다

1. 디스크 인식

새 디스크를 시스템에서 인식시키려면 아래 명령어를 사용합니다. 디스크가 자동으로 인식되지 않는 경우, 수동으로 인식시킬 수 있습니다:

 echo "- - -" > /sys/class/scsi_host/host0/scan

디스크가 여전히 인식되지 않으면 hostX 값을 0에서 5까지 변경하며 시도합니다:

 echo "- - -" > /sys/class/scsi_host/host1/scan
 echo "- - -" > /sys/class/scsi_host/host2/scan
 echo "- - -" > /sys/class/scsi_host/host3/scan
 echo "- - -" > /sys/class/scsi_host/host4/scan
 echo "- - -" > /sys/class/scsi_host/host5/scan

2. 추가된 디스크 확인

다음 명령어를 통해 추가된 디스크를 확인합니다.

 fdisk -l | grep sd

출력 예시는 다음과 같습니다:

Disk /dev/sda: 21.5 GB, 21474836480 bytes, 41943040 sectors
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    41943039    19921920   8e  Linux LVM
Disk /dev/sdb: 10.7 GB, 10737418240 bytes, 20971520 sectors
Disk /dev/sdc: 5368 MB, 5368709120 bytes, 10485760 sectors

3. 추가된 디스크에서 PV 생성

새로 추가된 디스크에서 물리 볼륨(Physical Volume, PV)을 생성합니다.

 pvcreate /dev/sdc

출력 예시

Physical volume "/dev/sdc" successfully created.

4. 추가할 LV 확인

현재 시스템의 논리 볼륨을 확인합니다

lsblk

NAME             MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                8:0    0   20G  0 disk 
├─sda1             8:1    0    1G  0 part /boot
└─sda2             8:2    0   19G  0 part 
  ├─centos-root  253:0    0   17G  0 lvm  /
  └─centos-swap  253:1    0    2G  0 lvm  [SWAP]
sdb                8:16   0   10G  0 disk 
├─vgname-lvname  253:2    0    3G  0 lvm  /lvname
├─vgname-lvname2 253:3    0    3G  0 lvm  /lvname2
└─vgname-lvname3 253:4    0    3G  0 lvm  /lvname3
sdc                8:32   0    5G  0 disk 
sr0               11:0    1 1024M  0 rom

5. VG에 추가

새로 생성한 PV를 볼륨 그룹(VG)에 추가합니다.

vgextend vgname /dev/sdc

출력 예시

Volume group "vgname" successfully extended

6. 용량을 확장할 디바이스 경로 확인

현재 활성화된 논리 볼륨을 확인합니다.

lvscan

출력 예시

ACTIVE            '/dev/vgname/lvname' [3.00 GiB] inherit
ACTIVE            '/dev/vgname/lvname2' [3.00 GiB] inherit
ACTIVE            '/dev/vgname/lvname3' [3.00 GiB] inherit
ACTIVE            '/dev/centos/root' [<17.00 GiB] inherit
ACTIVE            '/dev/centos/swap' [2.00 GiB] inherit

7. 용량 증설

논리 볼륨의 용량을 확장합니다.

 lvextend -l +100%FREE -n /dev/vgname/lvname3

출력 예시

Size of logical volume vgname/lvname3 changed from 3.00 GiB (768 extents) to 8.99 GiB (2302 extents).
Logical volume vgname/lvname3 successfully resized.

8. 파일 시스템 타입 확인

현재 파일 시스템 타입을 확인합니다.

 df -Th

출력 예시

Filesystem                 Type      Size  Used Avail Use% Mounted on
devtmpfs                   devtmpfs  894M     0  894M   0% /dev
tmpfs                      tmpfs     910M     0  910M   0% /dev/shm
tmpfs                      tmpfs     910M   10M  900M   2% /run
tmpfs                      tmpfs     910M     0  910M   0% /sys/fs/cgroup
/dev/mapper/centos-root    xfs        17G  5.3G   12G  31% /
/dev/sda1                  xfs      1014M  233M  782M  23% /boot
/dev/mapper/vgname-lvname3 ext4      2.9G  9.0M  2.8G   1% /lvname3
/dev/mapper/vgname-lvname2 ext4      2.9G  9.0M  2.8G   1% /lvname2
/dev/mapper/vgname-lvname  ext4      2.9G  9.0M  2.8G   1% /lvname
tmpfs                      tmpfs     182M     0  182M   0% /run/user/0

9. 파일 시스템 크기 조정

확장한 논리 볼륨의 파일 시스템을 확장합니다. lvname3이 ext4 파일 시스템을 사용하므로 다음 명령어를 실행합니다:

 resize2fs /dev/vgname/lvname3

출력 예시

resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vgname/lvname3 is mounted on /lvname3; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/vgname/lvname3 is now 2357248 blocks long.

파일 시스템이 xfs인 경우에는 다음 명령어를 사용합니다:

xfs_growfs /dev/vgname/lvname3

이로써 새로운 디스크를 추가하고 논리 볼륨의 크기를 확장하는 작업이 완료되었습니다.

Rocky Linux 8 / 9, Alma Linux 8/9 local repository 로컬 레포지터리 구성

Itlee — Mon, 27 May 2024 16:23:59 +0900

서버 운영 시 폐쇄망 환경에서는 외부 저장소에 접근할 수 없으므로, 로컬 저장소를 만들어 패키지를 설치해야 합니다. 이를 위해 Rocky Linux ISO 파일을 다운로드하고, 해당 ISO 파일을 마운트한 후 내용을 로컬 디렉토리에 복사합니다. 복사된 파일을 기반으로 로컬 레포지토리 설정 파일을 작성하여 저장소를 구성합니다. 이후 dnf 또는 yum을 통해 패키지를 설치할 수 있습니다.

1. ISO 파일 다운로드 및 마운트

공식 사이트에서 해당 OS의 ISO 파일을 다운로드합니다.
ISO 파일을 마운트합니다.

mount /dev/sr0 /mnt/

2. 로컬 디렉토리에 복사

마운트된 ISO 파일의 내용을 로컬 디렉토리로 복사합니다

cp -a /mnt/. /iso/

3. 로컬 레포지토리 설정

/etc/yum.repos.d/ 디렉토리에 새로운 .repo 파일을 생성합니다

cd /etc/yum.repos.d
mkdir repobak
mv *.repo ./repobak
vi local.repo

[ISO_AppStream]
name=local_AppStream
baseurl=file:///iso/AppStream/
enabled=1
gpgcheck=0

[ISO_BaseOS]
name=local_BaseOS
baseurl=file:///iso/BaseOS/
enabled=1
gpgcheck=0

4. 레포지토리 캐시 업데이트

dnf 또는 yum을 사용해 캐시를 업데이트합니다

dnf clean all
dnf makecache

5. 패키지 설치

이제 로컬 레포지토리를 통해 패키지를 설치할 수 있습니다

dnf install package-name

centos 8 이상 버전 local repository

Itlee — Thu, 2 Nov 2023 16:28:47 +0900

외부와 통신이 안되는 환경에서는 cd에 있는 패키지들을 복사해 언제든 필요한 패키지를 설치할 수 있다.

설정방법으로는

1. 설치 cd 넣기

2. cd-rom 마운트

#mount /dev/sr0 /mnt/cdrom

3. 복사할 디렉토리 생성

#mkdir /repository

4. cd에 있는 내용 복사

#cp -a /mnt/cdrom/* /repository

5. 기존 repository 삭제 또는 이동

# mv /etc/yum.repos.d/*.repo /tmp/

6. repository 등록
#vi /etc/yum.repos.d/local.repo
[BaseOS]
name=BaseOS
baseurl=file:///repository/BaseOS
enabled=1
gpgcheck=0

[AppStream]
name=AppStream
baseurl=file:///repository/AppStream
enabled=1
gpgcheck=0

7. 설정 적용 및 검증

#yum clean all

# yum repolist

windows server hba wwn 확인

Itlee — Mon, 4 Sep 2023 14:42:07 +0900

powershell 실행 후

get-initiatorport

입력 후 PortAddress 탭에 wwn 적혀있습니다.

windows server storage uuid값 확인

Itlee — Mon, 4 Sep 2023 14:39:07 +0900

cmd 창에서 mpclaim -s -d 입력해서 디스크 넘버확인

mpclaim -s -d [디스크 넘버] 입력하면 uuid값 확인 가능

vnc server 설정

Itlee — Mon, 15 May 2023 17:33:33 +0900

CentOS 6에서 GUI로 원격 접속하기 위해서는 VNC (Virtual Network Computing)를 사용할 수 있습니다. 다음은 CentOS 6에서 VNC를 설정하고 원격으로 접속하는 방법입니다:

1. VNC 패키지 설치:

CentOS 6에 VNC 서버 패키지를 설치합니다. 터미널에서 다음 명령을 실행합니다:

yum install tigervnc-server

2. VNC 사용자 비밀번호 설정:
VNC 서버에 접속하기 위해 사용될 비밀번호를 설정합니다. 다음 명령을 실행합니다:

vncpasswd

비밀번호를 입력하고 확인합니다. 이 비밀번호는 나중에 VNC 클라이언트에서 접속할 때 사용됩니다.

3. VNC 서버 구성:

VNC 서버 설정 파일을 편집합니다. 다음 명령을 실행하여 설정 파일을 엽니다:

vi ~/.vnc/xstartup

파일 내용을 아래와 같이 수정합니다:

#!/bin/sh
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

저장 후 파일을 닫습니다.

4. VNC 서비스 시작:
VNC 서비스를 시작합니다. 다음 명령을 실행합니다:

vncserver

처음 실행하는 경우, VNC 서버의 디스플레이 번호와 비밀번호를 설정하라는 메시지가 표시됩니다. 예를 들어, :1과 같은 디스플레이 번호를 선택하고 비밀번호를 입력합니다.

5. 방화벽 설정
CentOS 6의 방화벽 설정에서 VNC 포트인 5901을 허용해야 합니다. 다음 명령을 사용하여 방화벽에 포트를 추가합니다:

iptables -I INPUT -p tcp --dport 5901 -j ACCEPT
service iptables save

이제 CentOS 6 시스템에는 VNC 서버가 설정되었으며, 로컬 또는 원격 시스템에서 VNC 클라이언트를 사용하여 접속할 수 있습니다. VNC 클라이언트 프로그램(예: RealVNC, TightVNC, TigerVNC 등)을 사용하여 CentOS 6 시스템의 IP 주소나 호스트 이름과 설정한 VNC 포트(기본적으로 5901)를 입력하고 비밀번호를 입력하면 원격으로 CentOS 6 시스템에 GUI로 접속할 수 있습니다.

Centos Rhel 버전 update 와 downgrade (7.x)

Itlee — Thu, 24 Mar 2022 17:35:19 +0900

Update

원하는 버전을 cdrom 마운트 후 local yum 구성

local yum 구성방법 https://frog11.tistory.com/90

리눅스 local yum 구성

원하는 버전 Centos, Rhel CD rom 마운트 1. Package를 복사할 디렉토리 생성 [root@localhost /]# mkdir -p /redhat7/Packages/ 2. CD 안의 RPM파일 디렉토리로 copy [root@localhost /]# mount /dev/sr0 /cdrom..

frog11.tistory.com

1. 기존버전 7.6

[root@localhost /]# cat /etc/redhat-release 
CentOS Linux release 7.6.1810 (Core)

2. 업데이트 할 버전 7.9로 업데이트

[root@localhost /]# yum update -y
Loaded plugins: fastestmirror, langpacks, versionlock
Loading mirror speeds from cached hostfile
Excluding 4 updates due to versionlock (use "yum versionlock status" to show them)
Resolving Dependencies
--> Running transaction check
---> Package GeoIP.x86_64 0:1.5.0-13.el7 will be updated
---> Package GeoIP.x86_64 0:1.5.0-14.el7 will be an update

** 솔루션 영향도에 따라 update를 하지 말아야할 패키지들이 있을 경우 versionlock 기능이 있다.

[root@localhost Packages]# yum versionlocl java*

명령어가 설치되어 있지 않을 경우 아래 명령어로 설치

[root@localhost /]# yum -y install yum-plugin-versionlock

Downgrade

1. update 후 버전

[root@localhost /]# cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)

2. 이전 버전 7.6로 local repository 구성

https://frog11.tistory.com/90

리눅스 local yum 구성

frog11.tistory.com

3. yum history로 업데이트 내역 확인

[root@localhost /]# yum history
Loaded plugins: fastestmirror, langpacks, versionlock
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    12 | root <root>              | 2022-03-24 17:18 | I, O, U        |  682 EE

history list

4. yum protect 부분에 systemd가 포함되어있어 파일내용을 백업 후 기존파일 삭제

[root@localhost /]# cd /etc/yum/protected.d/
[root@localhost protected.d]# ls -l
total 8
-rw-r--r--. 1 root root 8 Oct  2  2020 systemd.conf

[root@localhost protected.d]# mv systemd.conf systemd.conf.bak

5. yum history undo [ID]로 downgrade

[root@localhost protected.d]# yum history undo 12
Loaded plugins: fastestmirror, langpacks, versionlock
Undoing transaction 12, from Thu Mar 24 17:18:23 2022
    Updated     GeoIP-1.5.0-13.el7.x86_64                                        @rhel7repository
    Update            1.5.0-14.el7.x86_64                                        @rhel7.9repository
    Updated     LibRaw-0.14.8-5.el7.20120830git98d925.x86_64                     @rhel7repository

리눅스 local yum 구성

Itlee — Thu, 24 Mar 2022 17:15:17 +0900

원하는 버전 Centos, Rhel CD rom 마운트

1. Package를 복사할 디렉토리 생성

[root@localhost /]# mkdir -p /redhat7/Packages/

2. CD 안의 RPM파일 디렉토리로 copy

[root@localhost /]# mount /dev/sr0 /cdrom
mount: /dev/sr0 is write-protected, mounting read-only
[root@localhost /]# df 
Filesystem              1K-blocks     Used Available Use% Mounted on
/dev/sr0                  4600876  4600876         0 100% /cdrom

[root@localhost /]# cd /cdrom/Packages
[root@localhost /]# cp -a . /redhat7/Packages

3. YUM의 그룹 명령어를 사용하기 위한 comps.xml 파일 copy

[root@localhost /]# cd /cdrom/repodata/
[root@localhost repodata]# cp *comps.xml.gz /redhat7/
[root@localhost repodata]# cd /redhat7/
[root@localhost redhat7]# mv *comps.xml.gz comps.xml.gz
[root@localhost redhat7]# gzip -d comps.xml.gz

4. createrepo 명령어를 사용하기 위한 패키지 설치

[root@localhost redhat7]# cd /redhat7/Packages/
[root@localhost Packages]# rpm -ivh createrepo-0.9.9-28.el7.noarch.rpm python-deltarpm-3.6-3.el7.x86_64.rpm deltarpm-3.6-3.el7.x86_64.rpm
[root@localhost redhat7]# cd /redhat7/
[root@localhost redhat7]# createrepo -g comps.xml /redhat7/

5. yum repository 데몬에 local.repo 신규파일 생성

[root@localhost Packages]# cd /etc/yum.repos.d/
[root@localhost yum.repos.d]# vi local.repo

[rhel7repository]
name=Redhat local repository
baseurl=file:///redhat7/
enabled=1
gpgcheck=0

6. local repository test

[root@localhost / ]# yum list | more

유용한 yum 명령어

Itlee — Tue, 7 Dec 2021 13:37:14 +0900

yum 이란 repository 를 통해 rpm 을 배포하고 의존성 관리를 하므로 손쉽게 패키지를 관리할수 있다.

1. yum 명령어로 rpm 추출

# yum install --downloadonly --downloaddir=/yumlocal python

의존성이 있는 경우 같이 설치된다는 장점이 있다.

[root@localhost yumlocal]# yum install --downloadonly --downloaddir=/yumlocal python
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: mirror.kakao.com
 * extras: mirror.kakao.com
 * updates: mirrors.aliyun.com
Resolving Dependencies
--> Running transaction check
---> Package python.x86_64 0:2.7.5-89.el7 will be updated
---> Package python.x86_64 0:2.7.5-90.el7 will be an update
--> Processing Dependency: python-libs(x86-64) = 2.7.5-90.el7 for package: python-2.7.5-90.el7.x86_64
--> Running transaction check
---> Package python-libs.x86_64 0:2.7.5-89.el7 will be updated
---> Package python-libs.x86_64 0:2.7.5-90.el7 will be an update
updates/7/x86_64/filelists_db                                                      | 7.0 MB  00:00:01     
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================
 Package                   Arch                 Version                       Repository             Size
==========================================================================================================
Updating:
 python                    x86_64               2.7.5-90.el7                  updates                96 k
Updating for dependencies:
 python-libs               x86_64               2.7.5-90.el7                  updates               5.6 M

Transaction Summary
==========================================================================================================
Upgrade  1 Package (+1 Dependent package)

Total download size: 5.7 M
Background downloading packages, then exiting:
exiting because "Download Only" specified

2. # yum localinstall *.rpm

받은 rpm 파일 설치

[root@localhost yumlocal]# yum localinstall *.rpm
Loaded plugins: fastestmirror, langpacks
Examining python-2.7.5-90.el7.x86_64.rpm: python-2.7.5-90.el7.x86_64
Marking python-2.7.5-90.el7.x86_64.rpm as an update to python-2.7.5-89.el7.x86_64
Examining python-libs-2.7.5-90.el7.x86_64.rpm: python-libs-2.7.5-90.el7.x86_64
Marking python-libs-2.7.5-90.el7.x86_64.rpm as an update to python-libs-2.7.5-89.el7.x86_64
Resolving Dependencies
--> Running transaction check
---> Package python.x86_64 0:2.7.5-89.el7 will be updated
---> Package python.x86_64 0:2.7.5-90.el7 will be an update
---> Package python-libs.x86_64 0:2.7.5-89.el7 will be updated
---> Package python-libs.x86_64 0:2.7.5-90.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================
 Package             Arch           Version                Repository                                Size
==========================================================================================================
Updating:
 python              x86_64         2.7.5-90.el7           /python-2.7.5-90.el7.x86_64               79 k
 python-libs         x86_64         2.7.5-90.el7           /python-libs-2.7.5-90.el7.x86_64          24 M

Transaction Summary
==========================================================================================================
Upgrade  2 Packages

Total size: 24 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.

  Updating   : python-libs-2.7.5-90.el7.x86_64                                                        1/4 
  Updating   : python-2.7.5-90.el7.x86_64                                                             2/4 
  Cleanup    : python-2.7.5-89.el7.x86_64                                                             3/4 
  Cleanup    : python-libs-2.7.5-89.el7.x86_64                                                        4/4 
  Verifying  : python-2.7.5-90.el7.x86_64                                                             1/4 
  Verifying  : python-libs-2.7.5-90.el7.x86_64                                                        2/4 
  Verifying  : python-2.7.5-89.el7.x86_64                                                             3/4 
  Verifying  : python-libs-2.7.5-89.el7.x86_64                                                        4/4 

Updated:
  python.x86_64 0:2.7.5-90.el7                      python-libs.x86_64 0:2.7.5-90.el7                     

Complete!

3. # yum history

yum 으로 설치하거나 삭제했던 목록을 확인

[root@localhost yumlocal]# yum history
Loaded plugins: fastestmirror, langpacks
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     2 | root <root>              | 2021-12-07 13:30 | Update         |    2  <
     1 | System <unset>           | 2021-12-02 08:52 | Install        | 1487 > 
history list

4. # yum history undo 2

뒤에 있는 숫자는 ID값

yum 목록에 있는 순서 실행취소 (삭제, 재설치)

[root@localhost yumlocal]# yum history undo 2
Loaded plugins: fastestmirror, langpacks
Undoing transaction 2, from Tue Dec  7 13:30:40 2021
    Updated python-2.7.5-89.el7.x86_64      @anaconda
    Update         2.7.5-90.el7.x86_64      @/python-2.7.5-90.el7.x86_64
    Updated python-libs-2.7.5-89.el7.x86_64 @anaconda
    Update              2.7.5-90.el7.x86_64 @/python-libs-2.7.5-90.el7.x86_64
Loading mirror speeds from cached hostfile
 * base: mirror.kakao.com
 * extras: mirror.kakao.com
 * updates: mirror.navercorp.com
Resolving Dependencies
--> Running transaction check
---> Package python.x86_64 0:2.7.5-89.el7 will be a downgrade
---> Package python.x86_64 0:2.7.5-90.el7 will be erased
---> Package python-libs.x86_64 0:2.7.5-89.el7 will be a downgrade
---> Package python-libs.x86_64 0:2.7.5-90.el7 will be erased
base/7/x86_64/filelists_db                                                         | 7.2 MB  00:00:00     
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================
 Package                    Arch                  Version                       Repository           Size
==========================================================================================================
Downgrading:
 python                     x86_64                2.7.5-89.el7                  base                 96 k
 python-libs                x86_64                2.7.5-89.el7                  base                5.6 M

Transaction Summary
==========================================================================================================
Downgrade  2 Packages

Total download size: 5.7 M
Is this ok [y/d/N]: y
Downloading packages:
warning: /var/cache/yum/x86_64/7/base/packages/python-2.7.5-89.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for python-2.7.5-89.el7.x86_64.rpm is not installed
(1/2): python-2.7.5-89.el7.x86_64.rpm                                              |  96 kB  00:00:00     
(2/2): python-libs-2.7.5-89.el7.x86_64.rpm                                         | 5.6 MB  00:00:00     
----------------------------------------------------------------------------------------------------------
Total                                                                     9.2 MB/s | 5.7 MB  00:00:00     
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
 Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>"
 Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
 Package    : centos-release-7-9.2009.0.el7.centos.x86_64 (@anaconda)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Is this ok [y/N]: y
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : python-libs-2.7.5-89.el7.x86_64                                                        1/4 
  Installing : python-2.7.5-89.el7.x86_64                                                             2/4 
  Cleanup    : python-2.7.5-90.el7.x86_64                                                             3/4 
  Cleanup    : python-libs-2.7.5-90.el7.x86_64                                                        4/4 
  Verifying  : python-2.7.5-89.el7.x86_64                                                             1/4 
  Verifying  : python-libs-2.7.5-89.el7.x86_64                                                        2/4 
  Verifying  : python-2.7.5-90.el7.x86_64                                                             3/4 
  Verifying  : python-libs-2.7.5-90.el7.x86_64                                                        4/4 

Removed:
  python.x86_64 0:2.7.5-90.el7                      python-libs.x86_64 0:2.7.5-90.el7                     

Installed:
  python.x86_64 0:2.7.5-89.el7                      python-libs.x86_64 0:2.7.5-89.el7                     

Complete!

기존 rpm 명령어보다 패키지 관리가 쉽다.

쿠버네티스 설치 kubernetes install

Itlee — Thu, 3 Jun 2021 16:17:08 +0900

vm 구성

hostname	ip	os version
master	192.168.79.140	centos 7.9. 2009
node1	192.168.79.141	centos 7.9. 2009
node2	192.168.79.142	centos 7.9. 2009

Master node, Work node 최소 사양

Master node 최소 사양 : CPU: 2 Core, RAM: 2G

Worker node 최소 사양 : CPU: 1 Core, RAM: 1G

출처: https://ikcoo.tistory.com/9 [이쿠의 슬기로운 개발생활]

1. 각 노드 별 패키지 업데이트

 yum -y update

2. 도커 설치 및 실행

2.1 필요 패키지들을 설치해준다.

 yum install -y yum-utils  device-mapper-persistent-data  lvm2

2.2 방화벽 disable

 systemctl stop firewalld && systemctl disable firewalld

2.3 repository 등록

 yum-config-manager --add-repo  https://download.docker.com/linux/centos/docker-ce.repo

2.4 도커 설치

 yum install -y docker-ce docker-ce-cli containerd.io

2.5 서비스 실행

 systemctl enable docker && systemctl start docker

2.6 서비스 실행 확인

ps -ef | grep docker
root      74290      1  0 14:36 ?        00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
root      74430  17689  0 14:49 pts/0    00:00:00 grep --color=auto docker

2.7 컨테이너 런타임 설정

cat << END  > /etc/docker/daemon.json
{
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": {
   "max-size": "100m"
 },
 "storage-driver": "overlay2"
}
END

3. 쿠버네티스 설치

3.1 swap disabled 스왑은 반드시 off로 해야한다.

swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab

3.2 Letting iptables see bridged traffic

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sudo sysctl --system

3.3 kubeadm. kubectl installation

cat <<EOF |  tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg 
exclude=kubelet kubeadm kubectl
EOF
yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
systemctl enable kubelet && systemctl start kubelet

3.4 selinux 종료

setenforce 0

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

3.5 kubeadm init (master에서 적용)

kubeadm init

아래부분 빨간 명령어부터 sha256값 까지 복사해두자

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.79.140:6443 --token 1qcrc2.uyvrm8gzrtfth3nv \
        --discovery-token-ca-cert-hash sha256:626ed4ec6ec3b829c992c7eb9b9106f6f20ba61d02fb8b410cb28d2f8e1ec1e2

3.6 master node에서 kubectl 명령을 쓸 수 있도록 허용 ( master에서 적용)

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

3.7 CNI - Weave 적용 (master에서 적용)

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

3.8 master 확인

 kubectl get nodes

NAME     STATUS   ROLES                  AGE     VERSION
master   Ready    control-plane,master   9m42s   v1.21.1

3.9 나머지 node 적용

아까 복사해두었던 해쉬값을 노드에 적용

kubeadm join 192.168.79.140:6443 --token 1qcrc2.uyvrm8gzrtfth3nv \
        --discovery-token-ca-cert-hash sha256:626ed4ec6ec3b829c992c7eb9b9106f6f20ba61d02fb8b410cb28d2f8e1ec1e2

3.10 확인 master에서 실행

kubectl get nodes

* 쿠버네티스 자동완성 적용

*.1 bash_complete 설치

yum -y install bash_completion

*.2 bash쉘에 영구적으로 추가

source <(kubectl completion bash) 
echo "source <(kubectl completion bash)" >> ~/.bashrc

*.3 kubectl을 k로 alias 적용

alias k=kubectl
complete -F __start_kubectl k

참조 url : https://kubernetes.io/ko/docs/reference/kubectl/cheatsheet/

nmon 설정

Itlee — Mon, 12 Apr 2021 11:35:37 +0900

nmon.dat

0.15MB

nmon이란

nmon은 AIX 및 Linux 운영 체제 용 컴퓨터 성능 시스템 모니터 도구입니다.

nmon을 이용해 5분마다 시스템의 cpu, memory, disk, network의 사용량을 기록하는 방법

/usr/bin/nmon로 복사

cp ./nmon.dat /usr/bin/nmon

chmod 755 /usr/bin/nmon

mkdir -p /root/nmon/nmonout

nmon shell 만들기

vi /root/nmon/nmon.sh

#!/bin/ksh

cd /root/nmon/nmonout

/usr/bin/nmon -f -d -t -s 300 -c 288 # 5분마다 확인 1일단위로 저장

crontab 등록

crontab -e

1 0 * * * /root/nmon/nmon.sh > /dev/null 2>/dev/null

hp dl380gen10 os installation rapid setup

Itlee — Mon, 4 Jan 2021 11:33:19 +0900

hp dl380gen10 os installation rapid setup

HP 서버에서 windows 설치

1. 부팅 하면서 f10번을 눌러 Intelligent Provisioning 화면

해당 화면에서 Rapid Setup 선택

2. 물리 Disk Raid구성 화면 [자동구성이면 10번으로 넘어가시면 됩니다.]

자동으로 os영역과 data영역으로 구성되지만 자동 구성이 맘에안든다면 manually configure 선택

3. Configure Devices에서 Logical Drive 선택 화면

CREATE ARRAY 선택을 해준다.

4. raid 구성할 disk 선택화면

해당 화면에서는 os영역 RAID1 구성을 위해 SSD 240GB 두장을 선택했다.

5. Raid 모드 선택 후 next

6. Raid가 잡힌 disk 상태 확인 및 나머지 디스크도 raid 설정

CREATE ARRAY 클릭

7. 나머지 disk 2장 선택

8. 마찬가지로 raid 1을 선택 후 next

(서버에서는 raid0 stripe모드는 거의 사용하지 않는다.)

9. 운영체제가 설치 될 lv 선택

해당 화면에서는 240GB쪽에 os를 설치할것이기에 lv1 선택

10. os type 선택화면

windows를 설치할것이기에 install Microsoft Windows Server 선택

11. 설치 이미지 선택화면

usb로 이미지를 구워놔서 Automatic scan local drives 선택

12. 자동 리부팅 후 설치 진행이 된다.

13. windows 설치 화면이 나온다. 언어 및 시간 키보드레이아웃 선택 후 next

14. 라이센스 정책 동의 후 next

15 os 설치 진행

os 설치가 끝나면 자동으로 windows가 부팅이 된다.

gpfs 파일시스템 증설

Itlee — Mon, 28 Dec 2020 10:36:33 +0900

기존에 gpfs 구성이 되어있다.

gpfs 영역 /app 2000GB 증설

1. 스토리지에서 lun 할당
xxx_share_vol_26 ~45

2. 서버 현재 pv확인
[root@xxx01:/]lspv
hdisk0          00ce2f578532e28b                    rootvg          active
hdisk1          00ce2f57d8bfebb2                    swvg            active
hdisk2          00ce2f57d8bfebdb                    swvg            active
hdisk3          00ce2f57abe8c760                    tbnsd1
hdisk4          00ce2f57abe8c78a                    tbnsd2
hdisk5          00ce2f57abe8c7b4                    tbnsd3
hdisk6          00ce2f57abe8c7de                    app_nsd01
hdisk7          00ce2f57abe8c808                    app_nsd02
hdisk8          00ce2f57abe8c832                    app_nsd03
hdisk9          00ce2f57abe8c85c                    app_nsd04
hdisk10         00ce2f57abe8c887                    app_nsd05
hdisk11         00ce2f57abe8c8b1                    app_nsd06
hdisk12         00ce2f570608599a                    app_nsd07
hdisk13         00ce2f5706086419                    app_nsd08
hdisk14         00ce2f5706086d93                    app_nsd09
hdisk15         00ce2f570608799a                    app_nsd10
hdisk16         00ce2f5748137973                    app_nsd11
hdisk17         00ce2f57481379b3                    app_nsd12
hdisk18         00ce2f57481379ec                    app_nsd13
hdisk19         00ce2f5748137a2f                    app_nsd14
hdisk20         00ce2f5748137a70                    app_nsd15
hdisk21         00ce2f5748137aab                    app_nsd16
hdisk22         00ce2f5748137ae2                    app_nsd17
hdisk23         00ce2f5748137b22                    app_nsd18
hdisk24         00ce2f5748137b61                    app_nsd19
hdisk25         00ce2f5748137b9a                    app_nsd20

3. fc path 하드웨어 재인식

cfgmgr -vl fcs1; cfgmgr -vl fcs3

4. 각 노드별로 추가된 disk pv =yes

chdev -l hdisk26 -a pv=yes
chdev -l hdisk27 -a pv=yes
chdev -l hdisk28 -a pv=yes
chdev -l hdisk29 -a pv=yes
chdev -l hdisk30 -a pv=yes
chdev -l hdisk31 -a pv=yes
chdev -l hdisk32 -a pv=yes
chdev -l hdisk33 -a pv=yes
chdev -l hdisk34 -a pv=yes
chdev -l hdisk35 -a pv=yes
chdev -l hdisk36 -a pv=yes
chdev -l hdisk37 -a pv=yes
chdev -l hdisk38 -a pv=yes
chdev -l hdisk39 -a pv=yes
chdev -l hdisk40 -a pv=yes
chdev -l hdisk41 -a pv=yes
chdev -l hdisk42 -a pv=yes
chdev -l hdisk43 -a pv=yes
chdev -l hdisk44 -a pv=yes
chdev -l hdisk45 -a pv=yes

5. cd /var/mmfs/etc
vi app_2000G_app.txt

/dev/hdisk26:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd21
/dev/hdisk27:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd22
/dev/hdisk28:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd23
/dev/hdisk29:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd24
/dev/hdisk30:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd25
/dev/hdisk31:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd26
/dev/hdisk32:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd27
/dev/hdisk33:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd28
/dev/hdisk34:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd29
/dev/hdisk35:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd30
/dev/hdisk36:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd31
/dev/hdisk37:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd32
/dev/hdisk38:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd33
/dev/hdisk39:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd34
/dev/hdisk40:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd35
/dev/hdisk41:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd36
/dev/hdisk42:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd37
/dev/hdisk43:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd38
/dev/hdisk44:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd39
/dev/hdisk45:xxx01-gpfs,xxx02-gpfs::dataAndMetadata::app_nsd40

6. mmcrnsd -F ./app_2000G_app.txt

7. mmadddisk /dev/app -F ./app_2000G_app.txt

GPFS: 6027-531 The following disks of app will be formatted on node xxx02:
    app_nsd21: size 104857600 KB
    app_nsd22: size 104857600 KB
    app_nsd23: size 104857600 KB
    app_nsd24: size 104857600 KB
    app_nsd25: size 104857600 KB
    app_nsd26: size 104857600 KB
    app_nsd27: size 104857600 KB
    app_nsd28: size 104857600 KB
    app_nsd29: size 104857600 KB
    app_nsd30: size 104857600 KB
    app_nsd31: size 104857600 KB
    app_nsd32: size 104857600 KB
    app_nsd33: size 104857600 KB
    app_nsd34: size 104857600 KB
    app_nsd35: size 104857600 KB
    app_nsd36: size 104857600 KB
    app_nsd37: size 104857600 KB
    app_nsd38: size 104857600 KB
    app_nsd39: size 104857600 KB
    app_nsd40: size 104857600 KB
Extending Allocation Map
Checking Allocation Map for storage pool system
GPFS: 6027-1503 Completed adding disks to file system app.
mmadddisk: 6027-1371 Propagating the cluster configuration data to all
  affected nodes.  This is an asynchronous process.

[root@xxx01:/var/mmfs/etc]mmdf /dev/app
disk                disk size  failure holds    holds              free KB             free KB
name                    in KB    group metadata data        in full blocks        in fragments
--------------- ------------- -------- -------- ----- -------------------- -------------------
Disks in storage pool: system (Maximum disk size allowed is 1.2 TB)
app_nsd01           104857600       -1 yes      yes         8365056 (  8%)      26813984 (26%)
app_nsd02           104857600       -1 yes      yes         8465920 (  8%)      26065520 (25%)
app_nsd03           104857600       -1 yes      yes         8088064 (  8%)      26130688 (25%)
app_nsd04           104857600       -1 yes      yes         8176640 (  8%)      26392320 (25%)
app_nsd05           104857600       -1 yes      yes         8171008 (  8%)      27328720 (26%)
app_nsd06           104857600       -1 yes      yes         8230400 (  8%)      26214656 (25%)
app_nsd07           104857600       -1 yes      yes          696832 (  1%)      39799472 (38%)
app_nsd08           104857600       -1 yes      yes          759808 (  1%)      37066608 (35%)
app_nsd09           104857600       -1 yes      yes          712192 (  1%)      37374512 (36%)
app_nsd10           104857600       -1 yes      yes          703488 (  1%)      40563808 (39%)
app_nsd11           104857600       -1 yes      yes        43102720 ( 41%)       3749840 ( 4%)
app_nsd12           104857600       -1 yes      yes        43127296 ( 41%)       3768288 ( 4%)
app_nsd13           104857600       -1 yes      yes        43124736 ( 41%)       3750608 ( 4%)
app_nsd14           104857600       -1 yes      yes        43133952 ( 41%)       3762480 ( 4%)
app_nsd15           104857600       -1 yes      yes        43147776 ( 41%)       3746224 ( 4%)
app_nsd16           104857600       -1 yes      yes        43160576 ( 41%)       3764496 ( 4%)
app_nsd17           104857600       -1 yes      yes        43165696 ( 41%)       3755456 ( 4%)
app_nsd18           104857600       -1 yes      yes        43170816 ( 41%)       3777248 ( 4%)
app_nsd19           104857600       -1 yes      yes        43291136 ( 41%)       3758384 ( 4%)
app_nsd20           104857600       -1 yes      yes        43585536 ( 42%)       3745024 ( 4%)
app_nsd21           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd22           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd23           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd24           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd25           104857600       -1 yes      yes       104854528 (100%)           496 ( 0%)
app_nsd26           104857600       -1 yes      yes       104854528 (100%)           496 ( 0%)
app_nsd27           104857600       -1 yes      yes       104854528 (100%)           496 ( 0%)
app_nsd28           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd29           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd30           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd31           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd32           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd33           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd34           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd35           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd36           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd37           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd38           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd39           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
app_nsd40           104857600       -1 yes      yes       104855040 (100%)           496 ( 0%)
                -------------                         -------------------- -------------------
(pool total)       4194304000                            2581478912 ( 62%)     351338256 ( 8%)

                =============                         ==================== ===================
(total)            4194304000                            2581478912 ( 62%)     351338256 ( 8%)

Inode Information
-----------------
Number of used inodes:        60087378
Number of free inodes:         3463086
Number of allocated inodes:   63550464
Maximum number of inodes:     63550464
[root@xxx01:/var/mmfs/etc]df -gt
Filesystem    GB blocks      Used      Free %Used Mounted on
/dev/hd4          20.00      0.72     19.28    4% /
/dev/hd2          30.00      4.66     25.34   16% /usr
/dev/hd9var       20.00      0.47     19.53    3% /var
/dev/hd3          10.00      1.75      8.25   18% /tmp
/dev/hd1          20.00      0.01     19.99    1% /home
/dev/hd11admin      0.50      0.00      0.50    1% /admin
/proc                 -         -         -    - /proc
/dev/hd10opt       5.00      0.59      4.41   12% /opt
/dev/livedump      0.50      0.00      0.50    1% /var/adm/ras/livedump
/dev/ibmlv        20.00      3.83     16.17   20% /ibm
/dev/swlv         55.00     37.50     17.50   69% /sw
/dev/swloglv     100.00     63.91     36.09   64% /log
/dev/veritaslv      5.00      2.59      2.41   52% /veritas
/dev/app        4000.00   1538.11   2461.89   39% /app

hyper V 에서 teaming 구성

Itlee — Thu, 10 Dec 2020 10:10:03 +0900

Hyper V 에서 teaming 구성

1. 가상화 구성된 서버에서 teaming 구성할 포트에 utp포트를 꽂는다.

2. Hyper-V 관리자 -> 가상 스위치 관리자

3. 새 가상 네트워크 스위치탭에서 외부 선택 후 가상스위치 만들기

4. 해당 포트 이름지정, 연결 형식에서 연결된 포트 선택

5. 다시 한번 더 실행해서 다른 포트도 동일하게 작업한다.

6. 가상화 구성 되어 있는 서버 오른쪽마우스 -> 설정

7. 하드웨어 추가 -> 네트워크 어댑터 -> 추가

8. 추가 된 네트워크 어댑터에서 + 확장버튼 클릭 -> 고급 기능 -> NIC팀 항목에서 게스트 운영 체제에서 이 네트워크 어댑터가 팀의 일부가 되도록 설정 선택

9. 가상화된 서버 실행 -> 서버관리자 -> 로컬서버 -> NIC 팀 클릭

10. 새 팀추가 -> 새로 생성된 어댑터 선택 후 구성

11. team device에 ip 부여

* 처음 구성할때 물리 서버에서 team device를 구성하고 가상화서버에서 team device를 매핑하는 방법을 생각했었는데

hyper-v관리자에서 team device는 인식을 못했다.

검색해서 찾아보니 물리적 포트를 가상화 서버들에게 할당 후 가상화 서버내에서 teaming을 해줘야 한다.

해당 페이지를 참고하여 구성하였다.

참고 url : docs.microsoft.com/ko-kr/windows-server/networking/technologies/nic-teaming/create-a-new-nic-team-on-a-host-computer-or-vm

물리 os를 hyper-V에 활성화하기

Itlee — Tue, 8 Dec 2020 14:13:48 +0900

P2V란 컴퓨팅에서. 물리적-가상은 물리적 서버의 운영 체제, 응용 프로그램 및 데이터를 물리적 서버에서 가상화 된 플랫폼에 호스팅 된 가상 시스템 게스트로 분리 및 마이그레이션하는 프로세스를 포함합니다.

물리 OS를 가상화 환경인 hyper-V에 활성화 하는 방법

Microsoft의 개발자가 개발한 Disk2vhd 를 실행 통해 vhd로 변환하는 방법이 있다.

1. disk2vhd를 다운로드 받는다.

다운로드 링크 : docs.microsoft.com/en-us/sysinternals/downloads/disk2vhd

2. disk2vhd 실행

vhd파일이 저장될 위치를 선택 후 (단, os이미지를 추출할 드라이브와 같은 드라이브경로에는 저장을 못한다.)

os가 설치된 드라이브를 선택 후 Create를 한다

3. 가상머신 생성

1) Hyper-V 관리자 -> 동작 -> 새로만들기 -> 가상컴퓨터

가상 하드디스크 연결항목에서 방금 전에 생성한 vhd 또는 vhdx를 선택한다.

요약 확인 후 마침

4. 생성한 vm을 실행해 준다.

해수수조

Itlee — Fri, 27 Nov 2020 16:21:00 +0900

마린코스트 fs900으로 3자 하단섬프 구성

스키머 : 버블메거스 a8

수류모터 : 맥스팩트 gp02 * 1ea , 제바오 sw4 * 1ea

리턴모터 : dcp10000

조명은 : k7 두발 사용중, 향후 오펙바90 추가예정

운영한지는 1년정도

물성치 : 염도 1.024

경도 7~8

수온 : 25.5~26.5도 유지

수조 사진

연산호 LPS 위주 짬뽕항

연산호 : 레더, 스타폴립, 펌핑제니아, 버튼

LPS : 토치, 엘레강스, 던칸, 헤머, 머쉬룸

생물 : 마룬크라운, 옐로탱, 블루탱, 락블레니, 이리디스레쓰