아래의 내용은  HP C7000 BL460c 장비에서 vmcore를 생성하기 위한 구성 조건입니다

vmcore를 생성하기 위한 조건으로 장비별로 특성을 가지는 경우도 생기는듯 합니다. 드라이버를

업데이트 한다든지 Firmware를 올린다든지.. 이부분에 있어서는 하드웨어 벤더사의 의견도

중요합니다.

RHEL 6.4 X86_64

HP C7000 BL460c

이슈사항

OS 설치 후 기존의 kdump 설정대로 진행하였을 경우 테스트 결과 kdump가 실행되지 않고 hang 상태를 유지하고 있었습니다.

1. kdump 테스트시 error message 발생

해결방법

1. HPSA 드라이버 최신 업데이트

           HPSA version:        3.4.4-125

2. HP에서 권장하는 kernel 파라미터 설정 (reboot 해야 적용)

/etc/sysctl.conf

           kernel.sysrq = 1

           kernel.panic = 10

           kernel.panic_on_oops = 1

           kernel.unknown_nmi_panic = 1

           kernel.panic_on_unrecovered_nmi = 1

           kernel.panic_on_io_nmi = 1

/etc/grub.conf (intel_iommu=on을 intel_iommu=off로 변경 nmi_watchdog=1 추가)

title Red Hat Enterprise Linux (2.6.32-358.el6.x86_64)

           root (hd0,0)

           kernel /tboot.gz logging=vga,serial,memory

           module /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg00-LogVol01 intel_iommu=off rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg00/LogVol00 rd_NO_MD rd_LVM_LV=vg00/LogVol01 SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM nmi_watchdog=1 rhgb quiet

           module /initramfs-2.6.32-358.el6.x86_64.img

3. kdump.conf 설정

           path /var/crash

           core_collector makedumpfile -c --message-level 1 -d 31

4. kdump 버전

           kexec-tools-2.0.0-258.el6.x86_64

5. 참고사항

ilo를 사용하는 환경에서 "# echo c > /proc/sysrq-triger" 로 kdump 생성 테스트하면 생성되지 않는 문제가 있다고 합니다.

서버에 monitor 를 직접 연결하시고 kdump 생성 테스트 해야합니다.

6. BSSAPDB, BSSAPAP kdump 생성 안되는 이유

           - /var/crash 영역이 multipath device(mpatha)로 인식이 되어있었고, kdump initrd(ramdisk) 에서는 multipath module을

             인식을 하지 못하여 /var/crash 영역을 mount 하지 못해 dump 파일이 생성이 되지 않았습니다.

           - 이 부분을 해결 하기 위해서 아래와 같은 절차로 진행을 하였습니다.

6.1 /etc/multipath.conf 파일 수정

           - /etc/multipath.conf 파일을 /root 영역으로 move

           - OS 영역 디스크 wwid 로 식별하여 blacklist 등록

           - OS initramfs 재생성후 reboot

           - reboot 완료 후 /root/multiipath.conf 파일을 /etc/multipath.conf 로 원복

           - multipathd 데몬 재시작

           - 기존에 있던 kdump initrd(kdump ramdisk) 백업

           - kdump initrd(kdump ramdisk) 재생성

           - echo "c" > /proc/sysrq-trigger 명령어로 테스트

자아~ Red Hat이 CentOS 커뮤니트 프로젝트를 인수했습니다, CentOS를 개발했던 모든 Main Contributor들은
모두 레드햇에 Join되었고..지속적으로 CentOS에 대한 개발을 진행한다고 합니다..

하지만 여기서 아주 재미 있는 대목이 있네요.이전에 Red Hat이 전통적으로 Source를 배포하는 방식을 바꿨습니다. SRPM이 아닌 GIT Repository를 이용한다는 군요..

Red Hat의 의견은 Git Repository를 이용한 소스 배포 방식이  CentOS와 Oracle에게 도움이 될거라고 합니다. 또한 CentOS의 프로젝트는 GlusterFS, Ovirt, OpenStack, OpenShift등 클라우드 인프라에 요구되는 오픈소스
프로젝트와 Pair로 빠르게 움직일 텐데..

