한빛출판네트워크

저자: 루크 A. 카니스(Luke A. Kanies), 역 서성용

파일시스템 배치와 관련해서는 다음과 같은 두 가지 방식이 부각되고 있다. 가능한 한 많이 분리하여, 모든 것을 자신만의 파일시스템에 두는 것이 최선이라는 것과 딱 한 개나 두 개의 파일시스템만을 갖고 나머지는 공동 파일시스템에 놓아야 한다는 주장이 그것이다.

본 기사는 여러분들이 위와 같은 두 주장의 절충지점을 선택하도록 하는 것이다. 서버에서 파일시스템의 수를 증가시키거나 감소시키는 것이 나쁜 것은 아니지만 적합한 이유를 위해서만 수행되어야 한다.

일반적 주의

소수의 파일시스템만 갖는 것은 대개 여러 가지 이유로 추천 할 만하다. 우선 다소 사소하다고 생각될 수도 있겠지만 파일시스템이 적을수록 빈 공간을 모니터하기에 편리하다. 또한 크기를 결정하는 실수에 대해 보다 관대하다. 왜냐하면 모든 것이 각각의 파일시스템에 흩어져 있고 파일시스템이 차지하는 공간에 대한 예측이 부정확했다면 서버에서 한 파일시스템은 거의 꽉 차있고 다른 파일시스템은 거의 비어있는 불행한 상황에 처할 것이기 때문이다.

		리눅스 네트워크 관리자 가이드, 개정판

파일시스템이 가득차는 것에 대해 말하자면 이는 파일시스템의 개수를 증가시키는 이유 중의 하나라고 볼 수 있다. 어떤 유닉스는 /tmp나 /과 같은 특정 파일시스템들이 가득 차는 경우에 동작하는데 문제가 발생한다. 이와 같은 파일시스템들을 확장 경향이 있는 /var같은 디렉토리로부터 분리하는 것은 수많은 골치거리를 미연에 방지하는 것이다. 운영체제를 제외하고도 파일시스템이 가득 찬다면, 이는 일반적으로 무엇인가가 제대로 작동하는 것을 멈추게 한다는 것을 의미한다. 이는 애플리케이션이 자료를 쓰기 위해 기다리며 잠겨있다거나(lock), 로그나 다른 데이터들이 이런 이유로 작성될 수 없고 그 결과 버려지게 되기 때문이다.

운영체제와 애플리케이션용 파일시스템을 배치하는데 있어서, 항상 유념해 두어야 할 요소로는 다음과 같은 것들이 있다. 가장 중요한 것은 백업일 것이다. 아마도 백업이 전혀 필요하지 않는 서버를 설계할 생각은 없을 것이고 적절한 파일시스템을 설계할 경우 백업 과정을 아주 단순화 할 수 있기 때문이다. 어떤 백업 소프트웨어는 오직 전체 파티션들을 백업하는데 백업 규칙에 대한 세분성(granularity)을 상대적으로 크게 만든다. 만약 백업에 대해 보다 엄격한 세분성이 필요하다면 이렇게 할 수 있는 유일한 방법은 자료를 분리 파일시스템으로 쪼개는 것이다.

직접적으로 보이지는 않지만 파일시스템 배치는 시스템 성능에 상당한 영향을 줄 수 있다. 디스크의 첫 번째 실린더들(바깥쪽에 있는 실린더)들은 가장 빨리 회전하기 때문에 최고의 성능을 나타내지만 디스크 헤드가 대부분의 시간을 디스크의 어느 부분에서 사용하는지에 대해서도 고려해야 한다.

만약 시스템이 스왑(보통 두 번째 파티션)을 많이 사용하고 디스크의 마지막 파티션에서 읽기 쓰기가 많이 일어나는 파일시스템을 갖고 있다면, 디스크 헤드는 계속해서 디스크의 앞뒤를 왔다갔다 할 것이다. 중간에 있는 자료는 모두 무시하고 지나치는 동안 끝 부분에서는 미친듯이 작업이 발생한다. 그리고 이것은 서버의 성능을 심각하게 저하시키므로 무슨 일이 있더라도 피해야만 한다.

파일시스템 작동하기

주요 파일 시스템은 아래와 같이 다섯 개가 있다. 그렇지만 파티션 방법에 대한 가이드라인이 시스템마다 그렇게 많이 다른 것은 아니기 때문에 상대적으로 쉽게 다룰 수 있다. 우리가 살펴볼 주요한 파일 시스템은 /, /usr, /var, /tmp, /home 이다.

