이상하게 들리겠지만 더 느리거나 캐시된 파일 시스템이 필요합니다.
저는 이러한 파일을 '로컬'(실제로는 FC SAN에 연결된) ext3 형식의 디스크에 기록하고 Splunk 서버에 메시지를 전달하는 한 쌍의 Linux VM에 데이터를 syslog하는 많은 방화벽을 보유하고 있습니다.
문제는 syslog 서버가 이러한 syslog 메시지를 초당 수백, 때로는 수천 개의 작은 ~4k 쓰기로 FC SAN에 다시 쓰고 있다는 것입니다. FC SAN은 현재 이 워크로드를 처리할 수 있지만 FW 트래픽은 최소한 1% 이상 증가할 것입니다. 앞으로 몇 달 안에 5000%(실제로)의 비율이 증가하고 이는 SAN에 고통이 될 것입니다. 문제가 발생하기 전에 근본 원인을 해결하고 싶습니다.
따라서 VM이 더 크지만 빈도가 낮은 쓰기를 실행할 수 있도록 '물리적' 디스크에서 어떤 방식으로든 이러한 쓰기를 캐시하거나 보류하는 방법을 찾는 데 도움이 필요합니다. 이러한 쓰기를 피할 수 있는 방법은 없지만 너무 많은 작은 일을 할 필요가 없습니다.
나는 noatime과 nodiratime을 설정하는 다양한 ext3 옵션을 살펴봤지만 문제가 크게 해결되지는 않았습니다. 분명히 다른 파일 시스템을 조사하고 있지만 나중에 다른 사람들도 같은 문제를 겪게 될 경우를 대비해 이 파일 시스템을 폐기할 것이라고 생각했습니다.
아, 그리고 이 메시지를 Splunk에 전달할 수는 없습니다. 우리 방화벽 팀은 진단 목적으로 메시지가 원본 형식이라고 주장합니다.
답변1
아마도 commitext3 마운트 옵션이 도움이 될까요? 예를 들어 commit=60모든 데이터와 메타데이터를 분당 한 번만 플러시합니다.
필수 경고: 이로 인해 최대 1분의 데이터가 손실될 수 있습니다(commit=60 값을 전달하는 경우).
답변2
파일 시스템: 장치가 쓰기 장벽을 사용하는 경우 쓰기 장벽을 비활성화하고 전반적으로 atime 업데이트를 비활성화합니다.
그러나 장애 이벤트(전원 등)가 발생할 경우 더 큰 데이터 손실을 감수하면서 syslog를 조정할 수도 있습니다.
지시어 예 syslog-ng(사용 중인 지시어가 아닐 수도 있음):
flush_lines()한 번에 대상으로 플러시되는 라인 수를 지정합니다. Syslog-ng는 이 라인 수가 누적될 때까지 기다렸다가 단일 배치로 보냅니다.flush_timeout()syslog-ng가 출력 버퍼에 라인이 누적될 때까지 기다리는 시간을 지정합니다. 자세한 내용은 플러시_lines 옵션을 참조하세요.
이 경우 대상은 디스크 파일입니다.