기사에 나와있는데로 개발 로드맵상Fedora는 너무 빠르고 RHEL은 새로운 Project에 Pair로 움직이기에는 
너무 긴 Roadmap을 가지고 있으니 적절하게 엔터프라이즈 환경에 필요한 프로젝트를  Pair로 움직일수 있는 프로젝트 기반이 필요했고..그걸 CentOS로 결정한 것이군요.. 

그렇다면 여기서 생각해 볼 필요가 있는 부분이 있겠죠.. 

1. GIT Repository 방법으로 소스를 배포하는 방법 

레드햇은 전통적인 Source 배포 방법의 SRPM이 아닌 Git Repository를 이용해서 배포한다고 발표했습니다. 
전통적으로 레드햇 Clone을 지향해온 CentOS와 Oracle Linux의 경우 도움이 될까요?? 

CentOS나 Oracle Linux의 경우 분명 RHEL의 Patch 기간이나 Minor Release 기간 그리고 새로운 Major 버젼의 Linux Platform에 따라서 영향을 받고 플랫폼을 내놓았는데 이렇게 된다면 분명 두 Enterprise 배포판의 개발 Roadmap에 치명적인 영향을 미치게 된다는 것을 예상할수 있습니다. 

2. 버젼 Release.. 

Red Hat은 Fedora와 RHEL의 개발 기간에 차이로 인해서 Cloud Computing 환경을 위한 오픈소스 
프로젝트를 Pair로 개발될수 있는 중간계 프로젝트로 CentOS를 선택했습니다. 여기서 주목해서 봐야할 부분은 CentOS Main Contributor에 의도입니다. 

CentOS 6.5 was released in December – what's on tap for the next release? How will the new partnership affect that?

In spite of the fact that I work for Red Hat now, I'm not privy to their release schedules. So over the next few months the board will publish our own road map. The mainline, the core, will stay as it is. But the variants will be able to set up their own road maps (based on their own release schedule).

http://en.linuxreviews.org/NTP_-_Howto_make_the_clock_show_the_correct_time

글러스터 구성하다가 아래와 같이 대용량 디스크에서 파티셔닝 하다가 나타나는 문제점에 대해서는

잘 정리되어 있는 문서입니다...

=======================================================================================

참조 : http://blog.seabow.pe.kr/?p=2132

Linux 에서 fdisk -l 을 하게되면
Partition “X” does not end on cylinder boundary. 라는 문구를 볼 수 있다.

ex)

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          26      204800   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              26         287     2097152   83  Linux

왜 위와 같은 문구를 출력 하는 것일까?

파티셔닝 작업에서는 LBA (Logical Block Addressing)기반으로 파티셔닝을 한다.
그러나 fdisk -l 상에서는 CHS (Cylinder/Head/Sector)기반으로 결과를 보여 줌으로써 위와 같은 메시지가 출력되는 것 이다.

이를 회피하는 방법?
$ sfdisk -uS -l /dev/Device

Disk /dev/sda: 9726 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot    Start       End   #sectors  Id  System
/dev/sda1   *        63    409662     409600  83  Linux
/dev/sda2        409663   4603966    4194304  83  Linux
/dev/sda3       4603967 156248189  151644223  8e  Linux LVM
/dev/sda4             0         -          0   0  Empty

참고 자료 :

Link 1 : http://prefetch.net/blog/index.php/2009/09/12/why-partition-x-does-now-end-on-cylinder-boundary-warnings-dont-matter/

Link 2 : http://www.symantec.com/business/support/index?page=content&id=TECH164072

Link 3 : http://www.novell.com/support/kb/doc.php?id=7005639

리눅스 시스템을 운영하다 보면  시스템 Hang-up에 대한  문제점을 많이 들어나게 됩니다. 물론  리눅스 시스템
자체의 문제점이라고 보다는 특정 운영 프로세스에 대해서 인터럽트 또는 스케쥴이 정상적으로 진행되지 못했을때 나타는 문제점에 대해서 간략해 소개해 보고자 합니다.