/tmp

/tmp에 대해 설명하는 것이 가장 쉽다. 이것은 거의 대부분 사용되지 않은 스왑에 저장되는 가상의 파일시스템으로 오직 임시 파일들만을 포함하기 때문이다. 그 자체로는 어떠한 실제의 디스크 공간을 잃는 것도 아니고 데이터의 무결성은 그리 중요하지 않다. 하지만 대부분의 시스템이 전체 스왑 할당으로써 가능한 한 크게 /tmp를 설정하기 때문에 /tmp를 가득 채우는 것은 일반적으로 스왑 공간을 다 써버리는 것을 의미하고 이것은 좋지 않은 일이다. 적어도 솔라리스와 같은 특정 시스템에서는 /tmp를 스왑보다 작은 크기로 제한하도록 하는데 이는 애플리케이션이 정지되고 서버가 리부팅 되는 것을 방지할 수 있다.

/var

/var를 배치하는 것 역시 비교적 쉽다. 왜냐하면 이것은 항상 성장하려는 경향이 있기 때문에 다소 떨어진 곳에 놓여져야 한다. /과 같은 /var를 다른 파티션에 포함시키는 것은 애플리케이션에 심각한 문제가 있거나 하드웨어 고장이 있을 경우 수 기가바이트의 로그가 매우 급속하게 생성될 수 있기 때문에 끔찍한 결과를 낳는다. /var를 가득 채우는 것은 더 이상 로그를 기록할 수 없음을 의미하지만 /를 채우는 것은 서비스 중단을 의미한다.

/var에서 가장 어려운 것은 크기를 결정하는 것인데 어느 정도의 로그 공간이 필요할지 예측하기 어렵기 때문이다. 요즘들어서는 9GB 디스크도 작게 여겨지기 때문에 1GB의 /var 파티션에서 시작해서 점점 올라가도록 해야 한다. 따라서 많은 로그를 남기는 웹이나 이메일 서버에서는 훨씬 더 큰 용량을 필요로 할 것이다. 사실 시스템 파티셔닝을 한 후에 여분의 공간이 있다면 그 공간을 /var에 할당하는 것도 좋은 생각이다. /var에 있는 공간은 로그를 저장할 네트워크 로그 서버를 사용함으로써 절약될 수 있다.

/usr

이 경우, /usr는 /usr/local을 포함할 수도 있고 아닐 수도 있다. 대부분의 오픈 소스 리눅스 시스템들은 /usr/local에 크게 의존하지만 일부 유닉스 변종들은 많은 경우 /usr/local을 몇몇 경우에만 사용하거나 전혀 사용하지 않기도 한다. /usr를 특이하게 만드는 것은 전체가 업그레이드나 패치 과정에서나 수정되는 극도로 중요한 파일들로 구성되어 있기 때문이다. 만약 /usr/local을 이와 비슷하게 사용할 생각이라면 /usr에 포함을 하고 그렇지 않으면 분리 해라.

일반적으로 /usr을 분리하는 것이 좋다고 생각되는 유일한 이유는 / 파티션이 그 안에 모든 애플리케이션을 담고 있거나 안전을 위해 그것을 읽기 전용으로 마운트할 수 있기 때문(필자가 가장 좋아하는 이유)이다. 결국 루트킷에 의해 수정된 파일의 대부분은 /usr에 있다. 만약 이것이 여러분이 필요로 하는 사항과 일치하지 않는다면 설치 특성에 따라서 /에 포함시켜 버리거나 /usr/local과 같이 둘 수 있다. /usr를 다른 것들과 분리함으로써 얻는 장점 하나는 그 크기를 아주 근접하게 설정할 수 있다는 것이다. 이는 파티션의 크기가 거의 커지지 않을 것이므로 업그레이드/패치 공간으로 15퍼센트 정도만을 남겨두면 된다.

/

/를 모든 파일시스템을 담아두는 것으로 생각하고 그 의무를 다하기 위해 충분히 크게 설정하려는 경향이 있기는 하지만 작게 만드는 것이 보다 적절하다는 것을 알게 될 것이다. 애플리케이션용 파일시스템에 대해서는 나중에 설명하겠지만 /var 또는 /usr가 빠진 /는 이제 비교적 작다는 것을 알게 될 것이다. 사실 루트 파티션의 크기를 결정할 때 고려해야 할 목표 중 하나는 가능한 한 크기를 작게 유지하는 것으로 아마 100MB 이하 정도여야 할 것이다. /의 주요 구성요소는 /etc, /dev, 커널, 그리고 정적으로 링크된 바이너리들이기 때문에 이를 성취하기는 비교적 쉬울 것이다.

