최근에 저는 많은 파일 처리를 수행하는 웹앱용 4노드 클러스터를 설계하고 구성했습니다. 클러스터는 웹 서버와 스토리지라는 두 가지 주요 역할로 분류되었습니다. 각 역할은 활성/수동 모드에서 drbd를 사용하여 두 번째 서버에 복제됩니다. 웹 서버는 스토리지 서버의 데이터 디렉터리에 대한 NFS 마운트를 수행하고 후자에는 브라우저 클라이언트에 파일을 제공하기 위해 실행되는 웹 서버도 있습니다.
스토리지 서버에서 drbd에 연결된 데이터를 보관하기 위해 GFS2 FS를 생성했습니다. 제가 GFS2를 선택한 주된 이유는 발표된 성능과 볼륨 크기가 꽤 높아야 하기 때문입니다.
우리가 생산에 들어간 이후로 나는 깊이 연관되어 있다고 생각되는 두 가지 문제에 직면해 왔습니다. 우선, 웹 서버의 NFS 마운트가 1분 정도 계속 중단된 후 정상적인 작업을 재개합니다. 로그를 분석하여 NFS가 잠시 동안 응답을 중지하고 다음 로그 줄을 출력한다는 것을 알았습니다.
Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
이 경우 정지 시간은 16초 동안 지속되었지만 정상 작동을 재개하는 데 1~2분 정도 걸리는 경우도 있습니다.
내 첫 번째 추측은 NFS 마운트의 과도한 로드로 인해 이런 일이 발생했으며 RPCNFSDCOUNT더 높은 값으로 증가하면 안정화될 것이라는 것이었습니다. 나는 그것을 여러 번 늘렸고 잠시 후 로그가 덜 나타나기 시작했습니다. 이제 값이 on 입니다 32.
문제를 더 자세히 조사한 결과 로그에 NFS 메시지가 계속 표시됨에도 불구하고 다른 문제가 발생했습니다. 때로는 GFS2 FS가 중단되어 NFS와 스토리지 웹 서버가 모두 파일을 제공하게 되는 경우도 있습니다. 둘 다 잠시 동안 정지된 후 정상 작동을 재개합니다. 이로 인해 클라이언트 측에 흔적이 남지 않고( NFS ... not responding메시지도 남지 않음) 스토리지 측에서는 가 rsyslogd실행 중임에도 불구하고 로그 시스템이 비어 있는 것처럼 보입니다.
노드는 10Gbps 비전용 연결을 통해 스스로 연결하지만 GFS2 행이 확인되었지만 활성 스토리지 서버에 직접 연결되기 때문에 이는 문제가 되지 않는다고 생각합니다.
저는 한동안 이 문제를 해결하려고 노력해 왔으며 다른 NFS 구성 옵션을 시도했지만 GFS2 FS도 중단된다는 사실을 발견했습니다.
NFS 마운트는 다음과 같이 내보내집니다.
/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)
NFS 클라이언트는 다음을 사용하여 마운트됩니다.
mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data
몇 가지 테스트를 거친 후 이는 클러스터에 더 많은 성능을 제공하는 구성이었습니다.
클러스터가 이미 프로덕션 모드에 있고 앞으로 이 중단이 발생하지 않도록 이 문제를 수정해야 하며 무엇을 어떻게 벤치마킹해야 하는지 잘 모르기 때문에 이에 대한 해결책을 필사적으로 찾고 있습니다. . 제가 알 수 있는 것은 이전에 클러스터를 테스트했는데 이 문제가 전혀 발생하지 않았기 때문에 과도한 로드로 인해 이런 일이 발생하고 있다는 것입니다.
클러스터의 구성 세부 정보를 제공해야 하는지, 어떤 내용을 게시하길 원하는지 알려주세요.
최후의 수단으로 파일을 다른 FS로 마이그레이션할 수 있지만 현재 볼륨 크기가 매우 크기 때문에 이것이 이 문제를 해결할 수 있는지 여부에 대한 확실한 지침이 필요합니다.
서버는 제3자 기업에서 호스팅하고 있으며 해당 서버에 물리적으로 액세스할 수 없습니다.
친애하는.
편집 1: 서버는 물리적 서버이며 사양은 다음과 같습니다.
웹서버:
- 인텔 바이 제온 E5606 2x4 2.13GHz
- 24GB DDR3
- 인텔 SSD 320 2 x 120GB RAID 1
저장:
- 인텔 i5 3550 3.3GHz
- 16GB DDR3
- 2TB SATA 12개
처음에는 서버 사이에 VRack 설정이 있었지만 더 많은 RAM을 갖도록 스토리지 서버 중 하나를 업그레이드했는데 VRack 내부에 없었습니다. 그들은 서로 공유된 10Gbps 연결을 통해 연결합니다. 공용 액세스에 사용되는 것과 동일한 연결이라는 점에 유의하세요. 이들은 단일 IP(IP 장애 조치 사용)를 사용하여 둘 사이를 연결하고 정상적인 장애 조치를 허용합니다.
따라서 NFS는 개인 네트워크가 아닌 공용 연결을 통해 이루어집니다(업그레이드 전이었고 문제가 여전히 존재했습니다).
방화벽은 철저하게 구성되고 테스트되었지만 문제가 계속 발생하는지 확인하기 위해 잠시 비활성화했습니다. 내가 아는 바로는 호스팅 제공업체는 서버와 공용 도메인 간의 연결을 차단하거나 제한하지 않습니다(적어도 아직 도달하지 않은 특정 대역폭 소비 임계값 미만).
이것이 문제를 파악하는 데 도움이 되기를 바랍니다.
편집 2:
관련 소프트웨어 버전:
CentOS 2.6.32-279.9.1.el6.x86_64
nfs-utils-1.2.3-26.el6.x86_64
nfs-utils-lib-1.1.5-4.el6.x86_64
gfs2-utils-3.0.12.1-32.el6_3.1.x86_64
kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64
drbd84-utils-8.4.2-1.el6.elrepo.x86_64
스토리지 서버의 DRBD 구성:
#/etc/drbd.d/storage.res
resource storage {
protocol C;
on <server1 fqdn> {
device /dev/drbd0;
disk /dev/vg_storage/LV_replicated;
address <server1 ip>:7788;
meta-disk internal;
}
on <server2 fqdn> {
device /dev/drbd0;
disk /dev/vg_storage/LV_replicated;
address <server2 ip>:7788;
meta-disk internal;
}
}
스토리지 서버의 NFS 구성:
#/etc/sysconfig/nfs
RPCNFSDCOUNT=32
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005
LOCKD_UDPPORT=30001
LOCKD_TCPPORT=30001
LOCKD_UDPPORT( 및 둘 다에 동일한 포트를 사용하면 충돌이 발생할 수 있습니까 LOCKD_TCPPORT?)
GFS2 구성:
# gfs2_tool gettune <mountpoint>
incore_log_blocks = 1024
log_flush_secs = 60
quota_warn_period = 10
quota_quantum = 60
max_readahead = 262144
complain_secs = 10
statfs_slow = 0
quota_simul_sync = 64
statfs_quantum = 30
quota_scale = 1.0000 (1, 1)
new_files_jdata = 0
스토리지 네트워크 환경:
eth0 Link encap:Ethernet HWaddr <mac address>
inet addr:<ip address> Bcast:<bcast address> Mask:<ip mask>
inet6 addr: <ip address> Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2630984979622 (2.3 TiB) TX bytes:1648430431523 (1.4 TiB)
eth0:0 Link encap:Ethernet HWaddr <mac address>
inet addr:<ip failover address> Bcast:<bcast address> Mask:<ip mask>
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
IP 주소는 지정된 네트워크 구성에 따라 정적으로 할당됩니다.
DEVICE="eth0"
BOOTPROTO="static"
HWADDR=<mac address>
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=<ip address>
NETMASK=<net mask>
그리고
DEVICE="eth0:0"
BOOTPROTO="static"
HWADDR=<mac address>
IPADDR=<ip failover>
NETMASK=<net mask>
ONBOOT="yes"
BROADCAST=<bcast address>
fsid=25두 스토리지 서버 모두에 설정된 NFS 옵션과 함께 정상적인 NFS 장애 조치를 허용하는 호스트 파일 :
#/etc/hosts
<storage ip failover address> active.storage.vlan
<webserver ip failover address> active.service.vlan
보시다시피, 패킷 오류는 0으로 줄었습니다. 또한 패킷 손실 없이 오랫동안 ping을 실행했습니다. MTU 크기는 보통 1500입니다. 현재 VLan이 없으므로 서버 간 통신에 사용되는 MTU입니다.
웹서버의 네트워크 환경도 비슷합니다.
제가 언급하지 않은 한 가지는 스토리지 서버가 NFS 연결을 통해 매일 최대 200GB의 새 파일을 처리한다는 것입니다. 이는 이것이 NFS 또는 GFS2의 일종의 과도한 로드 문제라고 생각하는 핵심 포인트입니다.
추가 구성 세부정보가 필요하면 알려주시기 바랍니다.
편집 3:
오늘 일찍 스토리지 서버에서 심각한 파일 시스템 충돌이 발생했습니다. 서버가 응답하지 않아 충돌 세부 정보를 바로 얻을 수 없었습니다. 재부팅 후 파일 시스템이 매우 느리고 캐시 워밍 등으로 인해 NFS 또는 httpd를 통해 단일 파일을 제공할 수 없다는 것을 알았습니다. 그럼에도 불구하고 서버를 면밀히 모니터링해 보았는데 dmesg. 문제의 원인은 분명히 GFS인데, a를 기다리고 있다 lock가 잠시 후 굶어 죽게 됩니다.
INFO: task nfsd:3029 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
nfsd D 0000000000000000 0 3029 2 0x00000080
ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f
ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f
ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098
Call Trace:
[<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40
[<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2]
[<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180
[<ffffffff814ff2cb>] mutex_lock+0x2b/0x50
[<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2]
[<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2]
[<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2]
[<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2]
[<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90
[<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2]
[<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2]
[<ffffffff81188cf4>] vfs_create+0xb4/0xe0
[<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd]
[<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd]
[<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd]
[<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc]
[<ffffffff810602a0>] ? default_wake_function+0x0/0x20
[<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc]
[<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd]
[<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd]
[<ffffffff81091de6>] kthread+0x96/0xa0
[<ffffffff8100c14a>] child_rip+0xa/0x20
[<ffffffff81091d50>] ? kthread+0x0/0xa0
[<ffffffff8100c140>] ? child_rip+0x0/0x20
편집 4:
무닌을 설치했는데 새로운 데이터가 나오네요. 오늘 또 다른 중단이 있었고 munin은 다음을 보여줍니다. inode 테이블 크기는 중단 직전에 80k로 높았다가 갑자기 10k로 떨어졌습니다. 메모리와 마찬가지로 캐시된 데이터도 7GB에서 500MB로 갑자기 줄어듭니다. 정지 중에 로드 평균도 급등하고 drbd장치의 장치 사용량도 약 90% 값으로 급등합니다.
이전 정지와 비교하면 이 두 표시기는 동일하게 작동합니다. 이는 파일 핸들러를 해제하지 않는 애플리케이션 측의 잘못된 파일 관리 때문일 수 있습니까? 아니면 GFS2 또는 NFS에서 발생하는 메모리 관리 문제(의심스럽습니다) 때문일까요?
가능한 피드백을 보내주셔서 감사합니다.
편집 5:
Munin의 Inode 테이블 사용법:
Munin의 메모리 사용량:
답변1
몇 가지 일반적인 지침만 제공할 수 있습니다.
먼저 몇 가지 간단한 벤치마크 지표를 준비하고 실행하겠습니다. 그러면 최소한 당신이 만든 변화가 최선인지 알게 될 것입니다.
- 무닌
- 선인장
나기오스
좋은 선택이군요.
이러한 노드는 가상 서버입니까 아니면 물리적 서버입니까? 사양은 무엇입니까?
각 노드 사이에는 어떤 종류의 네트워크 연결이 있습니까?
호스팅 제공업체의 개인 네트워크를 통해 NFS가 설정되어 있습니까?
방화벽으로 패킷/포트를 제한하지 않습니다. 호스팅 제공업체가 이를 수행하고 있습니까?
답변2
두 가지 문제가 있다고 생각합니다. 우선 문제를 일으키는 병목 현상과 더 중요한 것은 GFS의 잘못된 오류 처리입니다. GFS는 실제로 작동할 때까지 전송 속도를 늦춰야 하지만 저는 이에 대해 도움을 드릴 수 없습니다.
클러스터가 NFS에서 ~200GB의 새 파일을 처리한다고 합니다. 클러스터에서 얼마나 많은 데이터를 읽고 있습니까?
프론트엔드와 백엔드에 하나의 네트워크 연결이 있으면 프론트엔드가 백엔드를 "직접" 중단할 수 있기 때문에(데이터 연결에 과부하가 걸려서) 항상 불안할 것입니다.
각 상자에 iperf를 설치하면 특정 지점에서 사용 가능한 네트워크 처리량을 테스트할 수 있습니다. 이는 네트워크 병목 현상이 있는지 확인하는 가장 빠른 방법일 수 있습니다.
네트워크는 얼마나 많이 활용되나요? 스토리지 서버의 디스크 속도는 얼마나 빠르며 어떤 RAID 설정을 사용하고 있습니까? 어떤 처리량을 얻습니까? *nix가 실행 중이고 테스트할 조용한 순간이 있다고 가정하면 hdparm을 사용할 수 있습니다.
$ hdpard -tT /dev/<device>
네트워크 사용량이 많은 경우 보조 및 전용 네트워크 연결에 GFS를 배치하는 것이 좋습니다.
12개 디스크를 어떻게 RAID(ed)했는지에 따라 성능 수준이 달라질 수 있으며 이것이 두 번째 병목 현상이 될 수 있습니다. 또한 하드웨어 RAID 또는 소프트웨어 RAID를 사용하는지 여부에 따라 달라집니다.
요청된 데이터가 총 메모리보다 더 많이 분산되어 있으면 상자에 있는 엄청난 양의 메모리가 거의 쓸모가 없을 수 있습니다. 게다가 메모리는 읽기에만 도움이 될 수 있으며 많은 읽기가 동일한 파일에 대한 경우에만 도움이 됩니다(그렇지 않으면 캐시에서 쫓겨날 수 있음).
top/htop을 실행할 때 iowait를 시청하세요. 여기서 높은 값은 CPU가 무언가(네트워크, 디스크 등)를 기다리며 손가락질을 하고 있다는 훌륭한 지표입니다.
제 생각에는 NFS가 범인이 될 가능성이 적습니다. 우리는 NFS에 대해 상당히 광범위한 경험을 갖고 있으며 조정/최적화할 수는 있지만경향꽤 안정적으로 작동합니다.
GFS 구성 요소를 안정적으로 만든 다음 NFS 관련 문제가 사라지는지 확인하고 싶습니다.
마지막으로 OCFS2는 GFS를 대체할 수 있는 옵션이 될 수 있습니다. 분산 파일 시스템에 대해 연구하는 동안 꽤 많은 연구를 했는데 왜 OCFS2를 선택했는지 기억이 나지 않습니다. 하지만 그렇게 했습니다. 아마도 이는 Oracle이 데이터베이스 백엔드에 사용하는 OCFS2와 관련이 있을 수 있으며 이는 매우 높은 안정성 요구 사항을 의미합니다.
무닌은 당신의 친구입니다. 그러나 훨씬 더 중요한 것은 top / htop입니다. vmstat는 또한 몇 가지 주요 번호를 제공할 수도 있습니다.
$ vmstat 1
시스템이 정확히 무엇을 하는 데 시간을 소비하는지 매초마다 업데이트를 받게 됩니다.
행운을 빌어요!
답변3
첫 번째 HA 프록시는 Varnish 또는 Nginx를 사용하여 웹 서버 앞에 있습니다.
그런 다음 웹 파일 시스템의 경우 NFS, GFS2 대신 내결함성이 있고 읽기 속도가 빠른 MooseFS를 사용하는 것이 좋습니다. NFS, GFS2에서 잃어버린 것은 로컬 잠금입니다. 애플리케이션에 이것이 필요합니까? 그렇지 않다면 MooseFS로 전환하고 NFS,GFS2 문제를 건너뛸 것입니다. MFS 메타데이터 서버를 HA하려면 Ucarp를 사용해야 합니다.
MFS에서는 복제 목표를 3으로 설정합니다.
# mfssetgoal 3 /폴더
//신자
답변4
munin 그래프에 따르면 시스템은 캐시를 삭제합니다. 이는 다음 중 하나를 실행하는 것과 같습니다.
echo 2 > /proc/sys/vm/drop_caches- 무료 덴트리와 아이노드
echo 3 > /proc/sys/vm/drop_caches- 무료 페이지 캐시, dentires 및 inode
문제는 왜 느린 크론 작업이 있는지에 대한 것입니다.
01:00 -> 12:00 외에는 일정한 간격을 두고 있는 것으로 보입니다.
위 명령 중 하나를 실행하면 문제가 다시 발생하는 경우 피크를 통해 약 1/2 지점을 확인하는 것도 가치가 있습니다.언제나sync그렇게 하기 전에 올바른 방향 으로 달리도록 하세요 .
strace예상되는 제거 시점과 해당 제거 시점에 drbd 프로세스 중 하나가 실패하면 (이것이 범인이라고 다시 가정), 약간의 빛을 비출 수 있습니다.