갑자기 시스템  로그에서 출력하게된 /var/log/message 의 시스템 로그.

[예상 문제점 1]
시스템 로그에서 나타난  kernel:INFO: task 의 메세지를 나타내는 의미는 현재 운영하고자 하는 startup.sh
스크립트에 대해서  120초 (2분 default) 동안 khungtaskd  쓰레드에서 D-state 상태를 감지하여  call trace
를 호출하게 되는  상황으로 예측할 수 있습니다. 

[예상 문제점2]
시스템의 성능저하 특히 레드햇의 보고서에 의하면 디스크의 heavy I/O 로 나타나는 문제점으로
예측될수 있습니다.

[예상 문제점 2]
운영되고 있는 Application에 대해서 "D-state" (Uninterruptible sleep) 모드가 120초 동안 지속되었을때
예측될수 있는 문제로  해당 프로세스가 정상적으로 스케쥴링이 일어나지 않았을 때도 나타나게 됩니다

[ D-state 원인분석을 위해서는 ? ]
위와같은 문제점에 대해서 접근할수 있는 기본적인 방법에 대해서는  정확한 문제점을  파악하기 위해서는  커널의 덤프를 이용하여 core를 분석하는 것이 가장 정확할수 있습니다. core를 분석하기 위한 방법론에 대해서는 다음
블로깅을 통하여 소개하도록 하겠습니다.

위와 같이  kernel core를  생성하기 위해 설정을 진행한 후 동일한 현생이 발생되어 core가 생성이 되면 문제가
되는 운영 프로세스의 D-state 문점에 대해서 분석이 가능합니다.

[ hung_task_timeout을 Disable 시켜라]
기본적인 Work-Arround에 대해서는  아래와 같이 hung_task_timeout 부분에 대해서 Disable 시켜주는 것을 권장하고 있습니다.

위와 같이  커널에서 Hang Time OUt 을 체크하는 부분에 대해서 Disable 시켜준 후에는  call trace 여부가 지속적으로 발생되는지  모니터링이 필요합니다. 만약  해당 프로세스에 대해서  Uninterrupt sleep이 지속적으로 발생한다면 커널 업데이트 또한 고려해야 합니다.

요즘들어  금융권에 대한  성능 튜닝 이슈가 많이 요구되는 듯 하여 정리해서 올려봅니다. 

물론 운영되는 어플리케이션에 대한 특성과 환경에 고려되어야 하겠지만 일반적으로 금융

Low-latency 환경을 요구하는 시스템의 경우에는  Shared memory 또는  세마포어 

값을 민감하게 건들어야 하는 시스템의 경우는 아래와 같이 사용하기 합니다.

