사용가능한 하드웨어의 다양함과 증명된 성능과 신뢰성 때문에 리눅스는 점점 더 높은 요구수준을 맞추어야하는 도전에 직면해있다. 여기에 포함되는 것으로는 높은 처리 요구에 대응하기 위한 SMP (대칭형 다중 프로세싱 Symmetric Multi Processing) 설정, (소프트웨어 또는 하드웨어 방식의) RAID 레벨 0 부터 5 지원 등이 있다.
가끔은 현재 가동되고 있는 하드웨어에 비하여 리눅스 서버가 너무 커버렸다고 느끼거나 전혀 새로운 리눅스 버전으로 업그레이드하고 싶거나 전혀 다른 리눅스 배포판으로 바꾸고 싶을 때가 있다. 이를 해내는 방법에는 물론 두가지가 있다. 첫번째는 기존의 하드웨어 그대로 또는 업그레이드해서 가는 방법이고 (이 경우에는 서비스를 내리고 데이터를 백업한 다음 필요한 부분을 수정하고 데이터를 복구해주기만 하면 된다) 또 한가지 방법은 새로운 하드웨어로 이전해가는 것이다.
이 섹션에서는 두번째 경우에 집중할 것이다. 이 경우에는 기존의 서버에서 다양한 서비스를 새로운 서비스로 옮겨가야 한다. 서버를 이관하는데에는 여러가지 전략이 있을 수 있지만 이 섹션에서는 대략의 가이드라인을 제시함으로써 이를 따르기만 하면 사용자들에게 최소한의 충격을 주면서 이관할 수 있도록 하려고 한다.
필요에 맞추어 새로운 서버를 준비한다; 새로운 하드웨어 장치를 지원할 수 있도록 하고 데몬과 커널 기반의 기능들 (예를 들어 방화벽) 을 돌아가도록 리눅스를 설치하고 설정한다. 이에 관한 자세한 내용은 제 4 장 과 맞춤 커널 만들기 섹션 - 제 10 장 을 참조하시요.
기본의 서비스를 (예컨대 아파치 웹 서버, 삼바 또는 Netatalk 파일 & 인쇄 서비스 등) 셋업하고 테스트용 자료를 이용하여 며칠간 사용해봄으로써 모든 것이 제대로 동작하는지 확인한다. 이에 대한 자세한 사항은 삼바를 이용한 윈도 스타일의 파일과 인쇄 서비스 섹션 - 제 7 장 과 Netatalk 를 이용한 매킨토시 스타일의 파일과 인쇄 서비스 섹션 - 제 7 장 을 참조하시요. 이전의 서버에서 ``/etc/'' 디렉토리에서 ``/etc/rc.d/'' 등에 수정한 부분이나 따로 넣은 스크립트 등을 새로운 서버에도 필요에 따라 적용시켜 주어야 한다. 그리고, ``/etc/passwd'', ``/etc/group'', 와 만약 섀도우 패스워드를 사용하고 있다면 ``/etc/shadow'' 에 들어있는 사용자 계정 정보를 옮기는 것이 특별히 중요하다!
예전 서버에서 서비스를 내려서 파일 시스템에 변화가 최소한으로 나타나게 한다. 당연히 자료를 새 서버에 복구하는 중에 예전 서버에 사용자들이 웹 페이지를 올리거나 전자메일을 받아가도록 하면 안된다! 대부분의 서비스를 내리기 위해서는 루트로서 다음과 같이 명령을 내리면 된다:
killall httpd atalkd smbd nmbd squid sendmail ftpd |
위의 명령은 웹 서버, 파일 & 인쇄 서비스, 전자메일 서버, FTP 서비스를 중단시킨다. (내가 위에서 열거한 서비스 보다 더 적거나 많은 서비스를 돌리고 있을 수 있다. 프로세스 목록을 살펴보고 필요하다고 느껴지는 것이 있으며 그것도 중단시켜야 한다; 자세한 내용은 프로세스 관리 섹션 - 제 9 장 을 참조하시요.)
그리고 예전 서버에서 ``/etc/inetd.conf'' 파일을 편집하여 ``#'' 글자를 사용하여 파일 시스템에 변화를 일으킬 수 있는 모든 서비스 (예컨대 FTP, IMAP, POP3 서비스) 를 주석으로 막아버려야 한다. 그리고 나서 다시 루트로서 다음과 같이 타이핑한다:
killall -HUP inetd |
위의 명령은 (인터넷 서비스를 위한 보안 래퍼인) TCP 래퍼를 다시 올려서 ``/etc/inet.conf'' 파일에서 막아둔 서비스가 더이상 연결되지 않도록 한다.
이제 한 시스템에서 다른쪽으로 자료를 옮길 수 있다. 새로운 서버는 필요한 소프트웨어 중에서 레드햇 배포판에 포함되어 있지 않은 소프트웨어까지 설치되어 필요한 기능을 모두 할 수 있도록 이미 준비되어 있어야 한다. 이제, ``/home'', ``/var/spool'', 그리고 만약 있다면 선택적인 파일 시스템인 ``/archive'' 에 저장된 자료를 백업하여 새로운 시스템에 복구하여야 한다. 다음의 예는 ``tar'' 유틸리티를 사용하여 압축된 백업 파일을 만드는 과정을 보여준다:
cd /
tar zcvpf /tmp/backup_data.tar.gz --exclude=var/spool/squid \
home archive var/spool |
위의 명령은 ``/archive'', ``/home'', 과 ``/var/spool'' 파일 시스템 (또는 시스템의 셋업 상태에 따라서는 서브디렉토리) 의 백업본을 ``/tmp/backup_data.tar.gz'' 라는 이름의 파일에 압축된 타르 형식으로 기록한다. 백업 파일을 만들 수 있는 충분한 공간이 있는지 확인해야 한다!
Tip: 팁: 필요한 공간을 미리 알기 위해서는 ``du'' 유틸리티를 사용하면 도움이 된다. 예를 들어, ``/archive/'' 와 ``/home/'' 디렉토리 트리가 얼마나 되는지 알아보려면 다음과 같이 타이핑하면 된다:
위의 명령은 자료의 실제 크기를 보여주는 반면에 백업 파일을 만들때에는 크기를 줄이기 위하여 타르 명령에서 ``z'' 옵션을 (앞의 예에서 처럼) 사용하기 때문에 실제 필요한 공간은 훨씬 적을 수 있다는 점을 명심하여야 한다. 따라서 ``du'' 명령의 결과값은 최악의 경우에 해당하는 추정치라고 생각하면 된다.
이제 타르 파일로부터 백업한 자료를 새로운 서버에 복구하면 된다. NFS 를 (NFS 설정에 대한 상세한 정보는 네트웍 파일 시스템(NFS) 서비스 섹션 - 제 7 장 을 참조하시요) 이용하여 직접 복구할 수도 있고 일단 FTP 를 이용하여 타르 파일을 옮긴 다음 새 서버에서 타르를 풀 수도 있다. 다음은 앞에서의 예시에서 만든 파일을 복구하는 과정을 보여준다:
cd / tar zxvpf /tmp/backup_data.tar.gz |
그 다음은, 필요하다면, IP 주소를 변경하여 새로운 서버가 예전의 서버 주소에서 보이도록 해준다.
마지막으로 서버를 내렸다가 다시 시작시켜서 아무런 에러 메시지가 나오지 않는지 확인하여야 한다. 서버를 내리고 재시작하는 과정에 대한 자세한 설명은 시스템의 종료와 재시작 섹션 - 제 6 장 을 참조하시요.
일단 끝나고 나면 모든 것이 기대한대로 동작하는지 확인하여야 한다! 만약 그렇지 않으면 항상 예전 서버에서 중단시켜두었던 서비스를 다시 가동시켜서 새로운 서버에서 나타난 문제가 해결될 때까지 사용자들이 계속 서비스를 이용할 수 있도록 하여야 한다. (하지만 이렇게 하기로 하였다면 앞에서 얘기한 모든 단계를 몽땅 다시 하여야 한다는 점을 명심하라)