/usr과 달리 / 파티션은 대개 읽기/쓰기로 마운트되어야 하는데 이곳에 시스템 설정 정보, 디바이스 파일시스템들, /proc 파일시스템(시스템에 설치된 경우에만)이 존재하기 때문이다. 어떤 시스템에서는 /을 작성되지(written) 않아도 되는 지점에 놓는 것이 가능하지만 이렇게 하기 위해서는 시스템을 매우 잘 알아야 한다. 그리고 잘 알고 있더라도 아마 이는 좋은 방법은 아닐 것이다.

하지만 /usr와 마찬가지로 세심히 / 파티션의 크기를 조절하는 것은 훌륭한 파일시스템을 배치한다는 것을 의미한다. 솔라리스에서는 50MB 가량의 데이터만을 갖는 / 파티션을 갖는 것이 비교적 쉬우므로 75MB 크기의 파티션은 서버의 수명을 쉽게 연장시킬 수 있을 것이다.

/home

서버가 어떤 용도로 사용되는지에 따라 /home을 운영체제의 일부로 간주할 수도 있고 애플리케이션의 일부로 간주할 수도 있다. 오로지 관리자들만이 로그인하는 웹 서버가 있다면 /home은 크기가 작고 많은 수정이 가해지지 않을 것이기 때문에 /에 포함될 수 있다. 하지만 LAN에서 사용되는 파일 서버일 경우 /home은 애플리케이션의 일부가 된다. 심지어 /home을 완전히 없애버리고 NFS 마운트된 홈 디렉토리로 대체할 수도 있다. 이것은 애플리케이션과 네트워크 설계에 따라 적절할 수도 적절하지 않을 수도 있으며 얼마나 업타임(up-time)이 /home의 존재에 근접해 있는지를 보여준다(/home을 NFS로 마운트 하는 것은 실패할 다른 구실을 추가시키기 때문).

Application partitions

서버들은 대부분 단일 애플리케이션이나 서비스를 위해 설계되고 그렇게 작동하는 것이 절대적으로 바람직하다. 그리고 이렇게 할 때만이 그 애플리케이션을 개별적인 파티션에 쉽고 이치에 맞게 놓는 것이다. 또한 많은 서버들은 내부 디스크에 운영 체제를 두고 모든 애플리케이션 데이터는 어떤 형태의 배열(array)에 둔다. 이는 운영체제가 갖고있는 것과 같은 디스크에 데이터를 함께 놓아둘 수도 있는 가능성을 확실하게 없애준다.

역시 애플리케이션은 애플리케이션이 하나이든 아니면 여러 개이든, 로컬 디스크인지 배열을 갖고 있든지 간에 파일시스템 레이아웃에서 가장 어려운 부분이다. 어떤 경우 가령 오라클 같은 고성능 데이터베이스의 경우, 애플리케이션 벤더는 파일시스템 레이아웃에 대한 구체적인 요구사항이 있을 것이다. 이는 디스크에 각각의 파티션을 물리적으로 어디에 둘 것인가에 대해서만 결정 사항으로 남겨두기 때문에 이는 완전히 다른 주제라고 할 수 있다. 대부분의 다른 애플리케이션들은 파일시스템 레이아웃에 훨씬 많은 여유를 제공하는데, 이것은 결정하기가 보다 어려워지는 것을 의미한다. 일반적으로 말해, 애플리케이션을 운영체제와 분리하여 별도의 파티션에 두는 것이 가장 좋다. 하지만 이것은 제한된 디스크 공간 또는 서로 다른 애플리케이션이 많을 경우엔 불가능하며, NIS+처럼 본래 디스크 공간을 사용하지 않는 서비스일 경우에는 이 작업을 함에 있어 어떻게 해야 할 지에 대한 요점이 없다.

만약 애플리케이션이 많은 공간을 필요로 할 경우, 그 공간은 개별적인 파일시스템에 있는 공간에 집어 넣을 수 있다. 특히 로그 작업이 아닌 디스크 액세스가 많을 경우에 그렇게 하는 것이 좋다. 만약 애플리케이션이 상당한 양의 로그를 남긴다면 가능한 한 로그를 전부 /var에 저장해라. 특히 그것이 애플리케이션이 실제로 요구하는 I/O의 전부일 경우 그렇게 하는 것이 좋다.