[수정후]
title Red Hat Enterprise Linux Server LL (2.6.32-220.4.2.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-220.4.2.el6.x86_64 ro root=UUID=dd05c407-d62c-40b1-800e-ddff20d33062 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM nohpet intel_idle.max_cstate=0 processor.max_cstate=1 cgroup_disable=memory mce=ignore_ce transparent_hugepage=never nmi_watchdog=1 elevator=deadline idle=mwait nohz=off
        initrd /initramfs-2.6.32-220.4.2.el6.x86_64.img

[수정내용]
기존 kernel 구문에
intel_idle.max_cstate=0 processor.max_cstate=1 cgroup_disable=memory mce=ignore_ce transparent_hugepage=never nmi_watchdog=1 elevator=deadline idle=mwait nohz=off
추가

[각 항목에 대한 설명]
* intel_idle.max_cstate=0 : Processor C-Status 기능 사용한함.
* processor.max_cstate=1 : 프로세서 절전 상태로 진입하지 않게 함.
* cgroup_disable=memory : 자원의 QoS를 제공하는 cgroup기능 사용안함.
* mce=ignore_ce : HW의 corrected error scan으로 인한 latency spike 무시.
* transparent_hugepage=never : hugepage 사용하지 않음
* nmi_watchdog=1 : kdump를 사용설정
* elevator=deadline : cfq가 기본값인 I/O 스케쥴러를 deadline으로 변경
* idle=mwait : CPU idle시 대기처리를 조금만 수행하도록 함
* nohz=off : CPU의 c-status 진입방지

2. 기존 sysctl.conf의 추가 및 변경 사항

#### Kdump 사용 설정
net.ipv4.conf.lo.force_igmp_version = 2
net.ipv4.conf.eth0.force_igmp_version = 2
net.ipv4.conf.eth1.force_igmp_version = 2
net.ipv4.conf.eth4.force_igmp_version = 2
kernel.unknown_nmi_panic = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.panic_on_io_nmi = 1

#### 각 네트워크의 multicast 트래픽에 대한 filtering을 off
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth4.rp_filter = 0

#### 10G NIC tuning (SolarFlare에 문의해서 low latency에 적합한 튜닝값을 적용)
net.ipv4.neigh.default.unres_qlen = 100
net.ipv4.neigh.lo.unres_qlen = 100
net.ipv4.neigh.eth0.unres_qlen = 100
net.ipv4.neigh.eth1.unres_qlen = 100
net.ipv4.neigh.eth4.unres_qlen = 100
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_mem = 16777216 16777216 16777216 
net.ipv4.tcp_rmem = 4096 8388608 16777216 
net.ipv4.tcp_wmem = 4096 8388608 16777216 
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_default = 8388608
net.core.wmem_max = 16777216

### LAN에서의 arp 요청에 대한 응답을 하지 않게 설정하여 network latency를 줄여줌
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth1.arp_ignore = 1
net.ipv4.conf.eth4.arp_ignore = 1

### 세마포어 최적값 수정
kernel.shmmni = 4096
kernel.sem = 2000 32000 512 5029

### swap 사용비율 설정
vm.swappiness = 10

### 스케쥴러 nr 수정
kernel.sched_nr_migrate = 12

net.core.netdev_max_backlog = 20000
net.core.optmem_max = 25165824
#net.core.optmem_max = 20480

3. tuned를 사용한 Low Latency 프로파일 적용
OS를 사용되는 용도에 맞게 사전 tuning된 프로파일을 제공하는 tuned를 이용해서 
레드햇에서 권고하는 시스템 전반적인 tuning을 할 수 있으며 아래와 같이 tuned를 이용해서 적용.

# tuned-adm profile latency-performance

4. 파일시스템 Tuning
[수정내역]
/etc/fstab의 각 마운트 구문중 defaults 뒤에 noatime,nodiratime,nobarrier 옵션 추가

[각 옵션 설명]
* noatime : filesystem meta정보에 file의 access time 기록하지 않음
* nodiratime : filesystem meta정보에 Directory의 access time 기록하지 않음
* nobarrier : fsync기능을 사용하지 않도록 설정.
 
5. 서비스 실행 사용자 계정 File open 수 제한 설정
[수정내역]
/etc/limit.conf 파일에
사용자명              -       nofile          4096
# 서비스 실행 사용자의 File Open 수를 4096으로 증

리눅스 3.7 커널 릴리즈: TCP Fast Open, vxLan 지원

리눅스 운영체제에서 재부팅 없이 SCSI 디스크를 인식 시키기 위해서는 아래와 같은 절차를 통해서

진행한다. 운영하고 있는 시스템을 재부팅 하면서 까지 그럴필요는 없쥐.. 암암.. 

It is possible to add or remove a SCSI device explicitly, or to re-scan an entire SCSI bus without rebooting a running system. Please see the Online Storage Reconfiguration Guide for a complete overview of this topic on Red Hat Enterprise Linux 5.

For Red Hat Enterprise Linux 5

With fibre attached storage, it is possible to issue a LIP (loop initialization primitive) on the fabric:

echo "1" > /sys/class/fc_host/host#/issue_lip

Issuing a LIP (above) on Red Hat Enterprise Linux 5 is all that is needed to rescan fibre

attached storage. Once the LIP is issued, the bus scan may take a few seconds to complete.

Although present on previous releases, this feature is only fully supported in Red Hat Enterprise Linux 5.

For Red Hat Enterprise Linux 4 and 5

With other SCSI attached storage, a rescan can be issued:

echo "- - -" > /sys/class/scsi_host/host#/scan

Replace the # with the number of the SCSI bus to be rescanned.

In addition to re-scanning the entire bus, a specific device can be added or deleted for some

versions or Red Hat Enterprise Linux as specified below.

For Red Hat Enterprise Linux 4 or 5

To remove a single existing device explicitly

# echo 1 > /sys/block//device/delete

For Red Hat Enterprise Linux 3, 4, or 5

To add a single device explicitly:

# echo "scsi add-single-device " > /proc/scsi/scsi

To remove a device explicitly:

# echo "scsi remove-single-device " > /proc/scsi/scsi

Where are the host, bus, target, and LUN numbers for the device,as reported in /sys (2.6 kernels only) or /proc/scsi/scsi or dmesg.

These numbers are sometimes refered to as "Host", "Channel", "Id", and "Lun" in Linux tool output and documentation.

리눅스 시스템에서 FC를 이용한 스토리지 볼륨을 사용할 경우 전반적인 SCSI 정보를 Gathering

할필요가 있다. WWPN 이라든지, HBA 카드 정보라든지, SCSI 연결 정보에 대한 전체적인 

정보를  어떻게 가져오는지 다음과 같이 진행해 보자.. 

1. SYSFS를 통한 WWPN 검색 

/sys/class/scsi_host/host1/state 를  아래와 같이 검색했을 경우  각 Host 별로 FC Link  

현황에 대한 상태 정보를 확인할수 있다. 

2. SYSTOOL 를 통한 WWPN 검색 

SYSTOOL은 RedHat Enterprise Linux 계열의 운영체제에서만 사용할수 있는 Tool 이다. 

SYSTOOL을 사용하기 위해서는 아래와 같이 설치 절차를 진행한다. 

[root@/]yum -y install sysutils --> SysTool Packag에 systool 명령어가

포함되어 있다. 

Original Source : https://access.redhat.com/knowledge/solutions/9936

일반적인 Enterprise System에서는 System Hang-up을 방지하기 위한 NMI 스위치를 제공하기는하나
x86_64 시스템의 경우 NMI 신호처리를 운영체제에서 해주는 것이 일반적인다. 특히 리눅스의 경우
커널 파라메터에서 NMI 옵션을 적용함으로 인해서 System Hangup을 미연해 방지해주는 경우도 있다.

- Check Point 1 - 

레드햇이나, 수세 리눅스 처럼 엔터프라이즈 환경에 운영되어야 하는 리눅스의 경우 NMI의 옵션이
기본적으로 Enable 되어 있다. 이 사실을 모르는 상태에서 H/W에서 NMI 신호를 받았을때 시스템이
재부팅 되었을 경우 당황해 하는 경우가 있다. 아래의 Virtual File system에서 NMI 신호에 대한 옵션을 확인해 보자. 

cat /proc/sys/kernel/nmi_watchdog 

1

위의 경우 처럼 /proc/sys/kernel/nmi_watchdog을 쿼리했을때 옵션 값이 1 로 나올경우 커널옵션과 
상관없이 NMI 리눅스 상에서 동작하게 된다.  

- Check Point 2 - 

# grep NMI /proc/interrupts 
NMI:    0    0    0    0

title Red Hat Enterprise Linux Server (2.6.18-128.el5) 
        root (hd0,0) 
        kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/sda nmi_watchdog=1 
        initrd /initrd-2.6.18-128.el5.img 

# grep NMI /proc/interrupts 
NMI:    2123797    2123681    2123608    2123535 
# grep NMI /proc/interrupts 
NMI:    2124855    2124739    2124666    2124593 
# grep NMI /proc/interrupts 
NMI:    2125981    2125865    2125792    2125719 
# grep NMI /proc/interrupts 
NMI:    2126692    2126576    2126503    2126430 
# grep NMI /proc/interrupts 
NMI:    2127406    2127290    2127217    2127144 

grep NMI /proc/interrupts

NMI:       187       107        293       199
grep NMI /proc/interrupts
NMI:       187       107        293       199
grep NMI /proc/interrupts
NMI:       187       107        293       200