모두
모두콘텐츠
얼마 전 파일서버가 느리다는 상담을 받았는데, 서버의 CPU와 메모리에는 여유가 있었다. 문제는 용량이 거의 찬 디스크와 한 번도 시험하지 않은 백업이었다. 파일서버는 처음 접속이 되는 것보다 파일이 늘고 사람이 바뀐 뒤에도 안정적으로 운영되는지가 더 중요하다. 장비를 고르기 전에 저장할 양, 동시에 작업할 사람 수, 장애가 났을 때 허용할 중단 시간을 적어보는 편이 낫다.
파일 크기와 동시 작업량부터 계산한다
전체 직원 수를 동시 접속자로 잡으면 사양이 불필요하게 커진다. 직원이 50명이어도 같은 시간에 큰 파일을 주고받는 사람이 5명인지 30명인지에 따라 필요한 성능은 다르다. 문서와 사진을 열어 보는 정도라면 네트워크와 디스크가 쉬는 시간이 많다. 반면 영상 원본을 여러 명이 편집하거나 작은 파일 수십만 개를 반복해서 읽는 환경은 저장 용량이 같아도 체감 속도가 다르다.
계산은 바쁜 시간 한 구간을 잡아 시작한다. 예를 들어 동시에 10명이 각자 초당 2MB씩 파일을 읽으면 합계는 초당 20MB, 약 160Mbps다. 이 수치만 보면 1Gbps 내부망으로도 여유가 있다. 다만 실제 전송에는 프로토콜 처리와 다른 업무 트래픽이 붙고, 여러 사람이 동시에 대용량 파일을 복사하면 순간 사용량이 치솟는다. 사무실 밖에서 접속한다면 서버의 내부망 속도보다 인터넷 회선의 업로드 속도가 먼저 병목이 될 수도 있다.
저장 공간은 현재 파일 크기만으로 잡지 않는다. 지금 2TB를 쓰고 매달 약 5%씩 늘어난다면 1년 뒤에는 대략 3.6TB가 된다. 여기에 버전 보관, 임시 파일, 여유 공간을 더해야 한다. 목표 사용량이 디스크의 70~80%를 넘지 않도록 잡으면 증설 시점을 예측하기 쉽다. 특히 작은 파일이 매우 많다면 용량뿐 아니라 파일 수와 디렉터리 탐색 속도도 확인해야 한다.
처음부터 비싼 장비를 살 필요는 없다
사무실 안에서 문서 몇 TB를 공유하고 동시 작업자가 적다면 저전력 장비나 보급형 NAS로 충분한 경우가 많다. 이때는 CPU 등급보다 디스크 상태를 확인할 수 있는지, 메모리를 늘릴 수 있는지, 장애 알림을 받을 수 있는지를 먼저 본다. 원격 사용자만 이용한다면 클라우드 저장 공간이 관리 부담을 줄일 수도 있다. 다만 월 저장 요금에 외부 전송량, 백업 공간, 복구에 걸리는 시간을 함께 넣어 계산해야 한다.
영상 편집처럼 지속적으로 큰 파일을 읽고 쓰는 업무라면 SSD와 10Gbps 내부망을 검토할 만하다. 하지만 서버 포트만 10Gbps로 바꿔서는 효과가 없다. 작업자 PC, 스위치, 케이블, 실제 디스크 처리량까지 경로 전체가 받쳐줘야 한다. 반대로 인터넷 회선이 병목인 원격 접속 환경에서는 고가의 내부망 장비보다 회선과 접속 방식을 손보는 것이 먼저다.
디스크를 여러 개 묶는 방식도 목적을 구분해야 한다. 미러링은 디스크 하나가 고장 났을 때 서비스를 이어갈 가능성을 높이지만, 실수로 지운 파일까지 함께 지워진다. 장애가 나지 않게 하는 구성과 이전 상태로 되돌리는 백업은 별도로 준비해야 한다.
권한과 백업은 개설하는 날에 설정한다
공유 폴더를 만들 때 사람마다 예외 권한을 붙이기 시작하면 퇴사자나 부서 이동자가 생긴 뒤 관리가 어려워진다. 부서나 업무별 그룹을 만들고, 폴더에는 그룹 권한을 주는 방식이 단순하다. 읽기만 필요한 사람에게 쓰기 권한을 주지 않고, 관리자 계정은 평소 파일 작업에 쓰지 않는다. 외부 접속이 필요하다면 공개 범위를 좁히고 다중 인증과 접속 기록을 함께 운영한다.
백업은 원본과 다른 저장소에 둬야 한다. 같은 장비의 다른 폴더는 장비 고장이나 랜섬웨어 사고를 버티기 어렵다. 실무에서는 최근 변경분을 자주 보관하고, 별도 장비나 장소에도 사본을 두는 구성이 무난하다. 보관 주기는 파일이 얼마나 자주 바뀌는지에 맞춘다. 하루 작업을 다시 만들 수 없다면 하루 한 번 백업으로는 부족하다.
복구 시험은 파일 몇 개를 실제로 꺼내 열어보는 데서 시작한다. 권한까지 돌아오는지, 폴더 하나를 되살리는 데 몇 분이 걸리는지, 서버 전체를 새 장비에 복구하면 몇 시간이 걸리는지도 재본다. 백업 성공 알림만 믿고 있다가 사고 당일에 암호나 복구 절차를 찾는 일이 생각보다 흔하다. 복구 담당자와 필요한 계정 정보는 서버가 멈춰도 볼 수 있는 곳에 보관한다.
느려지거나 접속이 끊기면 이 순서로 본다
사용자 한 명만 느린지, 모두가 느린지부터 가른다. 한 명이라면 해당 PC의 무선망, 로컬 디스크, 인증 상태를 먼저 본다. 모두가 느리다면 서버의 디스크 여유 공간과 오류 기록, CPU와 메모리 사용량, 네트워크 사용량을 같은 시간대에 비교한다. 용량이 꽉 찼거나 디스크 오류가 반복되는데 CPU만 올리는 식의 처방은 문제를 남긴다.
접속이 안 될 때는 서버 전원과 네트워크 연결, 공유 서비스 상태, 계정 권한 순으로 범위를 좁힌다. 최근에 바꾼 설정이 있다면 변경 시각과 장애가 시작된 시각도 맞춰본다. 급하게 재부팅하기 전에 오류 메시지와 로그를 남겨두면 원인을 찾는 시간이 줄어든다. 디스크 고장 징후가 보이면 쓰기 작업을 줄이고 백업 상태를 확인한 뒤 교체 계획을 잡는다.
파일서버 사양은 넉넉할수록 마음이 편할 것 같지만, 실제 운영에서는 필요한 성능을 측정하고 복구 가능한 상태를 유지하는 편이 더 믿을 만하다. 작은 서버로 시작해도 용량 증가와 동시 작업량을 꾸준히 보면 증설 시점을 놓치지 않는다.