만약 한 서버에서 많은 애플리케이션을 실행할 계획이라면 애플리케이션을 일정한 기준으로 분할하여 실행할 것으로 계획해라. 만약 50개의 매우 비슷한 서비스가 있고 그 서비스 중 어떤 것도 많은 공간이나 I/O를 요구하지 않는다면 나란히 두도록 한다. 하지만 개별적인 공간과 I/O가 필요한 5개의 매우 다른 서비스가 있다면 각각의 파일시스템을 갖도록 하는 것이 좋다.

어떤 애플리케이션은 파일시스템을 다르게 작동시키는 것을 애플리케이션이 /usr/local에 있거나 메일 서버가 /var로 스풀할 경우와 같이 애플리케이션 디렉토리로 전환한다. 어떤 애플리케이션은 /opt에 있기를 선호하며, 어떤 상용 유닉스 변종들은 운영체제와 애플리케이션 데이터 모두를 /opt에 두는 것을 선호하는데 특히 HP-UX가 그렇다. 이러한 경우, 애플리케이션 부분을 /usr/local/apache나 /var/spool같은 별도의 파일시스템에 두는 것이 좋다. 만약 그렇게 할 수 없다면, 전체 파일시스템을 운영체제용 파일시스템보다는 애플리케이션용 파일시스템으로 간주하는 것이 좋다. 이것은 백업 규칙을 간단하게 해주고 데이터 손실과 서비스 중지를 쉽게 막아줄 것이다.

때때로 애플리케이션과 애플리케이션 데이터를 분리해두는 것이 좋을 때가 있다. 웹 서버 설정 파일들과 실행 파일들은 잘 바뀌지는 않지만 웹 서버에서 사용하는 데이터는 대개 아주 자주 변한다. 데이터베이스 또한 데이터와 애플리케이션을 분리해둔다. 이러한 타입의 결정에서는 개별적인 조각들을 개별적인 애플리케이션인 것처럼 취급할 수 있다. 만약 거의 공통점이 없는 I/O와 저장공간을 필요로 할 경우에는 분리되어야 하지만 공통점이 있는 것들은 모아두는 것이 좋을 것이다.

결론

다행히도 이 기사는 전부 중요한 데이터를 파티션하는 방법에 대한 몇 가지 기본적인 가이드라인을 제시함으로써 여러분에게 도움을 주었다. 최근에 대부분의 서버들에 장착되어 나오는 거대한 디스크들 때문에 원래부터 시스템 관리자들을 괴롭혀 왔던 저장공간에 제한은 없지만 부적절하게 서버를 설정해둘 경우 이는 계속해서 시스템 관리자들을 괴롭힐 것이다. 점점 더 많은 운영체제들 역시 포괄적인 볼륨 관리를 제공하고 있는데, 이것은 시스템 관리자가 잘못된 디스크 공간을 예측하는 것으로부터 복구할 수 있도록 해준다. 그러나 어느 누구도 작동하고 있는 서버에서 볼륨들의 사이즈를 변경하고 데이터를 재배치하기를 원하지 않으며, 이는 디스크에서 파일시스템이 어떻게 배치되어 있는가에 따라 보통 stop-gap 솔루션만을 제공할 수 있다. 시스템 파티션 결정에 가장 도움이 될만한 것은 공간을 제공하고자 하는 시간순에 따른 애플리케이션 분석이지만 그러한 분석은 절망적일 정도로 드물다.

시간순에 따른 시스템 분석이 거의 없으므로 이러한 가이드라인만을 따르도록 하자. 얼마나 다양한 파일시스템들이 사용될 것인지 언제나 주의를 기울이고 그 아래 놓여있는 것들은 실제적인 하드웨어임을 잊어서는 절대 안된다. 만약 크기, 구매, 파티션을 결정하는 방법에서 하드웨어 자체를 무시해버릴 경우 세상에서 가장 좋은 파일시스템 레이아웃이라 할지라도 서버가 원활히 돌아가지 못할 수 있기 때문이다.

루크 A. 카니스(Luke A. Kanies)는 운영 체제가 하는 일보다는 운영 체제 그 자체에 더 많은 관심을 갖고 있는 유닉스 시스템 관리자이다. 현재 더 좋은 시스템관리를 하기 위해 강사와 연구자로서 일하고 있다.