Las 낙서장

Linux Software Raid 설정

- 사전 작업

raid를 구성할 2개의 파티션을 생성후 fdisk에서 type을 fd로 설정

1. raid devices 생성

# mknod /dev/md0 b 9 0

b : block devices

9 : md 장치의 주 번호가 9번

0 : 0번 째 장치

Ex) 만약 2번째 장치이면

# mknod /dev/md1 b 9 1

2. raid 구성

# mdadm -C /dev/md0 --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdc1

이후 continue에서 y

- C : create

--level : raid 레벨

--raid-devices : raid를 구성할 devices 숫자

3. raid 확인

# mdadm --detail /dev/md0

4. Mount or format

# mkfs -t xfs -f /dev/md0

# mount /dev/md0 /test

- 정상적인 상태일 경우 lvs

- 정상적인 상태일 경우 pvs

- lv cache가 정상적으로 구동하지 않는 경우

- pv확인 시 disk 장애가 발생한 경우

- 해결 방법

1. 새로운 disk 삽입

2. fdisk를 통한 파티션 생성

# fdisk /dev/sda

3. pvdisplay로 장애난 disk의 pv uuid 확인

4. 메타데이터와 pv uuid를 통해 복구

# pvcreate --uuid "a2Lfiu-JoO2-3cte-dvAO-r12j-lvrn-bbi2z5" --restorefile /etc/lvm/archive/vg_hybrid_00015-1742953829.vg /dev/sda1

--restorefile의 경우 /etc/lvm/archive/ 아래있는 파일중 lvm 정상적으로 구성된 가장 마지막 버전을 찾아야 한다. 장애가 발생한 상태도 저장되기에 uuid와 status를 잘 확인해야한다.

IPMI Log로 HW 장애 확인

상황

- fan이 장애발생하였다가 정상복구되였다가 다시 장애가 발생하는 상황이 반복

- Vendor Tool (hpasm)등이 없어 ipmitool로만 확인을 해야하는 경우 유용

1. ipmitool log 확인

# ipmitool sel list last 10

-> ipmi 마지막 10개 이벤트 로그 확인

→ Fan #0x08번이 Degraded 되었다가 Running 되는 증상 확인

2. Fan Type 확인

# ipmitool sdr type fan

-> # ipmitool sdr type 명령으로 각 device별 정보 확인 가능

-> # ipmitool sdr type [type 명] 또는 # ipmitool sdr type [device 명]으로 확인가능

-> Log에서 Fan #0x08에 대한 로그 확인 후 type fan에서 08이 몇 번 fan인지 확인 후 장애 복구

3. 예제

# ipmitool sdr type "Power Supply"

-> power supply 등 다른 device도 확인 가능

• MacVLan은 브릿지가 없다. 대신 서브 인터페이스라는 개념이 등장하여 사용
• 호스트 머신에 물리적인 NIC인 eth0은 당연히 존재하며 eth0에서 여러 개의 하위 인터페이스를 만듬으로써 동시에 여러개의 mac 주소를 가질 수 있도록 구축한다. 그렇게 되면 생성된 하위 인터페이스들에 여러개의 컨테이너들이 연결되면서 VLAN을 구성할 수 있다.
• 하나의 네트워크 인터페이스 카드를 가상화함으로써 여러 개의 MAC주소를 생성하는 것

• macvlan은 부모 인터페이스(parent)와 서브 인터페이스(slave)로 나눈다. 
• 부모 인터페이스는 가상화될 주체, 즉 실제 물리적인 NIC인 eth0이 되고 거기서 생성된 서브 인터페이스들은 mac0, mac1, mac2가 된다.
• macvlan으로 생성된 인터페이스를 지칭할 때는 mac0@eth0과 같이 표현 (mac0은 서브 인터페이스, eth0이 부모 인터페이스)

• 호스트(eth0)와는 통신이 안되지만 다른 서브 인터페이스간 통신은 되는 방식
• 호스트와 통신이 안되는 것은 원래 macvlan에서 안되는 것이고 다른 서브 인터페이스간의 통신이 되는 것은 다른 방식(bridge 등)들과 차이를 가진다
• macvlan 방식은 부모 인터페이스에 간단한 브릿지를 둬서 다른 서브 인터페이스로 향하는 트래픽을 밖으로 내보내지 않고 바로 전달하는 방식 (내부 컨테이너끼리 통신을 하는 경우)
• 모든 서브 인터페이스의 맥 주소를 알고 있는 상태이므로 브릿지에서 Mac Learning(맥 추가) 작업도 필요없고 루핑을 방지하기 위한 STP알고리즘도 필요 없다고 함

• docker0 브릿지는 존재하지만 사용되지 않는다.
• 각 컨테이너들의 네트워크 인터페이스는 서브 인터페이스가 되고 호스트의 인터페이스가 부모 인터페이스가 된다.
• 아래의 그림은 위쪽의 설명한 그림과 조금 다른데 이런 경우는 호스트 인터페이스를 직접 부모 인터페이스로 삼은 경우

1. 높은 대역폭
2. 낮은 CPU 점유율

1. 부모 인터페이스가 죽으면 서브 인터페이스도 모두 죽음
2. 호스트와 통신 불가능
3. 복잡한 네트워크 구성 불가능

• 번외로 기본 도커 브릿지인 docker0과 macvlan의 속도 테스트 결과 docker0은 초당 22GB, macvlan은 초당 27GB가 나왔다고는 한다. 각 테스트 환경마다 다르니 참고
•